Best Of
DTP 2023.2 Product Release Announcement
Parasoft is pleased to announce the release of DTP 2023.2. This update is available at no cost to customers on an active subscription or maintenance contract.
Enhancements:
- Automatic Project Creation
- When a user sends data to DTP for a project that does not exist, DTP will automatically create the project if the user has permissions to create projects.
- Support for Docker and Kubernetes Environments
- Support for environment variables to automate JDBC driver installation and DB schema creation
- Helm Chart for DTP (available on dockerhub)
- Support for deploying DTP as a StatefulSet object
- Advanced Coverage Widgets and Reports
- New widget category for advanced coverage widgets
- Support for displaying coverage suppressions in widgets and drilldown reports
- Shareable URL for drilldown reports
- Violations Explorer
- Ability to export violation data to CSV file
Other Notes:
- Usability improvements to dashboard dropdown boxes (Filter, Period, Baseline and Target Builds)
- Support for integration between Parasoft DTP and Codebeamer 22 has been added.
- Various enhancements made to the syncTestCases functionality for Azure DevOps.
- Ability to configure name and number of violations in Verification Evidence report
- Public API for list and count of DTP Active Users
- Public API for summary of active licenses on the License Server
Deprecated or No Longer Supported:
- Support for Oracle 12c is deprecated and will be removed in a future version.
- Java API for creating custom processors is deprecated and will be removed in a future version.
- Integration with VersionOne is deprecated and will be removed in a future version.
Remote execution for SOAtest Server script
The Parasoft Marketplace now has a bash script for running tests on a remote SOAtest server. Visit the marketplace then look for Remote execution for SOAtest Server script for download link and details.
You can invoke this script directly from a bash prompt or from another bash script. This script can also be invoked from your CI system as a build step to run your functional and integration tests on a SOAtest Server. Use this script in combination with Parasoft Findings to publish the test results into your CI system (Bamboo, Jenkins, TeamCity, VSTS).
The server URL, credentials, and test scope are passed to the script as command line arguments. Test execution progress is printed, indicating whether the job is queued or the percent completed. When the test execution has finished, a test summary is printed and the SOAtest XML/HTML reports are downloaded.
Re: Continuous Integration for Virtual Services
Hello Vkumar,
One of the recommendations is to check-in your assets as a Project folder (not the workspace) that contains all of the artifacts (.pva, .pvadd, .pmpdd, etc) that are associated with the service you virtualized.
I recommend checking out the webinar presented by @Chris Colosimo that goes over some of the best practices to automate the deployment of these artifacts for continuous testing. The webinar can be found here . I have summarized the video for your convenience.
11:40 --> Review of artifacts and their purpose(.pva, .pvadd, .pmpdd, .pjcdd)
14:30 --> Demonstration of artifacts in workspace
20:08 --> Source Control Workflow
27:50 --> Deploying from Source Control & automation workflow
(introduction to Continuous Testing Platform)
This is Omar by the way
Parasoft Virtualize Community Edition - "How to" Webinar pt1 - 3/7/2017
Hi Everyone,
Next week we are going to do a “How to” webinar for Parasoft Virtualize Community Edition.
During this webinar, you will learn how to create and deploy the virtual assets presented during the Community Edition Launch Webinar previously done on 2/14/2017.
· Setup your license and get the latest updates.
· Create a simple mock/stub from an example payload (example: REST/JSON)
· Parameterized asset with a CSV/XLS data source using softlogic
· Control simple performance characteristics of the asset
· Create a virtual asset from traffic (example: SOAP/XML)
· Deploy the asset to a shared server (in Azure)
Please register for Parasoft Virtualize Community Edition - "How to" Webinar on Mar 07, 2017 10:00 AM PST at:
https://attendee.gotowebinar.com/register/5324802153439026690
NOTE: this session will be recorded and reposted here.
Regards
Mark L
Mark Lambert - Vice President of Products
Parasoft – Perfecting Software
Building on One machine to run on another with the same architecture
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.
/usr/local/insure/bin
/usr/local/insure/lib
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
gus_64 islave_64
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.
On AIX
The concerns are if the machines have the same basic oslevel
Type
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 5.1.0.0 and
one that returns 5.2.0.0 you would merely
cd <your base insure directory>
slibclean
./configure aixlibs
on both of those machines and you would end up with directories of
<your base insure directory>/lib.aix5/5.1.0.0
<your base insure directory>/lib.aix5/5.2.0.0
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
compatible.
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/5.2.0.0 ./a.out
On Windows:
First, consider, can you simply install a copy of Insure++
on the target machine and get a runtime license for that
installation?
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
ev.exe
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:
\Insure\bin.Win32
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
C:\Insure\lib.Win32
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\Win32\ins.reg
C:\Insure\lib.Win32\Win32
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\MSVC++-5.0\ins.reg
C:\Insure\lib.Win32\MSVC++-5.0
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\MSVC++-6.0\ins.reg
C:\Insure\lib.Win32\MSVC++-6.0
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\MSVC++-7.0\ins.reg
C:\Insure\lib.Win32\MSVC++-7.0
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\MSVC++-7.1\ins.reg
C:\Insure\lib.Win32\MSVC++-7.1
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*
C:\Insure\lib.Win32
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\Win32\*.tql
C:\Insure\lib.Win32\Win32
copy \\ahost\Program\Files\Parasoft\Insure++\lib.Win32\MSVC++-5.0\*.tql
C:\Insure\lib.Win32\MSVC++-5.0
B. run
insfixreg.exe -install
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).
e.g.
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\lrt-cache
C:\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
existing customers.
Resolving Community License Error
Resolving Community License Error
Description:
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.
Solution:
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 cesupport@parasoft.com so that we may assist you with resolving this.
Re: which version of JSON schema is supported
json-schema draft 4 and draft 5. Some properties from json-schema draft 3 are also understood, ones that were removed or redefined in draft 4, such as the "required" property. json-schema draft 5 is the same as draft 4 except that the draft itself fixes vocabulary, various typos, and bad examples.
The Swagger/OpenAPI schema object model is understood. It is a subset of json-schema draft 4 with some extensions.
json-schema documents from RAML are also understood.
Support for future json-schema drafts and other JSON type models are anticipated.