Programmatūras produktu testēšana. Kā pārbaudīt tādas funkcijas funkcionalitāti, kas izmanto citas tajā esošās funkcijas? Ar izmaiņām saistītā pārbaude

Pat ja esat tik iecietīgs, ka pēc avārijas pusstundas laikā varat restartēt programmu 18 reizes un tikai pēc tam mest monitoru tieši pa logu, piekritīsiet, ka strādāt ar šo programmu būtu ērtāk, ja tā "neavarētu". ”.

Kā jūs varat pārliecināties, ka jūsu izstrādātās programmas avāriju, sasalšanas vai nepieciešamo darbību neizpildes gadījumi kļūst ļoti reti?

Uz šo jautājumu nav precīzas atbildes. Taču gadsimtu gaitā gudrākie zinātnieki ir domājuši par šo tēmu gadiem ilgi un spējuši atrast līdzekli, kas, ja arī nenovērš visas programmas kļūdas, tad vismaz rada ilūziju par rīcību to novēršanai.

Un šo līdzekli sauc Programmatūras produkta TESTĒŠANA.

Pēc gudru cilvēku domām, testēšana ir viens no visizteiktākajiem veidiem, kā nodrošināt izstrādes kvalitāti programmatūra un ir daļa no efektīvu rīku komplekta moderna sistēma programmatūras produkta kvalitātes nodrošināšana.

Programmatūras produkta kvalitāti raksturo īpašību kopums, kas nosaka, cik produkts ir “labs” no ieinteresēto pušu, piemēram, produkta klienta, sponsora, galalietotāja, produktu izstrādātāju un testētāju, atbalsta inženieru, mārketinga viedokļa. , apmācību un pārdošanas personāls. Katram no dalībniekiem var būt atšķirīgs priekšstats par produktu un to, cik tas ir labs vai slikts, tas ir, cik augsta ir produkta kvalitāte. Tādējādi, uzstādot produktu kvalitātes nodrošināšanas problēmu, rodas uzdevums identificēt ieinteresētās puses, to kvalitātes kritērijus un pēc tam atrast optimālo risinājumu, kas atbilst šiem kritērijiem.

Kad un kurš?

Pēc pieredzējušu izstrādātāju domām, programmatūras produkta testēšana jāveic jau no tā izveides sākuma. Bet tajā pašā laikā pašiem pieredzējušiem izstrādātājiem nevajadzētu piedalīties testēšanā, jo tā nav karaliska lieta. Programmatūras produkts ir jāpārbauda speciāli apmācītiem darbiniekiem, kurus sauc par testētājiem, jo ​​pat vispieredzējušākais izstrādātājs nevarēs redzēt savu kļūdu, pat izmantojot jaunākos optiskos instrumentus.

Tomēr visi izstrādātāji piekrīt, ka programmatūras produkta testēšana no klasifikācijas viedokļa pēc mērķa ir jāsadala divās klasēs:

• Funkcionālā pārbaude
• Nefunkcionāla pārbaude

Funkcionālā pārbaude

Funkcionālā pārbaude nozīmē programmatūras produkta atbilstības pārbaudi funkcionālajām prasībām, kas noteiktas šī produkta izveides tehniskajās specifikācijās. Vienkārši sakot, funkcionālā pārbaude pārbauda, ​​vai programmatūras produkts pilda visas funkcijas, kurām tam vajadzētu būt.

Tātad, jūs beidzot nolēmāt veikt funkcionālo pārbaudi. Ieskaties tehniskajā specifikācijā, izlasi funkcionālās prasības un saproti, ka vismaz tās nav tādā secībā, kādā var veikt testēšanu. Jūs būsiet pārsteigts, ka diezgan sen citi jau pamanīja šo neatbilstību un izdomāja, kā to pārvarēt.

Lai veiktu funkcionālo testēšanu, tehniskās kontroles nodaļas darbinieki izstrādā dokumentu programmu un metodiku aplikācijas (API) funkcionalitātes pārbaudei. PMI dokumentā ir saraksts ar programmatūras produktu testēšanas scenārijiem (testa gadījumiem) ar Detalizēts apraksts soļi. Katru testēšanas scenārija soli raksturo lietotāja (testēšanas speciālista) darbības un sagaidāmie rezultāti - programmas reakcija uz šīm darbībām. Testa programmai un metodikai ir jāmodelē programmatūras produkta darbība reālajā režīmā. Tas nozīmē, ka testēšanas scenārijs jāveido, pamatojoties uz to darbību analīzi, kuras veiks nākamie sistēmas lietotāji, nevis mākslīgi sastādīta manipulāciju secība, kas ir saprotama tikai izstrādātājam.

Parasti funkcionālo pārbaudi veic divos līmeņos:

• Komponentu (vienību) testēšana. Programmatūras produkta atsevišķu komponentu testēšana, koncentrējoties uz to specifiku, mērķi un funkcionālajām iezīmēm.
• Integrācijas pārbaude. Šis tips testēšana tiek veikta pēc komponentu testēšanas un ir vērsta uz defektu identificēšanu dažādu apakšsistēmu mijiedarbībā vadības plūsmu un datu apmaiņas līmenī.

Nefunkcionāla pārbaude

Nefunkcionālā testēšana novērtē programmatūras produkta īpašības, piemēram, ergonomiku vai veiktspēju.

Es domāju, ka šāda veida testēšanas nozīme ir skaidra, un tai nav nepieciešams pamatojums. Galu galā visi saprot, ka, ja, piemēram, sistēmas veiktspēja nav pietiekama, lietotājiem būs jāgaida puse dienas, lai saņemtu atbildi uz viņu darbībām, kas var izraisīt viņu masveida hibernāciju.

Kā norāda nosaukums, nefunkcionālā testēšana pārbauda, ​​vai programmatūras produkts atbilst nefunkcionālajām prasībām darba uzdevums tās radīšanai. Un, tāpat kā funkcionālās testēšanas gadījumā, nefunkcionālajai testēšanai tiek izstrādāta testēšanas programma un metodika.

Iegultās programmatūras testēšana un atbilstība elastīgajā laikmetā

Atbilstību nozares standartiem nevar atstāt novārtā vai darīt vēlāk; tā ir iegultās programmatūras (programmatūras) izstrādes procesa neatņemama sastāvdaļa. Dažām nozarēm, piemēram, aviācijas elektronikai, automobiļu rūpniecībai un veselības aprūpei, stingra kvalitātes standartu ievērošana sarežģītu un bezproblēmu iegulto sistēmu izstrādē ir ļoti svarīga, lai produktu laistu tirgū. Tradicionāli testēšanai ir bijusi svarīga loma iegulto sistēmu izstrādē standartu regulētām nozarēm. Taču pēdējos gados ir būtiski mainījusies iedibinātā testēšanas prakse un procesi, to vieta un loma šādos projektos. Tas bija spēles mainītājs, un, mainoties spēles noteikumiem, jums ir jāmainās ar tiem, lai uzvarētu.

Pastāvīgi attīstoties jaunām, progresīvām tehnoloģijām, uzņēmumiem ātri jāpiedāvā tirgū uzticami, droši, ērti lietojami un ar citām sistēmām savietojami produkti – lai tikai nepazustu strauji mainīgajā tehnoloģiju pasaulē. Šādā situācijā tradicionālais ūdenskrituma modelis, kurā programmatūras izstrādes process notiek stingri secīgi un testēšana tiek veikta pašās beigās, kļūst par pagātni. DevOps un Agile metodes kļūst arvien populārākas, jo tās ļauj inženieriem vienlaikus izpildīt uzdevumus, kas iepriekš sekoja viens otram.

Veiktspējas pārbaude

Veiktspējas pārbaudes posmā pirmais solis ir slodzes pārbaude, kuras mērķis ir pārbaudīt, vai sistēma adekvāti reaģēs uz ārējām ietekmēm režīmā, kas ir tuvu reālai darbībai.

Papildus slodzes testēšanai tiek veikti testi minimālas aparatūras un maksimālās slodzes apstākļos - stresa testēšana, kā arī testi maksimālā apstrādātās informācijas apjoma apstākļos - tilpuma pārbaude.

Ir vēl viens testēšanas veids: stabilitātes un uzticamības pārbaude, kas ietver ne tikai programmatūras produkta ilgtermiņa testēšanu normālos apstākļos, bet arī tā spēju atgriezties normālā darbībā pēc īsiem stresa slodzes periodiem.

Dokumentācija pārbaudei

Kā minēts iepriekš, testēšana tiek veikta saskaņā ar programmu un pārbaudes metodiku, kas izstrādāta saskaņā ar GOST 34.603-92.

Pārbaudei mēs izstrādājam pārbaudes gadījums, kurā jāietver pietiekami daudz datu, lai pārbaudītu visus programmatūras produkta darbības režīmus. Parasti pārbaudes gadījumu pasūtītājs un darbuzņēmējs kopīgi izveido, pamatojoties uz reāliem datiem.

Lai veiktu visu veidu veiktspējas testēšanu, visbiežāk tiek izveidots tā sauktais datu ģenerators, kas ļauj automātiskais režīms izveidot pietiekamu datu apjomu, lai, novērtējot sniegumu, sasniegtu objektīvu rezultātu.

Testēšanas laikā tiek sastādīts testēšanas protokols, kurā ir informācija par visu testēšanas posmu un soļu pabeigšanu un testēšanas laikā saņemtie komentāri.

Ja testa rezultāts ir negatīvs, trūkumi tiek novērsti un atkārtoti pārbaudīti.

Izpētes pārbaude

Izpētes testēšana (ad hoc testēšana ir funkcionālās testēšanas apakštips. To izmanto strauji augošos projektos ar elastīgām izstrādes metodēm, kur nav skaidras dokumentācijas un prasības. Izpētes testēšana ir augstākā akrobātika programmatūras testēšanā. Kvalitatīvā pārbaude ir pieejama augsti kvalificēti speciālisti un gandrīz pilnībā ir atkarīgs no izpildītāja, viņa pieredzes, zināšanām (gan priekšmetā, gan testēšanas metodēs), un spējas ātri tikt pie būtības.

Stresa testēšana

Slodzes pārbaude ir testējamās sistēmas veiktspējas analīzes process slodzes laikā. Slodzes pārbaudes mērķis ir noteikt lietojumprogrammas spēju izturēt ārējās slodzes. Parasti pārbaudes tiek veiktas vairākos posmos.

1. Testa skriptu ģenerēšana

Efektīvai analīzei scenārijiem jābūt pēc iespējas tuvākiem faktiskajiem lietošanas gadījumiem. Ir svarīgi saprast, ka izņēmumi vienmēr ir iespējami, un pat visdetalizētākais pārbaudes plāns var neaptvert vienu gadījumu.

2. Testa konfigurācijas izstrāde

Ņemot vērā testa scenārijus, ir svarīgi sadalīt slodzes palielināšanas secību. Veiksmīgai analīzei ir nepieciešams noteikt darbības novērtēšanas kritērijus (atbildes ātrums, pieprasījuma apstrādes laiks utt.).

3. Testa testa veikšana

Veicot testus, ir svarīgi laikus uzraudzīt scenāriju izpildi un pārbaudāmās sistēmas reakciju. Lielu slodžu emulēšanai ir nepieciešama nopietna aparatūras un programmatūras infrastruktūra. Dažos gadījumos tiek izmantotas matemātiskās modelēšanas metodes, lai samazinātu darba izmaksas. Dati, kas iegūti pie zemām slodzēm, tiek ņemti par pamatu un tuvināti. Jo augstāks ir simulētās slodzes līmenis, jo zemāka ir novērtējuma precizitāte. Tomēr šī metode ievērojami samazina izmaksas.

Testēšanas automatizācija

Galvenā automatizētās testēšanas iezīme ir spēja ātri veikt regresijas testus. Galvenās automatizācijas priekšrocības (saskaņā ar Worksoft ziņojumu) ir paaugstināta personāla efektivitāte, agrāka defektu atklāšana u.c. augstas kvalitātes biznesa procesiem. Šīs priekšrocības kompensē būtisks trūkums: augstās izmaksas – testu automatizācijas ieviešanas un atbalsta augsto izmaksu dēļ aptuveni 50% uzņēmumu joprojām izmanto galvenokārt manuālo testēšanu.

Lietojamības pārbaude

Jebkura lietojumprogramma tiek izveidota, lai to varētu izmantot. Lietošanas ērtums ir svarīgs programmas kvalitātes rādītājs. IT nozare zina daudzus piemērus, kad projekti paceļas pēc veiksmīga lietojamības labojuma. Jo plašāka auditorija, jo svarīgāks ir lietojamības faktors. Lietojamības pārbaude ietver detalizētu lietotāja uzvedības analīzi. Lai novērtētu ergonomiku, ir svarīgi, lai būtu dati ne tikai par biznesa uzdevuma izpildes ātrumu, bet arī par lietotāja emocijām, sejas izteiksmēm un balss tembru.

Konfigurācijas pārbaude

Konfigurācijas testēšana sniedz pārliecību, ka lietojumprogramma darbosies dažādās platformās un līdz ar to maksimālajam lietotāju skaitam. WEB lietojumprogrammām parasti tiek izvēlēta starppārlūkprogrammu pārbaude. Windows lietojumprogrammām - testēšana uz dažādām operētājsistēmas un bitu izmēri (x86, x64). Svarīga konfigurācijas testēšanas sastāvdaļa ir testēšanas infrastruktūra: lai veiktu testus, jums pastāvīgi jāuztur testa iekārtu parks. To skaits svārstās no 5 līdz vairākiem desmitiem.

Integrācijas pārbaude

Ja jūsu projektā ir vairāk nekā viens komponents, tam nepieciešama integrācijas pārbaude. Ar sarežģītu lietojumprogrammu arhitektūru nepieciešams kvalitātes nodrošināšanas nosacījums ir programmas daļu mijiedarbības pārbaude. Pārbaude tiek panākta, izstrādājot un veicot “no gala līdz galam” gadījumus. Integrācijas pārbaude tiek veikta pēc komponentu pārbaudes. Tāpēc ir ļoti svarīgi ņemt vērā komponentu testēšanas pieredzi, vienlaikus ievērojot testa gadījumu biznesa orientāciju.

Stresa testēšana

Katrai sistēmai ir ierobežojums normāla darbība. Pārsniedzot limitu, sistēma nonāk stresa stāvoklī un būtiski maina savu uzvedību. Stresa testēšana pārbauda lietojumprogrammas darbību apstākļos, kas pārsniedz parastās darbības robežas. Tas ir īpaši svarīgi “kritiskajām” programmām: banku programmatūrai, aviācijas nozares programmām, medicīnai. Stresa testēšana tiek veikta ne tikai programmatūras izstrādes stadijā, bet arī visa darbības cikla laikā, lai iegūtu un apstrādātu sistēmas uzvedības datus ilgā laika periodā.

Pieņemsim, ka ir funkcija get-data, kas atgriež informācijas karti par nodoto lietotāja ID. Tagad šī funkcija izmanto 3 funkcijas avots-a , avots-b un avots-c, lai izveidotu trīs dažādu veidu kartes. Tagad mēs apvienosim visas šīs kartes vienā kartē un atgriezīsimies no datu iegūšanas.

Kad es pārbaudu get-datavai man jāpārbauda datu pieejamība atslēgām? Vai ir jēga šai funkcijai izgāzties vienības testos, ja viens no avota-a, avota-b un avota-c neizdodas? Ja šīs funkcijas uzdevums ir apvienot datus, un tas notiek, ar to vajadzētu pietikt, vai ne?

1

2 atbildes

Pieņemsim, ka ir funkcija get-data, kas atgriež informācijas karti par lietotāja ID, kuram ir nodots.

Lieliski. Tad jums tas jāpārbauda. Vai par norādīto ID atgriežat pareizos datus?

tagad šī funkcija izmanto 3 funkcijas avots-a, avots-b un avots-c, lai izveidotu trīs dažādu veidu kartes.

Kuru ieviešanas detaļu testā nevajadzētu ignorēt. Viss, ko jūs pārbaudāt, ir tas, vai jūsu darba vienība (šī metode) dara to, kas tai ir jādara (paņem ID un atgriež XYZ datus šim ID). Kāšai metodei nav īsti nozīmes — galu galā šīs vienības pārbaudes galvenais ieguvums ir tas, ka varat pārveidot metodes ieviešanu, un tests pārbaudīs, vai to izdarījāt pareizi.

Tomēr, iespējams, jums būs jāņirgājas par datu avotiem, tāpēc kādā brīdī testam, iespējams, būs jāzina, kā šis kods darbojas. Šeit jums ir jāsabalansē trīs konkurējoši mērķi: padarīt testu izolētu (izsmejot datus), vienlaikus liekot testam koncentrēties uz prasībām un pragmatismu.

Galu galā šis ir svarīgs kods. Ir testi, kas atbalsta faktisko kodu, pavadot daudz laika, un grūtības ar pulēšanas pārbaudi nav tik noderīgas kā testi padarot .

Vienību testēšanā ir jāpārbauda tikai vienas klases funkcionalitāte, ja jūsu avota-a, avota-b un avota-c metodes izsauc citas klases, jums tās ir jāņirgājas (tās ir jāpārbauda savās klasēs).

Integrācijas testēšanā jūs pārbaudāt vairāku klašu darbību, kas mijiedarbojas starp tām. Tas nozīmē, ka funkcijai get-data ir jāpārbauda, ​​vai dati, kas tiek izgūti, ir pareizi (avots-a, avots-b un avots-c ir pareizi un dati ir pareizi savienoti).

Vienību testi ir vienkāršāki un mērķtiecīgāki, un tie būtu jāraksta izstrādātājiem. Integrācijas testi parasti salīdzinoši ātri noveco (ja tādi ir iekšējā sastāvdaļa ir mainīts), padarot to izpildi grūtāku. Jāizveido, izmantojot kvalitātes nodrošināšanas profilu.

Pat ja esat tik iecietīgs, ka pēc avārijas pusstundas laikā varat restartēt programmu 18 reizes un tikai pēc tam mest monitoru tieši pa logu, piekritīsiet, ka strādāt ar šo programmu būtu ērtāk, ja tā "neavarētu". ”.

Kā jūs varat pārliecināties, ka jūsu izstrādātās programmas avāriju, sasalšanas vai nepieciešamo darbību neizpildes gadījumi kļūst ļoti reti?

Uz šo jautājumu nav precīzas atbildes. Taču gadsimtu gaitā gudrākie zinātnieki ir domājuši par šo tēmu gadiem ilgi un spējuši atrast līdzekli, kas, ja arī nenovērš visas programmas kļūdas, tad vismaz rada ilūziju par rīcību to novēršanai.

Un šo līdzekli sauc Programmatūras produkta TESTĒŠANA.

Pēc gudru cilvēku domām, testēšana ir viens no iedibinātākajiem veidiem, kā nodrošināt programmatūras izstrādes kvalitāti un ir iekļauts mūsdienīgas programmatūras produktu kvalitātes nodrošināšanas sistēmas efektīvu rīku komplektā.

Programmatūras produkta kvalitāti raksturo īpašību kopums, kas nosaka, cik produkts ir “labs” no ieinteresēto pušu, piemēram, produkta klienta, sponsora, galalietotāja, produktu izstrādātāju un testētāju, atbalsta inženieru, mārketinga viedokļa. , apmācību un pārdošanas personāls. Katram no dalībniekiem var būt atšķirīgs priekšstats par produktu un to, cik tas ir labs vai slikts, tas ir, cik augsta ir produkta kvalitāte. Tādējādi, uzstādot produktu kvalitātes nodrošināšanas problēmu, rodas uzdevums identificēt ieinteresētās puses, to kvalitātes kritērijus un pēc tam atrast optimālo risinājumu, kas atbilst šiem kritērijiem.

Kad un kurš?

Pēc pieredzējušu izstrādātāju domām, programmatūras produkta testēšana jāveic jau no tā izveides sākuma. Bet tajā pašā laikā pašiem pieredzējušiem izstrādātājiem nevajadzētu piedalīties testēšanā, jo tā nav karaliska lieta. Programmatūras produkts ir jāpārbauda speciāli apmācītiem darbiniekiem, kurus sauc par testētājiem, jo ​​pat vispieredzējušākais izstrādātājs nevarēs redzēt savu kļūdu, pat izmantojot jaunākos optiskos instrumentus.

Tomēr visi izstrādātāji piekrīt, ka programmatūras produkta testēšana no klasifikācijas viedokļa pēc mērķa ir jāsadala divās klasēs:

• Funkcionālā pārbaude
• Nefunkcionāla pārbaude

Funkcionālā pārbaude

Funkcionālā pārbaude nozīmē programmatūras produkta atbilstības pārbaudi funkcionālajām prasībām, kas noteiktas šī produkta izveides tehniskajās specifikācijās. Vienkārši sakot, funkcionālā pārbaude pārbauda, ​​vai programmatūras produkts pilda visas funkcijas, kurām tam vajadzētu būt.

Tātad, jūs beidzot nolēmāt veikt funkcionālo pārbaudi. Ieskaties tehniskajā specifikācijā, izlasi funkcionālās prasības un saproti, ka vismaz tās nav tādā secībā, kādā var veikt testēšanu. Jūs būsiet pārsteigts, ka diezgan sen citi jau pamanīja šo neatbilstību un izdomāja, kā to pārvarēt.

Lai veiktu funkcionālo testēšanu, tehniskās kontroles nodaļas darbinieki izstrādā dokumentu programmu un metodiku lietojumprogrammas (API) funkcionalitātes pārbaudei. PMI dokumentā ir programmatūras produktu testēšanas scenāriju (testa gadījumu) saraksts ar detalizētu darbību aprakstu. Katru testēšanas scenārija soli raksturo lietotāja (testēšanas speciālista) darbības un sagaidāmie rezultāti - programmas reakcija uz šīm darbībām. Testa programmai un metodikai ir jāmodelē programmatūras produkta darbība reālajā režīmā. Tas nozīmē, ka testēšanas scenārijs ir jāveido, pamatojoties uz operāciju analīzi, ko veiks nākamie sistēmas lietotāji, nevis mākslīgi sastādītu, tikai izstrādātājam saprotamu manipulāciju secību.

Parasti funkcionālo pārbaudi veic divos līmeņos:

• Komponentu (vienību) testēšana. Programmatūras produkta atsevišķu komponentu testēšana, koncentrējoties uz to specifiku, mērķi un funkcionālajām iezīmēm.
• Integrācijas pārbaude. Šāda veida testēšana tiek veikta pēc komponentu testēšanas un ir vērsta uz dažādu apakšsistēmu mijiedarbības defektu noteikšanu vadības plūsmu un datu apmaiņas līmenī.

Nefunkcionāla pārbaude

Nefunkcionālā testēšana novērtē programmatūras produkta īpašības, piemēram, ergonomiku vai veiktspēju.

Es domāju, ka šāda veida testēšanas nozīme ir skaidra, un tai nav nepieciešams pamatojums. Galu galā visi saprot, ka, ja, piemēram, sistēmas veiktspēja nav pietiekama, lietotājiem būs jāgaida puse dienas, lai saņemtu atbildi uz viņu darbībām, kas var izraisīt viņu masveida hibernāciju.

Kā norāda nosaukums, nefunkcionālā testēšana pārbauda programmatūras produkta atbilstību nefunkcionālajām prasībām no tā izveides tehniskajām specifikācijām. Un, tāpat kā funkcionālās testēšanas gadījumā, nefunkcionālajai testēšanai tiek izstrādāta testēšanas programma un metodika.

Iegultās programmatūras testēšana un atbilstība elastīgajā laikmetā

Atbilstību nozares standartiem nevar atstāt novārtā vai darīt vēlāk; tā ir iegultās programmatūras (programmatūras) izstrādes procesa neatņemama sastāvdaļa. Dažām nozarēm, piemēram, aviācijas elektronikai, automobiļu rūpniecībai un veselības aprūpei, stingra kvalitātes standartu ievērošana sarežģītu un bezproblēmu iegulto sistēmu izstrādē ir ļoti svarīga, lai produktu laistu tirgū. Tradicionāli testēšanai ir bijusi svarīga loma iegulto sistēmu izstrādē standartu regulētām nozarēm. Taču pēdējos gados ir būtiski mainījusies iedibinātā testēšanas prakse un procesi, to vieta un loma šādos projektos. Tas bija spēles mainītājs, un, mainoties spēles noteikumiem, jums ir jāmainās ar tiem, lai uzvarētu.

Pastāvīgi attīstoties jaunām, progresīvām tehnoloģijām, uzņēmumiem ātri jāpiedāvā tirgū uzticami, droši, ērti lietojami un ar citām sistēmām savietojami produkti – lai tikai nepazustu strauji mainīgajā tehnoloģiju pasaulē. Šādā situācijā tradicionālais ūdenskrituma modelis, kurā programmatūras izstrādes process notiek stingri secīgi un testēšana tiek veikta pašās beigās, kļūst par pagātni. DevOps un Agile metodes kļūst arvien populārākas, jo tās ļauj inženieriem vienlaikus izpildīt uzdevumus, kas iepriekš sekoja viens otram.

Veiktspējas pārbaude

Veiktspējas pārbaudes posmā pirmais solis ir slodzes pārbaude, kuras mērķis ir pārbaudīt, vai sistēma adekvāti reaģēs uz ārējām ietekmēm režīmā, kas ir tuvu reālai darbībai.

Papildus slodzes testēšanai tiek veikti testi minimālas aparatūras un maksimālās slodzes apstākļos - stresa testēšana, kā arī testi maksimālā apstrādātās informācijas apjoma apstākļos - tilpuma pārbaude.

Ir vēl viens testēšanas veids: stabilitātes un uzticamības pārbaude, kas ietver ne tikai programmatūras produkta ilgtermiņa testēšanu normālos apstākļos, bet arī tā spēju atgriezties normālā darbībā pēc īsiem stresa slodzes periodiem.

Dokumentācija pārbaudei

Kā minēts iepriekš, testēšana tiek veikta saskaņā ar programmu un pārbaudes metodiku, kas izstrādāta saskaņā ar GOST 34.603-92.

Lai veiktu testēšanu, tiek izstrādāts testa gadījums, kurā jāietver pietiekami daudz datu, lai pārbaudītu visus programmatūras produkta darbības režīmus. Parasti pārbaudes gadījumu pasūtītājs un darbuzņēmējs kopīgi izveido, pamatojoties uz reāliem datiem.

Lai veiktu visu veidu veiktspējas testēšanu, visbiežāk tiek izveidots tā sauktais datu ģenerators, kas ļauj automātiski izveidot pietiekamu datu apjomu, lai, novērtējot veiktspēju, sasniegtu objektīvu rezultātu.

Testēšanas laikā tiek sastādīts testēšanas protokols, kurā ir informācija par visu testēšanas posmu un soļu pabeigšanu un testēšanas laikā saņemtie komentāri.

Ja testa rezultāts ir negatīvs, trūkumi tiek novērsti un atkārtoti pārbaudīti.

Izpētes pārbaude

Izpētes testēšana (ad hoc testēšana ir funkcionālās testēšanas apakštips. To izmanto strauji augošos projektos ar elastīgām izstrādes metodēm, kur nav skaidras dokumentācijas un prasības. Izpētes testēšana ir augstākā akrobātika programmatūras testēšanā. Kvalitatīvā pārbaude ir pieejama augsti kvalificēti speciālisti un gandrīz pilnībā ir atkarīgs no izpildītāja, viņa pieredzes, zināšanām (gan priekšmetā, gan testēšanas metodēs), un spējas ātri tikt pie būtības.

Stresa testēšana

Slodzes pārbaude ir testējamās sistēmas veiktspējas analīzes process slodzes laikā. Slodzes pārbaudes mērķis ir noteikt lietojumprogrammas spēju izturēt ārējās slodzes. Parasti pārbaudes tiek veiktas vairākos posmos.

1. Testa skriptu ģenerēšana

Efektīvai analīzei scenārijiem jābūt pēc iespējas tuvākiem faktiskajiem lietošanas gadījumiem. Ir svarīgi saprast, ka izņēmumi vienmēr ir iespējami, un pat visdetalizētākais pārbaudes plāns var neaptvert vienu gadījumu.

2. Testa konfigurācijas izstrāde

Ņemot vērā testa scenārijus, ir svarīgi sadalīt slodzes palielināšanas secību. Veiksmīgai analīzei ir nepieciešams noteikt darbības novērtēšanas kritērijus (atbildes ātrums, pieprasījuma apstrādes laiks utt.).

3. Testa testa veikšana

Veicot testus, ir svarīgi laikus uzraudzīt scenāriju izpildi un pārbaudāmās sistēmas reakciju. Lielu slodžu emulēšanai ir nepieciešama nopietna aparatūras un programmatūras infrastruktūra. Dažos gadījumos tiek izmantotas matemātiskās modelēšanas metodes, lai samazinātu darba izmaksas. Dati, kas iegūti pie zemām slodzēm, tiek ņemti par pamatu un tuvināti. Jo augstāks ir simulētās slodzes līmenis, jo zemāka ir novērtējuma precizitāte. Tomēr šī metode ievērojami samazina izmaksas.

Testēšanas automatizācija

Galvenā automatizētās testēšanas iezīme ir spēja ātri veikt regresijas testus. Galvenās automatizācijas priekšrocības (saskaņā ar Worksoft ziņojumu) ir paaugstināta personāla efektivitāte, agrāka defektu atklāšana un augstāka biznesa procesu kvalitāte. Šīs priekšrocības kompensē būtisks trūkums: augstās izmaksas – testu automatizācijas ieviešanas un atbalsta augsto izmaksu dēļ aptuveni 50% uzņēmumu joprojām izmanto galvenokārt manuālo testēšanu.

Lietojamības pārbaude

Jebkura lietojumprogramma tiek izveidota, lai to varētu izmantot. Lietošanas ērtums ir svarīgs programmas kvalitātes rādītājs. IT nozare zina daudzus piemērus, kad projekti paceļas pēc veiksmīga lietojamības labojuma. Jo plašāka auditorija, jo svarīgāks ir lietojamības faktors. Lietojamības pārbaude ietver detalizētu lietotāja uzvedības analīzi. Lai novērtētu ergonomiku, ir svarīgi, lai būtu dati ne tikai par biznesa uzdevuma izpildes ātrumu, bet arī par lietotāja emocijām, sejas izteiksmēm un balss tembru.

Konfigurācijas pārbaude

Konfigurācijas testēšana sniedz pārliecību, ka lietojumprogramma darbosies dažādās platformās un līdz ar to maksimālajam lietotāju skaitam. WEB lietojumprogrammām parasti tiek izvēlēta starppārlūkprogrammu pārbaude. Windows aplikācijām - testēšana uz dažādām operētājsistēmām un bitu pārraides ātrumiem (x86, x64). Svarīga konfigurācijas testēšanas sastāvdaļa ir testēšanas infrastruktūra: lai veiktu testus, jums pastāvīgi jāuztur testa iekārtu parks. To skaits svārstās no 5 līdz vairākiem desmitiem.

Integrācijas pārbaude

Ja jūsu projektā ir vairāk nekā viens komponents, tam nepieciešama integrācijas pārbaude. Ar sarežģītu lietojumprogrammu arhitektūru nepieciešams kvalitātes nodrošināšanas nosacījums ir programmas daļu mijiedarbības pārbaude. Pārbaude tiek panākta, izstrādājot un veicot “no gala līdz galam” gadījumus. Integrācijas pārbaude tiek veikta pēc komponentu pārbaudes. Tāpēc ir ļoti svarīgi ņemt vērā komponentu testēšanas pieredzi, vienlaikus ievērojot testa gadījumu biznesa orientāciju.

Stresa testēšana

Jebkurai sistēmai ir ierobežojumi tās normālai darbībai. Pārsniedzot limitu, sistēma nonāk stresa stāvoklī un būtiski maina savu uzvedību. Stresa testēšana pārbauda lietojumprogrammas darbību apstākļos, kas pārsniedz parastās darbības robežas. Tas ir īpaši svarīgi “kritiskajām” programmām: banku programmatūrai, aviācijas nozares programmām, medicīnai. Stresa testēšana tiek veikta ne tikai programmatūras izstrādes stadijā, bet arī visa darbības cikla laikā, lai iegūtu un apstrādātu sistēmas uzvedības datus ilgā laika periodā.

Starp visiem veidiem funkcionālā pārbaude pamatoti ieņem vadošo pozīciju, jo programmai vispirms ir jādarbojas pareizi, pretējā gadījumā lietošanas ērtums, drošība un pietiekams ātrums būs absolūti nederīgs. Papildus dažādu testēšanas paņēmienu apguvei katram speciālistam ir jāsaprot, kā pareizi veikt testu, lai iegūtu visefektīvāko rezultātu.

Funkcionālā pārbaude: kur virzīt galvenos centienus?

Vienību un sistēmu testēšanai;

Lai atzīmētu lodziņu “baltais” vai “melnais”;

Manuālai pārbaudei un automatizācijai;

Lai pārbaudītu jaunu funkcionalitāti vai;

“Negatīviem” vai “pozitīviem” testiem.

Starp visām šīm darbības jomām ir svarīgi atrast pareizo ceļu, kas būs “vidus”, lai līdzsvarotu centienus, maksimāli izmantojot katras jomas priekšrocības.

Tiek veikta programmatūras pārbaude Dažādi ceļi, no kuriem viens ir melnās kastes vai datu vadīta pārbaude.

Programma šajā gadījumā tiek prezentēta no “melnās kastes” viedokļa, un tests tiek veikts, lai noteiktu apstākļus, kādos programmas darbība neatbilst specifikācijai. Visas kļūdas tiek identificētas, izmantojot datu pārvaldību, kas tiek veikta, veicot visaptverošu testēšanu, tas ir, izmantojot visu iespējamo

Ja programmai komandas izpilde ir atkarīga no notikumiem pirms tās, tad būs jāpārbauda visas iespējamās secības. Ir pilnīgi skaidrs, ka vairumā gadījumu vienkārši nav iespējams veikt izsmeļošu testēšanu, tāpēc biežāk viņi izvēlas pieņemamu vai saprātīgu iespēju, kas aprobežojas ar programmas palaišanu nelielā visu ievades datu apakškopā. Šī opcija pilnībā garantē nekādas novirzes no specifikācijām.

Funkcionālā pārbaude ietver pareizā testa izvēli. Tajā pašā laikā ir ierasts atšķirt šādas kopu ģenerēšanas metodes:

Robežvērtību analīze;

Līdzvērtīgs nodalījums;

Kļūdas pieņēmums;

Cēloņu un seku saistību analīze.

Jūs varat apsvērt katru no tiem atsevišķi.

Robežvērtību analīze. Robežvērtības parasti tiek saprastas kā tās, kas atrodas uz ekvivalences klašu robežām. Šādās vietās visticamāk tiks atrasta kļūda. Šādas metodes izmantošana prasa no speciālista zināmu radošumu, kā arī specializāciju šajā konkrētajā izskatāmajā problēmā.

Līdzvērtīgs nodalījums. Visas iespējamās ievades parametru kopas ir sadalītas vairākās ekvivalences klasēs. Dati tiek apvienoti, pamatojoties uz līdzīgu kļūdu noteikšanas principu. Ir vispārpieņemts, ka, ja vienas klases kopa uzrāda kļūdu, tad to norādīs arī līdzvērtīgās. Funkcionālā pārbaude, ko veic šī metode tiek veikta divos posmos: pirmajā tiek noteiktas ekvivalences klases, bet otrajā jau tiek veidoti īpaši testi.

Cēloņu un seku attiecību analīze. Sistēma var atlasīt augstas veiktspējas testus, veicot šādas pārbaudes. Šajā gadījumā par cēloni tiek ņemts atsevišķs ievades nosacījums, un izvades nosacījums tiek uzskatīts par efektu. Metodes pamatā ir ideja par visu veidu cēloņu attiecināšanu uz noteiktām sekām, tas ir, uz šo pašu cēloņu un seku attiecību noskaidrošanu. Programmatūras produkta testēšana tiek veikta vairākos posmos, kā rezultātā tiek izveidots cēloņu un no tā izrietošo seku saraksts.

• izstrādātāju neapzinātas novirzes no darba standartiem vai ieviešanas plāniem;
• funkcionālo un interfeisa prasību specifikācijas tiek veiktas, neievērojot izstrādes standartus, kas rada traucējumus programmu darbībā;
• izstrādes procesa organizācija - nepilnīga vai nepietiekama projekta vadītāja resursu (cilvēku, tehnisko, programmatūras u.c.) vadība un projekta elementu testēšanas un integrācijas jautājumi.

Apskatīsim testēšanas procesu, pamatojoties uz ISO/IEC 12207 standarta ieteikumiem, un norādīsim kļūdu veidus, kas tiek atklāti katrā dzīves cikla procesā.

Prasību izstrādes process. Nosakot sākotnējo sistēmas koncepciju un sākotnējās prasības sistēmai, analītiķi pieļauj specifikācijas kļūdas augstākais līmenis sistēmas un priekšmeta jomas konceptuālā modeļa veidošanu.

Tipiskas kļūdas šajā procesā ir:

• prasību specifikācijas neatbilstība gala lietotājiem - nepareiza programmatūras mijiedarbības ar darbības vidi vai ar lietotājiem specifikācija;
• neatbilstība klientu prasībām attiecībā uz atsevišķiem un vispārīgiem programmatūras rekvizītiem;
• nepareizs funkcionālo īpašību apraksts;
• instrumentu trūkums visiem klientu prasību īstenošanas aspektiem utt.

Dizaina process.Kļūdas komponentu projektēšanā var rasties, aprakstot algoritmus, vadības loģiku, datu struktūras, saskarnes, datu plūsmas modelēšanas loģiku, ievades/izvades formātus utt. Šo kļūdu pamatā ir analītiķa specifikāciju defekti un dizaina trūkumi. Tie ietver kļūdas, kas saistītas ar:

• ar lietotāja saskarnes ar vidi definīciju;
• ar funkciju aprakstu (komponentu mērķu un uzdevumu neatbilstība, kas tiek atklāta, pārbaudot komponentu kopu);
• ar informācijas apstrādes procesa definīciju un mijiedarbību starp procesiem (nepareizas komponentu un procesu attiecību noteikšanas rezultāts);
• ar nepareizu datu un to struktūru specifikāciju, aprakstot atsevišķas sastāvdaļas un programmatūru kopumā;
• ar nepareizu moduļu algoritmu aprakstu;
• ar nosacījumu noteikšanu iespējamo kļūdu rašanās programmā;
• pārkāpjot projektā pieņemtos standartus un tehnoloģijas.

Kodēšanas posms.Šajā posmā rodas kļūdas, kas ir dizaina defektu, programmētāju un vadītāju kļūdu rezultāts sistēmas izstrādes un atkļūdošanas laikā. Kļūdu cēloņi ir:

• kontroles trūkums pār ievades parametru vērtībām, masīva indeksiem, cilpas parametriem, izvades rezultātiem, dalīšanu ar 0 utt.;
• nepareiza neregulāru situāciju apstrāde, analizējot atgriešanas kodus no izsauktajām apakšprogrammām, funkcijām utt.;
• kodēšanas standartu pārkāpums (slikti komentāri, neracionāli moduļu piešķiršana un komponents utt.);
• viena nosaukuma izmantošana, lai apzīmētu dažādus objektus vai dažādus viena objekta nosaukumus, slikta nosaukumu mnemonika; - dažādu izstrādātāju nekonsekventas izmaiņas programmā utt.

Pārbaudes process.Šajā procesā kļūdas pieļauj programmētāji un testētāji, veicot montāžas un testēšanas tehnoloģiju, izvēloties testu komplektus un testēšanas scenārijus utt. Šāda veida kļūdu izraisītas programmatūras kļūmes ir jāidentificē, jānovērš un neietekmē komponentu un komponentu statistiku. programmatūras kļūdas kopumā.

Apkopes process.Apkopes procesā tiek atklātas kļūdas, kas radušās ekspluatācijas dokumentācijas nepilnību un defektu, nepietiekamu modificējamības un lasāmības rādītāju, kā arī par programmatūras uzturēšanu un/vai uzlabošanu atbildīgo personu nekompetences dēļ. Atkarībā no veikto izmaiņu rakstura šajā posmā var rasties gandrīz visas kļūdas, kas līdzīgas iepriekš uzskaitītajām kļūdām iepriekšējos posmos.

Visas kļūdas, kas rodas programmās, parasti tiek iedalītas šādās klasēs [7.12]:

• loģiskās un funkcionālās kļūdas;
• aprēķinu un izpildlaika kļūdas;
• ievades/izvades un datu manipulācijas kļūdas;
• saskarnes kļūdas;
• datu apjoma kļūdas utt.

Loģiskas kļūdas ir cēlonis algoritma loģikas pārkāpumam, mainīgo un operatoru iekšējai neatbilstībai, kā arī programmēšanas noteikumiem. Funkcionālās kļūdas ir nepareizi definētu funkciju sekas, to piemērošanas kārtības pārkāpums vai to ieviešanas nepilnības utt.

Aprēķinu kļūdas rodas avota datu un ieviesto formulu neprecizitātes, metožu kļūdu, aprēķinu operāciju vai operandu nepareizas piemērošanas dēļ. Izpildlaika kļūdas ir saistītas ar nespēju nodrošināt nepieciešamo pieprasījumu apstrādes ātrumu vai programmas atkopšanas laiku.

I/O kļūdas un datu manipulācijas ir sekas nekvalitatīvai datu sagatavošanai programmas izpildei, kļūmēm ievadot tos datu bāzēs vai izgūstot no tām.

Interfeisa kļūdas attiecas uz kļūdām atsevišķu elementu savstarpējās attiecībās, kas izpaužas datu pārsūtīšanas laikā starp tiem, kā arī mijiedarbības laikā ar darbības vidi.

Skaļuma kļūdas attiecas uz datiem un ir sekas tam, ka ieviestās piekļuves metodes un datu bāzes izmēri neapmierina reālos sistēmas informācijas apjomus vai to apstrādes intensitāti.

Dotās galvenās kļūdu klases ir raksturīgas dažāda veida programmatūras komponentiem un programmās izpaužas dažādi. Tādējādi, strādājot ar datu bāzi, rodas kļūdas datu prezentācijā un manipulācijās, loģiskās kļūdas piemērojamo datu apstrādes procedūru norādīšanā utt. Aprēķinu programmās dominē skaitļošanas kļūdas, bet vadības un apstrādes programmās dominē loģiskās un funkcionālās kļūdas. Programmatūra, kas sastāv no daudzām dažādām programmām, kas īsteno dažādas funkcijas, var saturēt kļūdas dažādi veidi. Interfeisa kļūdas un skaļuma pārkāpumi ir raksturīgi jebkura veida sistēmām.

Programmu kļūdu veidu analīze ir priekšnoteikums, lai izveidotu pārbaudes plānus un pārbaudes metodes, lai nodrošinātu programmatūras pareizību.

Pašreizējā programmatūras izstrādes atbalsta rīku izstrādes stadijā (CASE tehnoloģijas, objektorientētas metodes un rīki modeļu un programmu projektēšanai) tiek veikta projektēšana, kurā programmatūra ir aizsargāta no visbiežāk sastopamajām kļūdām un tādējādi novērš problēmu rašanos. programmatūras defekti.

Saistība starp kļūdu un neveiksmi.Kļūdas klātbūtne programmā, kā likums, noved pie programmatūras kļūmes tās darbības laikā. Lai analizētu "kļūdas-neveiksmes" cēloņu un seku attiecības, tiek veiktas šādas darbības:

• dizaina un programmēšanas tehnoloģiju trūkumu identificēšana;
• attiecības starp trūkumiem projektēšanas procesā un cilvēka kļūdām;
• kļūmju, nepilnību un iespējamo kļūdu, kā arī defektu klasifikācija katrā izstrādes stadijā - noteiktā izstrādes procesā pieļauto cilvēcisko kļūdu un objekta defektu salīdzinājums, kā rezultātā radušās kļūdas projekta specifikācijā, programmas modeļos;
• verifikācija un kļūdu aizsardzība visos dzīves cikla posmos, kā arī defektu atklāšana katrā izstrādes stadijā;
• programmatūras defektu un kļūmju salīdzināšana, lai izstrādātu starpsavienojumu sistēmu un metodes informācijas par kļūmēm un defektiem lokalizēšanai, apkopošanai un analīzei;
• pieeju izstrāde programmatūras dokumentēšanas un testēšanas procesiem.

Kļūdu un neveiksmju cēloņsakarības galvenais mērķis ir noteikt metodes un līdzekļus noteiktu klašu kļūdu pārbaudei un noteikšanai, kā arī kritērijus vairāku datu kopu testēšanas pabeigšanai; identificējot veidus, kā uzlabot programmatūras izstrādes, testēšanas un uzturēšanas procesa organizāciju.

Šeit ir šāda kļūmju veidu klasifikācija:

• aparatūra, kurā visas sistēmas programmatūra nedarbojas;
• informatīvs, ko izraisa kļūdas ievades datos un datu pārraide pa sakaru kanāliem, kā arī ievadierīču atteices (aparatūras atteices sekas);
• ergonomisks, ko izraisa operatora kļūdas viņa mijiedarbības laikā ar mašīnu (šī kļūme ir sekundāra kļūme un var izraisīt informācijas vai funkcionālus traucējumus);
• programmatūru, ja ir kļūdas komponentos utt.

Dažas kļūdas var rasties prasību definīcijas, dizaina, izvades koda ģenerēšanas vai dokumentācijas nepilnību dēļ. No otras puses, tie tiek ģenerēti programmas izstrādes laikā vai atsevišķu programmas elementu saskarņu izstrādes laikā (parametru secības pārkāpums, mazāk vai vairāk parametru utt.).

Kļūdu avoti.Projekta, komponentu, koda un dokumentācijas izstrādes gaitā var rasties kļūdas. Parasti tie tiek atklāti programmatūras izpildes vai apkopes laikā visnegaidītākajos un atšķirīgākajos punktos.

Dažas kļūdas programmā var būt prasību definīcijas, dizaina, koda ģenerēšanas vai dokumentācijas nepilnību rezultāts. Savukārt kļūdas rodas, izstrādājot programmu vai tās elementu saskarnes (piemēram, ja tiek pārkāpta komunikācijas parametru iestatīšanas kārtība - mazāk vai vairāk, nekā nepieciešams utt.).

Kļūdu iemesls ir klientu prasību neizpratne; neprecīzs prasību precizējums projekta dokumentos uc Tas noved pie tā, ka tiek ieviestas dažas sistēmas funkcijas, kas nedarbosies tā, kā to piedāvā pasūtītājs. Šajā sakarā tiek veikta kopīga diskusija starp pasūtītāju un izstrādātāju par dažām prasību detaļām, lai tās precizētu.

Sistēmas izstrādes komanda var arī mainīt sistēmas apraksta sintaksi un semantiku. Tomēr dažas kļūdas var netikt atklātas (piemēram, šo paziņojumu indeksi vai mainīgās vērtības ir nepareizi iestatītas).