Vad händer med L3: ΔL3-L4 för Krav följs upp av annan projektgrupp. Föreläsning 5: V&V II + Design II Efterläsning Kodning

Transkript

1 Föreläsning 5: V&V II + Design II Efterläsning Kodning Programvaruutveckling - Metodik 2016 Jonas Wisbrant 1 Vad händer med L3: ΔL3-L4 för Krav följs upp av annan projektgrupp PHL kopierar L3 + PHL-protokoll + L4 till QAmapp Peer QA Signera av åtgärdslista i QA-mapp Meta QA PHL gör extra koll

2 Idé: Kommetera och färgkoda uppföljningen gult= kan ej, delvis, svårt att följa upp... Tisdag kl 10 i projektens folder Dela upp inom projektet (parvis?) Lägg rimlig tid (2-3 h / person) Agenda F4-F6 F4 Konfigurations- och versionshantering står inte så tydligt i boken regler för projektet finns i projektmaterialet på kurswebben Plattformar & produktlinjer står inte så tydligt i boken (kort i måna av tid) Programvarudesign 1 Praktisk testning - fokus white-box Programvarudesign 2 Efterläsning programmering vid F5 F6 Utvecklingsprocesser

3 Verifiering & Validering II Programvaruutveckling - Metodik 2016 Jonas Wisbrant 5 White-box testing

4 Vad innebär det som står i kompendiets Testplanen (avsnitt 5) Betyder? 3.2 Unit testing Structural (white-box) testing is mainly used Before the developers check in and baseline any code, it should have been tested, using a complete statement coverage criteria No defects found 3.3 Integration testing The integration testing should exercise all calls to the other units API Complete coverage of the API No defects found 3.4 System testing Functional based on the requirements (Appendix A) all requirements are tested No critical defects are found when all defined test cases are executed 3.5 Acceptance testing Testrapporter från systemtest är en leverabel - uppfinn och beskriv (se 3.7.3) up to customer... White-box testing -

5 White-box och kodtäckning int foo (int x, int y) { int z = 0; if ((x>0) && (y>0)) { z = x; } return z; } White-box: Täcka vägar Antalet testfall exploderar med loopar! 4 vägar 8 vägar??? vägar

6 Programvarudesign II Programvaruutveckling - Metodik 2016 Jonas Wisbrant 1 1 Design

7 Design är både en aktivitet och ett resultat Typexempel Repository (delad data) Gemensam information repository subsystem 1 subsystem 2 subsystem n Fördelar: Svagheter: - Effektivt med mycket data - Alla subsystem måste använda samma dataformat - Data-producent måste inte veta så mycket om konsument - Operationer på all data underlättas, t.ex. backup - Vidareutveckling kan vara svårt eftersom mycket bygger på en viss datamodell

8 Typexempel - Client-server Klient 1 Klient 2 Klient n Nätverk Betj. 1 Betj. 1 Fördelar: Betj. m Svagheter: Uppdatering av klient eller betjänare kan kräva uppdatering av samtliga Ingen gemensam datamodell Distribuerad arkitektur Lätt att lägga till nya klienter och betjänare Typexempel Abstract machine Varje lager utgör en abstrakt maskin som används av nästa lager Fördelar: Svagheter: Stöd för inkrementell utveckling Underlättar portabilitet Kan uppstå beroenden mellan flera lager Kan bli sämre prestanda -

9 Objektorienterad design Implementationsnära design Beskrivning av hur komponenter implementeras på klassnivå Klasser beskriver meningsfulla entiteter i problemdomänen - Substantiv i beskrivningen blir klasser - Operationer implementeras i metoder Objektorientering - Fundamentala koncept 1. Inkapsling 2. Abstraktion 3. Arv 4. Polymorfism

10 Unified Modeling Language - UML Generellt språk för att modellera programvarusystem Standardiserat av ISO Tre skapare, varav en svensk: Ivar Jacobson Statisk modell av systemet Klassdiagram Dynamisk modell av systemet Sekvensdiagram Mer i kursen Objektorienterad design och modellering eller Objektorienterad design och diskreta strukturer Klassdiagram

11 Sekvensdiagram (c-sharpcorner) Designmål: Låg koppling (coupling) I hur stor utsträckning är klasser i programmet kopplade till varandra? Låg koppling underlättar underhåll och evolution

12 Designmål: Hög samhörighet (cohesion) Hur väl innehållet i en klass hänger samman Exempel: Logisk t.ex. en klass som sköter all utmatning av data Temporal t.ex. en klass som sköter all uppstart eller avslut Procedurbaserad aktiviteter som utförs efter varandra slås ihop Kommunikationsbaserad delar som behandlar samma data slås ihop Sekventiell kedja av aktiviteter som hänger ihop i sekvens Funktionell innehållet står för en enstaka funktion, t ex sortera vektor Designmönster Beprövade lösningar på återkommande problem Ursprungligen från arkitektur Inom programvara används objektorienterade koncept Några exempel: Singleton Iterator Visitor garanterar ett unikt objekt av en klass traverserar en samling objekt gör en operation på samtliga objekt i en samling

13 Exempelmönster: Observer Separera ett objekts tillstånd från presentation Möjliggör flera olika vyer Design av användargränssnitt Textbaserat gränssnitt Kraftfullt för expertanvändare Grafiska användargränssnitt Lättare att lära sig och använda

14 Några grundläggande designprinciper Igenkänning Använd välkänd terminologi från domänen Följ beprövade koncept (fönster, flikar, dialogfönster etc.) Konsistens i GUIt Använd samma grafiska komponenter överallt Erbjud samma kortkommandon överallt Inga överraskningar Användaren ska kunna förutspå vad som händer Återhämtning Användare gör fel: tillåt återgång till föregående tillstånd Guida användaren Hjälp användaren och presentera feedback I projektet: Designdokumentet Ingen mall finns Hitta ett format som funkar enligt policy i procesmodellen Rita klassdiagram Behöver inte vara UML Relationer och multiplicitet Alla GUI-klasser behöver ej visas (en GUI -box räcker) Högnivå beskrivning av ansvarsfördelning Referens till javadoc med: - Ansvarig utvecklare och kort förklaring av klassens syfte. - Alla publika metoder. Namn, parametrar och returvärde. där lämpligt

15 Design - sammanfattning Design är både en aktivitet och ett resultat Arkitekturdesign är en övergripande nedbrytning av systemstruktur: System Subsystem Moduler Val av arkitektur beror på kvalitetskraven Exempel: repository, client-server, abstract machine Objektorienterad design beskriver hur komponenter implementeras av klasser Beskrivs vanligtvis med UML Sträva efter låg koppling och hög sammanhållning Utveckla GUI som matchar användarens mentala modell Parvis systemtestning - exempel Programvaruutveckling - Metodik 2016 Jonas Wisbrant 3 0

16 Hitta testfall för parameterpar för systemtest av diskmaskin - 9 av 18 fall räcker Testparametrar: Temperatur Miljöläge Nedsmutsningsgrad (45, 55, 65) (on, off) (lätt, måttlig, grov) Utfall: Diskresultat (rent, smutsigt) Temp Miljö Resultat Smuts Parvis testning för systemtest av diskmaskin 3 x 2 x 3 = 18 möjliga testfall

17 Parvis testning Samtliga kombinationer av parameterpar testas En black box-teknik Färre testfall än vad som krävs för uttömmande testning Men en rimlig nivå för att hitta defekter Generera testdata som uppnår parvis täckning med ett minimalt antal testfall är svårt ett kombinatoriskt optimeringsproblem Systemtest diskmaskin: Möjliga par Temperatur-Miljöläge (3 x 2 komb.) 45-on, 45-off 55-on, 55-off 65-on, 65-off Temperatur-Nedsmutsningsgrad Miljöläge-Nedsmutsningsgrad (3 x 3 komb.) (2 x 3 komb.)

18 Parvis testning för systemtest av diskmaskin 9 testfall räcker för att testa alla parameterpar