A4B33SI, Automatizace testování - labe.felk.cvut.czlabe.felk.cvut.cz/~marikr/teaching/A4B33SI_10/Handouts/11.automatizace...Opakovan e pou zit : testovac metodika by nem ela b yt

A4B33SI, Automatizace testovanı

Radek Marık

CVUT FEL, K13133

November 28, 2010

Radek Marık ([email protected]) A4B33SI, Automatizace testovanı November 28, 2010 1 / 55

Obsah1 Motivace

Stav a cıle2 Pojem automatizace

Obecna definice a jejı interpretace3 Automatizace testovanı softwaru

Proc (ne)automatizovat?Prakticka resenı

4 Automatizace navrhu testuZakladnı principyNahodne testovanı - opice

5 Zaklady testovanı jednotekPrincipyArchitektura

6 Nastroje pro testovanı jednotekObecneJUnit 3.8JUnit 4.5


Motivace Stav a cıle

Proces vyvoje a proces testovanı

Trendy

Komplexita softwaru prekotne stoupa.

Jednoducha modifikace implementacesoftware muze zpusobit velke mnozstvızmen v testovacıch skriptech.

Nastroje

Vyvojari pouzıvajı pokrocile techniky jako pruvodce, CASE nastroje.Testeri kodujı kazdou radku manualne.

Pouzitı abstrakce

Software pouzıva abstraktnı metody, aby pokryl velke mnozstvı prıpadu.Testware se musı implementovat kazdy prıpad zvlast.



Pozadovane zakladnı vlastnosti procesu testovanı

Zada se, stezuje se na, diskutuje se, ...

Opakovane pouzitı: testovacı metodika by nemela byt vyvıjenapouze pro jediny projekt.

Flexibilita: vyjadrenı novych konceptu, navrhovych sablon.

Adaptivita: male modifikace v implementaci softwaru by mely bytpokryty automatizovane.

Komplexita: pokrytı dostatecne casti testovacıch prıpadu je casto zamoznostmi manualnı prıpravy.



Pozadovane odvozene vlastnosti procesu testovanı

Potrebne pro rızenı projektu

Udrzba: potrebne usilı je

neprımo umerne flexibilite a adaptivite,prımo umerne komplexite testovaneho produktu.

Prezentace stavu: dokumentace pravidelne obnovovana, napr.WWW stranky.

Nastroje: integrovana resenı adresujıcı vyse uvedene polozky.

Cena/cas: efektivnost vyjadrena pomocı vyse uvedenych polozek.

Proveditelnost: trh/cena/cas/zdroje/kvalita efektivnost.

Nepretrzity beh: rychla odezva, nekolik fazı (zahorovacı, . . . ,regresnı, dokumentace pravidelne obnovovana, napr. WWW stranky.


Pojem automatizace Obecna definice a jejı interpretace

Co je to automatizace?

Automatizace

je proces, pri kterem se prirazujıstrojum ci systemum aktivity, kterevykonavali jeste donedavna lide.

Zakladnı stavebnı bloky

formalnı modely,

zpetna vazba,

programovanı.


Pojem automatizace Obecna definice a jejı interpretace

Urovne automatizace


Automatizace testovanı softwaru Proc (ne)automatizovat?

Automatizace testovanı ?

Vyhody

1 Beh regresnıch testu na nove verzi programu.2 Castejsı testovanı.3 Provedenı testu, ktery by jinak bylo obtızne provest.4 Lepsı vyuzitı prostredku.5 Konzistence opakovatelnosti testu.6 Vıcenasobne pouzitı testu.7 Zkracenı doby uvedenı na trh.

Problemy

1 Nerealna ocekavanı.2 Slaba testovacı praxe.3 Ocekavanı, ze automatizovany test nalezne mnoho novych defektu.4 Udrzba automatizovanych testu.



Porovnanı postupu

Vlastnost Manualnı Automatizovany Automatizovanytestovanı beh navrh

Cena Nızka Vyssı Velmi vysokaprıpravy (omezeny Nızkatestovacı sady rozsah) (existujıcı resenı)

Kombinatoricke Neschopne Velmi omezene Rızenepokrytı

Flexibilita Vysoka (lide) Zanedbatelna Vysokaa adaptivita (prejmenovanı)

Cena behu Vysoka Nızka NızkaVstupy Vagnı Vagnı Modely softwaruDetekcnı Vysoka Nızka Strednıschopnost



Charakteristiky manualnıho testovanı

Vysoce flexibilnı a adaptivnı (lide)

Vysoka detekcnı rychlost defektu

Lide jsou schopni ovladat software a vyhledavat chyby i za situace, kdysoftware je ve velmi spatnem stavu.Pouzitı objevneho testovanı (exploratory testing) behem pocatecnıchvyvojovych fazı.



Charakteristiky automatizovaneho behu

Nızka cena opakovanych behu.

Obtızna udrzba testovacıch skriptu:

Strukturalnı zmeny znamenajı plnohodnotnou manualne vedenoureimplementaci skriptu.Soucasne komercnı nastroje umoznujı pouze prejmenovavanı polozek spoloautomatizovanou detekcı.



Problem udrzby



Usilı vyvoje



Testovanı kontra Verifikace

Testovanı softwaru

Neformalnı/formalnı oraculus pro validaci skutecnych vysledku.

Rızene vzorkovanı chovanı softwaru za ucelem snızenıpravdepodobnosti selhanı softwaru ci mıry nespokojenostizakaznıka.

Verifikace softwaru

Zalozena na formalnıch modelech softwaru.

Matematicky dukaz, ze model softwaru je spravny.

Pouze omezena mnozina pouzitelnych technologiı:

Vnoreny software zalozeny na konecnych automatech.Verifikace protokolu.


Automatizace testovanı softwaru Prakticka resenı

Automatizace provedenı testu - vseobecne

propagovana komercnımi vyrobci,

pouzıvana v praxi, zvlaste pro regresnı testy,

velmi citliva na zmeny specifikacıa implementace softwaru,

testovanı rızene tabulkami(funkce, hodnoty parametru)testovanı rızene daty(sablony skriptu, hodnoty promennych)mapy grafickych rozhrannı(fyzicke adresy - logicka jmena)

dobra vazba na navazujıcı podporu

sprava logu,hlasenı problemu.



Automatizace provedenı testu - nastroje

Komercnı automatizacnı nastroje

2 operacnı faze:1 programovanı pomocı simulace behu2 automaticke testovanı

IBM Rational Robot,

IBM Functional Tester,

Mercury WinRunner, HP QTP

Compuware TestPartner.

Automatizacnı ovladace na urovni komponent

Expect, nUnit, jUnit, pyUnit, JavaTest, PyTest, ParaSoft,Rational Robot & Quality Architect

sablony testu

dosazovanı parametru podle kombinacnıch tabulek



Automatizace navrhu testu - pohled manazera

Kratsı perioda vyvoje softwaroveho produktu.

Vyssı spolehlivost

Standardizovana rozhrannı softwaru

Redukce ceny vyvoje testwaru vzhledem k moznostem opakovanehopouzitı.

Moznost jasnejsıch formalizovanych specifikacı komponent softwaru.

Zmensenı zateze testeru-lidı, ktere by jinak museli vyvinout obrovskemnozstvı testu pro slozite softwarove aplikace a stradat jejichudrzbou.

OO: dedicnost, polymorfizmus trıd kombinovany s asociacemi,GUI: ”tahni a pust” akce s ruznymi zdroji a cıli,GUI: spousta formularu generovanych podle modelu.



Automatizace navrhu testu - pohled testera

Proc?

prıprava velkeho mnozstvı testu:

OO testing

102 trıd,

103 relacı,

101 vlastnostı nebo metod,

105 a 106 testu.

GUI testing

102 formularu,

102 prechodu,

101 atributu nebo akcı,

104 a 106 testu.

modifikace skriptu pri zmenach softwarove

specifikace, neboimplementace (GUI).

pomerne vysoke naklady

technologie nedospela do plne rozvinute komercnı faze.


Automatizace navrhu testu Zakladnı principy

Automatizovany navrh testu - postup

1 volba testovacı strategie - testovacı katalog,

2 urcenı testovacıho prıpadu,3 doplnenı na testovacı specifikaci:

1 vytvorenı nezbytneho prostredı pro testovany objekt,2 uvedenı objektu do pozadovaneho stavu,3 provedenı testu,4 uvedenı testovane komponenty do puvodnıho stavu,

4 transformace testovacı specifikace do sekvence,

5 urcenı ocekavanych vysledku,

6 kompilace kodu testovacıho skriptu,

7 vytvorenı doprovodne dokumentace.


Automatizace navrhu testu Zakladnı principy

Formalnı specifikace softwaru - testovacı modely

manualnı vstup,

plna specifikace byva narocnejsı nez prıme kodovanı,zatım nezbytne pro modely chovanı,

analyza vhodnych modelu a dat softwaru,

UML, IDL, SQL, XML,analyza textovych specifikacı ve vhodnem formatu,

rekonstrukce pomocı reverznıho inzenyrstvı a validace modelu,

COM rozhranı vlastnostı objektu,deterministicke konecne automaty,

problemy se skrytymi stavy,problemy s kombinatorickou explozı stavu jednoduchych automatu,

formalnı metody [Jac97, WD96],

aplikace logiky a jednoduche matematiky na programovanı,zapis formalnıho popisu programu,uzıvany pro modelovanı, navrh a verifikaci dokazovanım.


Automatizace navrhu testu Nahodne testovanı - opice

Metoda pokusne opice

Myslenka

Pokud milion opic bude po milion letnahodne ”busit” do klavesnice,mohly by statisticky nakonec napsatnejakou Shakespearovu hru ciJiraskovo Temno.

Hloupa opice

Nevı o testovanem softwaru vubec nic.

Jednoducha implementaceRANDOMIZE TIMERFOR i=1 TO 10000PLAY ”{CLICK ” + STR$(INT(RND+640)) + ”. ” + STR$(INT(RND*480)) + ” }”PLAY CHR$(RND*256)

NEXT i



Chovanı opic a typy aplikacı

Hierarchie Sıt



Zvysenı inteligence opice

zaznamy do protokolu,

zamerenı akce na konkretnı aplikaci,

detekce, kde se opice nachazı,

co na tomto mıste muze udelat,

kam muze prejıt,

kde jiz byla,

jestli to, co vidı, opravdu spravne,

prectenı (zjistenı) mapy stavu a prechodu daneho softwaru



Hranice metody pokusne opice


Zaklady testovanı jednotek Principy

Terminologie

System X

Component D

Component C

Component B Component A

Unit 2

Unit 5

Unit 11

Unit 6

Unit 3

Unit 10

Unit 4

Unit 9

Unit 1 Unit 7

Unit 12

Unit 8

Jednotka je nejmensı testovatelny kus softwaru. Znamena to, ze muzebyt prelozen, sestaven, spusten a rızen testovacımprıpravkem nebo radicem.

proceduralnı programovanı: program, funkce,procedura.objektove-orientovane programovanı: trıda

Komponenta, Modul je integrovany agregat jedne a vıce jednotek.



Cıl

Cılem je

izolovanı kazde casti programu,prokazanı, ze jednotlive individualnı casti jsou spravne.otestovanı dane individualnı metody v izolaci.

Kazdy testovacı prıpad je nezavisly na ostatnıch.

Testy zamerujıcı se na chovanı jine nez urcene signaturou metodynejsou povazovany za jednotkove.

Kazdy test urcuje striktnı explicitne popsany kontrakt, ktery dany kodmusı splnit.

Eliminace interakcı mezi jednotkami umoznuje jejich testovanı zapodmınek, ze potrebne dalsı jednotky nejsou jeste implementovany.



Strategie

Testovanı jednotek typicky provadı vyvojari.

Testovanı jednotek je zakladnım pilırem extremnıho programovanı(XP).

Automatizovane, opakovatelne, a proaktivnı testovanı.

Vyvoj rızeny testyPokud napısete nejprve testy, pak se hned z pocatku ztotoznujete s rolızakaznıka.”Zakaznık ma vzdy pravdu” - prioritnı pohled zakaznıka.



Typicka pravidla

1 Napis nejprve test, ktery je mozne prelozit (ale ne vıce).vede k testovatelnemu kodu,vede k cılove-orientovane implementaci kodu,

2 Nikdy nepis test, ktery je bezprostredne uspesny po jeho napsanı.kazdy test by mel overovat novou, jeste neimplementovanou vlastnost,overenı spravnosti testu reakcı na implementovanou vlastnost,

3 Zacni s prazdnym prıpadem, ci s necım, co nepracuje.4 Neboj se neceho, co vede na trivialnı veci, ktere splnı test.

testy, ktere overujı hranicnı jednoduche hranicnı podmınky5 Eliminace interakcı podporuje testovatelnost.

vede na udrzovatelny kod, se kterym je mozne pracovat i za podmınek,ze okolnı casti kodu chybı,

6 Pouzıvej imitacnıch objektu.poskytujı jasny pohled na prubeh interakcı mezi komponentami.

7 Chodıcı testy se neodstranujı, tj. jsou spojeny s implementovanoufunkcionalitou.



Vyhody I

Umoznuje zmeny implementace

kontroluje stabilitu funkcionality pri refaktorovanı kodu,jednotkove testy odrazı zamyslene pouzitı kodu,dobry navrh pokryva vsechny pouzitelne cesty.

Zesiluje separaci rozhranı od implementace

Zamerenı pouze na jednotku vyzaduje minimalizaci interakce jednotky sokolım.Prıpadna rozhranı jsou explicitne definovana, aby bylo mozne prostredıjednotky vytvorit pomocı nahrad.Nalezenı a eliminovanı nadbytecnych zavislostı mezi jednotkami.



Vyhody II

Zjednodusuje integraci

pri navrhu a implementaci zdola-nahoru zjednodusuje integracnı testy.

Poskytuje ”zivou” dokumentaci

vyvojar muze vycıst funkcionality z testovacıho kodu,umoznuje porozumenı API jednotky,identifikuje jak

positivnı chovanı, tj. cılenou funkcionalitu,tak negativnı chovanı, napr. pri nevhodnych parametrech ci zpracovanıvyjimek

na rozdıl od bezne dokumentace se vyvıjı soucasne s implementacıkodu.

Chovanı identifikovane testy podporuje lepsı komunikaci s ostatnımiprogramatory

chovanı a jeho protokoly jsou explicitne zachyceny,pri zadostech o zmeny selhavajıcı testy ihned identifikujı problemy,eliminuje prıpady pouzitı s vedlejsımi skrytymi ucinky,



Nevyhody, Omezenı

Nechytı vsechny chyby programu.

Testuje pouze funkcionalitu jednotek. Nenalezne chyby

integracnı,vykonostnı,systemove.

Jako vsechny ostatnı formy testovanı

muze pouze ukazat prıtomnost chyb,ale nemuze prokazat jejich absenci.

K identifikaci prıcin chyb je nutne podporit systemem rızenı zmen.


Zaklady testovanı jednotek Architektura

Testovacı prostredı

angl. unit testing framework,

je software zajistujıcı testovanı jednotek,

spoustenı celych sad testu, prıpadne vybranych castı,spustenı vybraneho testu.

vytvarı promenlive podmınky testu,

monitoruje chovanı jednotek a jejich vystupu,

prubezne sledovanı behu testu,generovanı reportu

umoznuje analyzu vysledku,

sklada se z exekucnıho modulu a sady testovacıch scriptu



Koncepty

Prıslusenstvı (angl. fixture) - sada objektu, ktere jsou testovany.

Testovacı prıpad (angl. test case)

trıda, ktera definuje prıslusenstvı pro radu testu,definuje promennou pro kazdou polozku prıslusenstvı,zarucuje vytvorenı a likvidaci prıslusenstvı.

Nastavenı (angl. setup) - metoda pouzita pro inicializaci promennychpred kazdym testem ci sadou testu.

Uklid (angl. tearDown) - metoda pro uvolnenı zdroju alokovanychnastavenım.

Testovacı sada (angl. test suite) - soubor testovacıch prıpadu.



Resenı chybejıcıch jednotek

Nahrada (angl. test double) - obecny pojem pouzity pro jakykolivobjekt, jehoz ucelem je dorucit funkcionalitu realnehoobjektu pro ucely testovanı.

Prazdny object (angl. dummy object) - objekt se predava, typicky jakoparametr, ale nenı de facto pouzit.

Padelek (angl. fake object) - plna funkcionalita radne implementaci,typicky nevhodna pro nasazenı v realne aplikaci,

nahrazenı realne databaze jednoduchou databazi vpameti.

Imitator (angl. mock object) - objekty plnı prıpadne kontrolujıvybranou specifikaci jejich volanı,

typicky specifikujı sekvenci volanı, tj. verifikujı chovanı

Zastupce (angl. stub) - je schopen dodat odpovedi v omezenychprıpadech cılenych jednotlivymi testy, tj. verifikuje stav.

mohou zaznamenavat i prubeh volanı.


Nastroje pro testovanı jednotek Obecne

Prehled prostredı - vybrane prıklady

SmalltalkKent Beck publikoval myslenku prostredı pro testovanı jednotek v roce1998. Tato myslenka a navrzeny protokol byl pak prevzat aimplementovan radou dalsıch (102) programovacıch prostredı.SUnit

JavaTestNGJUnit

PythonPyUnit

C++CppUnitCxxUnit

.NETNUnitVisual Studio Team Edition

DelphiDUnit


Nastroje pro testovanı jednotek Obecne

JUnit

http://www.junit.org

jednotkove testovanı pro jazyk Java

podpora vyvojovymi prostredky

Ant,Maven,NetBeansEclipse.

JUnit 3.8lokalizace testu zalozena na

dedicnosti trıd,reflexi,konvenci jmen.

JUnit 4.x, nynı 4.8zalozen na vlastnostech Java 5

anotacestaticky import


Nastroje pro testovanı jednotek JUnit 3.8

Architektura JUnit 3.8

Prıkazova sablona pro definici testu

TestCase je prıkazovy objekt, ktery obsahuje implementace testovacıchmetodtestXXX() definuje testovacı metodu (zacına ”test”),assert() metodu a radu jejıch variant lze pouzıt pro porovnanıocekavanych a aktualnıch vysledku.setUp() a tearDown() metody inicializujı a rusı spolecne objektuprıslusenstvı pro kazdou testovacı metodu zvlast.

Kompozicnı sablona pro vytvorenı hierarchie testu

TestSuite definuje hierarchii testu,vytvarenı testu obvykle automatizovano uzitım reflexe a konvencı jmen,postupy se velmi lisı,

Beh testu

Textove rozhranı: java junit.textui.TestRunner junit.samples.AllTestsGraficke rozhranı: java junit.swingui.TestRunnerjunit.samples.AllTests



JUnit 3.8 prıklad: testovacı metody

import junit.framework.TestCase;

public class AdditionTest extends TestCase {

private int x = 1;

private int y = 1;

@Override protected void setUp() {

y = 2;}

public void testAddition() {

int z = x + y;

assertEquals(3, z);}

protected void tearDown() {

System.gc();}

......

}Radek Marık ([email protected]) A4B33SI, Automatizace testovanı November 28, 2010 48 / 55


JUnit 3.8 prıklad: testovacı sada

import junit.framework.*;

public class AdditionTest extends TestCase {

.......

public static Test suite(){

return new TestSuite(AdditionTest.class);

}

public static void main(java.lang.String[] argList){

junit.textui.TestRunner.run(suite());

}

}




Prıkazova sablona pro definici testu

testovacı trıda se neodvozuje z TestCase,assert() metodu a jejı varianty lze pouzıt podobne jako v JUnit 3.8.@Test dekorace definuje testovacı metodu,@Before dekorace oznacuje metody inicializujı spolecne objektuprıslusenstvı pro kazdou testovacı metodu zvlast.@After dekorace oznacuje metody rusıcı spolecne objektu prıslusenstvıpo kazde testovacı metode.@BeforeClass dekorace oznacuje verejne staticke metody bezıcı predtrıdou.@AfterClass dekorace oznacuje verejne staticke metody bezıcı po trıde.@Ignore dekorace oznacuje ignorovany test.




Kompozicnı sablona pro vytvorenı hierarchie testu

@RunWith(Suite.class) dekorace specifikuje trıdu testovacı sady@SuiteClasses(TestA.class, TestB.class) dekorace specifikuje trıdy testupatrıcı do prıslusne sady

Beh testu

prıma podpora v IDE nebo antlze pouzıt podpory vytvorene v JUnit 3.8 pomocı adapteru



JUnit 4.5 prıklad: testovacı metody

import org.junit.*;

import static org.junit.Assert.*;

public class AdditionTest {

private int x = 1;

private int y = 1;

@Before public void setUp() {

y = 2;}

@Test public void testAddition() {

int z = x + y;

assertEquals(3, z);}

@After public void tearDown() {

System.gc();}

......

}Radek Marık ([email protected]) A4B33SI, Automatizace testovanı November 28, 2010 53 / 55


JUnit 4.5 prıklad: testovacı sada

import junit.framework.JUnit4TestAdapter; //from 3.8

public class AdditionTest {

.......

public static junit.framework.Test suite() {

return new JUnit4TestAdapter(AdditionTest.class);

}

public static void main(java.lang.String[] argList){

junit.textui.TestRunner.run(suite());

}

}



Literatura I

Jonathan Jacky.

The Way of Z: Practical Programming with Formal Methods.Cambridge University, 1997.

Jim Woodcock and Jim Davies.

Using Z: Specification, Refinement, and Proof.Prentice Hall, 1996.


Documents

A4B33SI, Automatizace testování - labe.felk.cvut.czlabe.felk.cvut.cz/~marikr/teaching/A4B33SI_10/Handouts/11.automatizace...Opakovan e pou zit : testovac metodika by nem ela b yt