Programvarutestning – Wikipedia

 Den här artikeln behöver fler eller bättre källhänvisningar för att kunna verifieras. (2010-02)
Åtgärda genom att lägga till pålitliga källor (gärna som fotnoter). Uppgifter utan källhänvisning kan ifrågasättas och tas bort utan att det behöver diskuteras på diskussionssidan.

Programvarutestning, eng. software testing, även kallat mjukvarutestning, är ett samlingsnamn för de metoder som används för att säkerställa bra kvalitet på programvara för datorer. Fokusområden är duglighet, pålitlighet, stabilitet, kompatibilitet, underhållsmässighet, användbarhet och prestanda.

Från att ha fört en undanskymd tillvaro på 1960- och 1970-talet har testningens vikt och komplexitet uppskattats i allt högre grad sedan slutet av 1980-talet. Numera ges kurser i programvarutestning vid svenska universitet[1] och det finns möjlighet till certifiering.

Det finns en mängd olika angreppssätt, såväl manuella som automatiserade, som alla måste leva med insikten att man aldrig kan testa ett program fullständigt, eftersom antalet möjligheter i praktiken är oändliga.

Syfte[redigera | redigera wikitext]

Det finns många föreslagna definitioner av vad huvudsyftet med testningen är, men några mål kan vara:

  • Att förebygga och hitta fel, buggar eller andra problem
  • Att verifiera att systemet uppfyller ställda krav
  • Att undersöka huruvida systemet under olika omständigheter beter sig på ett icke önskvärt sätt
  • Att visa att systemet uppfyller kundernas förväntningar
  • Att utforska systemet för att lära sig mer om det
  • Att ge beslutsunderlag för release
  • Att ta fram kvalitetsrelaterad information
  • Att eliminera risker

Nivåer och typer av programvarutestning[redigera | redigera wikitext]

Testaktiviteter verifierar olika nivåer av programvaruutveckling:

Programvarutestning kan göras med olika angreppssätt:

  • Ad hoc-testning är tester som görs utan specifik styrning; testaren gör det som bedöms lämpligt för tillfället.
  • Utforskande testning är en metod där exekvering, design och dokumentation sker parallellt.
  • Scenariotestning syftar att se om en längre kedja av händelser fungerar på ett bra sätt.
  • Betatestning utförs ofta av en delmängd av kunderna för att hitta allvarliga fel innan slutlig release.
  • Statisk testning är tester där man inte exekverar programvaran, exempelvis granskning eller inspektion av krav, kod eller testfall.

Andra exempel på testaktiviteter inkluderar:

  • Användbarhetstestning undersöker hur lättanvänt ett program är, ofta genom att låta kundlika personer försöka utföra uppgifter.
  • Prestandatestning utförs generellt sett för att undersöka hur ett system presterar avseende svarstider och stabilitet under last, men kan också användas för att utreda andra kvalitetsaspekter i systemet såsom skalbarhet, tillförlitlighet och resursutnyttjande.
  • Tillgänglighetstestning handlar om att så många användargrupper som möjligt ska kunna använda programmet, till exempel handikappade.
  • Regressionstestning säkerställer att existerande funktionalitet inte har påverkats (negativt).[2]

TMMi[redigera | redigera wikitext]

TMMi, eng. Test Maturity Model integration, är en modell för att utvärdera mognaden av en organisations testprocess som underhålls av TMMi Foundation[3]. Dess ursprungsmodell, TTM, utvecklades av Illinois Institute of Technology och var baserad på CMM (Capability Maturity Model). Båda modellerna har på liknande vis fem definierade mognadsnivåer, var och en med olika krav för att uppnås:

  • Level 1 - Initial Enbart ad-hoc-testning utan repeterbarhet.
  • Level 2 - Definition Process för testning finns. Det kan förekomma teststrategier, testplaner och testfall baserade på krav. Testning utförs efter att produkten är klar för att verifiera att kraven är uppfyllda.
  • Level 3 - Integration Testning är integrerat i utvecklingscykeln, exempelvis genom V-modellen. Testbehovet styrs av riskhantering och tester utförs av en testorganisation med viss självständighet.
  • Level 4 - Management and Measurement Testverksamhet bedrivs i utvecklingens alla steg, bland annat genom granskningar av krav och design. Kvalitetskrav är definierade.
  • Level 5 - Optimisation Testverksamheten utvärderas regelbundet och ett kontinuerligt förbättringsarbete utförs.

Genom att utvärdera verksamheten enligt dessa nivåer är tanken att man enklare ska kunna identifiera områden att förbättra, för att på så sätt utveckla sin testprocess.

Verktyg[redigera | redigera wikitext]

Bland verktyg som används vid testning finns defekthanterinssystem, testfallshanteringssystem, testramverk, GUI-robotar, prestandamätningsverktyg och testgenereringsverktyg. Exempel på fri programvara för testning är Watir och jUnit.

Utveckling[redigera | redigera wikitext]

Programvarutestning är en relativt ny disciplin och det finns många områden där det inte finns konsensus bland utövarna. Å ena sidan finns Context-Driven School of testing[4] som hävdar att det inte finns några givna metoder, utan att testerna måste anpassas efter den unika situationen. Å andra sidan finns det specificerade standarder inom testområdet, till exempel IEEE 829 som har tydliga metoder som kan appliceras på all form av testning. Än tydligare är den brittiska standarden BS-7925 med sina båda delar BS-7925-1 (Vocabulary of terms in software testing) och BS-7925-2 (Software component testing).

Snabb och traditionell testning[redigera | redigera wikitext]

I traditionella utvecklingsmetoder som exempelvis vattenfallsmodellen är testningen oftast tydlig och baserad på specifikationer. Den "lättrörliga" eller "agila" metoden som började användas i början på 90-talet inriktar sig på att testarna måste anpassa sig till situationer då de traditionella metoderna inte fungerar.

Utforskande och specificerad testning[redigera | redigera wikitext]

Det finns de som hävdar att varje testfall måste ha ett exakt förväntat resultat och att testerna ska skrivas innan de utförs. Andra hävdar att vaga testfall ger bättre resultat, och att testfallen ska skrivas samtidigt som man testar.

Manuell och automatisk testning[redigera | redigera wikitext]

Det finns de som hävdar att så många tester som möjligt ska vara automatiserade, och det finns de som hävdar att automatiserade GUI-tester i möjligaste mån skall undvikas.

Certifiering[redigera | redigera wikitext]

Certifiering är ett sätt att höja status på ett område, men det finns de som hävdar att programvarutestning inte är redo för detta då de certifieringsprogram som finns inte ställer några krav på att man faktiskt kan testa programvara.

Historiskt har brittiska ISEB varit stark på certifiering inom testområdet. På senare år har det mer internationella ISTQB, med sin svenska organisationsmedlem SSTB, börjat segla upp med ISTQB Certified Tester. ISEB och ISTQB samarbetar med varandra. Om man vill certifiera sig genom att skriva tentamen på sitt eget språk, så är det ISTQB med sina nationella representanter som man bör vända sig till. I Sverige är detta SSTB.

Certifieringen består hos alla dessa av en tentamen (på grundnivå) och/eller arbeten att utföra och få utvärderade. Det kursmaterial som man skriver tentamen på är allmänt tillgängligt. Tanken är att det ska gå att läsa in materialet själv utan att gå kurs. Däremot är det mycket enklare att klara tentamen om man går kurs och får kött på benen runt materialet, får reda på tankesätt, etc. Sådana kurser ges av olika företag, så kallade kursleverantörer. ISTQB-kurs på svenska fås endast ge av kursleverantör som är ackrediterad. För ISTQB-tentamen och certifiering på svenska vänder man sig till SSTB.

Accepterade sanningar/ Sju testprinciper[redigera | redigera wikitext]

Det finns några sanningar/principer som är accepterade av alla i branschen:

  • Man kan inte testa allting/fullständig testning är omöjligt
  • Det är oftast mer effektivt att fixa fel tidigt i processen.
  • Test visar att det kan finnas fel / ansamling av fel.
  • Ansamling av fel. Samma typ av fel sker på många ställen.
  • Immunitetsparadoxen/ Samma testfall hittar inga fel till slut.
  • Testning är beroende av sammanhang.
  • Frånvaro av fel fallgropen/ frånvaro av fel visar inte systemet "ofelbart".

Svensk forskning[redigera | redigera wikitext]

SWELL, Swedish Verification & Validation Excellence, var en svensk forskarskola i verifiering och validering[5] som samlade universitet och företag för att bedriva forskning och utveckling inom testning och mjukvarukvalitet. Organisationen grundades 2008 och finansierades av de inblandade parterna samt Vinnova.

Referenser[redigera | redigera wikitext]

  1. ^ http://cs.lth.se/ets200 Arkiverad 30 maj 2012 hämtat från the Wayback Machine. Software Testing at Lund University
  2. ^ ”8 Functional Testing Types Explained With Examples” (på amerikansk engelska). Insights on Latest Technologies - Simform Blog. 27 februari 2019. https://www.simform.com/functional-testing-types/. Läst 17 augusti 2021. 
  3. ^ TMMi Foundation, TMMi Foundation
  4. ^ http://www.context-driven-testing.com
  5. ^ SWELL Swedish V&V Excellence

Externa länkar[redigera | redigera wikitext]

Hämtad från ”https://sv.wikipedia.org/w/index.php?title=Programvarutestning&oldid=53953229”