Quantifying Test Impact and Automating Regression with Code‑Case Mapping

Functional Testing Pain Points

After a version is submitted for testing, developers often request a full regression suite while testers know that only a few lines changed. Impact‑range assessment and post‑test coverage evaluation rely on personal experience and lack objective data. Manual regression remains necessary alongside CI automation, leading to high cost and many ineffective tests. Establishing a precise code‑to‑test‑case mapping would enable regression of only the affected test cases.

The current bug‑handling flow (test → ZenTao → developer) is time‑consuming because developers must reproduce bugs from textual descriptions. Directly linking failing code to test cases would speed up feedback and allow developers to annotate coverage gaps.

Overall Solution

Architecture

Forward Tracing (Positive Trace)

The core of forward tracing is to link test cases with the code they exercise, creating a case‑code library . Dynamic call chains are collected by injecting an OpenTelemetry‑based agent into the running application.

Building the Case‑Code Library

Three data‑collection strategies are supported:

Manual execution: a tester runs a test case, each request generates a call‑chain snapshot.

Automated scripts: a script drives multiple requests, each producing a call chain.

Traffic recording & replay: recorded requests are replayed, yielding a call chain per request.

Each snapshot (test case ID, request ID, call‑chain) is stored in Elasticsearch or object storage. New features add entries to the library; existing features are served from the library for automated or manual regression.

Test Case Recommendation

When a new pull request arrives, the system clones and compiles both the target branch and master, computes the Java (and optionally SQL) diff, and walks the stored call chains to find affected entry points. To avoid over‑recommendation, the algorithm matches the branch conditions of the changed code with the branch conditions recorded for each test case. Only test cases whose branch predicates both match and have changed are recommended.

public static void fun(int a) {
  if (a == 0) {
    System.out.println("走了 a=0 的分支");
  } else if (a == 1) {
    System.out.println("走了 a=1 的分支");
  } else {
    System.out.println("走了 非a=0且非a=1 的分支");
  }
}

Reverse Tracing (Negative Trace)

Developers pull a feature branch, perform self‑test, and submit it for QA. The platform extracts the changed Dubbo and REST interfaces, then maps them back to functional test cases.

Implementation Steps

Clone and compile master and the target branch.

Compute Java and SQL diffs.

Use ASM to parse class bytecode, generate static method call chains, and extract annotations for REST ( @RestController, @RequestMapping) and Dubbo ( @DubboService, @Service). The parser supports Apache Dubbo 3.x, Alibaba Dubbo 2.x, and XML‑based configuration.

Query the static call chains with the diff to locate impacted entry points and retrieve the associated test cases.

Platform Interaction

Testers provide the Git repository URL and the target branch. A single button triggers the analysis pipeline and returns the list of affected Dubbo/REST interfaces together with the recommended test cases.

Coverage Collection and Reporting

Jacoco measures line‑level execution but cannot guarantee test effectiveness. In micro‑service environments coverage data must be merged across multiple instances and development stages. Native Jacoco cannot merge coverage from different code versions, so the platform performs incremental coverage.

Incremental Coverage Process

Clone and compile master and the test branch.

During CI/CD each instance dumps its Jacoco .exec file.

Merge all instance files into a unified exec file.

Use the code diff to generate an incremental coverage report that highlights newly covered or uncovered lines.

Report Optimization

Remove rarely used metrics such as cyclomatic complexity (Cxty) and instruction count.

Rename “miss%” to “covered%” and display the value in Chinese for readability.

Visualize coverage with a 3‑D donut chart.

Summary and Future Plans

The current implementation solves “what to test” via reverse tracing (impact analysis) and “how well we test” via incremental coverage. Future work includes:

Refining forward tracing to improve recommendation precision and reduce redundancy.

Embedding the tracing and coverage pipelines directly into the CI/CD workflow so developers receive automatic, data‑driven test recommendations without manual steps.

Enhancing reports with source‑code annotations that highlight newly added or modified lines and supporting collaborative comments between developers and testers.