This guide describes how to deploy complete test environments to Microsoft Azure using the Parasoft service virtualization assets available in the Azure marketplace.
In this guide:
Parasoft enables you to instantly provision dynamic test environments from a golden template in Microsoft Azure. The test environments deployed to the cloud are disposable, so you can readily destroy them after exercising a your test scenarios. There is no need to share test environments or resources across teams or test phases: the exact environment you need is instantly spun up whenever you want it, then destroyed as soon as you're done with it. Dynamic infrastructures provide advanced flexibility for extreme automation. When you need to scale the environment for performance testing or other use cases, you can do so on demand.
Parasoft offers two licensing options:
The following Parasoft artifacts enable you to deploy a Parasoft Service Virtualization VM on Azure and are available from the Azure Marketplace.
Parasoft Virtualize Server hosts virtual assets and proxies, which drive Parasoft's service virtualization solution. Virtual assets deployed to the Virtualize server can respond to requests from the application under test. Proxies allow you to dynamically control the configuration of the application environment, such as whether requests from the application under test are being forwarded to a virtual service or real endpoint, without making changes to the application under test.
CTP is a browser-based interface that enables you to leverage functionality in the Parasoft Virtualize Server. CTP for Azure includes the following modules:
The Environment Manager module enables team members to build, select, and provision environments. An environment contains representations of the AUT's dependent components set to specific states. For example, an environment may contain a virtual API that simulates network congestion and error responses, a real database, and a virtual mainframe that returns positive responses.
The Service Virtualization module is an interface for creating, configuring, and deploying virtual assets to the Virtualize server. Virtual assets send specific responses to requests that meet a set of correlation criteria.
The Data Repository Server captures and stores data associated with requests and responses when a virtual asset is created from traffic. When the virtual asset is invoked, it will pull data from the data repository server to construct a response.
Azure DevOps (formerly Visual Studio Team Services) allows you to create projects, manage code, and set up a continuous build and release process. Plugins expand Azure DevOps functionality by integrating with third-party platforms, including Parasoft Service Virtualization.
Installing the Parasoft Continuous Testing Extension for Azure DevOps makes several Parasoft tasks available to add to your pipelines. The Parasoft Deploy Environment task creates a simulated test environment so that the correct data, endpoints, and functionality are always available during a build/release process. The Parasoft Destroy Environment task instantly cleans up the simulated test environment once the build/release process has completed. Both of these steps are available as release tasks in Azure DevOps.
Other tasks include the Execute Job task for running test jobs hosted on the Virtualize server, as well as the Disconnect task for ending the pipeline session with Parasoft CTP. Refer to the Continuous Testing Extension for Azure DevOps documentation for details about configuring and using the tasks included with the extension.
Refer to the Using Parasoft in Azure DevOps section for details on how to configure Azure DevOps to grab the source code for a demo web application ("Parabank") from the Parabank GitHub repository, build the code on a hosted build machine, and release the resulting .war file to a dedicated Azure VM. It also demonstrates how to use the Parasoft "Deploy" task to provision a simulated test environment needed to test the Parabank application.
In this section, we'll create a complete continuous delivery pipeline for Parasoft's demo application, Parabank.
Before we create a project in Azure DevOps, we need to deploy an Azure virtual machine. The machine will serve as the host for CTP and the Parabank demo application. We'll define virtual environments in CTP and deploy them as part of the release process in Azure DevOps.
Once created, click on the VM to view its details page. Click the on the VM and note the IP address.
Open the IP address in a browser to access CTP. You will be prompted to provide an email address the first time you open the application.
When the system is imported, it will be represented as a diagram in the EM workspace.
A .war file will be produced as a result of the build process.
The next step is to release the artifact by deploying it onto a Tomcat server hosted on the Azure machine we created in the Creating a Virtual Machine in Azure section.
Before releasing, we need to install the Apache Tomcat Deployment and Installing Tomcat and Service Virtualization plug-ins.
The Apache Tomcat Deployment artifact has requirements that require additional configuration on the VM.
In this guide, we will use SSH to connect to the server. You can also click Connect on the VM home page in Azure and click the RDP tab to access a remote desktop configuration.
Open a command prompt and connect to the VM:
ssh <VM_USER_ID>@<VM_IP> |
Navigate to the /usr/local/tomcat/webapps/manager/META-INF directory
cd /usr/local/tomcat/webapps/manager/META-INF |
You may not have permissions to the subdirectories under tomcat and may need to add read, write, execute access. You can change the permissions as you move through each subdirectory or recursively change the permissions.
sudo chmod -R 777 webapps |
Edit the context.xml file with a command line editor.
Vim context.xml |
Comment out the following element to enable remote access to the manager application:
<Context antiResourceLocking="false" privileged="true" > <!-- <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" /> - -> </Context> |
You will also need to enable the user and role for scripting access to the manager application.
Navigate to the /usr/local/tomcat/conf directory. You may need to change the permissions to enable access to the applicable subdirectories.
Edit the tomcat-users.xml file with a command line editor
Vim tomcat-users.xml |
Add the following user and role configuration to the <tomcat-users> element:
<role rolename="manager-script"/> <role rolename="manager-gui"/> <user username="tomcat" password="tomcat" roles="manager-script,manager-gui"/> |
The username and password must both be "tomcat"
.
em
path segment is required.
Once the release has completed and is successful (this may take a few minutes), navigate to http://<VM_IP_ADDRESS>/parabank in your browser. The Parabank application should load
.
Now that we've provisioned our virtual environment, we must reconfigure the Parabank application to use our proxies, which are endpoints that sit between Parabank and the virtual services it will consume. Proxies can redirect traffic between the AUT and virtual components, including web services, databases, mainframes, and other endpoints. The proxies we configure in this section will redirect Parabank's requests to our virtual services.
Verify that ParaBank is using the proxies:
The following message indicates that we've successfully configured the correct environment during our release and we have received a response from the virtual environment instance we provisioned.
The Golden ParaBank environment includes several environment instances.
In this guide, we've executed the Deploy Parasoft task during separate release executions. This made it possible for the user to manually go into Parabank and witness the change in behavior after we deployed a certain virtual environment.
In a real use case, it's likely that a Deploy task would be utilized to create an appropriate environment for an automated test to execute. We'd then execute a Destroy task during the same workflow in order to "clean-up" the service virtualization engine after test execution. It's possible that we may iteratively provision and destroy several virtual environments in a release as we execute different categories of tests.
In this section, we'll go through the process of creating a simple virtual service (also called a PVA or Parasoft Virtual Asset) from a sample response using Parasoft and Microsoft Azure. We'll then consume the virtual response through the Parabank demo application.
If you have not already done so, follow the instructions in the Creating a Virtual Machine in Azure chapter to create the virtual machine on Azure before proceeding.
Copy and paste the following SOAP response into the input field.
<?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:requestLoanResponse xmlns:ns2="http://service.parabank.parasoft.com/"> <ns2:loanResponse> <responseDate>2019-01-01T12:33:47.076-07:00</responseDate> <loanProviderName>Wealth Securities Dynamic Loans (WSDL)</loanProviderName> <approved>false</approved> <message>error.insufficient.funds.for.down.payment</message> </ns2:loanResponse> </ns2:requestLoanResponse> </soap:Body> </soap:Envelope> |
We built ParaBank with an administration page to more easily facilitate demonstrations. In a real-world scenario, you may need to edit one or more configuration files associated with your application under test.
For additional details about building virtual assets, see the "Service Virtualization" section in the CTP user guide. The online documentation, as well as API reference, is available from help menu .