Návrh snadno testovatelného software

Návrh snadno testovatelného software

2007

Návrh snadno testovatelného software LaTes 07

Štěpán P. Nadrchal www.pdqm.cz [email protected]

Základní otázky Cíl prezentace

1. Kdo má vliv na to, jestli software půjde testovat a kolik to dá práce? 2. Co udělat pro to, aby testování bylo Manage work without work

co nejjednodušší a přitom zůstalo kvalitní?

2

Program

1. Představení 2. Kdy je třeba začít myslet na testování 3. Co všechno má vliv na možnosti testování

Manage work without work

4. Jak testovat efektivně

3

(c) 2007, PDQM; LaTes 07

1


PDQM – Kvalitní řízení procesů a dat Představení

–Cílem společnosti PDQM je podpora: • Využití procesů organizace pro zlepšování efektivity práce • Zavádění a zlepšování řízení kvality projektů (zejména kvality software) – podpora procesu vývoje


– zajištění kvality v rámci projektů nákupu a realizace – metodická podpora řízení projektů

• Podpora zlepšování interního fungování organizace • Kvalita software –www.pdqm.cz

4

Štěpán P. Nadrchal, Ph.D Představení

–Konzultace v oblasti zajištění kvality SW aplikací –Podpora řízení a kontrola kvality na softwarových projektech –Vědecká specializace • Spolehlivost a bezpečnost real-time systémů Manage work without work

–Profesní specializace • Optimalizace firemních procesů a projektů • Školení v oblasti kvality procesů, jejich zlepšování a implementace metodologie CMMI (T-Mobile, CN Resource Technologies, GMC,…)

5

Kdy začít myslet na testování Dřív než na cokoli jiného…


2


Testování začíná, když

A) Zjistí se, že software obsahuje chybu B) Je hotová aplikace


C) Zákazník se shání po předávacím protokolu D) Zákazník se na předávací testy ptá E) Přijde poptávka

7


Přijde poptávka… –Jsme schopni systém vyvinout? • Umíme porozumět tomu, co zákazník chce? –Jsme schopni dodat? –Jsme schopni ověřit, že dodáváme, co zákazník skutečně chce? • Umíme vytvořit takové podmínky, abychom ověřili, že náš produkt je tím, co zákazník potřebuje? • Máme kapacity a schopnosti na testování? • Umíme spočítat a ocenit, kolik bude ověřování stát? • Umíme definovat požadavky, které potřebujeme splnit, abychom byli schopni systém testovat?

8


… a následuje smlouva –Zpřesňujeme požadavky (funkční i technologické) –Pracujeme na detailech architektury –Vybíráme technologie –Sestavujeme tým –Sestavujeme plán projektu • Definujeme projektové činnosti a kroky • Obsazujeme projektové role • Stanovujeme odpovědnosti a plán úkolů • Odhadujeme celkové nároky na zdroje

9


3


Požadavky

Ideální způsob verifikace požadavků: Navrhněte, jak je otestujete


–Ověříme, že požadavku korektně rozumíme (verifikace požadavků) –Ujasníme si, co bude testování znamenat –Můžeme využít pro akceptační testy

10

Odpověď č. 1a


Kdo má vliv na to, jestli software půjde testovat? • Business Analytici • Management projektu Poučení • Zapojte zkušené testery do projektu hned od začátku

11


Architektura a technologie – Zvolená globální architektura má zásadní vliv na způsob testování a požadované schopnosti a nástroje • Testování distribuovaných, klient/server nebo terminálových aplikací se zásadně liší • Implementace midleware vyžaduje znalosti platformy i od testerů • Různé druhy rozhraní se testují různě (Corba, SOAP, FTP, DCOM,…) – Interní architektura je podstatná: • Objektové knihovny nebo atomizované moduly s API • Funkčnost definovaná daty • Real-Time moduly • Paralelismus • Load-balancing

12


4


Jak testovat efektivně aneb jak udělat co nejvíce muziky za co nejméně peněz


Efektivní nástroje pro testování – Objektové knihovny • vyvíjet vždy společně s testy (xUnit) – nechte xUnity vyvíjet testery • Podporovat testovací mód umožňující sledovat interní chování – Vytvořit testovací (ATI) rozhraní umožňuje přímo volat interní funkce – Víceúrovňový log – Paralelní systémy • vybavit logováním umožňujícím kontrolovat synchronizace činností • Nikdy netestovat jak black-box ale naopak se zaměřit na testování oblastí, které jsou kritické – Distribuované systémy • Podpora globálního logu • Podpora sledování dostupnosti modulů – Pro každý modul (externí i interní) vyvinout stub

14


Více úrovní testování –Nenechávat unit testy na programátory • Není dokumentované • Není ohlídatelné • Není objektivní –Je dobré společně plánovat jednotlivé úrovně testů (unit testy, funkční, integrační, testy rozhraní) • Společným plánováním testů se ušetří redundance (často úspora až 50% objemu práce) • Pro každý typ kontroly se vybere nejvhodnější úroveň • Zajistí se lepší pokrytí celku

15


5


Co je dobré pro pána není dobré pro kmána –Různé části aplikace je třeba testovat různě • Každá unita má specifická rizika, různá pro spolehlivost, dostupnost, přesnost • Potřeba testování se mění i podle původu testované jednotky


– Jinak testuji funkčnost obsaženou v koupeném balíku s 1000 instalacemi a jinak v nově vyvinutém řešení – Různou míru kontroly uplatňuji na moduly vyvinuté týmy s různou úrovní zralosti interních procesů

16

Odpověď č. 1b


Kdo/Co má vliv na to, kolik dá testování práce? • Architekti • Úzká spolupráce mezi testovacím a vývojovým týmem Poučení • Využívejte pokud možno interní testery • Postavte testery na roveň ostatním profesím

17

Nebojte se metrik –Metriky pomáhají plánovat testy, sledovat jejich průběh i je včas ukončit 140

120

100


Srovnání reality s modelem 80

# bug in test R-Curve S-Curve density

fmax = 6.5 K = 1000

60

40

20

0 1

2

3

4

5

6

7

8

9 10 11 12 13 14 15 16 17 18

18


6


Příklad - data


Wee k o f te s ting

19

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

# bug in tes t Dens ity 18 22 32 58 103 89 87 117 51 44 20 28 16 47

33,01 62,78 86,60 102,66 110,33 110,08 103,24 91,73 77,57 62,66 48,45 35,92 25,58 17,51 11,53 7,31 4,46 2,63 1,49 0,81 0,43 0,22 0,11 0,05 0,02

(s urrenes ) R 2 =

0,75

R - c urve C - curve numbe r o f c urve × re ality S-Curve S -to tal defec ts fo und var. de ns ity dis tributio n (%) 16,65 1,66% 1,50% 15,76 15,76 64,94 6,49% 4,08% 42,56 58,32 140,22 14,02% 5,46% 62,20 120,52 235,54 23,55% 4,47% 75,13 195,66 342,73 34,27% 0,73% 82,18 277,84 453,55 45,35% 2,11% 84,38 362,22 560,68 56,07% 1,62% 82,82 445,04 658,47 65,85% 2,53% 78,54 523,59 743,26 74,33% 2,66% 72,45 596,04 813,37 81,34% 1,87% 65,31 661,35 868,81 86,88% 2,84% 57,73 719,08 910,83 91,08% 0,79% 50,17 769,25 941,39 94,14% 0,96% 42,94 812,19 962,75 96,28% 2,95% 36,26 848,45 977,11 97,71% 30,25 878,70 986,39 98,64% 24,95 903,66 992,18 99,22% 20,37 924,03 995,66 99,57% 16,48 940,51 997,67 99,77% 13,21 953,72 998,79 99,88% 10,50 964,22 999,39 99,94% Fo rcas t 8,28 972,51 999,70 99,97% 6,49 978,99 999,86 99,99% 5,04 984,04 999,94 99,99% 3,90 987,94 999,97 100,00% 2,99 990,93

Dis tributio n

Poučení


–Bez metrik nikdy nejsme schopni říct, co je vhodná úroveň testování a kdy je možné testování ukončit • Statické metriky pomohou předem odhadnout objem testovacích prací • Vyhodnocování složitosti modulů pomůže zvolit vhodnou úroveň testování pro moduly • Dynamické metriky včas ukáží na problémy při testování Found In Environment 100%

Počet z Unit

80%

60%

40%

20%

20

0% 1

2

3

4

5

6

7

8

9

Week

10

11

12

13

AR client Balance Management BCM BE Billing blade7 C CDR CE CM CM Adapter CRM Cust Ed. CV CV, Pro data Invoice Invoice in PDF format JO LRI management console ME OFS OR OR - Pro OR, CV OR, Pro Ordering PC PC - data Pre Pro Prod Cat. Production


Provažte procesy –Změnové řízení musí být konzultováno s testováním • Náročnost testování podobné úpravy se může řádově lišit podle toho, v kterém modulu se změna projeví –Rozvoj aplikace musí sledovat potřeby testerů • Některé funkce (logy, interní jazyk systému apod.) mohou být pro testování kritický a bez spolupráce s testery se na to může zapomenout • Nákup řešení od třetí strany by měl být také posuzování – Je řešení otestovatelné? – Jsem schopni testy modulu provázat s našimi testy?

21


7


Automatizuje s rozumem –Automatizace může testy výrazně zlevnit ale také prodražit Kdy ne:

Kdy ano:

V době rychlého vývoje (kromě využití xUnit)


Opakované regresní testy dlouhodobě užívané a různě upravované aplikace

Produkt, který po dokončení nebude upravován nebo pouze zásadními změnami (např. koupené řešení)

Balík opakovaně dodávaný více zákazníkům (produkt)

–Automatizace je víc než simulace uživatele • Často je efektivnější vyvíjet nezávislé testy společně s aplikací s využitím logů, API a databáze • Automatizované „sanity testy“ kontrolují např. prostřednictvím administrátorských modulů komunikační vrstvy

22


Odpověď č. 2

Co udělat pro to, aby testování bylo co nejjednodušší a přitom zůstalo kvalitní? • Pro každou technologii používejte odpovídající nástroje a postupy • Vychovejte si zkušeného test architekta (nejlépe z analytika vývojového týmu) • Podporujte testování už v návrhu a při vývoji • Používejte metriky před testování, při něm i po něm Poučení • Testování není nudnou popelkou ale kreativní prací

23

Diskuse

Prezentace je k dispozici na adrese


www.pdqm.cz/download/lates07.pdf

24

Děkuji za pozornost, Štěpán P. Nadrchal [email protected]


8

Návrh snadno testovatelného software

Recommend Documents