Lee White, Lee White, Hareton Leung · Encyclopedia of Software Engineering · 2002
Abstract Regression testing is a testing process that is applied after a program is modified. It involves testing the modified program with test cases in order to reestablish our confidence that the program will perform according to the (possibly modified) specification. In the development phase, regression testing may begin after the detection and correction of errors in a tested program. Regression testing is a major component in the maintenance phase where the software system may be corrected, adapted to new environment, or enhanced to improve its performance. Modifying a program involves creating new logic to correct an error or to implement a change, and incorporating that logic into an existing program. The new logic may involve minor modifications such as adding, deleting, or rewriting a few lines of code, or it may involve major modifications such as adding, deleting, or replacing one or more modules or subsystems. Regression testing aims to check the correctness of the new logic, to ensure the continuous working of the unmodified portions of a program, and to validate that the modified program as a whole functions correctly. Many modifications may occur during the maintenance phase where the software system is corrected, updated, and fine‐tuned. Software maintenance is defined as the performance of those activities required to keep a software system operational and responsive after it is accepted and placed into production (FIPS, 1984). There are three types of modifications, each arising from different types of maintenance. Corrective maintenance , commonly called “fixes,” involves correcting software failures, performance failures, and implementation failures in order to keep the system working properly. Adapting the system in response to changing data requirements or processing environments constitutes adaptive maintenance . Perfective maintenance covers any enhancements to the system, where the objective may be to provide additional functionality, increased processing efficiency, or improved maintainability. During adaptive or perfective maintenance, new modules are usually introduced. The specification of the system is modified to reflect the required improvement or adaptation. However, in corrective maintenance, the specification is not likely to be changed, and no new modules are likely to be introduced. Most modifications involve adding, deleting, and modifying instructions. Many program modifications occurring during the development phase are similar to that of corrective maintenance, because the specification will not normally be modified due to a discovery of an error in the program.
Cited by 0
Amanda Schwartz · NDSU Repository (North Dakota State University) · 2013
Regression testing is an important but expensive part of the software development life-cycle. Many different techniques have been proposed for reducing the cost of regression testing. To date, much research has been performed comparing regression testing techniques, but very little research has been performed to aid practitioners and researchers in choosing the most cost-effective technique for a particular regression testing session. One recent study investigated this problem and proposed Adaptive Regression Testing (ART) strategies to aid practitioners in choosing the most cost-effective technique for a specific version of a software system. The results of this study showed that the techniques chosen by the ART strategy were more cost-effective than techniques that did not consider system lifetime and testing processes. This work has several limitations, however. First, it only considers one ART strategy. There are many other strategies which could be developed and studied that could be more cost-effective. Second, the ART strategy used the Analytical Hierarchy Process (AHP). The AHP method is subjective to the weights made by the decision maker. Also, the AHP method is very time consuming because it requires many pairwise comparisons. Pairwise comparisons also limit the scalability of the approach and are often found to be inconsistent. This work proposes three new ART strategies to address these limitations. One strategy utilizing the fuzzy AHP method is proposed to address imprecision in the judgment made by the decision maker. A second strategy utilizing a fuzzy expert system is proposed to reduce the time required by the decision maker, eliminate inconsistencies due to pairwise comparisons, and increase scalability. A third strategy utilizing the Weighted Sum Model is proposed to study the performance of a simple, low cost strategy. Then, a series of empirical studies are performed to evaluate the new strategies. The results of the studies show that the strategies proposed in this work are more cost-effective than the strategy presented in the previous study.
Cited by 0Open access
Botros Naseif Hanna Bishara Hanna · OSTI OAI (U.S. Department of Energy Office of Scientific and Technical Information) · 2024
Via programs including the Light Water Reactor Sustainability and Integrated Energy Systems, the U.S. Department of Energy has invested in the Framework for Optimization of ResourCes and Economics (FORCE) software framework (Idaho National Laboratory 2024a) for the technical and economic analysis of nuclear-integrated energy systems (IES). Nuclear IES expand the use of nuclear from traditional baseload electricity generation to a flexible and adaptive source of combined heat and power. Nuclear heat can be used in the production of a variety of energy currencies such as hydrogen and ammonia as well as other heat applications including water desalination and district heating. FORCE is designed with the intent to provide interconnected analysis tools that enable the accurate technical and economic assessment of specific nuclear IES configurations for individual energy markets. FORCE consists of three main analysis pathways: HYBRID (Idaho National Laboratory 2024b), which contains high-resolution physical models for IES; Holistic Energy Resource Optimization Network (HERON) (Idaho National Laboratory 2024c), which analyzes IES long-term economic viability; and Optimization of Real-time Capacity Allocation (ORCA) (Idaho National Laboratory 2024d), designed for real-time control of IES via digital twins and optimal decision making, including autonomous and remote operation research. Development of the FORCE ecosystem is guided by three pillars: capability, which assures that the computational requirements of IES analysis are met by the software tools; reliability, which provides for consistent code performance and expected behaviors; and accessibility, which lowers the barrier to entry for using the software and accelerates analysis by users beyond the FORCE primary developers. Reliability of the FORCE ecosystem is established according to the American Nuclear Society?s Nuclear Quality Assurance (NQA-1) program [American Society of Mechanical Engineers 1982], with specific levels of software quality assurance (SQA) within NQA-1 applied to each software tool in FORCE. As the tools within FORCE have matured, some integration algorithms to accurately connect the software tools for holistic analysis have been developed and deployed within the FORCE software repository. In accordance with NQA-1 standards, regression tests are required to guarantee the software performs consistently even when new capabilities are added to the software. In this report, we document the deployment of both unit tests, which test the consistent behavior of small pieces of the FORCE code base, as well as integration tests, which test the consistent performance of full use cases for the FORCE integration algorithms. We further document the encapsulation of these tests within a test harness, which collectively checks for each successful test completion on demand. Finally, we document the automation of the test harness using GitHub Actions [GitHub 2024], which require all tests succeed before any new capability or other changes can be added to the FORCE integration software
Cited by 0Open access
Suddhasvatta Das · 2024
Agile software development emphasizes rapid delivery of incremental features, raising concerns about software testing quality before release. Regression testing ensures new code modifications do not cause defects in already delivered features. The challenge is ensuring new code modifications do not break existing code after stopping the delivery pipeline. The research community is adapting existing regression test selection and prioritization algorithms to account for agile-specific process attributes such as time and value. The research aims to formally describe how regression testing is incorporated within the context of Agile Software Development. Additionally, the research aims to develop Regression Test Selection and Prioritization algorithms using Machine Learning techniques tailored to the characteristics of agile software development. The goal is to revolutionize the current approach to Regression Testing in Agile Software Development and deliver high-quality software within stringent timeframes.
Cited by 1
Ton J. Cleophas, Aeilko H. Zwinderman · 2018
Cited by 1
McLennan, Michael · TIB KMO / FLOWWORKS GmbH · 2012
00:09 Regression Testing 00:20 You've published it! 00:50 What's next? 02:53 You've published it again! 03:29 Cautionary Tale 06:18 Guard against those errors! 12:19 Create test cases 13:56 Label test cases 15:09 Demo: app-fermi tests 21:44 Types of errors 22:15 Assignment #10: Create tests for your tool
Cited by 0Open access
Ton J. Cleophas, Aeilko H. Zwinderman · 2021
Cited by 0
Moldovan, Andrada-Mihaela-Nicoleta · Figshare · 2025
regression testing study survey
Cited by 0Open access
Farrukh Shahzad Ahmed (12557623), Awais Majeed (12557626), Tamim Ahmed Khan (7622741) et al. · Figshare · 2022
Cited by 0Open access
Daniel J. Henderson, Christopher F. Parmeter · Cambridge University Press eBooks · 2015
In regression, estimation is only one component of an empirical analysis. It is incumbent upon the researcher to conduct inference regarding various features underlying the unknown data generating process. The story is no different for nonparametric methods. Many of the tests discussed in this chapter will be analogous to tests performed with parametric estimators. The tests here are similar to those in Chapter 4 and we suggest that you familiarize yourself with the fundamentals discussed in that section before proceeding further if you have not done so already.
Cited by 0
Grunewald, Paul · TIB KMO / FLOWWORKS GmbH · 2018
More than often it happens, that design changes of websites include unintended side-effects. Visual regression testing is one of few ways to get notified about those side-effects early on. I want to present our implementation of visual regression testing based on the RobotFramework and point out some challenges we had to face. With this approach we intend to test the university website of TU Dresden, which is a large-scaled Plone deployment.
Cited by 0Open access
Moldovan, Andrada-Mihaela-Nicoleta · Figshare · 2025
regression testing study survey
Cited by 0Open access
Lingming Zhang · Texas ScholarWorks (Texas Digital Library) · 2014
different sampling ratios . . . . . . . . .
Cited by 0Open access
Hareton Leung, Lee White · 2003
A problem facing those conducting maintenance testing is to identify proper test classes. The notion of regression testability is introduced as a way to measure the ease of retesting. Both the program design and the test plan design may affect the regression testability of a program. The testing set, testing number, regression number and stable and workable metrics are developed to measure the program and the test plan and program testability is defined. The retest strategy is proposed for performing corrective regression testing. This approach involves the use of the test plan in a way that will reduce the amount of testing required. The guiding principle of the retest strategy is to view the regression testing problem as being composed of two subproblems (the test selection problem and the test plan update problem). To this end, the author's retest strategy consists of two major phases (the test classification phase and test plan update phase).< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">></ETX>
Cited by 184
Forgács, I., Takács, É. · SZTAKI Publication Repository (Hungarian Academy of Sciences) · 1997
Cited by 0
Ole J. Forsberg · 2024
Cited by 0
Amanda Swearngin, Myra B. Cohen, Bonnie E. John et al. · 2013 35th International Conference on Software Engineering (ICSE) · 2013
As software systems evolve, new interface features such as keyboard shortcuts and toolbars are introduced. While it is common to regression test the new features for functional correctness, there has been less focus on systematic regression testing for usability, due to the effort and time involved in human studies. Cognitive modeling tools such as CogTool provide some help by computing predictions of user performance, but they still require manual effort to describe the user interface and tasks, limiting regression testing efforts. In recent work, we developed CogTool-Helper to reduce the effort required to generate human performance models of existing systems. We build on this work by providing task specific test case generation and present our vision for human performance regression testing (HPRT) that generates large numbers of test cases and evaluates a range of human performance predictions for the same task. We examine the feasibility of HPRT on four tasks in LibreOffice, find several regressions, and then discuss how a project team could use this information. We also illustrate that we can increase efficiency with sampling by leveraging an inference algorithm. Samples that take approximately 50% of the runtime lose at most 10% of the performance predictions.
Cited by 9
Torsten Hothorn, Achim Zeileis, R. W. Farebrother et al. · 2015
Cited by 25
Forster, Lucille; Beare, John Paul · OSTI OAI (U.S. Department of Energy Office of Scientific and Technical Information) · 2018
Abstract not provided.
Cited by 0Open access
Qurat Farooq · 2012
Cited by 1