Content deleted Content added
Adding short description: "Type of software bug" (Shortdesc helper) |
m v2.04b - Bot T20 CW#61 - Fix errors for CW project (Reference before punctuation) |
||
Line 1:
{{Short description|Type of software bug}}
A '''software regression''' is a type of [[software bug]] where a feature that has worked before stops working. This may happen after changes are applied to the software's [[source code]], including the addition of new [[software feature|features]] and bug fixes.<ref name=wong-issre-97>{{cite book |last1=Wong |first1=W. Eric |last2=Horgan |first2=J.R. |last3=London |first3=Saul |last4=Agrawal |first4=Hira |title=Proceedings of the Eighth International Symposium on Software Reliability Engineering (ISSRE 97) |date=1997 |publisher=IEEE |isbn=0-8186-8120-9 |url=https://ieeexplore.ieee.org/abstract/document/630875 |chapter=A Study of Effective Regression Testing in Practice}}</ref> They may also be introduced by changes to the environment in which the software is running, such as system upgrades, [[Patch (computing)|system patching]] or a change to [[daylight saving time]].<ref name=ibm-locating-bugs>{{cite conference |last1=Yehudai|first1=Amiram |last2=Tyszberowicz|first2=Shmuel |last3=Nir|first3=Dor|title=Locating Regression Bugs|url=https://link.springer.com/chapter/10.1007/978-3-540-77966-7_18#:~:text=Abstract,patch%20causes%20the%20regression%20bug.|conference=Haifa Verification Conference|conference-url=https://www.research.ibm.com/haifa/conferences/hvc2017/previous.shtml|year=2007|doi=10.1007/978-3-540-77966-7_18 |accessdate=10 March 2018}}</ref> A '''software performance regression''' is a situation where the software still functions correctly, but performs more slowly or uses more memory or resources than before.<ref>{{Cite journal|last1=Shang|first1=Weiyi|last2=Hassan|first2=Ahmed E.|last3=Nasser|first3=Mohamed|last4=Flora|first4=Parminder|date=11 December 2014|title=Automated Detection of Performance Regressions Using Regression Models on Clustered Performance Counters|url=https://sail.cs.queensu.ca/Downloads/ICPE2015_AutomatedDetectionofPerformanceRegressionsUsingRegressionModelsOnClusteredPerformanceCounters.pdf#page=1}}</ref> Various types of software regressions have been identified in practice, including the following:<ref>{{cite book |last1=Henry |first1=Jean-Jacques Pierre |title=The Testing Network: An Integral Approach to Test Activities in Large Software Projects |date=2008 |publisher=Springer Science & Business Media |isbn=3540785043 |page=74}}</ref>
* ''Local'' – a change introduces a new bug in the changed module or component.
* ''Remote'' – a change in one part of the software breaks functionality in another module or component.
Line 31:
A common technique used to localize functional regressions is [[Bisection (software engineering)|bisection]], which takes both a buggy commit and a previously working commit as input, and tries to find the root cause by doing a binary search on the commits in between.<ref>{{cite book |last1=Gross |first1=Thomas |title=Proceedings of the International Workshop on Automatic Debugging |date=10 September 1997 |publisher=Linkøping University Electronic Press |pages=185-191 |url=https://ep.liu.se/en/conference-article.aspx?series=ecp&issue=1&Article_No=15 |language=en |chapter=Bisection Debugging}}</ref> [[Version control]] systems such as Git and [[Mercurial]] provide built-in ways to perform bisection on a given pair of commits.<ref>{{cite web |title=Git - git-bisect Documentation |url=https://git-scm.com/docs/git-bisect |website=git-scm.com |access-date=7 November 2021}}</ref><ref>{{cite web |title=hg - bisect |url=https://www.selenic.com/mercurial/hg.1.html |website=www.selenic.com |publisher=Mercurial |access-date=7 November 2021}}</ref>
Other options include directly associating the result of a regression test with code changes;<ref>{{cite web |title=Reading 11: Debugging |url=https://web.mit.edu/6.005/www/fa15/classes/11-debugging/ |website=web.mit.edu |publisher=MIT}}</ref>
===Performance regressions===
| |||