Testēšanas plāns ir detalizēts dokuments, kurā aprakstītas programmatūras testēšanas jomas un darbības. Tajā ir izklāstīta testa stratēģija, mērķi, testu grafiks, nepieciešamie resursi (cilvēkresursi, programmatūra un aparatūra), testa novērtējums un testa rezultāti.

Testa plāns ir katras programmatūras testēšanas pamatā. Tā ir vissvarīgākā darbība, kas nodrošina visu plānoto aktivitāšu sarakstu pieejamību atbilstošā secībā.

Testa plāns ir veidne programmatūras testēšanas darbību veikšanai kā definēts process, ko pilnībā uzrauga un kontrolē testēšanas vadītājs. Testa plānu sagatavo testa vadītājs (60%), testa vadītājs (20%) un testa inženieris (20%).

Pārbaudes plāna veidi

Ir trīs pārbaudes plāna veidi

• Galvenais pārbaudes plāns
• Fāzes pārbaudes plāns
• Testēšanas tipam specifiski testēšanas plāni

Galvenais pārbaudes plāns

Galvenais pārbaudes plāns ir testa plāna veids, kam ir vairāki testēšanas līmeņi. Tas ietver pilnīgu pārbaudes stratēģiju.

Fāzes pārbaudes plāns

Fāzes pārbaudes plāns ir testa plāna veids, kas attiecas uz jebkuru testēšanas stratēģijas posmu. Piemēram, rīku saraksts, pārbaudes gadījumu saraksts utt.

Īpaši pārbaudes plāni

Īpašs testēšanas plāns, kas paredzēts galvenajiem testēšanas veidiem, piemēram, drošības pārbaudei, slodzes pārbaudei, veiktspējas pārbaudei utt. Citiem vārdiem sakot, īpašs testa plāns, kas paredzēts nefunkcionālai testēšanai.

Kā uzrakstīt testa plānu

Testa plāna sastādīšana ir vissvarīgākais testa pārvaldības procesa uzdevums. Saskaņā ar IEEE 829, lai sagatavotu testa plānu, veiciet tālāk norādītās septiņas darbības.

• Pirmkārt, analizējiet produkta struktūru un arhitektūru.
• Tagad izstrādājiet testa stratēģiju.
• Definējiet visus testa mērķus.
• Definējiet pārbaudes apgabalu.
• Definējiet visus izmantojamos resursus.
• Plānojiet visas darbības atbilstošā veidā.
• Nosakiet visus testa rezultātus.

Pārbaudes plāna sastāvdaļas vai atribūti

Testēšanas plāns sastāv no dažādām daļām, kas palīdz mums iegūt visu testēšanas darbību.

Mērķi: Tas sastāv no informācijas par moduļiem, līdzekļiem, testa datiem utt., kas norāda, ka lietojumprogrammas mērķis nozīmē lietojumprogrammas uzvedību, mērķi utt.

css maina attēla izmēru

Darbības joma: Tajā ir informācija, kas jāpārbauda ar attiecīgo lietojumprogrammu. Darbības jomu var iedalīt divās daļās:

• Redzeslokā
• Ārpus darbības jomas

Redzeslokā: Šie ir moduļi, kas ir rūpīgi jāpārbauda (detalizēti).

Ārpus darbības jomas: Šie ir moduļi, kas nav rūpīgi jāpārbauda.

Piemēram , Pieņemsim, ka mums ir Gmail lietojumprogramma, ko pārbaudīt, kur pārbaudāmās funkcijas piemēram, Rakstīt pastu, nosūtītos vienumus, iesūtni, melnrakstus un funkcijas, kuras nav jāpārbauda piemēram, Palīdzība , un tā tālāk, kas nozīmē, ka plānošanas stadijā mēs izlemsim, kura funkcionalitāte ir jāpārbauda vai nē, pamatojoties uz produktā norādīto laika ierobežojumu.

Tagad kā mēs izlemjam, kuras funkcijas netestēt?

Mēs varam izlemt, kuru funkciju netestēt, izmantojot tālāk norādītos aspektus.

• Kā mēs redzam iepriekš Palīdzība funkcijas netiks pārbaudītas, jo to ir rakstījis un izstrādājis tehniskais autors un pārskatījis cits profesionāls rakstnieks.
• Pieņemsim, ka mums ir viena lietojumprogramma P, Q, R un S funkcijas, kas jāizstrādā, pamatojoties uz prasībām. Bet šeit S funkciju jau ir izstrādājis un izmantojis kāds cits uzņēmums. Tāpēc izstrādes komanda iegādāsies S no šī uzņēmuma un integrēs ar papildu funkcijām, piemēram, P, Q un R.

Tagad mēs neveicam S funkcijas funkcionālo pārbaudi, jo tā jau ir izmantota reāllaikā. Bet mēs veiksim integrācijas testēšanu un sistēmas testēšanu starp P, Q, R un S līdzekļiem, jo ​​jaunās funkcijas var nedarboties pareizi ar S funkciju, kā redzams tālāk esošajā attēlā:

• Pieņemsim, ka produkta pirmajā izlaidumā elementi, kas ir izstrādāti, piemēram, P, Q, R, S, T, U, V, W…..X, Y, Z . Tagad klients nodrošinās prasības jaunajām funkcijām, kas uzlabo produktu otrajā laidienā, un jaunās funkcijas ir A1, B2, C3, D4 un E5.

Pēc tam tvērumu testa plāna laikā rakstīsim kā

Darbības joma

Pārbaudāmās funkcijas

A1, B2, C3, D4, E5 (jaunas funkcijas)

P, Q, R, S, T

Funkcijas, kuras nav jāpārbauda

W…..X, Y, Z

Tāpēc mēs vispirms pārbaudīsim jaunos līdzekļus un pēc tam turpināsim ar vecajiem līdzekļiem, jo ​​tas var tikt ietekmēts pēc jauno līdzekļu pievienošanas, kas nozīmē, ka tas ietekmēs arī ietekmes apgabalus, tāpēc mēs veiksim vienu regresa testēšanas kārtu P, Q. , R…, T funkcijas.

Pārbaudes metodika:

Tajā ir informācija par cita veida testēšanu, piemēram, funkcionālo testēšanu, integrācijas testēšanu un sistēmas testēšanu utt. Tajā mēs izlemsim, kāda veida testēšana; mēs darbosimies ar dažādām funkcijām, pamatojoties uz lietojumprogrammas prasībām. Un šeit mums vajadzētu arī definēt, kāda veida testēšanu mēs izmantosim testēšanas metodoloģijā, lai visi, piemēram, vadība, izstrādes komanda un testēšanas komanda, varētu viegli saprast, jo testēšanas noteikumi nav standarta.

Piemēram, atsevišķai lietojumprogrammai, piemēram, Adobe Photoshop , mēs veiksim šāda veida pārbaudes:

Dūmu pārbaude → Funkcionālā pārbaude → Integrācijas pārbaude → Sistēmas testēšana → Adhoc testēšana → Saderības pārbaude → Regresijas pārbaude → Globalizācijas testēšana → Pieejamības pārbaude → Lietojamības pārbaude → Uzticamības pārbaude → Atkopšanas pārbaude → Instalēšanas vai atinstalēšanas testēšana

Un pieņemsim, ka mums ir jāpārbauda https://www.jeevansathi.com/ lietojumprogrammu, tāpēc mēs veiksim šādus testēšanas veidus:

Pieeja

Šis atribūts tiek izmantots, lai aprakstītu lietojumprogrammas plūsmu testēšanas laikā un turpmākai uzziņai.

Mēs varam saprast lietojumprogrammas plūsmu, izmantojot šādus aspektus:

Rakstot augsta līmeņa scenārijus Rakstot plūsmas grafiku

Rakstot augsta līmeņa scenārijus

Piemēram , pieņemsim, ka mēs pārbaudām Gmail pieteikums:

• Pieteikšanās pakalpojumā Gmail — nosūta e-pastu un pārbauda, ​​vai tas atrodas lapā Nosūtītie vienumi
• Piesakieties …….
• ……
• ......

Mēs to rakstām, lai aprakstītu pieejas, kas jāizmanto produkta testēšanai, un tikai attiecībā uz kritiskajām funkcijām, kurās mēs rakstīsim augsta līmeņa scenārijus. Šeit mēs nekoncentrēsimies uz visu scenāriju aptveršanu, jo konkrētais testēšanas inženieris var izlemt, kuras funkcijas ir jātestē vai nē.

Rakstot plūsmas grafiku

Plūsmas diagramma ir uzrakstīta, jo augsta līmeņa scenāriju rakstīšana ir nedaudz laikietilpīgs process, kā redzams zemāk esošajā attēlā:

Mēs veidojam plūsmas diagrammas, lai iegūtu šādas priekšrocības:

• Pārklājums ir vienkāršs
• Apvienošana ir vienkārša

Šo pieeju var iedalīt divās daļās, kas ir šādas:

• Pieeja no augšas uz leju
• Pieeja no apakšas uz augšu

Pieņēmums

Tajā ir informācija par problēmu vai problēmu, kas varētu būt radusies testēšanas procesa laikā, un, rakstot testēšanas plānus, tiks veikti noteikti pieņēmumi, piemēram, resursi un tehnoloģijas utt.

Risks

Šie ir izaicinājumi, ar kuriem mums jāsaskaras, lai pārbaudītu lietojumprogrammu pašreizējā laidienā, un, ja pieņēmumi neizdosies, ir saistīti riski.

Piemēram, pieteikuma ietekme, izdošanas datums tiek pārcelts.

Seku mazināšanas plāns vai ārkārtas rīcības plāns

Tas ir rezerves plāns, kas ir sagatavots, lai pārvarētu riskus vai problēmas.

string.contains java

Apskatīsim vienu piemēru pieņēmumam, riskam un ārkārtas rīcības plānam kopā, jo tie ir savstarpēji saistīti.

Jebkurā produktā, pieņēmums mēs panāksim, ka visi 3 testēšanas inženieri būs tur līdz produkta pabeigšanai, un katram no viņiem tiks piešķirti dažādi moduļi, piemēram, P, Q un R. Šajā konkrētajā scenārijā risks tas varētu būt, ja testēšanas inženieris pamestu projektu tā vidū.

Tāpēc, ārkārtas rīcības plāns katram objektam tiks piešķirts primārais un pakārtotais īpašnieks. Tātad, ja viens testēšanas inženieris aizies, pakārtotais īpašnieks pārņem šo konkrēto funkciju un palīdz arī jaunajam testēšanas inženierim, lai viņš/viņa varētu saprast viņam piešķirtos moduļus.

Pieņēmumi, risks un mazināšanas vai ārkārtas rīcības plāns vienmēr ir precīzi attiecībā uz pašu produktu. Dažādi risku veidi ir šādi:

• Klienta perspektīva
• Resursu pieeja
• Tehniskais atzinums

Loma un atbildība

Tas definē visu uzdevumu, kas jāveic visai testēšanas komandai. Kad nāk liels projekts, tad Testa vadītājs ir persona, kas raksta pārbaudes plānu. Ja ir 3-4 nelieli projekti, tad testa vadītājs piešķirs katru projektu katram testa vadītājam. Un tad testa vadītājs uzraksta projekta pārbaudes plānu, kas viņam/viņai tiek piešķirts.

Apskatīsim vienu piemēru, kurā mēs sapratīsim testa vadītāja, testa vadītāja un testa inženieru lomas un atbildību.

Loma: Testa vadītājs

Vārds: Raiens

Atbildība:

• Sagatavojiet (uzrakstiet un pārskatiet) testa plānu
• Vadiet tikšanos ar izstrādes komandu
• Vadiet tikšanos ar testēšanas komandu
• Veiciet tikšanos ar klientu
• Rīkojiet vienu ikmēneša piecelšanās sanāksmi
• Parakstīties par atbrīvošanu
• Eskalāciju un problēmu risināšana

Loma: pārbaudes vadītājs

Vārds: Hārvijs

Atbildība:

• Sagatavojiet (uzrakstiet un pārskatiet) testa plānu
• Veiciet ikdienas piecelšanās sanāksmi
• Pārskatiet un apstipriniet testa gadījumu
• Sagatavojiet RTM un pārskatus
• Piešķirt moduļus
• Apstrādes grafiks

Loma: testēšanas inženieris 1, testēšanas inženieris 2 un testēšanas inženieris 3

Vārds: Luiss, Džesika, Donna

Piešķiriet moduļus: M1, M2 un M3

Atbildība:

• Rakstiet, pārskatiet un izpildiet testa dokumentus, kas sastāv no testa gadījuma un testa scenārijiem
• Izlasiet, pārskatiet, izprotiet un analizējiet prasību
• Uzrakstiet lietojumprogrammas plūsmu
• Izpildiet testa gadījumu
• RTM attiecīgajiem moduļiem
• Defektu izsekošana
• Sagatavojiet testa izpildes ziņojumu un paziņojiet to testa vadītājam.

Grafiks

To izmanto, lai izskaidrotu darba laiku, kas ir jādara, vai šis atribūts aptver, kad tieši katrai testēšanas darbībai ir jāsākas un jābeidzas? Un precīzi dati ir minēti arī par katru testēšanas darbību konkrētajā datumā.

Tāpēc, kā redzams zemāk esošajā attēlā, konkrētajai aktivitātei būs sākuma datums un beigu datums; katrai konkrētas versijas testēšanai būs norādīts datums.

Piemēram

• Pārbaudes gadījumu rakstīšana
• Izpildes process

Defektu izsekošana

Parasti tas tiek darīts, izmantojot rīkus, jo mēs nevaram manuāli izsekot katras kļūdas statusam. Mēs arī komentējam, kā mēs paziņojam par testēšanas procesa laikā konstatētajām kļūdām un nosūtām to atpakaļ izstrādes komandai un kā izstrādes komanda atbildēs. Šeit mēs pieminam arī tādu kļūdu prioritāti kā augsta, vidēja un zema.

Tālāk ir norādīti dažādi defektu izsekošanas aspekti.

Kļūdas izsekošanas paņēmieni
…..
……
……
……Kļūdu izsekošanas rīki
Varam komentēt rīka nosaukumu, ko izmantosim kļūdu izsekošanai. Daži no visbiežāk izmantotajiem kļūdu izsekošanas rīkiem ir Jira, Bugzilla, Mantis un Trac utt.<Smaguma pakāpe
Smaguma pakāpe var būt šāda:
Bloķētājs vai parāda aizbāznis
…..
….. (Paskaidrojiet to ar piemēru testa plānā)
Piemēram , būs moduļa defekts; mēs nevaram iet tālāk, lai pārbaudītu citus moduļus, jo, ja kļūda ir bloķēta, mēs varam turpināt pārbaudīt citus moduļus.
Kritisks
……
….. (Paskaidrojiet to ar piemēru testa plānā)
Šajā situācijā defekti ietekmēs biznesu.
Vairākums
….
…. (Paskaidrojiet to ar piemēru testa plānā)
Nepilngadīga
…..
….. (Paskaidrojiet to ar piemēru testa plānā)
Šie defekti ir tie, kas ietekmē lietojumprogrammas izskatu un sajūtu.Prioritāte
Augsts P1
…..
Vidējs-P2
…..
Zems-P3
…..
…..
P4

Tāpēc, pamatojoties uz kļūdu prioritāti bizness augsta, vidēja un zema, mēs to iedalīsim kategorijās P1, P2, P3 un P4.

java binārais koks

Testa vides

Šīs ir vides, kurās mēs pārbaudīsim lietojumprogrammu, un šeit mums ir divu veidu vides, kas ir no programmatūra un aparatūra konfigurācija.

The programmatūras konfigurācija nozīmē informāciju par dažādiem Operētājsistēmas piemēram, Windows, Linux, UNIX un Mac un dažādas Pārlūkprogrammas patīk Google Chrome, Firefox, Opera, Internet Explorer , un tā tālāk.

Un aparatūras konfigurācija nozīmē informāciju par dažādiem izmēriem RAM, ROM un procesori .

Piemēram

• The Programmatūra ietver sekojošo:

Serveris

Piezīme. Iepriekš minētie serveri ir tie serveri, kurus testēšanas komanda izmanto lietojumprogrammas testēšanai.

Klients

Piezīme. Iepriekš sniegtā informācija norāda uz dažādām operētājsistēmām un pārlūkprogrammām, kurās testēšanas komanda pārbaudīs lietojumprogrammu.

• The Aparatūra ietver sekojošo:

Serveris : Sun StarCat 1500

Testēšanas komanda var izmantot šo konkrēto serveri, lai pārbaudītu savu lietojumprogrammu.

Klients:

Tam ir šāda konfigurācija, kas ir šāda:

Piezīme. Tas nodrošinās testēšanas inženieru, kas ir testēšanas komanda, sistēmu konfigurāciju.

Programmatūras instalēšanas process
……
…..
…..

Izstrādes komanda nodrošinās programmatūras instalēšanas konfigurāciju. Ja izstrādes komanda vēl nenodrošinās procesu, mēs to ierakstīsim testa plānā kā Uzdevumos balstīta izstrāde (TBD).

Ieejas un izejas kritēriji

Tas ir nepieciešams nosacījums, kas jāizpilda pirms testēšanas procesa uzsākšanas un pārtraukšanas.

Iestāšanās kritēriji

Pieteikšanās kritēriji ietver šādus nosacījumus:

• Baltās kastes pārbaude ir jāpabeidz.
• Izprast un analizēt prasību un sagatavot testa dokumentus vai kad testa dokumenti ir gatavi.
• Testa datiem jābūt gataviem.
• Būvē vai jāsagatavo pieteikums
• Moduļi vai līdzekļi ir jāpiešķir dažādiem testēšanas inženieriem.
• Nepieciešamajam resursam jābūt gatavam.

Izejas kritēriji

Izejas kritēriji ietver šādus nosacījumus:

• Kad visas pārbaudes lietas ir izpildītas.
• Lielākajai daļai testa gadījumu jābūt pagājis .
• Atkarīgs no kļūdu nopietnības, kas nozīmē, ka nedrīkst būt bloķētāju vai būtisku kļūdu, lai gan pastāv dažas nelielas kļūdas.

Pirms sākam veikt funkcionālo testēšanu, viss iepriekš minētais Iestāšanās kritēriji būtu jāievēro. Pēc tam, kad esam veikuši funkcionālo testēšanu un pirms mēs veiksim integrācijas testēšanu, tad Izejas kritēriji Funkcionālā pārbaude ir jāievēro, jo izejas kritēriju procentuālo daļu nosaka tikšanās gan ar izstrādes, gan testa vadītāju, jo viņu sadarbība var sasniegt procentus. Bet, ja funkcionālās pārbaudes izejas kritēriji netiek ievēroti, mēs nevaram turpināt integrācijas testēšanu.

Šeit pamatojoties uz smaguma pakāpi no kļūdas nozīmē, ka testēšanas komanda būtu nolēmusi turpināt darbu nākamajās fāzēs.

Testa automatizācija

Šajā gadījumā mēs izlemsim sekojošo:

• Kurai funkcijai jābūt automatizētai, nevis automatizētai?
• Kuru testa automatizācijas rīku mēs izmantosim kādā automatizācijas sistēmā?

Mēs automatizējam testa gadījumu tikai pēc pirmās izlaišanas.

Šeit rodas jautājums, uz kāda pamata mēs gribu izlemt, kuras funkcijas ir jāpārbauda?

Iepriekš redzamajā attēlā redzams, ka visbiežāk izmantotās funkcijas ir jāpārbauda atkal un atkal. Pieņemsim, ka mums ir jāpārbauda Gmail lietojumprogramma, kurā ir galvenās funkcijas Rakstiet vēstules, nosūtītos vienumus un iesūtni . Tāpēc mēs pārbaudīsim šīs funkcijas, jo, veicot manuālo testēšanu, tas aizņem vairāk laika un kļūst arī par vienmuļu darbu.

Tagad kā mēs izlemjam, kuras funkcijas netiks pārbaudītas?

Pieņemsim Palīdzība Gmail lietojumprogrammas funkcija netiek pārbaudīta atkal un atkal, jo šīs funkcijas netiek regulāri izmantotas, tāpēc mums tas nav bieži jāpārbauda.

Bet ja dažas funkcijas ir nestabilas un tajās ir daudz kļūdu , kas nozīmē, ka mēs nepārbaudīsim šīs funkcijas, jo tās ir jāpārbauda atkal un atkal, veicot manuālo testēšanu.

Ja ir funkcija, kas ir bieži jāpārbauda , taču mēs gaidām šīs funkcijas prasību izmaiņas, tāpēc mēs to nepārbaudām, jo ​​manuālo testa gadījumu maiņa ir ērtāka, salīdzinot ar izmaiņām automatizācijas testa skriptā.

Piepūles novērtējums

Tajā mēs plānosim pūles, kas jāpieliek katram komandas dalībniekam.

Tests Piegādājams

Tie ir dokumenti, kas ir testēšanas komandas rezultāts, ko mēs nodevām klientam kopā ar produktu. Tas ietver:

Pārbaudes plāns Pārbaudes gadījumi Testa skripti RTM (prasību izsekojamības matrica) Ziņojums par defektiem Pārbaudes izpildes ziņojums Grafiki un metrika Izlaiduma piezīmes

Grafiki un metrika

Grafiks

Šajā sadaļā mēs apspriedīsim veidus grafiki mēs nosūtīsim, kā arī nodrošināsim katra grafika paraugu.

klēpjdatora ievietošanas atslēga

Kā redzam, mums ir pieci dažādi grafiki, kas parāda dažādus testēšanas procesa aspektus.

1. diagramma: Šajā mēs parādīsim, cik defektu ir identificēti un cik defekti ir novērsti katrā modulī.

2. grafiks: Pirmajā attēlā parādīts, cik kritisku, lielu un mazāku defektu ir identificēti katram modulim un cik ir laboti attiecīgajiem moduļiem.

3. diagramma: Šajā konkrētajā grafikā mēs attēlojam izveidot gudru grafiku , kas nozīmē, ka katrā būvējumā, cik defektu ir identificēti un novērsti katram modulim. Pamatojoties uz moduli, mēs esam noteikuši kļūdas. Mēs pievienosim R lai parādītu defektu skaitu P un Q, un mēs arī pievienojam S lai parādītu P, Q un R defektus.

4. diagramma: Testa vadītājs izstrādās Kļūdu tendenču analīze grafiks, kas tiek veidots katru mēnesi, un nosūtīt to arī vadībai. Un tas ir gluži kā prognozēšana, kas tiek veikta produkta beigās. Un šeit mēs arī varam novērtējiet kļūdu labojumus kā mēs to varam novērot loka ir tendence uz augšu zemāk esošajā attēlā.

5. diagramma: The Testa vadītājs ir izstrādājis šāda veida grafiku. Šī diagramma ir paredzēta, lai izprastu nepilnības kļūdu novērtējumā un faktiskās kļūdas, kas ir notikušas, un šī diagramma arī palīdz uzlabot kļūdu novērtēšanu nākotnē.

Metrika

Kā iepriekš, mēs izveidojam kļūdu izplatības grafiku, kas ir 1. attēlā, un ar iepriekš minēto datu palīdzību mēs izstrādāsim arī metriku.

Piemēram

Iepriekš redzamajā attēlā mēs saglabājam ierakstus par visiem testēšanas inženieriem konkrētajā projektā un to, cik defektu ir konstatēti un novērsti. Mēs varam izmantot šos datus arī turpmākai analīzei. Kad rodas jauna prasība, mēs varam izlemt, kam nodrošināt izaicinošo funkciju testēšanai, pamatojoties uz iepriekš konstatēto defektu skaitu saskaņā ar iepriekš minētajiem rādītājiem. Un mēs būsim labākā situācijā, lai zinātu, kurš var ļoti labi tikt galā ar problemātiskajām funkcijām un atrast maksimālo defektu skaitu.

Izlaiduma piezīme: Tas ir dokuments, kas tiek sagatavots produkta izlaišanas laikā un ko paraksta Testa vadītājs.

Tālāk redzamajā attēlā redzams, ka gala produkts ir izstrādāts un izvietots klientam, un jaunākā laidiena nosaukums ir Beta .

The Izlaiduma piezīme sastāv no sekojošiem:

• Lietotāja rokasgrāmata.
• Neapstiprināto un atklāto defektu saraksts.
• Pievienoto, modificēto un dzēsto funkciju saraksts.
• Platformas saraksts (operētājsistēma, aparatūra, pārlūkprogrammas), kurā produkts tiek testēts.
• Platforma, kurā produkts netiek testēts.
• Pašreizējā laidienā laboto kļūdu saraksts un iepriekšējā laidienā laboto kļūdu saraksts.
• Uzstādīšanas process
• Programmatūras versijas

Piemēram

Pieņemsim, ka Beta ir otrais lietojumprogrammas laidiens pēc pirmā laidiena Alfa tiek atbrīvots. Daži no defektiem, kas identificēti pirmajā izlaidumā, un kas tika novērsti vēlāk izlaistajā. Šeit mēs arī norādīsim nesen pievienoto, modificēto un dzēsto funkciju sarakstu no alfa laidiena līdz beta versijai.

Veidne

Šajā daļā ir visas veidnes dokumentiem, kas tiks izmantoti izstrādājumā, un visi testēšanas inženieri projektā izmantos tikai šīs veidnes, lai saglabātu produkta konsekvenci. Šeit mums ir dažādi veidņu veidi, kas tiek izmantoti visā testēšanas procesā, piemēram:

• Pārbaudes gadījuma veidne
• Pārbaudes gadījumu pārskata veidne
• RTM veidne
• Kļūdu ziņojuma veidne
• Pārbaudes izpildes ziņojums

Apskatīsim vienu testa plāna dokumenta paraugu

Lapa-1

Lapa3-lapa18

Lapa-20

1. lapā mēs galvenokārt aizpildām tikai Versijas, autors, komentāri un pārskatīja laukos, un pēc tam, kad pārvaldnieks to apstiprinās, mēs pieminēsim sīkāku informāciju Apstiprināts līdz un apstiprināšanas datums lauki.

Pārsvarā testa plānu apstiprina testēšanas vadītājs, un testēšanas inženieri to tikai pārskata. Kad būs pieejamas jaunas funkcijas, mēs pārveidosim testa plānu un veiksim nepieciešamās izmaiņas Versija laukā, un pēc tam tas atkal tiks nosūtīts tālākai pārskatīšanai, atjaunināšanai un pārvaldnieka apstiprināšanai. Testa plāns ir jāatjaunina ikreiz, kad ir notikušas izmaiņas. 20. lpp Atsauces norādiet informāciju par visiem dokumentiem, kurus mēs izmantosim, lai uzrakstītu pārbaudes plāna dokumentu.

Piezīme:

Kurš raksta pārbaudes plānu?

• Testa vads → 60%
• Pārbaudes vadītājs → 20%
• Testēšanas inženieris → 20%

Tāpēc, kā mēs redzam no augšas, 60% produkta testa plānu raksta testēšanas vadītājs.

Kas pārskata testa plānu?

• Testa vads
• Testa vadītājs
• Pārbaudes inženieris
• Klients
• Attīstības komanda

Testēšanas inženieris pārskata testa plānu sava moduļa perspektīvai, un pārbaudes vadītājs pārskata testa plānu, pamatojoties uz klienta viedokli.

Kas apstiprina testa plānu?

• Klients
• Testa vadītājs

Kurš raksta testa gadījumu?

• Testa vads
• Pārbaudes inženieris

Kas izskata testa gadījumu?

js globālais mainīgais

• Pārbaudes inženieris
• Testa vads
• Klients
• Attīstības komanda

Kas apstiprina pārbaudes gadījumus?

• Testa vadītājs
• Testa vads
• Klients

Pārbaudes plāna vadlīnijas

• Sakļaut testa plānu.
• Izvairieties no pārklāšanās un dublēšanas.
• Ja uzskatāt, ka iepriekš minētā sadaļa jums nav vajadzīga, izdzēsiet šo sadaļu un turpiniet.
• Esi konkrēts. Piemēram, ja norādāt programmatūras sistēmu kā testa vides daļu, norādiet programmatūras versiju, nevis tikai nosaukumu.
• Izvairieties no garām rindkopām.
• Kur vien iespējams, izmantojiet sarakstus un tabulas.
• Atjauniniet plānu, kad nepieciešams.
• Neizmantojiet novecojušu un neizmantotu dokumentu.

Pārbaudes plāna nozīme

• Pārbaudes plāns dod virzienu mūsu domāšanai. Tas ir kā noteikumu grāmata, kas ir jāievēro.
• Testa plāns palīdz noteikt nepieciešamos centienus, lai apstiprinātu pārbaudāmās programmatūras lietojumprogrammas kvalitāti.
• Testa plāns palīdz tiem cilvēkiem izprast testa detaļas, kas ir saistītas ar ārpusi, piemēram, izstrādātājiem, uzņēmumu vadītājiem, klientiem utt.
• Svarīgi aspekti, piemēram, testu grafiks, testēšanas stratēģija, testa apjoms utt., ir dokumentēti pārbaudes plānā, lai vadības komanda varētu tos pārskatīt un atkārtoti izmantot citos līdzīgos projektos.