Coverity Aquires Kalistick: The new Coverity Test Advisor - QA Edition includes the Cockpit and Recorder.
Skip to end of metadata
Go to start of metadata
Icon

Coverity Test Advisor - QA Edition is a hybrid local/cloud solution, meaning that some information collected by our client tool, the Recorder, must be submitted to our Cloud platform (the Test Advisor Cockpit server).

We do not submit confidential information from your application to our platform: No source code, no binary code, and no application data

How data is collected by your platform?

The Recorder, which is a tool that you deploy in your infrastructure, generates data files which must be submitted to our platform:

  • Scans (.kss): Generated when you use the Scanner on a new release of your application, which will allow for the detection of changes between all of your releases.
  • Test Footprints (.ksa): Generated when you execute some tests and record their runtime footprint (Test Footprint) using our Agent.

These data files are first stored on your servers, then submitted to our platform.

When data is collected?

Whenever a new release (build) is available for testing, you run a Scan it to identify changes.

During testing, a Test Advisor Agent that is installed on your test server will record your Test Footprints.

How is data submitted to your platform?

You always have control over data transmissions because they are never transmitted automatically by our tools. You are in charge of collecting data files (.kss and .ksa) on the Recorder and uploading them on our platform. You can upload the files manually through the Recorder user interface (a part of the Controller) or in an automated way through the Web API.

Files are always uploaded using a secure communication (HTTPS) to the same entry point: https://cockpit.kalistick.com.

What is stored in the data files?

Scan files

A Scan file is generated when you scan your application. It stores synthesis information about every file of your deployed application. The objective is to identify files, and even lines of code, that have changed between two versions of your application.

The following information is stored in a Scan file:

  • The relative path of all files used by your application runtime.

Example

Icon
./myapp/home.html
./myapp/bin/myapp-server.jar
...
  • The compiled code dictionary (for Java, C# or VB files):
    • Full name of each class, for example: com.mycompany.myproject.MyClass
    • Relative physical path of each class, for example: myapp/classes/com/mycompany/myproject/MyClass.class
    • Signature of each method, for example: String myMethod(String myParam)
    • Locations of method within their class file (for example, starts at line 25 and finishs at line 53)

Example

Icon
class:
  name: com.mycompany.myproject.MyClass
  file: myapp/classes/com/mycompany/myproject/MyClass.class
  methods:
    method:
      name: String myMethod1(String myParam)
      location: 25-53
    method:
      name: void myMethod2()
      location: 10-18
class:
  name: com.mycompany.myproject.MyClass2
  file: myapp/classes/com/mycompany/myproject/MyClass2.class
  • Signature of file contents
    This is the key data used to detect changes between your application versions: A checksum (MD5 or SHA-1) is stored for each application file.

For binary files (images, third-party libraries, and so on), the signature is computed from the entire file contents. For text files and compiled files related to the own code of the application (Java, C# or VB classes), a signature is computed for each line of code.

A signature cannot be reverted; it is impossible to find out the original content. However any change in a line of code will generate a change in the signature. Our platform compares all your application signatures to identify any changes and identify the impact of these changes without any details about the code itself.

Note: A salt can be configured for checksum generation.

Icon

MD5 and SHA-1 are widely used to store a unique identification without storing the source information as this algorithm cannot be reversed. Some common usages: Storing a password signature (instead of the password itself) to authenticate users, adding a signature beside a file to download in order to check if the file is completely valid, and so on. These hash functions are used in most of tools, Web applications, and OS.

Test Footprints

A Test Footprint file is generated when you record your tests using a Test Advisor Agent. They store information about what is executed by each test.

A Test Footprint file stores the following information:

  • General information about all recorded tests: Identifier, name, execution status, issue identifiers (if an issue is created and linked to the test case), date of execution (start/end)
  • URL(s) used during each test to navigate within your application (only for Web applications); for example:
    /webapp/displayreport
  • Method call trees: Signature of all methods executed by each test, with the full execution tree, that is, with all ancestor calls.

Example

Icon
doGet()
|-- executeSomething()
    |-- executeSomethingElse()
    |-- executeSomethingElseAgain()
  • Covered lines: For each test, lines of compiled code (Java, C# or VB) which have been executed and marked as covered for the test.

Example

Icon
tests:
  test1:
    com.mycompany.myproject.MyClass: 1, 3, 10, 11
    com.mycompany.myproject.MyClass2: 21, 22
  test2:
    com.mycompany.myproject.MyClass: 1, 3, 10, 11, 21, 22

Can I audit and control the submitted data?

Data files generated by the Recorder can always be controlled. The Scan file (.kss) is actually a ZIP file that you can open and browse using a standard ZIP tool. The Test Footprint file (.ksa) has a highly optimized binary format based on a proprietary algorithm, but we provide a parser to verify its content.

Where is the hosting and data storage?

We are using Amazon Cloud infrastructure (AWS), the leading Cloud provider within several regions and available around the world. We use best practices from Amazon to protect our servers, using the security infrastructure provided by Amazon, but also additional layers to guarantee the best protection.

Who have access to these data?

All account data is accessible by Coverity employees and contractors, all of whom are under strict confidentiality agreements.

Is there any on-premises option?

Yes, there is. If you cannot use a Cloud infrastructure, you can have your own instance of the Test Advisor Cockpit.

  • No labels