the same architecture
First the concerns for all Unix based platforms
The bin and lib directories have to have been created
on the run machine in the same directory tree as on the build
machine. So if you were running on a Solaris machine and on
your build machine you have created /usr/local/insure in this
location you should have both of these on your run machine.
In your bin directory the following binaries have to
have been copied from your build machine.
gus insra islave pslic psrcdump
On 64 bit architectures you will also need
Then in your base directory /usr/local/insure in this example.
You will need to make sure that you have a .psrc file with
a runtime license or entries telling it where Licenseserver
is running as well as the various options you want set.
Some platform specific concerns:
On Linux Solaris HP
copy all of Insure's libraries from the lib directory on
the build machine to the lib directory you created on
the run machine.
For Linux or Solaris set the environment variable
LD_LIBRARY_PATH to include the lib directory
For HP set the environment variable SHLIB_PATH to
include the lib directory.
The concerns are if the machines have the same basic oslevel
on both machines to determine if the same thing is returned.
And if they are the same oslevel do they have different libc's
and/or libpthread libraries. Insure creates it's libraries
below what amounts to
<your base insure directory>/lib.aix5/`oslevel`
And if you have one machine that oslevel returns 188.8.131.52 and
one that returns 184.108.40.206 you would merely
cd <your base insure directory>
on both of those machines and you would end up with directories of
<your base insure directory>/lib.aix5/220.127.116.11
<your base insure directory>/lib.aix5/18.104.22.168
and this present's no problem as it only requires that we build
with the correct -blibpath set.
But if machine A and machine B both return the same value
for oslevel and have different libraries installed then the
replacement libraries that insure has to create will not be
However you could workaround this by first configuring
for an individual Developer then
cd <your base insure directory>
cp -R lib.aix5 Developer.lib.aix5
Then Developer would need to set his LIBPATH for anything
that he built with insure like
env LIBPATH=<your base insure directory>/Developer.lib:<your base insure directory>/Developer.lib5/22.214.171.124 ./a.out
First, consider, can you simply install a copy of Insure++
on the target machine and get a runtime license for that
That is by far the easiest approach.
If Visual Studio is not on the target machine, the easiest
way to get Insure++ to successfully install on the target is
to have it first invoke msdev through a network share. e.g. run
\\ahost\shared-C\Program\ Files\Microsoft\ Visual\ Studio\Common\msdev98\bin\msd
and then close DevStudio.
If the network share is still available when Insure++ is
installed, the installation should proceed normally, even
though DevStudio is not technically installed on the target.
If for some reason the above is not acceptable and the two
machines have the same exact OS, proceed with the following steps:
1. Copy the instrumented executables and the pdbs from host to target.
e.g. copy \\ahost\myprogram.exe C:\myprogram.exe ;
copy \\ahost\myprogram.pdb C:\myprogram.pdb
2. Copy required executables from host to target
(note that the directory must be named bin.Win32).:
insure.dll, vahfer.dll InsureSpy.exe gus.exe mspdb60.dll
msdia20.dll or msdia71.dll if using vc7 compiled executables,
insfixreg.exe InsurePanel.exe InsureVc7Addin.dll insure.exe
(insfixreg.exe checks for the existence of InsureVc7AddIn.dll
insure.exe, and InsureSpy).
e.g. copy \\ahost\Program\ Files\Parasoft\Insure++\bin.Win32\Inject.exe C:
3. You will probably also want to copy optional executables from
host to target:
islave.exe psrcdump.exe Insra.exe TCA.exe Inuse.exe inject.exe
4. Copy the ins.reg files from the host to the target.
Note that these must be located in a directory called lib.Win32
that is a sibling directory to the Insure_bin directory.
e.g. copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\ins.reg
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\Win32\ins.reg
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\MSVC++-5.0\ins.reg
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\MSVC++-6.0\ins.reg
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\MSVC++-7.0\ins.reg
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\MSVC++-7.1\ins.reg
5. When the target machine has any version of Visual Studio installed:
A. Copy the necessary libtql* and tql files from the host.
e.g. copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\libtql*
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\Win32\*.tql
from the command line.
This will create the lrt cache.
6. When the target machine does not have any Visual Studio installed.
A. run insfixreg -nospy -nointegration on the target machine.
B. Copy the contents of the lrt-cache on the host to the target
(note1 that target OS must be the same as the host OS)
(note2- the lrt-cache must be located inside the lib.Win32 directory on the target).
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\lrt-cache
7. Optionally set gus-cache in the advanced tab of the InsurePanel.exe
e.g. gus_cache C:\gus-cache
8. Run the executable under inject.exe or InsureSpy.exe.
If the target windows OS is different than the host windows OS we may
be able to create the lrt-cache for you but this would only be done for
Resolving Community License Error
When activating your Community License for the first time, you may run into the following:
Community License is not currently available. Please try again later and contact Parasoft if you are still unable to access Community License.
This error can occur when the license connection is blocked by a firewall or there is a corporate proxy in place.
1) Check for updates. It is likely that any licensing issues have already been resolved with the latest updates made to Community Edition.
2) Ping “www1.parasoft.com”. An unsuccessful ping test indicates that there may be a firewall blocking this connection. If so, you should consult with your IT department to allow network access for your Community Edition.
3) Check your IE browser settings to verify if your machine is using a Proxy:
- Open IE
- Click the Tools button
- Click on Internet Options
- Click on the Connections Tab
- Click on LAN settings
If so, try adding these same settings within your CE instance in Parasoft>Preferences>Proxy.
Enable “Automatic Configuration script” or “Proxy Settings” depending on your current configurations.
After applying the appropriate settings, click Okay. Reopen your Parasoft Preferences and re-apply your License.
If the behavior persists, disable the initial proxy setting, “Automatic Configuration script”, and enable the secondary option, “Same Proxy Server for all Protocols”.
After applying the appropriate settings, click Okay. Reopen your Parasoft Preferences and re-apply your license.
If none of these steps resolve your license error or you continue to experience any unexpected behavior, please don’t hesitate to contact our Support team at email@example.com so that we may assist you with resolving this.
I am making this forum post to help out new users install Virtualize Community Edition on Windows, Linux, or Mac.
Windows (UI installation):
After downloading the installer linked from the initial email, execute the exe by double-clicking on the .exe file.
Click run on the popup that appears.
Choose your language for installation.
Click Next, then read through the End User License Agreement, then accept the agreement.
Select your installation directory, the default being
C:\Program Files\Parasfot\SOAtest & Virtualize\9.10
Choose Full installation. When only using Community Edition, the pydev option is not necessary.
Setup the location for the program's shortcuts, defaulted to
Parasoft\SOATest & Virtualize\9.10
If you wish, install the Root CA for https functional tests.
Note: This is only necessary for SOAtest functionality, not for Virtualize Community Edition.
If you wish, install a Desktop icon or quick launch icon.
Click install. Once the installation is finished, click Finish.
Mac/Linux (Terminal installation):
Open up your terminal and navigate into the Downloads folder.
Unpackage the download with
tar zxvf parasoft_soavirt_9.10.1_linux_x86_64.tar.gz
Run the installer with
Choose your installation language.
Enter in an installation location. The recommended installation location is
After the installation finishes, read through the additional information for starting up Virtualize from the command line. Once you have finished, press Enter.
Hope this helps!
- Recording and playback: Testing scenarios are created using recording and playback; the user just needs to record the actions they wish to test in the browser and SOAtest will create the XPaths necessary to identify elements used during the test.
- Modify tests from the rendered view: If an XPath used to identify an element becomes invalid for any reason (for example, the element moves or the text for the element changes), users can right-click the updated element in the rendered view and choose "Modify action to use <element>." No direct access to the XPaths is necessary.
- Add validations from the rendered view: To verify that an element is present during a step in the test, the user may right-click the element in the "Browser Contents" rendered view, choose "Extract value from element" and follow the wizard to create the validation. The XPath is generated automatically.
- Renaming actions: Users can double-click any action in a scenario, un-check "User default name" and enter a more appropriate description of the action taking place.
- Renaming test suites: Users can double-click any test suite in a scenario and change their name in the "Name" field to describe the steps contained in the test suite. Users can also add notes describing the test suite.
- Customizing validations: All validations in SOAtest can be renamed and their error messages adjusted to describe what they validate. Double-click any browser validation tool, select the validation and adjust the Description and Validation Message accordingly.
- Reference tests: Users can record and customize a sequence of common actions (such as logging in), save the test in one location, and re-use the test as part of any new test. Making changes to the original test updates all other tests that reference the test. An original designer can create tests with high-level functions (logging in, logging out, searching for a term, etc), and new testers can use references to these tests without needing to understand the details of how they function.
- Create actions and copy-paste: If necessary, an original designer can create tests that execute a single action (for example, click on the "Status" header), give the action a descriptive name (as explained above). The original designer could create a library of these single actions which new testers can copy and paste together into a sequence of actions without needing to know the XPaths used to generate the actions.