Introduction to SoapUI day 2
•Als PPTX, PDF herunterladen•
0 gefällt mir•974 views
A method of communicating between two devices A software function provided at a network address over the web with the service always on It has an interface described in a machine-processable format http://www.qualitestgroup.com/
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Introduction to SoapUI day 2
Ähnlich wie Introduction to SoapUI day 2 (20)
Mehr von Qualitest
Mehr von Qualitest (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Introduction to SoapUI day 2
- 1. Introduction to SOAPUI ANY QUESTIONS?? 1
- 2. Introduction to SOAPUI BUILDING TEST CASES 2
- 3. Building Test Cases • Creating Test Suite, Test Cases & Test Steps • Unit vs. Functional Tests • Parameterization of Data (Text file, excel, Database) 3
- 4. Hierarchy • Test Suite – Test Case • Test Steps – Soap request – REST request – HTTP request – AMF request – JDBC request – Data source/Data Gen – Manual test – Mock Response 4
- 5. Test Suite • From the Project level you can create an empty Test Suite 5
- 6. Test Suite from Operation Level 6
- 7. Adding a Request to a Test Case 7
- 8. Options for Test Case 8
- 9. Test Suite • Defaults placeholders for Load Tests and security tests are also added: • Name is operation name + request name 9
- 10. Test Case Window 10
- 11. Run the Test Case 11
- 12. Test Case Properties 12 Add properties such as TestCase Description
- 13. Adding New Test Steps • Click on type of request • Or drag and drop existing request 13
- 14. Parameterization of Data • Input data to drive the tests can come from – Text file – Excel sheet – Database • Can also parameterize the expected outputs 14
- 15. DataSource test step • DataSource – reads test data into properties from some external source • TestStep – uses the available properties • DataSource Loop – calls the test step(s) for each record of data 15
- 16. Let’s set up another Test Suite New Test Suite with Test Case 16
- 17. Setup Internal Data Source 17
- 18. Use Properties to add Columns 18
- 19. Add in Data in Grid 19
- 20. Add Test Soap Request Test Step 20
- 21. Map the Inputs to Test Data 21
- 22. Map the 2nd Input Field to the Data 22
- 23. Also want to Verify Response • Click Assertions tab under request 23
- 24. Add Assertion 24
- 25. Add XPath Assertion 25
- 26. Map Expected Result to Data Source 26
- 27. Finish Mapping & Save 27
- 28. Now add the Loop 28
- 29. Then Run the Test • By default stops on error 29
- 30. Double-Click to see Details 30
- 31. Update Expected Results 31
- 32. Data Source- Excel • Convert existing data store to EXCEL 32
- 33. 33
- 34. Add Properties Back 34
- 35. Data Mapping • If data source name and properties are the same, no need to remap 35
- 36. Set Test Case Options 36
- 37. PTO Patent Validation • Let’s take a look at • http://patft.uspto.gov/netahtml/PTO/index.ht ml • And the Bib WSDL 37
- 38. 38
- 39. Quick or Advanced Search 39
- 40. Pick one & Review Data 40
- 41. Data 41
- 42. Exercise • Create Excel based expected results for several of the web services • Create test cases to provide inputs to these web services • Set up an excel data source for the validation of the responses • Execute your tests 42
- 43. Instead of Excel, lets pull from DB • PALMFQT.ETC.USPTO.GOV = • (DESCRIPTION = • (ADDRESS = (PROTOCOL = TCP)(HOST = dev-jackson-scan. etc.uspto.gov)(PORT = 1610)) • (CONNECT_DATA = • (SERVER = DEDICATED) • (SERVICE_NAME = PALMFQT) • ) • ) • USER – FTDUSR • Pass - FTDUSR_USPTO2014 43
- 44. SQL • select appl_Id, Invn_ttl_tx, INV_SUBJ_MATTER_TY, FILE_DT, • FRGN_FILE_LIC_DT, DOMESTIC_IN, PCT_PUB_NO, PCT_PUB_DT, • APPL_TY, • PCT_NO, • PATENT_NO, • DN_PTO_ART_CLASS_NO, • DN_PTO_ART_SUBCLASS_NO, • b.fmly_nm, • b.givn_nm • from apc a, expousrp.ped_inventor b • where appl_id = '61245662'---like '293%' • AND A.FK_PC_ID = B.FK_PED_FK_PC_ID • order by 1; 44
Hinweis der Redaktion
- At the highest level we have Test Suite; a Test Suite can have one or more test cases and each test case can have one or more test steps (which can be a mix of requests) soapUI structures functional tests into three levels; TestSuites, TestCases and TestSteps. A TestSuite is a collection of TestCases that can be used for grouping functional tests into logical units. Any number of TestSuites can be created inside a soapUI project to support massive testing scenarios. A TestCase is a collection of TestSteps that are assembled to test some specific aspect of your service(s). You can add any number of TestCases to a containing TestSuite and even modularize them to call each other for complex testing scenarios. TestSteps are the "building blocks" of functional tests in soapUI. They are added to a TestCase and used control the flow of execution and validate the functionality of the service(s) to be tested.
- Select New TestSuite from right clicking on project name
- If you right click on the operation name you can select Generate TestSuite so if you have all of the requests set up and want to combine them into one test suite, this is an easy way to do that
- You can add a request to a test case from multiple places – from the request window itself or by right-clicking on the request – then you need to enter the name of the test suite and then it will ask you for the test case name – you can use the same request to create multiple test cases.
- These are the default settings for test cases- you can always go back and make changes. We haven’t talked about assertions yet, but we will
- After creating the test suite and adding the test case, the Test Case window opens and provides additional tabs for adding more information
- The test case window reports the results after clicking on the green arrow to run the test once
- You can directly add in properties of the test case in the test case window.
- There are 2 ways to add additional test step – click on the request type or drag and drop and existing request
- There are multiple sources for the data including text file , excel sheet and any odbc accessible database – note to use obdc, you will need to install that option in soapUI
- A datasource test step is used to read in the data from an external source, the test step will then use the data and by looping through all of the lines in the data, you can execute multiple tests.
- Right click on the project and select new test suite Then right click on the test suite and select new Test Case
- Pick the Grid so that you can input the data in the internal data structure
- Click on + on upper left to add a property
- Just type in the cells the values you want
- To facilitate finding all of the elements for mapping, I usually run a valid request first
- Pick the request to add to the test step and then from the form input field, click on GetData and navigate to the internal data source that we just created
- Here are the XML and outline views after you’ve mapped the data fields
- If you want to verify the expected results and/or the response that comes back, we need to add an assertion
- To add assertion you can right click on the item or click on the + icon right above it then you have your options of what to verify
- Select the icon on the top left and then select the response field in the popup window and select OK
- Right click on select content and then navigate to the 3rd column in your internal data structure
- After you select the field and any options for the expected result, click Save - While an XPath query pointing to <myElement>Some Text</myElement> will return Some Text, a query pointing to the empty element <myElement /> will instead return <myElement />. To instead return an empty string on empty elements, surround your XPath query like this: concat( //my:XPath/query[1] ).
- The request now uses the To and From properties in the DataSource and the Assertion uses the Rate. All that is missing now is an DataSource Loop at the end of the TestCase that loops back to the Request for each row in the DataSource. Add a DataSource Loop step from the TestCase toolbar, double-click it and configure it to loop back to the Request for each row in your DataSource
- Not surprisingly you get an error from the assertion in the first run of the request. Your expected Rate was not that returned by the web-service . Double click the Failed TestStep in the TestCase log (which opens the message viewer) and select the response tab to see what was actually returned.
- Double click on the error to see the results and then navigate between the request and response message tabs
- Run again after updating the expected results – it may still fail because currency conversions can be somewhat dynamic – we will talk about handling that later
- Navigate back to the Data store for the test suite and double click to open the editor
- Can use an existing file or setup a new file for your data – the ignore empty can be a good way to control the tests if you just want to try a few before running them all – leave an empty row and then ignore the row to run the whole set the Data Source options also provide for additional ways to control the data usage
- Since the data source was changed, we lost the properties – have to add them back in to point to the excel sheet – note that in my excel sheet I have a header, so I really want to start at A2, not A1
- In general it’s a bad idea to reuse the same names for different data sources
- By default the test suite will stop running as soon as it hits an error – if it doesn’t hurt anything to continue, you can turn this off. In addition the fail testcase on error is a choice – depends on if you are counting the entire test suite as one test case or if each line in a data file is one test case. Also, SoapUI does have memory issues – so if you don’t need to preserve the results for test cases that have passed, you can also select this option.