Task flow: Advanced test data scenario

In this scenario, the model of the system under test is set up manually by doing two tasks:

1. Specifying the logical and physical resources of the system
2. Defining the environment for binding the logical and physical resources

In this scenario, the format of the message used by the transport is imported as schema and the message exchange pattern is defined for the operations used by the system. The tests and test suites are created using the defined message exchange patterns and the system is tested.

• Create a project: After you have set up the results database and configured the required setup to enable testing the system under test, start HCL OneTest™ API and create a new project. Creating a new project goes through various stages where you must specify the project name and location. You can optionally specify the details for connecting to the results database and HCL® Quality Server, also set up user-based permissions and the change management integration.
• Create the Logical View: The Logical View provides an abstract view of the system under test and does not tie using any particular infrastructure. In this view, you can define the database and the web services required by the system. You do not need any details such as the database URL, connection details, or the type of database provider.
• Create the Physical View: In this view, you must specify the available physical resources and their location details. Each resource within the Physical View represents a single configuration of an infrastructure component described in the Logical View. The Physical View defines all of the implementation options. For example, if you use three separate databases across all different environments, you can specify all the three databases in the Physical View.
• Define the environment: You specify the environment to bind the logical and physical resources together. At any stage, HCL OneTest™ API can check which environment is being used. If a reference is found to a logical infrastructure element, it uses the environment to find the correct physical component. For example, if a database within a test or a stub must be accessed, HCL OneTest™ API looks up the environment to determine which of the three databases should be accessed. If you then move to another environment, HCL OneTest™ API performs the lookup again, and selects the appropriate database. This applies to any infrastructure such as databases, web servers, Java™ Message Service (JMS), or any proprietary technologies.
• Import the schema: To test the format of the messages going to and from the web services, you have two options:
  • Create a schema.
  • Import the schema from a resource into the schema library.
• Create tests using the Message Exchange Pattern: The final stage of building the system model is to state how the operations will make use of the message schemas that have been provided. You can do this by building up the Message Exchange Pattern, or MEP, for each operation. The MEP contains information about the input and output schemas for the operation, whether the messaging pattern is Request/Reply or Publish/Subscribe, and how the messages will be sent. When you create a dependency, you set up the transport used by the operation, stating how messages will be sent to and from the service.
• Create a test suite: If you create multiple tests, you can create a test suite to represent a group of tests, test suites or scenarios that can be run in series or in parallel.
• Running or scheduling the running of a test: You can initiate the execution of the test or the test suite from the Test Factory. The tests run and can be viewed in the Test Lab perspective.
• View test results: You can view the execution summary and the detailed coverage, and error reports for executed tests in the Results Gallery perspective.