The test case for most single-request, single-response scenarios have two steps:
The test case can also include a Unique Code Generator data set for generating a correlation ID.
The following graphic shows an example test case. The first step is a do-nothing step. The second step is a messaging step with the name Request/Response.
The data set contains information that changes for each transaction in the baseline. This information includes the request payload, response payload, and JMS message properties. By default, the data set is local, instead of global.
The messaging step includes a Graphical XML Side-by-Side Comparison assertion with the name Assert Response Equals. When you run the baseline test case, this assertion verifies that the actual response matches the expected response. If the responses do not match, then the test generates an error.
Other scenarios divide the request and response into separate steps.
The following graphic shows an example test case. The first step is a do-nothing step. The second step is a messaging step with the name Request. The third step is a messaging step with the name Response.
Configuration properties are generated for destination information, connection information, and XML diff options. If the client and service use different JNDI connection settings, then two sets of properties are generated for the connection information.
To run the test case, do one of the following actions:
You can monitor the results in the Consolidated Baseline tab.
Note: For information about how to stage a quick test or a test case, see Running Test Cases and Suites in Using CA Application Test.
Copyright © 2014 CA Technologies.
All rights reserved.
|
|