testovací model je logická struktura, která popisuje funkčnost systému a/nebo chování uživatele, podle které jsou generovány testovací případy. Vytvoření testovacího modelu začíná vytvořením struktury a poté je schválená struktura naplněna testovacími případy.

Modely jsou obvykle sestavovány na základě požadavků a/nebo očekávaného chování systému. Vytvoření testovacího modelu a jeho správa je vhodná pro velké systémy se složitou obchodní logikou a je obtížné ji aplikovat na projekty využívající agilní metodiky, protože náklady na udržování řízení testovacího modelu a procesu zajišťování kvality budou příliš vysoké.

Správa testovacího modelu je proces, který řídí pokrytí testovacího modelu, kvalitu scénářů popisujících testovací model a jeho aktualizaci.

Správa testovacího modelu je nepřetržitý proces životní cyklus produkt.

Pokrytí testovacího modelu

Chcete-li řídit pokrytí všech požadavků, můžete použít trasovací matice, které určují pokrytí požadavků testovacími scénáři (viz příklad).
Před popisem testovacích případů musí být struktura testovacího modelu schválena zákazníkem.

Kvalita skriptu

Pro řízení kvality scénářů je nutné kontrolovat nejen úroveň popisu testovacích případů, ale také jejich kvalitu.

Před zahájením popisu testovacích případů je nutné definovat požadavky na každou úroveň popisu a kritéria kvality popisu testovacích případů.

Možné úrovně popisu testovacích případů:

Na 4. úrovni lze dohodu se zákazníkem nahradit dohodou.

Kritéria kvality pro popis testovacích případů mohou být následující:

• Testovací případy musí být napsány podle požadavků

Testování je proces ověřování, zda produkt splňuje jeho požadavky. Proto je v části obecného popisu testovacího případu (v systémech pro sledování testů se obvykle používá termín „Shrnutí“) nutné odkázat na konkrétní požadavek ve spojení s fragmenty textu požadavků. Všem účastníkům projektu tak bude jasné, na základě čeho je tento testovací případ napsán.

• Použijte podrobné předpoklady

Jak ušetřit čas na testovacích případech?

Nastavte pravidla formátování pro všechny testovací případy. Testovací případ tak bude snadno pochopitelný a čitelný pro každého účastníka projektu. Například v projektu můžete zadat následující pravidla:

• Všechny vstupní parametry by měly být označeny červeně.
• Všechny skripty musí být zvýrazněny modře,
• Všechny názvy tlačítek, polí, bloků jsou uvedeny kurzívou a tučným písmem.
• Důležité pasáže jsou podtržené.
• Každý provedený krok musí mít očekávaný výsledek.
• Každý krok v testovacích případech by měl popisovat pouze jednu akci a její očekávaný výsledek. Tito. při přijetí neúspěšného testovacího případu v konkrétním kroku by mělo být jednoznačně jasné, u které akce k chybě došlo.
• Očekávaný výsledek musí být jednoznačný.

Testovací případy musí být jednoznačné, tzn. by měly být koncipovány a formulovány tak, aby neumožňovaly nejednoznačný výklad, ale aby byly jasně srozumitelné všem účastníkům.

Pokud psaní testovacích případů trvá dlouho, pak může nastat situace, kdy specialista přestane vidět své chyby. K tomu potřebujete pohled ze strany – zde to pomůže křížová recenze. Tuto fázi se doporučuje provést v případech, kdy se vývoj testovacího modelu časově prodlužuje a je dlouhý. Například když vývoj testovacích scénářů trvá déle než 1 měsíc.

Lze provést proces kontroly kvality skriptu s ovládáním testovacího modelu- speciálně připravená šablona.

Aktualizace testovacího modelu

Je nutné pravidelně aktualizovat testovací model a samotné testovací případy, aby byly v souladu s požadavky, a také revidovat priority testovacích případů.

Pro aktualizaci můžete udržovat "matici požadavků"(Requirement Traceability Matrix): po každé změně určitého požadavku je ze systému sledování testů proveden a aktualizován výběr všech testovacích scénářů souvisejících s tímto požadavkem.

Ovládací prvky testovacího modelu:

• zkušební kolejnice
• testovací odkaz
• Jira+Zephyr
• Microsoft Test Manager (MTM)
• vynikat

Testování je proces, který umožňuje vyhodnotit kvalitu vyráběného produktu. Kvalitní softwarový produkt musí splňovat požadavky na něj funkční i nefunkční. PS musí implementovat všechny požadované VI a nesmí mít vady - rozdíly mezi reálnými vlastnostmi nebo chováním od požadovaných. Kromě toho musí mít PS vlastnosti spolehlivosti (nesmí docházet k zasekávání, pádům atd.), zabezpečení, poskytovat požadovaný výkon, být snadno použitelný, rozšiřitelný atd. Testování je tedy proces analýzy PS , zaměřené na identifikaci vad a posouzení vlastností PS.

Cíle testovacího procesu

Účelem testování je vyhodnotit kvalitu softwarový produkt přes

• kontroly interakce součástí;
• Kontrola správné integrace komponent;
• Kontrola správnosti provedení všech požadavků a zjišťování závad.

Vlastnosti testovacího procesu v RUP

Testování je opakující se proces ve všech fázích životního cyklu. Testování začíná od začátku počáteční fáze identifikace požadavků na budoucí produkt a úzká integrace se současnými úkoly. Pro každou iteraci je stanoven cíl testování a metody jeho dosažení. Na konci každé iterace se zjišťuje, do jaké míry bylo tohoto cíle dosaženo, zda jsou potřeba další testy, zda by se měly změnit principy a testovací nástroje.

Každá nalezená závada je zaznamenána v databázi projektu s popisem situace, ve které byla nalezena. Analytik určí, zda se jedná o skutečnou vadu a zda se jedná o opakování dříve zjištěné vady. Nalezený defekt je přiřazen prioritou A označující důležitost opravy. Návrhář odpovědný za vývoj subsystému, komponenty nebo třídy nebo jiná osoba určená manažerem přistoupí k odstranění závady. Pořadí, ve kterém se vady opravují, se řídí jejich prioritami. Testující zopakuje testy a je přesvědčen (nebo nepřesvědčí), že závada byla odstraněna.

Testovací vývojář zodpovědný za plánování, vývoj a implementaci testů. Vytvoří zkušební plán a model, zkušební postupy (viz níže) a vyhodnotí výsledky zkoušek.

tester (tester) zodpovědný za provádění testování systému. Mezi jeho povinnosti patří nastavování a provádění testů, vyhodnocování výkonu testů, zotavování se z chyb a zaznamenávání zjištěných závad.

Artefakty

Během testování jsou vytvořeny následující dokumenty:

Testovací plán– dokument, který definuje strategii testování v každé iteraci. Obsahuje popis cílů a záměrů testování v aktuální iteraci a také strategie, které budou použity. Plán uvádí, jaké zdroje budou vyžadovány, a poskytuje seznam testů.

Testovací model je reprezentace toho, co a jak bude testováno. Model obsahuje sadu kontrolních úloh, testovacích metod, testovacích scénářů a očekávaných výsledků (testovací případy), testovacích skriptů a popisů testovacích interakcí.

• Kontrolní úkol– soubor testovacích dat, podmínek provádění testu a očekávaných výsledků.
• Testovací metoda– dokument obsahující pokyny pro nastavení a provádění kontrolních úkolů, jakož i pro vyhodnocování získaných výsledků.
• Testovací skript- jedná se o zjednodušený popis zkoušky, včetně počátečních údajů, podmínek a posloupností akcí a očekávaných výsledků.
• Testovací skript je program, který se spouští během automatizovaného testování pomocí testovacích nástrojů.
• Popis interakce testu je diagram sekvencí nebo kooperací, který odráží tok zpráv uspořádaných v čase mezi testovacími komponentami a testovacím objektem.

Výsledky testů a údaje získané během provádění testů.

Model pracovní zátěže se používá k modelování externích funkcí prováděných koncovými uživateli, rozsahu těchto funkcí a pracovní zátěže generované těmito funkcemi. Model je určen pro provádění zátěžových a/nebo zátěžových zkoušek, které simulují provoz systému v reálných podmínkách.

Vady- jedná se o popisy skutečností nesouladu systému s požadavky zjištěnými při testování. Jsou typem požadavků na změnu.

Testovací práce se provádějí v každé iteraci ve všech fázích, ale cíle a záměry v různých fázích projektu se výrazně liší.

Fáze vstupu do projektu. V této fázi probíhá příprava na testování. To zahrnuje:

• Vytvořte plán testování obsahující požadavky na testování a testovací strategie. Lze vytvořit jeden plán pro všechny typy testování (funkční, zátěžové atd.) nebo samostatné plány pro každý typ.
• Analýza rozsahu testování.
• Formulace kritérií kvality a dokončení testování.
• Instalace a příprava pro provoz testovacích nástrojů.
• Formulace požadavků na projekt rozvoje PS, determinovaných potřebami testování.

Vývojová fáze. V iteracích této fáze začíná stavba testovacího modelu a souvisejících artefaktů. Vzhledem k tomu, že model VI je již v této fázi přítomen, můžete začít navrhovat testovací scénáře. Zároveň není vhodné provádět testy, protože v této fázi obvykle ještě nejsou žádné hotové fragmenty PS. Provádějí se následující činnosti:

• Vývoj testovacích scénářů.
• Tvorba testovacích skriptů.
• Vývoj kontrolních úloh.
• Vývoj zkušebních metod.
• Vývoj modelu pracovní zátěže.

Stavební fáze. V této fázi se objevují hotové systémové fragmenty a prototypy, které je nutné otestovat. Zároveň se téměř v každé iteraci kontrolují všechny moduly (jak dříve vyvinuté a testované, tak nové přidané v aktuální iteraci). Testy použité v předchozích iteracích se také používají v následujících iteracích pro regresní testování, to znamená pro kontrolu, zda je v nové iteraci zachována dříve implementovaná funkčnost systému. Provádějí se následující činnosti:

• Vytvořte plán testování pro každou iteraci.
• Upřesnění a přidání testovacího modelu.
• Provádění testů.
• Popis nalezených závad.
• Popis výsledků testu.
• Vyhodnocení výsledků testů.

Na základě výsledků testování jsou provedeny změny v kódu programu za účelem odstranění zjištěných závad, poté se testování opakuje.

Fáze nasazení. V iteracích této fáze se provádí testování celého PS jako softwarového produktu. Prováděné aktivity jsou obdobné jako v předchozí fázi. Detekce defektů určuje potřebu změn a opětovného testování. Iterační proces se opakuje, dokud nejsou splněna kritéria pro ukončení testu.

Výsledky testů jsou vyhodnocovány na základě testovacích metrik, které umožňují určit kvalitu testovaného PS a samotného procesu testování.

Instrumentální podpora

Vzhledem k tomu, že proces iterativního testování zahrnuje vícenásobné opakování testů, ruční testování se stává neefektivním a neumožňuje důkladné posouzení kvality softwarového produktu. To platí zejména pro zátěžové a zátěžové testování, kde potřebujete simulovat zátěž a nashromáždit značné množství dat. Řešením je použití nástrojů, které podporují automatizaci sestavování a provádění testů.

Stejně jako proces vývoje se i proces následného testování softwaru řídí specifickou metodikou. Metodologií v tomto případě rozumíme různé kombinace principů, nápadů, metod a konceptů, ke kterým se při práci na projektu uchýlíte.

V současné době existuje poměrně velké množství různých přístupů k testování, z nichž každý má své vlastní výchozí body, dobu provádění a metody používané v každé fázi. A vybrat si jedno nebo druhé může být docela problém. V tomto článku se podíváme na různé přístupy k testování softwaru a promluvíme si o jejich hlavních funkcích, které vám pomohou orientovat se v existující rozmanitosti.

Model vodopádu (Lineární sekvenční model životního cyklu softwaru)

Waterfall Model je jedním z nejstarších modelů, které lze použít nejen pro vývoj softwaru nebo testování, ale také pro téměř jakýkoli jiný projekt. Jeho základní princip je sekvenční pořadí, ve kterém jsou úkoly prováděny. To znamená, že k dalšímu kroku vývoje nebo testování můžeme přistoupit až po úspěšném dokončení předchozího. Tento model je vhodný pro malé projekty a je použitelný pouze v případě, že jsou jasně definovány všechny požadavky. Hlavní výhody této metodiky jsou ekonomická účinnost, snadné použití a správa dokumentace.

Proces testování softwaru začíná po dokončení procesu vývoje. V této fázi jsou všechny potřebné testy převedeny z jednotek na testování systému, aby bylo možné řídit provoz komponent jak jednotlivě, tak jako celek.

Kromě výše zmíněných výhod má tento přístup k testování i své nevýhody. Vždy existuje možnost nalezení kritických chyb v procesu testování. To může vést k nutnosti zcela změnit jednu z komponent systému nebo dokonce celou logiku projektu. Ale takový úkol je v případě vodopádového modelu nemožný, protože návrat k předchozímu kroku v této metodice je zakázán.

Více o modelu vodopádu se dozvíte z předchozího článku..

V-Model (model ověření a ověření)

Stejně jako model vodopádu je model V založen na přímé posloupnosti kroků. Hlavní rozdíl mezi těmito dvěma metodikami je v tom, že testování je v tomto případě plánováno souběžně s odpovídající vývojovou fází. Podle této metodiky testování softwaru proces začíná, jakmile jsou definovány požadavky a je možné zahájit statické testování, tzn. ověření a přezkoumání, což zabrání případným softwarovým závadám v pozdějších fázích. Pro každou úroveň vývoje softwaru je vytvořen vhodný testovací plán, který definuje očekávané výsledky a vstupní a výstupní kritéria pro daný produkt.

Schéma tohoto modelu ukazuje princip rozdělení úloh na dvě části. Ty, které se týkají designu a vývoje, jsou umístěny vlevo. Úkoly související s testováním softwaru jsou umístěny vpravo:

Hlavní kroky této metodiky se mohou lišit, ale obvykle zahrnují následující:

• Etapa definice požadavků. Do této fáze patří přejímací zkoušky. Jeho hlavním úkolem je posoudit připravenost systému ke konečnému použití.
• Fáze, ve které high-level design nebo High-Level Design (HDL). Tato fáze se týká testování systému a zahrnuje posouzení shody s požadavky na integrované systémy.
• Fáze detailního návrhu(Detailed Design) je paralelní s fází integračního testování, během které se testují interakce mezi různými komponentami systému.
• Po fázi kódování Začíná další důležitý krok – testování jednotek. Je velmi důležité se ujistit, že chování jednotlivých částí a komponent softwaru je správné a odpovídá požadavkům.

Jedinou nevýhodou uvažované metodologie testování je nedostatek hotových řešení, která by mohla být použita k odstranění softwarových defektů nalezených během testovací fáze.

inkrementální model

Tuto metodologii lze popsat jako multikaskádový model testování softwaru. Pracovní postup je rozdělen do několika cyklů, z nichž každý je také rozdělen do modulů. Každá iterace přidává softwaru určitou funkčnost. Přírůstek se skládá ze tří cyklů:

1. návrh a vývoj
2. testování
3. implementace.

V tomto modelu je možný současný vývoj různých verzí produktu. Například první verze může být ve fázi testování, zatímco druhá verze je ve vývoji. Třetí verze může zároveň projít fází návrhu. Tento proces může pokračovat až do konce projektu.

Je zřejmé, že tato metodika vyžaduje co nejrychlejší odhalení maximálního možného počtu chyb v testovaném softwaru. Stejně jako realizační fáze, která vyžaduje potvrzení připravenosti produktu k dodání koncovému uživateli. Všechny tyto faktory výrazně zvyšují váhu požadavků na testování.

Oproti předchozím metodikám inkrementální model má několik důležitých výhod. Je flexibilnější, změny požadavků vedou k nižším nákladům a proces testování softwaru je efektivnější, protože testování a ladění je mnohem jednodušší díky použití malých iterací. Je však třeba poznamenat, že Celkové náklady stále vyšší než v případě kaskádového modelu.

spirálový model

Spiral Model je metodologie testování softwaru, která je založena na inkrementálním přístupu a prototypování. Skládá se ze čtyř fází:

1. Plánování
2. Analýza rizik
3. Rozvoj
4. Školní známka

Ihned po dokončení prvního cyklu začíná druhý. Testování softwaru začíná ve fázi plánování a pokračuje až do fáze hodnocení. Hlavní výhodou spirálového modelu je, že první výsledky testů se objevují ihned po výsledcích testů ve třetí fázi každého cyklu, což pomáhá zajistit správné posouzení kvality. Je však důležité mít na paměti, že tento model může být poměrně drahý a není vhodný pro malé projekty.

Přestože je tento model poměrně starý, zůstává užitečný pro testování i vývoj. dále hlavním cílem v poslední době se změnilo mnoho metodologií testování softwaru, včetně spirálového modelu. Využíváme je nejen k nalezení závad v aplikacích, ale také k zjištění důvodů, které je způsobily. Tento přístup pomáhá vývojářům pracovat efektivněji a rychle opravovat chyby.

Přečtěte si více o spirálovém modelu v předchozím příspěvku na blogu..

Agilní

Agilní metodiku vývoje softwaru a testování softwaru lze popsat jako soubor přístupů zaměřených na využití interaktivního vývoje, dynamické formování požadavků a zajištění jejich implementace jako výsledek neustálé interakce v rámci samoorganizující se organizace. pracovní skupina. Většina agilních metodik vývoje softwaru má za cíl minimalizovat rizika prostřednictvím vývoje v krátkých iteracích. Jedním z hlavních principů této flexibilní strategie je schopnost rychle reagovat na možné změny, spíše než spoléhat na dlouhodobé plánování.

Zjistěte více o Agile(poznámka - článek v angličtině).

Extrémní programování (XP, extrémní programování)

Extrémní programování je jedním z příkladů agilního vývoje softwaru. Charakteristickým rysem této metodiky je „párové programování“, tedy situace, kdy jeden vývojář pracuje na kódu, zatímco jeho kolega neustále kontroluje napsaný kód. Proces testování softwaru je poměrně důležitý, protože začíná ještě před napsáním prvního řádku kódu. Každý aplikační modul by měl mít test jednotky, aby bylo možné opravit většinu chyb ve fázi kódování. Další rozlišovací vlastností je, že test určuje kód a ne naopak. To znamená, že určitou část kódu lze považovat za dokončenou pouze v případě, že projdou všechny testy. V opačném případě je kód odmítnut.

Hlavními výhodami této metodiky jsou neustálé testování a krátké verze, což pomáhá zajistit vysoká kvalita kód.

Skrumáž

Scrum – část agilní metodologie, iterativní postupný rámec vytvořený pro řízení procesu vývoje softwaru. Podle principů Scrumu by měl být testovací tým zapojen do následujících kroků:

• Účast na plánování scrumu
• Podpora testování jednotek
• Testování uživatelského příběhu
• Spolupracujte se zákazníkem a vlastníkem produktu na stanovení kritérií přijetí
• Poskytování automatizovaného testování

Kromě toho by členové QA měli být přítomni na všech každodenních schůzkách, stejně jako ostatní členové týmu, aby diskutovali o tom, co bylo testováno a uděláno včera, co bude testováno dnes, a také o celkovém průběhu testování.

Principy agilní metodologie ve Scrumu zároveň vedou ke vzniku specifických vlastností:

• Odhad úsilí potřebného pro každý uživatelský příběh je nutností
• Tester musí být pozorný k požadavkům, protože se mohou neustále měnit.
• Riziko regrese se zvyšuje s častými změnami kódu.
• Současné plánování a provádění testů
• Nedorozumění mezi členy týmu v případě, že nejsou zcela jasné požadavky zákazníka

Více o metodice Scrum se dozvíte v předchozím článku..

Závěr

Na závěr je důležité poznamenat, že dnešní praxe používání té či oné metodologie testování softwaru implikuje multiverzální přístup. Jinými slovy, neměli byste očekávat, že jedna metodika bude vhodná pro všechny typy projektů. Výběr jednoho z nich závisí na velkém množství aspektů, jako je typ projektu, požadavky zákazníka, termíny a mnoho dalších. Z hlediska testování softwaru je běžné, že některé metodiky se začnou testovat na začátku vývoje, zatímco u jiných je obvyklé počkat, až bude systém kompletní.

Ať už potřebujete pomoc s vývojem softwaru nebo testováním, specializovaný tým vývojářů a techniků kontroly kvality je připraven vyrazit.

Testování webových služeb

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?

Jakékoli hodnotící metriky jsou ztrátou času. V tuto chvíli můžete testovat, spouštět chyby, připravovat autotesty. Jakou magickou výhodu získáme z metrik pokrytí testem, abychom obětovali čas na testování?

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í z 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í novou verzi, a začneme testovat 1. z nich a najdeme tam překlepy a tlačítka, která se posunula o pár pixelů a další drobnosti... A nyní je čas na testování u konce a tato funkčnost byla podrobně testována. 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?

Před implementací jakékoli metriky je důležité rozhodnout, jak ji budete používat. Začněte tím, že přesně odpovíte na tuto otázku - s největší pravděpodobností okamžitě pochopíte, jak je nejlepší ji vypočítat. A já se v tomto článku podělím pouze o některé příklady a své zkušenosti, jak to lze provést. Ne proto, abyste slepě kopírovali řešení – ale proto, aby se vaše fantazie mohla spolehnout na tuto zkušenost a promyslet řešení, které je pro vás ideální.

Posouzení pokrytí požadavků testy

Řekněme, že máte ve svém týmu analytiky a ti netráví čas nadarmo. pracovní čas. Na základě výsledků jejich práce byly vytvořeny požadavky v RMS (Requirements Management System) - HP QC, MS TFS, IBM Doors, Jira (s dalšími pluginy) atd. V tomto systému kladou požadavky, které odpovídají požadavkům na požadavky (omlouvám se za tautologii). Tyto požadavky jsou atomické, sledovatelné, specifické… Obecně ideální podmínky pro testování. Co můžeme v takovém případě dělat? Při použití skriptovaného přístupu propojte požadavky a testy. Provádíme testy ve stejném systému, vytváříme spojení požadavek-test a kdykoli můžeme vidět zprávu o tom, které požadavky mají testy, které ne, kdy tyto testy prošly as jakým výsledkem.
Dostaneme mapu pokrytí, pokryjeme všechny nepokryté požadavky, všichni jsou šťastní a spokojení, nechybí nám chyby ...

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é.

Analytici také někdy hřeší se salátem v hlavě a obvykle je to plné problémů s celým projektem. Například vyvíjíte textový editor a ve svém systému můžete mít dva požadavky (mimo jiné): „musí být podporováno formátování html“ a „při otevírání souboru nepodporovaného formátu se zobrazí vyskakovací okno s otázkou se musí objevit." Kolik testů je potřeba pro základní ověření 1. požadavku? A za 2.? Rozdíl v odpovědích je s největší pravděpodobností asi stonásobný!!! Nemůžeme říci, že pokud je alespoň 1 test na 1. požadavek, stačí to - ale asi na 2. s největší pravděpodobností úplně.

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.

V projektu chybí, diskutuje se o nich ústně, každý si dělá, co chce/umí a jak rozumí. Testujeme to samé. Tím se dostáváme k obrovskému množství problémů nejen při testování a vývoji, ale také zpočátku nesprávné implementaci funkcí – chtěli jsme něco úplně jiného! Zde mohu poradit možnost „definujte a zdokumentujte požadavky sami“, a dokonce jsem tuto strategii několikrát použil ve své praxi, ale v 99% případů takové zdroje v testovacím týmu nejsou - takže pojďme mnohem méně způsob náročný na zdroje:

1. Vytvořte seznam funkcí. Sami! Ve formě google-tabletu, ve formátu PBI v TFS - vyberte si libovolný, pokud se nejedná o 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é.

Na projektu je obrovské množství dokumentace, analytici píší rychlostí 400 znaků za minutu, máte specifikace, technické specifikace, návody, reference (nejčastěji se to děje na přání zákazníka) a to vše funguje jako požadavky a vše je na projektu již dlouho Zmatená, kde jaké informace hledat?
Opakování předchozí části a pomoc celému týmu s úklidem!

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í.

Samozřejmě by bylo fajn otestovat nějaký pevný systém, ale naše produkty jsou většinou živé. Zákazník se na něco ptal, něco se změnilo v legislativě mimo náš produkt a někde analytici našli chybu předloňské analýzy... Požadavky si žijí vlastním životem! Co dělat?

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ů.

Ve skutečnosti může být zdrojem tohoto problému nejen nedostatek času, ale také vaše zcela vědomá volba je nedokumentovat (nelíbí se nám to, vyhýbáme se efektu pesticidů, produkt se příliš často mění atd.). Jak ale v tomto případě vyhodnotit pokrytí testem?

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 kontroly prováděny různými způsoby, ale budete vědět: kdy to bude naposledy testováno a s 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!

| 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 končí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
Připravte ducha osvícení
A zkušenost, syn těžkých chyb,
A génius, paradoxy příteli,
A náhoda, bůh je 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“. Sestavte informační model objektu pro různé účely:
■ výběr obuvi pro turistiku;
■ výběr vhodného botníku;
■ 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í?