Alapadatok
Év, oldalszám:2005, 25 oldal
Nyelv:magyar
Letöltések száma:179
Feltöltve:2009. március 04.
Méret:1 MB
Intézmény:
-
Megjegyzés:
Csatolmány:-
Letöltés PDF-ben:Kérlek jelentkezz be!
Értékelések
Nincs még értékelés. Legyél Te az első!Legnépszerűbb doksik ebben a kategóriában
Tartalmi kivonat
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ó ! 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ó ! hibák alapján 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 !
Bottom-up 11 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 állapotkontextussal 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 H Throws BoundedStack::underflow construction pop() empty push() pop() destruction pop() partially full destruction H push() push() pop() Throws BoundedStack::overflow destruction full push() Figure 6: State transition diagram for BoundedStack We can use the
additional information provided in the state transition design a test set which thoroughly exercises the BoundedStack class. 4.4 empty stack.push(1); // push() when partially-full try { stack.push(9); } // push() when full catch (BoundedStack::overflow) { } // expected to throw stack.pop(); // pop() when full stack.pop(); // pop() when partially-full try { stack.pop(); } // pop() when empty catch (BoundedStack::underflow) { } // expected to throw BoundedStack stack2(3); stack2.push(6); // stack2 is partially-full BoundedStack stack3(1); stack3.push(6); // stack3 is full // destructors called implicitly at end of block for diagram to // stack (empty), stack2 (partially-full) and stack3 (full) }; 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 ! Tesztel! ! 29 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 ! Fejlesztési 31 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 512 512 512 512 512 512 516 517 512 512 512 512 512 512 860 861 863 864 864 866 867 867 867 867 867 869 885 897 903 753 753 753 753 752 752 752 752 752 752 752 750 742 740 739 47843 47869 47964 47990 48016 48065 48114 48277 48371 48471 48573 48878 48904 48936 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-" 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.) ! IPL Tech Static analysis: code complexity and size metrics Cantata++ Studio 38 T W a te Checks for all standard and 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 ! Eggplant ! 49 + 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
Ö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 !
Bottom-up 11 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 állapotkontextussal 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 H Throws BoundedStack::underflow construction pop() empty push() pop() destruction pop() partially full destruction H push() push() pop() Throws BoundedStack::overflow destruction full push() Figure 6: State transition diagram for BoundedStack We can use the
additional information provided in the state transition design a test set which thoroughly exercises the BoundedStack class. 4.4 empty stack.push(1); // push() when partially-full try { stack.push(9); } // push() when full catch (BoundedStack::overflow) { } // expected to throw stack.pop(); // pop() when full stack.pop(); // pop() when partially-full try { stack.pop(); } // pop() when empty catch (BoundedStack::underflow) { } // expected to throw BoundedStack stack2(3); stack2.push(6); // stack2 is partially-full BoundedStack stack3(1); stack3.push(6); // stack3 is full // destructors called implicitly at end of block for diagram to // stack (empty), stack2 (partially-full) and stack3 (full) }; 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 ! Tesztel! ! 29 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 ! Fejlesztési 31 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 512 512 512 512 512 512 516 517 512 512 512 512 512 512 860 861 863 864 864 866 867 867 867 867 867 869 885 897 903 753 753 753 753 752 752 752 752 752 752 752 750 742 740 739 47843 47869 47964 47990 48016 48065 48114 48277 48371 48471 48573 48878 48904 48936 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-" 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.) ! IPL Tech Static analysis: code complexity and size metrics Cantata++ Studio 38 T W a te Checks for all standard and 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 ! Eggplant ! 49 + 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
Jellemzően a vállalkozás beindítása előtt elkészített tanulmány, de készülhet már meglévő vállalkozás esetében is. Az üzleti tervezés egy olyan tervezési módszer, amely keretet a cég céljainak eléréséhez. Írásunk módszertani útmutatóként szolgál azoknak, akik érdeklődnek az üzleti tervezés iránt.
