A4B33SI, Úvod do testování

A4B33SI, Úvod do testovánı́
Radek Mařı́k
ČVUT FEL, K13133
November 28, 2010
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
1 / 47
Obsah
1
Proč testovat
Studie softwarových projektů
Charakteristika testera
Typické problémy vývoje softwaru
2
Definice testovánı́ softwaru
3
Koncept teorie kvality
Pojem kvality
4
Základnı́ terminologie testovánı́
Softwarová chyba
Úrovně testovánı́
5
Základy návrhu testů
Terminologie návrhu testů
Postupy návrhu testů
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
2 / 47
Proč testovat
Studie softwarových projektů
Studie softwarových projektů
IBM’s Consulting Group, June 1994
průzkum 24 významných společnostı́
[?]
55% softwaru vyvinuto za cenu většı́ než plánovanou,
68% vyvı́jeno delšı́ dobu než predikováno,
88% muselo být podstatně přenavrhnuto.
The Standish Group, 1994
studie 8 380 projektů,
31% softwarových projektů přerušena,
náklady 53% dokončených projektů se pohybujı́ okolo 189%
původnı́ch odhadů,
z těchto 53% pouze 42% obsahuje původnı́ sadu navrhovaných
vlastnostı́ a funkcı́,
pouze 9% z těchto projektů bylo ukončeno v dohodnuté době a ceně.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
4 / 47
Proč testovat
Studie softwarových projektů
Vývoj úspěšnosti projektů (CHAOS)
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
5 / 47
Proč testovat
Studie softwarových projektů
Rozpočty projektů (CHAOS)
200
180
160
140
120
100
80
60
40
20
0
Series1
1994
1996
1998
2000
2002
2004
189
142
69
45
43
43
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
6 / 47
Proč testovat
Poměr vývojář/tester:
Charakteristika testera
[Kit95]
Obecně
minulost: 1 tester, 9 vývojářů,
nové trendy: 2 testeři, 3 vývojáři,
může být 10:1 až 1:10,
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
8 / 47
Proč testovat
Charakteristika testera
Odborný profil dovednostı́ testera
Znalosti
znalost systému či produktu,
znalosti a zkušenosti s programovánı́m
porozuměnı́,
přı́prava podpory,
analytické postupy,
Postupy
orientace na detaily,
schopnost myslet kreativně,
dobrá představivost
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
9 / 47
Proč testovat
Charakteristika testera
Osobnı́ profil dovednostı́ testera
Charakter
trpělivost,
sebe-motivace,
vytrvalost.
Týmová práce
dobré komunikačnı́ dovednosti,
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
10 / 47
Proč testovat
Typické problémy vývoje softwaru
Ariane 5
Situace
Řada motorů na tekuté a tuhé palivo
nahrazena několika s většı́m tahem.
4.června, 1996, 40 s po startu ve výšce
okolo 3700 m se nosič odklonil od své
dráhy, rozlomil a explodoval.
Raketa, nesené 4 satelity nepojištěny,
500 miliónů $.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
12 / 47
Proč testovat
Typické problémy vývoje softwaru
Selhánı́ nosiče Ariane 5
Status testovánı́
Žádost o přetestovánı́ stabilizačnı́ plošiny převzaté z Ariane 4 v
podmı́nkách Ariane 5 byla “vetována CNES z důvodu vysokých
nákladů”.
Sextant Avionique po havárii potvrdila, že by závadu svými testy
detekovala.
Chyba
softwarová vyjı́mka v obou Stabilizačnı́ch referenčnı́ch systémech
(SRI).
nechráněný převod z 64bitového reálného čı́sla na 16bitové celé čı́slo.
SRI má význam pouze před zvednutı́m nosiče, ačkoliv je operativnı́
jestě dalšı́ch 50 s.
přetečenı́ nastalo z důvodu rozdı́lných drah.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
13 / 47
Proč testovat
Typické problémy vývoje softwaru
Shrnutı́ Arian 5
Typické chyby při procesu vývoje softwaru
nedostatek času - veto na testovánı́
malé či chybně rozložené náklady - veto na testovánı́,
chybné nebo chybějı́cı́ požadavky - jak dlouho by měl podsystém
fungovat,
chyby v kódu - nechráněné převody,
opakované využitı́ - změna specifikacı́,
řada chyb vzniká striktnı́m oddělenı́m vývoje softwaru a jeho
testovánı́.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
14 / 47
Proč testovat
Typické problémy vývoje softwaru
Radiačnı́ předávkovánı́
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
15 / 47
Proč testovat
Typické problémy vývoje softwaru
Therac 25
červen 1985 - leden 1987
lineárnı́ urychlovač
použı́vaný v lékařstvı́ k ozařovánı́ rakovinných nádorů,
povrchové tkáně ozařovány elektrony,
pro hlubšı́ tkáně gama zářenı́,
6 incidentů přezářenı́, z toho 3 smrtelné,
20000 rad mı́sto 86 rad,
systém reálného času vytvořený 1 programátorem,
neexistujı́cı́ formálnı́ specifikace a testovacı́ kritéria,
hardwarové zámky nahrazeny programovými,
pokud byla vstupnı́ data změněna mezi 1 až 8 s, pak zářič a
polohovacı́ stůl pracovaly v různých módech,
k nastavovánı́ logické proměnné použita inkrementace bytové
proměnné.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
16 / 47
Proč testovat
Typické problémy vývoje softwaru
Shrnutı́ Therac 25
uživatelské rozhrannı́ kontra bezpečnost,
složitý návrh
systémové testovánı́ nenı́ dostatečné,
chybějı́cı́ specifikace,
typicky problémy systémů:
paralelnı́ch (angl. parallel)
souběžných (angl. concurrency).
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
17 / 47
Proč testovat
Typické problémy vývoje softwaru
Zkušenosti z chyb
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
18 / 47
Proč testovat
Typické problémy vývoje softwaru
Proslulé chyby I
Oběžná dráha Apollo 13: program testován za pomalu měnı́cı́ch se
podmı́nek. Při velké dynamice došlo k vydělenı́ nulou na
netestované cestě.
Mariner let k Venuši: 80 miliónů $,
záměna − za + vedla k odklonu z dráhy,
Minutı́ Merkuru: proměnná Fortranu DO10I
DO 10 I=1.5
DO 10 I=1,5
Selhánı́ rakety Patriot: během Války v zálivu v 1991 kvůli kumulativnı́
chybě v časové synchronizaci
(ve skutečnosti: 0.34 s, 100 hodin; navrženo: 14 hodin),
F16 simulace: letadlo se překlápělo při překročenı́ rovnı́ku,
Návrh jaderné elektrárny: v roce 1979 muselo být 5 jaderných elektráren
uzavřeno z důvodu poddimenzovánı́ potrubı́, velikost vektoru
počı́tána jako součet složek, modul byl napsán studentem na
praxi.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
19 / 47
Proč testovat
Typické problémy vývoje softwaru
Proslulé chyby II
Sonda Marsu Vymazán přistávacı́ modul s cı́lem uvolnit paměť. Modul
navigace antény k Zemi vyžadoval navigačnı́ funkce obsažené
v přistávacı́m modulu.
Selhánı́ regulace sı́ťového systému Kalifornie: 1998
Nezbyl čas na řádné testovánı́ komunikačnı́ho systému.
Vzniklé zpožděnı́ stálo přibližně 90 miliónů $.
Zpožděnı́ otevřenı́ letiště v Denveru: 1995 Chyby v systému řı́zenı́
zavazadel způsobily rozdrcenı́ automatizovaných vozı́ků se
zavazadly o stěny. Letiště bylo otevřeno o 16 měsı́ců později
se ztrátou 3.2 miliardy $ a s manuálnı́m zavazadlovým
systémem. Nedávno podobné problémy na Heathrow.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
20 / 47
Proč testovat
Typické problémy vývoje softwaru
Porucha Pendolina
2005-2006
89 závad za prvnı́ měsı́c provozu,
závady v obslužném software pomocných měničů (topenı́, osvětlenı́),
přı́padná ztráta se pohybovala okolo 43 miliónů euro,
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
21 / 47
Definice testovánı́ softwaru
Testovánı́ softwaru - výchozı́ definice
Hetzel 1973 Testovánı́ je proces určenı́ věrohodnosti, že program či
systém dělá to, co se o něj předpokládá.
Myers 1979 Testovánı́ je proces spouštěnı́ programu či systému s
úmyslem nalézt chyby.
Hetzel 1983 Testovánı́ je jakákoliv aktivita s cı́lem vyhodnotit atribut či
schopnost plněnı́ požadované výsledky programem nebo
systémem.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
22 / 47
Definice testovánı́ softwaru
Testovánı́ softwaru - přehled definic
Testovánı́ je
kontrola programů vzhledem ke specifikacı́m,
nalézánı́ chyb v programech,
určenı́ mı́ry akceptovánı́ uživatelem,
ujištěnı́ se o tom, že systém je připraven k použı́vánı́,
zı́skánı́ důvěry, že program pracuje,
prezentace, že program běžı́ správně,
demonstrace toho, že program je bez chyb,
porozuměnı́ omezenı́ výkonnosti programu,
učenı́ se toho, co systém nenı́ schopen dělat,
hodnocenı́ schopnostı́ programu,
verifikace dokumentace.
Testovánı́
je měřenı́ kvality softwaru.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
23 / 47
Koncept teorie kvality
Pojem kvality
Definice kvality
Rozsah od inženýrských specifikacı́ na úrovni dı́lny až po definice na úrovni
společnosti:
Webster’s New World Dictionary Kvalita je fyzická či jiná charakteristika,
která definuje základnı́ podstatu věci či jednu z jejı́ch
vyznačných vlastnostı́.
Crosby 1979 Kvalita je mı́rou souhlasu s požadavky.
ISO 9000 Kvalita je souhrn vlastnostı́ a charakteristik produktu či
služby, která se týká schopnosti uspokojit určené nebo
vyplývajı́cı́ potřeby.
Taguchi 1986 Kvalita je ztráta, kterou produkt způsobı́ společnosti po
jeho dodánı́, způsobenou funkčnı́mi změnami a škodlivými
účinky mimo těch, které vyplývajı́ z vlastnı́ch funkcı́.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
25 / 47
Koncept teorie kvality
Pojem kvality
Aspekty kvality
operačnı́ podmı́nky - výkonnost v krátkodobém horizontu,
spolehlivost - dlouhodobý horizont,
pohled zákaznı́ka,
IKIWISI - Guaspari:“I Know It When I See It”
[Kit95]
Ideálnı́ kvalita,
kterou zákaznı́k může očekávat, je,
že každý produkt poskytuje cı́lenou výkonnost
kdykoliv je použit,
za všech zamýšlených operačnı́ch podmı́nek,
po celou dobu jeho předpokládaného života,
se žádnými škodlivými postrannı́mi efekty.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
26 / 47
Koncept teorie kvality
Pojem kvality
Kvalita softwaru
Kvalita znamená ”splňovat požadavky zákaznı́ka”:
Faktory:
Funkčnost (externı́ kvalita)
správnost,
spolehlivost,
použitelnost,
integrita.
Inženýrské řešenı́ (vnitřnı́ kvalita)
efektivita,
testovatelnost,
dokumentace,
struktura.
Adaptabilita (budoucı́ kvalita)
flexibilita,
opětné použitı́,
údržba.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
27 / 47
Koncept teorie kvality
Pojem kvality
Koncept kvality
Vztah mezi skutečnou kvalitou produktu pociťovanou zákaznı́kem a
kvalitou měřenou na úrovni produkce:
Factory production processes
Product and process design
Factory test perfomance
Materials and supplies
(Substitute performance)
Components
Factory test load
Product subsystems
Factory test method
Finished product
Factory test environment
Transfer of ownership to customer
Degree of correspondence
Field usage processes
Field performance
(True performance)
Customer product configuration
Field environment
Customer requirements
Field operating method
Field application
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
28 / 47
Základnı́ terminologie testovánı́
Co je to softwarová chyba?
Softwarová chyba
[KFN93]
Softwarová chyba je prezentace toho, že program nedělá něco, co jeho
koncový uživatel předpokládá (Myers, 1976).
Nemůže existovat absolutnı́ definice softwarové chyby ani
absolutnı́ určenı́ jejı́ existence. Mı́ra přı́tomnosti chyb v programech
odpovı́dá mı́ře, podle které program přestává být užitečný. V základu
lidská mı́ra (Beizer, 1984).
ŠPATNĚ: softwarová chyba je nesouhlas mezi programem a jeho
specifikacı́.
Nesouhlas mezi programem a jeho specifikacı́ je chybou pouze tehdy a
jen tehdy, jestliže specifikace existujı́ a jsou správné.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
30 / 47
Základnı́ terminologie testovánı́
Softwarové chyby
Mi s
ta k
Softwarová chyba
[Kit95]
e
Fa
re
ilu
Error
Fault
System
Pochybenı́: Akce člověka, která produkuje nesprávný výsledek.
Vada: Nesprávný krok, proces nebo definice dat v počı́tačovém
programu. Výsledek pochybenı́. Potenciálně vede k selhánı́.
Selhánı́: Nesprávný výsledek. Projev vady.
Chyba: Kvantitativnı́ vyjádřenı́ toho, na kolik je výsledek nesprávný.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
31 / 47
Základnı́ terminologie testovánı́
Chybná vı́ra testerů
Softwarová chyba
[Bei90]
Hypotéza laskavých chyb: chyby jsou krásné, bezduché a logické.
Hypotéza lokality chyb: chyba objevená v
nějaké komponentě ovlivňuje pouze chovánı́ této komponenty.
Dominance chyb v řı́zenı́: chyby v řı́dicı́ch strukturách převládajı́
(vs. chyby v toku dat a datových struktur)
Oddělenı́ kódu a dat: chyby respektujı́ oddělenı́ kódu a dat.
Lingua Salvator Est: syntaxe a sémantika jazyka eliminuje většinu
chyb (vs. prevence).
Opravy přetrvávajı́: opravená chyba zůstává opravena. (A,B
ovlivněné, skutečná chyba je v C)
Univerzálnı́ všelék: X (jazyk, návrhová metoda, atd.) zaručuje
imunitu vůči chybám,
Sadismus postačuje: k vyhlazenı́ většiny chyb. Obtı́žné chyby
vyžadujı́ metodologii a techniky.
Testeři - andělé: tester je lepšı́ při návrhu testů než programátoři při
navrhu kódu.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
32 / 47
Základnı́ terminologie testovánı́
Co lze testovat?
Úrovně testovánı́
[Bei90]
Unit 1
Unit 5
Component A
Unit 2
Unit 3
Unit 7
Component B
Unit 4
Unit 6
Unit 8
Component D
Unit 9
Unit
11
Component C
Unit
10
Unit
12
System X
Jednotka je nejmenšı́ testovatelný kus softwaru. Znamená to, že může
být přeložen, sestaven, spuštěn a řı́zen testovacı́m
přı́pravkem nebo řadičem.
Komponenta je integrovaný agregát jedné a vı́ce jednotek.
Systém je velká komponenta obvykle odpovı́dajı́cı́ celému produktu.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
34 / 47
Základnı́ terminologie testovánı́
Úrovně testovánı́
Úrovně testovánı́
[Bei90]
Testovánı́ jednotek - funkčnı́ a strukturnı́ požadavky na úrovni jednotky,
Testovánı́ komponent - požadavky na úrovni komponenty,
Integračnı́ testovánı́ - za předpokladu funkčnı́ch komponent
testovánı́ kombinace komponent,
Testovánı́ systému - zabývá se problematikou chovánı́, ke kterému
docházı́ v plně integrovaném systému.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
35 / 47
Základnı́ terminologie testovánı́
Typy testovánı́
Úrovně testovánı́
[Het88]
Formálnı́ testovánı́ je proces prováděnı́ testovacı́ch aktivit a hlášenı́
výsledků testů podle odsouhlaseného testovacı́ho plánu.
Akceptačnı́ testovánı́ je formálnı́ testovánı́ prováděného za účelem
stanovit, zda systém splňuje akceptačnı́ kritéria a umožňuje
zákaznı́kovi určit zda přijme systém či nikoliv.
Systémové testovánı́ je proces testovánı́ integrovaného systému za účelem
ověřenı́, zda vyhovuje specifikovaným požadavkům.
Regresnı́ testovánı́ je částečné testovánı́ s cı́lem ověřit, že provedené
modifikace nezpůsobujı́ nechtěné vedlejšı́ efekty nebo že
modifikovaný systém stále splňuje požadavky.
Hodnocenı́ výkonnosti - určenı́ dosaženı́ efektivnosti operativnı́
charakteristiky.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
36 / 47
Základnı́ terminologie testovánı́
Revize
Úrovně testovánı́
[KFN93]
identifikace problémů v návrhu,
okolo 7 lidı́.
Inspekce - formálnı́ hodnotı́cı́ technika zahrnujı́cı́ detailnı́
prozkušovánı́ člověkem či skupinou jiným než autorem.
Inspektoři kontrolujı́ každou řádku návrhu proti
každé položce kontrolnı́ho seznamu.
Demonstrace - inspekčnı́ proces, při kterém návrhář ukazuje ostatnı́m
pomocı́ simulace část návrhu nebo kódu, který napsal.
Technická porada - každý přinese seznam problémů. Účelem schůzky je
vytvořit seznam problémů a zajistit, aby návrháři všemu
rozuměli. Konečná rozhodnutı́ nejsou součástı́ této schůzky.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
37 / 47
Základy návrhu testů
Terminologie návrhu testů
[Het88, KFN93, Bei95]
Vstupy návrhu testů
Requirements
based
tests
Requirements
Design
based
tests
Design
Code
Code
based
tests
Návrh testů
založený na požadavcı́ch . . . z externı́ specifikace,
založený na návrhu . . . z architektury softwaru,
založený na kódu . . . ze zakódované logiky a datových struktur.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
39 / 47
Základy návrhu testů
Návrh testů
Terminologie návrhu testů
[Het88, KFN93, Bei95]
Testovánı́ černé skřı́ňky funkcionálnı́ testovánı́:
strategie testovánı́ chovánı́ založené na požadavcı́ch,
program se chápe jako černá skřı́ňka.
Testovánı́ funkcı́: funkce jsou testovány předloženı́m
vstupů a prověřovánı́m jejich výstupů. Internı́ struktura
programy se uvažuje pouze zřı́dka.
Testovánı́ bı́lé skřı́ňky testovánı́ skleněné skřı́ňky:
strategie testovánı́ struktur odvozených ze struktur
testovaných objektů. Programátor využı́vá znalosti a přı́stup
ke zdrojovému kódu k vývoji testovacı́ch přı́padů.
Strukturálnı́ testovánı́: Hlavnı́ důraz je kladen na
vhodný výběr cest skrz program nebo podprogram,
které se procházejı́ při prováděnı́ sady testů.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
40 / 47
Základy návrhu testů
Terminologie přı́pravy testů
Terminologie návrhu testů
[Het88, Bei90]
Požadavek - podmı́nka nebo schopnost, kterou uživatel potřebuje k
řešenı́ problému nebo vyřešenı́ úlohy.
Specifikace - vyjádřenı́ množiny požadavků, kterým by měl produkt
vyhovět.
Testovacı́ plán - dokument popisujı́cı́ zvolený přı́stup k zamýšleným
testovacı́m aktivitám.
Testovacı́ přı́pad - specifická množina testovacı́ch dat společně s
očekávanými výsledky vztažené k vybranému cı́lu testu.
Návrh testu - výběr a specifikace množiny testovacı́ch přı́padů, které
splňujı́ úlohu testu nebo kritéria pokrytı́.
Dobrý test - nezanedbatelná pravděpodobnost detekce dosud
neobjevené chyby.
Úspěšný test - detekuje dosud neobjevenou chybu.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
41 / 47
Základy návrhu testů
Terminologie testovánı́
Terminologie návrhu testů
[Het88, Kit95]
Testovacı́ data - vstupnı́ data a podmı́nky pro soubory asociované s
daným testovacı́m přı́padem.
Očekávané výsledky - predikované výstupnı́ data a podmı́nky souborů
asociované s daným testovacı́m přı́padem.
Orákulus je jakýkoliv program, proces nebo objem dat, které specifikujı́
očekávaný výsledek množiny testů, pokud jsou aplikovány na
testovaný objekt.
Testovacı́ procedura - dokument definujı́cı́ kroky směřujı́cı́ k pokrytı́
alespoň části testovacı́ho plánu nebo běhu množiny
testovacı́ch přı́padů.
Záznam testu - chronologický záznam všech význačných podrobnostı́
testovacı́ aktivity.
Platnost testu - stupeň, jak dalece test dosahuje specifického cı́le.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
42 / 47
Základy návrhu testů
Prvnı́ kolo testovánı́
1
2
Postupy návrhu testů
[KFN93]
Začni se zřejmým a jednoduchým testem.
Poznamenej si, co dále je potřeba testovat:
Hledej hraničnı́ podmı́nky.
Typicky se chyby nacházejı́ v blı́zkosti hranic.
3
4
Zkontroluj platné přı́pady a pozoruj, co se děje.
Proveď testovánı́ “za letu”.
Vždy si zapisuj, co jsi udělal a co se děje, pokud
provádı́š průzkumné testy.
5
Shrň, co vı́š o programu a jeho problémech:
zpracovánı́ chyb,
datové typy,
skryté hranice.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
44 / 47
Základy návrhu testů
Postupy návrhu testů
Prohlubovánı́ testovacı́ho plánu pomocı́ seznamů
[KFN93]
Seznamy je jednoduché vytvořit, problémem bývá úplnost.
Seznam zpráv a obrazovek vstupů dat.
Seznam vstupnı́ch a výstupnı́ch proměnných.
Seznam vlastnostı́ a funkcı́.
Seznam chybových hlášek.
Seznam souborů programu.
Seznam kompatibilnı́ho hardwaru.
Seznam kompatibilnı́ho softwaru.
Seznam kompatibilı́ch operačnı́ch prostředı́.
Seznam komponent, které nalezne zákaznı́k v krabici.
Seznam veřejných dokumentů.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
45 / 47
Základy návrhu testů
Postupy návrhu testů
Prohlubovánı́ testovacı́ho plánu pomocı́ tabulek
[KFN93]
Tabulky dobře charakterizujı́ vztahu.
Tabulka zpráv.
Tabulka vstupnı́ch a výstupnı́ch proměnných.
Tabulka vztahu vstupů a výstupů.
Rozhodovacı́ tabulky a stromy.
Tabulka kompatibility hardwaru/softwaru.
IF
THEN
Rozlišujı́cı́ kód = 3
Označeno “Odloženo”
Vyřešeno v červnu
Zahrň do červnové zprávy
Zahrň do přehledové zprávy
Radek Mařı́k ([email protected])
Y
Y
Y
Y
Y
YYYNNNN
YNNYYNN
NYNYNYN
NYNYNNN
YYYYYNN
A4B33SI, Úvod do testovánı́
November 28, 2010
46 / 47
Základy návrhu testů
Postupy návrhu testů
Literatura I
Boris Beizer.
Software Testing Techniques.
Van Nostrand Reinhold, New York, 2 edition, 1990.
Boris Beizer.
Black-Box Testing, Techniques for Functional Testing of Software and Systems.
John Wiley & Sons, Inc., New York, 1995.
Bill Hetzel.
The Complete Guide to Software Testing.
John Wiley & Sons, Inc., second edition, 1988.
Cem Kaner, Jack Falk, and Hung Quoc Nguyen.
Testing Computer Software.
International Thomson Computer Press, second edition, 1993.
Edward Kit.
Software Testing in the Real World.
Addison-Wesley, 1995.
Radek Mařı́k ([email protected])
A4B33SI, Úvod do testovánı́
November 28, 2010
47 / 47