Regresní testování (Regression testing)

Příklady z praxe

1. 01

   Oprava výpočtu slevy v e-shopu

   Vývojář opraví zaokrouhlování slev u košíku a tím se může nechtěně změnit výpočet pro běžné slevy. Regresní testy ověří, že nulová sleva nechá cenu beze změny a desetiprocentní sleva pořád vrací očekávaný výsledek. Pokud pozdější úprava logiky cenu rozbije, test selže ještě před nasazením.

   def apply_discount(price, percent):
       return round(price * (1 - percent / 100), 2)
   
   
   def test_zero_discount_keeps_original_price():
       assert apply_discount(1299, 0) == 1299
   
   
   def test_ten_percent_discount_still_works():
       assert apply_discount(1000, 10) == 900

2. 02

   Přepracovaný přihlašovací formulář

   Tým přepracuje vzhled přihlašovací stránky a přesune pole do nové komponenty. Regresní test projde scénář špatného hesla a ověří, že aplikace pořád zobrazí chybovou hlášku místo tichého selhání. Chyba v napojení formuláře se tak objeví v CI, ne až u uživatele.

   import { test, expect } from '@playwright/test';
   
   test('login keeps showing an error for a wrong password', async ({ page }) => {
     await page.goto('/login');
     await page.getByLabel('E-mail').fill('user@example.com');
     await page.getByLabel('Password').fill('bad-password');
     await page.getByRole('button', { name: 'Sign in' }).click();
     await expect(page.getByText('Invalid credentials')).toBeVisible();
   });

Časté omyly

MýtusKdyž máme unit testy, regresní testování už nepotřebujeme.

Ve skutečnostiUnit testy mohou být součástí regresní sady, ale samy o sobě obvykle nepokrývají spolupráci komponent, databázi, UI ani hlavní uživatelské toky. Regresní testování je účel kontroly, ne jeden konkrétní typ testu.

MýtusRegresní testování se dělá až těsně před releasem.

Ve skutečnostiRegresní testování těsně před releasem zachytí část problémů, ale zpětná vazba přichází pozdě. Rychlé regresní kontroly dávají větší hodnotu už během vývoje, například v pull requestu nebo CI.

MýtusKaždý nalezený bug musí hned dostat regresní test.

Ve skutečnostiRegresní test má největší smysl u chyby, která se může vrátit a má reálný dopad. Jednorázová chyba v nepoužívané části systému může být levnější opravit bez rozšiřování trvalé testovací sady.

Časté dotazy

Kolik regresních testů má projekt udržovat?

Počet regresních testů má odpovídat riziku projektu, ne snaze o co nejvyšší číslo. Kritické finanční toky, autentizace, oprávnění, migrace dat a často měněné části aplikace si obvykle zaslouží silnější pokrytí. Méně důležité scénáře mohou stačit ve smoke testech nebo v ruční kontrole před vydáním. Praktickým pravidlem je přidat regresní test tam, kde by opakování chyby bylo drahé nebo viditelné pro uživatele.

Patří regresní testování do každého pull requestu?

Regresní testování v pull requestu má být dost rychlé na to, aby vývojář dostal výsledek v rozumném čase. Typicky se spouští unit testy, vybrané integrační testy a malá sada nejdůležitějších end-to-end scénářů. Úplná regresní sada může běžet později, například před releasem nebo v nočním běhu. Příliš pomalá kontrola v pull requestu vede k obcházení pravidel a ztrácí hodnotu.

Kdy má být regresní test ruční místo automatický?

Ruční regresní test má smysl u scénářů, které se automatizují obtížně, mění se málo často nebo vyžadují lidské posouzení vzhledu, srozumitelnosti a pocitu z ovládání. Automatizace je vhodnější pro opakovatelné kontroly s jasným očekávaným výsledkem. Dobrý proces často kombinuje obě možnosti: stroje hlídají stabilní pravidla a tester se soustředí na oblasti, kde může najít nečekané souvislosti.

Proč regresní testy někdy zpomalují vývoj?

Regresní testy zpomalují vývoj hlavně tehdy, když jsou nespolehlivé, příliš závislé na detailech implementace nebo běží všechny při každé malé změně. Užitečná regresní sada bývá vrstvená: rychlá část běží často, pomalá část jen v důležitých bodech procesu. Zrychlení obvykle znamená odstranit flaky testy, paralelizovat běh, lépe připravit testovací data a pravidelně mazat testy, které už nechrání skutečné riziko.

Zdroje

1. Regression testing(otevře se v novém okně)Wikipedia
2. unittest(otevře se v novém okně)Python Software Foundation
3. Unit testing in .NET(otevře se v novém okně)Microsoft
4. Web Security Testing Guide(otevře se v novém okně)OWASP Foundation

Související pojmy

• RegreseRegrese je úloha strojového učení a statistiky, při které model odhaduje spojitou číselnou hodnotu z hodnot vstupních proměnných. Typickým výstupem je cena, teplota, doba trvání nebo objem prodeje. Model se učí ze vzorků se známou odpovědí a jeho chybu měříme vzdáleností předpovědi od skutečné hodnoty, nejčastěji střední kvadratickou chybou.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.
• Adaptive IconAdaptivní ikona je formát ikony aplikace na Androidu, který se místo jedné hotové bitmapy skládá z oddělených vrstev: pozadí a popředí. Systém výsledný tvar sám ořízne podle masky výrobce zařízení a může vrstvy animovat nebo přebarvit. Vývojář tak dodá jeden zdroj a launcher z něj vytvoří kruh, čtverec i squircle.
• Adresa v pamětiAdresa v paměti je číslo, kterým procesor jednoznačně označuje konkrétní buňku operační paměti, obvykle jeden bajt. Program pomocí adresy říká, odkud má data načíst nebo kam je zapsat. Adresy tvoří souvislý číselný rozsah, jehož velikost určuje šířka adresní sběrnice a architektura, typicky 32 nebo 64 bitů.
• AI agentAI agent je softwarový systém, který pomocí modelu umělé inteligence vnímá zadaný kontext, plánuje další kroky a samostatně volá nástroje nebo služby k dosažení cíle. Na rozdíl od jednorázového promptu udržuje stav úlohy, vyhodnocuje výsledky akcí a může opakovat postup, dokud nesplní zadání nebo nenarazí na limit.
• AndroidAndroid je operační systém postavený nad linuxovým jádrem, který vyvíjí Google a otevřeně uvolňuje jako projekt AOSP. Android pohání převážnou většinu chytrých telefonů, dále tablety, televize, hodinky i palubní systémy aut. Aplikace se pro něj píší hlavně v Kotlinu nebo Javě a distribuují přes Google Play i alternativní obchody.
• APIAPI je smluvené rozhraní, přes které spolu dva programy komunikují, aniž by jeden musel znát vnitřní fungování druhého. Definuje, jaké operace lze volat, jaká data se posílají a co se vrátí zpět.
• API GatewayAPI Gateway je vstupní vrstva mezi klientem a sadou backendových služeb, která přijímá požadavky, směruje je na správné API, vynucuje bezpečnostní pravidla a často řeší limity, logování nebo transformace odpovědí. Pomáhá skrýt vnitřní strukturu systému a sjednotit chování pro web, mobilní aplikaci i partnery.