Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Katedra informačních technologií
Student : Martin Kučera
Vedoucí bakalářské práce : Ing. Martin Kosejk
TÉMA BAKALÁŘSKÉ PRÁCE
Testování softwaru a metodika RUP
ROK : 2006
Prohlášení
Prohlašuji, že jsem bakalářskou práci zpracoval(a) samostatně a že jsem uvedl(a) všechny použité prameny a literaturu, ze kterých jsem čerpal(a).
V Praze dne 28.08.2006 ...
podpis
Poděkování
Rád bych poděkoval Ing. Martinu Kosejkovi za vedení a podporu při tvorbě práce. Dále bych chtěl poděkovat Ivanu Tichému za poskytnutí podkladových materiálů a četné konzultace.
Poděkování patří také mým rodičům za podporu během studia.
Abstrakt
Předmětem zájmu bakalářské práce je problematika testování softwaru a jeho zpracování v metodice vývoje softwaru Rational Unified Process. Práce si klade za cíl seznámit čtenáře srozumitelnou formou s testováním softwaru a je z toho důvodu rozdělena na část teoretickou, ve které se nachází rozbor podstatných témat souvisejících s testováním a metodikou RUP, a část praktickou, obsahující pohled na testování podle metodiky RUP v praxi.
Úvodní kapitola teoretické části je věnována seznámení s hlavním tématem práce, kterým je testování softwaru. Obsahuje vysvětlení tohoto pojmu a poskytuje představu o problematice testování v širším měřítku. Pozornost je zaměřena na rozčlenění testů a objasnění některých dalších pojmů souvisejících s testováním. Pohledu do historie testování softwaru a změnám přístupu k testování je věnována samostatná kapitola, vysvětlující postupnou změnu názoru na prospěšnost testování a vývoj testování do dnešní podoby. Následující kapitola odpovídá na otázku, jaký význam má testování softwaru a proč by se mělo stát nedílnou složkou vývoje.
Kapitola nabízí posouzení hlavních výhod a nevýhod testování. Charakteristiky metodik a jejich použití při softwarovém vývoji jsou shrnuty v další kapitole, která rovněž nabízí seznámení s nejznámějšími modely vývoje softwaru, ze kterých metodiky vychází. Další kapitola slouží k detailnějšímu rozboru metodiky RUP jako celku. Je zaměřena na popis historie metodiky, klíčových myšlenek a pojmů, ze kterých metodika vychází, jsou zdůrazněny rozdíly v přístupu metodiky RUP a jiných modelů k procesu vývoje softwaru. Závěrečná kapitola teoretické části zpracovává problematiku testování podle metodiky RUP. Jsou rozebrány role členů v týmu, které jsou spojené s testováním. Obsaženo je rovněž vysvětlení cílů a významu disciplíny a vazby na zbylé disciplíny.
Praktická část práce je založena na zkušenostech s konkrétní realizací testů dle metodiky RUP. Nabízí pohled na komunikaci testerů se zbytkem projektu, metody evidence chyb v softwaru a jejich následnou rekonstrukci za účelem opravy chyb, popisuje možnosti spolupráce s vývojáři při řešení chyb. Na příkladech jsou znázorněny podoby dokumentů, které je možno použít jako podklady nebo jsou výsledkem testování. Poslední kapitola se věnuje automatizovanému testování, rozebírá principy fungování nástrojů určených pro automatizované testy a podmínky, za jakých je možné automatizované testy použít. Část kapitoly obsahuje praktickou ukázku vytvoření, provedení a vyhodnocení automatizovaného testu.
Abstract
This bachelor’s thesis deals with the issue of software testing and its form in Rational Unified Process software development methodology. The purpose of the thesis is to make reader familiar with software testing in an comprehensible way. Therefore the thesis is divided into theoretical section which provides an analysis of essential subjects related to software testing and RUP methodology and practical section containing an insight into practical testing solutions with the use of RUP.
The opening chapter is devoted to the main subject of the thesis, which is software testing.
It contains an explanation of the term and helps forming a broad conception of testing. Attention is also paid to different types of tests and clarifying some other terms connected with testing.
A separate chapter is dedicated to the history of software testing and development in the test approach, explains a change in opinion of testing benefit and the emergence of testing into present state. The importance of software testing and reasons for its existence as a part of software development are provided in following chapter, where the main testing advantages and disadvantages are also reviewed. Next chapter summarizes the features and use of methodologies in software development and offers a description of well known software development models serving as a basis for methodologies. The purpose of following chapter is to describe RUP methodology as a whole. It is focused on a history of the methodology, key principles and terms, which form its intellectual basis, also the differences of RUP and other methodologies in approach to software development process. The final chapter of the theoretical section covers the scope of testing in RUP methodology. Test team roles and related activities are reviewed, also the explanation of purpose and importance of testing discipline and described connections to other disciplines are present.
Practical section is based on an experience with test realization using RUP methodology.
Section's first chapter explains communication of testers with the rest of the project, methods of defect tracking and further defect reconstruction for the purpose of their correction, describes possible cooperation with developers fixing the defects. Using the examples, the possible forms of documents are presented that can be used as test inputs or come out as a result of testing. The last chapter is devoted to automated testing. It presents the operating principles of automated test tools and conditions of using an automated test. Part of the chapter contains a practical demonstration of creating, executing and evaluating an automated test.
Obsah
1 Úvod ... 1
2 Testování softwaru ... 2
2.1 Východiska pro existenci testování ... 2
2.2 Základní rozbor testování ... 4
2.2.1 Výklad pojmu ... 4
2.2.2 Struktura testů ... 5
2.2.3 Zabezpečení kvality ... 6
2.3 Kategorie v oblasti testování ... 7
2.3.1 Statické a dynamické testování ... 7
2.3.2 Úrovně testů ... 7
2.3.3 Testování černé a bílé skříňky ... 8
2.3.4 Zátěžové a výkonnostní testy ... 9
2.3.5 Manuální a automatizované testy ... 10
2.4 Cíl testování ... 10
2.5 Testové prostředí a realizace testování ... 10
3 Pohled do historie ... 12
3.1 Vývoj názoru na prospěšnost testování ... 12
3.2 Známé případy softwarových chyb ... 13
4 Přístup k testování ... 15
4.1 Argumenty proti testování ... 15
4.2 Argumenty pro testování ... 15
4.3 Zhodnocení ... 17
5 Použití metodik při vývoji softwaru ... 19
5.1 Význam metodik ... 19
5.2 Modely vývoje softwaru ... 20
5.2.1 Model velkého třesku ... 20
5.2.2 Vodopádový model ... 20
5.2.3 Spirálový model ... 21
6 Metodika RUP ... 22
6.1 Historie ... 22
6.2 Typické znaky ... 22
6.3 Nejlepší praktiky ... 23
6.3.1 Iterativní vývoj (Develop Iteratively) ... 23
6.3.2 Řízení požadavků (Manage Requirements) ... 24
6.3.3 Použití komponentových architektur (Use Component Architectures) ... 24
6.3.4 Vizuální modelování pomocí UML (Model Visually) ... 24
6.3.5 Průběžné ověřování kvality (Continuously Verify Quality) ... 25
6.3.6 Řízení změn (Manage Change) ... 25
6.4 Klíčové principy ... 25
6.5 Dynamické rozdělení metodiky ... 26
6.5.1 Zahajovací fáze ... 26
6.5.2 Přípravná fáze ... 27
6.5.3 Konstrukční fáze ... 27
6.5.4 Předávací fáze ... 28
6.6 Statické rozdělení metodiky ... 28
7 RUP a oblast testování ... 30
7.1 Význam a cíle testové disciplíny ... 30
7.2 Role v testové disciplíně ... 31
7.2.1 Tester ... 31
7.2.2 Analytik testů ... 33
7.2.3 Návrhář testů ... 36
7.2.4 Manažer testů ... 38
7.3 Vazby na další disciplíny ... 41
8 Testování v praxi ... 42
8.1 Podoby testových artefaktů ... 42
8.1.1 Testové skripty a testové logy ... 42
8.1.2 Evidence chyb ... 43
8.2 Testový tým ... 44
8.3 Komunikace se zbytkem projektu ... 45
9 Automatizované testování ... 47
9.1 Význam automatizovaného testování ... 47
9.2 Automatizované testování v metodice RUP ... 47
9.3 Realizace testu nástrojem Rational Robot ... 48
9.3.1 Generování skriptu ... 49
9.3.2 Úpravy skriptu ... 51
9.3.3 Spuštění testu a kontrola výsledků ... 52
9.4 Další nástroje pro automatizované testování ... 53
10 Závěr ... 54
Literatura ... 57
Terminologický slovník ... 59
Seznam ilustrací ... 67
1 Úvod
1 Úvod
K volbě daného tématu bakalářské práce jsem se rozhodl na základě vlastních zkušeností s testováním softwaru podle metodiky RUP, které jsem získal v praxi na pozici softwarového testera. Jelikož považuji oblast testování softwaru za perspektivní a v rámci budoucího povolání bych se testování softwaru rád věnoval, zvolil jsem téma také za účelem prohloubení a ujasnění si dosavadních znalostí, k čemuž jsem dosud neměl příležitost. Problematice testování softwaru je věnována nižší pozornost, než je tomu v případě programování a implementačních technologií obecně, což je potvrzeno horší dostupností informačních zdrojů o testování a metodice RUP (zejména v českém jazyce) a také slabším pokrytím tématu testování v závěrečných pracích. Tato skutečnost dále podpořila mé rozhodnutí ohledně výběru tématu.
Testování softwaru představuje důležitou součást softwarového vývoje, neboť s využitím množství odlišných testových postupů usiluje o to, že vyvíjený produkt bude splňovat požadavky zákazníka a uživatelů. Úsilí je při testování dále zaměřeno na zvýšení kvality produktu a na vyhledání chyb, které se v produktu vyskytují. Absence testování se nevyplácí, což dokazují i četné negativní zkušenosti se softwarem v minulosti. Proto je v současné době oblast testování zpracována ve většině metodik, které jsou při vývoji softwaru používány. V metodice RUP, která patří mezi osvědčená řešení v oblasti metodik a propaguje iterativní přístup k vývoji softwaru, je testování věnována patřičná pozornost.
Cílem této práce je seznámit čtenáře srozumitelnou formou s testováním softwaru, přičemž významná část práce bude věnována vysvětlení přístupu k testování v metodice RUP. Práce má z toho důvodu zhruba ze dvou třetin teoretickou část, ve které jsou zahrnuta podstatná témata související s testováním, která pokládám za potřebné zmínit před samotným rozborem otázky testování v rámci metodiky RUP. Pro pochopení problémové oblasti je nezbytné začít od základních pojmů, s jejichž jednoznačným výkladem jsem se dosud nesetkal, proto se v úvodu práce zaměřím na jejich objasnění a porovnám vysvětlení pojmů v různých zdrojích.
Dále provedu zhodnocení argumentů, které testování podporují nebo jsou naopak proti jeho použití a doporučím, zda při vývoji softwaru testovat či nikoliv. Teoretickou část zakončí rozbor metodiky RUP a zvláště testové disciplíny. Praktická část plynule navazuje na předchozí teoretické kapitoly a s využitím vlastních zkušeností nabídnu čtenáři pohled testera na skutečnou podobu týmu, testových dokumentů a komunikaci se zbytkem projektu. Upozorním také na obvyklé překážky při testování. Práce bude zakončena praktickou ukázkou tvorby, spuštění a vyhodnocení automatizovaného testu.
2 Testování softwaru
2 Testování softwaru
2.1 Východiska pro existenci testování
Použití výpočetní techniky přináší nezpochybnitelné výhody, jako je úspora času, peněz, lidských zdrojů a dalších specifických faktorů. Její nasazení představuje v drtivé většině případů přínos. Jsou však situace, kdy je třeba mít na paměti především rizika. Výpočetní technika a programové vybavení jsou produkty lidské činnosti a jak je zřejmé, lidé chybují. Pokud jsou ponechány stranou problémy technického charakteru, které postihují hardware a kterým je často obtížné předcházet, zůstává stále velký okruh potíží se softwarem, o nichž je možné tvrdit, že jsou způsobeny lidským faktorem. V oblastech, kde je korektní funkčnost nezbytná, by nesprávné chování softwaru mohlo vést k závažným následkům. Zejména ve zdravotnictví je bezchybné fungování softwaru důležité, protože v určitých případech může zajišťovat běh podpůrných životních systémů nebo pomáhat při náročných operačních zákrocích. Chyba v softwaru by tak mohla ohrozit lidský život. Dalším příkladem je finanční sektor, kde práce s citlivými osobními údaji a probíhající operace s penězi vyžadují spolehlivost a důkladné zabezpečení softwaru s ohledem na bezpečnostní rizika poslední doby. O vysokých nákladech v případě vzniku škody, kterou je následně příslušná finanční instituce nucena poškozenému uhradit, není třeba pochybovat. Možností výpočetní techniky v dnešní době využívá každá moderní armáda, řízení a automatizace různých výrobních provozů je v současnosti často zajišťováno právě pomocí počítačů, rovněž dopravní prostředky využívají software ve svých řídících systémech. Zmíněné příklady představují jen malý zlomek z celkového množství případů, ve kterých je kladen velký důraz na správné fungování softwaru.
Narůstající uplatnění výpočetní techniky je jednou z příčin, proč roste i množství problémů s použitím a vývojem softwaru. Důvodů je však více, zde je uvedeno shrnutí několika zásadních:
Především je nově vznikající software vždy o něco komplexnější, než jeho předchůdce.
Existuje přirozená tendence vytvářet a používat software, který bude univerzálnější, vybaven více funkčnostmi a bude podporovat pokud možno co největší procento činností v oblasti použití, do které bude nasazen. Názorným příkladem je nárůst počtu podniků, které disponují svými vlastními podnikovými informačními systémy, tzv. podnikovými portály. Tyto portály, představující konkrétní realizaci ERP systémů na míru podniku, pokrývají převážnou většinu úloh, které lze v podniku řešit pomocí počítače, a sjednocují je do jednoho informačního systému namísto použití více oddělených aplikací. Vytvoření takových systémů je náročné ve všech
2.1 Východiska pro existenci testování fázích a významně zvyšuje pravděpodobnost zanesení chyby. Proto je obvyklé řešit pořízení ERP systému nákupem osvědčeného produktu některé ze společností působících v této oblasti.
Nepsaným standardem jsou již delší dobu produkty společnosti SAP.
Uživatelská rozhraní již delší dobu nejsou realizována fyzicky na úrovni děrných štítků a pásků. Postupně došlo k přechodu od jednoduchých rozhraní dřívějšího softwaru, přes textový režim a ovládání pomocí příkazové řádky až ke grafickému uživatelskému rozhraní, které umožňuje implementovat do softwaru širokou škálu ovládacích prvků. Vytvoření jednoduše použitelného a správně fungujícího uživatelského rozhraní není jednoduchou záležitostí a je častou oblastí výskytu chyb. Zároveň narostl počet periferních zařízení, s jejichž přítomností musí mnohdy software počítat. Příkladem jsou hardwarové klíče k jednoznačné identifikaci uživatele v systému, sloužící při přihlašování nebo provádění zabezpečených operací, a další méně obvyklá zařízení.
Dále narostlo množství hardwarových konfigurací, na kterých musí být software schopen bez problému pracovat. Kupříkladu v oblasti procesorů existují souběžně modely s různými instrukčními sadami, 32-bitovými nebo 64-bitovými architekturami a různým počtem jader.
Podobná situace nastává také u dalších hardwarových komponent IS. Obdobně je tomu i v oblasti základního softwaru. Informační systémy využívající klient / server architekturu mají v mnoha případech prezentační vrstvu založenou na výstupu do WWW prohlížeče, jehož typ a konfiguraci na straně uživatele je výrobce softwaru jen stěží schopen ovlivnit. Bylo by tedy omylem předpokládat, že podmínky u každého klienta budou vždy totožné. Samotná klient / server architektura je náchylná k výskytu problémů už jen z toho důvodu, že k zajištění správného chodu je potřeba úspěšně zprovoznit nejen jednotlivé vrstvy zvlášť, ale také celý systém jako celek, což vyžaduje bezchybnou spolupráci vrstev. Pravděpodobnost výskytu problému se zvyšuje, jelikož jde o architekturu s více samostatnými vrstvami.
Fenoménem současnosti jsou informační systémy schopné nepřetržitého provozu, tedy umožňující plnit úlohy a uživatelské příkazy ve kteroukoliv chvíli. Přitom nepřetržitým provozem se rozumí spíše dostupnost s hodnotou blížící se sta procentům. Takový systém bývá obvykle plánovaně odstaven pouze na nezbytně krátkou dobu, která je zapotřebí pro úkony, jejichž charakter neumožňuje provedení za provozu. U špičkových systémů se z mnoha důvodů často smí doba takových odstávek pohybovat pouze v řádu desítek minut ročně. Z toho plyne, že po hardwarové i softwarové stránce musí být takové systémy co možná nejstabilnější. Opravy zásadních problémů, probíhající v časovém stresu až po nasazení systému do provozu, mohou stát obě strany, dodavatele a zadavatele, mnoho úsilí i peněz.
2.1 Východiska pro existenci testování Výčet všech problémů a potenciálních příčin jejich vzniku by tímto zdaleka neskončil.
Dále je nutno dodat, že některé zmiňované problémy nejsou otázkou posledních let, ale že se v počítačovém odvětví vyskytují již delší dobu. Je přirozené, že s jejich výskytem se souběžně začaly objevovat také následné snahy o jejich odstranění. Jako lepší řešení se však v mnoha ohledech jeví těmto problémům přímo předcházet. Již zdaleka nestačí spoléhat se pouze na základní a mnohdy zběžnou kontrolu provedené práce. Především výše zmiňované skutečnosti přispěly nevyhnutelně k tomu, že se s postupem času v odvětví softwarového vývoje vyvinula samostatná a v dnešní době již nepostradatelná oblast testování softwaru, která představuje jeden ze způsobů eliminace softwarových problémů již v počátečním stádiu jejich vzniku.
2.2 Základní rozbor testování
2.2.1 Výklad pojmu
Terminologie informačních systémů a informačních a komunikačních technologií nabízí různé přístupy k vysvětlení pojmu testování softwaru. Příčinou je proměnlivý význam tohoto slovního spojení v závislosti na tom, v jakém kontextu je použito.
Dotážeme-li se většího počtu jedinců nezasvěcených do problematiky, co si pod pojmem představí, odpověď bude nejspíše v mnoha případech znít, že se jedná o činnost spočívající v hledání chyb v softwaru, případně ve snaze uvést software do stavu, ve kterém se chová nestabilně a nepředvídatelně, a v evidenci veškerého nekorektního chování v těchto situacích.
Taková odpověď není vyloženě chybná, jako spíše neúplná. Jak je zmíněno v [MUL05], o testování existuje rozšířená představa, že sestává pouze z provádění testů, tj. provozování softwaru. To je sice částí testování, ale nejedná se o jedinou testovou aktivitu. Aktivity spojené s testováním existují před i po provádění testů. Pokud by testování softwaru bylo definováno výčtem aktivit, které jej představují, bylo by třeba výčet podstatně rozšířit. Ani pak by ale výsledek nebyl uspokojivý. [HAI02] uvádí, že jako testování je možno nazvat jakoukoliv aktivitu odhalující chování programu, které je v rozporu se specifikací požadavků. Pohlížet na testování softwaru při jeho popisu pouze jako na konečný souhrn několika samostatných činností se jako příliš vhodné nejeví, protože nelze s jistotou říci, že výčet aktivit bude úplný.
Poněkud odlišně k termínu přistupují definice, které testování softwaru považují za disciplínu či samostatný proces v rámci softwarového vývoje. Na základě takového přístupu definuje [WIKI1] testování softwaru jako proces napomáhající k identifikaci korektnosti, úplnosti, bezpečnosti a kvality vyvíjeného softwaru, případně dle [WHI00] jako proces
2.2 Základní rozbor testování
provozování softwarového systému za účelem stanovení, zda odpovídá specifikaci a běží v cílovém prostředí. Na již zmiňovaném srovnání zjištěného stavu systému se stavem požadovaným, jehož popis se nachází ve specifikaci, je postaveno také konkrétnější pojetí podle [SAM06], vysvětlující testování softwaru jako provádění testů s důrazem na stanovení, zda se systém a testovaná aplikace chová či nechová v souladu se specifikací požadavků.
Některá z uvedených vysvětlení vychází z pojmu test, který je možno obecně charakterizovat jako aktivitu, sloužící k potvrzení či vyvrácení očekávaných výsledků pozorováním [WIKI2]. Uplatnění testů v různých oblastech lidských činností vedlo k odlišným přizpůsobením pojmu. V provozech, kde jsou produkovány výrobky hmotné povahy, se lze setkat s popisem testu jako s relací, v průběhu které je produkt nebo část zařízení vystaveno každodenním nebo extrémním podmínkám a je zkoumána jeho životnost, atd. [WIKT1]
Pro potřeby této práce je však nutná především definice, vysvětlující test z pohledu softwarového. K tomuto účelu je vhodné vyjádření testu jako aktivity, v rámci které je systém nebo komponenta provozována za specifických podmínek, výsledky jsou sledovány a zaznamenávány a k určitému aspektu systému či komponenty je provedeno zhodnocení [UOU06].
Odlišnost mezi testováním softwaru a testem se může na první pohled jevit nejasná, protože oba pojmy se v definicích významově překrývají a jsou popisovány jako aktivity s obdobnými cíli.
Často dochází k jejich záměně a termíny „testování softwaru“ a „testy softwaru“ bývají pokládány za totožné. K objasnění si však stačí uvědomit vztah mezi oběma pojmy tím způsobem, že test je nástroj nacházející uplatnění při testování softwaru. Test představuje realizaci testování softwaru a je jedním, nikoliv však jediným z prostředků při použití testování softwaru v praxi.
2.2.2 Struktura testů
Podle [VEE05] struktura testu sestává z jednoho či více testových případů, které zdroj definuje jako sadu vstupních hodnot, podmínek před spuštěním, očekávaných výsledků a podmínek po spuštění, vytvořenou za určitým účelem či na základě testové podmínky, což je např. spuštění určité části programového kódu nebo ověření shody s určitým požadavkem.
Testové případy si lze představit jako základní stavební kameny, ze kterých je složen test.
Představují nejnižší úroveň při provádění testů, neboť jednotlivě u každého z mnoha prvků či vlastností softwaru jednoznačně rozhodují o tom, zda testem projdou úspěšně či nikoliv. Správně vytvořený testový případ by měl být formulován jako matematický výrok. Měl by tedy mít podobu tvrzení, o jehož pravdivosti je možno jednoznačně rozhodnout. Ukázku jednoduchého
2.2 Základní rozbor testování textového editoru, je například možné písemně formulovat následujícím způsobem:
„V dialogovém okně Odstavec se nachází combobox s popisem Zarovnání.“ Navazující případ může vypadat následovně: „V comboboxu s popisem Zarovnání je jako výchozí vybrána hodnota Automaticky.“ Testové případy mohou dále obsahovat doplňující informace, které napomáhají při provádění testu.
Ke kompletnímu zachycení softwaru nebo jeho určité části pro účely testu je obvykle potřeba velké množství testových případů. Stejně jako je i software z různých hledisek strukturován, lze také testové případy odlišovat podle toho, k jaké části softwaru náleží či jak spolu jinak logicky souvisí. Může být vhodné rozdělit testové případy podle jejich příslušnosti ke komponentě, modulu, ale také k případům užití, definovaným v [VEE05] jako sekvenci transakcí v dialogu mezi uživatelem a systémem s konkrétním výsledkem. Smyslem takových rozdělení je vytvoření skupin testových případů, které mohou být použity jako samostatné testy nebo mohou vytvářet v kombinaci s dalšími skupinami testových případů různé sady testů na míru podle aktuálních potřeb při testování softwaru. V ideálním případě je dosaženo stavu, kdy ke každé významné části softwaru existuje zvláštní skupina testových případů, která představuje test této části.
Při pokračování ve výše uvedené ukázce tak může mít význam například odlišení skupiny testových případů, které zpracovávají veškeré ovládací prvky v dialogovém okně Odstavec.
Takto vytvořenou sadu testových případů, případně doplněnou o další nezbytné prvky, je možné považovat za test, konkrétně za GUI test dialogového okna Odstavec. Testy lze dále seskupovat do testových suit. [VEE05] vymezuje testovou suitu jako sadu několika testových případů k testované komponentě či systému, kde podmínka po spuštění jednoho testu je často použita jako podmínka před spuštěním dalšího. Toto pojetí je založeno na předpokladu, který již byl zmíněn – tedy že test představuje několik testových případů. Další zdroj se již o testové suitě zmiňuje jako o sadě souvisejících testů, obvykle příslušející skupině vlastností nebo softwarové komponentě a obvykle vymezené stejnou databází [UOU06].
2.2.3 Zabezpečení kvality
V souvislosti s testováním softwaru bývá zmiňován další pojem, kterým je zabezpečení kvality. Lze setkat s případy, kdy dochází k nesprávnému použití a zaměňování obou termínů, přitom jejich významy jsou do jisté míry odlišné. Zabezpečení kvality představuje významnou složku komplexního řízení jakosti, vychází z mezinárodních ISO standardů ISO 9000 a ISO 9001, hojně využívá statistické metody a nezabývá se konkrétním produktem, ale zaměřuje se na celý proces, jehož je produkt výsledkem. V případě softwaru se tedy zabezpečení kvality týká
2.2 Základní rozbor testování
celého procesu softwarového vývoje - monitorování a zdokonalování procesu, ověřování, zda jsou dodržovány sjednané standardy a procedury, a dohledu na tím, že nalezené problémy jsou řešeny [HOW05]. Jak autor dále zmiňuje, zabezpečení kvality je především otázkou prevence.
Termínu testování spíše v oblasti komplexního řízení jakosti odpovídá termín kontrola kvality, vyjadřující sledování kvality produktu.
2.3 Kategorie v oblasti testování
2.3.1 Statické a dynamické testování
Zábor testování, co se činností týče, je široký a je tedy možno z různých hledisek testování dále třídit do kategorií. Za asi nejvýraznější rozdělení testovací disciplíny lze považovat členění na statické a dynamické testování. Toto rozčlenění vychází z otázky, zda test má či nemá povahu provozování softwaru. Do statického testování náleží úkony, prováděné převážně v raných fázích procesu softwarového vývoje, kdy vývoj softwaru dosud nebyl dokončen. Jedná se především o kontroly specifikace požadavků a analýzu zdrojového kódu. V pozdních fázích může jít o kontroly dokumentace a dalších součástí, které budou dodány spolu s aplikací.
Dynamické testování je někdy chápáno jako testování v užším slova smyslu, protože představuje hlavní pilíř testování a je více rozšířené. Zatímco statické testování zahrnuje testy, které nevyžadují běh softwaru, při dynamickém testování je software spuštěn a testy jsou zaměřeny na jeho provoz.
2.3.2 Úrovně testů
Na rozčlenění testů je možno pohlížet také z hlediska jejich výskytu v čase. Výsledek tohoto rozčlenění je označován jako tzv. úrovně testů. Tento pohled je odvozen z typické posloupnosti etap při tvorbě softwaru, kdy jsou nejprve vytvářeny samostatné softwarové moduly a komponenty budoucího systému, následně jsou integrovány do systému, čímž po čase vzniká kompletní produkt. V tomto pořadí tak nejdříve nastupují unit testy, což jsou testy věnované jednotlivým komponentám nebo jinak odlišitelným součástem ve vyvíjeném produktu.
Jedná se o testy, často probíhající v uměle vytvořeném okolí, které součásti poskytuje nezbytné vstupy a sleduje výstupy. Tyto testy bývají obvykle z důvodu výraznějšího zaměření na zdrojový kód prováděny ve spolupráci s vývojáři, kteří jsou za příslušnou část kódu odpovědní.
Začlenění modulů a komponent do systému a spolupráci mezi nimi za účelem bezchybné funkčnosti v systému se věnují integrační testy. Tyto testy sledují vyvíjený a kompletovaný systém a dále se dělí na integrační testy komponent, soustředěné na korektní spolupráci
2.3 Kategorie v oblasti testování
systémové integrační testy, provádějící kontrolu, zda systém bez problému spolupracuje se svým okolím, například při výměně dat s dalšími systémy a aplikacemi po síti. Integrační testy lze provádět již v raných fázích vývoje, obvykle ve chvíli, kdy je jádro softwaru provozuschopné a je možné k němu připojovat moduly a komponenty sloužící k rozšíření softwaru.
Po fázi integračních testů nastupuje další etapa spočívající v systémových testech. Nutnou podmínkou této etapy je dokončený systém, který je předán k testu. Test je zaměřen na ověření, zda systém není v rozporu se všemi sjednanými požadavky a parametry, které bývají uváděny ve specifikacích požadavků. Na rozdíl od integračních testů je tedy v rámci systémového testu zkoumán kompletní systém. Vzhledem k tomu, že jde o testy, na jejichž výsledcích významně závisí, zda bude software posléze předán zadavateli a hlavní vývoj ukončen, je škála použitých testovacích metod široká. Lze se setkat s množstvím neobvyklých testů, jež jsou založeny výhradně na snaze vyvolat chyby v softwaru úmyslně, a to například nekorektním chováním a netradičními postupy. Testy tohoto typu jsou označovány jako testy selháním. Jejich podstata spočívá ve zjišťování, zda se v softwaru nevyskytnou chyby, pokud se budeme snažit jednat v rozporu s pravidly a požadavky danými ve specifikaci produktu. Opačný postup je nazýván testy splněním a vyznačuje se prováděním pouze takových úkonů, potvrzujících chování a reakce softwaru popsané ve specifikaci, viz [PAT02].
Pokud jsou systémové testy v pořádku ukončeny, nastává závěrečná fáze uživatelských akceptačních testů. Na rozdíl od předchozích není v této fázi hlavním úkolem nalézt v softwaru chyby, ale spíše shodu se zadavatelem v otázce, zda software splňuje požadavky, na kterých se dodavatel se zadavatelem dohodli. Do provedení akceptačních testů se obvykle zapojují budoucí uživatelé softwaru, což s sebou přináší výhody. V softwaru tak mohou být objeveny problémy, na které se v dosud proběhlých testech nepřišlo. Především proto, že pohled vývojářů, testerů a dalších členů dodavatelského týmu může být do jisté míry zkreslen jejich profesním zaměřením a dosavadní usilovnou prací na softwaru, navíc k vyvíjenému produktu přistupují odlišně jak uživatel s laickými znalostmi softwarové problematiky. Z těchto skutečností vychází také fenomén nezávislých testů. Akceptační testy bývají obvykle prováděny v prostředí zadavatele, jehož vlastnosti jsou již totožné nebo podobné vlastnostem prostředí, kde bude systém v konečné podobě provozován.
2.3.3 Testování černé a bílé skříňky
Je vhodné zmínit podstatný pohled na rozdělení testů, založený na tom, z jaké pozice k softwaru tester přistupuje a na jaké úrovni testování probíhá. Pokud má tester k dispozici software bez možnosti kontroly jeho zdrojového kódu, je v takovém případě odkázán především
2.3 Kategorie v oblasti testování na specifikaci požadavků a testování provádí z pozice běžného uživatele. Zkoumáním funkčnosti softwaru a porovnáváním zjištěných výsledků oproti definovaným požadavkům ze specifikace je bez znalostí vnitřní struktury softwaru schopen posoudit, zda software obsahuje chybu. Takové testování se označuje jako testování černé skříňky nebo také funkční testování. Název je odvozen z vizuální představy softwaru jako černé skříňky, jejíž obsah, v případě softwaru tedy zdrojový kód, není zvenčí viditelný a tester tak nezná pochody uvnitř skříňky, kterými bylo na základě jím vložených vstupů dosaženo vzniklých výsledků na výstupu ze skříňky. Odlišný charakter má testování bílé skříňky, založené na analýze zdrojového kódu. Tester je seznámen s vnitřní strukturou softwaru či jeho testované části a v průběhu testu používá taková testová data a postupy, aby obsáhl pokud možno všechny průchody zdrojovým kódem, otestoval hraniční hodnoty použitých proměnných, zkontroloval, zda se software korektně zachová po obdržení neočekávaných vstupních hodnot, a provedl některé další testy, které vycházejí z kontroly zdrojového kódu. Kombinace obou přístupů bývá nazývána jako testování šedé skříňky a v praxi se může jednat o situaci, kdy tester jedná z pozice uživatele a provádí test softwaru pomocí uživatelského rozhraní, přičemž výsledky operací navíc kontroluje pomocí dotazů na databázi, prověřuje, zda se podařil zápis do souboru, nebo sleduje události zapsané do různých typů log souborů.
2.3.4 Zátěžové a výkonnostní testy
V odvětví softwarového testování bývají používány také další dva typy testů, které spolu v určitých rysech souvisejí. Jedná se o zátěžové a výkonnostní testy. Mezi společné znaky lze zařadit jejich zaměření na běh softwaru při určité zátěži. Zátěž softwaru lze obecně definovat jako procento využití systémových prostředků, případně po odvození jako stav, kdy je do softwaru přihlášen daný počet uživatelů, nebo software naráz zpracovává daný počet operací.
Zátěžové testy mají za úkol prověřit chování softwaru, pokud zátěž dosahuje takových hodnot, při kterých se doba odezvy softwaru blíží či překračuje horní hranici stanovenou ve specifikaci požadavků. Častým výstupem zátěžových testů je určitým způsobem kvantifikovaná zátěž, při které bylo ještě dosaženo přijatelných hodnot odezev. Úkolem výkonnostních testů je sledování doby odezev softwaru při proměnlivé zátěži a trendů při změnách zátěže. Dále pak nalezení problematických částí softwaru, způsobujících největší nárůst doby odezev při zátěži.
Výkonnostní i zátěžové testy bývají nejčastěji řešeny za pomoci automatizovaných nástrojů.
2.3 Kategorie v oblasti testování
2.3.5 Manuální a automatizované testy
V praktické části bude uvedeno ještě jedno významné rozdělení, a to konkrétně na manuální a automatizované testy. Rozbor v předcházejících odstavcích tak nabídl pohled na nejobvyklejší typy testů, se kterými se lze v oblasti testování softwaru setkat. Přitom je běžné, že konkrétní test může svými vlastnostmi odpovídat více zmíněným kategoriím najednou. Například revize zdrojového kódu určitého modulu může být zařazena do kategorie statického testování, protože software po dobu testu neběží, a zároveň se jedná o revizi samostatného modulu, proto jde o unit test. Rovněž je z povahy revize zdrojového kódu zřejmé, že jde o test bílé skříňky.
2.4 Cíl testování
Jako hlavní poslání při testování softwaru je nejčastěji zmiňováno ověřování shody se specifikací požadavků. Pokud se v průběhu testování softwaru vyskytne rozpor se specifikací, bývá zvykem označovat nález jednoduše jako chybu. V [VEE05] je chyba definována jako vada v komponentě nebo systému, která může způsobit selhání komponenty nebo systému při plnění požadované funkce, např. chybnou zprávu nebo definici údajů. Chyba, která nastane během provozu, může způsobit poruchu komponenty nebo systému. Z definice lze vyčíst, že chyba způsobuje selhání softwaru. Pokud se k pojmu softwarové chyby přistoupí obecněji jako k rozporu se specifikovanými požadavky, může být chybou označeno mnohem širší spektrum případů. Jako názorný příklad lze zmínit funkčnost softwaru, která není ve specifikaci uvedena a přesto se v softwaru nachází. Tato funkčnost přitom může být z hlediska zdrojového kódu naprosto v pořádku, její realizace v softwaru je bezproblémová a pro uživatele představuje přínos, přesto je nutné ji zařadit mezi chyby. Později může být buď po dohodě se zadavatelem dodatečně zařazena do specifikace požadavků a stát se plnohodnotnou součástí softwaru, nebo odstraněna ze softwaru. V obou případech je však do rozhodnutí vedena jako chyba. Stejně tak může být za chybu považováno, pokud je software po funkční stránce bezchybný, ale neodpovídá specifikovaným požadavkům na výkon při běžném provozu či zvýšené zátěži.
2.5 Testové prostředí a realizace testování
Testování softwaru je u dodavatele podmíněno existencí testovacího týmu, obvykle složeného z test manažerů, test architektů a testerů, který zajišťuje testování softwaru ve všech fázích projektu. Jeho podoba splňující požadavky metodiky RUP je podrobněji popsána v 7. a 8. kapitole. Aby mělo testování softwaru smysl, je nezbytné dodržovat předem sjednaná pravidla a postupy při testování. Toho se obvykle dosahuje použitím určité metodiky. Nasazení některých typů testů, zejména pak automatizovaných, zátěžových a výkonnostních, také
2.5 Testové prostředí a realizace testování nezbytně vyžaduje použití speciálních testovacích nástrojů, jejichž provozní licence jsou mnohdy značně finančně náročné na pořízení, především u plnohodnotných komerčních produktů zavedených značek. Zajištění licence na provoz takových nástrojů může nepříznivě ovlivnit rozpočet projektu a prodejní cenu vyvíjeného produktu, proto bývá rozsah testování softwaru podrobně stanoven po dohodě se zadavatelem. V každém případě by mělo být pro účely testování na straně dodavatele (podle potřeby i u zadavatele) vyčleněno testové prostředí, na kterém budou prováděny testy a kde poběží aktuální verze softwaru, určená k testování.
Smyslem existence samostatného prostředí pro testy je oddělení vývojářských aktivit od aktivit testovacího týmu, které jsou odlišné povahy. Pokud vývoj i testy probíhají zvlášť, nedochází ke konfliktům, jako například k testování modulu, na kterém momentálně probíhá ladění, či k nucenému přerušení testů z důvodů restartu služeb, databáze nebo aplikačního serveru, změn konfigurace a dalších. Úkolem zadavatele je pak v procesu testování především poskytování součinnosti při provádění testů a dalších úkonech souvisejících s testováním. Výraznější zapojení probíhá ve fázi uživatelských akceptačních testů.
Testování bývá obvykle prováděno dodavatelem softwaru. Je však možné (a v praxi se tak často z různých důvodů děje, ať už z iniciativy dodavatele či zadavatele) zajistit fázi testování pomocí outsourcingu, tedy přenechat testování specializované firmě, která disponuje potřebným know-how, nástroji a kvalifikovanými specialisty. Externí zajištění testů může představovat náhradu za testy, které by jinak prováděl dodavatel softwaru, nebo se může jednat o doplňující formu v podobě nezávislých testů, která má za úkol znovu prověřit již jednou testovaný software. Nezávislé testování si zadavatel v některých případech dodatečně provádí sám nad rámec standardního rozsahu uživatelských akceptačních testů, zejména pokud jde o software, jehož oblast použití vyžaduje věnování zvláštního důrazu bezchybnosti softwaru (např. systém zpracovávající komplikovanou obchodní problematiku).
3 Pohled do historie
3 Pohled do historie
3.1 Vývoj názoru na prospěšnost testování
Z historického hlediska je možné testování softwaru nazvat relativně mladou disciplínou, jelikož její počátky lze dle [WIKI3] časově zařadit do období vzniku profese softwarového inženýrství, tedy do 60. až 70. let 20. století. Do této doby se vývoj softwaru omezoval na aktivity, v současné době řazené do implementační fáze softwarového vývoje. Další činnosti, tvořící dnes zbylé fáze, nebyly považovány za důležité nebo jejich realizace představovala pouze doplněk k programátorské činnosti. Tvorbou softwaru se tak rozumělo výhradně programování.
Dřívější software byl, co se náročnosti implementace týče, jednodušší jak software vznikající nyní a rozsáhlé systémy byly často dílem malého počtu programátorů. V týmech, složených z několika jedinců, si obvykle každý člen kontroloval výsledky své práce nebo probíhala mezi členy navzájem alespoň základní kontrola zdrojového kódu. Tyto činnosti se vyvinuly do dnešní podoby unit testů.
Dlouhou dobu bylo testování softwaru opomíjeno a nepřikládal se mu nijak zvláštní význam. Testerem se tak častokrát stával až zadavatel, na kterého bylo v podstatě testování přesunuto předáním softwaru do provozu a který nekorektní chování softwaru objevil při jeho používání. Za pomocí cyklů, při kterých zadavatel předával připomínky a chyby nazpět dodavateli k vyřešení, se software postupně přibližoval požadovanému stavu. Až výskyt zásadních problémů v průběhu softwarové krize přispěl ke změně pohledu na softwarové testování, viz [WIKI3]. V současné době je již testování pokládáno za nezbytnou fázi při vývoji softwaru a je obsaženo prakticky ve všech používaných metodikách vývoje, přičemž například metodika vývoje řízeného testy je na principech testování přímo založena.
Změnu přístupu k testování v průběhu času je také možné vhodně znázornit ukazatelem poměru mezi počty vývojářů a testerů v týmu, který bývá používán jako informační údaj o projektu. V počátcích softwarového testování bylo běžné, pokud údaj činil 10:1 a více, tedy když na skupinu deseti nebo více vývojářů připadal jeden tester. Ten pochopitelně nemohl být schopen zajistit testování v takovém rozsahu a kvalitě, jak je dnes obvyklé, a většinou pouze zběžně kontroloval software z pohledu uživatele, zejména pomocí testů splněním. Neúnosné množství chyb a z toho plynoucí neúspěchy velkého počtu projektů v 70. a 80. letech vedly k přehodnocení potřeby testování a hodnoty ukazatele se zvolna posouvaly do příznivější oblasti s větším podílem testerů. Podle [MOI03] například Microsoft v 80. letech po výrazném nárůstu chyb a stupňujících se problémech s ranou verzí textového editoru Word, jehož vývoj musel být předčasně ukončen, přistoupil k poměru 1:1. V současné době se můžeme často setkat
3.1 Vývoj názoru na prospěšnost testování s poměrem 3:1, nejsou však výjimkou ani případy, kdy na jednoho vývojáře připadá více testerů.
K otázce volby správného poměru ale [RIC06] dodává, že univerzální poměr neexistuje, neboť se vše odvíjí od specifik jednotlivých softwarových projektů, jejichž požadavky na testování se přirozeně liší.
3.2 Známé případy softwarových chyb
S vývojem testování softwaru je spojeno množství případů, kdy chyby v softwaru vedly či mohly vést k závažným následkům. Velké pozornosti jsou již tradičně vystaveny mise spojené s objevováním vesmíru, a tak jsou neúspěchy v této oblasti obzvlášť viditelné. Mezi mise, jejichž neúspěch zavinila softwarová chyba, je dle [WIKI4] řazena například sonda Mariner 1, která měla za úkol provést v roce 1962 průlet kolem planety Venuše. Po startu se však u nosné rakety vyskytl problém s anténou, sloužící pro komunikaci s pozemními naváděcími systémy, a kontrolu nad raketou převzal palubní počítač. Jak se později ukázalo, při přepisu programových příkazů z ručně psané specifikace do počítače došlo k překlepu, který způsobil i při zanedbatelných vychýleních z kursu nepřiměřené vyrovnávací manévry počítače, které nakonec vedly k nekontrolovatelné změně kursu směrem k zemskému povrchu a raketa musela být dálkově zničena. Neúspěšně z důvodu chyb v softwaru skončily také obě mise programu Mars Surveyor v roce 1998, kdy v případě modulu Mars Polar Lander software pravděpodobně zaznamenal otřesy při vysouvání přistávacích ramen, vyhodnotil je nesprávně jako dotek se zemí a ve výšce 40 metrů nad povrchem Marsu vypnul přistávací motory, což způsobilo volný pád a zničení modulu při dopadu. V případě modulu Mars Climate Orbiter došlo k chybě při navigaci, kdy byly v palubním počítači očekávány hodnoty jednotek metrického systému a systémy na Zemi poskytly sice správné hodnoty, ale v imperiálním anglickém systému. Následkem toho modul vstoupil na orbitální dráhu v nízké výšce a nevydržel odpor atmosféry.
Jeden z nejzávažnějších softwarových problémů, který způsobil také ztrátu nejméně pěti lidských životů, je případ částicového urychlovače Therac-25 (viz [WIKI5]), používaného v letech 1985 až 1987 k léčbě rakoviny pomocí radioterapie. Předchozí model Therac-20 využíval ochranné prvky na elektromechanickém principu, které byly v novém modelu nahrazeny softwarem, jež byl pokládán za spolehlivější. Přístroj byl schopen provozu ve dvou módech, přičemž první mód slabě emitoval přímý elektronový paprsek na krátkou dobu, zatímco druhý mód využíval silného proudu elektronů, které se upravily na bezpečné rentgenové záření umístěním několika prvků v dráze paprsku. Chyba, vyskytující se nedopatřením v softwaru, umožňovala spustit druhý mód, aniž by se do dráhy paprsku zasunuly potřebné bezpečnostní
3.2 Známé případy softwarových chyb prvky, nezbytné k rozptýlení a filtraci částic. Pacienti tak mohli být vystaveni smrtelné dávce záření. Bylo uvedeno, že jednou z hlavních příčin selhání byla absence nezávisle provedené kontroly zdrojového kódu a vynechání softwaru při tvorbě bezpečnostního návrhu.
4 Přístup k testování
4 Přístup k testování
4.1 Argumenty proti testování
Mnohé softwarové společnosti však i v dnešní době považují testování softwaru za nepotřebné a pro vynechání testů se obvykle vyskytují argumenty, pokládající například samotnou existenci testování za důvod vzniku chyb v softwaru. Jako příčina je uváděno vědomí následné kontroly prováděné testovacím týmem, které u zbývajících členů v projektu nevytváří potřebu klást důraz na tvorbu bezchybného produktu.
Dalším často uváděným argumentem pro vynechání testů je již popsaná praktika přesunu testů na zadavatele, která se zachovala z dřívějších dob. Umožňuje zredukování členů na projektu díky absenci testového týmu, což snižuje náklady na projektu. Používání softwaru a hlášení chyb zadavatelem může být výhodné i z toho důvodu, že testy provádí skuteční uživatelé se skutečnými potřebami a požadavky na systém. Počet uživatelů produktu je obvykle vyšší jak počet testerů, kteří by jinak produkt testovali. Uživatelé mají k dispozici větší množství softwarových i hardwarových konfigurací, mají různé návyky a způsoby práce se softwarem, a šance na nalezení chyb v produktu jsou tak vyšší. Rovněž lze snadno prověřit chování systému při skutečné zátěži.
Vynechání testů je někdy u softwaru distribuovaného pomocí internetových technologií zdůvodňováno možností rychlé opravy chyb. Provedené změny na straně serveru, který má dodavatel softwaru snadno přístupný, se během krátké doby projeví u všech uživatelů, kteří software používají. Také u aplikací, běžících pouze na straně klienta, je uskutečnění oprav možné díky aktualizaci pomocí internetu.
Pokud není při vývoji softwaru použito testování, může se celý proces vývoje značně urychlit, protože testování je zejména v pozdějších fázích projektu časově náročné. Uvedené argumenty proti použití testování jsou převzaty ze [SPO00].
4.2 Argumenty pro testování
Softwarový projekt, v jehož rámci je již od počátku prováděno testování, je mnohem méně náchylný k překročení časového i finančního rozpočtu díky nalezení převážné většiny chyb a jejich opravě před nasazením softwaru do provozu. Pokud jsou testy opomenuty, nelze po nalezení chyb za provozu zabránit zásahům v prostředí zákazníka do běžícího a používaného softwaru, který je za účelem opravy chyb často potřeba dočasně pozastavit. Pokud je zákazník na
4.2 Argumenty pro testování funkčnostech softwaru závislý a dočasné náhradní řešení v jiné formě neexistuje, vznikají neplánované prostoje, obchodní ztráty a jiné škody, jejichž úhradu zákazník může po dodavateli softwaru požadovat.
Nezanedbatelná je také informační role testování, umožňující sledovat aktuální stav ukazatelů kvality. Testování, pokud jsou využity všechny hlavní kategorie, poskytuje informace o základních rozměrech kvality, označovaných zkratkou FURPS – funkčnost (functionality), použitelnost (usability), spolehlivost (reliability), výkonnost (performance) a obsluhovatelnost (supportability).
V reakci na první argument proti testování je třeba dodat, že softwarové chyby vznikají naprosto neúmyslně, bez ohledu na to, zda se počítá s pozdějším provedením testů. Jejich vzniku nelze zcela zabránit jak při použití testování, tak bez něj, a to i při sebevětší snaze členů projektu se chyb vyvarovat. Pouze při testování však lze existenci chyb v produktu včas odhalit, což patrně nejzásadnější z důvodů pro jeho použití.
Přesun testů na zadavatele může posloužit jako náhrada za interní testy, ale zadavateli je předkládán produkt, ve kterém se může nacházet množství chyb, což nijak nepřispívá k vytvoření dobrého jména společnosti. Softwarový trh je již delší dobu možné popisovat jako silně konkurenční prostředí. Pokud dříve platilo, že v oboru existovalo pouze několik významných dodavatelů, schopných produkovat použitelný software, kteří měli případně i možnost určovat si podmínky, za jakých bude software pro zadavatele vytvořen, v současnosti již nic nebrání zákazníkovi poptávajícímu software zvolit si takového dodavatele, který nabídne co možná nejkvalitnější produkt. O kvalitě dodávaného produktu velkou měrou rozhoduje právě použití testování, které dodavateli poskytuje konkurenční výhodu oproti jiným softwarovým společnostem, jejichž produkt neprošel testy. Jde tak o další důvod, proč testování využít.
K zajištění opravy případných chyb, které zadavatel nalezne, musí být na projektu i po ukončení implementace stále k dispozici členové vývojářského týmu, případně i další, což projekt dále prodražuje. Proto je vhodné s testováním začít co možná nejdříve po zahájení projektu. Skutečnost, že čím později se chyba v softwaru vyskytne, tím dražší je její odstranění, je zachycena následujícím grafem, viz Ilustrace 1.
4.3 Zhodnocení
4.3 Zhodnocení
Porovnání argumentů vede k závěru, který hovoří ve prospěch použití testování při vývoji softwaru. Pouze ve výjimečných případech, jako je například vývoj vlastního softwaru pro interní potřeby společnosti, může vynechání testů přinášet výhody. Vyjmenované argumenty proti testování se dají snadno vyvrátit, neboť obvykle přehlížejí zásadní skutečnost – výskytu chyb v softwaru se nelze vyvarovat. Při testování je však možné chyby vyhledat a předat k odstranění. Rovněž další služby, jako je poskytování informací o shodě s požadavky zadavatele a zhodnocení kvality, jsou nepostradatelné. Shrnutí nejdůležitějších výhod a nevýhod testování se nachází v následující tabulce:
Použití testování
PRO PROTI
- kontroluje splnění požadavků zadavatele - vede ke sníženému úsilí ostatních disciplín - zajišťuje tvorbu kvalitního produktu - je drahé a časově náročné
- umožňuje včasné nalezení chyb - testy mohou lépe provést skuteční uživatelé - přispívá k dodržení projektového rozpočtu - není nutné, opravu lze ihned šířit po internetu - informuje o kvalitativních ukazatelích - nezaručuje bezchybnost produktu
- vytváří dobré jméno společnosti
K zachování objektivity je nutné dodat, že prakticky není v silách testových týmů nalézt veškeré chyby, které se v softwaru vyskytují. Důvodem je obrovské množství stavů, událostí, Ilustrace 1: Náklady na odstranění chyby versus fáze projektu
4.3 Zhodnocení souvisí i nemožnost jejich úplného pokrytí testovacími případy, které by některé těžko zjistitelné chyby odhalily. Testy tak vždy zahrnují pouze více či méně předvídatelné případy a rozsah pokrytí se odvíjí od časového harmonogramu celého projektu, resp. jen fáze testování. Při zpožděních projektu bývá zvykem za účelem dodržení předávacího termínu operativně zkracovat fázi testování, což pokrytí softwaru testy rovněž výrazně ovlivňuje.
Výše uvedený graf (viz Ilustrace 2) zjednodušeně znázorňuje kompromis, vznikající při určování doby trvání testovací fáze, kdy je třeba pro zachování rozumné délky fáze podstoupit riziko, že určité procento chyb zůstane neodhaleno. Pokud by k testování vůbec nedošlo, můžeme veškeré chyby v softwaru považovat za nenalezené. S rostoucí dobou testování je zpočátku interval mezi objevením nové chyby krátký a v pozdějších fázích se již doba k nalezení každé další chyby zvětšuje. Je tak potřeba zvolit jen takový rozsah testování, jehož přínos pro dodavatele softwaru bude vyšší jak náklady na jeho provedení nebo na opravu chyb.
Ilustrace 2: Závislost procenta nalezených chyb na době testování
5 Použití metodik při vývoji softwaru
5 Použití metodik při vývoji softwaru
5.1 Význam metodik
Vývoj softwaru je složitý proces, jehož úspěšné zvládnutí vyžaduje věnování pozornosti mnoha skutečnostem ve všech fázích vývoje. Aby výsledkem projektu byl kvalitní software, který je dodán v termínu a za dohodnutou cenu, je nezbytné celý proces naplánovat, což obnáší vytvoření závazných pravidel, stanovení používaných postupů, dokumentů a nástrojů, rozdělení kompetencí mezi členy projektu, vypracování rozpočtu a množství dalších úkonů, které jsou samotné časově náročné. Přitom se softwarové projekty, jejich cíle a charakteristiky, ale také rizika, často velmi podobají. Na této skutečnosti jsou pak postaveny metodiky vývoje softwaru.
Jak je definováno v [MON06], metodiku lze v kontextu informačních technologií chápat jako osvědčené procesy, dodržované při plánování, vymezení, analýze, návrhu, sestavení, testování a implementaci systému. Při použití metodik je vývoj softwaru usnadněn tím, že metodika poskytuje již připravené a v praxi ověřené procesní modely, z nichž přizpůsobením konkrétnímu projektu vznikají jednoduše použitelné procesy. Pro většinu metodik je společné, že rozdělují proces vývoje do snadno odlišitelných fází, zakončených milníky. Často se lze také setkat s různě formulovanými doporučeními, které mají podobu krátkých a výstižných hesel a představují myšlenkový základ celé metodiky.
Protože vytvoření použitelné a kvalitní metodiky není jednoduché, bývá ve většině případů pořízena jako hotový produkt specializované firmy, případně (zejména pro velké společnosti) vznikají zcela nové metodiky na míru. Přestože tato investice představuje v okamžiku pořízení pro softwarovou společnost vysokou finanční zátěž, doprovázenou dalšími problémy s přechodem na novou metodiku, tak již po několika projektech se pořízení metodiky začne podniku vyplácet. K použití metodik [CHA05] zmiňuje, že složitým problémem při výběru a dodržování metodiky je činit tak s rozumem - poskytnout dostatek procesních disciplín k zajištění kvality vedoucí k obchodnímu úspěchu, ale zároveň se vyvarovat kroků, které představují ztrátu času, snižují produktivitu, demoralizují vývojáře a vytvářejí nepotřebnou administrativu.
Nejlepším přístupem při použití metodiky je považovat ji za nástroj k ovládání rizik.
5.2 Modely vývoje softwaru
5.2 Modely vývoje softwaru
V současnosti používaných metodik je velké množství, a proto je při jejich členění využito rozlišení podle modelu, který metodika používá pro návrh procesu softwarového vývoje. Výčet začíná paradoxně modelem, ze kterého žádná ze seriózních metodik patrně nikdy čerpat nebude, a jeho popis se zde nachází spíše pro úplnost a možnost porovnání s dalšími přístupy. Jedná se o model velkého třesku (big-bang model).
5.2.1 Model velkého třesku
Při použití modelu velkého třesku je veškeré úsilí při vývoji softwaru již od počátku projektu věnováno implementaci produktu, viz [PAT02]. Vývoj produktu je po zadání soustředěn na programování kódu, které má být provedeno co nejrychleji, s využitím všech dostupných zdrojů a bez zbytečných prodlev. Plánování, analýza a návrh jsou omezeny na minimum, stejně tak testování, které je prováděno pouze zběžně před odevzdáním produktu zadavateli. Tento způsob vývoje byl v minulosti velice oblíbený a jak [PAT02] uvádí, v určitých případech má jeho použití opodstatnění i dnes, například pokud vstupní požadavky na produkt nejsou příliš dobře srozumitelné a datum konečného odevzdání je hodně volné.
Nesrozumitelnost vstupních požadavků ale v tomto případě znamená nejasnou představu ze strany zadavatele, který si produkt objednal a je si vědom toho, že z nepřesných požadavků, které jsou definovány neformálně, může vzniknout mnoho variant řešení. Dodavatel však nemůže postavit obhajobu špatného produktu na nesrozumitelných požadavcích. Zejména pokud zanedbal komunikaci se zadavatelem v úvodní fázi projektu, kdy byla vytvářena specifikace požadavků, a zadavatel měl přitom o podobě produktu jasnou představu.
5.2.2 Vodopádový model
Nejdéle existující model v oblasti softwarového vývoje bývá nazýván jako vodopádový model (waterfall model). Jeho název vychází z vizuální představy modelu (viz Ilustrace 3), která zachycuje posloupnost fází jako stupně vodopádu. Tento model je založen na výrazném oddělení jednotlivých fází, jelikož k započetí nové fáze je požadováno úplné dokončení fáze předchozí.
Výhoda tohoto požadavku spočívá dle [WIKI6] v tom, že v okamžiku ukončení musí být bezpodmínečně vyřešeny všechny problémy související s touto fází, a její výsledky by tak vždy měly být bezchybné. Jako další přednost vodopádového modelu bývá uváděno, že v samotném modelu není nijak omezována či zvýhodněna žádná z fází vývoje na úkor jiné, jako k tomu dochází u některých metodik.
5.2 Modely vývoje softwaru
5.2.3 Spirálový model
Za hlavní nevýhodu vodopádového modelu bývá považováno zvýšené riziko neúspěchu projektu, způsobené obtížnou reakcí na pozměněné požadavky zákazníka a další okolnosti vzniklé až v průběhu projektu. Problematická je také skutečnost, že software je poprvé předán zákazníkovi ve chvíli, kdy jsou již fáze, nezbytné pro případné opravy a úpravy, dokončeny.
Testy jsou při použití vodopádového modelu zahájeny až v pozdní fází projektu, kdy je odstranění chyb náročnější. Těmto problémům se snaží zabránit spirálový model, postavený na myšlence tvorby softwaru po menších částech, tzv. iteracích. [VEE05] definuje iteraci jako kompletní vývojový cyklus, jehož výsledkem je release (interní nebo externí) spustitelného produktu, podmnožina produktu v konečné podobě, který je vyvíjen a narůstá od iterace k iteraci do konečné podoby produktu. Rozdělení vývoje na iterace napomáhá pružnějším reakcím na vyskytující se problémy a umožňuje lépe se přizpůsobit požadovaným změnám.
Ilustrace 3: Grafické znázornění vodopádového modelu
6 Metodika RUP
6 Metodika RUP
6.1 Historie
Z principů iterativního vývoje čerpá mnoho metodik, mezi nejvýznamnější zástupce tohoto modelu patří metodika Rational Unified Process (RUP). Vznik této metodiky je úzce svázán se společností Objectory AB, ve které v 80. letech působil Ivar Jacobson, jedna z významných osobností softwarového inženýrství. Společnost Objectory AB pracovala od roku 1988 na vlastní metodice pod názvem Objectory. V roce 1995 přešla Objectory AB pod společnost Rational, která metodiku Objectory využila jako základ procesního modelu své metodiky Rational Objectory Process. Ta byla dále rozšířena o prvky iterativního vývoje. V dalších verzích, již označených jako Rational Unified Process, se postupně objevila podpora modelovacího jazyka UML, zpracování tvorby webových aplikací a další rozšíření, například ve verzi z roku 2000 se jednalo o oblast analýzy požadavků. V roce 2002 uskutečnilo IBM koupi společnosti Rational, která nyní představuje samostatnou divizi v rámci IBM. O rok později byla dále rozšířena testovací disciplína a objevily se rovněž některé prvky agilního vývoje. V současnosti je metodika RUP součástí produktu IBM Rational Method Composer (RMC), jehož hlavním úkolem je usnadnit konfiguraci metodiky pro různé oblasti použití. Výše uvedené milníky v historii metodiky jsou podrobně popsány v [AMB06].
6.2 Typické znaky
Charakteristickým znakem a propagovanou výhodou metodiky RUP je její konfigurace na míru cílové oblasti před samotným používáním. Proto je vhodnější pohlížet na tuto metodiku jako na tzv. procesní framework, tedy jakýsi rámec či model, poskytující vzory procesů a dalších součástí, ze kterých je možno vybrat nejvhodnější kombinaci a dále jí upravit do požadované podoby. Samotná realizace procesů je ponechána na uživatelích metodiky, kteří znají nejlépe oblast, ve které bude metodika používána. Metodika tak plní pouze úkol poradce, který nabízí modelová řešení problémů. V reakci na přímočaré použití některých konkurenčních metodik, jejichž pohled na proces vývoje bývá často poměrně konkrétní a jednostranně zaměřený, se však lze v posledních verzích setkat také s dalším způsobem zavedení metodiky.
Bývá označován jako „out-of-the-box“ a jedná se o předem připravené varianty řešení, které umožňují metodiku ihned „po rozbalení“ začít využívat, neboť vyžadují pouze minimum nastavení.
6.2 Typické znaky Metodika RUP má podobu webové prezentace, jejíž obsah je dán pomocí konfiguračních nástrojů, které jsou součástí produktu RMC. Uživatelům je pak prostřednictvím webového prohlížeče distribuována metodika, obsahující pouze na míru vytvořený proces a další informace, které jsou pro příslušný projekt potřebné. Tato forma distribuce v elektronické podobě je pro využití na softwarových projektech zvlášť výhodná, protože členové projektu mají metodiku snadno přístupnou. Jako součásti metodiky jsou dále k dispozici vzorové dokumenty a šablony.
6.3 Nejlepší praktiky
Při tvorbě metodiky RUP se vycházelo ze známých a často se vyskytujících problémů a také množství shromážděných postupů a technik, které se osvědčily v praxi při vývoji softwaru.
Na takto získaných postupech a technikách byl v šesti bodech položen základ metodiky, označovaný jako tzv. nejlepší praktiky (best practices). Následující přehled nejlepších praktik je založen na informacích ze zdrojů [RAT98], [RAT03] a [KRU01].
6.3.1 Iterativní vývoj (Develop Iteratively)
Rozdělení projektu na iterace je výhodné v tom ohledu, že je díky průběhu celého vývojového cyklu již v rámci jedné iterace možné odhalit rizika v počátcích projektu, kdy náklady na jejich odstranění jsou relativně nízké. To je umožněno díky pravidelnému testování a nasazování částí produktu na konci každé iterace. Pokud je dále vývoj vhodně naplánován a problematické části produktu jsou řešeny v úvodních iteracích, je rozdíl v rizikovosti projektu oproti tradičnímu vodopádovému modelu ještě výraznější (viz Ilustrace 5). Jak již bylo zmíněno, vývoj softwaru po částech také umožňuje lépe se přizpůsobit změnám a novým požadavkům.
Ilustrace 5: Vývoj rizika při iterativním a vodopádovém vývoji
