Skip to content
Free planNo credit card requiredStart writing
AI for Research home
AI for Research home
Dashboard
Sign inGet started

Search 250 million research papers

Read the abstract, see who wrote it and who cites it, and get the citation in APA, MLA, Chicago or Harvard.

About 10,000 papers for “Code coverage”

Code-coverage guided prioritized test generation

J.J. Li, Howell Yee · 2004

With Internet applications spreading like wildfire, software testing is challenged with new topics related to the distributed nature of Web applications. We apply code based testing techniques to the testing of Web applications, specifically Java programs. Source code based automatic test generation is difficult because most previous methods use constraint satisfaction models as a solution, which is an NP complete problem [M. J. Gallagher et al. (1997)]. We present a method of guiding users through test case generations. Instead of automating the entire procedure, our method aims at generating a framework of test cases and providing instructions for users to instantiate the framework into actual executable test cases. An early experimental study of this method shows the effectiveness of this method.

Cited by 1

Code Coverage Criteria for Asynchronous Programs

Mohammad Reza Ganji, Saba Alimadadi, Frank Tip · 2023

Asynchronous software often exhibits complex and error-prone behaviors that should be tested thoroughly. Code coverage has been the most popular metric to assess test suite quality. However, traditional code coverage criteria do not adequately reflect completion, interactions, and error handling of asynchronous operations. This paper proposes novel test adequacy criteria for measuring: (i) completion of asynchronous operations in terms of both successful and exceptional execution, (ii) registration of reactions for handling both possible outcomes, and (iii) execution of said reactions through tests. We implement JScope, a tool for automatically measuring coverage according to these criteria in JavaScript applications, as an interactive plug-in for Visual Studio Code. An evaluation of JScope on 20 JavaScript applications shows that the proposed criteria can help improve assessment of test adequacy, complementing traditional criteria. According to our investigation of 15 real GitHub issues concerned with asynchrony, the new criteria can help reveal faulty asynchronous behaviors that are untested yet are deemed covered by traditional coverage criteria. We also report on a controlled experiment with 12 participants to investigate the usefulness of JScope in realistic settings, demonstrating its effectiveness in improving programmers’ ability to assess test adequacy and detect untested behavior of asynchronous code.

Cited by 2

Code coverage criteria for asynchronous programs

Mohammad Faghanpour Ganji, Mohammad Faghanpour Ganji · Summit (Simon Fraser University)

In recent years, asynchronous programming has gained significantly in popularity.Asynchronous software often exhibits complex and error-prone behaviors and should therefore be tested thoroughly.Code coverage has been the most popular metric to assess test suite quality.However, traditional code coverage criteria are not sufficient as a measure of test adequacy for asynchronous applications.In particular, they do not adequately reflect completion, interactions, and error handling of asynchronous operations.This research proposes novel test adequacy criteria for measuring: (i) eventual completion of asynchronous operations in terms of both successful and exceptional execution, (ii) registration of reactions for handling both possible outcomes, and (iii) execution of said reactions through tests.We present JScope, a code coverage tool for automatically measuring these criteria in Java-Script applications and implement it as an interactive plug-in for Visual Studio Code.An evaluation of JScope on 20 JavaScript applications shows that the proposed code coverage criteria can help improve assessment of test adequacy, complementing traditional criteria.Furthermore, an investigation of 15 real GitHub issues concerned with asynchrony demonstrates that the new criteria can help reveal faulty asynchronous behaviors that are untested and are deemed covered by traditional coverage criteria.We also report on a controlled experiment with 12 participants to investigate the usefulness of JScope in realistic settings, demonstrating that it is effective in improving programmers' ability to assess test adequacy and detect untested behavior, and that it can be helpful for debugging.

Cited by 0Open access

Evaluating TESTAR's effectiveness through code coverage

Aaron van der Brugge, Fernando Pastor Ricós, Pekka Aho et al. · Zenodo (CERN European Organization for Nuclear Research) · 2021

Testing is of paramount importance in assuring the quality of software products. Nevertheless, it is not easy to judge which techniques or tools are the most effective. A commonly used surrogate metric to evaluate the effectiveness of testing tools is code coverage, which has been widely used for unit and integration testing. However, for GUI testing approaches, this metric has not been sufficiently investigated. To fill this gap, we run experiments with the TESTAR tool, a scriptless testing tool that automatically generates test cases at the Graphical User Interface (GUI) level. In the experiment, we analyze and compare the obtained code coverage when using four different action selection mechanisms (ASMs) in TESTAR that are used to test three SUTs.

Cited by 3Open access

An Effective Android Code Coverage Tool

Aleksandr Pilgun, Olga Gadyatskaya, Stanislav Dashevskyi et al. · Open Repository and Bibliography (University of Luxembourg) · 2018

The deluge of Android apps from third-party developers calls for sophisticated security testing and analysis techniques to inspect suspicious apps without accessing their source code. Code coverage is an important metric used in these techniques to evaluate their effectiveness, and even as a fitness function to help achieving better results in evolutionary and fuzzy approaches. Yet, so far there are no reliable tools for measuring fine-grained bytecode coverage of Android apps. In this work we present ACVTool that instruments Android apps and measures the smali code coverage at the level of classes, methods, and instructions. Tool repository: https://github.com/pilgun/acvtool

Cited by 15Open access

Toward Rigorous Object-Code Coverage Criteria

Taejoon Byun, Vaibhav Sharma, Sanjai Rayadurgam et al. · 2017

Object-branch coverage (OBC) is often used as a measure of the thoroughness of tests suites, augmenting or substituting source-code based structural criteria such as branch coverage and modified condition/decision coverage (MC/DC). In addition, with the increasing use of third-party components for which source-code access may be unavailable, robust object-code coverage criteria are essential to assess how well the components are exercised during testing. While OBC has the advantage of being programming language independent and is amenable to non-intrusive coverage measurement techniques, variations in compilers and the optimizations they perform can substantially change the structure of the generated code and the instructions used to represent branches. To address the need for a robust object coverage criterion, this paper proposes a rigorous definition of OBC such that it captures well the semantics of source code branches for a given instruction set architecture. We report an empirical assessment of these criteria for the Intel x86 instruction set on several examples from embedded control systems software. Preliminary results indicate that object-code coverage can be made robust to compilation variations and is comparable in its bug-finding efficacy to source level MC/DC.

Cited by 5

Unveiling the Secrets of Code Coverage

Owen Heaume · Apress eBooks · 2024

By now, you've mastered the art of crafting powerful Pester tests. But have you ever wondered: are you testing all the corners of your code? This is where the intriguing concept of code coverage comes into play.

Cited by 0

How Effective Are Code Coverage Criteria?

Hadi Hemmati · 2015

Code coverage is one of the main metrics to measure the adequacy of a test case/suite. It has been studied a lot in academia and used even more in industry. However, a test case may cover a piece of code (no matter what coverage metric is being used) but miss its faults. In this paper, we studied several existing and standard control and data flow coverage criteria on a set of developer-written fault-revealing test cases from several releases of five open source projects. We found that a) basic criteria such as statement coverage is very weak (detecting only 10% of the faults), b) combining several control-flow coverage together is better than the strongest criterion alone (28% vs. 19%), c) a basic data-flow coverage can detect many undetected faults (79% of the undetected faults by control-flow coverage can be detected by a basic def/use pair coverage), and d) on average 15% of the faults may not be detected by any of the standard control and data-flow coverage criteria. Classification of the undetected faults showed that they are mostly to do with specification (missing logic).

Cited by 72

Effective Fault Localization using Code Coverage

W. Eric Wong, Yu Qi, Lei Zhao et al. · Proceedings - International Computer Software & Applications Conference · 2007

Localizing a bug in a program can be a complex and timeconsuming process. In this paper we propose a code coveragebased fault localization method to prioritize suspicious code in terms of its likelihood of containing program bugs. Code with a higher risk should be examined before that with a lower risk, as the former is more suspicious (i.e., more likely to contain program bugs) than the latter. We also answer a very important question: How can each additional test case that executes the program successfully help locate program bugs? We propose that with respect to a piece of code, the aid introduced by the first successful test that executes it in computing its likelihood of containing a bug is larger than or equal to that of the second successful test that executes it, which is larger than or equal to that of the third successful test that executes it, etc. A tool, ÷Debug, was implemented to automate the computation of the risk of the code and the subsequent prioritization of suspicious code for locating program bugs. A case study using the Siemens suite was also conducted. Data collected from our study support the proposal described above. They also indicate that our method (in particular Heuristics III (c), (d), and (e)) can effectively reduce the search domain for locating program bugs.

Cited by 205

Code Coverage Demo and CI Demo

Klinvex, Alicia · Figshare · 2017

Module 8 of the Better Scientific Software tutorial delivered at SC17, Denver, Colorado, 2017-11-13.

Cited by 0Open access

On software reliability and code coverage

R.M. Karcich, Robert E. Skibbe, Akshay Mathur et al. · 1996 IEEE Aerospace Applications Conference. Proceedings · 2002

Failure and module coverage data were collected during the system testing phase of a commercial hardware-software system called Product S. The Goel-Okumoto and Musa-Okumoto models were used to predict the Mean Test Cases to Failure (MTCTF) for these data. It was observed that the errors in predictions of MTCTF correlate with a sharp rise in code coverage. The sharp rise occurs when testers test code which was not previously tested. This observation suggests that software reliability prediction models may be able to improve the accuracy of prediction by accounting for code coverage.

Cited by 7

Diablo Test Suite: Code Coverage Analysis

Rishi Ganeriwala · OSTI OAI (U.S. Department of Energy Office of Scientific and Technical Information) · 2019

An analysis of the Diablo source code covered by its Software Quality Assurance test suite was performed. Intel’s code coverage tool was used to determine the percentage of covered files, blocks, and functions. Excluding non-functional legacy files and single use developer-only files, the code coverage tool showed that 55% of blocks, the most applicable metric and closest to lines of code, are covered. For a large software code, 70-80% coverage is generally considered a reasonable target.A significant percentage of the uncovered code can be categorized as features that are not practical to test, duplicate/unused legacy code, and niche features only used by select individuals. Additionally, large segments of code dedicated to debugging and error handling are untested, as the test problems do not error out. The remaining untested code can be considered general purpose for use by the analyst/user community. These untested general purpose features are identified in the document and should be prioritized when new testing is added. Suggestions for additional test problems that would have the biggest impact on increasing the code coverage metric are presented. Finally, it is important to note that the single biggest way to increase the overall coverage metric is to delete old and unused code. While admittedly tedious to perform, future code development would also benefit markedly from this. Deleting unused code would likely push the coverage metric north of 60%, which is not too far off the 70-80% target. Overall, the current test suite covers the majority of commonly used features in Diablo, but there remains significant room for improvement. These areas for improvement have been identified.

Cited by 0Open access

Code mapping coverage of Format 3.

Melissa Finster (20513440), Maxim Moinat (20513443), Elham Taghizadeh (20513446) · Figshare · 2025

<p>It comprises all OMOP CDM domains including local concepts, and ICD-10-GM and OPS to standard mappings. Example data 3 contains fictional OPS codes. A PZN mapping to map codes from domain Drug to standard concepts is lacking.</p>

Cited by 0Open access

Estimating Residual Faults from Code Coverage

Peter Bishop Adelard, Peter G Bishop · 2002

Many reliability prediction techniques require an estimate for the number of residual faults. In this paper, a new theory is developed for using test coverage to estimate the number of residual faults. This theory is applied to a specific example with known faults and the results agree well with the theory.

Cited by 0