Jak se zbavit plovoucího brouka?

Chcete-li se zbavit plovoucích chyb, používá se tradiční princip „opakovat a analyzovat“, ale s určitými výhradami:

1. Jak zkontrolovat, zda máte plovoucí chybu a ne běžnou? Ve druhém případě chápete, kde se problém vzal, ale v prvním ne. Právě proto je všímavost a schopnost nic neminout jednou z hlavních předností testeru. Legrační na tom je neopravené plovoucí a opraveno běžné chyby jsou velmi podobné – nejsou reprodukovatelné, ale plovoucí chyba se může kdykoli vrátit.
2. Ten vyšší testovatelnost produktu, tím snazší je najít v něm plovoucí chybu.
3. Jakákoli chyba, ke které dojde z neznámých důvodů, se může vrátit. „Odešlo to samo“ nefunguje. Kód má jasnou strukturu, proto je důležité rozvíjet schopnost lokalizovat chyby. Tato dovednost se bude hodit, když se chyba reprodukuje, ale není jasné, jak.
4. Plovoucí chyby mohou snadno reprodukovat v produktivním prostředí a v testu se projevují špatně nebo vůbec. To je důležité zvážit a uvést do souladu s procesem uvolnění systému.
5. Když se objeví plovoucí chyby na vině může být celá řada důvodů, takže při testování použijte tabulky s mnoha možnostmi. Někdy jednoduché hledání kombinací různé podmínky vedou k úspěchu.
6. Nikdy se nepokoušejte skrýt plovoucí štěnici od zákazníků a uživatelů. To by mohlo v budoucnu vést k ještě větším problémům.

Pozoruhodný příklad toho, jak pokus Intelu skrýt chybu vedl ke ztrátám:

Procesory Pentium vydané Intelem v roce 1994 měly problém s nesprávným dělením čísel s pohyblivou řádovou čárkou. Společnost usoudila, že závada by mohla ovlivnit práci velmi úzkého okruhu uživatelů, a rozhodla se ji skrýt. Veřejný pokřik donutil Intel změnit svůj postoj a přinesl ztráty ve výši 475 milionů dolarů.

Jak lokalizovat chybu, pokud počáteční analýza nic nepřinesla?

• Věnujte pozornost mezifunkčním a mezisystémovým blokům. Chyby často žijí na hranicích.
• Studujte protokoly a stopy.
• Vytvořte podobné testovací uživatele se stejnými právy a oprávněními a otestujte na nich fungování programu.
• Vyzkoušejte test na jiných strojích s podobnými a odlišnými vlastnostmi.
• Prozkoumejte od konkrétního k obecnému celé prostředí, ve kterém program funguje, a naopak, zkuste vyjít z chyby. Jaké podmínky mohou být důležité pro její projev?

Proč se vyskytují plovoucí chyby?

Po úspěšné lokalizaci plovoucí chyby nebo jiné složité chyby je důležité analyzovat a zaznamenat důvody jejího výskytu. Takové případy jsou skutečnými perlami profesionálních zkušeností.

Zde je ukázkový seznam důvodů, které vám pomohou, pokud vás inspirace opustila:

1. Přetékat. Pole nebo kontejner může přetéct a způsobit selhání, pokud funkce s ním spojené fungují správně. V době velkých paměťových rezerv to testeři často ztrácejí ze zřetele. Například v rámci systému mohou být vypočteny obrovské celkové hodnoty a nebude schopen strávit takový počet znaků.
2. Problém s kódem, který je také nazýván „Problém s TK“. Plovoucí chyba často souvisí se způsobem napsání kódu. (nyní neuvažujeme o nekvalitní práci, pouze o nepředvídatelnosti). Pisateli technických specifikací pro vývoj je například zřejmé, že při vzorkování dat je nutné vzít určitý unikátní objekt, ale vývojář to nemůže vědět a předepisuje svobodnou volbu. Stává se, že kód je napsán správně, ale některá kombinace podmínek nevede k rozpadu, ale k záměně funkcí. Na tomto místě nebude žádná chyba, ale program jako celek nebude fungovat správně.
3. Problémy se vstupem. Například do volného vstupního pole uživatel zadal data, která algoritmus neposkytuje, nebo chybný znak (čárka místo tečky atd.). Patří sem také chyby spojené s používáním klávesnice místo myši nebo chyby ve vstupu duchů, když stroj zadává data (zejména někde uprostřed výpočtů). V takových případech lze problém zjistit nastavením řídicích „zastávek“ a kontrolou fungování kódu po částech. Další možností je vadný vstup, kdy jsou data z klient-server aplikací poškozena nebo přenášena s chybou.
4. Problémy s hardwarem dochází, když jsou chyby spojeny s fyzikálními faktory. Například kvůli výpadkům proudu, vysokým teplotám v serverové místnosti, fyzickému poškození počítače atd.
5. Nehody. Určitá kombinace podmínek může fungovat správně, ale následně vést k chybě.
6. Deus Ex Machina. Tyto problémy nastávají, když aplikaci používá někdo jiný ve stejnou dobu jako vy: vývojář, hacker nebo jiný tester.
7. Nejasné body. Při analýze odborníci často vyřazují nepotřebné, aby se zaměřili na to důležité, ale ukazuje se, že problém vyplývá z možností, které byly dříve vyřazeny.
8. Neznámý. Není možné brát v úvahu všechno. V systému může být například funkce, o které tester neví, nebo některé zdroje zkreslení. V aplikaci mohou být vytvořeny nezdokumentované proměnné atd. atd.

Několik dalších tipů, jak se vypořádat s plovoucími chybami:

• Vždy zkontrolujte databázi. Charakteristika počítače, který testujete, zdrojová data v dokumentech a ve skutečnosti.
• Vždy si ověřujte informace zvenčí. Nepokládejte otázky v chatu uživateli ani kolegovi, je lepší se jít přesvědčit na vlastní oči.
• Pokud se zdá, že vše již bylo zkontrolováno zevnitř i zvenku a několikrát, požádejte své kolegy, aby se podívali. Bez vás a vašich příběhů, s minimem úvodů.
• Hledejte podobné případy a podívejte se, jak se takové problémy dříve řešily.
• Uložte všechny protokoly. Možná budete muset porovnat nejen původní a nejnovější, ale i ty středně pokročilé.
• Zkontrolujte, co na první pohled není důležité. I když se vám zdá, že se to k otázce vůbec netýká. Často je to přesně to, co hledáte.
• Zkontrolujte konflikty na hranicích různých modulů a systémů, zejména pokud dojde k integraci mezi produkty od různých vývojářů.
• Pokud používáte komponenty třetích stran, kontaktujte technickou podporu vývojáře.
• Pokud nejsou žádné informace, nic nepomáhá a chyba stále nebyla nalezena, ať se problém vyřeší. Vraťte se k tomu zítra a dnes přesuňte svou pozornost na jiné úkoly.
• Nezoufejte. Hledejte nástroje, které vám pomohou problém vyřešit – jednoho dne je určitě najdete.
• Vyvažte přínos opravy chyby a úsilí vynaložené na ni. Někdy stačí vědět, že existuje problém: To není chyba, to je vlastnost.

Neodhalené chyby mohou vést k nebezpečným následkům. V roce 1962 měla k Venuši směřovat kosmická loď Mariner, ale anténa praskla a autopilot letěl špatným směrem. V důsledku toho muselo být zařízení vyhozeno do povětří nad Atlantickým oceánem, a to kvůli chybějícímu symbolu v jedné ze vzorců při programování navigačního systému. Většina chyb není tak fatálních a systémy detekce chyb se staly spolehlivějšími, ale rychlý růst informačních technologií také vede ke zvýšení složitosti systémů. Najít v nich i obyčejné chyby je stále obtížnější a plovoucích chyb přibývá. Jejich odstranění již není vstupní úrovní práce testera, ale řešení takových problémů je o to zajímavější. Hodně štěstí při studiu!