pondělí 7. března 2011

Příprava testovacích dat I.

V dnešním článku bych se rád s vámi podělil o zkušenosti při přípravě testovacích dat.

Přípravě testovacích dat by se měla věnovat stejná pečlivost, jako přípravě testovacích scénářů - zejména v případech, kdy je množství dostupných dat omezeno. Nekvalitní data mohou mít za následek reportování problémů, které nejsou ve skutečnosti chybou kódu, ale pouze chybou zvolených testovacích dat - což významně snižuje reputaci týmu testerů.


Před začátkem samotného testování je nutné specifikovat, jaká testovací data budete pro testy potřebovat - například kolik kusů SIM karet, s jakými konkrétními vlastnostmi atd.
Počítejte s rezervou minimálně 3- násobku původních dat - platí pravidlo, čím více dat máte, tím lépe (při zohlednění náročnosti přípravy těchto dat, odhadované chybovosti aplikace a rizika "nekonzistence" dat mezi různými systémy).
Dodatečná "výroba" testovacích dat může být velmi nákladná, případně můžete ztratit všechna data z již spuštěných testů (při "přeplachu" databáze).

Takže když máte v testovacím scenáři, že potřebujete zákazníka s nezaplacenou fakturou za služby a čekáte, že se tam najde chyba a ta se opraví až napodruhé, chtějte těch zákazníků aspoň 3 kusy (1 pro první test, 1 pro první retest a 1 pro druhý retest).

Testovací data je možné do testovacího prostředí dostat v zásadě dvěma způsoby:

  1. jejich vytvořením přímo na testovacím prostředí (ať již manuálně, nebo automatizovaně)
  2. překopírováním dat z produkčního prostředí do testovacího (s případnou anonymizací citlivých údajů)

Dnes se budu věnovat prvnímu způsobu.


Vytvoření testovacích dat na testovacím prostředí

Pokud vytváříte data "manuálně", dodržujte tato pravidla:

1. zachovávejte uvěřitelnost dat - volte třeba jméno zákazníka "Karel Hynek Mácha" místo "Xxxx Zazaza". Čím blíže reálným datům budete, tím je větší šance, že otestujete systém na těch datech, s kterými byl navržen pracovat. Obzvlášť, když výsledek testů posíláte na kontrolu třetí straně (zažil jsem případ, že tester dal jméno zákazníka "Test Test" a při kontrole dokladu na finančním oddělení měli problém rozeznat, co je jméno a co příjmení, jestli se to uložilo do správných kolonek).

2. vyhýbejte se paradoxu pesticidů - nemějte "statickou" množinu dat déle než 2-3 iterace, ale průběžně ji měňte (třeba numerické údaje generujte v požadovaném intervalu generátorem náhodných čísel). Čas od času revidujte celou množinu dat - už jen kvůli novým vlastnostem testované aplikace, které byly v průběhu času přidány a ovlivňují výběr dat.

3. nevytvářejte "nevalidní" data, pokud to není nutné pro účel testu, případně takový záznam nějak "označte", nebo po otestování příslušného testovacího scénáře smažte. 
Důvod - pokud tento záznam nemůže být vytvořen standardní cestou (a vytváříte ho natvrdo přes databázi), tak s tím aplikace nemusí umět pracovat a začnou se množit chyby "aplikace nemůže načíst tento záznam" a tester netuší, že je to způsobeno nevalidním ručně vytvořeným záznamem.
Je to důležité zejména v případě, pokud nemáte "natvrdo" přidělená data k jednotlivým scénářům, ale necháváte na testerovi, aby si vhodná data v systému našel sám.

4. Zálohujte si skripty, kterými jste testovací data vytvořili, případně i vytvořenou množinu dat.
Prostě umožněte znovupoužití těchto dat.


Způsoby přípravy vkládaných dat

1. využití testované aplikace


Nejvhodnějším způsobem "manuální" přípravy dat je využití samotné aplikace, ve které tato data obvykle vznikají. Důvodem je největší pravděpodobnost, že vzniklé datové entity jsou správné a konzistentní. Obzvlášť to doporučuji v případech rozsáhlé integrace - kdy se například založení zákazníka v systému X přenese i do systémů Y a Z.
Není nutné, abyste museli tyto data "klikat" do aplikace ručně, obzvlášť pokud je těchto dat větší množství. Perfektně se pro tento účel hodí skripty pro automatizované funkční testy, nebo zátěžové testy (pokud takové již máte, nebo je stejně budete vytvářet pro automatizované/zátěžové testy aplikace).


2. manipulace s úložištěm

Druhou možností je ovlivňování dat přímo v úložišti - vkládání dat do databáze, souborů... Je to poněkud riskantnější možnost, jelikož musíte velmi dobře znát strukturu "backendu" a současně chování aplikace (například které hodnoty aplikace "akceptuje" z rozsahu databázového typu). Musíte dávat pozor na věci jako jsou primární a cizí klíče, časové konstanty (datum založení zákazníka v různých systémech musí být stejné, například) a další "provázanosti" - a to i napříč různými systémy/databázemi.

Výhodou této možnosti je velmi efektivní použití generátorů testovacích dat - například pro databáze lze použít různé utilitky, co vám ze dvou tabulek udělají kartézský součin, nebo jiným způsobem data "prokombinují mezi sebou". Oblíbené je používání generování testovacích dat na základě regulárních výrazů, pro textové řetězce o stanovené délce vám může pomoci "Lorem Ipsum" generátor.

Já osobně preferuji kombinaci obojího - vytvářím data v aplikaci automatizovaně, přičemž jako vstup dat do automatizačního nástroje používám zmíněné generátory dat.

Příště se budu věnovat přípravě dat nahráním dat z produkčního prostředí (což je velmi oblíbená praktika zejména u velkých společností).

1 komentář:

  1. It is in point of fact a nice and useful piece of information.
    I'm satisfied that you just shared this useful info with us. Please keep us up to date like this. Thank you for sharing.
    http://tinyurl.com/cfxkvdx youtube comments

    Here is my web site youtube likes

    OdpovědětVymazat