Először is, tudnunk kell, hogy mi az alapvonal, mielőtt megértenénk, mi az alapvonal tesztelés.

Technikailag –

Az alapvonal egy hivatalos dokumentum, amely a jövőbeli munka alapdokumentumaként szolgál. Laikus nyelven szólva, egy épület felépítéséhez szükség van egy alapra. Ugyanez vonatkozik a tesztelésre is. Szükségünk van egy alapvonalra, amelyből kiindulva történik a további tesztelés. Először is nagyon fontos tudni, hogy ez nem funkcionális tesztelés, ami azt jelenti, hogy semmi köze az alkalmazás funkcionalitásának teszteléséhez. Inkább a dokumentum tesztelése történik, amely megalapozza a jövőben elvégzendő munkát. Tehát elmondható, hogy a jövőbeli fejlesztés alapjául szolgál, bármi legyen is az. Ez lehet a teljesítmény, a tesztesetek fejlesztése.

A teljesítménytesztelésről beszélve –

Ha azt látjuk, hogy egy adott szerver alkalmazásának teljesítménye 100 felhasználó terhelésével, ha 100 felhasználó terhelésével jól működik a szerveren megszakítás, lassúság vagy meghibásodás nélkül, és utána a szerver teljesítménye drasztikusan csökken, miután 100-nál több felhasználó terhelését alkalmazzák az alkalmazást tartalmazó szerverre. Akkor azt mondhatjuk, hogy ennek a szervernek a szabványa 100 felhasználó. Most ezt a szabványt össze lehet hasonlítani a szabványos szerverrel, és meg lehet határozni a teljesítménytesztelés jövőbeli hatókörét.

Magyarázzuk ezt egy másik példával: tegyük fel, hogy az 1. kiadás válaszideje 2 másodperc, a 2. kiadásé pedig 3 másodperc. Most a 3. kiadás esetében a 2. kiadás 2 másodperces válaszideje szolgál a 3. kiadás teljesítményének alapjául vagy bázisaként. Ebből tehát arra következtethetünk, hogy a Baseline egy olyan dokumentum, amelyre összehasonlítási alapként vagy referenciaként hivatkoznak a jövőbeli munkákhoz. Kell lennie valamilyen dokumentumnak, amelyre stabil, véglegesített dokumentumként lehet hivatkozni a jövőbeli munkához.

A szoftverfejlesztés fogalmairól beszélve –

Ha a szoftverfejlesztés fogalmairól beszélünk, van egy dokumentum, amelyet tervdokumentumnak hívnak. Ez lehet Low-Level Document vagy High-Level Document, amely alapján a fejlesztési munkák megkezdődnek. Ha beszélünk a tesztelés kifejezés, egy dokumentum által készített üzleti elemző, aki kapcsolatban áll az ügyféllel, és felelős a követelményeket az ügyféltől való lehívásáért, hivatkozási pontként szolgál a tesztelők számára a fejlesztési és tesztelési folyamat megkezdéséhez. Az üzleti elemző a találkozót követően elmegy az ügyfélhez, és átveszi a követelményt, majd kitölti azt egy meghatározott sablonban. Ezután megbeszéli a követelményt a megbízási menedzserrel vagy a projektmenedzsment-menedzserrel, hogy tesztelje a követelményt és ellenőrizze annak megvalósíthatóságát. Abban az esetben, ha nem egyértelmű a követelmény, megkérik a fejlesztőt, hogy készítsen prototípust, és ha elégedett, átadja a követelménydokumentumot a projektmenedzsernek, aki elkészíti a szoftverkövetelmények specifikációját. Az üzleti elemző által készített dokumentumot a szervezet által használt terminológiától függően üzleti követelménydokumentumnak vagy funkcionális követelményspecifikációnak vagy felhasználói követelményspecifikációnak vagy üzleti tervdokumentumnak vagy üzleti dokumentumnak nevezik. Tehát itt láthatjuk, hogy a követelménytesztelés a követelménydokumentum véglegesítése érdekében történik, amely a tervezési dokumentum vagy a projektterv és a tesztterv alapjául szolgál, és a szoftverfejlesztés és -tesztelés alapját képezi. Ezt a fajta tesztelést nevezzük alapszintű tesztelésnek. Az ilyen típusú tesztelés során ellenőrizzük, hogy az elkészített dokumentum megfelel-e a célnak és megfelelően megfelel-e az elvárásoknak, vagy más szóval validáljuk és véglegesítjük a dokumentumot.

Az alapszintű tesztelés elvégzése és a Szoftverkövetelmény-specifikációs dokumentum véglegesítése után készen állunk a továbblépésre és a fejlesztési és tesztelési folyamat megkezdésére. A teszteléshez megkezdhetjük a tesztesetek elkészítését a követelménydokumentumok alapján. Az alapszintű tesztelés fő előnye, hogy már a szoftverfejlesztési életciklus korai szakaszában kiküszöbölhetjük a követelményekben lévő hibákat, és a későbbi szakaszban rengeteg problémát és erőfeszítést tudunk kiküszöbölni, és segít nekünk abban, hogy a projektet minimális átdolgozással és kevesebb erőfeszítéssel adjuk át.

A szoftverfejlesztési életciklus fázisáról beszélve –

Mivel tudjuk, hogy a szoftverfejlesztési életciklus korai szakaszában végzett több munka a későbbi szakaszban túl sok erőfeszítést csökkent. Ahhoz, hogy megértsük, mennyire fontos az alapszintű tesztelés, kicsit meg kell értenünk a szoftverfejlesztési életciklust. Az első fázis a követelményfázis, amelyben az üzleti elemző információkat gyűjt az ügyféltől, és követelménydokumentumokat készít, amelyeket a szervezet által használt terminológiától függően üzleti követelménydokumentumnak, funkcionális követelményspecifikációnak, felhasználói követelményspecifikációnak, üzleti tervdokumentumnak vagy üzleti dokumentumnak neveznek. A követelménydokumentum alapján a követelménydokumentum tesztelése történik, amit alapszintű tesztelésnek nevezünk, és a követelményt véglegesítjük, vagy úgy is mondhatjuk, hogy a követelményt befagyasztjuk. Amint ez a jelnek megfelel, és akár úgy is tekinthető, hogy a szoftverkövetelmény-specifikációt az elemzési fázisban készítsük el. Ebben a dokumentumban a projektmenedzser vagy a műszaki vezető vagy a rendszerelemző projekttervet készít arról, hogy a projektet hogyan fogják fejleszteni. Az SRS dokumentum alapján készül a tervezési dokumentum, például a magas szintű tervezési dokumentum és az alacsony szintű tervezési dokumentum, amely alapján a szoftverfejlesztési életciklus egy másik fázisa, például a kódolás, a tesztelés és a szállítás történik.

Tegyük fel, hogy az alapszintű tesztelés nem megfelelően történik, és az üzleti követelménydokumentumot nem megfelelően véglegesítik, akkor az üzleti követelménydokumentum alapján készített SRS nem lesz megfelelő, és a tervezési dokumentum sem lesz helyes, és ezért a fejlesztés és tesztelés összes tevékenysége nem az ügyfél elvárásainak megfelelően fog zajlani, mivel előfordulhat egy kis hiba a követelmény felvétele során, vagy a követelmény nem volt megfelelően alapszintű. Ebből megérthetjük, hogy mennyire fontos az alapvonal-tesztelés.

Egy fontos dolog, hogy van egy alapvonal kifejezés, amelyet a konfigurációkezelésben használnak, bár a jelentése többé-kevésbé ugyanaz ott is. A dokumentum verziószámozásához kapcsolódik, ahol a dokumentum alapverzióját véglegesítik, és a dokumentum új verzióját szoftveralkalmazás kiadásonként adják ki. De a konfigurációkezelésben is kevés fogalom van az alapszintű tesztelésről, mivel minden dokumentum alapverzióját, legyen szó akár a fejlesztésről, tesztelésről, webtervezésről vagy bármely más, a szoftverfejlesztéssel kapcsolatban készített dokumentumról, megfelelően felül kell vizsgálni a formátumok és a tartalom szempontjából, hogy a dokumentum következő verziója kevesebb erőfeszítéssel készüljön el a már megfelelően formázott dokumentumban.

Következtetés:

Így látjuk, hogy az alapszintű tesztelés mennyire fontos, és hacsak és amíg a követelménydokumentumot nem érvényesítik megfelelően, vagy más szóval, ha az alapszintű tesztelés nem történik meg, sok probléma lesz a későbbi szakaszban, és az erőfeszítés felhasználása sokkal több lesz a problémák megoldásában, ami csak az erőfeszítés és az idő pazarlása lesz, és új követelményt kell venni, és a szoftverfejlesztési életciklus minden fázisán keresztül kell menni a probléma teljes megoldása érdekében. Tehát azt mondhatjuk, hogy az alapszintű tesztelés számos problémát megold egy korábbi szakaszban, csökkenti a szervezet költségeit, erőfeszítéseit és idejét a szoftverfejlesztési életciklus későbbi szakaszában.

⇓ Subscribe Us ⇓

Ha nem rendszeres olvasója ennek a weboldalnak, akkor erősen ajánljuk, hogy iratkozzon fel ingyenes e-mail hírlevelünkre!!! Iratkozzon fel, csak adja meg az alábbi email címét:

Boldog tesztelést!!!