Jak na testování?

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

Plně automatizované

Strategie testování

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

•

Prostředí:

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 – –

• •

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





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í

Porovnání vývoje defektů v21 a v23 V21 v21 vs v23 První týden vs v23 250 1400

1200

200

1000 Defekty Defekty

150

All v21 All v21

800

All v23 All v23 v23

100 600

A Defects v23 A Defects v23

v21

A Defects v 21 A Defects v 21

400

50

200 0 1

0 1

5

2

3

4

5

6

7

8

9

10

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


• Endurance testing


• Endurance testing • Volume testing



• Stress testing



• Stress testing • Capacity 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

ODS

Document Server

IDM

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ářů

• 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

Příprava

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 Průměrná odezva serveru (ms)

4000

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 01 - Login 02 - Login.Prihlasit

25000

03 - Registrace.Poslat_sms 04 - Registrace.Dalsi_krok 20000

05 - Registrace.Dokoncit 10 - Registrace4 11 - Registrace4.Dalsi_krok

15000

10000

5000

0

Čas

Odezvy dotazů v průběhu testu 45000

40000

35000

• Problém při paralelním zpracování

30000 01 - Login 02 - Login.Prihlasit

25000

03 - Registrace.Poslat_sms 04 - Registrace.Dalsi_krok 20000

05 - Registrace.Dokoncit 10 - Registrace4 11 - Registrace4.Dalsi_krok

15000

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%

60,00%

50,00%

50,00%

40,00%

40,00%

30,00%

30,00%

20,00%

20,00%

10,00%

10,00%

01 - LoginCC 02 - LoginCC.Prihlasit 10 - Vyhledani.Vyhledat 11 - Odznaceni_klienta

0,00%

20 - Vyhledani.Odhlasit

0,00%

Odezva >2s

Odezva >4s

Odpověď >2s Odpověď >4s

Odezva >2s

Odezva >4s

Odpověď >2s

Odpověď >4s

Metody volané portálem 45000

40000

35000

30000

25000 Počet volání Průměrný čas odpovědi (ms)

20000

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 Počet volání Průměrný čas odpovědi (ms)

20000

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%

Nekompletní stránka HTTP Timeout HTTP Connection reset

2%

HTTP Connection refused

SSL peer not authenticated 404 Not Found 502 Bad Gateway 1%

0% 40

80

100

Počet souběžných uživatelů

150

Podíly jednotlivých typů chyb 4%

• Systém dle požadavků obsluhuje 80 souběžných 3%

uživatelů Nekompletní stránka HTTP Timeout HTTP Connection reset

2%

HTTP Connection refused

SSL peer not authenticated 404 Not Found 502 Bad Gateway 1%

0% 40

80

100


150

Propustnost 25,0

19,9

20,0

16,4

14,3

15,0

Úspěšných požadavků/s

10,0

9,7

5,0

0,0 40

80

100


150

Propustnost 25,0

• Systém dle požadavků obsluhuje 16 dotazů za sekundu 19,9

20,0

16,4

14,3

15,0

Úspěšných požadavků/s

10,0

9,7

5,0

0,0 40

80

100


150

Vytížení procesoru Liferay 100 75 50 25 0

Čas

ESB

IDM

100

100

75

75

50

50

25

25

0

0

Čas

Čas

Vytížení procesoru Liferay 100 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

0

Čas

Č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


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

Náklady

4

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 DWH

SAP FSCD

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

31 funkcí Kritičnost 5



Funkce systému


Pokrytí systému testy




Údržba Testů Analýza a implementace testů, dělená na části (měsíce)

Plán projektu • Fázování zajistí vyšší přidanou hodnotu pro zákazníka Fáze 1 – 11 testů nejvyšší kritičnosti Milník 2

Analýza Tvorba scénářů a kroků

Milník 3

Ostatní podpůrné činnosti

Milník 4

Fáze 2 – dalších 30-50 testů Analýza Tvorba scénářů a kroků

Milník 1

Milník 5

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

14.10.

21.10.

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.





Ú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





Ú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





Ú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


www.profinit.eu

Děkujeme za pozornost

Jak na testování?

Recommend Documents