Oplossingen voor het testen van objectgeoriënteerde software

Transcriptie

1 Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

2 1 Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving 2 3 Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes 4 Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

3 Een vierkant in een... Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving Soms is compositie een betere oplossing. Maar het is nog steeds oppassen geblazen. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

4 Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving Delegatie en niet abstracte methoden in Super Bij overerving van concrete methodes is ook de delegatie-oplossing problematisch, omdat een correct gedrag alleen door het overschrijven van alle, inclusief de concrete, methodes van de basisklasse gegarandeerd kan worden. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

5 Het substitutieprincipe volgens Liskov Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving Substitueerbaar betekent: Exemplaren van een subklasse moeten onder alle omstandigheden in de plaats van exemplaren van elke superklasse inzetbaar zijn De pré-condities van iedere methode moeten gelijk of zwakker zijn dan in de superklasse De post-condities van iedere methode moeten gelijk of sterker zijn. Er mogen dus meer garanties gedaan worden, maar niet minder. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

6 Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving Voor de zichtbare toestanden betekent dat: Alle zichtbare toestanden en toestandsovergangen (transities) van de superklasse moeten in de subklasse bewaard blijven. In de subklasse mogen transities tussen de toestanden van de superklasse toegevoegd worden. In de subklasse mogen nieuwe zichtbare toestanden toegevoegd worde, zolang deze bestaande toestanden van de superklasse orthogonaal aanvullen ofwel subtoestanden van een reeds bestaande toestand zijn. Het waarborg- en verantwoordelijkheidsprincipe: Een klasse kan geen waarborgen voor eigenschappen van haar superklasse afdwingen. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

7 A deflated world Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving Flattening schematisch: We laten de lucht uit de verervingshiärarchie en zien welke vererfde methodes in de subklasses opnieuw getest moeten worden. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

8 Drie regels voor de vererving. Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving Een subklasse mag een gebeurtenis van de superklasse in meer toestanden accepteren dan een superklasse. Op deze wijze kunnen we een toestand van de superklasse in subtoestanden partitioneren. Een subklasse mag nieuwe toestanden definiëren wanneer deze orthogonaal ten opzichte van de superklasse zijn, dus deze slechts met nieuwe aspecten uitbreiden. Het effect van private-variabelen van de superklasse op hun toestandsruimte moet orthogonaal ten opzichte van de toestanden van de protected-variabelen zijn. Compact Eis niet meer, beloof niet minder. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

9 Toevallige correctheid door vererving Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving p u b l i c c l a s s Account { p r o t e c t e d Date lasttxdate, today ; i n t newrequestsperday ( i n t n r R e q u e s t s ){ r e t u r n ( n r R e q u e s t s / d a y s S i n c e L a s t T r a n s a c t i o n ( ) ) ; } i n t d a y s S i n c e L a s t T r a n s a c t i o n ( ) { r e t u r n ( today. day ( ) l a s t T x D a t e. txdate ( ) + 1 ) ; } } p u b l i c c l a s s S p e c i a l A c c o u n t extends Account { i n t d a y s S i n c e L a s t T r a n s a c t i o n ( ) { r e t u r n ( today. day ( ) l a s t T x D a t e. txdate ( ) ) ; // newly d e f i n e d } } HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

10 Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving Wat er allemaal mis kan gaan bij de vererving. Ontbrekende overschrijvingen: Directe toegang tot attributen: Hoekige plug in een rond gat : Ondeugende kinderen : een subklasse die niet alle berichten van de superklasse accepteert, een subklasse die in een toestand komt die voor de superklasse niet is toegestaan. Wormgaten Verantwoordelijkheidsverschuiving Fat Interface HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

11 Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving en de klasieke fout in java.util: HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

12 Teststrategie bij vererving Principes van objectgeoriënteerde vererving Flattening: Welke methodes moeten getest worden? Typische fouten in hiërarchieën van vererving Anti extentionaliteit: Een testsuite resp. de testcases voor één bepaalde implementatie volgens een eis dekken niet noodzakelijkerwijs ook de testcases voor een andere implementatie van dezelfde eis af. Anti-decompositie: De testcoverage voor een klassen- of ketentest dekt niet noodzakelijkerwijs ook de test voor de gebruikte (primitieve) klassen mede af. Anti-compositie De voor delen van een module adequate testcases zijn niet noodzakelijkerwijs ook voor de test over de gehele module voldoende. Objectoriëntatie is dus een Denken in verantwoordelijkheden HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

13 Test volgorde: In de V langs rechts omhoog 1 Methodes, dus functies van een klasse. 2 De klassen met hun methodes. 3 De hoeveelheid van klassen die gezamenlijk een taak in samenwerking uitvoeren. 4 Componenten of subsystemen als werkende bij elkaar horende groepen van hoeveelheden van klassen. 5 Applicatie of systeem. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

14 Structurele richtingen Daar komt nog de samenhang tussen klassen, dus structurele samenhang bij. top-down langs de verervingshiërarchie langs de associaties resp. de associatieketen HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

15 De orthogonale testeisen voor een klassentest HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

16 De twee integratierichtingen architectuur-test: Op basis van de klassendiagrammen wordt langs de klassenhiërarchie door de gegeneraliseerde klasse naar beneden in de richting van de gespecificeerde klassen getest. De superklassen zijn dus altijd het eerste aan de beurt. integratietest voor klassen: Op basis van de sequentiediagrammen wordt langs de associatieketens het samenspel van de afzonderlijke objecten, dus het correcte wederzijdse aanroepen van methodes getest. Daaruit resulteren twee vragen: In welke volgorde moeten de tests in objectgeoriënteerde programma s plaatsvinden? Hoe dienen objectgeoriënteerde programma s gestructureerd te worden zodat deze tests kans op succes hebben? HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

17 Associaties Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes Voorbeelden voor multipliciteitsbeperkingen bij associaties. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

18 Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes Multipliciteiten kunnen tot anomaliën leiden. Invoeganomalie: Gebeurt het invoegen van nieuwe associaties op de juiste plaats binnen de collectie? Veranderingsanomalie: Zijn veranderingen zoals bijvoorbeeld op mijn collectie correct? Wisanomalie: Wordt het juiste element gewist en is de toestand van de collectie na het wissen correct? Bij bi-directionele associaties kan het probleem van inconsistente verbindingen optreden. De heen- en terugverwijzingen passen dan niet bij elkaar (Volgende dia). HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

19 Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes Voorbeeld van een inconsistente bidirectionele associatie Tenslotte moeten de vererfde associaties aan een controle onderworpen worden. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

20 Vererving uit testers perspectief Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes strikt: In een subklasse vinden alleen uitbreidingen van haar superklassen plaats. niet-strikt: In een subklasse wordt basisfunctionaliteit uit de superklassen overschreven. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

21 Strikte vererving Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

22 Problemen bij niet-strikte vererving Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

23 Extra tests bij niet strikte vererving Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes Bij niet strikte vererving kan het voorkomen dat de overschreven methoden ook gebruikt worden in de ander methoden van de superklasse. Dat betekent dat alle vererfde methoden van de superklasse nog een keer getest moeten worden bij het testen van de afgeleide klasse HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

24 De pijltjes bepalen de volgorde Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes Uit het voorgaande vloeit voor onze tests in echte klassenomgevingen, waarin we een vervlechting van vererving en associaties hebben, een duidelijke volgorde voort. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

25 Testvolgorde voor methodes Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes 1 constructoren 2 get-methodes 3 boolean methodes, de is...()-testmethodes 4 set-methodes 5 iteratoren 6 complexe berekeningsmethodes of lokale procesbesturing binnen de klasse 7 overige methodes 8 destructoren HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

26 Invloed van zichtbaarheid (visibility) Associaties Vererving Testvolgorde bij vervlechting van associaties en vererving Testvolgorde voor methodes 1 private alleen klassen intern zichtbaar 2 protected alleen klassen-intern en in afgeleide klassen zichtbaar 3 public overal zichtbaar 4 Default alleen zichtbaar binnen nhet package Het laatste kunnen we gebruiken om de klassen die niet buiten het package zichtbaar moeten zijn toch te kunnen testen. Hetzelfde geldt voor methoden met default visibility. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

27 Modale klasse Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Niet modaal Er zijn geen beperkingen in de volgorde van het aanroepen van methodes of eventsen. Voorbeeld DateTime-klasse Uni-modaal: Er zijn sequentieafhankelijke beperkingen in de volgorde van het aanroepen van methodes en eventsen. Voorbeeld verkeerslicht-klasse Quasi-modaal: Wij vinden inhoudsafhankelijke beperkingen in de volgorde van het aanroepen van methodes en events. Voorbeeld stack-klasse. Modaal: De echte modale klassen hebben bedrijfsspecifieke beperkingen in de volgorde van het aanroepen van methodes en events alsook binnen parallelle functionele gebieden. Voorbeeld Account-klasse. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

28 Aanroepvolgorde en modaliteit. Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Modaliteit zegt dat er een voorgeschreven aanroepvolgorde is. Beide groepen moeten getest worden. Voor de niet-modale methodes zijn er twee tests die in de praktijk deugdelijk zijn gebleken. Tests met verschillende oproepvolgordes Tests met herhaalde aanroepen van dezelfde methode Modale methodes testen we als volgt: Tests in de vereiste volgorde: Functioneert alles zoals het gespecifieerd is? Worden alleen maar correcte toestanden bereikt? Tests van elke verkeerde volgorde: Wijzen de methodes de aanroep in de verkeerde toestand af? Blijft de klasse in een stabiele, correcte toestand? HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

29 Het testpattern Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers geldige aanroepen van methodes die geaccepteerd moeten worden, illegale aanroepen van methodes die afgewezen moeten worden, de resulterende toestand voor het aanroepen van deze beide methodes, De resultaten van iedere aanroep van de methode. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

30 Het testpattern Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Ontbrekende transitie: Een methode wordt afgewezen, hoewel ze bedrijfsspecifiek is toegestaan. Verkeerde actie: Het resultaat voor een bepaalde methode in een bepaalde toestand is verkeerd. Ongeldige resulterende toestand. Corrupte of inconsistente toestand Een geheime zijstraat staat het aanroepen van een methode toe, hoewel die niet toegestaan is. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

31 Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Modale klasse: toestandsmodel van een reservering HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

32 Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Modale klasse: toestandsmodel als boom HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

33 Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Modale klasse: Tabel met toestandsovergangen reserved in use returned cancelled payed reserved in use returned cancelled payed : Geldige overgangen, ongeldige overgangen HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

34 Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Modale hiërarchie: voorbeeld van geometrische klassen HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

35 Testcontext Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Het testpattern voor een subklasse kent de volgende testcontext: De klasse die getest wordt is een concrete subklasse en erft van een modale superklasse, implementeert eigen gedrag en breidt het modale gedrag van de superklasse uit. De klasse moet conform haar eigen toestandsmodel en die van zijn superklasse zijn. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

36 Centrale foutenmogelijkheden Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Een overschrijvende methode in onze subklasse produceert toestanden die een deelverzameling of uitbreidingen van de toestanden van de superklasse zijn, maar zonder de toestanden van de superklasse te kunnen veranderen. De superklasse heeft fouten die echter alleen bij het gebruik in de subklasse optreden. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

37 Andere veel voorkomende fouten Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Alle op toestand gebaseerde fouten van de superklasse worden vererfd. Mogelijke nieuwe, op toestand gebaseerde fouten, die door de uitbreiding in de subklasse kunnen zijn ontstaan. Fouten die ontstaan zijn door de eisen aan de toestanden van de superklasse niet in acht te nemen. Een geldig bericht van de superklasse wordt afgewezen. Een ongeldig bericht van de superklasse wordt geaccepteerd. Naar aanleiding van het bericht van de superklasse vindt er een verkeerde actie plaats. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

38 Klassendiagram Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39

39 Teststrategie Modale klasse Het testpattern Het testpattern voor modale klassen Niet-modale, polymorfe servers Iedere polymorfe methode moet in de omgeving van haar eigen klasse en in alle client-subklassen, die ze erven, getest worden. Client-klassen van de polymorfe server-klasse mogen door hun overschrijvingen geen fouten veroorzaken. Dit wordt gewaarborgd door zich te houden aan het substitutieprincipe. Daarenboven moet de correctheid van alle implementaties van de basisklassen-interface 1 en zijn afspraken getoetst worden. De tests worden dan als reviews of als automatische test-suites resp. test-scripts uitgevoerd. 1 In ons voorbeeld zijn het de abstracte methodes van GeomFigur. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /39