Testning på 3 föreläsningar. PV7180 Verifiering och Validering. Litteratur. Vad är testning? Varför testa och olika syn? Målet med testning

Transkript

1 ning på 3 föreläsningar Första föreläsningen Översikt PV7180 Verifiering och Validering Föreläsning 3 ning del 1 Andra föreläsningen Coverage ing, OO-ing, Utvärdering av tekniker Tredje föreläsningen Automatiserad ning och sammanfattning Litteratur Whittaker, What is Software ing? And Why is it so hard? Sommerville, Software Engineering, kap 20 (Kit, Software ing in the Real World Improving the Process, sida [hela avsnittet]) Definition: Vad är ning? ing is the process of establishing confidence that a program or system does what it is supposed to do ing is the process of executing a program or system with the intent of finding errors Vad är din syn? Varför a och olika syn? Fas 0 Det är ingen skillnad mellan ning och debugging Fas 1 Syftet med ning är att visa att programvaran fungerar Fas 2 Syftet med ning är att visa att programvaran INTE fungerar Sista fasen ning är inte en aktivitet utan en disciplin som resulterar i programvara med högre tillförlitlighet Målet med ning Undvika buggar (ej med i denna föreläsning) Upptäcka buggar (kallas Defect ing ) Generellt mål Software Quality Assurance 1

2 ning och kvalitet Hur når man målen? Vad är kvalitet i programvara? Syftet med ning är att visualisera kvaliteten i åtminstone en aspekt ning kan vara mätverktyget för kvalitet i programvara strategier Ex: Defect ing metoder Ex: White-box ing nivåer: Ex: Enhets ( ) typer: Ex: Stressning, Last Överblicksbild över ning strategi Acceptans System Integrations Enhets Defect ing Statistical ing Defect ing ning av program för att skapa sig en uppfattning om att det finns defekter i systemet Statistical ing ning med något annorlunda fokus Nivå Metod Strategi Typ White box Funktion Black box Positiv Top-down Bottom up Negativ Boundary Dagens föreläsning Annan föreläsning Defect ing Processen för Defect ing Målet med defect ing är att hitta defekter i program Ett lyckat defect är ett som får programmet att uppträda på ett icke- önskvärt sätt cases data results reports en påvisar närvaron, inte frånvaron, av defekter Design cases Prepare data Run program with data Compare results to cases 2

3 fall ( Cases) och data metoder fall Indata och förväntade utfall/utdata i förhållande till systemets specifikation Indata kan även innebära särskilda aktiviteter och interaktion med systemet data Egentlig indata som har konstruerats för att a systemet Black-box ning Ett tillvägagångssätt där programmet betraktas som en svart låda Programmets fall är baserade på systemspecifikationen planeringen kan påbörjas tidigt i utvecklingsprocessen White-box ning Kallas ibland för strukturell ning fallen utvecklas i enlighet med programstrukturen och ytterligare fall identifieras genom kunskap om programmet Målet är att köra så många/alla programuttryck (inte alla kombinationer) Black-box ning White-box ning Input data I e Inputs causing ano malo us b eh av io ur data System s Derives Output results O e Outputs which reveal the presence of d efects Component code outputs Equivalence partitioning Equivalence partitioning Indata- och utdataresultat kan ofta delas in i olika klasser där alla medlemmarna i en klass är besläktade Varje klass är en ekvivalent indelning där programmet uppträder på ett ekvivalent sätt för varje klass fall bör väljas från varje sådan klass eller indelning I n v a l i d i n p u t s S y s t e m V a l i d i n p u t s O u t p u t s 3

4 Equivalence partitioning Dela in systemets indata och utdata i olika ekvivalenta mängder Om indata är ett 5-siffrigt heltal mellan och 99999, så är de ekvivalenta mänderna <10000, och >99999 Välj fall vid gränserna av dessa mängder 09999, 10000, 99999, Välj fall som på annat sätt är i gränslandet 0, -1, , osv. Equivalence partitioning Less than 4 Between 4 and 10 More than 10 Number of input values Less than Between and More than Input values nivåer Enhets ( ) Enhets ( ), även kallad modul- eller komponent Integrations System Funktions Prestanda Acceptans Installations Genomförs på systemets delar (komponenter) Genomförs av utvecklarna Målsättning: Fastställa att enhetens kod fungerar enligt designen Ta bort tidiga buggar Integration Function Performance Acceptance Installation Integrations Inkrementell integration Genomförs på systemets delar (komponenter) Genomförs av utvecklarna eller are Integration A T1 A T1 T2 A B T1 T2 Målsättning: Kombinera komponenterna till ett fungerande system Fastställa att de olika delarna fungerar tillsammans Function Performance Acceptance Installation B sequence 1 T2 T3 B C sequence 2 T3 T4 C D sequence 3 T3 T4 T5 4

5 Top-down -ning Bottom-up -ning ing Level 1 Level 1 sequence... drivers ing sequence stubs Level 3 stubs drivers ning av gränssnitt ning av gränssnitt Sker när moduler eller delsystem integreras för att skapa större system T e s t c a s e s Målet är att hitta fel som orsakats av problem med gränssnitten eller felaktiga antagande om gränssnitten Speciellt viktigt för objekt-orienterad-utveckling eftersom objekt är definierade genom deras gränssnitt A B (Gränssnitt = Interface ) C Olika typer av gränssnitt Parametergränssnitt Data skickas ifrån en enhet till en annan Delade minnesgränssnitt Minnesareor delas av enheter Procedurgränssnitt Delsystem inkapslar en mängd procedurer och anropas av andra delsystem, t.ex. objekt och abstrakta datatyper Fel i gränssnitt Felaktig användning av gränssnitt En anropande komponent anropar en annan komponent och gör ett fel i dess användning av gränssnittet, t.ex. parametrar i fel ordning Misstolkade gränssnitt En anropande komponent har inbyggda, felaktiga antagande om beteendet hos den anropade komponenten Tidsfel Den anropade och den anropande komponenten kör på olika hastigheter och använd gammal information 5

6 Riktlinjer för ning av gränssnitt Funktions Konstruera en så att parametrar till procedurer är extremvärden inom dess områden (max och min) a pekarparametrar med null-pekare Konstruera som har som mål att krascha komponenterna Använd stress i meddelande system För delade minnesareor, variera ordningen på aktiveringen av komponenter (Reader/Writer) Genomförs på hela systemet Genomförs av gruppen Målsättning: a de funktionella kraven Integration Function Performance Acceptance Installation Prestanda Exempel på prestanda Genomförs på hela systemet Genomförs av gruppen Målsättning: a de icke-funktionella kraven (de kvalitativa kraven, såsom prestanda, tillförlitlighet, osv.) Integration Function Performance Acceptance Installation Stress Utvärderar systemets prestanda när många användare använder systemet Volym Utvärderar systemets prestanda när stora mängder data hanteras Säkerhets Försäkran om att säkerhetskraven uppfylls Tids Utvärderar systemets svarstider typer Funktionella Algoritmiska Positiva Negativa Användbarhets Gränsvärdes Systemuppstart och systemavslut Konfiguration Plattforms Belastnings-/Stress (Load/Stress) Utvecklingsprojekt och ning? När skall man påbörja tänkandet och planerande av? Planerar vi ningen? Styr och hanterar vi ningen? Dokumenterar vi ningen? 6

7 R e qu ire m e nt s d efi ni ti on ning under projektets gång S y st e m a nd so ftw a re d es ig n fall plan rapport Im pl e m e nt a t io n and u nit in g Int e gr a t io n a n d s ys te m t e st in g Problem -rapport dokumentation plan specifikation fall (fallsbeskrivning) Problemrapport O p e rat io n a n d m a in te n a nc e rapport fall Syfte: a en komponent eller funktionalitet Kan innehålla följande information: Beskrivning av indata Beskrivning av förväntat beteende Beskrivning av förväntad utdata Riktlinjer för et Är en samling av fall specifikation Kan innehålla följande information Huvudsyftet med et Huvudsakliga riktlinjer för et En lista av krav som as Beskrivning av fall Problemrapport Kan innehålla följande information: Ställe: var inträffade felet? Stund: När inträffade felet? Symptom: Vad observerades? Skäl: Vad orsakade felet? rapport Är en summering av aktiviteterna Vilka har genomförts? Hur många har genomförts? Hur många har misslyckats? Osv 7

8 Tips Planera tid och resurser för Att göra fall Att designa och implementera automatiserade Att göra enhets Att göra funktionser Att göra prestandaer Att hitta och ta bort fel (debugging) er efter debugging Starta planeringen för er så fort som möjligt Starta utvecklingen av fall samtidigt med kraven Principer Fullständiga er är inte möjligt ning är kreativt och svårt En viktig del av ning är att förhindra brister från att märkas under skarp systemkörning ning är riskbaserat ning måste planeras Läs tips (förutom kurslitteratur, artiklar) Rakitin, Verification and Validation for processionals and managers Hetzel, The complete guide to software ing Tidskrifter, t.ex. IEEE Xplore, IEEE Software, ACM osv. Inlämningsuppgift 1 Fördelar och nackdelar med ning och inspektioner Parvis Deadline Minst 3 sidor och max 5 sidor 8