neděle 6. září 2009

Murphyho zákony. Proč jsou pravdivé?

Program je dobrý, když je bezchybný – což je nemožné.

Jsou lidé, kteří nevěří v existenci bezchybného softwaru a lidé, kteří si myslí, že testování bezchybnost zaručí. (Jsou i jiné skupiny lidí, z nichž nejhorší jsou ti, které kvalita nezajímá. Ale ty teď ponechme stranou.)
Bezchybné programy existují, ale pouze ty triviální. Například pokud jediné, co daný program má umět, je vypsat na obrazovku "Ahoj světe!" a skončit.
Čím je program složitější, tím těžší je i zkontrolovat jeho bezchybnost.
Nakonec i jednoduchý program o pár řádcích může mít tolik různých cest kódem, že bychom je všechny neotestovali ani za deset let.
Proto u jakéhokoli netriviálního programu, tím spíš složitých aplikací a systémů, je nutné počítat s tím, že ať na testování věnujeme sebevíc času, vždy bude obsahovat chyby.

Neviditelných chyb je nekonečné množství, oproti viditelným chybám, kterých je už z definice konečné množství.

Tento zákon je pouhým důsledkem Dijkstrova axiomu, že testování je vhodné k dokázání přítomnosti chyb, ale nevhodné k prokázání jejich nepřítomnosti.

Každý program obsahuje jeden chybný řádek.
Každý program jde zkrátit o jeden řádek.
Z toho plyne, že každý program jde zkrátit na jeden řádek, který je chybný.


K tomu téměř není co dodat. Snad jen, že je to jako sebenaplňující se proroctví. Čím více do kódu člověk zasahuje, tím je větší pravděpodobnost, že do něj zanese chybu.

Fungující program má pouze neobjevené chyby.


Tento zákon by ve skutečnosti měl znít, že software, na který si nikdo nestěžuje, má pouze neobjevené chyby a to proto, že ho nikdo nepoužívá.
Tak to funguje ve skutečnosti. Cílem testování je dosáhnout určitého (nejlépe vysokého) stupně kvality, ne dosáhnout toho, aby zákazník nenahlásil jedinou chybu.

Stačí, když zákazník bude mít z produktu dobrý pocit, protože nebude narážet na chyby často a ty nebudou mít žádné vážné důsledky. A ty chyby, na které narazí, budou rychle vyřešeny

Počet chyb vždy překročí počet řádek v programu.

Toto je spíše zobecněné pozorování. Často je tento zákon pravdivý, protože během životního cyklu vývoje dojde k tolika změnám v programu, že i když konečný program má x řádek, programátoři jich napsali mnohonásobně více.

Šance, že program dělá to, co má, je nepřímo úměrná počtu řádek v programu.


To je snadné pochopit. Čím je program složitější, tím je těžší se v něm vyznat, na něco nezapomenout a neudělat chybu.

Nehledě na to, kolik zdrojů máš, nikdy to není dost.

Netriviální program nemůžeme nikdy kompletně otestovat a nemůžeme zjistit, kolik dosud neobjevených chyb obsahuje. Je tedy možné testovat do nekonečna.
Důležité je dokázat s přidělenými zdroji co největšího efektu. Což je pravé umění nejschopnějších manažerů. Pokud objevení chyby a její oprava stojí více než kdyby jí objevil až zákazník, pak je na čase testování ukončit.

Patch je kus softwaru, který nahrazuje starou chybu novou.

I když je patch relativně malý kus softwaru, je nutné ho otestovat. Spoléhat na to, že vše poběží, jak má, aniž by to někdo opravdu vyzkoušel, je spolehlivým receptem na katastrofu.

Chyby se objeví v jedné části fungujícího softwaru, pokud další zdánlivě nesouvisející část je modifikována.


Jsou dva důvody, proč i když je změna pouze v jedné části programu, se mohou najednou objevit chyby tam, kde předtím žádné nebyly.
První důvod je, že tyto části spolu nějakým způsobem souvisí, ale nikdo si to neuvědomil.
Například jedna část volá funkci, ve které se nachází nadbytečné volání jiné funkce, která byla touto změnou zrušena.
Druhý důvod je, že přestože obě části softwaru spolu nesouvisejí, používají stejné zdroje. Může se tak projevit chyba, která v softwaru byla už nějakou dobu. Například špatně ošetřené sdílení paměti nebo ukazatel, který ukazuje na náhodné data.

Ty nejpřehlédnutelnější chyby způsobí ty největší problémy.

Malé a nenápadné chyby mají buď malé nebo žádné dopady (například logo je pixel posunuté mimo určenou pozici) nebo velmi závažné důsledky (V jednom ze sta případů dojde ke špatnému zaokrouhlení částky, což může mít za následek ztráty několikanásobně větší, než byla cena softwaru). Pokud chyba je nápadná, uživatel si jí hned všimne a pokud její dopady jsou závažné, tak je možné hned situaci napravit, aby se už neopakovala. Pokud ale chyba uniká pozornosti, její důsledky se hromadí, až se lavina protrhne a může dojít k velmi vážným problémům.

Softwarové chyby je nemožné detekovat kýmkoli kromě koncového uživatele.


Přestože testeři při testování odhalí velké množství různých chyb, některé chyby je těžké odhalit pro kohokoli než koncového uživatele. To proto, že i když se tester snaží na software dívat z pohledu uživatele, tak běžným uživatelem není, a chybí mu znalost chování uživatele.
Jediný způsob, jak zjistit reakce uživatelů na software, je vidět je s ním pracovat.

Jakoukoli chybu nehledě na její složitost, lze objevit pouhým pohledem.
Důsledek: Otravující kolemjdoucí s nevítanými radami ji spatří okamžitě.


Pokud už tester vyčerpal všechny nápady a objevil svým trénovaným okem všechny chyby, je potřeba k nalezení dalších chyb změnit přístup nebo i třeba zkusit větší odstup.

Chození po vodě a vývoj softwaru podle specifikace je snadné pouze pokud je obojí zamrzlé.

Každá změna specifikace přináší do vývoje rizika:
• O změně se nedozvědí všichni, kdo o ní potřebují vědět
• Změna bude nejasná a špatně pochopena
• Je třeba zahodit už otestovanou část a napsat novou, která je potenciálně plná chyb
• Složitost toho, co si vývojář musí pamatovat, se zvyšuje a je lehčí udělat chybu
• ...

Nejlepší způsob, jak obejít bezpečnostní prvek, je posadit za počítač třináctiletého.

Ve snaze zabezpečit software před nevítanými vetřelci mají lidé občas tendenci se soustředit na nejčastější a nejznámější způsoby průniku a budování sofistikované obrany proti nim. Přitom mohou přehlédnout nepřímou ale jednoduchou cestu dovnitř. Dalo by se říct, že tento zákon je důsledkem toho, když někdo přes samé stromy nevidí les.

Murphyho zákony byly převzaty z Murphy's computers laws, přeloženy a popřípadě mírně upraveny.

2 komentáře:

  1. Interesting! I read this post using Google translator and it was nice to read your idea of using Murphy's laws and explain a few things related to testing.

    OdpovědětVymazat
  2. You can read it in english too. I took me a day too translate it.

    OdpovědětVymazat

Oblíbené příspěvky