Interpreting Coverage Information Using Direct and Indirect Coverage

Huo, Chen; Clause, James

doi:10.1109/icst.2016.20

Cited by 7 publications

(6 citation statements)

References 37 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The first of these is restricted flexibility in customizing the analysis. One example is the inability to define new metrics like indirect coverage [30] within JaCoCo. Secondly, the expressiveness of the analysis can be limited.…”

Section: B Limitationsmentioning

confidence: 99%

“…2) Indirect Coverage: Indirect coverage is a metric introby [30], which is often overlooked in conventional coverage analysis. A covered entity 𝑒 (e.g.…”

Section: E Coverage: Versatile Metricsmentioning

confidence: 99%

“…statement, branch, function) is said to be directly covered if there exists a test that directly invokes the method 𝑚 that contains 𝑒; otherwise 𝑒 is said to be indirectly covered. To the best of our knowledge, no existing tool can compute indirect coverage of a test suite (the authors of [30] provide none). Reusing the same instrumentation specification from Section IV-E1, we implemented a pipeline that perform this task; the analysis yields a comprehensive report, outlining both direct and indirect coverage of basic blocks and instructions for every executed method.…”

Section: E Coverage: Versatile Metricsmentioning

confidence: 99%

See 2 more Smart Citations

Dynamic Program Analysis with Flexible Instrumentation and Complex Event Processing

Soueidi,

Falcone,

Hallé

2023

2023 IEEE 34th International Symposium on Software Reliability Engineering (ISSRE)

View full text Add to dashboard Cite

This paper presents a flexible and modular approach to dynamic program analysis for JVM-based languages, aiming to address the limitations of existing tools, in particular their limited expressivity and tight coupling between instrumentation and analysis. The proposed solution decouples these two processes using BISM, a lightweight instrumentation language, and BeepBeep, a complex event processing engine. This novel combination enhances expressiveness, promotes reusability, and integrates seamlessly into JVM-based projects. Various analyses such as monitoring, profiling, coverage measurement, and complex event generation are demonstrated, showcasing the approach's flexibility.

show abstract

Section: B Limitationsmentioning

confidence: 99%

“…2) Indirect Coverage: Indirect coverage is a metric introby [30], which is often overlooked in conventional coverage analysis. A covered entity 𝑒 (e.g.…”

Section: E Coverage: Versatile Metricsmentioning

confidence: 99%

Section: E Coverage: Versatile Metricsmentioning

confidence: 99%

See 1 more Smart Citation

Dynamic Program Analysis with Flexible Instrumentation and Complex Event Processing

Soueidi,

Falcone,

Hallé

2023

2023 IEEE 34th International Symposium on Software Reliability Engineering (ISSRE)

View full text Add to dashboard Cite

show abstract

“…Since 100% coverage is often infeasible, several new approaches have been proposed for interpreting coverage information. For instance, Huo et al [41] introduced the concepts of direct coverage and indirect coverage, that address these limitations. In addition, several other challenges are present in general software testing [42], like coherent testing, test oracles and compositional testing.…”

Section: Related Workmentioning

confidence: 99%

Large Scale Evaluation of Natural Language Processing Based Test-to-Code Traceability Approaches

2021

View full text Add to dashboard Cite

Traceability information can be crucial for software maintenance, testing, automatic program repair, and various other software engineering tasks. Customarily, a vast amount of test code is created for systems to maintain and improve software quality. Today's test systems may contain tens of thousands of tests. Finding the parts of code tested by each test case is usually a difficult and timeconsuming task without the help of the authors of the tests or at least clear naming conventions. Recent test-to-code traceability research has employed various approaches but textual methods as standalone techniques were investigated only marginally. The naming convention approach is a well-regarded method among developers. Besides their often only voluntary use, however, one of its main weaknesses is that it can only identify one-to-one links. With the use of more versatile text-based methods, candidates could be ranked by similarity, thus producing a number of possible connections. Textual methods also have their disadvantages, even machine learning techniques can only provide semantically connected links from the text itself, these can be refined with the incorporation of structural information. In this paper, we investigate the applicability of three text-based methods both as a standalone traceability link recovery technique and regarding their combination possibilities with each other and with naming conventions. The paper presents an extensive evaluation of these techniques using several source code representations and meta-parameter settings on eight real, medium-sized software systems with a combined size of over 1.25 million lines of code. Our results suggest that with suitable settings, text-based approaches can be used for test-to-code traceability purposes, even where naming conventions were not followed.

show abstract

“…There are some related techniques for studying unit test cases, which include unit test case minimization [92,91], prioritization [56,135,143], test case descriptions [85,122,95,165], code quality [33], test coverage [79], data generation [93,101], unit test smells [40,151,104,150,149], fault localization [159], automatic test case generation [52,64,69,145,160,155,91], and automatic recommendation of test examples [126]. TeStereo is also related to (i) techniques for generating documentation for software artifacts [80,63,100,97,111], and (ii) other approaches for supporting code comprehension provided by difference tools [122,95,110,113,68].…”

Section: Related Workmentioning

confidence: 99%

Automatically Documenting Software Artifacts

2016

2016 IEEE International Conference on Software Maintenance and Evolution (ICSME)

View full text Add to dashboard Cite

Software artifacts, such as database schema and unit test cases, constantly change during evolution and maintenance of software systems. Co-evolution of code and DB schemas in Database-Centric Applications (DCAs) often leads to two types of challenging scenarios for developers, where (i) changes to the DB schema need to be incorporated in the source code, and (ii) maintenance of a DCAs code requires understanding of how the features are implemented by relying on DB operations and corresponding schema constraints. On the other hand, the number of unit test cases often grows as new functionality is introduced into the system, and maintaining these unit tests is important to reduce the introduction of regression bugs due to outdated unit tests. Therefore, one critical artifact that developers need to be able to maintain during evolution and maintenance of software systems is up-to-date and complete documentation.

show abstract

Interpreting Coverage Information Using Direct and Indirect Coverage

Cited by 7 publications

References 37 publications

Dynamic Program Analysis with Flexible Instrumentation and Complex Event Processing

Dynamic Program Analysis with Flexible Instrumentation and Complex Event Processing

Large Scale Evaluation of Natural Language Processing Based Test-to-Code Traceability Approaches

Automatically Documenting Software Artifacts

Contact Info

Product

Resources

About