Application Under Test (AUT)
The part of the system that you are responsible for developing or testing. This is sometimes referred to as the system under test or an in-scope system. You and your team have direct control over (and immediate access to) the AUT.
Data groups are a special type of data source. With data groups, you can group similar sets of data (such as development environment test data and load/performance test data), then easily switch which data set is used at any given time—without having to edit the tool configurations or data sources. To use data groups, you group together data sources with common columns. You can then specify "on the fly" which data source should be applied to the virtual asset at the given time. Data groups are configured in Virtualize desktop.
A data source is any set of data you want to use to populate response messages or other tool values. Data sources can include CSV, Excel, relational databases, files on disk, in-project spreadsheets, and Parasoft’s data repository.
An existing application or component within a development, test, or production environment that the AUT needs to access in order for you to complete your development or testing tasks. This is sometimes referred to as an out-of-scope system. Dependent components might include mainframes, third-party applications or services, databases, etc.
These components might be difficult to access for development and testing purposes. Or, they might be difficult to configure for your test scenarios. When you need faster, more flexible access to behavior associated with these components (including data and performance profiles), you can "virtualize" this behavior with a Parasoft Virtualize "virtual asset."
Parasoft Data Repository helps teams define, extend, and review large and/or hierarchical data sets for use in Parasoft messaging tools. Once a repository is established on a data repository server, it can be populated from existing data sources and/or updated manually. Through the graphical representation of hierarchical data, you can review and extend the repository structure and contents. Records from one data set can be referenced in other data sets to simplify editing and management of large data sets with a high level of data reuse.
Provides insight into Virtualize Server events (request messages received, response messages sent, errors, and so forth). This helps you monitor the behavior of the AUT and diagnose unexpected behavior as it occurs and better understand long-running transactions.
Operates as a man-in-the-middle between an AUT and a dependent component. The proxy can record traffic that passes through it so that the corresponding behavior can be virtualized. It can also be used to control whether traffic is routed to a virtual asset or to the actual component. Once the AUT is configured to communicate with the proxy, you do not need to reconfigure the AUT in order to enable/disable recording, reroute traffic to the virtual asset or actual asset, etc.—you can achieve this by simply modifying the proxy configuration.
Parasoft JDBC Driver
Similar to a message proxy, but designed to operate on database queries and results. Once the Parasoft JDBC Driver is configured and the AUT is set up to communicate with it, you can use the JDBC Controller (in the Virtualize Server view) or Parasoft Environment Manager to switch modes (passthrough, record, virtualize, etc.)—without having to restart the application server.
Performance profiles give development, QA, or performance engineers the flexibility to rapidly configure dependent system performance characteristics. This enables an array of performance testing scenarios to be executed one after another. The performance of each virtual asset can be set to reflect the dependent application’s actual performance or to emulate specific performance models that you want to test against. Performance profiles are configured in Virtualize desktop.
Provisioning actions can be used to automate configurations that are commonly applied in your environments. For example, you might run a script for changing certain environment settings, then update a settings file via FTP. Or, you might initialize a live database for testing. Provisioning actions are defined in Provisioning Action (.pvn) files, which contain action suites. The structure and management of .pvn files and action suites is similar to that of .pva files and responder suites (respectively); each project can contain multiple .pvn/.pva files, each of those can contain any number of action suites or responder suites, data sources can be added and used to parameterize tools, tools can be added as outputs, and so on.
A .pva file can contain one or more nested responder suites. A .pva that is deployed on a Virtualize Server is considered a virtual asset.
Responders are tools that specify which response should be sent for a given incoming request. Each responder responds to incoming request messages that match its correlation criteria. Responses can be configured in a variety of modes, ranging from simple fixed messages to dynamic parameterized messages using a data source. Multiple responders can be configured, each with its own correlation strategy, data set, and message structure. Message Responders are protocol agnostic; the transport protocol or API to access a responder is defined in the deployment configuration of the associated virtual asset.
Responder suites are used to group and organize responders, variables applicable to multiple responders, data sources, performance profiles, and other assets within a .pva file.
Virtual assets simulate the behavior, performance, and data of dependent components.They can be used for manual or automated testing with any testing platform. Virtual assets for existing components can be created from live recording, definition files, or log files. In addition, virtual assets can be modeled from sample messages or designed from scratch.
Virtual Asset Deployment / Deployed Virtual Asset
A .pva that is deployed on a Virtualize server is considered a virtual asset deployment. A single .pva may be associated with multiple virtual asset deployments—each with different performance profiles or data group settings.