Testning

Viktigt att påbörja tidigt i kursen

Testa tidigt och skapa manuella testfall utifrån krav

‌

Exempel inloggning Krav - Manuella tester - Exempelapplikation

Förväntad aktivitet

Till varje krav knyt minst ett test. Beskriv kortfattat hur testningen av kravet gått till och vilket resultat det fick. Stora och mer komplicerade krav kan kräva flera tester. Om du skapar användningsfall, låt då olika scenarion få var sitt manuellt testfall. Låt testfallen ha en bestämd indata (Ex. [Mata in "Kalle"] istället för [Mata in ett namn]). Om möjligt skriv testfallet innan koden som implementerar kravet.

Rapportera testningens utfall när du beskriver vilka krav som implementerats.

Testningsmetoder

Det finns flera sätt att testa ett system — välj det som passar ditt projekt:

  • Testfall från krav — skriv testfall direkt från dina krav/issues. Avslöjar ofta svagheter i kraven.
  • Negativ testning — testa med ogiltig indata och verifiera att systemet hanterar det korrekt.
  • Automatiserad testning — kod som testar kod. Se Vecka 8 - Automatiserad testning för mer info.
  • Explorativ testning — använd systemet fritt och logga vad du gör. Skapa testfall av det som går fel.
  • Användartester — låt en annan student använda systemet och observera. Enkelt och effektivt.
  • Stresstestning — testa med extrem indata, många användare eller lite minne. Frivilligt i detta projekt.

Testspecifikation

Testspecifikationen beskriver hur din applikation testas — en oberoende testare ska kunna följa den och avgöra om testerna lyckas eller misslyckas.

Den ska innehålla:

  1. Testplan — strategi, verktyg, vad som täcks och vad som inte täcks
  2. Testsviter — grupper av testfall kopplade till krav, t.ex. "Inloggning", "Profil"
  3. Testfall — steg-för-steg beskrivning av varje test (se format nedan)

Format för manuella testfall

Namnge testfall med TC[svit].[nr], t.ex. TC1.1. Det skapar spårbarhet mot krav och gör det enkelt att referera i testrapporten.

‌‌‌‌‌

Var specifik med indata ("Johnny", inte "ett namn") — det gör testfallet repeterbart och lättare att automatisera senare.

Fullständigt exempel (Greeter)

Testrapport

Testrapporten dokumenterar resultatet av ett test och används som input till nästa iterations planering.

Den ska innehålla:

  • Datum och version av systemet som testades (använd git describe --tags --dirty)
  • Testmiljö (OS, webbläsare, enhet)
  • Resultat per testfall (pass/fail)
  • Spårbarhetstabell — vilka krav täcks
  • Förbättringspunkter och övergripande analys

För att utveckla testningen i ditt projekt

Automatiska enhetstester

‌

Instuderingsfrågor för kapitel 8

  • Vilka två huvudsyften har testning? (s227)
  • Varför kan inte testning hitta ALLA fel? (s227)
  • Beskriv med egna ord Validering och Verifiering (alltså inte bara översätt definitionen). (s228)
  • Vad bestämmer hur mycket resurser vi kan lägga på testning? (s228-229)
  • Vad skiljer testning från inspektioner? (s229-230)
  • Vilka tekniker/utvecklingsmetoder kan användas i Development testing ? (s231-245)
  • Varför är beroenden till exempelvis en databas dåligt för automatiska enhetstester och hur kan vi lösa det problemet? s234
  • Vilka ekvivalenta partioner (in och ut) kan du identifiera för en funktion som tar antal år som indata och returnerar true om personen är myndig? (Tips: tre olika in och tre olika ut) (s234-237)
  • Ge ett exempel på "emergent behaviour". (s240)
  • Förklara varför systemtestning ofta är svårare att utföra än enhetstestning. s240
  • Utveckla en funktion som returnerar medianen från en array med nummer utan inbyggd funktion för median ;) med hjälp utav TDD. Du kan skriva testerna som en serie if-satser om du inte har ett testramverk installerat. Använd processen på s243.
  • Vilka är fördelarna med TDD?
  • Vad är målet med release-testing?
  • Gå igenom dina krav och fundera kring Requirements-testing. (s245-246)
  • Gör en plan för att låta en annan student acceptanstesta din applikation eller någon del av din applikation. (s249-251)