static testing dynamic testing difference between these two important testing techniques
Testování je Ověření a ověření . Všichni víme, že dokončení testu vyžaduje 2 Vs.
V dnešním článku si trochu posvítíme Statické testování . Nazývá se také Ověření. Dozvíme se o tom všechno a věnujeme tomu zvláštní důraz, protože Dynamické testování často dostává maximální pozornost a má nespočet článků, které ji podrobně popisují.
Žádná diskuse o statickém testování by však nebyla úplná bez vysvětlení, co znamená jeho protějšek, dynamické testování. Dynamické testování je validace, druhé „V“.
Dynamické testování je, když pracujete se skutečným systémem (nikoli s nějakým artefaktem nebo modelem, který představuje systém), poskytuje vstup, přijímá výstup a porovnává výstup s očekávaným chováním. Jedná se o praktickou práci se systémem se záměrem najít chyby.
Během tohoto procesu pochopíme, jak nejsou pravdivé následující dvě běžné mylné představy o testování:
- Testování je aktivita, která přichází na konci
- Provádí ji pouze testeři a ostatní nemají nic společného
Začněme krátkým odkazem na v-model :
- Na levá strana modelu V máme činnosti, které tým QA neprovádí.
- Na pravá strana , máme některé z nich, o které se stará tým Dev, některé testery a některé uživatelé.
Začněme s - Shromažďování požadavků . Provádí ji obchodní analytik a další nadřazená správa - výstupním dokumentem pro tuto fázi je dokument obchodních požadavků, BRD.
Další fází je Návrh systému . Návrh systému je fáze, kdy jsou obchodní požadavky převedeny do funkčních požadavků v dokumentu FRD (Functional requirements document).
Když dojde k překladu, tým vývojářů (který je v tomto kroku hlavním aktérem) projde dokument BRD krok za krokem, stránku po stránce a řádek po řádku. Přestože je primárním cílem spotřebovat obchodní požadavky kvůli překladu, dokument BRD se postupně přezkoumává.
Příklad: Řekněme, že toto je BRD pro bankovní web, který je velký v oblasti bezpečnosti. V BRD je část, která hovoří o pravidlech pro hesla pro různé uživatele, kteří si vytvářejí účet na webu online bankovnictví. Jedno z pravidel je: Uživatel nemůže použít heslo, které používá pro jiné účty.
To není možné. Protože web může pouze navrhnout, jak by měl uživatel nastavit přihlašovací údaje, ale neexistuje žádný způsob, lze toto omezení uvalit. Tento požadavek tedy není proveditelný - jinými slovy nelze jej dosáhnout prostřednictvím softwaru.
Zvažme nyní na základě tohoto příkladu následující body:
- Jak je možné zjistit, že tento požadavek nelze sestavit a nelze jej tedy otestovat (jinými slovy neproveditelně)? Máme web banky a potom nastavíme přihlašovací jméno a heslo - a pak si uvědomíme, že to není možné? Ne, vycházíme jednoduše z naší revize směrnice BRD a samozřejmě z nějakého běžného obchodního smyslu.
- Testujeme tento požadavek? Jistě, ale čistě na základě teoretického, koncepčního smyslu, ale ne na skutečném AUT (testovaná aplikace).
- Jaká je fyzická forma tohoto testu? -Jednoduché čtení nebo formální revize BRD nebo ještě formálnější analýza proveditelnosti obchodních požadavků.
Vracíme se k našim mylným představám:
- Kdo provádí tuto kontrolu BRD? - Většinou vývojový tým a další technické týmy, které jsou odpovědné za vytvoření produktu. Ne testeři.
- Probíhá tato kontrola na konci vytváření produktu? Ne, ve velmi počáteční fázi vývoje projektu. Proto nejen konec.
Techniky statického testování:
Stručně řečeno, statické testování je ověřovací částí testování softwaru, která se řídí metodami:
- Recenze dokumentů
- Návod
- Inspekce
- Analýza proveditelnosti nebo jakákoli jiná forma analýzy k určení, zda je software takový, jaký by měl být, či nikoli
- Kontrola kódu
Citovat CSTE CBOK, 'Ověření odpovídá na otázku:' Vytvořili jsme správný systém? ' zatímco ověřovací adresy: „Vytvořili jsme systém správně?“
Následuje seznam všech statických testovacích aktivit, ke kterým dochází na levé straně modelu V.
| SDLC fáze | Výstup | Ověřuje | Herci |
|---|---|---|---|
| Shromažďování obchodních požadavků | BRD (obchodní požadavek) | Rozsah dokumentu (pokud existuje) | |
| Návrh systémových požadavků | FRD (dokument s funkčními požadavky) | Zkontroluje / ověří BRD | Dev, technické týmy |
| Návrh technických požadavků | TDD (technický návrhový dokument) | Zkontroluje / ověří FRD | Dev, technické týmy |
| Design (kód) | Kód | Zkontroluje / ověří TDD. Kontrola kódu vývojovým týmem ohledně úplnosti, formátu atd. | Dev, technické týmy |
Poznámka: Tyto informace lze extrapolovat pro projekty podle jakékoli vývojové metodologie, protože kroky budou více či méně podobné.
Na pravé straně modelu V je ověření.
Techniky dynamického testování:
- Testování jednotek
- Testování integrace
- Testování systému
Fáze Unit, integrace, systému a UAT jsou o vytváření testů, které mají být prováděny na AUT během různých fází jeho vývoje. I když jsou testy zaměřeny na ověřování různých druhů požadavků, všechny jsou stejné.
K určení výsledku testu (úspěšného či neúspěšného) je tedy vyžadována jakákoli forma testování, kde máme test, který je třeba provést na AUTu a jeho výstupu - je to validace.
Bylo by v pořádku zobecnit, že na pravé straně (RHS) modelu V není vůbec žádné ověření? Odpověď je ne.
Všechny testy, které se vytvoří v každé fázi RHS, se během fáze vytváření / finalizace testu několikrát zkontrolují. Podrobný proces kontroly dokumentace k testu je na https://www.softwaretestinghelp.com/test-documentation-reviews/
kde najít klíč zabezpečení sítě na routeru
Na RHS:
- Testy a kód vývojáři kontrolují ve fázích testování Unit / Integration.
- Systémové testy procházejí během dokumentace peer review a po dokončení projdou kontrolou vývojářským týmem a obchodním analytikem.
- Testy UAT projdou kontrolou týmu QA i uživatelů před zahájením UAT.
Závěr
Závěrem lze říci, že statické testování je důležitou testovací technikou, která má podobu kontroly obchodních požadavků, kontroly funkčních požadavků, kontroly designu, návodů k kódu a kontroly dokumentace testu. Je to nepřetržitá činnost, kterou neprovádějí pouze testeři.
Ověření, dynamická testovací část je praktičtější a děje se na samotném produktu, nikoli na artefaktu nebo reprezentaci produktu. Mnohem formální proces identifikace testovacích případů / podmínek, úvah o pokrytí, provádění a hlášení vad - to vše označuje metody dynamického testování.
O autorovi: Tento článek je napsán členem týmu STH Swati S.
Sdílejte prosím své komentáře, dotazy a zkušenosti k tématu statického a dynamického testování.
Doporučené čtení
- Rozdíl mezi desktopem, klientským serverem a webovým testováním
- Agile Estimation Techniques: A True Estimation in an Agile Project
- Testování černé skříňky: Podrobný výukový program s příklady a technikami
- Co je testování shody (testování shody)?
- Jaký je rozdíl mezi testováním SIT vs UAT?
- Alfa testování a beta testování (kompletní průvodce)
- Klíčové rozdíly mezi testováním černé skříňky a testováním bílé skříňky
- Rozdíly mezi testováním jednotek, testováním integrace a funkčním testováním