Proces technologického testování. Proč je testování nutné

| Plánování výuky na školní rok | Hlavní fáze modelování

Lekce 2
Hlavní fáze modelování

Studiem tohoto tématu se naučíte:

Co je modelování;
- co může sloužit jako prototyp pro modelování;
- jaké místo má modelování v lidské činnosti;
- jaké jsou hlavní fáze modelování;
- co je počítačový model;
Co je počítačový experiment.

počítačový experiment

Abychom dali život novému konstrukčnímu vývoji, zavedli nová technická řešení do výroby nebo otestovali nové nápady, je zapotřebí experiment. Experiment je experiment, který se provádí s objektem nebo modelem. Spočívá v provedení některých akcí a určení, jak experimentální vzorek na tyto akce reaguje.

Ve škole děláte pokusy v hodinách biologie, chemie, fyziky, zeměpisu.

Experimenty se provádějí při testování nových vzorků produktů v podnicích. Obvykle se pro tento účel používá speciálně vytvořená sestava, která umožňuje provádět experiment v laboratorních podmínkách, nebo je samotný skutečný produkt podroben všemožným testům (experiment v plném rozsahu). Ke studiu např. výkonových vlastností jednotky nebo sestavy se umístí do termostatu, zamrazí ve speciálních komorách, zkouší na vibračních stojanech, upustí atd. Je dobré, když se jedná o nové hodinky nebo vysavač - ztráta při ničení není velká. Co když je to letadlo nebo raketa?

Laboratorní a plnohodnotné experimenty vyžadují velké materiálové náklady a čas, ale jejich význam je přesto velmi velký.

S vývojem počítačová technologie objevila se nová unikátní výzkumná metoda – počítačový experiment. V mnoha případech experimentální vzorky a zkušební stolice pomohly a někdy dokonce nahradily studie počítačové simulace. Fáze provádění počítačového experimentu zahrnuje dvě fáze: sestavení plánu experimentu a provedení studie.

Plán experimentu

Plán experimentu by měl jasně odrážet posloupnost práce s modelem. Prvním krokem v takovém plánu je vždy otestování modelu.

Testování je proces kontroly správnosti sestrojeného modelu.

Test - soubor výchozích údajů, které umožňují určit správnost konstrukce modelu.

Abychom si byli jisti správností získaných výsledků modelování, je nutné: ​​♦ zkontrolovat vyvinutý algoritmus pro sestavení modelu; ♦ ujistěte se, že sestrojený model správně odráží vlastnosti originálu, které byly zohledněny při simulaci.

Pro kontrolu správnosti algoritmu konstrukce modelu se používá testovací sada počátečních dat, u kterých je konečný výsledek předem znám nebo je předem určen jiným způsobem.

Pokud například při modelování používáte výpočetní vzorce, musíte vybrat několik možností pro počáteční data a vypočítat je „ručně“. Toto jsou zkušební položky. Když je model sestaven, testujete se stejnými vstupy a porovnáváte výsledky simulace se závěry získanými výpočtem. Pokud se výsledky shodují, pak je algoritmus vypracován správně, pokud ne, je nutné hledat a odstranit příčinu jejich nesouladu. Testovací data nemusí vůbec odrážet skutečnou situaci a nemusí mít sémantický obsah. Výsledky získané během procesu testování vás však mohou přimět k zamyšlení nad změnou původního informačního nebo znakového modelu, především v té jeho části, kde je stanoven sémantický obsah.

Abychom se ujistili, že sestrojený model odráží vlastnosti originálu, které byly zohledněny při simulaci, je nutné vybrat testovací příklad s reálnými zdrojovými daty.

Provádění výzkumu

Po otestování, kdy máte důvěru ve správnost sestrojeného modelu, můžete přistoupit přímo ke studii.

Plán by měl zahrnovat experiment nebo sérii experimentů, které splňují cíle simulace. Každý experiment musí být doprovázen pochopením výsledků, které slouží jako základ pro analýzu výsledků modelování a rozhodování.

Schéma přípravy a provedení počítačového experimentu je znázorněno na obrázku 11.7.

Rýže. 11.7. Schéma počítačového experimentu

Analýza výsledků simulace

Konečným cílem modelování je učinit rozhodnutí, které by mělo být vypracováno na základě komplexní analýzy výsledků simulace. Tato fáze je rozhodující – buď ve studiu pokračujete, nebo ukončíte. Obrázek 11.2 ukazuje, že fáze analýzy výsledků nemůže existovat autonomně. Získané závěry často přispívají k další sérii experimentů a někdy ke změně problému.

Výsledky testování a experimentů slouží jako základ pro vývoj řešení. Pokud výsledky neodpovídají cílům úkolu, znamená to, že v předchozích fázích došlo k chybám. Může se jednat buď o nesprávné uvedení problému, nebo příliš zjednodušenou konstrukci informačního modelu, nebo neúspěšnou volbu modelovací metody či prostředí nebo porušení technologických metod při sestavování modelu. Pokud jsou takové chyby identifikovány, pak je třeba model opravit, to znamená vrátit se do jedné z předchozích fází. Proces se opakuje, dokud výsledky experimentu nesplní cíle simulace.

Hlavní věcí je zapamatovat si, že zjištěná chyba je také výsledkem. Jak říká přísloví, chybami se člověk učí. Velký ruský básník A. S. Puškin o tom také napsal:

Ach, kolik úžasných objevů máme Duch osvícení připravuje A zkušenost, syn obtížných chyb, A génius, přítel paradoxů, A náhoda, bůh vynálezce ...

Kontrolní otázky a úkoly

1. Jaké jsou dva hlavní typy modelování problémů.

2. Ve známé „Knize problémů“ od G. Ostera je následující problém:

Neúnavně pracující zlá čarodějnice promění denně 30 princezen v housenky. Kolik dní jí bude trvat, než promění 810 princezen v housenky? Kolik princezen denně by se muselo proměnit v housenky, aby práci zvládly za 15 dní?
Kterou otázku lze přiřadit typu „co se stane, když...“ a kterou – typu „jak to udělat, aby...“?

3. Uveďte nejznámější cíle modelingu.

4. Formalizujte hravý problém z „Knihy problémů“ G. Ostera:

Ze dvou budek umístěných ve vzdálenosti 27 km od sebe vyskočili současně dva bojovní psi. První běží rychlostí 4 km / h a druhý - 5 km / h.
Za jak dlouho boj začne?

5. Pojmenujte co nejvíce charakteristik objektu „pár bot“. Komponovat informační model objekt pro různé účely:

■ výběr obuvi pro turistiku; ■ výběr vhodného boxu na boty; ■ nákup krému na obuv.

6. Jaké vlastnosti teenagera jsou zásadní pro doporučení při výběru povolání?

7. Proč je počítač široce používán v simulaci?

8. Vyjmenujte nástroje počítačového modelování, které znáte.

9. Co je počítačový experiment? Uveďte příklad.

10. Co je testování modelu?

11. Jaké chyby se vyskytují v procesu modelování? Co je třeba udělat, když je nalezena chyba?

12. Jaká je analýza výsledků simulace? Jaké závěry se obvykle vyvozují?

Anotace: Základní pojmy testování. Fáze a fáze testování. Typy testů. Testem řízený vývoj

Úvod

Testování je jedním z nejrozšířenějších způsobů zajištění kvality rozvoj software.

Z technického hlediska Testování z hlediska spočívá ve spuštění aplikace na určité množině výchozích dat a porovnání získaných výsledků s dříve známými (referenčními) za účelem zjištění souladu různých vlastností a charakteristik aplikace s objednanými vlastnostmi. Jako jedna z hlavních fází procesu vývoje softwarového produktu (návrh aplikací – vývoj kódu – testování) se testování vyznačuje poměrně velkým podílem na celkové náročnosti vývoje produktu. Odhad rozložení pracovní náročnosti mezi fázemi tvorby softwarového produktu je všeobecně známý: 40 % -20 % -40 %.

Z hlediska matematiky testování lze chápat jako výklad nějakého vzorce a testování jeho pravdivosti na některých množinách. Program může být skutečně reprezentován vzorcem f = f1* f2* f3*... * fn , kde f1, f 2, ... fn jsou operátory programovacího jazyka a jejich superpozice je program.

Pravdivost takové formule je možné doložit pomocí formálního přístupu - tedy odvodit z původních axiomových formulí pomocí formálních postupů (odvozovacích pravidel) požadované formule a tvrzení (věty). Výhodou formálního přístupu je, že s jeho pomocí je možné se vyhnout odkazům na nekonečný rozsah hodnot a v každém kroku důkazu pracovat pouze s konečnou množinou symbolů. Konstrukce formálního systému a formalizace samotného programu jsou však často velmi složité procesy. Interpretace může sloužit jako alternativní přístup k doložení pravdy.

Interpretační přístup se používá, když se konstanty dosazují do vzorců a vzorce jsou pak interpretovány jako smysluplné výroky v prvcích množin konkrétních hodnot. Pravdivost interpretovaných vzorců je kontrolována na konečných množinách možných hodnot. Složitost přístupu spočívá ve skutečnosti, že počet kombinací hodnot je často velmi velký a samotné kombinace se skládají z velkého počtu hodnot - což znamená, že zpracování všech kombinací bude vyžadovat značné zdroje. Existovat různé metody snížit počet zvažovaných kombinací. Hlavní testovací problém- stanovení dostatečnosti souboru testů pro pravdivost závěru o správnosti implementace programu, jakož i zjištění souboru testů, které tuto vlastnost mají.

Statické testování pomocí metod formální analýzy bez spuštění testovaného programu detekuje nesprávné konstrukce nebo nesprávné vztahy mezi objekty programu (chyby formálního přiřazení) pomocí speciálních nástrojů pro kontrolu kódu - CodeChecker.

Dynamické testování(skutečné testování) zjišťuje chyby pouze na běžícím programu pomocí speciálních nástrojů automatizace testování- Testbed nebo Testbench.

Základy testování

Třídy testovacích kritérií

Strukturální kritéria využívat informace o struktuře programu (kritéria tzv. „bílé skříňky“), z čehož vyplývá znalost zdrojového kódu programu nebo specifikace programu ve formě řídicího toku grafu. Strukturální kritéria jsou založeny na hlavních prvcích řídicího grafu - operátory, větve a cesty.

• Podmínka kritéria testování příkazu (kritérium C0) - sada testů v agregaci musí zajistit, aby každý příkaz prošel alespoň jednou.
• Podmínka kritéria testování větve (kritérium C1) - sada testů v souhrnu musí zajistit, aby každá větev prošla alespoň jednou.
• Podmínka kritéria testování cesty (kritérium C2) - sada testů v agregaci musí zajistit, aby každá cesta prošla alespoň 1krát.

Funkční kritéria jsou formulovány v popisu požadavků na softwarový produkt (kritéria tzv. "black box") Zajišťují především kontrolu míry splnění požadavků zákazníka v softwarovém produktu. Jelikož jsou požadavky formulovány pro produkt jako celek, odrážejí interakci testované aplikace s prostředím. Problém funkčního testování je primárně náročný na práci; Faktem je, že dokumenty, které stanoví požadavky na softwarový produkt, jsou zpravidla poměrně objemné, příslušná kontrola by však měla být komplexní.

Rozlišují se následující konkrétní typy funkční kritéria:

• položky specifikace testování;
• testování tříd vstupních dat;
• testovací pravidla - sada testů v agregaci musí zajistit ověření každého pravidla, pokud jsou vstupní a výstupní hodnoty popsány sadou pravidel nějaké gramatiky;
• testování výstupních tříd;
• funkční testování;
• kombinovaná kritéria pro programy a specifikace. Stochastická testovací kritéria formulováno v pojmech

kontrola přítomnosti specifikovaných vlastností v testované aplikaci, pomocí testování některé statistické hypotézy. Používá se při testování složitých softwarových systémů – kdy má soubor deterministických testů (X, Y) obrovskou sílu.

Kritéria mutace zaměřené na kontrolu vlastností softwarového produktu založeného na přístupu Monte Carlo.

Metoda testování mutací spočívá v tom, že do vyvinutého programu P se vnesou mutace (drobné chyby), tzn. uměle vytvořit mutantní programy P1, P2... . Poté se program P a jeho mutanty testují na stejné sadě testů (X, Y).

Pokud se potvrdí správnost programu P na sadě (X, Y) a navíc se odhalí všechny chyby vnesené do mutantních programů, pak sada testů (X, Y) splňuje kritérium mutace a testovaný program je prohlášen za správný. Pokud některé mutanty neodhalily všechny mutace, pak je nutné rozšířit testovací sadu (X, Y) a pokračovat v testování.

Testovací fáze

Při testování se zpravidla rozlišují tři fáze: jednotkové, integrační a systémové testování.

Testování jednotek- jedná se o testování programu na úrovni jednotlivých modulů, funkcí nebo tříd. Účelem unit testování je identifikovat chyby lokalizované v modulu při implementaci algoritmů a také určit stupeň připravenosti systému na přechod na další úroveň vývoje a testování. Testování jednotek se provádí podle principu "bílé skříňky", to znamená, že je založeno na znalosti vnitřní struktury programu a často zahrnuje určité metody analýzy pokrytí kódu.

Integrační testování- jedná se o testování části systému sestávajícího ze dvou nebo více modulů. Hlavním úkolem integračního testování je najít defekty spojené s chybami v implementaci a interpretaci interakcí rozhraní mezi moduly. Hlavní rozdíl mezi jednotkovým a integračním testováním spočívá v cílech, tedy v typech detekovaných defektů, které následně určují strategii výběru vstupních dat a metod analýzy.

Testování systému kvalitativně odlišné od integrační a modulární úrovně. Posuzuje testovaný systém jako celek a funguje na úrovni uživatelská rozhraní. Hlavní úkol testování systému spočívá v identifikaci závad souvisejících s provozem systému jako celku, jako je nesprávné využívání systémových prostředků, nezamýšlené kombinace dat na uživatelské úrovni, nekompatibilita s prostředím, nezamýšlené případy použití, chybějící nebo nesprávná funkčnost, nepříjemnosti při používání a podobně.

Testování systému se provádí na projektu jako celku metodou „black box“. Na struktuře programu nezáleží, k testování jsou k dispozici pouze vstupy a výstupy, viditelné pro uživatele. Kódy a uživatelská dokumentace podléhají testování.

Navíc alokovat regresní testování- testovací cyklus, který se provádí při provádění změn ve fázi testování systému nebo údržby produktu. Hlavním problémem regresního testování je volba mezi úplným a částečným přezkoušení a doplňování testovacích sad. S částečným přezkoušení jsou řízeny pouze ty části projektu, které se týkají změněných komponent.

Testovací fáze

Každý testovací fáze zahrnuje následující kroky:

1. Stanovení cílů(požadavky na testování), včetně následující specifikace: jaké části systému budou testovány, jaké aspekty jejich práce budou vybrány pro testování, jaká je požadovaná kvalita atd.
2. Plánování: vytvoření harmonogramu (plánu) pro vývoj testů pro každý testovaný subsystém; posouzení nezbytných lidských, softwarových a hardwarových zdrojů; plánování testovacích cyklů . Je důležité si uvědomit, že plán testování musí být nutně v souladu s plánem vývoje vytvářeného systému.
3. Vývoj testu (testovací kód pro testovaný systém).
4. Průběžné testy: implementace testovacích smyček .
5. Analýza výsledků.

Testovací cyklus je cyklus provádění testu, který zahrnuje fáze 4 a 5 testovacího procesu. Testovací cyklus spočívá ve spuštění vyvinutých testů na nějakém jednoznačně definovaném řezu systému (stav kódu vyvíjeného systému). Obvykle se takový řez systému nazývá stavět.

Testovací plán- jedná se o dokument nebo soubor dokumentů, který obsahuje testovací zdroje, seznam funkcí a subsystémů, které mají být testovány, testovací strategie, harmonogram testovacího cyklu, stanovení testovací konfigurace (složení a konkrétní parametry hardwarového a softwarového prostředí), stanovení seznamu testovacích metrik, které je třeba shromáždit a analyzovat během testovacího cyklu (například metriky, které hodnotí stupeň testu pokrytí souboru požadavků).

Testy jsou vyvíjeny ze specifikací jak ručně, tak pomocí automatizovaných nástrojů. Kromě samotného kódu zahrnuje pojem „test“ i jeho obecný popis A Detailní popis kroky provedené v tomto testu.

K posouzení kvality testů se používají různé metriky související s počtem nalezených defektů, pokrytím kódu, funkčními požadavky a různými scénáři.

Veškeré informace o závadách zjištěných během testování (typ, podmínky detekce, příčina, podmínky nápravy, čas strávený nápravou) se zapisují do databáze závad.

Na konci každého testovacího cyklu se ke generování používají informace o plánu testování, testech a defektech Protokol o zkoušce a nastavení testovacího systému pro další iteraci.

Typy testů

Testovací plán definuje a dokumentuje různé typy testů.

Typy zkoušek podle typu subsystému nebo produktu jsou následující:

1. Testování hlavní funkčnosti, kdy se testuje samotný systém, který je hlavním vydávaným produktem.
2. Testování instalace zahrnuje testovací skripty pro prvotní instalaci systému, skripty pro reinstalaci (přes existující kopii), testovací odinstalaci, testování instalace za přítomnosti chyb v instalovaném balíčku, v prostředí nebo ve skriptu atd. .
3. Testování uživatelské dokumentace zahrnuje kontrolu úplnosti a srozumitelnosti popisu pravidel a vlastností používání produktu, přítomnosti popisu všech scénářů a funkčnosti, syntaxe a gramatiky jazyka, provozuschopnosti příkladů atd.

Typy testování metodou výběru vstupních hodnot:

1. Funkční testování, které kontroluje:
   • pokrytí funkčních požadavků;
   • pokrytí případů použití.
2. Zátěžové testování, které kontroluje extrémní způsoby použití produktu.
3. Testování hraničních hodnot.
4. Testování výkonu.
5. Testování shody s normami.
6. Testování kompatibility s jinými softwarovými a hardwarovými systémy.
7. Testování práce s prostředím.
8. Testování práce na konkrétní platformě.

Testem řízený vývoj

Zvažte testovací přístup, který se mírně liší od výše uvedeného. Test Driven Development (TDD) je proces vývoje softwaru, který zahrnuje psaní a automatizaci jednotkových testů před napsáním odpovídajících tříd nebo modulů. Tím je zajištěno, že všechny odpovědnosti jakékoli části softwaru jsou definovány před jejich kódováním.

TDD specifikuje následující pořadí programovacích kroků:

• Červená – Napište malý test, který nefunguje, nebo se možná ani nezkompiluje.
• Zelená – udělejte testovací běh co nejrychlejší bez starostí o správný design a čistotu kódu. Napište jen tolik kódu, aby test fungoval.
• Refaktoring – odstraňte z kódu, který píšete, veškerou duplicitu.
• Po zvládnutí TDD vývojáři zjistí, že píší podstatně více testů než dříve a postupují vpřed po malých krocích, které se dříve mohly zdát zbytečné.

Poté, co programátor provede test a může si být jistý, že tato část funkčnosti je pokryta, provede druhý test, poté třetí, čtvrtý a tak dále. těžší problém směrem k programátorovi, menší oblast funkčnosti by měl každý test pokrýt. Výsledkem je 100% pokrytí kódem unit testy, čehož zpravidla nelze dosáhnout klasickým přístupem k testování.

Určitě existují problémy, které nelze (alespoň prozatím) vyřešit pouze testy. TDD zejména neumožňuje mechanickou demonstraci adekvátnosti vyvinutého kódu v oblasti bezpečnosti dat a interakce mezi procesy. Zabezpečení je samozřejmě založeno na kódu, který by neměl být vadný, ale je také založen na lidské účasti na postupech ochrany dat. Jemné problémy, které vznikají v oblasti komunikace mezi procesy, nelze s jistotou reprodukovat pouhým spuštěním nějakého kódu.

Výsledek

Čím aktivněji nové Informační systémy Architektury se stávají složitějšími, vyvíjejí se nové technologie, tím důležitější je proces testování. Existuje stále více síťových aplikací a aplikací pro mobilní zařízení. Testování takových systémů je mnohem obtížnější než jednouživatelské programy pro domácí PC. Tyto typy systémů vyžadují účinné algoritmy pro automatizaci testování. Kromě toho je relevantní úkol testování bezpečnosti. informační systémy ve všech jejích projevech. Videoherní průmysl také potřebuje nové přístupy k testování.

Testování provází téměř celý vývojový proces, včetně nejranějších fází. Stále je potřeba zlepšovat technologie testování specifikací a požadavků. Relevantní je úkol vypracovat testy, které otestují proces vývoje, obchodní požadavky a cíle celé organizace. Jde o vývoj efektivnějších testů, které pokrývají nejvíce různé vlastnosti informační systém.

Kromě toho probíhá výzkum v oblasti testů zaměřených na konkrétní model vývoj (vodopád, spirála) nebo specifické programovací paradigma. Například testování pomocí agentů je navrženo pro testování komponentově orientovaných systémů. Pro testování aktivních Java appletů se navrhuje použít neuronové sítě. Pro testování agentů existujících na webu (robotů, pavouků) se navrhuje používat znalostní systémy.

Navzdory značné jistotě procesu testování a úplné automatizaci mnoha jeho fází tedy zůstává mnoho směrů pro výzkum a praktickou práci.

Většina Nejlepší způsob vyhodnotit, zda jsme produkt dobře otestovali – analyzovat chybějící vady. Těm, kterým čelí naši uživatelé, implementátoři, podniky. Můžete z nich vyhodnotit mnohé: co jsme nezkontrolovali dostatečně důkladně, jakým oblastem produktu je třeba věnovat větší pozornost, jaké je obecně procento opomenutí a jaká je dynamika jeho změn. S touto metrikou (možná nejběžnější při testování) je vše v pořádku, ale ... Když jsme produkt vydali a zjistili jsme chybějící chyby, může být pozdě: na Habré se o nás objevil naštvaný článek, konkurenti jsou rychle se šířící kritika, zákazníci v nás ztratili důvěru, management je nespokojený.

Aby k tomu nedocházelo, obvykle se snažíme vyhodnotit kvalitu testování předem, před vydáním: jak dobře a důkladně produkt kontrolujeme? Jakým oblastem chybí pozornost, kde jsou hlavní rizika, jaký pokrok? A abychom na všechny tyto otázky odpověděli, vyhodnotíme testovací pokrytí.

Proč hodnotit?

1. Najděte své slabé stránky. Přirozeně, potřebujeme to? nejen truchlit, ale vědět, kde je potřeba zlepšení. Jaké funkční oblasti testy nepokrývají? Co jsme nezkontrolovali? Kde jsou největší rizika chybějících chyb?
2. Málokdy získáme 100% pokrytí na základě výsledků hodnocení. Co zlepšit? Kam jít? Jaké je nyní procento? Jak jej můžeme zvýšit jakýmkoliv úkolem? Jak rychle se můžeme dostat na 100? Všechny tyto otázky přinášejí transparentnost a jasnost našeho procesu., a odpovědi na ně dává odhad pokrytí.
3. Zaměření pozornosti.Řekněme, že náš produkt má asi 50 různých funkčních oblastí. Vychází nová verze a začínáme testovat první z nich a nacházíme tam překlepy, tlačítka, která se posunula o pár pixelů, a další drobnosti... A nyní je čas na testování u konce a tato funkce byla podrobně zkontrolováno ... A zbývajících 50? Hodnocení pokrytí nám umožňuje stanovit priority úkolů na základě aktuální reality a termínů.

Jak hodnotit?

Posouzení pokrytí požadavků testy

Dobře, vraťme se na zem. S největší pravděpodobností nemáte podrobné požadavky, nejsou atomické, některé požadavky jsou obecně ztraceny a není čas dokumentovat každý test, nebo alespoň každý druhý. Můžete si zoufat a plakat, nebo si můžete připustit, že testování je kompenzační proces, a čím hůře jsme na tom s analytikou a vývojem na projektu, tím více bychom se sami měli snažit kompenzovat problémy ostatních účastníků procesu. Pojďme analyzovat problémy samostatně.

Problém: Požadavky nejsou atomické.

Test požadavků nám tedy nezaručuje vůbec nic! Co v tomto případě znamenají naše statistiky pokrytí? Skoro nic! Budeme se muset rozhodnout!

1. V tomto případě lze automatický výpočet pokrytí požadavků testy odstranit - stále nenese sémantickou zátěž.
2. Pro každý požadavek, počínaje nejvyšší prioritou, připravujeme testy. Při přípravě analyzujeme, jaké testy budou pro tento požadavek vyžadovány, kolik jich bude stačit? Provádíme plnohodnotnou testovací analýzu a nezavrhujeme „existuje jeden test, ale v pořádku“.
3. V závislosti na použitém systému exportujeme/nahráváme testy na vyžádání a... testujeme tyto testy! Jsou dost? V ideálním případě by samozřejmě takové testování mělo být prováděno s analytikem a vývojářem této funkce. Vytiskněte si testy, zamkněte své kolegy v zasedací místnosti a nepusťte je, dokud neřeknou „ano, tyto testy stačí“ (to se děje pouze s písemným souhlasem, kdy jsou tato slova vyslovena pro odhlášení, a to i bez analýzy testů. Při ústní diskusi ze sebe vaši kolegové vysypou kritiku, zmeškané testy, nepochopené požadavky atd. - to není vždy příjemné, ale pro testování je to velmi užitečné!)
4. Po dokončení zkoušek na vyžádání a odsouhlasení jejich úplnosti lze tento požadavek v systému označit stavem „kryto zkouškami“. Tato informace bude znamenat mnohem více než „zde je alespoň 1 test“.

Samozřejmě, že takový proces dohod vyžaduje spoustu zdrojů a času, zvláště zpočátku, dokud se nerozvine praxe. Provádějte proto pouze požadavky s vysokou prioritou a nová vylepšení. Postupem času zpřísněte zbytek požadavků a všichni budou spokojeni! Ale ... a pokud neexistují vůbec žádné požadavky?

Problém: Neexistují vůbec žádné požadavky.

1. Vytvořte seznam funkcí. Sami! Ve formě google-tabletu, ve formátu PBI v TFS - vyberte si jakýkoli, jen ne textový formát. Stále musíme sbírat statusy! Do tohoto seznamu zahrnujeme všechny funkční oblasti produktu a snažíme se vybrat jednu obecnou úroveň rozkladu (můžete zapisovat softwarové objekty nebo uživatelské skripty, moduly nebo webové stránky nebo metody API nebo obrazovkové formuláře. .) - ale ne všechno najednou! JEDEN formát rozkladu, který vám usnadní a zpřehlední, aby vám neunikly důležité věci.
2. KOMPLETNOST tohoto seznamu koordinujeme s analytiky, vývojáři, obchodem, v rámci našeho týmu... Snažte se udělat vše pro to, abyste neztratili důležité části produktu! Jak hluboko analyzovat je na vás. V mé praxi bylo jen pár produktů, pro které jsme vytvořili více než 100 stran v tabulce, a to byly obří produkty. Nejčastěji je 30-50 řádků dosažitelným výsledkem pro další pečlivé zpracování. V malém týmu bez specializovaných testovacích analytiků více fichelistické prvky by bylo příliš náročné na údržbu.
3. Poté projdeme priority a zpracujeme každý řádek fichelisty jako v části požadavků popsané výše. Píšeme testy, diskutujeme, domlouváme se na dostatečnosti. Označujeme stavy, pro kterou funkci je dostatek testů. Komunikací s týmem získáme stav, postup a rozšíření testů. Všichni jsou šťastní!

Ale... Co když jsou požadavky zachovány, ale ne ve sledovatelném formátu?

Problém: Požadavky nejsou dohledatelné.

1. Vytváříme featurelist (viz výše), ale bez podrobného popisu požadavků.
2. Pro každou funkci společně shromažďujeme odkazy na technické specifikace, specifikace, pokyny a další dokumenty.
3. Jdeme podle priorit, připravíme testy a dohodneme se na jejich úplnosti. Vše je při starém, jen díky kombinaci všech dokumentů v jedné desce zvyšujeme snadnost přístupu k nim, přehledné stavy a konzistenci testů. Nakonec je všechno super a všichni jsou šťastní!

Ale... Ne na dlouho... Zdá se, že za poslední týden analytici aktualizovali 4 různé specifikace na základě požadavků zákazníků!!!

Problém: Požadavky se neustále mění.

1. Řekněme, že jste již shromáždili odkazy na TK a specifikace ve formě seznamu funkcí, PBI, požadavků, poznámek Wiki atd. Řekněme, že již máte testy pro tyto požadavky. A nyní se požadavek mění! To může znamenat změnu v RMS nebo úkol v TMS (Task Management System) nebo dopis v poště. V každém případě to vede ke stejnému výsledku: vaše testy jsou zastaralé! Nebo mohou být irelevantní. To znamená, že vyžadují aktualizaci (pokrytí testy stará verze produkt se nějak moc nebere v úvahu, že?)
2. V seznamu funkcí, v RMS, v TMS (Test Management System - testrails, sitechco atd.) musí být testy okamžitě a bezpodmínečně označeny jako irelevantní! V HP QC nebo MS TFS to lze provést automaticky při aktualizaci požadavků a v google-tabletu nebo wiki budete muset odložit pera. Ale měli byste vidět hned: testy jsou irelevantní! To znamená, že čekáme na úplnou změnu cesty: aktualizaci, znovu spusťte analýzu testu, přepište testy, dohodněte se na změnách a teprve poté označte funkci/požadavek znovu jako „pokrytý testy“.

V tomto případě získáme všechny výhody hodnocení pokrytí testem, a to i v dynamice! Všichni jsou šťastní!!! Ale…
Ale vy jste se tolik soustředili na práci s požadavky, že nyní nemáte dostatek času testy testovat ani dokumentovat. Podle mého názoru (a je zde místo pro náboženský spor!) jsou požadavky důležitější než testy a je to tak lepší! Alespoň jsou v pořádku a celý tým o tom ví a vývojáři dělají přesně to, co je potřeba. ALE NENÍ ČAS NA DOKUMENTACE TESTŮ!

Problém: Nedostatek času na zdokumentování testů.

1. Stále potřebujete požadavky jako úplné požadavky nebo jako seznam funkcí, takže jedna z výše uvedených sekcí, v závislosti na práci analytiků na projektu, bude stále nezbytná. Máte požadavek/seznam funkcí?
2. Popisujeme a ústně domlouváme krátkou testovací strategii, bez dokládání konkrétních testů! Tato strategie může být specifikována ve sloupci tabulky, na wiki stránce nebo v požadavcích v RMS a opět musí být dohodnuta. V rámci této strategie budou testy prováděny různými způsoby, ale budete vědět: kdy byla naposledy testována a jakou strategií? A to, jak vidíte, také není špatné! A všichni budou šťastní.

Ale… Co jiného "než"? Který???

Řekněte, všechno obejdeme a ať jsou s námi kvalitní produkty!

Proč je testování nutné?

V této části se podíváme na většinu základní pojmy a principy, které se používají v procesu testování. Zjistíme, co ve skutečnosti testuje, proč je to potřeba a kdo to dělá. Zvažte cíle, principy a hlavní fáze testování. Pojďme si osahat, jaký by měl být psychologický postoj skutečného testera a na závěr vyvrátit pár mýtů o testování. Jsme si jisti, že budete mít zájem.
Začněme tím, co je to „testování“. Pro začátek abstrahujme od suchých akademických definic a podívejme se na tento pojem z hlediska každodenního používání.
Když něco testujeme, položíme si jednoduchou otázku: „Funguje to tak, jak očekáváme? nebo jinými slovy: odpovídá skutečné chování testovaného objektu našim očekáváním? Pokud je odpověď ano, skvělé, pokud ne, jsme ve svých očekáváních klamáni, což znamená, že je třeba něco napravit.
Testování je nutné, protože všichni děláme chyby. Některé z nich mohou být drobné, zatímco jiné mohou být nejničivější. Vše, co vyprodukuje člověk, může obsahovat chyby (tak jsme my lidé zařízeni). To je důvod, proč každý produkt potřebuje ověření – testování, než bude možné jej efektivně a bezpečně používat.
Totéž platí pro software (angl. Software).
Software (software) - počítačové programy, funkce a průvodní dokumentace a údaje relevantní pro provoz počítačového systému.
Počítačové technologie pronikají stále hlouběji do našeho každodenního života. Software řídí chod mnoha věcí kolem nás – od mobilní telefony a počítače do pračky a kreditní karty. V každém případě jsme se všichni setkali s některými nebo jinými chybami v programech: textový editor, který zamrzá při práci na maturitním projektu, bankomat, který „sežral“ kartu, nebo prostě stránka, která se nijak nenačte - to vše nám život neusnadňuje.
Ne všechny chyby jsou však stejně nebezpečné – pro různé programy systémů, úrovně rizika se mohou lišit.
Riziko (riziko):
- faktor, který může v budoucnu vést k negativním důsledkům; zpravidla se vyjadřuje jako pravděpodobnost výskytu takových následků a jejich dopad na systém.
- něco, co se ještě nestalo a nemusí se stát vůbec; potenciální problém.
Kromě toho bude úroveň rizika záviset na pravděpodobnosti výskytu negativních důsledků.
Například stejná drobná chyba, řekněme překlep, může mít pro různé programy zcela odlišné úrovně rizika:
- překlep v popisu zájmů na osobní stránce na sociální síti pravděpodobně nebude mít významné důsledky, kromě toho, že přiměje vaše přátele k úsměvu;
- stejný jednoduchý překlep v popisu aktivity velká společnost zveřejněná na jejích webových stránkách je již nebezpečná, neboť nepřímo naznačuje neprofesionalitu jejích zaměstnanců;
- překlep v kódu programu, který počítá úrovně expozice během provozu rentgenového přístroje (například 100 místo 10), může mít ty nejnešťastnější důsledky - poškození zdraví a bezpečnosti lidí bude mít za následek ztráta důvěry ve společnost a soudní spory s mnoha nulami.

Váš cíl je jako správce systému
je implementovat efektivní strategie pro
maximalizovat své počítačové zdroje.

D. Gunter, S. Barnet, L. Gunter.
Integrace Windows NT a Unixu

IT odborníci se musí nejen seznámit s četnými testy publikovanými v počítačovém tisku, ale také sami vypracovat testovací postupy, které jsou nezbytné jak při výběru dodavatele, tak při tvorbě vlastního řešení. Pokusíme se proto odpovědět na otázky, které se v nelehkém procesu testování vynořují, zvláště když o takové jde komplexní systémy jako servery.

Co se testuje a proč

V počítačových periodikách jsou často různé druhy recenzí programů, hardwaru a řešení. Zvláště zajímavé jsou zpravidla srovnávací recenze funkčně homogenních produktů, kde jsou uvedeny výsledky testů. Předpokládá se, že tyto tabulky pomáhají uživateli, správci a IT profesionálovi alespoň držet krok s děním v této oblasti a dokonce se rozhodnout o výběru produktu.

Jaké faktory se tedy v takových případech berou v úvahu, co je předmětem výzkumu a jaké testy jsou nejoblíbenější?

Testovací kritéria jsou obvykle:

• funkčnost produktu;
• snadnost vývoje;
• snadná instalace;
• kvalita dokumentace a podpory;
• výkon;
• u zařízení se někdy bere v úvahu design.

Existují také velmi nejednoznačná kritéria. Není to tak dávno, co recenze webových serverů uváděla „vysoký stupeň integrace s operačním systémem“ jako pozitivní faktor v jejich celkovém hodnocení. Ale pokud pád aplikace způsobí pád operační systém(jehož pravděpodobnost je úměrná míře integrace) - je to taková výhoda?

Sto králíků se rovná jednomu tygrovi?

Samostatně bych se chtěl pozastavit nad poměrem cena / výkon, který je typický při hodnocení hardwaru. Na první pohled je to skutečně jediné objektivní kritérium propojení Specifikace studovaného systému s peněženkou spotřebitele. Ne vše je však tak jednoduché, jak se zdá. Faktem je, že výše uvedený přístup funguje pouze v okamžiku nákupu a nezohledňuje ani náklady na vlastnictví, ani bezpečnost investic do vybavení nebo softwaru, ani možnost dalších upgradů.

Typickým příkladem je srovnání starších modelů systémů na procesory Intel s juniory v řadě platforem RISC. Ano, skutečně, v daném cenovém rozpětí jsou stroje s architekturou Intel srovnatelné nebo v některých případech dokonce lepší než systémy RISC. Co je však pro některé platformy stropem, je pro jiné pouze vstupní úrovní a tak dále.

Závěry: buďte kritičtí ke kritériím, podle kterých je produkt hodnocen – vy a testeři můžete mít odlišný vkus. Zkuste to říct lidem z Unixu kvůli pohodlí GUI Při konfiguraci systému byste měli přijmout nutnost restartování po změně parametrů IP. Pokud jde o kompaktní design systémové jednotky, je to dobré, dokud není nutné do tenkého pouzdra vložit další pevný disk.

Jedním slovem – přehodnoťte výsledky testů podle svých potřeb.

Specifika testování serveru

Pokud se počítač nezapne, je vadný.
Pokud se nevypne, jedná se o server.
lidové znamení

Jedním ze základních požadavků na servery je podle nás spolehlivost. Výkon je samozřejmě také důležitý, protože ovlivňuje dobu odezvy systému – nejdůležitější vlastnost z pohledu uživatele, ale dostupnost služby je dána právě spolehlivostí. Na spolehlivosti závisí také včasnost jejich poskytování, relevance a integrita informací.

Kromě toho je třeba mít na paměti, že specializované servery, tj. poskytující pouze jednu službu, jsou stále spíše výjimkou než pravidlem. Jeden takový počítač obvykle kombinuje řadu funkcí – například aplikační server může sloužit také jako souborový server, tiskový server, servisní řadič Rezervovat kopii atd. Pro komunikační servery je typické, že pracují s několika protokoly aplikační vrstva, z nichž každý je obsluhován svým vlastním "démonem".

A nakonec charakteristický rys fungování serverů je přítomnost špičkového zatížení. Důvody jejich vzhledu mohou být velmi odlišné - od začátku pracovního dne ve velké organizaci (zejména pokud všichni uživatelé přicházejí do práce včas) až po obnovení „přerušeného“ připojení u poskytovatele internetových služeb, když se nahromadí pošta a diskusní skupiny spadají na komunikační servery.

Tyto faktory, tedy požadavek na zvýšenou spolehlivost v podmínkách více služeb a špičkového zatížení, by měly být klíčové při určování ideologie testování serverů.

Bohužel většina recenzí publikovaných v počítačových periodikách je věnována buď porovnávání výkonu různých hardwarových řešení na sadě testovacích úloh prováděných sekvenčně, popř. srovnávací testování konkrétní službu (například testování webových serverů různých výrobců). Jednou z nejhorších možností tohoto přístupu je kdy srovnávací přehled Možnostem podobných řešení se říká testování jen proto, že autor publikace provedl instalaci a produkt trochu „pohnal“.

Zkušební podmínky

Začněme trochou teorie. Glenford Myers ve své práci "Spolehlivost softwaru" uvádí několik "testovacích axiomů". Zkusme se po nich zamyslet nad tím, co a jak testovat.

Čas od času se v počítačovém tisku objeví téměř sportovní zprávy: produkt společnosti N vykázal rekordní výkon v testu M. Jak vypovídající jsou testy prováděné výrobci?

Nelze otestovat svůj vlastní program

Často testy píší zaměstnanci společnosti pro konkrétní produkt. Řeč města se staly testy výkonu procesoru, napsané tak, aby si uvědomily výhody konkrétního procesoru. Například velikost testovacího programu se vybírá s ohledem na jeho umístění v mezipaměti atd. Grafické znázornění takových výsledků je často značně neobjektivní.

Znalost architektury aplikací a toho, jak využívají prostředky operačního systému, umožňuje vývojářům softwaru vyladit systém takovým způsobem, aby pro svůj program získali maximální výsledky. Vůbec nezáleží na tom, zda se s takovými instalacemi operačního systému bude cítit i jiný software nebo služby a zda testovaná aplikace bude „ubírat zdroje“.

Autor se s tímto jevem setkal při pokusu nastavit Netscape Enterprise Web Server pro Solaris (SPARC). Výkon serveru nad protokolem http se zvýšil téměř 6 (!) krát (podle testování s MS InetLoad), při komplexním testu se však ukázal nárůst až trojnásobný, zatímco výkon POP3 serveru zdvojnásobil, News server zůstal nezměněn a SMTP fungoval dvakrát tak špatně než před změnou.

Kromě toho výrobci, kteří znají vlastnosti konkrétní testovací sady, mohou pro ni optimalizovat systémové parametry. Příkladem toho je webová stránka Netscape, která poskytuje návod, jak nastavit Netscape Enterprise Server pro testování pomocí SPECweb96.

Testování se provádí za účelem zjištění chyb

V případě serverů a serverového softwaru to znamená, že zařízení by mělo být nuceno pracovat v nejnepříznivějším režimu – provést test „přežití“. Toho lze dosáhnout testováním serveru v následující pracovní konfiguraci:

• všechny služby musí být spuštěny;
• všechny služby by měly být testovány současně (komplexní test);
• proud požadavků je zasílán každé ze služeb, simulující typickou aktivitu uživatele;
• tato aktivita by se měla během testu pravidelně zvyšovat, dokud alespoň jedna služba již nebude zvládat zpracování požadavků.

Zde jsou důležité dvě poznámky:

1. Model uživatelského chování.

Ve vztahu k uživatelům musí být správce pesimista. V souladu s tím by mělo být vybudováno testování „pro přežití“.

Zvažte maximální počet akcí, které by vás normálně nenapadlo udělat. Odhadněte (nebo zkontrolujte), zda bude systém v této situaci fungovat normálně. A co je stejně důležité, dostane od ní uživatel jasnou zprávu, že už to nemá cenu dělat a proč.

2. Služba přestala zvládat zpracování požadavků: možné možnosti.

Podle závažnosti lze taková selhání rozdělit do 4 skupin:

• zhoršení výkonu – služba nestihne zpracovat, ale reaguje správně (vrací příslušný chybový kód – „Příliš mnoho připojení“ atd.);
• abnormální ukončení služby, které nemá negativní důsledky pro systém: odpovídající program dokončil svou práci, byl uvolněn z paměti, systémové prostředky propuštěn;
• pád služby, který nepříznivě ovlivňuje výkon systému. Program buď "zasekne" v seznamu procesů, aniž by uvolnil prostředky, nebo v procesu dokončení získá další zdroje;
• kolaps systému nejlepší případ následovaný restartem, v nejhorším případě - se zablokováním.

Připravte testy pro správné i nesprávné vstupy

Tento axiom podrobně popisuje předchozí z hlediska toků vstupních informací.

Jak bude systém reagovat na odeslání dopisu o velikosti několika desítek megabajtů? Zasekne se ve frontě a zablokuje tak váš poštovní systém na dobu neurčitou (zejména pokud se pravidelně ztrácí komunikace s hostitelem příjemce), nebo bude zničen a uživatel bude upozorněn, že takové akce nejsou povoleny?

Rada převzatá ze stejné knihy G. Myerse: "Snažte se nezlobit systém na uživatele, protože to může vést k některým neočekávaným situacím na vstupu - pravidlo č. 5 minimalizace chyb uživatelů v interaktivních systémech. Být pesimistou znamená neznamená být misantrop!"

A co zpravodajský server - je tam nainstalován maximální velikostčlánky?

Může někdo, odhodlaný stáhnout si polovinu vašeho FTP serveru, otevřít tři tucty paralelních ftp relací, a pokud ano, jak to ovlivní váš kanál a práci ostatních, kteří chtějí FTP navštívit?

Jako příklad potvrzující správnost tohoto přístupu můžeme uvést incident s raketovým křižníkem Yorktown, kde chyba operátora při zadávání porucha řídicího systému motoru. Nebo jiný citovaný samotným Myersem: „Operátoři systému newyorských policejních vozů SPRINT v volný čas bavili se tím, že se to snažili deaktivovat zaváděním záměrně nesprávných zpráv." Stalo se to na začátku 70. let. Možná od té doby morálka změkčila, ale to je nepravděpodobné."

Vyhněte se nereprodukovatelným testům

V případě testování serverů a serverového softwaru je tento axiom obzvláště relevantní. Nejprve je k jejich testování potřeba mít hardwarově oddělené generátory zátěže (Client-Side Load Generators, CSLG) – obvykle se jedná o skupiny pracovních stanic, které provádějí klientskou část testu a zajišťují tok požadavků na server. Za druhé, stav sítě spojující server a CSLG může ovlivnit výsledky. Kromě toho v mnoha případech závisí výkon na historii volání na server. Většina serverových aplikací používá ukládání do mezipaměti. Rychlost přístupu k vyrovnávací paměti je mnohem vyšší než rychlost přístupu k diskovému subsystému. Mezipaměť aplikace se může zaplnit v důsledku předběžných nebo ladicích běhů testovacích programů - a výsledky se mohou odpovídajícím způsobem změnit. Kromě toho je při komplexním testování možné testování napříč aplikacemi – například počet komplexních požadavků zpracovaných za jednotku času na servery POP3 nebo IMAP závisí na velikosti poštovní fronty, kterou lze zvýšit předchozím testem SMTP. A konečně nastavení operačního systému ovlivňuje výkon.

Všechny slušné recenze mají sekci "Jak probíhaly testy". V některých publikacích je to podrobnější, v jiných méně - zdá se, že standard pro popis a protokolování testování stále neexistuje. Vynikajícím příkladem toho je test SPECweb96. Tento dokument bere v úvahu specifika testování serverové aplikace. Na rozdíl od tradičních popisů existují požadavky na protokolování pokročilé nastavení operačního systému a zkoumané aplikace - něco, co je obvykle zmíněno jen okrajově i v těch nejlepších příkladech popisů testů.

Možná si sami uvědomíte potřebu provést svůj vlastní test. Taková potřeba může nastat v následujících případech:

• plánujete rozšířit svou síť, což zvýší zatížení serverů v ní hostovaných;
• máte v úmyslu aktualizovat (nebo změnit) software;
• rozhodnete se změnit svůj server (nebo servery) na produktivnější;
• konečně, možná jste se právě rozhodli zjistit "limity růstu" vašeho systému.

Vaším prvním krokem je pravděpodobně přečíst si publikované recenze. Abyste tedy mohli využít data získaná někým jiným, buďte k nim kritičtí a snažte se mimo jiné pochopit motivaci lidí, kteří toto testování prováděli. A pak už záleží jen na vás – pochopení cíle, výběr či sepsání adekvátní sady testů a správné provedení samotného testování. Doufám, že úvahy uvedené v tomto článku vám v tom pomohou.