WA1670 SOA Testing Workshop. Student Labs. Web Age Solutions Inc.

Transcription

1 WA1670 SOA Testing Workshop Student Labs Web Age Solutions Inc. 1

2 Table of Contents Quiz...3 Labs - A Note to the Students...12 Lab 1 - Getting To Know a Service...13 Lab 2 - WSDL Tests...23 Lab 3 - Functional Testing of a Web Service...30 Lab 4 - Expose Bugs with Negative Testing

3 Quiz Chapter 1 - Introduction to SOA Testing Q1. SOA Testing follows most of the best practices and methodology of Enterprise Application Integration (EAI) testing. 1. True 2. False Q2. In SOA, the following components need to be tested. Multiple selections apply. 1. Business processes 2. Third party adapters 3. Adapters developed in-house, if any 4. Legacy applications 5. Services that wrap legacy applications Q3. Proper order for testing phases is: 1. Unit testing Stress testing Integration testing 2. Integration testing Stress testing Unit testing 3. Unit testing Integration testing Stress testing Q4. A stub in SOA testing is: 1. A patch that fixes a defect. 2. A fake component that emulates a component that a component being tested depends on. 3. A fake component that emulates the component being tested. 4. A component that transforms XML data to binary data. Q5. In SOA testing, a verifier: 1. Is an IT governance process. 2. Validates the results of a test. 3. Validates the performance metrics of a test. 4. Only validates the output data of a service operation. Answers: Q1: 1. Q2: 1, 3, and 5. Q3: 3. Q4: 2. Q5: 2. 3

4 Chapter 2 Unit Testing Q1. Unit testing is performed by: 1. Professional testers 2. Project managers responsible for the ultimate quality of a software 3. The developers 4. The end users Q2. Unit test should be highly automated. 1. True 2. False Q3. Unit test the following components of a Web service. (You can select multiple answers.) 1. The Web service itself (by sending SOAP request). 2. The Java or C# class that implements the Web service. 3. The database schema where data is stored by the Web service. 4. The HTTP server where the SOAP request is posted. Q4. An adapter needs to be tested when: 1. The service being tested wraps a legacy application and the ESB product requires an application-specific adapter. 2. When an adapter is required by the ESB but the legacy application's vendor does not provide an adapter and an adapter needs to be developed in-house. 3. When the legacy application uses.net. 4. When the legacy application communicates with other applications by exporting and importing files. Q5. How will you verify a service operation that does not return any output data? (You can select multiple answers.) 1. By measuring its performance. 2. By invoking another operation, the output of which can determine the success of the first operation. 3. By validating the internal state of the application that the service wraps. 4. By checking the HTTP reply code. 5. By checking the log file. Q6. The following constitutes unit testing for boundary conditions. (You can select 4

5 multiple answers.) 1. Null input data. 2. Empty string. 3. Array of length A very large string. Q7. A service operation said to be idempotent if: 1. It is thread safe. 2. It uses large amounts of memory. 3. It processes the same input data only once. 4. It processes the same input data (at a maximum) twice. Q8. Although a service may be stateless, an operation can depend on another operation to be invoked first. For example, a product must be added to the catalog before it can be purchased. Why then test for "out of sequence" operation calls? 1. Malicious or buggy code can invoke operations out of sequence that can harm the internal state of the application. 2. Out of sequence operation call is used to detect memory leaks. 3. Out of sequence call testing can cause excessive CPU usage. Q9. A data map, D1, maps data format A to B. Another data map, D2, maps B to A. Which of the following statements is true? 1. If D2 passes test, there is no need to test D1. 2. If D1 passes test, there is no need to test D2. 3. Both D1 and D2 need to be independently tested. 4. Testing data maps is not necessary. Q10. A data map converts data for a target legacy system, which can handle ASCII text only. Which statement is true? 1. The data map will always fail if the source data does not use ASCII encoding for text data. 2. If the source data has Japanese text in UTF-8 encoding, there may be data loss after conversion. You will need to test the map for that. 3. If the source data has Japanese text in UTF-8 encoding, there will be no data loss after conversion to ASCII. 4. SOA is not meant to handle a scenario like this where different systems use different text encoding. 5

6 Q11. You are developing a business process and need to unit test it. Over half the services the business process invokes are not ready. You will: 1. Inform your manager of the situation and ask her to put pressure on the other departments to make their services available for testing. 2. Run unit testing anyway, which will invariably fail, and then open a defect. 3. Use stubs for the missing services and unit test the process. 4. Wait for other services to be available. Answers: Q1: 3. Q2: 1. Q3: 1, 2. Q4: 2, Q5: 2, 3. Q6: 1, 2, 3. Q7: 3. Q8: 1. Q9: 3. Q10: 2. Q11: 3. 6

7 Chapter 3 Integration Testing Q1. Integration test is required because (multiple choices apply): 1. Developers are not always the best testers of their own work. 2. Developers should not do any kind of testing. Their job is to write code but not to test. 3. Developers often work using hardware and an operating system that is different from the production system. 4. We need to test an entire SOA solution with all the components working together. Q2. Build Verification Test (BVT) is required because: 1. A build with obvious defects can cause major productivity loss among the integration testers. 2. BVT catches code compilation errors. 3. BVT automatically runs most test cases, reducing the work of the integration testers. 4. BVT is only required if a component is written in Java. Q3. A regression test is required because: 1. It will automatically catch defects in the features that are new in a build. 2. We don't want to run all test cases to re-test the existing features. Our focus is to test the new features only. 3. It is used to detect performance problems. Q4. According to good IT governance practice, the quality of a component should be certified by: 1. The team that owns the development of the component. 2. The team that owns the quality control of the component. 3. The team that deploys and administers a component. 4. A body composed of managers from all of the above teams. Q5. If a service wraps a legacy application, you should (multiple answers may apply): 1. Set up a test installation of the wrapped application. 2. Set up test accounts and data in production system if a test installation can be created. 3. Always use the production system of the wrapped applications. 4. Such a scenario cannot be tested. Such services will go into production without 7

8 testing. Q6. Which one of the following tasks is not performed during integration testing of a process? 1. Configure the network connectivity between the machine running the process and the machines running the services. 2. Enter the endpoint information of the services in the process configuration. 3. If a service is accessed using SOAP over message queue, use SOAP over HTTP for integration testing. This will simplify the test. 4. Install the Web-based application that supports the human tasks in the process. Q7. In a test script created to test a service, a test case is: 1. A spreadsheet of input data. 2. A carefully sequenced list of operation calls that mimic a real-life usage scenario. For each operation, input data and validators are registered. 3. A carefully sequenced list of operation calls that will be used to test the system in a way it was not intended to be used. Q8. Before running a test case, the business state of applications needs to be initialized using the following ways (you can select multiple answers): 1. By specifying input data for the operations in the test case. 2. By running SQL scripts that restore the application databases to a known state. 3. By restoring the application databases from a backup. 4. By running certain service operations that effectively bring the state to a known level. For example, call an operation to add product before running a test case that searches for the product and purchases it. Q9. The following actions are taken when designing a test case for a business process (you can select multiple answers): 1. Validators are added for an activity that invokes an external service operation. This validator validates the output data of the operation. 2. A validator is added to validate the output of the business process. 3. Add validators that validate the business process state variables after certain activities are executed. 4. Add path coverage validator to ensure that an activity is executed (or not executed) when the test case is run. 8

9 Answers: Q1: 1, 3, 4. Q2: 1. Q3: 2. Q4: 2. Q5: 1, 2. Q6: 3. Q7: 2. Q8: 2, 3, 4. Q9:1, 2, 3, 4. 9

10 Chapter 4 Non-functional Test Q1. Non-functional tests happen before a component is integration tested. 1. True 2. False Q2. Which one of the following is not a type of non-functional test? 1. Performance test. 2. Testing for memory leakage after long usage. 3. Testing to see if an operation fails with null input data. 4. Security testing. Q3. The following need to be done during a stress test of a service (you can select multiple answers): 1. Measure the average response time of the operations called. 2. Carefully set the active load that represents the production environment and yet takes into account the differences in hardware capacity between production and test. 3. Check the temperature of the server. 4. Look for errors taking place in the service due to heavy concurrent operation calls. Q4. When should you test for securing a SOAP message using a digital signature? 1. When service usage policy requires the consumer and service provider to use message encryption. 2. When the service usage policy requires the consumer and service provider to use digital signature. 3. Test for digital signing anyway even if there is no plan to use it in production. 4. When SSL communication is required by the service usage policy. Q5. To test for SQL injection vulnerability, you: 1. Check if the firewall allows someone from the Internet to open a connection to an internal database. 2. Check if you can supply SQL fragments as input data and have the database system execute those statements. 3. Make sure that the application gracefully returns an error code when any text data starts with INSERT, UPDATE, DELETE, or SELECT. Q6. To test for Web service interoperability, you will: 10

11 1. Test to make sure that the network connection is up between the service provider and consumer. 2. Make sure that the service provider supports SOAP over HTTP. 3. Create test cases by carefully going through the WS-I guidance for common interoperability concerns. 4. Make sure that the service provider and consumer applications are written using the same programming language. Q7. Process state persistence testing is important because: 1. A process needs to save state in the database to save memory. 2. A process instance may run for a long time. If the server shuts down, the instance should begin execution after the server restarts. 3. Multiple instances of the same process may be running. 4. Multiple versions of the same process may be running. Answers: Q1: 2, Q2: 3. Q3: 1, 2, 4. Q4: 2. Q5: 2. Q6: 3. Q7: 2. Chapter 6 - SOA Testing Tools Go to Click on Product Demo and watch the video for an excellent presentation of how Web services are tested using an automated tool. 11

12 Labs - A Note to the Students These lab exercises are designed for testers. The lecture portion of the class is highly theoretical. These labs bring the theory to life. You will get to see most of the SOA testing concepts in action. By doing the labs, you will actually get to see some of the SOA testing tools in action and understand different areas of SOA testing. You don't have to write much code. In most cases, you will import relevant code. You will inspect various developed artifacts as if you are doing code review. Finally, you will execute the code to see a particular aspect of SOA in action. These labs use WebSphere Integration Developer (WID) as the IDE. The goal of the labs is not to teach you how to use this tool, so don't worry too much about how the imported applications are developed. Just focus on the key concepts. 12

13 Lab 1 - Getting To Know a Service By now, you may already have an idea of what a service is. From a technical point of view, a service is a collection of operations. This notion is very close to distributed objects like EJB, CORBA, or Microsoft DCOM. But, unlike such technologies, a service is more of a concept that describes what a software application can do for other applications. Each business task is represented as an operation. A service can be built using many different technologies and support different communication protocols. A service may be offered by a human user. In this lab, we will inspect the elements of a Web service. In this case, the Web service represents a warehouse system. Orders can be created in the warehouses. Their status can be queried. The architecture of the service is as follows. OnlineOrderWeb (Consumer) The Web service is located in the USWarehouse project. A Web-based ordering software acts as a consumer of the service. This application is in the OnlineOrderWeb project. In the next lab, we will functionally test this application; therefore it's necessary to first understand the application. Part 1 - Import the Applications Note: WebSphere Integration Developer (WID) is used by service integration developers who string together services to create business processes. In our course, we will use WID to view services and business processes that have been developed for you (since the focus is on testing). SOA testers will also find themselves using WID to understand services and business processes. The first lab also provides an opportunity to get familiar with this tool. 1. Launch WID by selecting Start > All Programs > IBM WebSphere > Integration Developer V6.0.2 > WebSphere Integration Developer V In the workspace selection dialog, type C:\wid6\workspace as the folder name. 3. Check the Use this as the default and do not ask again check box. 4. Click OK. 5. Close the Welcome page if it displays. Prior to working with the tool, enable the Web services development feature. 6. From the menu, select Window > Preferences. USWarehouse (Service Provider) 13

14 7. Expand Workbench > Capabilities. 8. Check the Web Service Developer check box to enable it as shown below and click OK. 9. From the file menu, select Window > Open Perspective > Other. 10. Check the Show all check box, then select J2EE from the list and click OK. If the Confirm Enablement dialog displays, click OK. 11. Start importing the projects using File > Import from the menu. 12. Choose Project Interchange as the import source. Click Next. 13. Use Browse to select C:\LabFiles\Lab1\Warehouse.zip as the file to be imported and click Open. 14. The system will show all the projects located in that ZIP file. Click Select All to select them all. 14

15 15. Click Finish to import the projects. 16. To view the projects just imported, in the Project Explorer view, expand Enterprise Applications and Dynamic Web Projects. Part 2 - Deploy Applications to the Server We will use WebSphere Process Server as the test server. WPS is an application server with J2EE and SOA capabilities. 1. Open the Servers view. 2. Right click WebSphere Process Server v6.0 and choose Start to start it. 15

16 3. Wait for the server to start. You will see, in the Console view, the message Server server1 open for e-business. 4. Change to the Servers view and verify that the WebSphere Process Server v6.0 server status has changed to Started. 5. Right click the WebSphere Process Server v6.0 server again and choose Add and remove projects. 6. Click Add all to deploy all projects to the server. 7. Click Finish. Watch the bottom right hand corner of the screen to see the progress of the deployment operation. Wait for it to complete. Part 3 - Inspect the Web Service Specification In this part, we will inspect various elements of the USWarehouse Web service. First, we will look at the WSDL file of the Web service. The Web service is created in a J2EE Web module called USWarehouse. 1. In the Project Explorer view, expand Dynamic Web Projects > USWarehouse > WebContent > WEB-INF > wsdl. 2. Locate the USWarehouse.wsdl file. 3. Double click the file. The system will open the interface editor and show the interface of the service. Notice that there are two operations supported by this service. FindOrderStatus: Takes as input an order ID. Returns a Status object. PlaceOrder: Takes as input an UserOrder object and returns a Status object. The interface editor does a good job in showing the interface in an easy-to-understand manner. But, for us to get a better understanding of the service, we must look at the code of the WSDL file. 16

17 4. Close the interface editor. 5. Right click USWarehouse.wsdl and select Open With > XML Source Page Editor. Looking through a WSDL file can be intimidating. We will learn about WSDL later. For now, we will skim through the file and look for important information only. 6. Locate and briefly look at the schema of the Status and UserOrder object. <complextype name="status"> <sequence> <element name="status" nillable="true" type="xsd:string"/> <element name="orderid" nillable="true" type="xsd:string"/> </sequence> </complextype> <complextype name="userorder"> <sequence> <element name="address" nillable="true" type="xsd:string"/> <element name="country" nillable="true" type="xsd:string"/> <element name="lineitemlist" nillable="true" type="impl:arrayoflineitem"/> <element name="zip" nillable="true" type="xsd:string"/> </sequence> </complextype> 7. Scroll down and locate the <porttype>. <wsdl:porttype name="uswarehouse"> A <porttype> defines the service specification. Notice the two operations are listed there. For example: <wsdl:operation name="findorderstatus"> 8. Next, move to the binding section. Here, we specify the format of the request and response messages. Have a look the following snippet: <wsdl:binding name="uswarehousesoapbinding" type="impl:uswarehouse"> <wsdlsoap:binding style="document" transport=" <wsdl:operation name="findorderstatus"> <wsdlsoap:operation soapaction=""/> <wsdl:input name="findorderstatusrequest"> <wsdlsoap:body use="literal"/> </wsdl:input> Key information shown in boldface includes: 17

18 Presence of the <wsdlsoap:binding> tag indicates that messages should be formatted using SOAP. The use of style "document" and for operations "literal" means that the Document literal dialect of SOAP should be used. 9. Finally, scroll down and locate the <wsdl:service> tag. This contains the service endpoint information. For example: <wsdlsoap:address location=" 10. Close the file. Part 4 - Inspect the Service Implementation The last element of a service is its implementation code. In our case, a Java class is used to write the business logic. In Java, JAX-RPC specification is used to write Web services. According to this specification, a Web service can be implemented as a plain Java class in a Web module or a stateless session EJB in an EJB module. 1. In the Project Explorer view, expand Dynamic Web Projects > USWarehouse > Java Resources > JavaSource > com.webage.warehouse. 2. Double click USWarehouse.java. 3. You will see two public methods called placeorder and findorderstatus. Take a cursory look at them. 4. Close the file. Part 5 - Test the Application Now, we will test the system by running the consumer application. 1. Open a Web browser. 2. Enter the URL: 3. Enter some kind of input value as shown below. 18

19 4. Click Place Order. The system will show this page: Nothing terribly exciting occurs. The end user has no visible clue that the Web application invoked a service operation to send the order to the warehouse. Part 6 - Inspect SOAP Messages Now, we will monitor the communication between the service consumer and provider. This will give us a chance to look at the SOAP formatted messages. 1. In the Servers view, right click the server and select Monitoring > Properties. 2. Click Add. 19

20 3. Select port 9080 to monitor as shown above. Click OK. 4. Select the newly added port to be monitored and click Start. 5. Click OK to close the monitor configuration dialog. According to the service endpoint URL we have seen before, the consumer connects to the service using port We need to change that to 9081 so that we can connect through the monitor that will then forward messages to the actual service over port This change will be done in the consumer application. OnlineOrderWeb (Consumer) 9081 TCP/IP Monitor 9080 USWarehouse (Service Provider) 6. In the Project Explorer view, expand Dynamic Web Projects > OnlineOrderWeb > WebContent > WEB-INF > wsdl. 7. Right click USWarehouse.wsdl and select Open With > XML Source Page Editor. 20

21 8. Scroll down and change the endpoint URL to use port 9081 as shown below. <wsdlsoap:address location=" 9. Save and close the file. 10. In the Servers view, right click the server and select Restart Project > OnlineOrderApp. 11. Now, we are ready to monitor SOAP messages. Go back to the Web browser and view the order entry page ( Enter some kind of input and submit the form. Make sure that you see the order status page. 12. Go back to WID. 13. Open the TCP/IP Monitor view. You can do this by selecting 'Window -> Show View -> Other', expanding the Debug group of views, selecting the TCP/IP Monitor view and clicking the OK button. 14. The system will show the SOAP request just made. Select it. 15. Choose XML View for the request and the response. The system will show the SOAP messages. Briefly go through the message. 16. Change the port number back to 9080 in the consumer-side WSDL file the way you did it before. 17. Restart the OnlineOrderApp project. 18. To Stop the server, right click on the WebSphere Process Server v6.0 server and select Stop. 21

22 19. Switch to the Servers view and verify the status is stopped. 20. Close the Web browser and all open editors. 21. Close WID. Part 7 - Review In this lab, we took a brief look at a service that is a Web service. We observed the following elements of the service: 1. The schema of the data types used in the operations. 2. The service specification (porttype). 3. The binding configuration. 4. The endpoint settings. 5. The implementation Java class. We also observed the SOAP formatted request and response messages. If you are new to Web services, this lab should demystify the key concepts for you. 22