Informatika | Tesztelés, Minőségbiztosítás » Szoftvertesztelés III előadás

Szoftver tesztelés a gyakorlatban 3 Speciális tesztelési helyzetek Objektum orientált szoftverek tesztelése 3 OO sajátosságok ! adat elrejtés ! egymásra ható független objektumok saját állapotokkal (nincs egy megosztott globális állapot ) ! a rendszer struktúrája helyett a viselkedésén van a hangsúly ! kód újrafelhasználás ! egységbezárás ! öröklés ! többalakúság 4 OO következmények ! Egységbezárás ! az osztályok nem funkcionális részprogramok (metódusok) ! nehéz integrációs tesztelés (állapot beállítás) ! Adat elrejtés ! állapot vizsgálat az objektum interfészén keresztül ! Örökl!dés ! többszörös tesztelés szükségessége 5 Teszttervezés ! Várható hibák alapján ! OO meggondolások Bizonyos hibák kisebb valószín"séggel ! Bizonyos hibák nagyobb valószín"séggel ! Újfajta hibák ! ! Várható felhasználás alapján ! Scenárió alapú tesztelés 6 Újfajta hibák ! Örökl!dés,

többalakúság ! milyen kód hajtódik végre metódus híváskor? ! jó-e a paraméterek formája? ! pl.: base::foo() derived::foo() ! teszt nyílvántartás (kontextus) változása 7 Hibavalószín"ség változása ! OO metódusok általában rövidebbek ! inkább integrálási problémák 8 A rendszer szétbontása ! objektumok, osztályok -> modul tesztelés ! együttm!köd" osztályok -> osztály csoport tesztelés (integrációs teszt) 9 Osztály tesztelés ! Metódusok, mint egységek ! alacsony ciklomatikus komplexitás ! bonyolult interfészek ! sok csonk szükséges ! Intraclass és interclass integráció ! Osztályok, mint egységek ! statikus nézet ! fordítási id! nézet ! végrehajtási id! nézet Hagyományos tesztelési módszerek ! Izolációs tesztelés ! nehéz, ritkán alkalmazott ! pl.: Osztály tesztelés alatt Osztály A Osztály B Osztály C Osztály D 10 Hagyományos tesztelési módszerek 11 ! Bottom-up

tesztelés ! osztályokból álló rétegek ! probléma a körkörös hivatkozásokkal ! bels" m!ködés és interfészek tesztelése egyszerre történik 12 Tervezés tesztelhet"ségre ! Osztályok közötti felesleges kapcsolatokat kerülni kell ! Lehet"ség a bels" adat lekérdezésére, beállítására ! Ne használjunk feleslegesen virtuális metódusokat ! Absztrakt alap osztályok használata (interfész osztályok) 13 Interfész-osztályok Interfész A Osztály tesztelés alatt Implementáció A Interfész B Interfész C Implementáció B Implementáció C Interfész D Implementáció D Öröklési kontextus metrikák szükségessége Bázis osztály Lesz. A Lesz. B Örökölt metódusok Örökölt metódusok Új metódusok Új metódusok 14 15 1. Példa ! bázis osztály ! inherited(int x) . if(x<0) x=x/redef(); . ! redef() : int 1.10 ! leszármaztatott osztály ! redef() : int 0.20 16 Állapot kontextus ! Állapotgép

alapú tesztelés ! állapot függ! viselkedés ! állapot-kontextus metrikák ! Belépési pont lefedés állapot- kontextussal 17 4.2 Using White-Box Coverage Metrics If entry-point coverage does not ensure thorough testing, perhaps we should use a stronger coverage requirement, say, 100% decision coverage. Unfortunately, there are disadvantages to the adoption of such a requirement. 2. Példa One factor is that there may be decisions in the code which do not correspond to features of the public interface. Typical examples include error handling code and defensive programming idioms. In these cases, 100% decision coverage may be difficult to achieve. ! Korlátos stack A more significant problem is the inability of traditional structural coverage metrics to int test driver() { identify code which is missing altogether. For example, consider what would happen BoundedStack stack(2); to check for the stack-empty condition in if the BoundedStack implementor forgot pop().

Requiring 100% decision coverage would not help find this fault – the stack.push(1); missing condition is not there to be covered! 4.3 We Can Do Better }; stack.pop(); // destructor called implicitly at end of block Actually, we can write a better test set than that required by any traditional structural coverage metric, and without any knowledge of the internal details of the class. int better test driver() { The UML state transition diagram (see figure 6) shows how the behaviour of the class BoundedStack stack(2); changes, depending on the current state. This type of diagram is commonly used to describe the state-dependent behaviour of classes stack.push(3); // push() when empty stack.push(1); // push() when partially-full try { stack.push(9); } // push() when full catch (BoundedStack::overflow) { } // expected to throw pop() empty stack.pop(); // pop() when full stack.pop(); // pop() when partially-full push() destruction pop() try { stack.pop(); } // pop() when empty

pop() partially full destruction H catch (BoundedStack::underflow) { } // expected to throw push() BoundedStack stack2(3); push() destruction pop() Throws stack2.push(6); // stack2 is partially-full BoundedStack::overflow BoundedStack stack3(1); full push() stack3.push(6); // stack3 is full Figure 6: State transition diagram for BoundedStack // destructors called implicitly at end of block for We can use the additional information provided in the state transition diagram to // stack (empty), stack2 (partially-full) and stack3 (full) design a test set which thoroughly exercises the BoundedStack class. }; H Throws BoundedStack::underflow 4.4 construction Writing State-Driven Test Cases The aim of our test design is to exercise every method in every possible state. In the improved test set which follows, the push() and pop() methods are invoked on an empty, partially full and full stack: 10 IPL Information Processing Ltd 18 Integrációs tesztelés ! UML támogatás az integrációs

teszteléshez ! Együttm"ködési diagram ! Szekvencia diagram ! MM-utak ! Különböz! szomszédsági centrumok 19 Tesztek újra hasznosítása ! Felüldefiniált és többalakú metódusok ! eltér! specifikáció és megvalósítás ! megfelel! tervezéssel hasonlóság ! átfed! tesztesetek 20 3. Példa 21 OO tesztelés metrikái ! Belépési pont lefedettség ! Kölcsönös hívás lefedettség ! Kontextus függ! mértékek (a hagyományos metrikák spec. változatai) ! Öröklési kontextus lefedettség ! Állapot kontextus lefedettség (állapot alapú tesztelésnél) Metrikák gy"jtése, m"szerezés ! Csomagoló osztályok ! (illeszt! tervezési minta) 22 23 Scenárió alapú tesztelés ! Use case-k használata ! Követelmény meghatározás ! Interakciós hibák felderítése ! OO hatás ! szoftver struktúra (mély szerkezet) ! interfész (UI) struktúra (felületi szerkezet) 24 Felületi struktúra ! Direkt manipuláció ! Független

objektumokban elosztott funkcionalitás ! Task alapú megközelítés 25 Mély szerkezet ! Szoftver szerkezetének megértése m"ködés közben ! Class diagramok örökl!dés ! kapcsolatok ! ! Objektum diagramok, interakciós diagramok, use case maps ! m"ködés közbeni kapcsolatok 26 Tesztelési tervezési minták ! Név ! Cél ! Kontextus ! Hibamodell ! hiba elérése ! hiba kiváltása ! hiba terjesztése ! Stratégia ! algoritmus, technika, heurisztika Automatizált tesztelés 28 Automatizált tesztelés hatásai ! Általában több különböz! eszköz szükséges ! Tesztelési ráfordítás nem feltétlenül csökken ! Tesztelési id! nem csökken ! Egy “mini” fejlesztési folyamat jelenik meg ! Nem minden teszt automatizálható ! Képzés szükséges Automatikus tesztel! eszközök 29 ! Tesztel! eszköz ismerete ! kompatibilitás a fejlesztési környezettel ! Automatizálható tesztek ! Kereskedelmi termékek ! szükséges

funkcionalitás vs. túl sok funkció ! Speciálisan fejlesztett megoldások ! létrehozási költségek 30 Eszköz típusok ! Teszt-eset generátor ! Lefedettség elemz! és kód bem"szerez! ! Memória szivárgás detektorok ! Használhatósági vizsgálati eszközök ! Teszt management eszközök ! Hálózati tesztel! eszközök ! GUI teszt eszközök ! Teljesítmény, stressz tesztel! eszközök Speciálisan fejlesztett eszközök 31 ! Fejlesztési okok ! Operációs rendszer inkompatibilitás ! Alkalmazás inkompatibilitás ! Speciális tesztelési igény ! A fejlesztés menete ! Er!forrásigény, fejlesztési korlátok meghatározása ! Teszt eszköz fejlesztése része a rendszer fejlesztési folyamatnak, ! de önnálló célként kezelend! Technológiák automatikus teszt eszközök fejlesztésére ! shell scriptek ! script nyelvek: Perl, Python ! magas szint" programozási nyelvek ! COTS integrálás ! adatbázis kezel!k ! sorkezel!k ! XML editorok,

parszerek ! makro rögzít!k ! verzió management eszközök ! összehasonlító eszközök 32 Spec. fejlesztés" tesztkörnyezet példa struktúra Analysis Module Test Result DB Test Management Module Queue Manager Test Case Version Management Module Test Case DB 33 Control PC Web Tier Equipment Adapter Equipment Under Test Control PC Test Automation Framework Tesztel! eszközök kiválasztása ! Meghatározó szempontok ! szoftver technológiai, fejlesztési környezet ! alkalmazott tesztelési módszertan ! támogatandó tesztelési tevékenység ! alkalmazott szoftver architektúra ! adatbázisok, middleware, GUI, OR ! egy vagy több eszköz? ! szoftver által kezelt adatok verifikálhatósága ! teszt típusok 34 35 Tesztkörnyezetek (pl.) ! sgi Tester ! teszt paraméterek beállítása 36 Tesztkörnyezetek (pl.) ! lefedettségi adatok 37 Tesztkörnyezetek (pl.) ! WDTest Major Features Unit and Integration Testing: on both host and target

platforms T T T T T T T T T T T T T T T 512 860 753 47843 512 861 753 47869 512 863 753 47964 512 864 753 47990 512 864 752 48016 512 866 752 48065 512 867 752 48114 516 867 752 48277 517 867 752 48371 512 867 752 48471 512 867 752 48573 512 869 750 48878 512 885 742 48904 512 897 740 48936 512 903 739 48976 "Saj·tgÈp-CabinetWClass-717-653-0-0-" "Saj·tgÈp-CabinetWClass-718-653-0-0-" "Saj·tgÈp-CabinetWClass-720-653-0-0-" "Saj·tgÈp-CabinetWClass-721-653-0-0-" "Saj·tgÈp-CabinetWClass-721-652-0-0-" "Saj·tgÈp-CabinetWClass-723-652-0-0-" "Saj·tgÈp-CabinetWClass-724-652-0-0-" "-Shell TrayWnd-865-8-0-0--TrayNotifyWnd-8-7-0-0-" "-Shell TrayWnd-865-8-0-0--TrayNotifyWnd-8-7-0-0-" "WinVNC Tray Icon-WinVNC Tray Icon-819-685-0-0-" "WinVNC Tray Icon-WinVNC Tray Icon-819-685-0-0-" "WinVNC Tray Icon-WinVNC Tray Icon-821-683-0-0-" "WinVNC Tray Icon-WinVNC Tray

Icon-837-675-0-0-" "WinVNC Tray Icon-WinVNC Tray Icon-849-673-0-0-" "WinVNC Tray Icon-WinVNC Tray Icon-855-672-0-0-" Tech Cantata++ has been designed around the requirements of the C/C++ language a tool which allows developers to efficiently perform unit and integration testing Teszt script (macro) részlet offers high productivity and a unique set of testing, coverage analysis and static features. Unit and Integration Testing Integrated Coverage Analysis Wizard-driven Test Script generation step-by-step facilities for creating a complete test driver environment. Full support for: ANSI C, ISO C++ and EC++ GUI: Graphical results analysis and Wizard-driven test preparation Flexible Test Build/Run from inside Cantata++ or via developer’s compiler IDE. Object Oriented: OO-aware testing and coverage analysis Cross-Platform Execution of tests from development environment to target. Intuitive Test Directives for quickly developing structured repeatable

tests yielding clear and unambiguous results. Stubbing and Wrapping: to simulate and control external interfaces Tesztkörnyezetek (pl.) Static analysis: code complexity and size metrics 38 T W a te Checks for all standard and ! IPL Cantata++ Studio user-defined data types. Exception verificatio expected and unexpe exceptions. White Box and Black techniques are fully su Stubbing - programm of external software, w sequence validation. Automated Wrappin control over external i allowing use of real ex in integration testing. Test Case Re-use for classes and template Test and Coverage results in Developed under the control of IPL’s Quality Management System which is certified to ISO Studio Project Level Tree View of test pass/fail results with drill-down for easy navigation to individual tests. Detailed Test Diagnostics for all Tesztelés grafikus felhasználói felületeken keresztül 40 Probléma ! események (tér és id!beli) képezik a bemenetet !

eseményvezérelt rendszerek ! nagy és komplex eseménytér ! felhasználói beavatkozások lehetséges száma nagy ! tetsz!leges id!zítés és esemény sorozatok ! nagy kódkomplexitás ! a kimenet fogalmának értelmezése nem egyszer" 41 Következmények ! Kézzel végrehajtott tesztelés problémás ! nem dokumentált ! nehezen reprodukálható ! de hatékony! ! Tesztautomatizálás költséges ! rögzített (capture tool) tesztek nem alkalmasak automatizálásra -> teszt fejlesztés ! Gyakran csak könnyen végrehajtható teszteket automatizálnak ! Nehéz a tesztesetek karbantartása ! komponensek helye, mérete változik ! felület nyelve változik ! rögzit! eszköz nehezen módosítható scriptet készit Rögzít!/visszajátszó eszközök ! Fix (rögzített) adatértékek ! input értékek ! képerny! koordináták ! ablak címkék ! id!k! ! Nem moduláris scriptek ! Nincsenek szabványok 42 43 Helyes megközelítés ! Tudatosítani a

tesztfejlesztés költségeit ! tervezés ! fejlesztés ! Adatvezérelt teszt architektúra használata ! teszt végrehajtó kódtól elkülönített paraméter állományok ! komplex tesztesetek szétbontása résztesztekre ! Keretrendszer jelleg" tesztkörnyezet használata ! tesztelt felülett!l elválasztott tesztfüggvénykönyvtár (teszt script független ) ! custom control vezérlés ! elemi és komplex függvények létrehozása ! struktúrált rögzít!-visszajátszó környezet 44 Helyes megközelítés (folyt.) ! Struktúrált, moduláris UI navigáció ! navigációs függvények külön modulba ! UI componensek elérése ! billenty" használat szimulálása ! objektum nevek, egyedi ID-k ! esetleg címkék, x,z koordináták ! GUI map adatbázis ! Különböz! ablakkezel!khöz tesztelési függvény könyvtárak ! pl. WinRunner 45 Test harness rendszerek ! Magas szint" programozási nyelven fejlesztve ! Illeszt! tervezési minta alkalmazása !

többféle rendszer tesztelhet! ! Felhasználói felület megkerülése ! gyorsabb tesztelés ! MVC! ! Tesztesetek leírása ! Kiinduló pont beállítás 46 GUI test harness pl. ! Mercury WinRunner 47 Véletlen tesztgenerálás ! Palm OS Emulator Gremlins Tesztelés standard script interfészen keresztül ! Perl, VB + COM ! AppleScript Teszt script GUI Script interfész Program kód 48 Tesztelés virtuális perifériákon keresztül 49 ! Eggplant + VNC ! image capturing + scripting Scripts are ge in “Capture M Menu, tab, tex other UI elem selected The command executed The image is Line of script i for you 50 AppleScript és tesztelés ! System Events 3. The SenseTalk code for the command is added t ! Mac OS X accessibility interface ! UI Element inspector Teszt script ! AppleScript Studio GUI Script interfész Program kód