I detta kapitel kommer begrepp och testmetoder presenteras som ligger till grund för de nya testningsmetoderna som kommer introduceras i senare avsnitt. De definierade termerna nedan grundar sig i definitionerna Paul C. Jorgensen sätter ned i sin bok “Software Testing: A Craftsman’s Approach”[75]
B.3.1
Testobjekt
Ordet testobjekt (eng. test item) syftar på det som testas i ett specifikt testfall. Exempel är bland annat en funktion, en modul eller för tester av exempelvis användargränssnitt kan det gälla ett helt fungerande program eller prototyp av sådan. I de fall då testobjekten blir för stora kan bakomliggande funktioner impersoneras av hårdskrivna, korrekta och inkorrekta svar. Detta görs i de fall då det ej är nödvändigt att testa dessa funktioner; exempelvis då de testas av andra testfall.
B.3.2
Ekvivalensklasser
Ekvivalensklasser är ett sätt att dela upp indata i ekvivalenta subklasser till hela indata mäng- den. Ekvivalenta i den meningen att indata i en subklass ger upphov till samma typ av svar från testobjektet. Denna uppdelning möjliggör en drastisk minskning av sökområdet för test- ningen utan att förlora komplett täckning.
B.4. Metod
B.3.3
Uttömmande testning
Uttömmande testning är som namnet antyder på karakteriserat av att man identifierar hela mängden av möjlig indata till programvaran som testas och sedan går igenom dem allihop och jämför med godkänt beteende för varje fall.
Denna typ av testning kan bli extremt resurskrävande för komplicerade funktioner med stor variation på indata. För mindre indata mängder är dock kostnaden inte ett lika stort bekymmer och ser då till att testobjektet testas fullständigt vilket för kritiska system kan vara värt den extra tidskostnaden. Metoden kan även vara lättare att ställa upp då mindre förarbete krävs för att hitta och avgränsa testfall.
B.4
Metod
I detta kapitel kommer den metod som använts för att bygga upp en den teoretiska grund som behövs för att senare besvara frågeställningen att beskrivas. Problem från vårt testnings- arbete kommer dessutom utvärderas och testmetoder som kan underlätta hanteringen av dessa problem kommer presenteras.
Stöd för svaren på frågeställningarna kommer samlas in utifrån följande punkter:
• Litteratursökning: dels formella artiklar som beskriver hur testning bör utformas och dessutom manualer+bloggar som beskriver användningen av pytest.
• Analys av testningsarbetet i projektet: bla genom jämförelse av levererad produkt med kravspecifikationen.
B.4.1
Litteratursökning
För att lägga en teoretisk bas för testningsarbetet konsulterades kursmaterialet från kursen “Software Testing” (kurskod: TDDD04) som hålls på Linköping universitet [76]. I denna kurs rekomenderades kursboken: “Software testing: A Craftsman’s Approach” [75] och är huvud- källan till den grundläggande teorin i detta bidrag.
En fokuserad genomläsning av denna text gjordes genom att först identifiera relevanta kapitel för testning av ogenomskinliga testobjekt. Den första grova sållningen gjordes genom att söka i en elektronisk kopia efter nyckelord som tros relatera till testning av denna typ utav objekt.
Listan nedan innehåller de nyckelord som användes vid avgränsning inuti denna text. • “black box”
• “okänd”
• “ogenomskinliga”
Identifierade kapitel och delkapitel lästes igenom grundligt och samtidigt noterades ter- mer som informerade utökning av nyckelordslistan som återanvändes vid vidare eftersök- ningen i UniSearch och Google Scholar.
UniSearch
UniSearch är en tjänst som tillhandahålls för studenter och personal vid Linköping Univer- sitet som tillåter åtkomst till allt material universitetet prenumererar på; material så som: e-böcker, tidsskrifter och artiklar. Verktyg är byggt på “EBSCO Discovery Service” som är en tjänst som hjälper till att tillgängliggöra alla informationsresurser via en portal.
B.5. Resultat
Följande sökningar gjordes i UniSearch: Sökord: “software testing black box”
• A case study of black box fail-safe testing in web applications
• Test Case Selection for Black-Box Regression Testing of Database Applications [C] • Two decades of Web application testing—A survey of recent advances [C]
• A language-independent approach to black-box testing using Erlang as test specifica- tion language
• Black-box testing: Techniques for functional testing of software and systems [C]
B.5
Resultat
Resultatdelen av detta bidrag är uppdelad i två huvudavsnitt. Det första avsnittet går igenom de testmetoder som rekommenderas och nämns i sammanhanget “Black box testing” och det senare kommer gå igenom ett antal problem från både testningsarbetet och implementatio- nen.
B.5.1
Arbetsätt och testmetoder
Metoderna som främst talas om i materialet som hämtats i undersökningen har varit relate- rade till “Uttömmande testning”. En metod som tyvärr visade sig vara svårtillämpad i vårt system då vi ej hade tillräcklig förståelse av OpenCORs inre för att avgränsa testningen till något realistisk omfång. Variationer på uttömmande testning med avgränsningar av testom- rådet så som “All Pairs” är dock fullt implementerbara på grund av begränsningen av indata mängden och kommer att beskrivs i detta kapitel tillsammans med andra testmetoder som funnnits relevanta vid testning av “black-boxes”.
All Pairs testing
“All Pairs” testing [75] [77] är en populär metod som ämnar att minska tidskostnaden för uttömmande testning där fel kan uppstå som resultat av specifika kombinationer av indata. Istället för att ställa upp hela indata mängden delas indatan upp i ekvivalensklasser där tester sedan körs över alla möjliga kombinationer av två ekvivalensklasser.
Tekniken bygger på ett antal antaganden om indatan: att indatan är oberoende från varandra och att fel inte beror på ordningen som indatan skickas på. Detta antagande gör att metoden inte kan garantera att fel som uppstår som resultat av specifika kombinationer av mer än två ekvivalensklasser hittas.
Kraften i denna metod kommer från att när antaganden kan göras om det maximala an- talet typer av indata som spelar in vid ett fel så tillåter det en drastisk minskning av använd- ningsområdet som behöver sökas av.
Att dessa antaganden kan göras bygger på observationen att samma exponentiella ök- ning av antal testfall som sker vid uttömmande testning även sker på användarsidan. När det krävs fler indataberoenden för att ett fel skall uppstå blir det mindre sannolik att den situationen uppstår under normal körning.
“All Pairs” testning ämnar därför att täcka de mest sannolika situationer där fel kan upp- stå: de där felet uppstår som resultat av antingen en typ av indata eller interaktionen i ett testobjekt när två typer av indata skickas in.
B.5. Resultat
Exploratory testing
“Exploratory testing” eller “utforskande testning” är en ledigare filosofi för testningsarbete som bygger på idén att en testskrivare som känner till systemet kan vidarutveckla tester efter testkörningar utifrån dennes kunskap om systemet.
Några punkter som kännetecknar “Exploratory testing” som Paul C. Jorgensen pekar ut [75] är följande:
• Fokuserad interaktion med systemet som testas, ett tydligt mål krävs med testningen för att arbetet inte ska bli för spritt.
• Krävs mycket resurser i from av tid från testskrivare • Mindre dokumentation vid uppställning av testarbetet.
• Mer dokumentation av upptäckter under testkörning: buggar såväl som system infor- mation som uppkommit.
Black-box sårbarhetstestning av webbapplikationer
Yuan-Fang Li, et al ställer upp ett antal sökta kvalitéer på programvara som letar efter sårbar- heter i webbapplikationer [78] där programvaran som söker inte har någon inblick i koden som körs i webbläsaren. Specifikt anser de att god testningsprogramvara skall utöver iden- tifiering av fel och sårbarheter även kunna klassificera dessa. Ytterligare menar de att dessa verktyg är av större intresse då testningen önskas utföras likt hur en applikation kommer användas i bruk.
B.5.2
Problem ur projektarbetet
I detta delavsnitt kommer ett antal situationer där problem uppstått ur både testningsarbetet och implementationen presenteras. För varje problem har anledningen till att projektgruppen identifierade problemet beskrivits tillsammans med problemets felkälla.
Testningsarbetet
Via enhetstesten som utfördes under iteration 2 på motorn med OpenCOR inkopplat upp- täcktes att OpenCOR kan slås ut då funktioner i simulationsobjekt som är importerade till Python kallas på i fel ordning. Detta uppkom tidigt i iteration 2 under utforskningen av OpenCOR inladdat i en Jupyter Notebook.
Dessa testresultat influerade implementationen av motorn under resten av projekttiden för att förhindra att problem med simulationsobjekten uppkommer i senare stadien. Speci- fikt ändrades implementationen så att interaktionen med simulationsobjekten blev väldigt begränsad och ordningen på funktionsanroppen sattes ned statiskt i motorns funktioner.
Lösningen för arbetet med CellML filer och hur de simuleras i OpenCOR fungerar vid akt- sam användning utan problem, men utan skarp validering av inmatning - exempelvis simu- leringsanrop innan ett simulationsobjekt har initialiserats - kan orsaka att OpenCOR stoppar under körning. Vilket gjorde att testning utav validering på indata från backend prioriterades i arbetet under iteration 3.
I början av iteration 3 upptäcktes en bugg som fick en av simulationerna att mata ut orea- listisk data. Detta har kopplats med inställningar i den “Ordinära differential ekvations lösa- ren” som sitter i OpenCOR. Mer specifikt har det med vilken tidsskala en modell är definerad för och då det begärda simulationsspannet tvingar OpenCOR att stega igenom fler punkter än inställningarna tillåter. Ett sätt att interagera med dessa inställningar i ODE-lösaren hitta-