Testování je nedílná součást výroby SW. To platí od okamžiku, kdy vznikla první řádka programového kódu (a s ní jistě i první bug). Disciplína testování už povýšila na samostatný obor, který zkoumá metody tvorby testů, techniky testování, ale i třeba psychologické aspekty a dopady testování na vztahy v týmech.
V softwarových firmách se testování věnují vyčleněné skupiny odborníků. Testování v takových firmách začíná už v raných fázích projektů.
Testování software lze rozdělit do několika fází
- Plánování testů – harmonogram testů vznikajícího software
- Příprava testovacích scénářů – tvorba konkrétních testů dílčích částí aplikace
- Provedení testů – samotné testování aplikace
Zatímco první dvě fáze představují tvůrčí činnost a mohou být pro autora testů zajímavé, třetí fáze, tedy samotné testování, je opakovaná činnost, která se může testerovi omrzet. Přitom jsou případy, kdy ji lze dobře automatizovat.
Automatický test
Automatický test je test prováděný zcela nebo z části strojově. Je to program prováděný počítačem. Program testu musí někdo vyrobit. Často to musí být programátor, jsou ovšem i specializované nástroje, které umí nahrát činnost uživatele a tu pak opakovaně spouštět a testovat, že se aplikace chová stále stejně. Takové testy umí vyrobit i test analytik bez hlubokých znalostí programování.
Typů automatických testů je celá řada, každý typ se zaměřuje na jinou část aplikace. Zatímco jednotkové testy ověřují funkčnost jednotlivých metod v kódu, automatické zátěžové testy testují výkon celé aplikace nebo její části jako celku.
Automatické testy lze spouštět ad hoc nějakým podnětem ze strany testera nebo lépe rovnou v rámci buildu aplikace. V takovém případě odhalí chybu už programátor a její oprava je rychlá a levná. Spouštění testu v rámci buildu je ovšem možné pouze pro plně automatické testy a nehodí se pro všechny typy testů.
Dále se budeme zabývat příkladem automatického funkčního testu aplikace – testu, kdy ověřujeme konkrétní funkčnost aplikace na úrovni případu užití.
Příklad – Příjem zákaznického hlášení do helpdesk systému firmy
Firma CCA vyvinula systém správy zákaznických hlášení. Do systému hotline firmy nebo rovnou zákazníci zapisují náměty, vady, požadavky (říkáme tomu hlášení) na aplikace, která jim firma dodává.
Každý zápis hlášení má své pravidla, jak probíhá:
- Ke hlášení je přiřazen zákazník (firma a osoba)
- Každé hlášení je k nějaké aplikaci
- Každé hlášení má svého řešitele, který je dán nastavením týmu na aplikaci
- Během životního cyklu řešení hlášení odcházejí mailové notifikace zainteresovaným osobám. Konkrétně při zápisu hlášení odejde notifikace:
o Zákazníkovi
o Vedoucímu projektu
o Řešiteli hlášení
V průběhu řešení hlášení takto odchází desítky notifikací. Tyto notifikace se velmi obtížně testují, přitom chyba systému notifikací může mít závažné následky – zákazníkovi neodejde důležitá zpráva nebo mu jich naopak odejde moc. V krajním případě se program zacyklí a zcela zablokuje schránku zákazníka. Máme tady kandidáta na automatická funkční test.
Jak připravím test
K provedení testu potřebuje tester
- Scénář – postup, jak testovat, včetně očekávaných výstupů
- Testovací data – vhodně zvolená množina dat
- Testovanou aplikaci – ano, bez ní by to nešlo
- Místo, kam zaznamenat výsledek – v horším
případě tester ústně oznámí „je tam chyba oprav to“, v lepším do systému
zaznamená výsledek testu nebo zapíše vady a předá je ro procesu zapracování
Zatímco v případě ručního testu nemusí být testovací scénáře a data vždy dokonalé a mohou spoléhat na erudici testera, v případě automatického testu to tak není. Scénář musí krok za krokem přesně popsat činnost a očekávaný výsledek, množina dat musí být také úplná. V našem příkladu může zjednodušený testovací scénář včetně dat vypadat takto:
|
Testovací scénář:
|
TP_ISZA_HAP_NOTIFIKACE - Automatický test notifikací hlášení
|
|
|
Vytvořil:
|
Petr Přibyl
|
|
|
Dne:
|
23.7.2018
|
|
|
Odpovědný tester:
|
Jan Novák
|
|
|
Cíl testů:
|
Testy
ověřují správnou funkčnost notifikací uživatelů při založení a změnách
hlášení
|
|
|
Pořadí
testu
|
ID testu
|
Název
testu
|
|
1
|
TP001
|
Přijetí
hlášení typu VADA
|
|
2
|
TP002
|
…
|
|
3
|
TP003
|
…
|
Testovací data
|
Data
|
Popis
|
|
Osoba Bivoj
|
Pracovník firmy na pozici softwarového návrháře
Osoba:
ID: BIVOJ
Jméno: Bivoj
Email: bivoj@nasefirma.cz
|
|
Osoba Krok
|
Pracovník firmy na pozici vedoucího projektu
Osoba:
ID: KROK
Jméno: Krok
Email: krok@nasefirma.cz
|
|
Osoba Metoděj
|
Kontaktní osoba zákazníka
Osoba:
ID: METODEJ
Jméno: Metoděj
Email: metodej@zakaznik.cz
|
|
Aplikace RAKETA
|
Aplikace:
Název: Raketa
Vedoucí projektu: KROK
Softwarový návrhář: BIVOJ
Dodavatel: NašeFirma
|
|
Hlášení hl01
|
Hlášení:
Aplikace: RAKETA (Dodavatel NašeFirma)
Typ: VADA
Text hlášení: Příliš žluťoučký kůň úpěl ďábelské ódy
Priorita hlášení: Vysoká
|
Testovací případ TP001 - Přijetí hlášení typu VADA
|
Popis testu:
|
Založí hlášení typu vada
|
||
|
Výchozí podmínky:
|
Je nastavená aplikace RAKETA a jsou nastavení
uživatelé podle dat výše.
|
||
|
Testovací data:
|
Viz kroky testu
|
||
|
Testovací prostředí:
|
Helpdesk_test
|
||
|
Konečný (očekávaný) stav:
|
Bude založené hlášení typu vada, odejdou notifikace
podle popisu v krocích testu
|
||
|
Číslo
kroku
|
Popis
|
Očekávaný
výsledek
|
|
|
1
|
Založ hlášení hl01
|
-
bivoj@nasefirma.cz,
krok@nasefirma.cz
a metodej@zakaznik.cz obdrží notifikaci o založení hlášení
-
V systému je založeno nové hlášení
|
|
Implementace testu
Přestože v našem případě má testovací scénář jediný krok, z pohledu implementace automatického testu představuje řešení několika dílčích úkolů.
Pokud bychom řešili založení hlášení pomocí programu nahráním činnosti uživatele, musel by být scénář košatější:
1. Spusť aplikaci
2. Přihlas se jako XY
3. Spusť stránku AB
4. Založ hlášení hl01
Takový scénář je jistě správný, ovšem za předpokladu, že nahrávací nástroj nemáme, není možný.
V našem případě není předmětem testu zápis hlášení do stránky, ale test notifikací, které při něm odcházejí. Pokud je stránka pracuje přes nějaké backend API, můžeme využít přímo volání tohoto API. Náš příklad používá databázové API, implementace je v jazyce PL/SQL:
hl_01 ccag_hlaseni_api_pkg.data_type;
...
hl_01.v.datum_vzniku
:= sysdate;
hl_01.v.druh_hlaseni
:= 'VADA';
hl_01.v.id_zakaznika
:= 'METODEJ';
hl_01.v.text_hlaseni
:=
'Příliš žluťoučký
kůň úpěl ďábelské ódy';
hl_01.v.system
:= 'RAKETA';
hl_01.v.kod_uzivatele_resi :=
'BIVOJ';
hl_01.v.priorita
:= 'H';
ccag_hlaseni_api_pkg.zaloz_hlaseni(hl_01);
Kontrola odešlých notifikací
Dalším úkolem, který musíme při implementaci testu řešit, je kontrola odchozích notifikací. Samozřejmě bychom mohli napsat mailového klienta například v jazyce Java a podívat se rovnou do cílové schránky, ovšem v našem příkladu takových schránek bude více na různých serverech, nastavení by bylo obtížné a ještě bychom měli pro pořádek po testu maily smazat.
Při takových testech se používá technika takzvaného mockování – použijete náhražku za skutečný SMTP server, která umí maily přijmout, ale dál je neodesílá. Pouze zaznamená do logu nebo na disk, že mail došel a jaké měl vlastnosti. Test potom rovnou na disku nebo v logu zkontroluje, že odešly správné notifikace.
Aby celý test fungoval, je nutné změnit nastavení aplikace, aby jako SMTP server požívala náš mock a po dokončení testu zase nastavit původní hodnoty, aby aplikace fungovala standardním způsobem.
Závěr
Uvedený příklad měl jenom nastínit možnosti běžného automatického funkčního testu. Takto je možné efektivně otestovat velkou část aplikace a testovat ji při každém buildu aplikace. Díky tomu, že náš test používá standardní API aplikace, není tolik náchylný na její změny a vůbec na změny uživatelského rozhraní.
Autor článku: Petr Přibyl
Žádné komentáře:
Okomentovat