When you open DevTest Workstation for the first time, the Project panel displays a project with the name examples.
Open any of the sample files by double-clicking them. The appropriate editor opens in the right panel.
The actual project files are located in the LISA_HOME\examples directory.
Suite MAR that includes the test suite AllTestsSuite, with all the .tst files and accompanying data files to run the AllTestsSuite. The suite also includes the 1User1Cycle0Think staging document, the DefaultAudit audit document, and the project.config configuration file.
Test-based Monitor MAR that includes the creditCheckValidate test case and the monitorRunBase staging document.
Virtual Service MAR that includes the DatabaseModel virtual service model and virtual service image.
Test-based Monitor MAR that includes the test case webservices-xml-fail, staging document Run1User1Cycle, and project.config.
Test-based Monitor MAR that includes the async-consumer-jms test case, the Run1User1Cycle staging document, and the project.config configuration file.
Test Based Monitor MAR that includes the following items:
Test-based Monitor MAR that includes the webservices-xml test case, Run1User1Cycle staging document, and the project.config configuration file.
Test MAR that includes the rawSoap test case, the 1User0Think_RunContinuously staging document, and the project.config configuration file.
The project.config file contains intelligent defaults for many properties.
Data
The Data directory contains data sets, keystores, and WSDLs that are necessary to run some of the examples for the demo server.
Monitors
Test case that is used for CVS monitor demos. Fails randomly on a specific cid.
Staging document with one user, one cycle, and 100 percent think time, with CAI disabled and no maximum run time.
Staging document with one user, run continuously, 136 percent think time, with CAI enabled and a maximum run time of 15 seconds.
Staging document with one user, one cycle, and 100 percent think time, with CAI disabled and no maximum run time. JMX and JBOSS metrics are selected to record.
Sample skeleton parameter file with Selenium web driver parameters that you can set to customize options for Selenium test cases.
Used for CVS monitor demos. Fails randomly on a specific cid.
This test is used in the monitor setup for CVS demos.
Setup
The Setup directory in the Examples directory contains batch files to start all DevTest components, stop all DevTest components, and load CVS monitors.
To use the scripts with access control (ACL) enabled, add the user name and password options to the Service Manager commands in the script. The password is not automatically encrypted, so be sure to protect the file by using the appropriate method for your operating system.
This staging doc runs a single virtual user with zero think time. This staging document also runs the test or tests "continuously," which does not necessarily mean "forever".
When a test that this staging doc runs meets ALL of the following conditions and runs out of data, the run finishes:
If there are multiple data sets matching these conditions, then the first data set to expire finishes the run. For a good example, review the multi-tier-combo.tst test case.
This staging document runs a test with a single user one time with a 0 percent think time scale.
To test IP spoofing support with your DevTest installation, use this staging document. IP spoofing is enabled in this staging document in the IP Spoofing tab. If you are running the examples server, an IP spoofing test web page is available at http://localhost:8080/ip-spoof-test.
This staging document runs a test with three users, run continuously, with a maximum run time of 440 seconds and 100 percent think time. The document has all four report generator parameter check boxes selected, and specifies all JBOSS JMX metrics to be collected.
This staging document runs a test with a single user one time with 100 percent think time scale.
This staging document runs a test with a single user one time with 100 percent think time scale, with CAI enabled.
This staging document runs a test with a single user one time with 100 percent think time scale. The staging document also selects all four check boxes in the default report generator so more things show in the web base model execution page.
This one-step test case is marked as a subprocess and can be called from any Execute Subprocess step.
The AllTestsSuite runs all the tests in the DevTest Tests directory, using the 1user1cycle staging document and a default audit document of AuditDocs\DefaultAudit.aud. For report metrics, it only records requests and responses, and produces the default metrics. The Run Mode is serial.
The AllTestsSuite runs all the tests in the DevTest Tests directory, using the 1user1cycle0think staging document and a default audit document of AuditDocs\DefaultAudit.aud. For report metrics, it only records requests and responses, and produces the default metrics. The Run Mode is parallel.
A simple JMS test that adds a user with an account to LISA Bank. We expect and assert on patterns in the responses from the two steps.
An example of an "async consumer" queue where the test case continually accepts messages from a response queue/topic. The queue also makes the messages available to the test case in the order in which they arrived.
The first step creates the queue (internal to the test).
The second step fires three messages to a JMS queue on the demo server. The async queue receives the messages.
The third step validates that the async queue received three messages.
A pure EJB test of the LISA Bank functionality. Usually you would test applications by recording a web browser or other UI. Those tests are "end to end" integration tests. These sorts of tests are "lower down the food chain" and require more technical authors (though you still do not need to write any code).
These tests enable the development team to use to test constantly and validate the code without having a user interface, which may not exist or may change so frequently that the tests cannot keep up.
This model thoroughly tests the LISA Bank web services. The model is almost identical in functionality to the ejb3EJB test and useful for the same reasons (see that test case documentation).
This example test case demonstrates IP spoofing support in DevTest.
This test requests the URL "http://localhost:8080/ip-spoof-test" using a REST step, a web page that contains the IP address of the requesting client. The test then makes a SOAP request to the following URL, which identifies a web service containing an operation that returns the IP address of the requesting client:
http://localhost:8080/itko-examples/ip-spoof-test/webservice
The rest case executes both requests in a loop for ten times. You can stage this test with the IP Spoofing Test staging document "ip-spoofing.stg". With the correct network interface configuration, you see different IP addresses being used among virtual users while they make the HTTP and SOAP requests.
This test case is a simple JMS example showing how to send XML/text messages and objects in native Java format.
This test case fetches diagnostic information about the computer running DevTest. The results can help Support solve configuration issues.
This test model uses a comma-separated values (CSV) file as a data set to test a web application. The demo web app that is shipped with DevTest lets us add and remove users from the database.
This example shows how to fail a test by watching a log file for ERROR or WARNING messages.
The example uses a data set to feed the example AntiPattern bean two numbers to divide. Approximately halfway through the data set we give 0 as the operand. This operand causes a divide-by-zero exception to occur on the server. The AntiPattern bean logs the exception and returns -1 as a result.
This example is a common anti-pattern: internal errors occurring but external parties have no idea that the result is incorrect. The result looks believable but it is wrong. The expected result is that the EJB propagates the exception back to the caller.
This test case fails with CAI because the agent records the fact that an exception was logged. Thus, DevTest determines that something is wrong.
An alternative to using CAI is to set up a global assertion to watch the server log file. We define what comprises a regular expression: in this case simply the test "ERROR". The regular expressions can be as simple or as complicated as you want.
Usually you would set the assertion to fail the test immediately. In this case, we advance to the "Error detected in log file" step and end the test normally.
DevTest expects applications under test that log errors or warnings never to pass. Consider using an equivalent companion in your test cases by default.
This test is an example of negative testing. Because we expect test steps to fail, we feed a service data that we expect will cause an error.
The test has a companion, the NegativeTestingCompanion, which fails the test if any steps succeed.
In this case, we try to create users in the demo server that exist. We get this data from the database itself (the username data set queries the table directly). If any step passes, the overall test fails.
The only step that does pass is the "quietly succeed" step. This step lets you mark steps that you expect to pass in this sort of scenario as "quiet" in the editor so the NegativeTestingCompanion excludes them.
This test calls a subprocess to insert a unique user name into the demo server USERS table.
The data set is interesting because it relies on a data sheet to draw values from a unique code generator. The same thing could have been done with a unique code generator with a "counter" data set. This example demonstrates how one data set can influence another.
Data sets are evaluated in the order they are specified. Each time the step is executed, the UniqueUser property is assigned a new value. The data sheet refers to {{UniqueUser}} four times, so we get five unique values.
If any of the steps fail, the test fails immediately.
Compare this test to "main_all_should_fail," which is a similar test where we expect each step to fail and we fail the test if anything passes. This process is known as negative testing.
The multi-tier-combo test uses a variety of service endpoints to validate the LisaBank example. We test SOAP, EJB, JMS, Selenium, and web transactions and validate these transactions in a variety of ways including directly validating the demo server database. This test requires a Firefox browser for the Selenium steps to run.
The multi-tier-combo test uses various service endpoints to validate the LISA Bank example. The test case tests SOAP, EJB, JMS, and web transactions and validates these transactions in several ways including directly validating the demo server database.
The test also demonstrates how you can build complex SOAP objects from spreadsheets. A spreadsheet with the name multi-tier-users.xls in the Data folder of the project backs the User data set on the first step.
If you run this test in the Interactive Test Run (ITR) window, it creates a single user from the first row of the spreadsheet, then the test finishes.
The test restarts until it reaches the end of the data set if you stage it with the example 1User0Think_RunContinuously staging document. This process is the preferred way to iterate repeatedly over a large data set. You could introduce a loop in the test case that is not as flexible.
If you let the staging document control the data set ending the test, then you can spread the test over many virtual users. Or, you can control the pacing of the test with think times and other parameters.
Only global data sets that are set on the FIRST step in the test affect the staging document "end the continuous test run" behavior. If the data set is local to the test or is declared elsewhere in the test, the "run continuously" behavior really does mean "run forever".
The multi-tier-combo-se test uses various service endpoints to validate the LISA Bank example. We test SOAP, EJB, JMS, and web transactions and validate these transactions in various ways including directly validating the demo server database.
The test also demonstrates how you can build complex SOAP objects from spreadsheets. The User data set on the first step is backed by a spreadsheet with the name multi-tier-users.xls in the Data folder of the project.
If you run this test in the Interactive Test Run window (ITR), it creates a single user from the first row of the spreadsheet and then the test finishes.
If you stage the test with the example 1User0Think_RunContinuously staging document, the test will be restarted until the end of the data set is reached. This is the preferred way to repeatedly iterate over a large data set. You could introduce a 'loop' in the test case but it is nowhere near as flexible.
If you let the staging document control the data set ending the test then you can spread the test over many virtual users or control the pacing of the test with think times.
Note that the staging document "end the continuous test run" behavior is only affected by global data sets that are set on the FIRST step in the test. If the data set is local to the test or declared elsewhere in the test, the "run continuously" behavior really does mean "run forever".
The rawSoap step is a one-step test case demonstrating a simple raw SOAP request in the "listUsers" step.
The rest-example test demonstrates how to execute RESTful services. The Demo Server contains a JAX-RS example. Each step in this test shows how to interact with that service using both XML and JSON.
scripting
CA Application Test can take advantage of JSR-223 scripting engines, allowing you to use a large variety of scripting engines in script steps, assertions, data protocol handlers, match scripts and almost anywhere using {{=%language%}} syntax.
Tests the ability of VSEasy to create a JMS service from request/response pairs.
This test is a simple example of service validation. The test calls one web service and one EJB service and inspects the underlying database with SQL to validate that the services function appropriately.
This test is a simple web test that was generated using the web recorder. The test contains some basic assertions such as "assert nonempty response," which is automatically generated. The test also contains some "assert title" assertions that were created by parsing the HTML responses for the <title> tag. These assertions help to ensure that the recorded page is the same when we play back the test.
This test case adds, gets, and deletes a user from the EJB3 web services. The test uses a unique code generator to create a number that has a prefix that is a value {{user}} from the config file. The password is hard-coded in the config file.
This test case tests our ability to send and receive inline base64 encoded data blobs and XOP/MTOM attachments. Filters and assertions on steps verify that the requests and responses look correct.
The ws_security test case shows how to use signed and encrypted SOAP messages. The first two steps succeed and the last two steps fail. The calls are the same, but the web service does not accept messages that are unencrypted or unsigned.
This test model shows how to use signed and encrypted SOAP messages. The first two steps should succeed and the last two steps should fail. (The calls are the same but the web service does not accept messages that are unencrypted or signed.)
This test plan requires that your Java environment supports unlimited strength encryption. If either of the first two steps fail, a likely suspect is that your JCE jars must be updated to enable unlimited strength encryption. The JCE jars can be downloaded from www.oracle.com. Search on the keywords "JCE unlimited strength" and pick the JCE library matching your Java version, such as JCE 7 for Java 7. After you install the JCE jars, your DevTest services must be restarted.
In the audit document, two occurrences of Step Error are expected. We audit for two Step Errors because we expect both of the last two steps here to raise Step Errors. Thus, the audit document can also audit how many occurrences of an event are received. If we add a third Step Error entry to the audit document, the auditor will fail this test because only two Step Error events are raised.
Tests that Fail
This test case adds, gets, and deletes a user from the EJB3 web services. The test uses a unique code generator to create a number that has a prefix that is a value {{user}} from the config file. The password is hard-coded in the config file.
VServices
Images
DatabaseModel.vsi
kioskV4ServiceImage.vsi
kioskV6.vsi
si-kioskV5-dynamic.vsi
si-kioskV5.vsi
WebServicesModel.vsm
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|