Jak na testování? 18.4.2013
Proč? Vnímáme konstatní zájem zákazníků o problematiku testování Máme dlouholeté zkušenosti s testováním na mnoha zajímavých projektech
Naše zkušenosti Datamasking Procesní konzultace Synchronizace test. dat Automatizace testů QA Migrace Strategie testování Plně automatizované Vykonání testů Manuální
Program 9:00 9:10 Úvod 9:10 9:50 Otakar Ertl: Metodika testování internetového bankovnictví 9:50 10:30 Lukáš Mejdrech: Zátěžové testování Liferay portálu 10:30 11:00 Přestávka/občerstvení 11:00 11:40 Radek Václavík: Přístup k automatickému testování 11:40 11:50 Závěr
Testování IB České spořitelny Nový přístup k testování MCI Otakar Ertl
Agenda Představení IB České spořitelny Původní stav vývoje a testování Organizační změny Miniteamy Nová metodika Enterprise architect Propojení HPQC Dry Run testy Mockování Výsledky Diskuze
Servis24 & Business24
Servis24 & Business24 rychlá fakta 1,35 miliónu? uživatelů Cca 80% všech jednorázových příkazů realizovaných Českou spořitelnou Cca 5,3 mil. finančních transakcí za měsíc Více než 1000? obrazovek 4 velké release ročně Architektura připravena na paralelní vývoj minimálně na dvou nezávislých projektech
IB České spořitelny 4 vrstvy Rozsáhlá integrace 10 frontendů 18 backendů
Původní stav -vývoj Dokumentace v textové formě Pouze inkrementální postihování změn V rámci vývoje není prostor pro otestování nové funkcionality Oddělené teamy Veškerá komunikace s test teamem pouze přes HPQC defekty
Původní stav - testy Test dokumentace v excelu HPQC pouze na evidenci defektů Obrovské testy až 1500 řádek V exekuční fázi probíhalo až 7 překrývajících se kol Vysoká relativní chybovost evidováno cca 1200 chyb na release Testeři odděleni od vývojového teamu Na začátku testů cca 1. týden stovky showstoperů +
Současný stav Profinit jako systémový integrátor zastřešuje: Analýzu Vývoj Testování Systém testy (Funkční testy) Regresní testy Core testy
Organizační změny Miniteamy Jsou složeny z analytiků, vývojářů, testerů Pro každou novou funkcionalitu jeden mini team Vývojáři a testeři validují práci analytiků Testeři neformálně s vývojáři testují (DryRun test) Povinné buildování vývojářů Povinnost vývojářů po sobě vyzkoušet, že základní funkčnost funguje Výsledek odstranění showstoperů v prvním týdnu testů
Dry Run testy DESIGN IFAT SIT Dry Run Testy probíhající před SIT testy Neformální přístup Nutná koordinace termínů dodání vývoje a testingu Cíl: Odstranění show stoperů, základní otestování funkcionality, kontrola správnosti testovací dokumentace Prostředí: AT (vývojové) lokální build u vývojáře Mockování Organizace: miniteamy (analytik, vývojář, tester)
Mockování Simulace MW zpráv Vybrané zprávy nejsou odeslány na backendy ale jsou přesměrovány na mockovací simulátor Použití: Testy nové funkcionality, která ještě není na backendech vyvinuta. AT i ST2 prostředí
Nová metodika Enterprise architect Veškeré informace o fungování aplikace uloženy v EA EA obsahuje jedinou a jednoznačnou pravdu o aplikaci (odstranění inkrementů) HP Quality center Namapování HPQC na EA Plné využití HPQC jako jediného nástroje pro testování +
Informace uložené v EA Activity diagram
Informace uložené v EA Activity diagram Obrazovka
Informace uložené v EA Activity diagram Obrazovka Toky obrazovek
Mapování EA do QC
Přenos informací z EA do QC Export z databáze EA: Activity diagram Dílčí activity Obrazovky Toky obrazovek Pro všechny předchozí prvky umístění ve struktuře. Exportovány jsou pouze prvky pro daný release Vyexportovaný file ve formátu csv Import do QC: Standardní importovací tool QC
Namapování EA - QC
Namapování EA - QC
Namapování EA - QC
Namapování EA - QC
Namapování EA - QC
Struktura Totožné uložení objektů ve struktuře Objekty svázány přes unikátní ID převzaté z EA
Pokrytí REQ testy
Pokrytí REQ testy
Přínosy propojení EA a QC
Testy knihovny Volání vnořených testů z knihoven Využití - zejména navigace Výhody při změně stačí updatovat na jednom místě v knihovně
Testy - atributy
Testy životní cyklus
Testy - měříme
Coverage analysis
Dashboard
Výsledky přínosy - organizační změny Zvýšení kvality kódu vstupujícího do testů Pouze 2 testovací kola + 3 regresní Významné snížení chybovosti Snížení počtu showstoperů v prvním kole => rychlejší a efektivnější otestování
Defekty Defekty Porovnání vývoje defektů v21 a v23 250 1400 V21 vs v23 První týden v21 vs v23 1200 200 1000 150 800 600 100 v21 v23 All v21 All v21 All v23 All v23 A Defects v23 A Defects v23 A Defects v 21 400 50 A Defects v 21 200 0 0 1 2 3 4 5 6 7 8 9 10 1 5 9 13 17 21 25 29 33 Dny 37 41 45 49 53 57 61 65 69 73
Výsledky přínosy - metodické změny Snadnější identifikace testů k modifikaci pro další verzi na základě propojení EA a HPQC Jednoduché vyhledávání Regresních testů k nové funkčnosti Jednoduché vyhledávání Core testů Benefity HPQC (reporting, navázání chyb na testy) Možnost přesného a rychlého plánování Snadné dohledávání jak se má aplikace chovat (jediná pravda v EA) Transformace na novou metodiku proběhla bez zvýšení nákladů => prostor pro budoucí úspory
Diskuze
Děkuji za pozornost
Zátěžové testování Liferay portálu Lukáš Mejdrech
Zátěžové testy
Zátěžové testy co znamenají? Znamenají Testování systému pod zátěží Více než jednotky uživatelů najednou Více než jednotky dotazů za sekundu Zpravidla automatizované testy Neznamenají Testy funkčnosti
Zátěžové testy co umožňují? Load testing
Zátěžové testy co umožňují? Load testing Endurance testing
Zátěžové testy co umožňují? Load testing Endurance testing Volume testing
Zátěžové testy co umožňují? Load testing Endurance testing Volume testing Stress testing
Zátěžové testy co umožňují? Load testing Endurance testing Volume testing Stress testing Capacity testing
Zátěžové testy co umožňují? Load testing Endurance testing Volume testing Stress testing Capacity testing Spike testing
Zátěžové testy co potřebují? Funkční systém Definovat oblast testování Definovat zátěž Definovat přípustná kritéria Definovat testovací scénáře Vytvořit transakční mix testovacích scénářů Připravit data Umožnit automatizovaný průchod Nastavit měření Zajistit exkluzivní přístup
Zátěžové testy jak probíhají? Příprava Vyhodnocení Provedení
Kontext
Architektura Testované webové portály Liferay Obdobné portály na aplikačním serveru Propojovací middleware Autentizační a autorizační systém Databáze Datový sklad Liferay Dokumentový server Externí rozhraní ESB IDM ODS Document Server Email Server SMS gateway
Příprava
Příprava Analytické schůzky Definice rozsahu, zátěže, kritérií Workshopy Definice procesů jako testovacích scénářů Příprava 14 testovacích scénářů Samostatné procesy, komponenty Sestavení transakčního mixu Opakovatelné testovací scénáře dohromady Úpravy aplikace Povolení jakýchkoli potvrzovacích kódů doručovaných v SMS Zobrazení odkazů doručovaných v emailech Více než dvě stovky testovacích uživatelů Zatěžovací server s velmi rychlým připojením
Provedení
Provedení Nastavení Přístup z vnější sítě Exkluzivní přístup Provedení Postup Inicializace dat Nasazení upravené verze aplikace Spuštění monitorování serverů Spuštění testovacího scénáře převedení registrace Postupné spouštění samostatných testovacích scénářů se stejnou zátěží Transakční mix spouštěný postupně se vzrůstající zátěží Opakování po nápravě nalezených problémů
Apache JMeter Nástroj umožňující testovat: Webové aplikace přes protokoly HTTP a HTTPS Webové služby přes protokol SOAP Databáze pomocí JDBC LDAP JMS FTP Emaily přes protokoly SMTP(S), POP3(S) a IMAP(S) Příkazy a skripty Open source
Testovací scénáře v JMeter Vytvářeny Na základě důležitých procesů S důrazem na pokrytí komponent Obsahovaly Konfiguraci pro jazykové mutace rozhraní Konfiguraci testovacích uživatelů Simulaci prohlížeče Hlavičky Cache Cookies Prodlevu mezi dotazy Čítače pro tvorbu unikátních emailů a telefonních čísel Vyhledávání parametrů pro další dotazy Automatické kontroly odpovědí dotazy
Vyhodnocení
Vyhodnocení JMeter harmonogram JMeter dotazy Vytížení procesoru Využití paměti Swapování Využití síťových rozhraní Volání metod Vyhodnocení
Vyhodnocení samostatných scénářů Které dotazy trvají nejdéle? Kdy se přenáší nejvíce dat? Kolik dotazů nevyhovuje definovaným kritériím? Měnily se časy dotazů v průběhu testu? Která volání jsou nejpomalejší nebo dokonce kolabují?
Statistika dotazů - registrace 12000 10000 8000 6000 4000 Průměrná odezva serveru (ms) Průměrný čas odpovědi (ms) Průměrná velikost (KB) 2000 0
Odezvy dotazů v průběhu testu 45000 40000 35000 30000 25000 20000 15000 01 - Login 02 - Login.Prihlasit 03 - Registrace.Poslat_sms 04 - Registrace.Dalsi_krok 05 - Registrace.Dokoncit 10 - Registrace4 11 - Registrace4.Dalsi_krok 10000 5000 0 Čas
Odezvy dotazů v průběhu testu 45000 40000 35000 Problém při paralelním zpracování 30000 25000 20000 15000 01 - Login 02 - Login.Prihlasit 03 - Registrace.Poslat_sms 04 - Registrace.Dalsi_krok 05 - Registrace.Dokoncit 10 - Registrace4 11 - Registrace4.Dalsi_krok 10000 5000 0 Čas
Dotazy nevyhovující kritériím - vyhledávání Podle čísla smlouvy Podle emailu 100,00% 100,00% 90,00% 90,00% 80,00% 80,00% 70,00% 70,00% 60,00% 50,00% 40,00% 60,00% 50,00% 40,00% 01 - LoginCC 02 - LoginCC.Prihlasit 10 - Vyhledani.Vyhledat 11 - Odznaceni_klienta 20 - Vyhledani.Odhlasit 30,00% 30,00% 20,00% 20,00% 10,00% 10,00% 0,00% Odezva >2s Odezva >4s Odpověď >2s Odpověď >4s 0,00% Odezva >2s Odezva >4s Odpověď >2s Odpověď >4s
Metody volané portálem 45000 40000 35000 30000 25000 20000 Počet volání Průměrný čas odpovědi (ms) 15000 10000 5000 0 authenticationbypassword getclient getclient - NO_DATA getidentity
Metody volané portálem 45000 40000 35000 Databázový problém u čísla smlouvy 30000 25000 20000 Počet volání Průměrný čas odpovědi (ms) 15000 10000 5000 0 authenticationbypassword getclient getclient - NO_DATA getidentity
Vyhodnocení transakčního mixu Jak se vyvíjí podíl chybových dotazů s rostoucí zátěží? Které části systému jsou vytíženy nejvíce? Jak se vyvíjí podíl dotazů nevyhovujících definovaným kritériím? Kolik dotazů zvládne systém rozumně obsloužit? Co se stane po opadnutí velké zátěže?
Podíly jednotlivých typů chyb 4% 3% 2% Nekompletní stránka HTTP Timeout HTTP Connection reset HTTP Connection refused SSL peer not authenticated 404 Not Found 502 Bad Gateway 1% 0% 40 80 100 150 Počet souběžných uživatelů
Podíly jednotlivých typů chyb 4% 3% Systém dle požadavků obsluhuje 80 souběžných uživatelů 2% Nekompletní stránka HTTP Timeout HTTP Connection reset HTTP Connection refused SSL peer not authenticated 404 Not Found 502 Bad Gateway 1% 0% 40 80 100 150 Počet souběžných uživatelů
Propustnost 25,0 20,0 19,9 16,4 15,0 14,3 10,0 9,7 Úspěšných požadavků/s 5,0 0,0 40 80 100 150 Počet souběžných uživatelů
Propustnost 25,0 Systém dle požadavků obsluhuje 16 dotazů za sekundu 20,0 19,9 16,4 15,0 14,3 10,0 9,7 Úspěšných požadavků/s 5,0 0,0 40 80 100 150 Počet souběžných uživatelů
Vytížení procesoru 100 Liferay 75 50 25 0 Čas ESB IDM 100 100 75 75 50 50 25 25 0 Čas 0 Čas
Vytížení procesoru 100 Liferay 75 Nejvytíženější je jednoznačně aplikační server Liferay 50 25 0 Čas ESB IDM 100 100 75 75 50 50 25 25 0 Čas 0 Čas
Závěr Byla zjištěna nejvyšší zátěž vyhovující požadavkům 80 souběžných uživatelů, 16 dotazů za sekundu Bylo odhaleno několik problémů Dlouhé dokončení převodu registrace při paralelním přístupu Dlouhé přihlášení se k nové registraci kvůli číslu smlouvy Dlouhé dokončení nové registrace Dlouhé vyhledávání podle čísel smluv Byla odhalena slabá místa Dlouhé stahování všech souborů při zobrazení prvních stránek Vytížení procesoru aplikačního serveru Liferay Velké prodlevy komunikace mezi Liferay a IDM
Diskuze
Děkuji za pozornost
Diskuze u občerstvení
Přístup k automatickému testování Radek Václavík
Agenda Základní body o automatickém testování (dále jen AT) Náklady a výnosy zavedení AT Metodika AT Technologie a nástroje pro AT Business cases příklady Jak začít s AT
Základní body
Definice Automatizace testů je použití software na řízení vykonávání testů, porovnávaní aktuálních výstupů testů s předpokládanými výstupy, nastavení testovacích podmínek a reportování výsledků.
Proč ANO? Opakovatelnost a konzistence testů stejné vstupy a podmínky nezávislé na počtu opakování, odpadá problém s motivací lidí k opakování stejných testů Praktická znovupoužitelnost testů lze opakovat stejný test v různých prostředích, v různých konfiguracích, s mírně modifikovanými vstupními daty, a znovuspuštění testu je levné Praktické baseline testy automatizace umožňuje spustit velmi hutnou sadu testů, umožňují efektivně provádět regresní testování Eliminace lidských chyb testy jsou vykonávány vždy naprosto stejně
Proč NE? Vyšší počáteční náklady analýza, implementace, SW licence, HW Nutná pravidelná údržba adaptace na novou funkcionalitu SW. Nutná podmínka použitelnosti! Nevhodnost pro dynamicky se měnící funkcionality lépe se hodí pro regresní testy
3 základní tvrzení ROI automatizovaných testů není založeno na automatizaci existujících testů versus nákladů jejich manuálního vykonání Za normálních okolností se bude testování skládat jak z automatizované tak z manuální části + Typicky má smysl uvažovat o regresních, výkonnostních a smoke AT 3
Náklady a výnosy
3 základní výnosy (hard $$) Úspora nákladů za manuální testování [% opak. testů * počet opakování * cena testů] Úspora nákladů na kvalitu [snížení počtu chyb * cena opravy chyby] Redukce time-to-market [časová úspora ve dnech * ztráta revenue na den]
3 základní náklady (hard $$) HW a SW infrastruktura [cena licencí nástroje AT + cena HW] Analýza a implementace AT [cena feasibility study + cena tvorby scénářů AT + cena implementace AT + cena úprav testované app] Údržba a rozvoj AT [cena podpory licencí AT + roční inkrement AT + roční údržba AT]
4 další výnosy (soft $$) Posun v kvalitě testů a jejich scenářů Možnost kdykoliv a prakticky zdarma přetestovat funkcionalitu aplikace Detailní logovací a auditní záznamy (lehká reprodukovatelnost chyby) Profesionalita: Automatizované testování je intelektuálně přitažlivější než manuální -> motivační faktor pro profesionalitu
Náklady na testy 4 4 Náklady
Naše metodika
Postup automatizace testů Úvodní analýza (dny až týdny) Studie proveditelnosti, analýza a implementace vzorku testů (týdny až měsíce) Analýza a implementace testů, dělená na části (měsíce) Údržba testů
Úvodní analýza Stanovuje technologické a funkční varianty, vymezuje rozsah pokrytí testy a náplň dalších etap Výstupy Definice požadavků na systém automatického testování Vymezení hranic testovaného systému Varianty pro technologický návrh systému automatického testování Specifikace okrajových podmínek automatizovaných testů Návrh přístupu k tvorbě a rutinnímu spouštění automatizovaných testů za specifikovaných okrajových podmínek Přibližné vymezení rozsahu požadovaných testovacích případů Business case, je-li požadován
Studie proveditelnosti Prověřuje a hodnotí stanovené alternativy, navrhuje řešení Výstupy Detailní technologický návrh systému aut. testování Popis způsobu hlášení chyb ze systému automatických testů Specifikace úprav existující testovací infrastruktury Vzorek aut. testů na ukázku, v rámci možností neupravené infrastruktury Popis tvorby/programování a rutinního spuštění automatizovaných testů za specifikovaných okrajových podmínek, Upřesnění rozsahu požadovaných testovacích případů, Plán projektu pro vlastní vývoj/implementaci testů.
Analýza a implementace Rozdělení projektu na fáze (výsledky jsou vidět průběžně) Data driven testing (test = scénář + data) Lze vytvářet sady testů dle potřeby Validace analýzy např. pojistní matematici, testovací oddělení Validace vlastních testů testovací oddělení
Údržba Testy JE POTŘEBA UDRŽOVAT Pravidelné spouštění Kontrola výsledků Aktualizace testů dle změn systému Další rozvoj testů dle potřeb zákazníka
Technologie
Dva přístupy k AT Code-driven testování Testování kódu na nižší úrovni GUI testování Princip simulace klienta Princip automatizace klienta
Simulace klienta Server Client/Browser Automat
Simulace klienta Užívaný zejména na webové aplikace, které podporují princip request response Výhodami jsou robustnost řešení, podobnost s vývojem aplikací a jednoduchost a přehlednost testovacích aplikací Nevýhodami jsou nemožnost capture replay a obtížné provádění operací jen na straně klienta (javaskript)
Automatizace klienta Server Client/Browser Automat
Capture - Replay Metoda, při níž se monitorují uživatelské aktivity (capture), které se následně opakují (replay) K obsluze zpravidla nejsou nutné žádné technické znalosti Pořízení testu znamená provedení testu, což znamená nejnižší možné náklady na pořízení Nízká robustnost provádění testů Získané skripty jsou často prakticky neudržovatelné, což vede k problémům při parametrizaci a navýšení nákladů při změnách
Automatizace klienta Většina řešení na bázi Automatizace vychází z metody capture replay a odstraňuje její nedostatky K ovládání klientské aplikace se používají zpravidla prostředky operačního systému Výhodou je obecnost nasazení nezáleží na typu testované aplikace Nevýhodou je opět potenciální složitost nasnímaných skriptů Rovněž je třeba zvážit programovací jazyk
Gartner Magic Quadrant for Integrated Software Quality Suites Zdroj: Gartner (Leden 2011)
Business case příklady
Seznam příkladů Česká pojišťovna core systém pro správu smluv životního pojištění ČSOB S-Cube Česká spořitelna Partner24 unit testy ČSOB Pojišťovna testování core systému
Příklad č. 1 Automatizace testů, Česká Pojišťovna GUI testy
Situace Core systém pro správu smluv životního pojištění Porovnání nákladů na manuální a automatické vykonávání Cca. 60 komplexních testů Manuální Cca. 100 MD/release 5 release/rok Automatické Implementace testů Pravidelné spouštění a kontrola výsledků Aktualizace testů dle změn systému
Propojení s jinými systémy SAP R3 SPS Printnet DACP SAP FSCD DWH KCČ IMO KDP JOK/CCD OCE JOK PWB CZP JOK PK JOK JOK/CCM SUP-ISP...
Projekt automatizace testů KDP Úvodní analýza (10 dní) Studie proveditelnosti, analýza a implementace vzorku testů (3 měsíce) Analýza a implementace testů, dělená na části (9 měsíců) Údržba Testů (roky)
Rozsah studie proveditelnosti Volba rozsahu automatizace Návrh architektury Změny aplikace KDP a ATest Plán projektu POC
Volba rozsahu automatizace Kritičnost = f (business důležitost, chybovost, náklady na testování, náklady na odstraňování chyb,potenciální náklady na AT) Funkce Systémy
Pokrytí systému automatizací Pokrytí 80% funkcí systému Integrační testy 6 funkcí Kritičnost 2 31 funkcí Kritičnost 5 66 funkcí Kritičnost 4 Funkce systému 18 funkcí Kritičnost 3 Pokrytí systému testy
Postup automatizace testů Úvodní analýza (dny až týdny) Studie proveditelnosti, analýza a implementace vzorku testů (týdny až měsíce) Analýza a implementace testů, dělená na části (měsíce) Údržba Testů
Plán projektu Fázování zajistí vyšší přidanou hodnotu pro zákazníka Fáze 1 11 testů nejvyšší kritičnosti Analýza Tvorba scénářů a kroků Ostatní podpůrné činnosti Milník 2 Milník 3 Milník 4 Fáze 2 dalších 30-50 testů Analýza Tvorba scénářů a kroků Milník 5 Milník 1 Fáze 3 integrační testy a testy práv Analýza Tvorba scénářů a kroků 2.5. 16.5. 18.6. 18.7. 13.8. 14.10. 21.10. 30.7. 28.11.
Testy a jejich validace Data driven testing (test = scénář + data) Lze vytvářet sady testů dle potřeby Validace analýzy pojistní matematici, testovací oddělení Validace vlastních testů testovací oddělení
Čísla 60 plně automatizovaných regresních testů Z toho 10 testů práv a integračních Infrastruktura pro automatizované testy Dokumentace pro vývoj a údržbu systému Cca. 700 čd. Doba běhu celé sady cca. 24 h.
Nalezené chyby Nevygenerování záznamu pro požadavek na finální odkup. Duplicitní storna předpisů při přerušení placení. Chyba v účetnictví. Chyba v právech (přístup na správu front úkolů). Další chyby menšího dopadu.
Postup automatizace testů Úvodní analýza (dny až týdny) Studie proveditelnosti, analýza a implementace vzorku testů (týdny až měsíce) Analýza a implementace testů, dělená na části (měsíce) Údržba Testů
Nároky na údržbu Zkušenosti z přechodu na R3 a dále na R4 Velké změny úrazového pojištění cca. 1 čd/test (R2 -> R3) Technické změny cca. 0,2 čd/test (R3 -> R4) Dáno dobře navrženou architekturou (knihovna pro GUI, atp.).
Nároky na interní zdroje Vlastní know-how pojišťovnictví nižší náklady na interní zdroje odběratele. Pojistný analytik kompletní analýzy testů Zapojení strany odběratele zejména na připomínkování a akceptaci.
Údržba 1 rok 1 člověk na plný úvazek. Kontrola výsledků, reporty chyb. Aktualizace testů dle změn systému KDP. Další rozvoj testů mírný a řízený aktuálními potřebami zákazníka.
Další projekty
Automatizace testování S-Cube PoC S-Cube Obsah dodávky: Ověření technologické kompatibility testovacího nástroje HP Quick Test Professional verze 11 s aplikací S-Cube Návrh přístupu strojové identifikace objektů (Descriptive Programming vs. Object Repository) Zavedení unikátních ID objektů ze strany vývoje do aplikace pro bezproblémovou identifikace napříč verzemi (nulové náklady) Ověření přenositelnosti testů mezi verzemi aplikace a verzemi vývojové technologie Návrh architektury aut. Testů Granularita testů Knihovny Metodika psaní testů Testovací data a jejich úklid Návrh kritérií pro výběr manuálních testů vhodných pro automatizaci
Partner24 Aplikace pro back office externího prodeje externí partnery Kritická modulární platforma, nad kterou vznikají další aplikace Charakteristiky Partner24 Rozsah systému: cca 350 obrazovek, cca 200 tabulek Počty uživatelů: 3500 4000 Integrace s core systémy České spořitelny Funkční testování kompletně v režii zákazníka! Implementace a údržba testů: cca 5% Pokrytí testů: cca 30 40% funkčnosti
Balíčky Agenda povinného ručení, pojištění vozidel, nemovitostí a domácností. Automatizace celého životního cyklu smluv v systému kalkulačky pojistného, vznik, změny, storna, upomínky, výročí, tisky atd. Charakteristiky Rozsah systému: 1,8 milionu SLOC 400 obrazovek 2 4 releases ročně Počet uživatelů: tisíce Počet smluv: miliony Implementace a údržba testů: cca 5 % Pokrytí testů: cca 30 % funkčnosti
Jak začít s AT
Postup automatizace testů Úvodní analýza (dny až týdny) Studie proveditelnosti, analýza a implementace vzorku testů (týdny až měsíce) Analýza a implementace testů, dělená na části (měsíce) Údržba Testů
Úvodní analýza Stanovuje technologické a funkční varianty, vymezuje rozsah pokrytí testy a náplň dalších etap Výstupy Definice požadavků na systém automatického testování Vymezení hranic testovaného systému Varianty pro technologický návrh systému automatického testování Specifikace okrajových podmínek automatizovaných testů Návrh přístupu k tvorbě a rutinnímu spouštění automatizovaných testů za specifikovaných okrajových podmínek Přibližné vymezení rozsahu požadovaných testovacích případů Business case, je-li požadován
Postup automatizace testů Úvodní analýza (dny až týdny) Studie proveditelnosti, analýza a implementace vzorku testů (týdny až měsíce) Analýza a implementace testů, dělená na části (měsíce) Údržba Testů
Studie proveditelnosti Prověřuje a hodnotí stanovené alternativy, navrhuje řešení Výstupy Detailní technologický návrh systému aut. testování Popis způsobu hlášení chyb ze systému automatických testů Specifikace úprav existující testovací infrastruktury Vzorek aut. testů na ukázku, v rámci možností neupravené infrastruktury Popis tvorby/programování a rutinního spuštění automatizovaných testů za specifikovaných okrajových podmínek, Upřesnění rozsahu požadovaných testovacích případů, Plán projektu pro vlastní vývoj/implementaci testů.
Diskuze
Děkuji za pozornost
www.profinit.eu Děkujeme za pozornost