Billy McMullin admin

About

Username
Billy McMullin
Joined
Visits
276
Last Active
Roles
Admin, Staff
Points
46
Posts
41
Badges
5
  • Running Maven with SOAtest

    Parasoft offers a Maven integration plugin that will allow you to execute SOAtest analysis on project with Maven. Please follow the steps below if you would like to have SOAtest execute during your Maven process:

    1. Before you can use the Parasoft Test Maven plugin, you need to add the "http://build.parasoft.com/maven" repository to your POM or repository manager. For instance:

      <project> ... <pluginRepositories> <pluginRepository> <id>Parasoft</id> <url>http://build.parasoft.com/maven</url> </pluginRepository> </pluginRepositories> ... </project>

    2. Once added, you can choose do one of the following to execute Parasoft with:

    Extend the POM, Configure the plugin through the command line, or configure a Profile Switch.

    Extending the POM
    1). If you extend the POM, the specified goals will always be run at a particular phase of the build lifecycle. This allows you to specify your configuration once, and have it used every time that Maven builds the configured project. First, specify the plugin version. For example:

     <project>
        ...
        <build>
        <!-- To define the plugin version in your parent POM -->
            <pluginManagement>
                <plugins>
                    <plugin>
                        <groupId>Parasoft</groupId>
                        <artifactId>maven-parasoft-plugin</artifactId>
                        <version>3.0</version>
                    </plugin>
                    ...
                </plugins>
            </pluginManagement>
            <!-- To use the plugin goals in your POM or parent POM -->
            <plugins>
                <plugin>
                    <groupId>Parasoft</groupId>
                    <artifactId>maven-parasoft-plugin</artifactId>
                    <version>3.0</version>
                </plugin>
                ...
            </plugins>
        </build>
        ...
    </project>
    

    2). Next, specify goals and configuration parameters. For example:

    <project>
        ...
        <build>
            <plugins>
                <plugin>
                    <groupId>Parasoft</groupId>
                    <artifactId>maven-parasoft-plugin</artifactId>
                    <executions>
                        <execution>
                            <id>soatest-test</id>
                            <phase>test</phase>
                            <goals>
                                <goal>soatest</goal>
                            </goals>
                            <configuration>
                                <clean>false</clean>
                                <config>soatest.builtin://Demo Configuration</config>
                            </configuration>
                        </execution>
                    </executions>
                </plugin>
            </plugins>
        </build>
        ... 
    </project>
    

    3). Once added to your POM, you can execute the project with the following command line:

    mvn clean test -Dparasoft.soatest.home="PATH TO SOATEST INSTALL" -Dparasoft.localsettings="PATH TO LOCALSETTINGS FILE"

    Configure from the Command line
    1). The most direct way to execute the plugin is to configure the plugin execution details completely from the command line. For example:

    Parasoft:maven-parasoft-plugin:soatest -Dparasoft.config="builtin://Demo Configuration" -Dparasoft.soatest.home="PATH TO SOATEST INSTALL" -Dparasoft.localsettings="PATH TO LOCALSETTINGS FILE"

    Configuring a Profile Switch
    1). You can add a Profile Switch to the POM so you can run the appropriate switch when you want to apply one of the Parasoft goals. You can configure any number of switches with different goals and parameters. This approach is useful when you want to set plugin execution details in the POM but don't want it permanently attached to a lifecycle phase. You can create a profile switch like the following:
    <project> ... <profiles> <profile> <id>soatest</id> <build> <plugins> <plugin> <groupId>Parasoft</groupId> <artifactId>maven-parasoft-plugin</artifactId> <configuration> <config>soatest.builtin://Demo Configuration</config> </configuration> <executions> <execution> <phase>test</phase> <goals> <goal>soatest</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </profile> </profiles> ... </project>

    2). You can then use "mvn clean install -Psoatest" and this will run the soatest profile.

    NOTE:
    In order to execute SOAtest, you need to have a ".project" file that works in the server environment.

    You can find an example POM.xml using the Extended POM method attached to this post.

  • Unrecognized command line option "-m32"

    This message occurs because C/C++test will implicitly change the compilation line to add the "-m32" compiler option for some compilers. This is generally not an issue, however sometimes the user is using a compiler that does not support this "-m32" option (This usually means that an "unsupported" compiler is being used. "Unsupported" means it is not one of the compilers we test our product with and is not listed in our product's documentation). In this case, we need to create a C/C++test custom compiler configuration which does not add the "-m32" option.

    More information about the custom compiler configurations can be found in the C/C++test User Guide, under the section Parasoft C++test User's Guide > Cross-Platform and Embedded Testing > Configuring Testing with the Cross Compiler. The C/C++test User Guide can be opened through C/C++test from the Help > Help Contents menu.

    Resolution

    • Open up your project properties. Right-click on your project and select Properties > Parasoft > C++test > Build Settings
    • Make sure you have selected the correct Compiler settings Family from the drop-down. Make sure the C compiler, C++ compiler, and Linker executables are correct as well.

    • If you have made any changes to this page, save the changes with the OK button, and rerun the test (Static Analysis or Unit Testing). If you still receive the same error of Unrecognized command line option "-m32", continue with the next steps

    • In C/C++test, select File> New> Other. Then choose C++test> Custom compiler. Then click Next. The New Custom Compiler dialog will open.

    • Select Add custom compiler, then click Next.

    • In the next page, specify the following custom compiler settings:
    • Compiler name: The unique name that will be used to identify this custom compiler in the C++test GUI.
    • Compiler family: The family of compilers which corresponds to your actual compiler (if you are not sure, choose one of the GCC compilers).
    • Compiler identifier: The unique name that will be used to identify the directory in which its configuration settings are stored. This name should conform to all limitations that your OS file system imposes on directory names
    • C compiler executable: The C compiler executable.
    • C++ compiler executable: The C++ compiler executable.
    • Linker executable: The linker executable. The compiler and linker settings must be consistent.
    • When you are done, click Next.

    • Copy the location of the path of the C compiler definition file, then click Finish.

    • Navigate to the path you copied from the previous step.
    • Open each file in this directory in a text editor (files: c.psrc, cpp.psrc, and gui.properties), then remove all instances of "-m32" from each file and save the changes. There are multiple instance of "-m32" in each file, so take care to remove all "-m32" strings.
    • ex. if a file contains the line

    edgtk.preprocessorCommand {exe} {opts} -ftabstop=1 -E -xc++ -m32 {in} -o {out}

    it should be changed to become

    edgtk.preprocessorCommand {exe} {opts} -ftabstop=1 -E -xc++ {in} -o {out}

    • In C/C++test, go back to the project properties build settings (see Steps 1 and 2), and change the Compiler setting Family drop-down to your new compiler configuration. Double-check that all the compiler settings are correct. Save the changes by clicking OK.

    • Rerun the test, and you should no longer see the error message. If you do, restart C/C++test and run the analysis again.

  • How to change the severity of a static analysis rule

    Changing the severity of a static analysis rule:

    1. Open the Test Configuration window from Parasoft > Test Configurations
    2. Select any Test Configurations in the right-hand pane, and go to the Static > Rule Tree tab. Find the id of the rule you want to edit. The id is at the end of the string in the square brackets -- the last number in the name represents the current severity of the rule and is not part of the id. (ex CDD-001)
    3. Select the Edit Rulemap button.

    4. In the Edit Rulemap File window, create a new row with the New button. Add the rule id to the Original Id column, and use the drop-down under the Severity column to pick the new severity.

    5. When you are done, save your changes and go back to the Test Configuration window. Notice that the severity of the rule has now changed.

    Important

    Please note that this change will affect ALL the test configurations in this workspace. This means all your Static Analysis rule-set will be subject to the rule's new severity. Because of this fact, the recommended workflow suggests that only the team lead/project architect makes the final decision on the rule severities and shares this decision with the rest of the team via the Team Server. Please see the Solution for sharing rule mappings for more details. This will work on C/C++test and Jtest as well.

  • C/C++test Data Flow Analysis Performance Debugging Log

    To get information about how long it takes to process each file and how long it takes to do each of the Data Flow (Bug Detective) analysis phase, set up the following flags in the Parasoft > Preferences > Technical Support > Advanced options (make sure Advanced options are enabled):
    CPPTEST_TIME_STATISTICS_PER_FILE=true
    CPPTEST_TIME_STATISTICS_PER_PHASE=true

    Results will be displayed on the C++test console after the analysis finishes.

    To achieve that in the CLI run, set up the following options in the localsettings properties file:

    techsupport.advanced=true
    techsupport.advanced.options=CPPTEST_TIME_STATISTICS_PER_FILE\=true
    CPPTEST_TIME_STATISTICS_PER_PHASE\=true

    and make sure you use "-appconsole stdout|" option specified in the cpptestcli command line.

    With these options we will know which phase takes the most time (collecting data building graphs / running rules) and whether there are some files that we take most of the time (you could consider disabling testing of such files in the first place).

    To get detailed profiling information about the BD analysis (including time spent processing each of the rules), enable verbose logging in GUI (Parasoft > Preferences > Technical Support > Enable verbose logging) or in the CLI with the following localsettings properties option:

    techsupport.verbose=true

    and use the following flags in the cpptestcli command line:

    -J-DFA_DEV=true -J-DFA_DEV_LOG_DIR="PATH_TO_A_DIR_TO_STORE_PROFILING_INFO_IN"

    Specified directory will be filled with data after the analysis finishes. It will contain e.g. profiler.dat file, where you can find detailed profiler information. To find information about the rules, look for lines line this:

    : complete|.......

    E.g.:

    BD-TRS-LOCK: complete|196|0.488|0.0|0.487|0.002

    means that rule BD-TRS-LOCK was invoked 196 times with the total time: 0.488sec, min time: 0.0sec, max time: 0.487sec, avg time: 0.002sec