Testuji, testuješ, testujeme (diskuse)

[Käyttäjä 11133]

No knihovna... Knihovna je blackbox který poskytuje nějaké operace a je tam vstup a výstup. V dokumentaci je popsáno co by taková funkce měla se vstupem udělat a jaký by měl pak být výstup. Ty by si se neměl starat o vnitřní strukturu jak to ta knihovna provede, ale jenom se dívat, jestli pro zadaný vstup dostaneš očekávaný výstup. Zkoušet co se stane, když tam pošleš něco, co by tam být nemělo, jestli se to s tím vypořádá,... Prostě jestli se knihovna chová přesně tak, jak by podle dokumentace měla.

[thingie]

Jo, dokud to nezačne mít side effecty a další zla.

[Rootan]

Tak to reportneš a pošleš na opravu ne?

[thingie]

Od toho jsou nepříjemné side-effecty nepřijemnými side effecty, aby se daly blbě najít a ještě hůř reportovat. Nemluvě o něčem takovém jako snad replikovat

[Filip Jirsák]

Systémové knihovny by měly mít automatizované testy ve stylu XUnit testování. Od systémové knihovny se očekává, že její funkce budou na zadaný vstup vracet konkrétní výsledek nebo skončí s konkrétní chybou. Pokud už by je měl testovat nějaký tester, musí vystupovat v roli uživatele té knihovny, tj. programátora – a testovat použití knihovny v nějakém kódu. Čímž se dostáváme zpět k XUnit testování, protože je škoda takto napsaný kód nespouštět opakovaně a neformalizovat výstup z těchto testů.

Uživatelské testování (člověkem) je potřeba pro testování UI (část se dá zvládat automatizovaně, ale zda UI dává nějakou logiku už musí posoudit člověk), případně na nějaké komplexní systémy, kde se nevyplatí psát testy na všechny možné případy.

[derddddd]

1. tester - clovek, kt. by dle meho mel mit celkem globalni zkusentosti s PC (development, network, soft/hard), toze je to clovek, kt. naleza chyby, kt. mohou nekdy lezet i mimo app(rozumej napr. -> server). Ale takovy tester s velkym T se clovek stava praxi. Ale dulezitou veci je, ze mozna nebude souhlasit, ale jiste pomuze, kdyz je to ex-vyvojar, kt. vi jak to "chodi" a specifikace chyby jsou presnejsi - ale co je dulezite a musim dodat(je-li to ex-vyvojar), nikdy nesmi sahat do kodu i presto, ze jej zna - tester musi byt odstinen od logiky app.

2. iAPP nebo K/S - jasne ze zalezi na platforme, KlientServer app mi nic nerikaji, ale co se tyce web. apps.... zde je velmi velikym prinosem, kdyz testera dela clovek znaly HTML,JS,CSS(visualni veci + chby v jsku), dale znalosti serveroveho reseni.... atd.

3. mel by to byt celkem klidny a vyrovnany clovek....

[Pavel Kysilka]

zdravim,

velmi tezko se mi odpovida. Pisete vcelku nejasne, co vlastne chcete.

Nicmene se mi velmi osvedcily dane postupy:

- Zadani by melo byt idealne i s testy nebo idealne formou testu.

- Idealne dostat i testovaci data (vstupni, vystupni) a s temi porovnat, co skutecne aplikace dela.

- Aplikaci piste i s testy.

- Inverse - zkuste docilit, toho, aby se aplikace chovala jinak, nez ma a pokud se Vam to povede, tak testy neprosly.

- Aplikace by mela mit moznost velmi pruzne nacist a zpracovat data v ruznem stavu a miste daneho programu.

- Dve oddeleni si navzajem testuji aplikace a kdyz je vice chyb, tak se plati vice piv. Rivalita hodne zkvalitni program.

- Posadte k aplikaci nekoho hodne neznaleho aplikace nebo i pocitacu. Vetsinou Vam to zbori.

- Nejlepsi testovani aplikace je prvni skoleni uzivatelu.

- Delate -li vylepsenou kopii aplikace, tak nechte bezet starou a novou instanci aplikace zaroven.

Metodik a nastroju je skutecne mnoho. Cim lepsi programator, tim vice umi testovat. S guru, kteri umi naprogramovat slozity kod, ale nasekaji mraky chyb (nenaimplementovano, opomenuto, naimplementovano jinak,...), je ve vysledku vice prace nez uzitku.

bye gf

[Pavel Kysilka]

jeste jedna dobra testovaci technika:

spuste aplikaci bez dat v databasi. pouze se strukturami database nebo s daty, ktere v databasi musi nezbytne byt po instalaci.

bye gf

[finc]

Mel by jsi si urcit urovne testu.

1. U striktne typovych jazyku, ziskam prvni otestovani uz jen tim, ze kod pujde zkompilovat.

2. Dalsi urovni muze byt samotne psani Unit testu, ktere by se meli psat zaroven s psanim noveho kodu (dejme tomu tridy). Tato uroven je nejdulezitejsi a ze vsech

3. Spustena aplikace a nahodne testovani, ktere simuluje uzivatele. Zde se spise jedna o test na samotne GUI.

4. Test od neprogramatoru. Za dobu, co programuji, jsem se naucil jednu zasadni vec. Programator je spatny uzivatel. Dela to, co predpoklada, ze je spravne. Lidska predstavivost je natolik fascinujici, ze hned prvni uzivatel udela vec, s kterou jste vubec nepocital :)

5. Samotny beh programu. Zadny program neni bez chyby, tak je jasne, ze se za behu budou objevovat nejake ty bugy. Zde by mela byt zpetna vazba mezi uzivateli a vyvojari pomoci nejakych automatizovanych nastroju.

Jinak co se tyce aplikaci nad DB. Existuje i moznost spustit DB v safe (nevim presne nazev) modu, ktery mi ochrani data pred znehodnocenim, ktere muze nastat behem testu.

Jinak, rad si pripomenu jeden citat: "Zadny kod neni funkcni, pokud k nemu neexistuji testy.".

[Rootan]

No co mám teď čerstvou zkušenost, neb jsem hned po státnicích nastoupil do práce jako tester-analytik, tak to u U:fona děláme takto: Udělá se akceptační dokument, v něm je sada test caseů, které se projedou v několika test runech.

Test case je tabulka o třech sloupcích, kde jsou popsány jednotlivé kroky, očekávané výsledky a v posledním výsledek testu (OK, Failed, Not tested a pod...)

Testujeme tu vše jak GUI tak DB a spoustu dalších věcí, které se týkají celého toho businessu.

Jsou tu lidi co testovali pro Vodafone a tam to funguje podle všeho stejně.

[HS]

1. Nepodcenuj analyzu projektu. Vetsina bolestnych problemu vznika prave tam. Ujastni si, co kazda funkce v knihovne bude delat, jake ma vstupy a jake vystupy.

2. Pokud uz mas knihovnu napsanou, udelej si testovaci program, ktery overi na danych datech, zda knihovna vraci odpovidajici vystupy. Pokud nikoliv, oprav ji a az pak pokracuj dalsi casti projektu.

Testovaci program nacte vstupni data a na nich overi vsechny funkce v knihovne, a vyhodi vysledky.

Co se tyka testeru, vybuduj si vhodnou sit. Podle me zkusenosti je vhodne mit v tymu testera neprogramatora i testera programatora. Kazdy z nich se zameruje na jine veci.

Pokud-li chces testovat knihovnu, kterou napsal nekdo jiny, prvne si precti dokumentaci a seznam se s problematikou. Pak pokracuj bodem 2 a over, zda jsi dostal spravne ysledky. Pokud ne zapatrej , kde se stala chyba ( uz v analyze nebo az v implementaci ? ) a dej o tom vedet autorovi pripadne ji jinak zverejni.

[kafa]

Ta současná móda testerů mi poněkud vadí. Nic proti ověřování ale zdá se mi, že se programátoři zbavují svých povinností. Žádný technologicky složitý výrobek (a tím program je) nemůže být testován až po dokončení. Kontrolovat se musí každá součástka a každá výrobní operace. Testovat všechny povolené i nepovolené kombinace vstupů - jak se radilo někdy v 60. letech - už při složitosti dnešních programů nelze. Kdysi vyšla tlustá kniha o verifikaci programů, kde v samém závěru autor konstatoval,že žádný spolehlivý způsob verifikace prostě neexistuje. Nejspolehlivějším způsobem je kontrola algoritmů a tedy kódu a tu musí provádět analytik a programátor. A pak samozřejmě kontrola vstupních filtrů a výjimek, tam se snad tester uplatnit může. Ale spíše než program kontroluje to, zda se si jeho autor příliž neulehčoval práci a neflákal se. A pokud firma potřebuje stádo testerů, pak si nemohu myslet nic dobrého ani o jejích programátorech ani o tom, kdo je řídí!

[Filip Jirsák]

To co popisujete vy je ale pouze kontrola dílčích komponent. Ta ale ještě nezaručuje, že když z těch komponent něco poskládám, bude i ten výsledek v pořádku. Samozřejmě že je nutné testovat jednotlivé komponenty už v průběhu jejich vývoje, ale pak je také potřeba otestovat na závěr, zda to funguje všechno dohromady a dělá to to, co to dělat mělo.

[kafa]

I "montáž" dílčích komponent je výrobní operací a programátor je povinnen ji překontrolovat. V článku se mluví mj. o testování systémových knihoven testerem. Ale to je přeci bez znalosti kernelu a zdrojového kódu jenom ztráta času. Systémové knihovny musí být snad testovány okruhem vývojářů a ne až v rámci nějaké aplikace, kde se na případné vedlejší efekty težko příjde. Kdyby se aplikační programátor nemohl spolehnout ani na systémové knihovny, pak nejrozumnější reakcí je změnit systém. Nepochybuji o tom, že je třeba testovat i výsledný job. Ale trochu mě mate vznik testerů coby samostatné profese mimo okruh vývojářů, kteří suplují jejich povinnosti. V praxi jsem se setkal s výstupní kontrolou podobným týmem ve stylu "je-li výstup při validních datech správný, je vše OK". Možná to má nějaký smysl v rámci předávacího protokolu ale to je asi tak vše.

Autor článku se také s mírnou obavou ptá na vztah programátorů k testerům. Já bych měl obavy spíše z opačného vztahu. Jako programátor mám spíš dojem, že bych měl testerům za každou odhalenou chybu platit ze své mzdy.

[Filip Jirsák]

Oddělení role testera a programátora má dva jednoduché důvody – za prvé spoustu věcí lze otestovat, aniž bych musel umět programovat; za druhé – je obecně známo, že svoje vlastní chyby člověk snadno přehlédne, proto vznikají různé funkce kontrolorů, korektorů nebo testerů.

O testování knihoven spor není, tester by měl vždy vystupovat v roli uživatele, a uživatelem knihoven je programátor – musí je tedy testovat programátor (ale opět je dobré, pokud některé druhy testů dělá jiný programátor, než který knihovnu psal).

Testování dílčích komponent a operací nebude nikdy úplně dokonalé, a dělat to opravdu důkladně se vyplatí možná u nějakých vesmírných sond, kde je řešený problém poměrně uzavřený a na případný upgrade bývá sonda dost daleko. Ve všech ostatních případech se vyplatí dělat neúplné testy komponent a neúplné testy operací a pak testovat až výsledek. Ono by většinou nebylo ani v lidských silách popsat všechny možné operace, natož je testovat. Navíc pokud množinu přípustných operací omezím, abych jí mohl vůbec popsat, zastavím tím jakýkoli další rozvoj. Takové ty ISO snahy zdokumentovat všechny vstupy a procesy, což má prý zaručit kvalitu výstupu, jsou sice na první pohled hezké, ale jsou naivní a naštěstí nemůžou fungovat.