Programvaruregression

En mjukvaruregression är en typ av programvarubugg där en funktion som har fungerat tidigare slutar fungera. Detta kan hända efter att ändringar har tillämpats på programvarans källkod , inklusive tillägg av nya funktioner och buggfixar. De kan också införas genom förändringar i miljön där programvaran körs, såsom systemuppgraderingar, systemkorrigering eller en ändring av sommartid . En mjukvaruprestandaregression är en situation där programvaran fortfarande fungerar korrekt, men fungerar långsammare eller använder mer minne eller resurser än tidigare. Olika typer av mjukvaruregression har identifierats i praktiken, inklusive följande:

  • Lokal – en ändring introducerar en ny bugg i den ändrade modulen eller komponenten.
  • Fjärr – en ändring i en del av programvaran bryter funktionaliteten i en annan modul eller komponent.
  • Unmasked – en ändring avmaskerar en redan existerande bugg som inte hade någon effekt före ändringen.

Regressioner orsakas ofta av inkluderade buggfixar som ingår i programvarukorrigeringar . Ett sätt att undvika denna typ av problem är regressionstestning . En korrekt utformad testplan syftar till att förhindra denna möjlighet innan någon programvara släpps. Automatiserade tester och välskrivna testfall kan minska sannolikheten för en regression.

Förebyggande och upptäckt

Tekniker har föreslagits som försöker förhindra att regressioner introduceras i mjukvara vid olika utvecklingsstadier, som beskrivs nedan.

Innan release

För att undvika att regressioner ses av slutanvändaren efter release, kör utvecklare regelbundet regressionstester efter att ändringar har införts i programvaran. Dessa tester kan inkludera enhetstester för att fånga lokala regressioner såväl som integrationstester för att fånga fjärrregressioner. Regressionstestningstekniker utnyttjar ofta befintliga testfall för att minimera ansträngningen för att skapa dem. Men på grund av volymen av dessa befintliga tester är det ofta nödvändigt att välja en representativ delmängd med hjälp av tekniker som prioritering av testfall .

För att upptäcka prestandaregressioner körs mjukvaruprestandatester regelbundet för att övervaka svarstid och resursanvändningsstatistik för programvaran efter efterföljande ändringar. Till skillnad från funktionella regressionstester är resultaten av prestationstest föremål för varians - det vill säga resultat kan skilja sig mellan tester på grund av varians i prestationsmätningar; som ett resultat av detta måste ett beslut fattas om en förändring av prestationstalen utgör en regression, baserat på erfarenhet och slutanvändarnas krav. Tillvägagångssätt som statistisk signifikanstestning och ändringspunktsdetektering används ibland för att underlätta detta beslut.

Innan du begår

Eftersom felsökning och lokalisering av grundorsaken till en mjukvaruregression kan vara dyrt, finns det också några metoder som försöker förhindra att regressioner läggs in i kodförrådet i första hand. Till exempel Git Hooks det möjligt för utvecklare att köra testskript innan kodändringar committeras eller skjuts till kodförrådet. Dessutom förändringseffektanalys tillämpats på mjukvara för att förutsäga effekten av en kodändring på olika komponenter i programmet, och för att komplettera val och prioritering av testfall. Programvarulinters läggs också ofta till för att commit hooks för att säkerställa en konsekvent kodningsstil, och därigenom minimera stilistiska problem som kan göra programvaran benägen till regressioner.

Lokalisering

Många av de tekniker som används för att hitta grundorsaken till programvarufel utan regression kan också användas för att felsöka programvaruregressioner, inklusive brytpunktsfelsökning , utskriftsfelsökning och programutdelning . De tekniker som beskrivs nedan används ofta specifikt för att felsöka programvaruregressioner.

Funktionella regressioner

En vanlig teknik som används för att lokalisera funktionella regressioner är bisection , som tar både en buggy commit och en tidigare fungerande commit som indata, och försöker hitta grundorsaken genom att göra en binär sökning på commits däremellan. Versionskontrollsystem som Git och Mercurial tillhandahåller inbyggda sätt att utföra bisektion på ett givet par av commits.

Andra alternativ inkluderar att direkt associera resultatet av ett regressionstest med kodändringar; inställning av divergensbrytpunkter; eller genom att använda inkrementell dataflödesanalys , som identifierar testfall - inklusive misslyckade - som är relevanta för en uppsättning kodändringar, bland annat.

Prestandaregressioner

Profilering mäter prestanda och resursanvändning för olika komponenter i ett program och används för att generera data som är användbar vid felsökning av prestandaproblem. I samband med programvaruprestandaregressioner jämför utvecklare ofta samtalsträden ( även kända som "tidslinjer") som genereras av profiler för både buggyversionen och den tidigare fungerande versionen, och det finns mekanismer för att förenkla denna jämförelse. Webbutvecklingsverktyg ger vanligtvis utvecklare möjligheten att registrera dessa prestandaprofiler.

Loggning hjälper också till med lokalisering av prestandaregression, och i likhet med anropsträd kan utvecklare jämföra systematiskt placerade prestandaloggar för flera versioner av samma programvara. En avvägning finns när du lägger till dessa prestandaloggar, eftersom att lägga till många loggar kan hjälpa utvecklare att hitta vilka delar av programvaran som regresserar med mindre granulariteter, medan att lägga till endast ett fåtal loggar också kommer att minska omkostnader när programmet körs.

Ytterligare tillvägagångssätt inkluderar att skriva prestandamedvetna enhetstester för att hjälpa till med lokalisering, och rangordning av delsystem baserat på prestandaräknareavvikelser. Bisektion kan också återanvändas för prestandaregressioner genom att betrakta commits som presterar under (eller över) ett visst baslinjevärde som buggy, och ta antingen vänster eller höger sida av commits baserat på resultaten av denna jämförelse.

Se även