Vývoj řízený akceptační zkouškou - Acceptance test–driven development - Wikipedia

Vývoj softwaru
Hlavní činnosti
Paradigmata a modely
Metodiky a rámce
Podpůrné disciplíny
Praxe
Nástroje
Standardy a subjekty znalostí
Glosáře
Obrysy

Vývoj řízený akceptační zkouškou (ATDD) je rozvoj metodika založená na komunikaci mezi obchodními zákazníky, vývojáři a testery.[1] ATDD zahrnuje mnoho stejných postupů jako specifikace příkladem (SBE),[2][3] vývoj založený na chování (BDD),[4] příkladem řízený vývoj (EDD),[5] a podpora-řízený vývoj také volal příběh test-řízený vývoj (SDD).[6] Všechny tyto procesy pomáhají vývojářům a testerům porozumět potřebám zákazníků před implementací a umožňují zákazníkům konverzovat v jejich vlastním doménovém jazyce.

ATDD úzce souvisí s testovaný vývoj (TDD).[7] Liší se důrazem na spolupráci vývojář-tester-obchodní zákazník. ATDD zahrnuje přejímací zkoušky, ale zdůrazňuje psaní akceptačních testů dříve, než vývojáři začnou kódovat.

Přehled

Akceptační testy jsou z pohledu uživatele - z vnějšího pohledu na systém.[1] Zkoumají externě viditelné efekty, jako je zadání správného výstupu systému s daným konkrétním vstupem. Akceptační testy mohou ověřit, jak se stav něčeho mění, například objednávky, která přejde z „zaplaceno“ na „odesláno“. Mohou také kontrolovat interakce s rozhraními jiných systémů, jako jsou sdílené databáze nebo webové služby. Obecně platí, že jsou nezávislé na implementaci, i když jejich automatizace nemusí být.[8][9]

Tvorba

Akceptační testy se vytvářejí při analýze požadavků a před kódováním.[1] Mohou být vyvíjeny společně žadatelem požadavků (vlastník produktu, obchodní analytik, zástupce zákazníka atd.), Vývojářem a testerem. Vývojáři implementují systém pomocí akceptačních testů. Neúspěšné testy poskytují rychlou zpětnou vazbu, že požadavky nejsou splněny. Testy jsou specifikovány v podmínkách obchodní domény. Tyto výrazy pak tvoří všudypřítomný jazyk, který sdílejí zákazníci, vývojáři a testeři.[10] Zkoušky a požadavky spolu souvisejí.[11] Požadavek, kterému chybí test, nemusí být správně implementován. Test, který neodkazuje na požadavek, je nepotřebný test. Přijímací test, který je vyvinut po zahájení implementace, představuje nový požadavek.[12]

Strategie testování

Akceptační testy jsou součástí celkové testovací strategie. Jsou to zákaznické testy, které demonstrují obchodní záměr systému. Testy komponent jsou technické přejímací testy vyvinuté architektem, které specifikují chování velkých modulů. Testy jednotek vytváří vývojář pro správu snadno udržovatelného kódu.[13] Často jsou odvozeny z přejímacích zkoušek a jednotkových testů. Cross-funkční testování zahrnuje testování použitelnosti,[14] průzkumné testování,[15] a testování vlastností (škálování a zabezpečení).[16]

Kritéria přijetí a testy

Kritéria přijetí jsou popisem toho, co by bylo kontrolováno testem. Vzhledem k požadavku jako „Jako uživatel si chci rezervovat knihu z knihovny“ může být kritériem přijetí „ověřit, že je kniha označena jako rezervovaná“. Akceptační zkouška pro tento požadavek poskytuje podrobnosti, aby mohla být zkouška spuštěna se stejným účinkem pokaždé.

Formát testu

Akceptační testy mají obvykle tento tvar:[1]

Dáno (nastavení)

Zadaný stav systému

Když (spoušť)

Dojde k akci nebo události

Pak (ověření)

Stav systému se změnil nebo byl vytvořen výstup

Je také možné přidat příkazy, které začínají A v kterékoli z níže uvedených sekcí (Dáno, Kdy, Pak).

U ukázkového požadavku mohou být kroky uvedeny jako:

Dáno Kniha, která nebyla odhlášenaA Uživatel, který je registrován v systémuKdyž Uživatel si rezervuje knihuPak Kniha je označena jako rezervovaná

Kompletní test

Předchozí kroky nezahrnují žádná konkrétní příkladová data, takže se přidají k dokončení testu:

Dané:

Kniha, která nebyla odhlášena
Knihy
TitulOdhlásil
Skvělá knihaNe
Uživatel, který je registrován v systému
Uživatelé
názevSam

Když:

Uživatel si rezervuje knihu
Akce pokladny
UživatelSamZkontrolujeSkvělá kniha

Pak:

Kniha je označena jako rezervovaná
Knihy
TitulOdhlásilUživatel
Skvělá knihaAnoSam

Testovací zkouška

Zkouška testu konkrétními údaji obvykle vede k mnoha otázkám. U ukázky to mohou být:

  • Co když je kniha již vydána?
  • Co když kniha neexistuje?
  • Co když uživatel není v systému zaregistrován?
  • Existuje datum, kdy má být kniha odbavena?
  • Kolik knih si může uživatel rezervovat?

Tyto otázky pomáhají osvětlit chybějící nebo nejednoznačné požadavky. K očekávanému výsledku lze přidat další podrobnosti, například termín splatnosti. Jiné akceptační testy mohou zkontrolovat, že podmínky, jako je pokus o vydání knihy, která je již rezervována, způsobí očekávanou chybu.

Další příklad testu

Předpokládejme, že obchodní zákazník chtěl obchodní pravidlo, že si uživatel může rezervovat pouze jednu knihu najednou. Následující test by prokázal, že:

Scénář:Zkontrolujte, zda je vynucováno obchodní pravidlo pokladny

Dané:

Kniha, která byla rezervována
Knihy
TitulOdhlásilUživatel
Skvělá knihaAnoSam
Další skvělá knihaNe
Uživatelé
název
Sam

Když:

Uživatel si rezervuje jinou knihu
Akce pokladny
UživatelSamZkontrolujeDalší skvělá kniha

Pak:

Došlo k chybě
Vyskytla se chyba
Popis
Porušení obchodního pravidla placení

Akceptační testy projektu

Kromě přejímacích zkoušek požadavků lze na celém projektu použít přejímací zkoušky.[1] Například pokud byl tento požadavek součástí projektu pokladny knih, mohlo by dojít k akceptačním testům pro celý projekt. Ty se často nazývají SMART cíle. Příklad testu je „Když bude nový knihovní systém ve výrobě, uživatelé budou moci knihy přihlašovat a odhlašovat třikrát rychleji než dnes“.

Viz také

Reference

  1. ^ A b C d E Pugh, Ken (2011). Lean-Agile Acceptance Test-Driven Development: Lepší software díky spolupráci. Addison-Wesley. ISBN  978-0321714084.
  2. ^ Adzic, Gojko. (2009) Překlenutí komunikační mezery: specifikace příkladem a agilní přejímací zkoušky, Neuri Limited,
  3. ^ Adzic, Gojko (2011). Specifikace na příkladu: Jak úspěšné týmy dodávají správný software. Manning. ISBN  978-0-321-27865-4.
  4. ^ Chelimsky, David, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp a Dan North. Kniha RSpec: Vývoj založený na chování s RSpec, okurkou a přáteli. Pragmatická knihovna.
  5. ^ „Ukázkový design“. Citováno 2013-04-15.
  6. ^ „Příběh založený na testech (PDF). Citováno 2013-04-15.
  7. ^ Beck, Kent. Vývoj řízený testem: Příkladem. Addison-Wesley Professional, 2002.
  8. ^ Melnik, Grigori a Frank Maurer. Mělník, Grigori; Maurer, Frank (2007). „Více pohledů na vývoj řízený přijatelnou akceptací“. Agilní procesy v softwarovém inženýrství a extrémním programování. Přednášky z informatiky. 4536. 245–249. doi:10.1007/978-3-540-73101-6_46. ISBN  978-3-540-73100-9.
  9. ^ Koskela, Lasse. (2007) Test Driven: TDD and Acceptance TDD for Java Developers. Manning Publications
  10. ^ Evans, Eric. (2003) Design založený na doménách: řešení složitosti v srdci softwaru. Addison-Wesley Professional.
  11. ^ Weinberg, Gerald; Gause, Donald (1989). Zkoumání požadavků: Kvalita před návrhem. Dorset House. ISBN  0-932633-13-7.
  12. ^ Martin, Robert C. a Grigori Melnik.„Zkoušky a požadavky, požadavky a zkoušky: Möbiova páska“ (PDF). Citováno 2013-04-15.
  13. ^ [Test-driven_development]
  14. ^ Meszaros, Gerard a Janice Aston. (2006) „Přidání testování použitelnosti k agilnímu projektu.“ Agilní konference
  15. ^ „Vysvětlení průzkumných zkoušek“ (PDF).
  16. ^ Meszaros, Gerard. (2007) Testovací vzory xUnit: Refactoring Test Code. Addison-Wesley.

externí odkazy