Phenquestions
Egység tesztelése
Az egységtesztelés egy egyedi funkción, osztályon vagy modulon végzett tesztelés, függetlenül a teljesen működő szoftver tesztelésétől. Az egység teszteléséhez keretrendszert használva a programozó létrehozhat teszteseteket bemenettel és várható kimenettel. Ha több száz, ezer vagy tízezer egység teszt esete van egy nagy szoftverprojekt számára, akkor az biztosítja, hogy az egyes egységek a várt módon működnek, miközben tovább változtatja a kódot. Teszteseteket tartalmazó egység cseréjénél meg kell vizsgálni az adott modul teszteseteit, és meg kell határoznia, hogy szükség van-e új tesztesetekre, megváltozott-e a kimenet, vagy eltávolíthatók-e az aktuális tesztesetek, mivel ezek már nem relevánsak. Nagy mennyiségű egységteszt létrehozása a legegyszerűbb módszer a szoftveres kódbázis magas teszteset-lefedettségének elérésére, de nem biztosítja, hogy a végtermék rendszerként működjön a várt módon.
Funkcionális tesztelés
A funkcionális tesztelés a tesztelés leggyakoribb formája. Amikor az emberek különösebb részletek nélkül hivatkoznak a szoftver tesztelésére, akkor gyakran funkcionális tesztet jelentenek. A funkcionális tesztelés a várakozásoknak megfelelően ellenőrzi a szoftver működésének elsődleges funkcióit. Teszttervet lehet írni a tesztelni kívánt funkcionális tesztesetek leírására, amely megfelel a szoftver főbb jellemzőinek és lehetőségeinek. Az elsődleges funkcionalitás teszteléseboldog út ” tesztelés, amely nem próbálja meg feltörni a szoftvert vagy használni bármilyen kihívást jelentő forgatókönyvben. Ennek minden szoftverprojekt tesztelésének abszolút minimumának kell lennie.
Integrációs tesztelés
Az egység tesztelése és a funkcionális tesztelés után több modul vagy az egész rendszer lehet, amelyet még nem teszteltek egészében. Vagy lehetnek olyan alkatrészek, amelyek nagyrészt függetlenek, de alkalmanként együtt használják őket. Bármikor, amikor az alkatrészeket vagy modulokat függetlenül tesztelik, de nem az egész rendszert, akkor integrációs tesztet kell végezni annak érdekében, hogy az alkatrészek működési rendszerként működjenek együtt a felhasználói igények és elvárások szerint.
Stressz tesztelés
Gondoljon a stressztesztre, mint például egy űrsiklóra vagy repülőgépre. Mit jelent a szoftver vagy a rendszer „STRESS” alá helyezése? A stressz nem más, mint egy adott típusú intenzív terhelés, amely nagy valószínűséggel megtöri a rendszerét. Ez hasonló lehet a „Terhelés teszteléséhez” abban az értelemben, hogy a rendszer nagy egyidejűségbe kerül, sok felhasználó hozzáfér a rendszerhez. De a rendszer hangsúlyozása más vektorokon is előfordulhat. Például a firmware futtatása hardverkomponensen, ha a hardver fizikai állapotának romlása és leromlott üzemmódban működik. A stressz minden szoftvertípusra jellemző, és a rendszereket, valamint a stressztesztek tervezését annak figyelembevételével kell megvizsgálni, hogy mely természetes vagy természetellenes okok okozhatják a legnagyobb valószínűséggel a szoftvert vagy a rendszert.
Terhelés tesztelése
A terheléses teszt a stressztesztelés egy speciális típusa, amint azt fentebb tárgyaltuk, amelynek során nagyszámú egyidejű felhasználói kapcsolat és hozzáférés automatizálódik, hogy szimulációt generálhasson a szoftveres rendszerhez egyszerre hozzáférő nagyszámú hiteles felhasználó hatásáról. A cél annak kiderítése, hogy hány felhasználó férhet hozzá a rendszeréhez egyszerre anélkül, hogy a szoftver rendszere megszakadna. Ha a rendszere könnyedén képes kezelni a 10 000 felhasználó normál forgalmát, mi lesz, ha webhelye vagy szoftvere vírusos lesz és 1 millió felhasználót szerez? Váratlan lesz "BETÖLTÉS" törje meg webhelyét vagy rendszerét? A terheléses teszt ezt szimulálja, így Ön jól érzi a felhasználók jövőbeni növekedését, mert tudja, hogy rendszere képes kezelni a megnövekedett terhelést.
Teljesítményfelmérés
Az emberek teljesen csalódottak és kétségbe eshetnek, ha a szoftver nem felel meg teljesítménykövetelményeiknek. A teljesítmény általában azt jelenti, hogy a fontos funkciók milyen gyorsan teljesíthetők. Minél összetettebb és dinamikusabb funkciók állnak rendelkezésre egy rendszerben, annál fontosabb és nem nyilvánvalóbb lesz a teljesítményének tesztelése, vegyünk egy alap példát, Windows vagy Linux operációs rendszer. Az operációs rendszer nagyon összetett szoftvertermék, és a rendszeren végzett teljesítménytesztelés magában foglalhatja olyan funkciók sebességét és időzítését, mint például a Bootup, egy alkalmazás telepítése, fájl keresése, számítások futtatása GPU-n és / vagy bármely más az elvégezhető akciók milliói. A teljesítményteszt esetek kiválasztásakor ügyelni kell a tesztelt fontos és valószínűleg hibás működési jellemzők biztosítására.
Méretezhetőség tesztelése
A laptopon történő tesztelés jó, de nem elég jó, ha közösségi hálózatot, e-mail rendszert vagy szuperszámítógépes szoftvert épít. Ha a szoftvert 1000 szerveren kívánják telepíteni, amelyek mind egyöntetűen működnek, akkor a helyben, egy rendszeren végzett tesztelés nem fedezi fel azokat a hibákat, amelyek akkor fordulnak elő, amikor a szoftvert több százezer példányban telepítik „méretben”. Valójában a tesztelés valószínűleg soha nem fog teljes mértékben lefutni, mielőtt kiadná a termelést, mert túl drága lenne és nem praktikus egy tesztrendszert felépíteni 1000 szerverrel, dollármilliókba kerülve. Ezért a skálázhatóság tesztelése több szerveren történik, de általában nem a termelő szerverek teljes számával, hogy megpróbálja feltárni azokat a hibákat, amelyek előfordulhatnak, mivel a rendszereket nagyobb infrastruktúrán használják.
Statikus elemzés tesztelése
A statikus elemzés olyan tesztelés, amelyet a szoftverkód ellenőrzésével végeznek anélkül, hogy azt ténylegesen futtatnák. A statikus elemzéshez általában egy eszközt használna, sok van, egy híres eszköz a Coverity. A statikus elemzés könnyen futtatható a szoftver kiadása előtt, és számos minőségi problémát találhat a kódban, amelyet a kiadás előtt lehet orvosolni. Memóriahibák, adattípus-kezelési hibák, nullpont-eltérések, inicializálatlan változók és még sok más hiba található. Az olyan nyelvek, mint a C és a C ++, nagy hasznot húznak a statikus elemzésből, mert a nyelvek nagy szabadságot biztosítanak a programozóknak a nagy teljesítményért cserébe, de ez nagy hibákat és hibákat is előidézhet, amelyek statikus analízis teszteléssel megtalálhatók.
Hiba befecskendezés tesztelése
Bizonyos hibakörülményeket nagyon nehéz szimulálni vagy kiváltani, ezért a szoftver úgy tervezhető, hogy mesterségesen adjon problémát vagy hibát a rendszerbe anélkül, hogy a hiba természetesen előfordulna. A hibabefecskendezés célja annak megismerése, hogy a szoftver hogyan kezeli ezeket a váratlan hibákat. Kecsesen reagál-e a helyzetre, összeomlik-e, vagy váratlan és kiszámíthatatlan problémás eredményeket produkál-e?? Tegyük fel például, hogy van bankrendszerünk, és van egy modul, amely belsőleg utalja át az A SZÁMLÁT a B SZÁMLÁRA. Ezt az átviteli műveletet azonban csak akkor hívják meg, ha a rendszer az átviteli művelet meghívása előtt már ellenőrizte, hogy ezek a fiókok léteznek-e. Annak ellenére, hogy feltételezzük, hogy mindkét fiók létezik, az átviteli műveletnek meghibásodási esete van, amikor egy cél- vagy forrásfiók nem létezik, és hibát okozhat. Mivel normál körülmények között soha nem kapjuk meg ezt a hibát a bemenetek előzetes tesztelése miatt, ezért a rendszer viselkedésének igazolásához, amikor az átvitel nem létező fiók miatt sikertelen, hamis hibát injektálunk a rendszerbe, amely nem létező fiókot ad vissza átvitelhez és tesztelje, hogy a rendszer többi része hogyan reagál ebben az esetben. Nagyon fontos, hogy a hibainjekció kód csak tesztelési szcenáriókban áll rendelkezésre, és ne adják ki a gyártásba, ahol pusztítást okozhat.
Memória túllépés tesztelése
Olyan nyelvek használatakor, mint a C vagy a C ++, a programozónak nagy felelőssége a memória közvetlen kezelése, és ez hibákat okozhat a szoftverben, ha hibákat követnek el. Például, ha egy mutató nulla és hivatkozás nélküli, a szoftver összeomlik. Ha egy objektumhoz memóriát osztanak ki, majd egy karaktersorozatot másolnak az objektum memóriaterületére, akkor az objektumra való hivatkozás összeomlást vagy akár meghatározatlan hibás viselkedést okozhat. Ezért kritikus fontosságú egy olyan eszköz használata, amely megpróbálja elkapni a memóriaelérési hibákat olyan szoftverekben, amelyek olyan nyelveket használnak, mint a C vagy a C ++, amelyeknek ezek a lehetséges problémák lehetnek. Az ilyen típusú tesztelésre képes eszközök közé tartozik a nyílt forráskódú Valgrind vagy a saját fejlesztésű eszközök, például a PurifyPlus. Ezek az eszközök megmenthetik azt a napot, amikor nem világos, hogy a szoftver miért összeomlik vagy nem megfelelően viselkedik, és közvetlenül rámutatnak a hibát tartalmazó kód helyére. Félelmetes, igaz?
Határeset-tesztelés
Könnyen hibázhatunk a kódolásban, ha az úgynevezett határon vagyunk. Például egy banki pénztárgép azt mondja, hogy legfeljebb 300 dollárt vehet fel. Tehát képzeljük el, hogy a kódoló a következő kódot természetesen megírta a követelmény megalkotásakor:
Ha (amt < 300)startWithdrawl ()
más
hiba („% s visszavonható”, amt);
Meg tudja észlelni a hibát? Az a felhasználó, aki megpróbálja kifizetni a 300 dollárt, hibát fog kapni, mert az nem kevesebb, mint 300 dollár. Ez egy hiba. Ezért a határvizsgálat természetesen történik. A követelményhatárok biztosítják, hogy a szoftver a határ és a határ mindkét oldalán megfelelően működjön.
Fuzz tesztelés
A szoftverrel történő nagy sebességű bemenet előállítása annyi lehetséges bemeneti kombinációt eredményezhet, még akkor is, ha ezek a bemeneti kombinációk teljesen hülyeségek, és soha nem valós felhasználó nyújtaná. Ez a fajta fuzz teszt olyan hibákat és biztonsági réseket találhat, amelyek más módon nem találhatók meg, mivel a bemenetek és a forgatókönyvek nagy mennyisége gyorsan tesztelhető, kézi tesztesetek generálása nélkül.
Feltáró tesztelés
Csukd be a szemed, és vizualizáld, mit jelent az „Explore” szó. Megfigyel egy rendszert, és megismeri annak működését. Képzelje el, hogy új asztali széket kap postai úton, és 28 része külön műanyag zacskóban van, utasítások nélkül. Meg kell vizsgálnia új érkezését, hogy rájöjjön, hogyan működik és hogyan áll össze. Ezzel a szellemmel felfedező tesztelővé válhat. Nem lesz jól meghatározható teszt terve a tesztesetekről. Felfedezi és megvizsgálja a szoftverét, és olyan dolgokat keres, amelyek arra késztetik, hogy kimondja a csodálatos szót: „Érdekes!”. A tanulás után tovább vizsgálja, és megtalálja a szoftverek megszakításának módját, amelyre a tervezők soha nem gondoltak, majd jelentést készít, amely részletezi a szoftver számos rossz feltételezését, hibáját és kockázatát. Tudjon meg erről többet az Explore című könyvben.
Penetrációs vizsgálat
A szoftverbiztonság világában a penetrációs tesztelés az egyik elsődleges eszköz a teszteléshez. Minden rendszernek, legyen az biológiai, fizikai vagy szoftveres, vannak határai és határai. Ezeknek a határoknak az a célja, hogy csak meghatározott üzenetek, emberek vagy alkatrészek léphessenek be a rendszerbe. Konkrétabban vegyünk figyelembe egy olyan online banki rendszert, amely felhasználói hitelesítést használ a webhelyre történő belépéshez. Ha a webhelyet megfelelő hitelesítés nélkül lehet feltörni és belépni a háttérbe, az behatolásnak minősül, amelyet védeni kell. A behatolási teszt célja ismert és kísérleti technikák alkalmazásával egy szoftverrendszer vagy egy webhely normál biztonsági határának megkerülése. A behatolási teszt gyakran magában foglalja az összes portot, amely figyeli, és megpróbál egy nyílt porton keresztül belépni a rendszerbe. Egyéb elterjedt technikák: SQL-injekció vagy jelszó feltörése.
Regressziós teszt
Miután működő szoftver van telepítve a helyszínen, elengedhetetlen a hibák bevezetése a már működő funkciókba. A szoftverfejlesztés célja, hogy növelje a termék képességeit, hibákat mutasson be, vagy a régi funkciók működésének leállítását okozza, ezt REGRESSION-nak nevezik. A regresszió olyan hiba vagy hiba, amelyet akkor vezettek be, amikor a képesség a várakozásoknak megfelelően működött. Semmi sem ronthatja gyorsabban szoftverének vagy márkájának hírnevét, mint hogy regressziós hibákat vigyen be a szoftverébe, és hogy valódi felhasználók megtalálják ezeket a hibákat egy kiadás után.
A regressziós teszteket és a tesztterveket az alapvető funkciók köré kell építeni, amelyeknek tovább kell működniük annak biztosítása érdekében, hogy a felhasználók jó tapasztalatokat szerezzenek az alkalmazással kapcsolatban. A szoftver minden olyan alapvető funkciójának, amelytől a felhasználók bizonyos módon működnek, rendelkeznie kell egy regressziós tesztesettel, amelyet végre lehet hajtani, hogy megakadályozzák a funkcionalitás feltörését egy új kiadásnál. Ez 50-50 000 teszteset lehet, amelyek lefedik a szoftver vagy alkalmazás alapvető funkcióit.
Forráskód felezési tesztelése
A szoftverben hibát vezettek be, de nem nyilvánvaló, hogy a kiadás melyik verziója vezette be az új hibát. Képzelje el, hogy 50 szoftveres elkötelezettség volt a legutóbbi ismert időtől, amikor a szoftver hiba nélkül működött, egészen mostanáig
Lokalizációs tesztelés
Képzeljen el egy időjárási alkalmazást, amely megmutatja a jelenlegi és a tervezett időjárást az Ön tartózkodási helyén, valamint leírja az időjárási viszonyokat. A lokalizációs tesztelés első része annak biztosítása, hogy a helyes nyelv, ábécé és karakterek megfelelően jelenjenek meg, a felhasználó földrajzi helyétől függően. Az Egyesült Királyságban található alkalmazást angolul, latin betűkkel kell megjeleníteni; ugyanazt az alkalmazást Kínában kínai karakterekkel, kínai nyelven kell megjeleníteni. Bonyolultabb lokalizációs teszt elvégzése, a különböző földrajzi helyekről érkező emberek szélesebb köre kapcsolódik az alkalmazáshoz.
Kisegítő lehetőségek tesztelése
A közösségünk néhány polgárának fogyatékossága van, ezért problémái lehetnek a létrehozandó szoftver használatával, ezért akadálymentességi teszteket végeznek annak biztosítására, hogy a fogyatékossággal élő lakosság továbbra is hozzáférhessen a rendszer funkcióihoz. Például, ha feltételezzük, hogy a lakosság 1% -a színvak, és szoftveres felületünk feltételezi, hogy a felhasználók meg tudják különböztetni a pirosat és a zöldet, de ezek a színvakok NEM tudják megmondani a különbséget. Ezért egy jól szoftveres interfésznek a színen túl további jelzései lesznek, amelyek jelzik a jelentést. A színvakság-teszten kívül más forgatókönyvek is bekerülnek a szoftver-akadálymentességi tesztekbe, például a teljes látásvakság, a süketség és sok más forgatókönyv. Egy jó szoftverterméknek a potenciális felhasználók maximális százaléka számára hozzáférhetőnek kell lennie.
Frissítési tesztelés
A telefonon található egyszerű alkalmazások, az operációs rendszerek, mint az Ubuntu, a Windows vagy a Linux Mint, valamint a nukleáris tengeralattjárókat működtető szoftverek gyakori frissítést igényelnek. Maga a frissítés folyamata olyan hibákat és hibákat mutathat be, amelyek nem lennének elérhetőek egy új telepítésnél, mivel a környezet állapota más volt, és az új szoftver bevezetésének folyamata a régi tetején hibákat mutathatott. Vegyünk egy egyszerű példát: van egy laptopunk, amely Ubuntu 18-at futtat.04, és frissíteni szeretnénk az Ubuntu 20-ra.04. Ez az operációs rendszer telepítésének más folyamata, mint a merevlemez közvetlen tisztítása és az Ubuntu 20 telepítése.04. Ezért előfordulhat, hogy a szoftver vagy annak bármely származtatott funkciójának telepítése után nem működik 100% -osan a várakozásoknak megfelelően, vagy nem ugyanaz, mint amikor a szoftvert frissen telepítették. Tehát először meg kell fontolnunk magának a frissítésnek a tesztelését sokféle esetben és forgatókönyv szerint annak biztosítása érdekében, hogy a frissítés befejeződjön. Ezután meg kell fontolnunk a rendszer frissítés utáni tesztelését is annak biztosítása érdekében, hogy a szoftvert a várakozásoknak megfelelően fektessük le és működjünk. Nem ismételnénk meg egy frissen telepített rendszer összes tesztesetét, ami időpazarlás lenne, de alaposan átgondoljuk a rendszer ismeretében, hogy mi is szakadhat meg egy frissítés során, és stratégiailag hozzáadjuk a teszteseteket ezekhez a funkciókhoz.
Fekete doboz és fehér doboz tesztelés
A fekete és a fehér doboz kevésbé specifikus vizsgálati módszertan, és inkább a kategorizálás típusai. Lényegében a fekete doboz tesztelése, amely feltételezi, hogy a tesztelő semmit sem tud a szoftver belső működéséről, és elkészít egy teszttervet és olyan teszteseteket, amelyek csak kívülről nézik a rendszert annak működésének ellenőrzésére. A fehér doboz tesztelését olyan szoftverépítészek végzik, akik megértik a szoftverrendszer belső működését és az eseteket úgy tudják megtervezni, hogy tudják, mi lenne, mit kellene és valószínűleg megtörnének. A fekete és a fehér doboz tesztelése valószínűleg különböző típusú hibákat talál.
Blogok és cikkek a szoftver teszteléséről
A szoftvertesztelés dinamikus terület, és számos érdekes publikáció és cikk frissíti a közösséget a szoftverteszteléssel kapcsolatos korszerű gondolkodásmódról. Mindannyian profitálhatunk ebből a tudásból. Íme egy példa érdekes cikkekre különböző blogforrásokból, amelyeket érdemes követni:
- 7 tipp, amelyet követni kell a követelmények nélküli tesztelés előtt; http: // www.folyóiratok tesztelése.com /
- 60 legjobb automatizálási tesztelő eszköz: A végső lista útmutató; https: // testguild.com /
- Nyílt forráskódú adatbázis-tesztelő eszközök; https: // www.softwaretestingmagazine.com /
- A 100 százalékos vizsgálati lefedettség nem elég; https: // www.pálcikaemberek.com /
- Pelyhes tesztek a Google-nál és hogyan mérsékeljük őket; https: // tesztelés.googleblog.com /
- Mi a regressziós tesztelés? ; https: // teszt.io / blog /
- 27 legjobb Chrome-bővítmény a fejlesztők számára 2020-ban; https: // www.lambdatest.com /
- 5 fő szoftver tesztelési lépés, amelyet minden mérnöknek el kell végeznie; https: // techbeacon.com /
Termékek szoftver teszteléshez
Az értékes tesztelési feladatok többsége automatizálható, így nem meglepő, hogy jó ötlet eszközök és termékek felhasználása a szoftver minőségbiztosítás számtalan feladatának elvégzéséhez. Az alábbiakban felsorolunk néhány fontos és nagyon értékes szoftvereszközt a szoftver teszteléséhez, amelyeket felfedezhet, és megnézheti, segíthetnek-e.
JUnit
A Java-alapú szoftverek teszteléséhez a JUnit átfogó tesztcsomagot biztosít a Java-környezetbarát kód egységes és funkcionális teszteléséhez.
Szelén
A webalkalmazások teszteléséhez a Selenium lehetővé teszi a webböngészőkkel való interakciók automatizálását, beleértve a böngészők közötti kompatibilitási tesztet is. Ez egy elsődleges tesztelési infrastruktúra a webes tesztelés automatizálásához.
Uborka
A viselkedésvezérelt tesztelési keretrendszer lehetővé teszi az üzleti felhasználók, a termékmenedzserek és a fejlesztők számára, hogy természetes nyelven magyarázzák el az elvárt funkcionalitást, majd ezt a viselkedést definiálják teszt esetekben. Ez olvashatóbb teszteseteket és egyértelmű hozzárendelést jelent a várható felhasználói funkcionalitáshoz.
Megtisztítani
Keresse meg a memóriaszivárgásokat és a memória sérüléseit futás közben a szoftver végrehajtásával a beágyazott Purify Plus műszerrel, amely nyomon követi a memóriahasználatot és rámutat a kód hibáira, amelyeket műszerezés nélkül nem könnyű megtalálni.
Valgrind
Nyílt forráskódú eszközök, amelyek végrehajtják a szoftvert, és lehetővé teszik a használatát, miközben hibajelentést mutatnak be a kódolási hibákról, például memóriaszivárgásokról és korrupciókról. Nincs szükség újrafordításra vagy műszer hozzáadására az összeállítási folyamatba, mivel a Valgrind rendelkezik intelligenciával a gépi kód dinamikus megértéséhez és a műszer zökkenőmentes injektálásához a kódolási hibák megtalálásához és a kód javításához.
Fedezettség
Statikus elemző eszköz, amely még a kód fordítása és futtatása előtt megtalálja a kódolási hibákat a szoftverben. A fedezettség megtalálhatja a biztonsági réseket, a kódolási egyezmények megsértését, valamint olyan hibákat és hibákat, amelyeket a fordító nem talál. Megtalálható a holt kód, az inicializálatlan változók és több ezer egyéb hibatípus. Létfontosságú, hogy statikus elemzéssel tisztítsa meg a kódot, mielőtt kiadná a termelésbe.
JMeter
Nyílt forráskódú keretrendszer a teljesítmény teszteléséhez, amely Java-alapú fejlesztőkre irányul, ezért a nevében a J. A weboldal-tesztelés az egyik fő felhasználási eset a JMeter számára az adatbázisok, a levelezőrendszerek és sok más kiszolgálóalapú alkalmazás teljesítménytesztje mellett.
Metasploit
A biztonság és a behatolás teszteléséhez a Metasploit egy általános keretrendszer, amely ezer funkcióval és képességgel rendelkezik. Az interakciós konzol segítségével érje el az előre kódolt kihasználásokat, és próbálja meg ellenőrizni az alkalmazás biztonságát.
Akadémiai kutatás a szoftver teszteléséről
- Sheffieldi Egyetem Vizsgálati Kutatócsoport
- Kentucky Egyetem Szoftverellenőrző és -ellenőrző laboratórium
- Észak-Dakotai Állami Egyetem Szoftvertesztelés Kutatócsoport
- Rendszertesztelés Intelligent Lab; Cseh Műszaki Egyetem Prága
- NASA: Jon McBride szoftver tesztelés és kutatás (JSTAR)
- McMaster Egyetem; Szoftverminőség-kutató laboratórium
- Ontario Műszaki Egyetem; Szoftverminőség-kutató labor
- Texasi Egyetem @ Dallas; STQA
Következtetés
A szoftverek szerepe a társadalomban folyamatosan növekszik, és ezzel együtt a világ szoftvere is összetettebbé válik. Ahhoz, hogy a világ működjön, rendelkeznünk kell módszerekkel és stratégiákkal az általunk létrehozott szoftver tesztelésére és validálására az általa végrehajtani kívánt funkciók végrehajtásával. Minden összetett szoftverrendszerhez ki kell dolgozni egy tesztelési stratégiát és tesztelési tervet, hogy továbbra is érvényesíthessék a szoftver funkcionalitását, miközben azok tovább javulnak és biztosítják a funkcióját.
