Hogyan törjük el a szoftvert

• 

Általános trend, hogy egyre több termék tartalmaz valamilyen szoftvert, illetve az is, hogy ezek komplexitása is folyamatosan növekszik. Emiatt mindenképpen jól átgondolt stratégiák mentén kell dolgoznunk, hogy minél több hibát találjunk meg, minél rövidebb idő alatt. A komplexitás növekedésével párhuzamosan ugyanis a lehetséges kombinációk száma is növekszik, melyeket megfelelő stratégia hiányában nem lehet megfelelően végig tesztelni. Még 2017-ben a HUSTEF tesztelői konferencián tartottam egy előadást egy heurisztikáról, ami abban segíthet a tesztelőnek, hogy minden aspektusát letesztelje egy szoftvernek. Ebben a cikkben az akkor előadottakat fogom összegezni azt, hogy hogyan lehet az általam “Fault Model”-nek nevezett modell használatával kidolgozni egy olyan teszt stratégiát, ami minden aspektusát figyelemben veszi a szoftvernek.

Pályafutásom elején gyakran tapasztaltam, hogy rutinos tesztelő kollégáim különösebb erőfeszítés nélkül találják meg a kritikus hibákat a termékben. Akkoriban még nem láttam át, hogy ez miként lehetséges. Kicsit megmagyarázhatatlan volt számomra, hogy honnan is jön az a megérzés. 20 évvel később természetesen már sok mindent értek, amit akkoriban nem értettem. Sok olyan tapasztalat, illetve információ áll a rendelkezésünkre, ami segítheti a tesztelő munkáját:

1. a legtriviálisabb nyilván az adott termék ismerete
2. az adott domain ismerete is mérhetetlenül nagy előnyt jelent. Még úgy is, hogy az aktuális terméket nem annyira ismered. Jómagam is majdnem 16 évet töltöttem el a távközlési szektorban így nyilván látatlanban is tudom, hogy hol is törhet el legkönnyebben egy távközlési szoftver.
3. a termékben felhasznált technológiák előzetes ismerete is nagy előnyt jelenthet
4. egy architektúra dizájn ismerete is sokat tud segíteni
5. és végül a felhasználói csoport, illetve szokásaik ismerete is nagy segítségére lehet a tesztelőnek abban, hogy kiválassza azt a számosságában kevés esetet, amit érdemes letesztelni és amivel a legkritikusabb hibákat meg lehet fogni.

Emellett a tapasztalt tesztelők mindenféle heurisztikákat, illetve írott vagy fejben létező modellt is alkalmaznak a munkájuk során. Ebben a cikkben az általam alkalmazott „Fault Model”-t fogom tárgyalni, amit a lenti ábra illusztrál.

Nézzük most át, hogy hogyan épül fel ez a „Fault Model” ami későbbiekben abba fog támogatni minket, hogy minden releváns aspektusból megvizsgáljuk a terméket: 1. a működési környezet (Felhasználó, OS, Hardver, vagy más rendszerek, amikkel a szoftverünk interakcióba lép működése során), 2. a termékünk képességei (funkciók, illetve nem funkcionális karakterisztikák pl. hiba tűrés), 3. a szoftver belső magas szintű architektúrája.

• Működési környezet: ez a környezet sok esetben bonyolult, illetve rendkívül változatos. Vegyük például a mobil alkalmazásokat. A mobil alkalmazásoknak változatos hardveren (különféle képernyőméreteken és különféle szenzorok megléte vagy azok hiánya esetén is), különböző mobil operációs rendszereken vagy az operációs rendszer különböző verzióján is hiba nélkül kell futniuk. Vagy ott vannak a webes alkalmazások, amelyeknek el kell futniuk a különböző böngészők mindenféle verzióján. Emellett nagyon sok alkalmazásnak az adott régió vagy ország nyelvén kell, hogy megjelenítse az üzeneteit a felhasználó felé. Ezek amolyan tipikus példák „támadási pontokra” amit a tesztelő kihasználhat. Elég egyértelmű, hogy minél komplexebb, illetve változatosabb egy működési környezet az annál nagyobb kihívást jelent az architekteknek illetve a fejlesztőknek. Ha pedig valamit nagy kihívás lekódolni, akkor ott egészen biztosan lesznek hibák. Ebből adódóan a tesztelőknek érdemes ezekre a nehezen implementálható bonyolult részekre is fókuszálniuk. Bár sokan teljesen megfeledkeznek róla, de az általunk fejlesztett szoftver működése során mindenféle erőforrást is használ: memória (ami elfogyhat), fájl tárhely (ami betelhet), fájlokhoz próbálhat meg hozzáférni, amelyek megsérülhetnek, CPU erőforrásért versenghet más folyamatokkal vagy alkalmazásokkal, vagy távoli rendszerekkel próbálhat meg kommunikálni melyek elérhetetlenné válhatnak, …. Ezek nyilvánvalóan olyan területek, amelyeket a tesztelés során érdemes megvizsgálni annak függvényében, hogy potenciálisan fennállhatnak-e ezek az esetek. Emellett olyan finomságokat is érdemes észben tartani mint, hogy a felhasználók sose direktben kommunikálnak a szoftverünkkel, hanem valamilyen periférián keresztül (egér, billentyűzet, képernyő stb.…) vagyis a szó leg szorosabb értelmében magán az operációs rendszeren, illetve illesztő programokon keresztül. Ha mindez nem lenne elegendő akkor a termékünk sokszor más rendszerekkel is kommunikál működése során, ami további hibalehetőséget hordoz magában: a távoli rendszer elérhetetlenné válik (például DBS) vagy egyszerűen nem tudja lekezelni a párhuzamos kéréseket.

• Képességek: ez az az aspektus, ami talán a legtriviálisabb a tesztelők számára és ezeket használják leggyakrabban a tesztelési stratégia kialakítása során. A „támadási pontokat” a következő aspektusok mentén tudjuk definiálni: a szoftver nyilván érvényes és érvénytelen bemeneti adatokat kap, illetve fogad, ezek alapján valamilyen kimenetet állít elő, mindezt mindenféle számítások során (ezek a számítások az algoritmus szintjén elég komplexek is lehetnek, ami jó támadási pont egy tesztelő számára), a szoftver adatokat tárol el majd később felhasználja azokat (szerencsésebb esetben érintetlenül). Ezen felül az egyes funkciók egymásra is hathatnak: vagy azért, mert működésük állapot függő vagy mert azonos adathalmazon dolgoznak. Bár lényegében az állapot is tekinthető adatnak. Ezeken felül természetesen ott vannak az ISO 25010 által is lefedett szoftver minőség attribútumok, amelyekre minden estben gondolni kell:

1. Funkcionális Megfelelés (Functional Suitability)
2. Teljesítmény Hatékonyság (Performance Efficiency)
3. Kompatibilitás (Compatibility)
4. Használhatóság (Usability)
5. Megbízhatóság (Reliability)
6. Biztonság (Security)
7. Karbantarthatóság (Maintainability)
8. Portolhatóság (Portability)

• Szoftver architektúra ismerete szintén adhat pár támpontot a tesztelőnek arra vonatkozóan, hogy mit érdemes letesztelni. Vegyük például a távközlési szoftvereket. Ezeknek a rendszereknek a nap 24 órájában üzemelniük kell így le kell tudniuk kezelni mindenféle szoftveres vagy akár hardver hibát is. De ezen felül teljesen alap, hogy üzemidőben lehessen rajtuk szoftvert frissíteni vagy akár egy hardver komponenst is ki lehessen rajtuk cserélni. De emellett számos olyan aspektusa lehet a magas szintű dizájnnak, ami jó kiindulási alapot jelenthet tesztek írásához. Épp ezért ezt az aspektust is mindig figyelembe kell venni. Persze felmerülhet a kérdés, hogy nekünk tesztelőknek minden ilyen információnak a birtokában kell-e lennünk. Erre az igen egyszerű válaszom, hogy nem, de jó, ha idővel minél több ilyen információt mi magunk ismerünk. Ennek ellenére az ideális az lenne, hogy ha a project minden tagja részt venne a szoftver tesztelésében. Még ha csak azzal is, hogy ötletet ad, hogy mit kellene tesztelni vagy információt ad melyből teszt eseteket lehet kinyerni.

Vegyük akkor most a saját szoftverünket, vegyük végig a fent felsorolt aspektusokat és azonosítsunk be támadási pontokat. Aztán meg hajrá! Had törjön az a szoftver! J

Jelen cikkre épülő előadás itt tekinthető meg:
https://www.youtube.com/watch?v=N3GzpVKQw-M&t=0s