}w!"#$%&'()+,-./012345<ya

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY }w!"#$%&'()+,-./012345<ya Tvorba testů a metodika testování aplikačního proxy firewallu BAKALÁŘSKÁ PRÁCE Miroslav Buda Brno, jaro 2010.

2 Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: RNDr. Marek Kumpošt, Ph.D. ii

3 Shrnutí Tématem této bakalářské práce je seznámení se s aplikačním proxy firewallem firmy Trusted Network Solutions, konkrétně s uživatelskou příručkou. Dále pak popis zkušeností spolupráce s externí firmou, vytvoření metodiky tvorby testů pro firewall, tvorbu testů samotných a jejich následné použití před vydáním nové verze firewallu. Bakalářská práce je rozdělena na část teoretickou a praktickou. V teoretické části se věnuji postupům tvorby metodiky a metodám automatického testování. Zatímco v praktické části práce aplikuji metodiku pro tvorbu testů. iii

4 Klíčová slova Aplikační proxy firewall, automatické testování, metodika, moderní značkovací jazyk, XML, XSLT. iv

5 Obsah 1 Úvod Značkovací jazyk XML Rozdělení práce Přínos práce Kernun Specifikace firewallu Systémové prostředí a vzdálený přístup Použitelnost firewallu Hardwarové a softwarové nároky Zařazení firewallu Obecné postupy práce na projektu Zadání projektu Doporučená literatura Komunikace Časový plán Další úskalí Postup tvorby a obsah metodiky testování Shrnutí Využití XML Ukázka XML testu Tvorba DTD XSD testu XSLT transformace Další vývoj Shrnutí Automatické testovaní Výhody automatického testování Rozdělení testovacích nástrojů Základní testovací nástroje Automatické nástroje Možnost nasazení konkrétního softwaru Závěr A Přiložené dokumenty B Přiložené CD Literatura v

6 Kapitola 1 Úvod Součástí vývoje výrobku, at už se jedná o věc hmatatelnou nebo software, je testování. Moderní způsob testování můžeme zařadit do doby industrializace, kdy počet výrobků začal exponenciálně růst. Jejich kvalitu a správnou funkčnost je i nadále potřeba testovat. V této době začaly vznikat metodiky tvorby testů. Doposud, a to žijeme v 21. století, bylo vytvořeno pouze několik desítek dokumentů, které se zabývají touto problematikou [10] [4]. Jejich hledání je často problematické, protože ve většině případů nejsou veřejně dostupné. Metodiku tvorby testů můžeme vytvořit pro každý výrobek, u kterého potřebujeme ověřit, jestli správně funguje. Z velkého množství výrobků jsem si vybral právě software, konkrétně tedy firewall a jeho uživatelskou příručku, jako objekt tvorby metodiky pro tvorbu testů v rámci této bakalářské práce. Vývoj výrobku ale nesestává pouze z jeho testování. Protože jsem část z této bakalářské práce zpracovával jako školní projekt pro externího zadavatele, rád bych v mojí práci zmínil i některé aspekty spolupráce na projektech. Rád bych zdůraznil některé problémy, které jsem při práci na projektu měl a ze kterých by se mohli poučit studenti, kteří se rozhodnou nějaký projekt v rámci studia zpracovat. 1.1 Značkovací jazyk XML V mé bakalářské práci jsem mimo jiné pracoval s technologií XML (Extesible Markup Langue) 1. Tento jazyk je vhodným prostředkem pro zaznamenávání strukturovaných dokumentů sémantického charakteru. Tento jazyk jsem vybral pro jeho snadnou použitelnost, velkou flexibilitu a rozšířenost. O dalších výhodách a postupech použití jazyka se zmíním v práci později. 1.2 Rozdělení práce V druhé kapitole se práce věnuje firewallu, jeho rozhraní a ovládacím prvkům. Poté, stále ještě ve druhé kapitole, se věnuji teoretickým aspektům tvorby metodiky a úskalím zpracování projektů. K tomuto teoretickému výkladu přikládám své osobní zkušenosti. Ve třetí 1. Jedná se o značkovací jazyk umožňující snadnou konverzi formátů a strojové zpracování (více na [3] nebo 1

7 1.3. PŘÍNOS PRÁCE kapitole se věnuji značkovacím jazykům, jako prostředku pro zpracování testovací metodiky. Konkrétně formátům XSLT (extensible Stylesheet Language Transformations) 2 a XSD (XML schema definition) 3. Kapitola čtvrtá obsahuje výčet technologií použitelných pro automatické testování spolu s jejich možným použitím a poslední kapitola obsahuje závěr a shrnutí práce. 1.3 Přínos práce Přínosů mé práce je podle mého názoru hned několik. Mimo přínosu pro mě samotného, jako získání zkušeností s novými technologiemi (XML, firewall a automatizace) a přípravu pro zaměstnání, kde se s podobnými projekty doufám setkám, je zde i přínos pro ostatní studenty, kteří z mé práce mohou získat představu o úskalích práce na projektech, ke kterým se mohou na fakultě přihlásit. Dalším je pak přínos pro firmu TNS (Trusted Network Solutions) 4, pro kterou jsem na základě této metodiky zpracoval testy pro jejich uživatelskou příručku [1], které nyní používají pro její testování. Dále pak přehled technologií pro automatizaci testů a návrh, kudy by se v TNS v tomto ohledu mohli vydat. 2. Formát pro transformaci mezi XML a jiným, např. značkovacím jazykem (vice na [3] nebo [2]). 3. Jedná se o formát, který předepisuje strukturu XML dokumentu (více na [3] nebo [2]). 4. Informace o firmě TNS naleznete na [1]. 2

8 Kapitola 2 Kernun Firma TNS je jedním z externích partnerů Fakulty Informatiky, v rámci této spolupráce vypisuje projekty pro studenty. K jednomu z projektů jsem se dostal i já. Mým již zmíněným úkolem bylo vytvořit testy pro Kernun aplikační proxy firewall, což je rodina nástrojů navržena pro sít ové prostředí s vysokými nároky na bezpečnost. 2.1 Specifikace firewallu Nyní bych rád stručně charakterizoval produkt, který jsem měl za úkol otestovat. Nejprve definuji co je to aplikační proxy firewall, poté popíši prostředí firewallu, funkční aspekty, hardwarové a softwarové nároky. Závěrem přidám osobní zařazení firewallu a srovnání s jinými firewally. Základním principem aplikačního proxy firewallu je filtrování provozu mezi vnitřní (privátní) a externí (Internet) sítí. Tento firewall však funguje tak, že pokud se klient snaží spojit se serverem, tak se toto spojení nenavazuje přímo ale přes firewall. Klient navazuje spojení s proxy (firewallem) a ten dále komunikuje se serverem. Proxy interpretuje, kontroluje nebo upravuje obsah na úrovni aplikačního protokolu, např. HTTP nebo FTP. Proxy může být transparentní nebo netransparentní. Při použití netransparentního spojení se klient explicitně spojuje s proxy a adresa serveru, kam má být dotaz předán je uložena bud v aplikačním protokolu, nebo přímo v konfiguraci proxy. Pokud se klient snaží spojit přímo se serverem (případ s transparentní proxy), pak proxy spojení zachytí. Klient při tom vůbec netuší, že jeho spojení je monitorováno. Proxy si z této komunikace zjistí IP adresu serveru a poté s klientem komunikuje s použitím této IP adresy. Více o proxy lze nalézt v 7. kapitole uživatelské příručky [1] Systémové prostředí a vzdálený přístup Firewall běží na operačním systému FreeBSD 1. Systém je distribuován přímo s firewallem, protože jsou v něm obsaženy některé úpravy, které software tohoto druhu vyžadoval. Protože firewall běží na svém vlastním systému (a tedy i jádře) potřebujeme k jeho zprovoznění samostatný oddíl na disku, samostatný počítač nebo software pro tvorbu virtuálního počítače (např. Virtual Machine). Po instalaci nám naběhne unixové jádro systému FreeBDS, 1. Jeda z distribucí unixového operačního systému vyvinutého ze systému BSD (více na 3

9 2.1. SPECIFIKACE FIREWALLU které nemá grafický režim. Pracuje tedy v režimu příkazové řádky (obr. 2.1). I když by režim příkazové řádky k plnému nastavení firewallu stačil, poskytuje Kernun grafické uživatelské rozhraní pro méně pokročilé uživatele. Obrázek 2.1: Firewall instalovaný ve VMware workstation. K firewallu tedy lze přistupovat dvojím způsobem. První je z příkazové řádky, kdy uživatel může jednoduše použít příkazy pro správu firewall nebo úpravu nastavení jeho pravidel. Druhou možností je vzdálený přístup (remote access). K tomu potřebujeme počítač z vnitřní sítě, který bude mít nainstalované grafické uživatelské rozhraní (obr. 2.2), pomocí kterého se vzdáleně připojí k firewallu. Pomocí tohoto rozhraní uživatel může taktéž upravit nastavení firewallu nebo jeho pravidel. Výše zmíněné úpravy se týkaly převážně provozu transparentní proxy. Konkrétně se jedná o možnost přidělení IP adresy soketu pomocí binding 2. Musí se jednat o IP adresu, která není nakonfigurovaná na žádném sít ovém rozhraní. Tento postup umožňuje firewallu 2. Jeden z možných způsobů přiřazování IP adres. Více na anglických stránkách 4

10 2.1. SPECIFIKACE FIREWALLU Obrázek 2.2: Změny nastavení jednotlivých položek firewallu pomocí GUI. komunikovat s použitím adresy klienta, nebo jakékoliv jiné zvolené adresy. Dále pak přijímat pakety, které nejsou určené pro žádnou IP adresu, což dovoluje transparentně zachytit komunikaci mezi serverem a klientem. Selektivní přeposílání paketů, kdy firewall funguje jako router pouze pro určité pakety explicitně vybrané pomocí pravidel paketového filtru. Tolik k systémovému prostředí a nyní se podívejme na množinu funkcí, kterými firewall disponuje Použitelnost firewallu Většina obsažených nástrojů je založena na jádře aplikačního proxy firewallu. Pro lepší představu o velkém počtu možných nastavení přikládám jejich seznam Obrázek 2.3 zachycuje synchronizace nastavení firewallu pomocí GUI. 5

11 2.1. SPECIFIKACE FIREWALLU Paket filtr, selektivní přeposílání paketů a překlad sít ových adres (NAT). Nastavení uživatelských účtů. Sít ová rozhraní a statické směrování Konfiguraci démonů 4 a logování záznamů. DNS a DHCP služby a bezpečnou komunikaci pomocí SSL/TLS. Časovou synchronizaci pomocí protokolu NTP Transparentní a netransparentní proxy. H.323, SIP, SQLNet, UDP, HTTP, HTTPS, SMTP,POP3, IMAP4 proxy. Antispam a antivirus. Detekci obsahu, IDS, IPS a monitorování aktivních spojení. OpenVPN a IPsec. Jednotlivá nastavení mají podobu pravidel, která se uplatňují v pořadí přirozeného uspořádání. Tedy první pravidlo, kterému dané spojení vyhovuje, je aplikováno. Jedná se tedy o first match approach firewall. Na tento fakt je nutné myslet při zadávání pravidel. Nyní se podíváme na hardwarové požadavky jednotlivých produktů z balíku Kernun Hardwarové a softwarové nároky Hardwarové nároky přímo úměrně rostou spolu s očekávaným provozem, který má firewall zpracovat. Protože se Kernun dodává v několika verzích, které navíc podporují různé technologie. Je zde přiložena tabulka z druhé kapitoly uživatelské příručky, která ukazuje podporu jednotlivých produktů v pro jednotlivé druhy hardwaru. KBA SOHO Pro Enterprise Enterprise Plus Kernun Net Access Ne Ano Ano Ano Ano Kernun Mail Access Ne Ano Ne Ano Ne Kernun VPN Access Ne Ano Ne Ano Ne Kernun Office Access Ne Ano Ne Ano Ne Kernun Web Access Ne Ano Ne Ano Ne Kernun Branch Access Ano Ne Ne Ne Ne Tabulka 2.1: Podpora produktů na různém druhu hardware. Jednotlivé hardwarové varianty jsou popsány v 2. kapitole uživatelské příručky [1]. Stejná kapitola obsahuje tabulku s doporučenými hardwarovými parametry jednotlivých firewallů. 4. Procesů spuštěných na pozadí běžícího systému. 6

12 2.1. SPECIFIKACE FIREWALLU Obrázek 2.3: Grafické uživatelské rozhraní. Softwarové nároky při instalaci jsou minimální. Instalační CD s firewallem a systémem FreeBSD dostaneme při jeho zakoupení. Uživatelské rozhraní je volně ke stažení na stránce Jediným problémem je případ, kdy si chcete vytvořit instanci firewallu pomocí virtuálního prostředí. V tomto případě je nutné si opatřit například VMware nebo jiný software, který vytvoření podobného prostředí umožňuje Zařazení firewallu V porovnání s osobními firewally, bych firewall Kernun zařadil jako složitější software, který pro svoji obsluhu vyžaduje zkušeného administrátora. Přece jen nástroje jako Windows Fi- 7

13 2.2. OBECNÉ POSTUPY PRÁCE NA PROJEKTU rewall 5 [14] nebo Kerio WinRoute Firewall 6 [12] jsou uživatelsky přívětivější. Zatímco tyto firewally kontrolují provoz pouze na vašem počítači, Kernun je možné nasadit do sítí s několika desítkami i stovkami počítačů. Protože obsahuje celou řadu možných nastavení, je vhodným produktem do každé větší společnosti, která stojí o ochranu své privátní sítě. Rozhodně nechci odradit méně zkušené správce sítě, kteří by se mohli domnívat, že na software podobné velikosti nestačí. Po přečtení uživatelské příručky jsem jednotlivá nastavení firewallu dokázal simulovat i já, a to nemám se správou sítí téměř žádné zkušenosti. Bohužel se nejedná o freeware 7, takže dostat se k jeho distribuci nebude jednoduché. Pokud se Vám tato možnost naskytne, neváhejte jí využít. V tomto ohledu si cením spolupráce s TNS, protože seznámení se s podobným produktem bylo pro mě nedocenitelnou zkušeností. 2.2 Obecné postupy práce na projektu Zadání projektu Pokud jste nikdy neslyšeli, že by fakulta spolupracovala s externími partnery nebo že máte možnost pracovat na projektech (někdy i za peníze), pak doporučuji zapsat si některou z laboratoří. Fakulta disponuje hned několika (LaBaK 8, SITOLA 9 aj.). Na tyto laboratoře se obvykle externí partneři obracejí, když hledají studenty, kterým by mohli zadat zpracování projektů. Může se stát (není to však pravidlem), že pro členství v těchto laboratoří musíte nějaký projekt zpracovávat. Ted se přesuneme o krok dále. Navštěvujete laboratoř a máte vybraný nějaký projekt. Vaši spolupracovníci z laboratoře Vám v této chvíli doporučí, zda si nemáte nastudovat nějakou literaturu nebo webové stránky týkající se projektu. Po úvodním studiu materiálů k projektu je vhodná úvodní konzultace s externím zadavatelem. Na této konzultaci si obě strany ujasní, co od projektu očekávají, kdy se začne s prací a kdy se s ní skončí, jaká bude forma předání a podobně. Pokud si v této chvíli uvědomíte, že je projekt nad Vaše síly, nebývá problém se zadavatelem domluvit, že od projektu odstupujete nebo se dohodnete na zpracovaní pouze určité části. Ve chvíli, kdy si s externím partnerem ujasníte Vaše společné cíle je opravdu vhodné sepsat dokument, ve kterém tato shoda bude zaznamenána smluvní formou (tzv. specifikací). Zamezí to v mnoha případech tomu, že Vy nebudete pro partnera projekt dokončovat se slovy: Ale na tom jsme se přece nedomlouvali. A na druhou stranu Vás poté partner nebude moct nutit, abyste pracovali více než je napsáno v této specifikaci. Opravdu doporučuji tuto specifikaci alespoň neformálně sepsat, protože v polovině práce zjistíte, že nevíte, zda na dané části projektu opravdu máte pracovat, nebo už to Vaše práce není. Ve specifikaci se dále mohou objevit i některé z věcí, které zmíním v následujících kapitolách. 5. Základní nástroj správy externí komunikace v operačním systému MS Windows. 6. Komerční firewall vytvoření firmou Kerio pro potřeby ochrany osobních počítačů. 7. Označení softwaru, který je distribuován bezplatně. 8. Stránky laboratoře umístěny na 9. Stránky laboratoře umístěny na 8

14 2.2. OBECNÉ POSTUPY PRÁCE NA PROJEKTU Doporučená literatura Tuto stránku rozhodně doporučuji nepodcenit, zvláště pak, pokud s podobným projektem nemáte zkušenosti. Já osobně jsem ji podcenil, a po ukončení projektu jsem si jednu z knížek přečetl. Následně jsem zjistil, že jsem nespočet věcí dělal příliš složitě, že jsem znovu objevoval kolo a že jsem celý projekt mohl zvládnout s velkou časovou rezervou. Literaturu, kterou byste měli přečíst nejlépe před tím, než začnete na projektu pracovat, můžete získat různým způsobem. Část literatury Vám může doporučit externí zadavatel. Vhodným člověkem v tomto ohledu by měl být i vedoucí Vašeho projektu na fakultě. V neposlední řadě doporučuji do Googlu zadat téma vašeho projektu (např. softwarové testování) a uvidíte, kolik užitečných publikací Vám bude předloženo. Stačí si jen vybrat. Přečtení těchto publikací obvykle není pro zpracování vyžadováno, ale já je vřele doporučuji. Čas strávený při čtení se Vám několikanásobně vrátí při práci na projektu. Toto mé doporučení se týká studentů s žádnými nebo malými zkušenostmi s projekty. Zkušení programátoři a testeři rozhodně nemusí znovu číst knihy o základech programování nebo testování. Pokud si ale zkušení nepřipadáte, literatura je vždy vhodným začátkem práce na projektu Komunikace Při práci na projektu se komunikaci nevyhnete, at už se bude jednat o komunikaci s Vašimi týmovými spolupracovníky nebo se zadavatelem. V rámci mého projektu jsem musel být v kontaktu s zaměstnancem firmy TNS. Špatně zvolené komunikační prostředky nebo jejich poměr mi přinesl hned několik úskalí. Podívejme se jaké jsou Vaše komunikační možnosti. Je jich hned několik. Pracovní meeting, kde se obě strany sejdou a prodiskutují změny a dosažené výsledky, průběžné y nebo telefonické porady. Telefonická komunikace je sice rychlá, ale nemusí být vždy efektivní. Může se stát, že se dovoláte vedoucímu v nepravou chvíli, kdy na Vás nebude mít čas a jakákoli debata o projektu je zmařena. Mnohem vhodnějším prostředkem v tomto směru jsou y s průběhem postupu Vaší práce. Ideálně v pravidelném intervalu (např. jednoho týdne) informujete Vašeho vedoucího jaké pokroky jste v práci učinili. Vedoucí není nijak stresován telefonátem v nevhodnou dobu a má čas si v klidu přečíst. Tento přístup má ale také svá úskalí doba zpracování projektu se začne protahovat. V případě, že čekáte na od vedoucího projektu, který Vám má odpovědět na řadu důležitých otázek položených ve Vašem u, a Vy na něj musíte čekat někdy i pár dní. Pak s každým takovýmto em přichází několikadenní režie. Jedno malé doporučení při komunikaci pomocí u, které jsem získal při mém projektu: V každém u na konci vložte prosbu, aby Vám druhá strana potvrdila přijetí u. Vyhnete se tak čekání na odpověd, která nikdy nemůže přijít a obvykle končí em od Vašeho vedoucího, že jste se mu dlouho neozval. Ústní konzultace nebo meetingy jsou v tomto směru nejlepší. Stanovíte si určitý čas, kdy se sejdete a výsledky projektu prodiskutujete a případné dotazy vyřešíte hned na místě. Nedochází zde k žádným prodlevám. Zdálo by se, že přímý kontakt je nejvhodnější 9

15 2.2. OBECNÉ POSTUPY PRÁCE NA PROJEKTU formou. Možným problémem je zde fakt, že zadavatel nemusí mít sídlo firmy ve Vašem dosahu, takže například meeting jedenkrát týdně není možné uspořádat. Je tedy vhodné mezi těmito komunikačními kanály zvolit nějaký poměr. V mé práci docházelo k největším pokrokům, při udržování poměru týdenní ové zprávy a měsíční ústní konzultace. Týdenní y Vás samotné donutí, aby i během týdne docházelo k postupu práce a na měsíčních konzultacích stihnete probrat problémy vzniklé během uplynulého měsíce. Musíme vycházet z faktu, že každý je individualita, a proto každému vyhovuje něco jiného. V žádném případě Vám nebudu nutit můj poměr komunikačních cest, protože můžete Vy i Váš zadavatel preferovat jinou variantu nebo kombinaci. Důležité ale je, domluvit se na formě komunikace a její četnosti, aby pak nedocházelo k zbytečným prodlevám nebo nedorozuměním Časový plán Jako většina zde uvedených věcí, by se i časový plán mohl zdát volitelným doplňkem. Silně však doporučuji ho promyslet a nebo i sepsat. Dobře promyšlený a navržený časový plán Vám poskytne nejen stálý postup v práci, ale zároveň Vám umožní se věnovat i jiným činnostem. Již při konzultacích jsem zmínil, že by měli mít pravidelnou formu. Stejně tak by mělo mít pravidelnou formu odevzdávání výsledků práce. Je důležité si domluvit se zadavatelem, kdy chce mít práci hotovou. Pokud si určíte koncový termín, je vhodné si poslední dva až čtyři týdny nechat na závěrečné práce jako úpravy dokumentů nebo jemné technické nedostatky. Ve zbytku času je vhodné si naplánovat několik, vhodný počet je značně proměnlivý a závisí na velikosti projektu a také na tom, jak často chce být kontrolování, kontrolních termínů spolu s procentuálním vyjádřením práce, která bude v tom daném termínu hotová. Toto Vám i zadavateli umožní vidět, jak si na projektu stojíte, a případné zpoždění je pak vždy snadno identifikovatelné a rychle řešitelné Další úskalí Jedním z dalších aspektů projektu je jeho cena nebo řečeno jinak Vaše odměna. Nepovažujte za drzost se zeptat, jestli za práci dostanete zaplaceno a v jaké výši. Neměla by to být pro zadavatele překvapivá otázka. Pokud se ale jedná o dobrovolný projekt pro některou z laboratoří, může být odpověd, že nedostanete. I když je tato odpověd z těch, které neradi slyšíte, zvažte, zda Vám nestačí zkušenosti s prací na projektu a práce s novými technologiemi a peníze oželíte. Projekt Vám může přinést mnoho cenných zkušeností, které ve svém důsledku mohou vést k mnohem lepší práci než jste očekávali. Proto práci zadarmo nezavrhujte už z principu. Jako poslední bych zde rád uvedl problém s verzováním a verzemi. Ve většině projektů se setkáte s postupem práce a postupným měněním jeho částí. Je dobré se u zadavatele informovat, např. na jaké verzi jeho software budete pracovat, kterou verzi budete testovat nebo zda se bude verze software měnit během Vaší práce. Na začátku projektu doporučuji projít se zadavatelem tuto stránku věci a navrhnout mu, zda by Vás o těchto změnách in- 10

16 2.3. POSTUP TVORBY A OBSAH METODIKY TESTOVÁNÍ formoval v průběhu projektu. Vyhnete se pak zbytečným problémům, kdy v manuálových stránkách naleznete příklad nastavení softwaru, který ve verzi, se kterou pracujete, ještě není možné nastavit apod. Pokud se bude jednat o projekt testování nějakého softwaru, pak se nezapomeňte domluvit na verzi softwaru, která bude předmětem předávacích testů. 2.3 Postup tvorby a obsah metodiky testování Protože primárním cílem mé práce na projektu byla tvorba testů, nikoli psaní metodik pro testování nebo pro vytváření testů, samotné metodiky vznikly jako vedlejší produkt tvorby testů. Hlavním cílem bylo vytvořit již zmiňované testy. Protože výsledný dokument obsahuje zhruba 150 testů sepsaných na 80 stranách, nebylo vhodné ho umist ovat přímo do bakalářské práce 10. V průběhu práce se objevovaly nové atributy, které jsme po dohodě se zadavatelem postupně začleňovaly do testovací metodiky. Stejně tak musel být následně zařazen i do metodiky tvorby testů, protože každý nově vytvořený test je musel obsahovat. Metodika tvorby testů vznikala tedy paralelně s tím jak vznikaly testy. Zadavatel však více požadoval vypracování testů a to z důvodů jejich brzkého nasazení. Proto musela tvorba metodiky být čas od času odložena. Ještě jeden faktor měl velkou váhu na pozdním zpracování metodiky. Fakt, že moje zkušenosti na začátku práce nebyly velké, způsobil, že jsem z větší části musel napsat testy, než jsem k nim byl schopen zhotovit metodiku. Všechny tyto aspekty zapříčinily, ač to bylo mírně proti logice, že výsledná metodika byla dokončena až po sepsání testů. Metodiky pro testování bych rozdělil na dvě samostatné kapitoly. Jednak na metodiku testování, ve které by měli být zaznamenány postupy testování, zápis výsledků testů, kritéria úspěšnosti testování apod. Druhou částí by měla být metodika tvorby testů, která by měla obsahovat postup na vytvoření nového testu, seznam atributů jednotlivých testů spolu s příklady atributů. Tyto dvě metodiky bych oddělil a to z důvodu, že je rozdíl v psaní a tvorbě testů, a testování softwaru. Kapitola obsažená i v mé testovací příručce byla metodika tvorby testů. V této kapitole jsem postupně uváděl shodné atributy všech testů. Každý test je třeba identifikovat. K tomu slouží jeho identifikační číslo (ID). V mém případě jsem tvořil testy podle uživatelské příručky, která byla rozdělena na kapitoly. Pro snadnou orientaci jsou čísla testů shodná s čísly kapitol, které testují. Dalším identifikátorem byl název testu, který je opět stejný s názvem kapitoly nebo části kapitoly, jíž se týká. Dále následuje popis testu. Obvykle se jedná o český překlad anglického názvu testu společně s podrobnějším vysvětlením, co se bude testovat. Podstatným bodem jsou prerekvizity, kde uvádím čísla testů, které musí být úspěšně provedeny před testem, který je má obsaženy v prerekvizitách. Do prerekvizit je vhodné zapsat i různá nastavení sítě, speciální software, popřípadě úkony, které je potřeba provést před samotným zahájením testu. Ve výčtu položek dále následuje postup testu, který obsahuje atomické nebo velmi jednoduché operace, které je nutné provést jako otestování dané funkcionality. Za každým testem následují kritéria úspěšnosti, podle kterých tester posoudí, zda 10. Ukázka z testovací příručky je umístěna v tištěné i elektronické příloze bakalářské práce. 11

17 2.4. SHRNUTÍ test skončil úspěšně či nikoliv. Většinou se jedná o textový popis změn chování firewallu nebo grafických změn uživatelského rozhraní. Posledním prvkem výčtu atributů je strávený čas. Jedná se o předpokládaný čas, který by měl test trvat. Díky tomuto prvku můžeme test, který trvá neúměrně dlouho, zařadit mezi neúspěšné. V případě inovace uživatelské příručky firewallu a následného psaní testů pro toto nastavení je tedy jednoduché, vytvořit si šablonu obsahující tyto atributy a jejich vyplnění aktuálními údaji, které pokrývají daný test. Druhá složka testovacích metodik, metodika testování, sice není samostatně obsažena v dokumentu s testy, ale její fragmenty můžeme najít v metodice tvorby testů. Mezi její hlavní složky bych zařadil postup při testování. V mém případě postupuje chronologicky podle čísel testů, i když prerekvizity dovolují testerovi jistou variabilitu. Další složkou je záznamový arch, který je na konci mojí testovací příručky. Obsahuje výčet všech testů spolu s políčkem pro zápis, zda test prošel či nikoliv, a polem pro napsání poznámky testera. Nepostradatelnou částí je seznam položek nutný při testování, který si tester musí připravit předem. K testování patří i testovací prostředí, proto je vhodné do metodiky testování zařadit i odstavec, který obsahuje možná testovací prostředí. Může obsahovat i postup k jejich nastavení. V mém případě se část testů dotýkala příkazové řádky, která byla spuštěna v rámci firewallu a systému FreeBSD. Druhá část testů se prováděla ze vzdáleného počítače pomocí grafického uživatelského rozhraní. Proto jsem do testovací metodiky přidal pasáž, ve které specifikuji, že všechny testy vyžadující příkazový řádek provádíme přímo na stroji, at už virtuálním nebo normálním, kde je nainstalován firewall a testy vyžadující uživatelské rozhraní provádíme pomocí vzdáleného přístupu k firewallu. Na závěr je vhodné zmínit, jak se má tester zachovat při neúspěchu některého testu. Zde je vhodné v testování pokračovat, nebo u některých testů skončit a výsledek reportovat, protože se jedná o základní testy, které musí být splněny za každých okolností. 2.4 Shrnutí V druhé kapitole mé práce jsem nejprve představil produkt od firmy TNS, kterým je aplikační proxy firewall Kernun. Dále jsem popsal aspekty práce na projektu, které mohou podle mého názoru vést k prodloužení práce na projektu, k jeho neúspěšnému ukončení, ale také k jeho urychlení. V poslední části jsem uvedl dvě konkrétní, spíše teoretické, části mojí práce, které však v druhé části práce použiji k prvním krokům k automatizaci testování uživatelské příručky firewallu. Jedná se převážně o část metodiky tvorby testů, která se stala předlohou pro návrh struktury značkování XML dokumentu. 12

18 Kapitola 3 Využití XML Cílem mé práce bylo vytvoření testovací příručky nikoliv popisování základů technologie značkovacích jazyků. Základy k těmto technologiím jsou uvedeny například v bakalářské práci Jana Pavloviče Tvorba dokumentu v XML [6] nebo v knize Jiřího Koseka XML pro každého [2]. Protože využití této technologie považuji za první krok k automatizaci testů, budu se v této kapitole věnovat použití značkovacích jazyků při tvorbě testů, snadné validaci struktury testu a jich transformace do formátu HTML (HyperText Markup Language) 1 nebo do textu. V minulé kapitole jsem v metodice pro tvorbu testů vytyčil strukturu testu. V přehledné tabulce 3.1 zrekapituluji jednotlivé atributy testů spolu s jejich očekávaným obsahem. ID Jméno Popis Prerekvizity Checklist Kritéria Čas Číslo jednoznačně identifikující test. Název testu. Obvykle schodný s anglickým názvem kapitoly. Stručný popis charakteru testu (co test testuje). Čísla testů, které musí předcházet aktuálnímu testu. Seznam kroků, kterými se provádí samotné testování. Podmínky, za kterých lze test považovat za úspěšný. Odhadovaný čas nutný k provedení testu. Tabulka 3.1: Struktura testu. Od této struktury, se odvíjela struktura XML dokumentu obsahující test i další související prvky jako DTD (Data Type Definiton) 2, XSD nebo XSLT, které tuto strukturu vynucují nebo ji transformují například do HTML. V průběhu této kapitoly se podíváme na všechny tyto technologie, ve stručnosti si řekneme k čemu slouží, ukážeme si vzorové příklady jednotlivých dokumentů a ukážeme si na nich rozdíly či případné výhody a nevýhody. 3.1 Ukázka XML testu Dříve než se podíváme na vzorový XML dokument, bych rád začal trochou teorie o XML [3]. Extensible Markup Language (zkráceně XML, česky rozšiřitelný značkovací jazyk) je 1. Jeden ze značkovacích jazyků, který slouží k publikování na Internetu (vice na 2. Anglická zkratka vyznačující definici datového typu. Obvykle se jedná o šablonu pro XML soubor (více na 13

19 3.1. UKÁZKA XML TESTU obecný značkovací jazyk, který byl vyvinut a standardizován konsorciem W3C (World Wide Web Consorcium) 3. Je zjednodušenou podobou staršího jazyka SGML (Standard Generalized Markup Language) 4. Jazyk je určen především pro výměnu dat mezi aplikacemi a pro publikování dokumentů, u kterých popisuje strukturu z hlediska věcného obsahu jednotlivých částí, nezabývá se vzhledem. Jazyk XML sebou přináší hned několik výhod [11]: Otevřený formát (specifikace zdarma na W3C). Snadná srozumitelnost. Textově orientovaný formát. Vysoký informační obsah (např. oproti prezentačnímu značkování). Snadná konverze do jiných formátů. Snadná automatická kontrola správnosti struktury. Snadné odkazování. Z těchto výhod bych pro účely testování zdůraznil zejména textově orientovaný formát, snadnou konverzi do jiných formátů a automatickou kontrolu správnosti struktury. Z těchto výhod nám vyplývá, že pokud jednou začneme psát testy určitou formou (podle určitého DTD nebo schématu), můžeme následně pouze upravovat aplikace, které s těmito testy pracují. Jednoduše můžeme měnit a přizpůsobovat výstupní formát testů z obyčejného textu až po HTML. Budeme mít také vždy jistotu, že po vytvoření testu dle šablony a jeho ověření pomocí schématu bude schopna aplikace s testem pracovat a takto vytvořený test vždy rozpozná. Nyní už se podívejme na strukturu XML s jeho jednotlivými tagy 5. <?xml version="1.0" encoding="utf-8"?> <test id="3.4.1"> <name>test Boot Manager</name> <description>otestovat omezený přístup neautorizovaným osobám do systému </description> <prerequisites>3.5.1</prerequisites> <checklist> <step>znemožníme změnu bootovacích zařízení, například nastavením hesla v~biosu</step> <step>povolíme pouze chtěné partitions pomocí bootmgr</step> 3. Jedná se o mezinárodní konsorcium, jehož členové společně s veřejností vyvíjejí webové standardy pro World Wide Web (více na [3]. 4. Metajazyk, který umožňuje definovat množinu značkovacích jazyků jako své vlastní podmnožiny (více na [3]. 5. Anglický výraz, který označuje párové značky používané v XML dokumentech. V dokumentech jsou uváděny k zvýšený sémantického významu. 14

20 3.2. TVORBA DTD <step>přidáme řádek --n do /boot.config -- příkazem printf -- -n\n > /boot.config</step> <step>přidáme řádek do souboru /boot/leader.conf a změníme mu práva pouze pro čtení rootem -- příkazy:</step> <step>echo password="secret" >> /boot/loader.conf</step> <step>chmod go-rw /boot/loader.conf</step> <step>vynutíme dotazování na root heslo změněním v~souboru /etc/ttys na řádku začínajícím console poslední slovo na insecure</step> </checklist> <criteria>zkontrolujeme, že ze single user modu je vyžadováno heslo </criteria> <time>5</time> </test> Z příkladu je vidět, že jsem tagy v dokumentu pojmenoval anglicky a to hned ze dvou důvodů. Prvním je, že firma TNS se vyskytuje nejen na českém trhu, ale také v Americe, a druhým pak, že anglické pojmenování vede v mezinárodním měřítku k jednoduššímu pochopení významu. Přece jen anglicky rozumí téměř půl druhé miliardy lidí na celém světě. V dokumentu je použit jako kořenový element <test> s atributem id, které označuje číslo testu. Dále jsou zde elementy zmíněné v definici struktury dokumentu. Za zmínku dále stojí element <checklist>, který obsahuje elementy <step>, které symbolizují jednotlivé kroky testování. Celý dokument je jednoduchý a přehledný. Význam všech elementů je patrný z anglických tagů a s takto připraveným dokumentem můžeme dále pracovat. 3.2 Tvorba DTD DTD je nejjednodušší nástroj pro validaci XML. Pomocí dokumentu, který obsahuje DTD můžeme validovat libovolný XML dokument. XML dokumentu stačí do hlavičky připsat tento řádek: <!DOCTYPE test SYSTEM "cesta k~dtd"> Kde cesta k DTD označuje místo pro zadání cesty k souboru s příponou.dtd. Po přidání tohoto řádku do XML dokumentu se při validaci použije soubor s DTD a validátor nahlásí případné neshody XML s DTD. Mnou vytvořené DTD pro vzorové XML vypadá následovně: <?xml version="1.0" encoding="utf-8"?> <!ELEMENT test (name,description,prerequisites,checklist,criteria,time)> <!ELEMENT name (#PCDATA)> <!ELEMENT description (#PCDATA)> <!ELEMENT prerequisites (#PCDATA)> <!ELEMENT checklist (step+)> <!ELEMENT step (#PCDATA)> <!ELEMENT criteria (#PCDATA)> 15

21 3.3. XSD TESTU <!ELEMENT time (#PCDATA)> <!ATTLIST test id CDATA #REQUIRED> Je z něho patrných několik věcí. Kořenovým elementem je <test>, který obsahuje atribut id, který je povinný. Obsahem elementu <test> je výčet výše zmíněných elementů, kde pouze element <checklist> obsahuje jako svůj obsah elementy <step>. Počet elementů <step> je zdola omezen na více než 0. Zřejmou výhodou tohoto formátu je jeho jednoduchost. Jeho základními stavebními kameny jsou elementy, atributy, entity, PCDATA (parsed character data) 6 a CDATA (character data) 7. Jednoduchost ale přináší nevýhodu v nemožnosti zaznamenání specifických požadavků na omezení. U elementu <time> bychom chtěli zdůraznit, že se jedná o celé číslo, které je větší než 0, pak nám DTD nestačí. Proto se v následující podkapitole podíváme na silnější nástroj, kterým je XSD. 3.3 XSD testu XSD schéma je druhým formátem pro validaci struktury XML, stejně jako DTD. V tomto případě se ale jedná o nástroj mnohem silnější ale také komplikovanější. V této kapitole ukáži na příkladu jednoduchého schématu, které však naprosto dostačuje nutnosti validace XML dokumentu s testem, jeho elementy. Z tohoto schématu budou vycházet i další příklady, na kterých demonstruji jeho výhody oproti DTD a navrhnu přísnější kritéria pro validaci testů. Cíle XSD [3]: Definuje místa v dokumentu, na kterých se mohou vyskytovat různé elementy. Definuje atributy. Definuje, které elementy jsou potomky jiných elementů. Definuje pořadí elementů. Definuje počty elementů. Definuje, zda element může být prázdný, nebo zda musí obsahovat text. Definuje datové typy elementů a jejich atributů. Definuje standardní hodnoty elementů a atributů. Nyní přejděme k samotnému příkladu: 6. Jedná se o text, který bude zpracován syntaktickým analyzátorem. Syntaktický analýzátor hledá entity a značkování (více na [2]. 7. Text reprezentovaný pod touto zkratkou nebude zpracováván pomocí syntaktického analyzátoru (více na [2]. 16

22 3.3. XSD TESTU <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" targetnamespace=" xmlns:tns=" elementformdefault="qualified"> <xsd:element name="test"> <xsd:complextype> <xsd:sequence> <xsd:element name="name" type="xsd:string" /> <xsd:element name="description" type="xsd:string" /> <xsd:element name="prerequisites" type="xsd:string" /> <xsd:element name="checklist"> <xsd:complextype> <xsd:sequence> <xsd:element name="step" type="xsd:string" minoccurs="1" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> </xsd:element> <xsd:element name="criteria" type="xsd:string" /> <xsd:element name="time"> <xsd:simpletype> <xsd:restriction base="xsd:integer"> <xsd:mininclusive value="1"/> <xsd:maxinclusive value="30"/> </xsd:restriction> </xsd:simpletype> </xsd:element> </xsd:sequence> <xsd:attribute name="id" type="xsd:string" use="required" /> </xsd:complextype> </xsd:element> </xsd:schema> Na první pohled je vidět, že dokument schématu je složitější než obyčejné DTD, přičemž navíc kontroluje pouze hodnotu času, který může nabývat hodnot Schéma stejně kontroluje elementy jako jméno nebo popis, omezuje počet kroků v checklistu na alespoň jeden a vyžaduje použití atributu ID. Otázka zní, zda jsme si vůbec pomohli? Odpověd je ano. Jak už jsem uvedl na začátku této kapitoly, pro účely testování validace struktury testu by takovéto schéma bohatě stačilo. Navíc u elementů obsahujících textový obsah musíme být vždy opatrní, pokud chceme omezovat jejich obsah. Vždy když ho chceme omezit, musíme si být zcela jisti, že se určitý text nebo znaky v elementu vyskytovat nebudou, nebo tento fakt musíme chtít explicitně vynutit. I přes tato fakta můžeme schéma upravit do striktnější formy. V metodice tvorby testů jsem zmínil, že jméno obsahuje anglický název testu. Proto můžeme v elementu <name> vynutit používání anglických znaků, číslic, mezer a čárek (jako oddělovačů slov). Naše schéma upravíme následujícím způsobem: 17

23 <xsd:element name="name" > <xsd:simpletype> <xsd:restriction base="xsd:string"> <xsd:pattern value="([a-za-z0-9, ])+"/> </xsd:restriction> </xsd:simpletype> </xsd:element> 3.4. XSLT TRANSFORMACE V elementu <xsd:pattern> a jeho hodnotě value jsme pomocí regulárního výrazu vynutili použití znaků anglické abecedy, číslic a znaků pro oddělení slov. Tímto regulárním výrazem však projde i výraz složený z několika mezer nebo čárek. I když je tento případ možný a test bude validní, pro tvůrce transformací nebo programu pracujícím s těmito testy je mnohem důležitější fakt, že se ve jméně testu nemůže objevit znak jiný, než vyjmenované. Další kontrolu, kterou můžeme přidat, je kontrola struktury id. Id je jednoznačně zadaná posloupnost číslic, které jsou odděleny a zakončeny tečkami. Tedy například Mezi použitými číslicemi jsou 0-9. Můj návrh schématu můžeme tedy dále upravit: <xsd:attribute name="id" use="required" > <xsd:simpletype> <xsd:restriction base="xsd:string"> <xsd:pattern value="(([0-9])+.)+ "/> </xsd:restriction> </xsd:simpletype> </xsd:attribute> Tato změna umožní kontrolovat, že je v atributu id použit řetězec, který má správnou strukturu. Těmito ukázkovými příklady jsem chtěl nastínit sílu XSD, která jsou ve výsledku více striktní a v použitelnosti několikrát převyšují DTD. Věřím, že rozdíl mezi DTD a XSD je více než zřejmý. Více podobných variací a možných úprav, které schéma nabízí, lze hledat na stránkách W3Schools 8 [2] v sekci XML Learn Schema. 3.4 XSLT transformace XSLT je jednou z dalších součástí XML. Samotné XML je samo o sobě hůře čitelné než dokument zpracovaný bez značkování. Proto je vhodné před zobrazením dokumentu provést transformaci. At už se jedná o transformaci textovou nebo transformaci do HTML, vždy je výsledek lépe čitelný (tedy alespoň pro člověka). Tyto transformace také umožňují použití XML v rámci různého softwaru. Jednoduše řečeno, pokud s jedním druhem XML neumí pracovat nějaký software, není těžké napsat transformační soubor, který jej změní na XML (nebo jiný dokument), se kterým už software pracovat umí. Jedním z možných transformací je textová transformace, která ze vstupního XML dokumentu vygeneruje dokument textový. Zdrojový kód textové transformace: 8. Anglický internetový portál s ukázkovými příklady pro jazyky HTML, XML aj. naleznete na 18

24 3.4. XSLT TRANSFORMACE <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet xmlns:xsl=" version="1.0"> <xsl:output method="text"/> <xsl:template match="/test"> ID: <xsl:value-of /> Jméno: <xsl:value-of select="name" /> Popis: <xsl:value-of select="description" /> Prerekvizity:<xsl:value-of select="prerequisites" /> Checklist:<xsl:text> </xsl:text> <xsl:for-each select="checklist/step"> <xsl:text> </xsl:text><xsl:value-of select="self::step"/> <xsl:if test="following-sibling::step"><xsl:text> </xsl:text></xsl:if> </xsl:for-each> Kritéria: <xsl:value-of select="criteria" /> Čas: <xsl:value-of select="time" /> min </xsl:template> </xsl:stylesheet> Nyní tuto transformaci rozebereme a ukážeme si konkrétní prvky XSLT. Celá transformační šablona je uzavřena do tagů <stylesheet>. Tag <output> určuje druh výstupního souboru. Tedy například text, HTML nebo XML. Dále pokračuje výběr kořenového elementu pomocí <template>. Po výběru kořenového elementu pokračujeme s výpisem jednotlivých elementů či atributů, které mají být v cílovém dokumentu. Při výpisu ID jsme použili zavináč, protože se jedná o atribut elementu test. Další důležitým výpisem je až cyklický výběr všech elementů <step> a jejich následný výpis za pomoci <foreach>. Uvedená transformace není nijak složitá a výsledný dokument je díky odstranění značkování snadněji srozumitelný. Druhou možností je transformace do HTML. Při tvorbě této transformace je využito jmenných prostorů (namespaces), které jsou v XML hojně využívány. Dochází tak k odlišení různých druhů značkování. V následujícím příkladě je pomocí předpony xsl odlišeno značkování transformace od značkování HTML, které předponu postrádá. Zdrojový kód transformace do HTML: <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet xmlns:xsl=" version="1.0"> <xsl:output method="html"/> <xsl:template match="/test"> <html> <head> <title><xsl:value-of select="name"/></title> </head> <body> <h2><xsl:value-of select="name"/></h2> <h3>id: <xsl:value-of select="@id" /></h3> <p>popis: <xsl:value-of select="description" /></p> 19

25 3.5. DALŠÍ VÝVOJ <p>prerekvizity: <xsl:value-of select="prerequisites" /></p> <p>checklist:<br/> <ul> <xsl:for-each select="checklist/step"> <li><xsl:value-of select="self::step"/></li> </xsl:for-each> </ul> </p> <p>kritéria: <xsl:value-of select="criteria" /></p> <p>čas: <xsl:value-of select="time" /> min </p> </body> </html> </xsl:template> </xsl:stylesheet> Možným využitím této transformace je generování stránek s testy. Tyto samostatné stránky stačí poté pouze provázat, např. díky unikátním identifikátorům, a tak vytvořit jednoduchou neustále dostupnou testovací příručku na firemním webovém serveru. 3.5 Další vývoj XML technologie, které jsem zde prezentoval, jsou pouhým začátkem. Další vývoj by měl pokračovat směrem k vytvoření databáze obsahující všechny mnou vytvořené testy. Testy by byli uloženy ve formě XML. V časovém horizontu několika desítek hodin je reálné zpracovat program, který by k takovéto databázi přistupoval, uměl testy zobrazit, editovat a transformovat, např. do HTML. Mezi jinými by program mohl mít režim provádění testů, kdy by testerovi umožňoval provádět ruční testování, a dále by do programu mohl zadávat výsledky testů. Software by pak automaticky generoval různé logy a grafy o průbězích testů a nalezených chybách. 3.6 Shrnutí V této kapitole jsem nastínil výhody použití XML při tvorbě testů. Ukázal jsem vytvořený XML dokument testu, který lze snadno validovat jak pomocí DTD tak složitější technologie XSD. Závěrem jsem ukázal výhody transformací XML dokumentů do lépe čitelných formátů jako je prostý text nebo HTML a navrhl další postup ve využití této technologie k efektivnějšímu testování nebo jako mezistupně na cestě k testování automatickému. 20

26 Kapitola 4 Automatické testovaní V poslední kapitole mé bakalářské práce se budu věnovat náhledu na automatické testování, jeho výhody a nevýhody, nástroje s ním spojené a jejich využití na názorném příkladu. Před sepsáním této kapitoly jsem si přečetl 14. kapitolu z knihy Testování Softwaru od Rona Pattona [5], kde jsem načerpal spoustu užitečných myšlenek o automatickém testování. Nejprve se tedy zaměřme na výhody a nevýhody nástrojů pro automatické testování. V následující kapitole uvidíme, že i když by se mohlo zdát, že tyto nástroje dokáží zázraky, někdy se prostě manuální testování nedá ničím nahradit. 4.1 Výhody automatického testování Položme si jednoduchou otázku, proč automatizovat proces testování? Při vyvíjení softwaru obvykle postupujeme tak, že po přidání nové funkcionality celý software otestujeme. Tímto vždy kontrolujeme, zda nová funkce nenarušila práci jiné části softwaru. Tento případ snadno zapadá do reálného vývoje jakéhokoliv software, který i po jeho uvedení dále inovujeme. Dalo by se tedy říci, že proces automatizace testování bychom měli udělat z důvodu možnosti opakování testů. Tuto funkci automatických testů můžeme pojmenovat jako opakovatelnost [5]. Pokud jednou do sady automatických testů zařadíme test, zda tlačítko funguje, pak už vždy budeme mít jistotu, že pokud testy budou splněny, tlačítko bude fungovat. Ruku v ruce s opakovatelností jde efektivita [5]. Pokud tester jednou napíše nějaký test, je jasné, že ho příště nemusí vytvářet znovu. Díky této úspoře času při automatickém testování se může více věnovat psaní těchto testů, rozdělování testových případů nebo plánování testů. Nejvíce viditelná výhoda takového testování je rychlost [5]. Pokud máme sepsaný test, jehož průchod trvá 10 min, pak je v tomto čase obsažena i určitá režie. Je to způsobeno faktem, že příkazy člověk neumí napsat v nulovém čase ale nějakou dobu mu to trvá, nebo přesunout se myší z jednoho místa obrazovky na jiné taky určitou dobu zabere. Režie, tedy času, který je potřebný k manuálnímu zpracování testu se můžeme zbavit, použitím například skriptů. V případě, že všechny příkazy vhodně uspořádáme za sebe a sepíšeme, např. do skriptu příkazového řádku Unixu (tzv. Shell skript), můžeme tuto režii omezit na minimum, protože všechny příkazy jsou předem připraveny v tomto skriptu a záleží pouze na rychlosti procesoru a velikosti operační paměti, za jak dlouho s jeho prováděním skončí. Jednou z další výhod je správnost a přesnost [5] takto sepsaných testů. I když je tester 21

27 4.2. ROZDĚLENÍ TESTOVACÍCH NÁSTROJŮ sebelepším odborníkem na problematiku testování, po otestování několika desítek až stovek testů je mnohem náchylnější k udělání chyby a přehlédnutí nějakého špatného výsledku testu. Zatímco pokud automatickým testům zapíšete do kódu, že očekávaný výsledek je 1, pak dokud bude výsledkem testu 1, budou ho považovat za správný. Automatické testy jsou samy osobně méně náchylné k chybám. Jediné chyby do nich mohou zanést pouze testeři samotní při jejich psaní. Pokud ale test jednou napíší správně poté funguje naprosto stoprocentně, at ho spustíme poprvé nebo po tisící. Poslední z výhod, které bych zde rád vyjmenoval je neúnavnost [5]. Zatím co my lidé musíme čas od času spát nebo relaxovat, stroje tuto potřebu nemají, což z nich dělá vynikající a neúnavné testery. Testovací dávku můžeme spustit večer, když odcházíme od projektu, a ráno se vrátit a přečíst si výsledky testování. Testovací nástroj také můžeme nechat provést několik desítek stejných testů, které nám umožní vidět některé speciální druhy chyb, jako synchronizační chyby vláknových aplikací apod. Když jsem zde uvedl výčet výhod takto prováděného testování, bylo by vhodné zmínit i některé nevýhody. První je velká časová náročnost zpracovaní těchto testů. Jejich přípravou, hlavně v úvodní fázy, můžeme strávit velké množství času, kdy k žádnému testování nedochází. Mezi dalšími je nefunkčnost testů při (i malých) změnách v grafických rozhraních. Při jakékoli změně, nemusí testovací nástroje na daném místě najít správné tlačítko a celá sada testů nebo několik sad se během jednoho okamžiku stane nefunkční. Cena je také důležitým fatorem. Jak už bylo řečeno, většina těchto aplikací je placená a pro menší společnosti je nepředstavitelné investovat takové peníze do automatických nástrojů. Jako ukázka nevýhod automatického testování je tento výčet dostačující. Tolik k přehledu výhod/nevýhod automatických testovacích nástrojů. Výhod je spousta, a proto by se mohlo zdát, že nic jiného než automatické testovací nástroje nepotřebujeme. Každý tester by měl vždy dobře zvážit, zda je vhodné (a v jaké míře) použít tyto testovací nástroje. 4.2 Rozdělení testovacích nástrojů Pomocných testovacích nástrojů (nejen automatických) existuje celá řada. Vzhledem k tomu, že každý je určen k jinému úkolu, lze je rozdělit do několika různých skupin. V této kapitole se uvedu letmé zevrubné rozdělení testovacích nástrojů, z nich vyberu ty, které jsou vhodné pro budoucí automatizaci testů a v navazující kapitole jeden z těchto nástrojů představím podrobněji Základní testovací nástroje Již zmíněným letmým rozdělením nástrojů pro testování je dělení na invazivní a neinvazivní. Toto rozdělení do jedné skupiny seskupuje nástroje, které při použití v testovacím procesu jen málo ovlivňují výsledek testu (neinvazivní). Druhá skupina výsledek testu může ovlivnit více (invazivní). Toto musíme mít na paměti vždy, když chceme zajistit kvalitu testování. Můžeme tvrdit, že čím více je nástroj invazivní, tím lepší prostředky pro testování 22

28 4.2. ROZDĚLENÍ TESTOVACÍCH NÁSTROJŮ nám poskytuje. Avšak i tato mince má dvě strany. Pokud použijeme více invazivní nástroj, mohou být výsledky našeho testování více ovlivněny. Mezi neinvazivní nástroje pro testování řadím tyto: Prohlížeče a monitory. Ovladače a skripty. Makety. Naopak mezi invazivní bych zařadil: Nástroje pro zátěžové testování. Generátory šumu a interference. Analytické nástroje. Obsahem následujících řádků bude stručná charakteristika jednotlivých testovacích nástrojů. Prohlížeče a monitory jsou jedním ze základních testovacích nástrojů. Zástupcem z této třídy by mohl být monitor sít ové komunikace, který se napojí na linku mezi zdrojem a cílem a sleduje jejich komunikaci. Účelem tohoto testování může být například zjištění zda zdroj posílá chybná data, nebo zda jsou data správná a cíl je chybně interpretuje. Do kategorie monitorů bychom dále mohli zařadit například debuggery. Tyto nástroje zkoumají zdrojový kód programu při činnosti. Debuggery však musí být kompilovány se zdrojovým kódem, a proto už se jedná spíše o invazivní nástroj. Ovladače nebo, v dnešní době více využívané, skripty jsou další spíše neinvazivní technikou testování. Jako ovladač si můžeme představit vhodně propojené počítače, kdy cíl očekává velké množství dat a zdroj mu je generuje. Skripty (dříve se používal výraz dávkový soubor) jsou soubory obsahující seznam příkazů, které mají být vykonány sekvenčně. Skripty jsou psány ve jednom ze skriptovacích jazyků, např. Ruby [9] nebo Perl [9]. Za skriptovací jazyk můžeme považovat i unixový shell [13]. Výhodou skriptů je snazší údržba, vývoj, správa kódu, a fakt že nepotřebují být kompilovány. Testování pomocí maket spočívá v nahrazení konkrétního druhu hardwaru jeho maketou, např. nahrazení skeneru za obyčejný počítač. V takovém případě musí počítač obsahovat speciální software, který mu umožní tvářit se jako skener. Makety se obvykle využívají při testování softwaru při komunikaci s externími zařízeními. Obvykle totiž potřebujeme otestovat velké množství konfigurací hardwaru, na které ovšem nemáme peníze. Zátěžové a stresové nástroje umožňují při testování simulovat podmínky, které nastanou v případě, kdy je software plně vytížen. Tyto nástroje umí obvykle zvýšit zátěž kladenou na procesor, omezit operační pamět nebo simulovat nedostatek místa na disku. Zátěžové testy se také mohou týkat webových serverů, kde může dojít k náhlému nárůstu uživatelů. V této chvíli musíme zajistit, aby server zůstal funkční a nehavaroval. Generátory šumu a interference slouží k ověření chování softwaru, např. komunikačního protokolu, když na komunikační lince bude docházet k výpadkům paketů, občasnému 23

29 4.2. ROZDĚLENÍ TESTOVACÍCH NÁSTROJŮ přerušení spojení nebo obdobným neduhům, které v reálné situaci mohou nastat. Tyto nástroje se podobají zátěžovým nástrojům, protože ovlivňují okolní podmínky, jejich chování je však mnohem více nahodilé. Do analytických nástrojů můžeme zařadit software třetích stran, který je při testovaní použit a slouží k analýze. Konkrétně tedy tabulkové procesory, databázový software, software pro snímání obrazovek nebo programy pro porovnávání textů. Tyto nástroje slouží testerům k usnadnění práce. I když se obvykle nejedná o speciální druh softwaru, dokáží i tyto nástroje přinést nezanedbatelný přínos Automatické nástroje Po přehledu testovacích nástrojů se nyní podíváme na jejich automatické protějšky. Ve stručnosti si zmíníme jednodušší varianty těchto aplikací abychom se mohli více věnovat plně automatickým nástrojům. K základnímu prostředku automatického testování řadíme jednoduchá makra. Jedná se o záznamy pohybu myší a stisků kláves na klávesnici, které jsou snímané při tvorbě makra (prvním vytvoření testu) a poté znovu přehrány při testech opakovaných. Mezi výhody těchto nástrojů můžeme zařadit možnost urychlení přehrávání makra. Do jisté míry je však tento fakt limitující, protože musíme brát ohledy na rychlost odezvy systému. Mohlo by se nám totiž snadno stát, že při vyšší rychlosti přehrávání makra se nám tlačítko, které má makro zmáčknout ještě neobjevilo. V té chvíli makra přestávají být účinnými nástroji. Druhou nevýhodou je nemožnost verifikace výsledku testu. Tato jednoduchá makra nám dovolují pouze provádět stejné úkony, jaké byly dříve uloženy, ale stejný výsledek musí opět zkontrolovat tester. Mezi tyto nástroje lze zařadit software QuickKeys [8] pro Macintosh nebo Macro Magic [3] pro Windows. Druhým, důmyslnějším nástrojem jsou programovatelná makra. Je to zřejmý krok vpřed. Nyní již makra jednoduše nepřehrávají sadu instrukcí, ale jsou tvořena pomocí programového kódu. Dochází tak k lepší kontrole a vynutitelnosti operací, např. čekání na událost. Tento vývojový stupeň má stále dva nedostatky. Zaprvé jde o možnost verifikace výsledku, kdy sice makro může nabídnout testerovi okno, ve kterém si vyžádá odpověd zda byl test úspěšný, ale k úplné automatizaci nedochází. Druhým je pak nutno vykonávat kód makra v přímé linii. To znamená, že tyto nástroje neposkytují žádná větvení ani podobné užitečné programovací struktury. Poslední a nejdůmyslnější skupinou nástrojů jsou plně automatizovatelné nástroje pro testování. Nástroje tohoto druhu obvykle nabízí testerům strukturovaný programovací jazyk pro psaní testů s možností verifikace výsledků. Obvyklými způsoby verifikace jsou snímky obrazovek, kdy se při vytváření testu vytvoří předloha obrazovky, která se následně porovnává při každém dalším testování s aktuální zachycenou obrazovkou. Při nesouhlasu obou obrazů lze snadno vyvodit, že došlo k chybě. Druhou metodou verifikace je souborový výstup, kdy očekávaná výstupní data zapíšeme do souboru, a tento pak porovnáváme se souborem, který nám vytvoří aplikace při testování. Neshoda v souborech opět vede k ohlášení chyby při testování. Z nabídky možných nástrojů na trhu bych vyzvedl produkty 24

30 4.3. MOŽNOST NASAZENÍ KONKRÉTNÍHO SOFTWARU Rational 1, TestComplete 7 2, který je podporován i Windows 7 nebo TestAnywhere 3. Poslední produkt byl i předmětem mého testování. Když už jsme si vysvětlili rozdíly v jednotlivých automatizovaných nástrojích, můžeme přejít k výběru a vyzkoušení jednoho z nich. Mým osobním potřebám nejvíce vyhovoval TestAnywhere, kterým jsem si stáhl z Internetu 4. Více o tomto nástroji a zpracování automatického testu v následující kapitole. 4.3 Možnost nasazení konkrétního softwaru K automatickému testování lze využít celou řadu aplikací, které jsou dostupné na Internetu. Bohužel většina z nich je tak jednoduchá, že pro větší testování nejsou použitelné. Dále existují aplikace, které jsou licencovány a tyto licence překračují finanční prostředky, které bych byl schopen investovat při psaní bakalářské práce. Podařilo se mi však najít několik aplikací s trial 5 licencí, které jsem si vyzkoušel a z nich vybral jednu, kterou jsem použil ke zpracování testů. V této kapitole bych se zaměřil na nedostatky těchto aplikací, které jsem zjistil při práci s nimi. Poté zde prezentuji způsob zaznamenání testů 6 a jejich přehrávání. Název Platforma Licence TestComplete MS Win 30 denní trial TestAnywhere MS Win 30 denní trial MacroMagic MS Win 30 denní trial QuickKeys MacOS Freeware EggPlant MS Win, Linux, MacOS 30 denní trial Tabulka 4.1: Automatické nástroje. Během hledání vhodného nastroje jsem narazil na celou řadu problémů s automatickými testovacími nástroji, které přispěly k výběru konkrétního mnou navrženého softwaru, jako vhodného kandidáta pro zpracování automatických testů. Jedním z prvních kritérií byla snadná instalace. U většiny nástrojů se mi povedlo je nainstalovat zcela bez problémů. Například s nástrojem TestComplete 7 jsem však měl takové problémy, že i přes jeho lepší výsledky v ostatních aspektech, byly problémy s instalací tak závažné, že jsem práci s ním vzdal. Dalším faktorem, který jsem bral v úvahu byla možnost tvorby makra pro testování pomocí záznamy činnosti obrazovky. Všechny nástroje disponovaly textovým režimem pro 1. Vyvíjený firmou IBM. Dostupný ze stránek 2. Vystavený na stránkách 3. Vyvíjený stejnojmenou firmou. Dostupný ze stránek 4. Přehled staženého softwaru s podmínkami jeho stažení ukáže tabulku Slovo převzaté z angličtiny. Anglický překlad je zkušební. Ve světě softwaru to obvykle znamená, že tato licence je veřejně dostupná ale platí pouze omezenou dobu, většinou několik týdnů. 6. K zaznamenání byl použitý Free Screen Recorder, který je dostupný pod volnou licencí, např. ze stránek 25

31 4.3. MOŽNOST NASAZENÍ KONKRÉTNÍHO SOFTWARU tvorbu automatických testů. Jen pár disponovalo tvorbou makra přímo pomocí operací prováděných na obrazovce. Tyto nástroje jsem tedy upřednostnil. Jejich výhody jsou uvedeny v dalším odstavci. Posledním problémem, který sužoval i TestComplete 7 byl fakt, že po provedeném snímání obrazovky, bylo vytvořené makro moc rychlé. To znamenalo, že v určitých fázích testování bylo nutné počkat na dokončení určité operace a teprve poté pokračovat v dalším kroku (stisku klávesy nebo pohybu myší). Jsem přesvědčen, že při propracovanosti tohoto softwaru se toto nastavení zcela určitě někde skrývalo, avšak mě se jej nepodařilo najít. Software, který z těchto požadavků vyšel jako vítěz byl TestAnywhere (Obr 4.1). Další a dle mého názoru velkou výhodou je, že tento software pracuje na bázi klienta a serveru, tedy je umožněna jeho široká dostupnost. V podstatě kdekoli, kde je Internet, máte možnost se připojit k Vašemu testovacímu serveru a stáhnout si potřebné testy. Po tomto výběru se v mé práci dále budu věnovat pouze tomuto konkrétnímu softwaru a všechny záznamy obrazovek a videa jsou zaznamenána pouze s ním. Obrázek 4.1: TestAnywhere. Ze způsobů zaznamenání testu bych zdůraznil dva. Prvním je ruční psaní kódu (obvykle zdrojového) s příkazy, které se budou krok za krokem vykonávat. Tato metoda klade 26

32 4.3. MOŽNOST NASAZENÍ KONKRÉTNÍHO SOFTWARU mnohem větší požadavky na testera, který musí ovládat syntax programovacího jazyka daného testovacího nástroje. Z mého pohledu je výhodnější zaznamenávání testovacího makra přímo pomocí ukázkového testovaní. Tato operace povětšinou začíná v testovacím nástroji stiskem tlačítka Nahrát test. Poté začne testovací software snímat pohyby myši na stisky kláves na klávesnici přesně tak, jak momentálně pracujete. V takovém okamžiku Vy testujete daný software a po úspěšném ukončení tvorby testů ukončíte také nahrávací režim softwaru pro záznam testu. V této chvíli software začne zpracovávat jednotlivé příkazy a transformuje je do posloupnosti instrukcí, které mohou být opětovně spuštěny. Takto tedy odpadá jakákoli znalost syntax nebo sémantika, kterou za Vás řeší program sám. Zaznamenání testu je po zmáčknutí příslušného tlačítka v nabídce TestAnywhere reprezentováno po celou dobu testu oknem, kde se dá celý test zastavit. (Obr. 4.2). Po dokončení záznamu testu je test zpracován a uložen k jeho opětovnému přehrání. Obrázek 4.2: Okno tvorby testu. K tomuto příkladu je v sekci příloh na CD obsaženo video s tvorbou testu. Ukazuje, jak je tvorba testu pomocí tohoto nástroje snadná a intuitivní. Po tvorbě testu je druhou klíčovou vlastností nástroje, aby uměl daný test opět přehrát. Režim přehrávání testu je opět charakteristický svým vlastím oknem (Obr. 4.3). Obrázek 4.3: Okno spuštěného testu. Protože se jedná o automatický test, je nutné při jeho provádění nechat všechen hardware, zejména klávesnici a myš, v klidu. Při činnosti těchto zařízení testy obvykle selžou. K automatickému testu a jeho přehrávání jsem do příloh na CD opět zařadil video, jako nejlepší možná reprezentace daného nástroje. Po ukázkách práce tohoto inteligentního softwaru, ho můžu jedině doporučit. Tento nebo jiný software s obdobnými funkcemi je určitě přínosem pro proces testování. Jeho ovládání je intuitivní, práce s ním je jednoduchá a v rukou zkušeného testera se bude jednat 27