In this section:
| Table of Contents | ||
|---|---|---|
|
Overview
This section covers change-based testing. Parasoft's change-based testing helps capabilities help you optimize your testing efforts by automatically identifying the test cases directly related to your most recent source code modifications. You can then rerun only the impacted test cases rather than retest the entire system after each modification.
In this section:
| Table of Contents | ||
|---|---|---|
|
Correlating Code via Test Case Execution
Project Center helps you monitor which source code is exercised when a test executes, then correlate that source code with the appropriate task, requirement, or defect.
To do this, you need to:
- Enable reporting to Parasoft Project Center - see Connecting to Project Center.
- Mark which task, requirement, or defect each test is related to - see Indicating Code and Test Correlations.
Correlating Tests
If you are correlating code via test case execution (as described above) no additional configuration is necessary for this.
In addition to enabling change-based testing and requirements-based testing, correlating tests with tasks, requirements, and defects allows Project Center to track the number of project PRs/FRs/tasks that have test cases, track PR/FR/task test case status details (passed, failed).
...
Change-based testing is enabled through:
- testing and code analysis with C/C++test,
- data collection, correlation, and visualization with Parasoft DTP,
- and advanced process intelligence with Parasoft Enterprise Pack–specifically the Change Based Testing extension.
Parasoft DTP identifies the source code exercised during test execution and correlates it with the code coverage image. The Change Based Testing extension calculates change-based testing metrics that can be displayed in DTP. The extension analyzes the test cases associated with each file and if the file has been modified and the test cases associated with that file were not execute, then the test case “Action” is set to “Retest.” Otherwise, the test case “Action” will not be modified. When analysis is completed, the results can be viewed in pie chart format for test summaries (total pass, fail, incomplete, retest statistics), the table report for test summaries per file, and the DTP test explorer. See the documentation for DTP and the Change Based Testing DTP Enterprise Pack extension for additional information.
Requirements
The following components are also required to enable change-based testing:
- DTP 5.3.0 or later (with appropriate license).
- Parasoft Enterprise Pack with the Change Based Testing artifact deployed.
Enabling Code and Test Correlation
To do this, you need to:
- Enable reporting to Parasoft DTP. See Connecting to DTP.
- Associate tasks, requirements, or defects with tests. See Indicating Code and Test Correlations
- Enable code coverage during test execution. See Generating Coverage Information.
If want to use change-based testing as part of your application coverage process that includes manual and API testing, see the SOAtest and Coverage Agent Manager documentation for additional setup and configuration instructions.
Change-based Testing in Concerto or Older Versions of DTP
If you are using a version of DTP older than 5.3.0, see the "Legacy 9.x Functionality for Concerto and Development Testing Platform" guide in the DTP documentation.
...
From Project Center
You can determine where retesting is needed in the following ways:
- To see which manual test scenarios should be retested due to changes in correlated code, choose Tests> Change-Based Testing> Test Scenarios. This opens the Change-Based Testing: Test Scenarios Report.
- To see which requirements/defects should be retested due to changes in correlated code, choose Tests> Change-Based Testing> Requirements/Defects. This opens the Change-Based Testing: Requirements/Defects Report.
...
The Change-Based Testing: Test Scenarios report indicates which manual test scenarios should be retested because there have been changes in the source code that was correlated to the previously-tested functionality. In other words, if a manual test scenario A was correlated to requirement B and the source code related to requirement B has changed, manual test scenario A will be marked as a recommended test.
The Priority column sorts tests by priority. The more changes that are introduced to the specific functionality related to a test, the higher the priority is.
The Relations column shows project artifacts with which the scenario is linked.
The report date period specifies the period for which code changes are considered. You can adjust the date range by clicking the Last 7 | 15 | 30 days Last 12 | 26 | 52 weeks area—or by clicking the Switch to range mode icon then specifying the desired to/from date range.
Clicking the priority cell value will display code details. For example:
The details report presents all the source code revisions that:
- Are associated with specific functionality and
- Were committed to source control after the recent manual test run.
...
This report indicates which requirements or defects should be retested because there have been changes in the source code that was correlated to them. In other words, if code correlated to requirement A has changed, requirement A will be marked as needing retesting.
Clicking the priority cell value will display details about the entity that changed. For example:
The details report presents all the source code revisions that:
- Are associated with specific requirement/defect and
- Were committed to source control in the specified timeframe.