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

Pat ja esat tik iecietīgs, ka pēc kļūmes pusstundas laikā varat restartēt programmu 18 reizes un tikai pēc tam mest monitoru tieši pie loga, piekritīsiet, ka strādāt ar šo programmu būtu ērtāk, ja tā nedarītu “ kritums”.

Kā panākt, lai gadījumi, kad nokrīt, nosalst, netiek veiktas nepieciešamās jūsu izstrādātās programmas darbības, kļūtu ļoti reti?

Uz šo jautājumu nav precīzas atbildes. Taču gadsimtiem ilgi gudrākie zinātnieki par to ir domājuši gadiem ilgi un tomēr spējuši atrast līdzekli, kas ja ne novērš visas programmas kļūdas, tad vismaz rada ilūziju par aktivitāti to novēršanai.

Un šo rīku sauc Programmatūras produktu 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 iekļauts efektīvu rīku komplektā moderna sistēma programmatūras produktu 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 viedokļa. inženieri, mārketinga, apmācību un pārdošanas darbinieki. 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 produkta kvalitātes nodrošināšanas problēmas formulēšanas rezultātā rodas uzdevums apzināt ieinteresētās puses, to kvalitātes kritērijus un pēc tam atrast šiem kritērijiem atbilstošu optimālo risinājumu.

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 tas nav karalisks bizness. Speciāli apmācītiem darbiniekiem, ko sauc par testētājiem, vajadzētu pārbaudīt programmatūras produktu, 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 ir vienisprātis, ka programmatūras produkta testēšana pēc mērķu klasifikācijas ir jāsadala divās klasēs:

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

Funkcionālā pārbaude

Ar funkcionālo testēšanu tiek saprasta programmatūras produkta atbilstības pārbaude šī produkta izveides darba uzdevumā noteiktajām funkcionālajām prasībām. 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 nolēmāt veikt funkcionālo pārbaudi. Apskati darba uzdevumu, izlasi funkcionālās prasības un saproti, ka tās vismaz nav tādā secībā, kādā var pārbaudīt. Jūs būsiet pārsteigts, ka jau sen citi ir pamanījuši šo neatbilstību un izdomājuši, kā to pārvarēt.

Lai veiktu funkcionālo testēšanu, tehniskās kontroles nodaļas darbinieki izstrādā dokumentu programmu un lietojumprogrammas funkcionalitātes (API) testēšanas metodi. PMI dokumentā ir saraksts ar programmatūras produktu testēšanas scenārijiem (testa gadījumiem) ar Detalizēts apraksts soļi. Katru testa scenārija soli raksturo lietotāja (testēšanas speciālista) darbības un sagaidāmie rezultāti – programmas reakcija uz šīm darbībām. Programmai un testa metodikai ir jāmodelē programmatūras produkta darbība reālajā režīmā. Tas nozīmē, ka testa skripts ir jāveido, pamatojoties uz to darbību analīzi, kuras veiks nākamie sistēmas lietotāji, nevis mākslīgi apkopota 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ē tādas programmatūras produkta īpašības kā, piemēram, ergonomika vai veiktspēja.

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 novest pie viņu masveida ziemas guļas.

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 programma un testēšanas metodika.

Iegultās programmatūras testēšana un atbilstība veiklības laikmetā

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

Tā kā jaunas, vismodernākās tehnoloģijas nepārtraukti attīstās, uzņēmumiem ātri jāievieš tirgū produkti, kas ir uzticami, droši, viegli lietojami un savietojami, lai tie nepazustu ātrā tempā. tehnoloģiju pasaule. Šādā situācijā tradicionālais ūdenskrituma modelis, kurā programmatūras izstrādes process notiek stingri secīgi un testēšana tiek veikta pašās tā beigās, kļūst par pagātni. DevOps un Agile metodes kļūst arvien populārākas, jo tās ļauj inženieriem veikt uzdevumus, kas agrāk sekoja viens otram vienlaikus.

Veiktspējas pārbaude

Veiktspējas testēšanas fāzē, pirmkārt, tiek veikta 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ālajam darbības režīmam pietuvinātā režīmā.

Papildus slodzes testēšanai tiek veikti testi minimālās 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 - apjoma pārbaude.

Ir vēl viens testēšanas veids: stabilitātes un uzticamības testēšana, kas ietver ne tikai programmatūras produkta ilgstošu pārbaudi normālos apstākļos, bet arī tā spēju atgriezties normālā darbībā pēc īslaicīgām stresa slodzēm.

Dokumentācija pārbaudei

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

Izstrādāts testēšanai 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 pietiekami daudz datu, lai sasniegtu objektīvu rezultātu, novērtējot veiktspēju.

Testēšanas laikā tiek sastādīts testēšanas protokols, kurā tiek ievadīta informācija par visu testēšanas posmu un posmu norisi un pārbaužu laikā saņemtajiem komentāriem.

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šsuga. 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 programmatūras testēšanas virsotne. Ir pieejama augstas kvalitātes testēšana augsti kvalificētiem speciālistiem 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), spējas ātri iekļūt būtībā.

Stresa testēšana

Slodzes pārbaude ir testējamās sistēmas veiktspējas analīzes process slodžu ietekmē. 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 reālajiem 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 izcelt 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 savlaicīgi uzraudzīt skriptu izpildi un pārbaudāmās sistēmas reakciju. Lai atdarinātu lielas slodzes, 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 tiek 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.

Testa 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 uzturēšanas augsto izmaksu dēļ aptuveni 50% uzņēmumu joprojām izmanto galvenokārt manuālo testēšanu.

Lietojamības pārbaude

Katra lietotne ir paredzēta lietošanai. 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āju 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 aplikācija darbosies dažādās platformās, kas nozīmē maksimālo lietotāju skaitu. WEB lietojumprogrammām parasti tiek izvēlēta vairāku pārlūkprogrammu saderības pārbaude. Windows lietojumprogrammām - testēšana uz dažādām operētājsistēmas un bitness (x86, x64). Svarīga konfigurācijas testēšanas sastāvdaļa ir testēšanas infrastruktūra: testēšanai ir 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 pārbaudīt mijiedarbību starp programmas daļām. Testēšana tiek panākta, izstrādājot un veicot "caur" 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 veiktspēju normālās darbības robežu pārsniegšanas apstākļos. Tas ir īpaši svarīgi "kritiskajām" programmām: banku programmatūrai, aviācijas nozares programmām un medicīnai. Stresa testēšana tiek veikta ne tikai programmatūras izstrādes stadijā, bet arī visā darbības ciklā, lai iegūtu un apstrādātu datus par sistēmas uzvedību 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 iegūtu 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-data, vai man jāpārbauda, ​​vai nav datu par 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 ievadīto lietotāja ID.

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 iegūtu 3 dažādu veidu kartes.

Kāda ieviešanas detaļa jums nevajadzētu ignorēt testā. Viss, ko jūs pārbaudāt, ir tas, ka jūsu darba vienība (šī metode) veic 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 nāksies ņirgāties 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), padarīt testu koncentrētu uz prasībām un pragmatismu.

Galu galā šis ir svarīgs kods. Ir testi, lai dublētu faktisko kodu, daudz laika tērēšana un apgrūtinājumi, lai pārbaudītu pulēšanu, nav tik noderīgi kā testi padarot .

Vienību testēšanā jums vajadzētu pārbaudīt tikai vienas klases funkcionalitāti, 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, kas 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āizveido izstrādātājiem. Integrācijas testi parasti noveco salīdzinoši ātri (ja tādi ir iekšējā sastāvdaļa ir mainīts), tāpēc tos ir grūtāk izpildīt. Jāizveido, izmantojot kvalitātes nodrošināšanas profilu.

Pat ja esat tik iecietīgs, ka pēc kļūmes pusstundas laikā varat restartēt programmu 18 reizes un tikai pēc tam mest monitoru tieši pie loga, piekritīsiet, ka strādāt ar šo programmu būtu ērtāk, ja tā nedarītu “ kritums”.

Kā panākt, lai gadījumi, kad nokrīt, nosalst, netiek veiktas nepieciešamās jūsu izstrādātās programmas darbības, kļūtu ļoti reti?

Uz šo jautājumu nav precīzas atbildes. Taču gadsimtiem ilgi gudrākie zinātnieki par to ir domājuši gadiem ilgi un tomēr spējuši atrast līdzekli, kas ja ne novērš visas programmas kļūdas, tad vismaz rada ilūziju par aktivitāti to novēršanai.

Un šo rīku sauc Programmatūras produktu 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 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 viedokļa. inženieri, mārketinga, apmācību un pārdošanas darbinieki. 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 produkta kvalitātes nodrošināšanas problēmas formulēšanas rezultātā rodas uzdevums apzināt ieinteresētās puses, to kvalitātes kritērijus un pēc tam atrast šiem kritērijiem atbilstošu optimālo risinājumu.

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 tas nav karalisks bizness. Speciāli apmācītiem darbiniekiem, ko sauc par testētājiem, vajadzētu pārbaudīt programmatūras produktu, 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 ir vienisprātis, ka programmatūras produkta testēšana pēc mērķu klasifikācijas ir jāsadala divās klasēs:

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

Funkcionālā pārbaude

Ar funkcionālo testēšanu tiek saprasta programmatūras produkta atbilstības pārbaude šī produkta izveides darba uzdevumā noteiktajām funkcionālajām prasībām. 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 nolēmāt veikt funkcionālo pārbaudi. Apskati darba uzdevumu, izlasi funkcionālās prasības un saproti, ka tās vismaz nav tādā secībā, kādā var pārbaudīt. Jūs būsiet pārsteigts, ka jau sen citi ir pamanījuši šo neatbilstību un izdomājuši, kā to pārvarēt.

Lai veiktu funkcionālo testēšanu, tehniskās kontroles nodaļas darbinieki izstrādā dokumentu programmu un lietojumprogrammas funkcionalitātes (API) testēšanas metodi. PMI dokumentā ir programmatūras produktu testēšanas scenāriju (testa gadījumu) saraksts ar detalizētu darbību aprakstu. Katru testa scenārija soli raksturo lietotāja (testēšanas speciālista) darbības un sagaidāmie rezultāti – programmas reakcija uz šīm darbībām. Programmai un testa metodikai ir jāmodelē programmatūras produkta darbība reālajā režīmā. Tas nozīmē, ka testa skripts ir jāveido, pamatojoties uz to darbību analīzi, kuras veiks nākamie sistēmas lietotāji, nevis mākslīgi apkopota 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. Šā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ē tādas programmatūras produkta īpašības kā, piemēram, ergonomika vai veiktspēja.

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 novest pie viņu masveida ziemas guļas.

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

Iegultās programmatūras testēšana un atbilstība veiklības laikmetā

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

Tā kā jaunas, vismodernākās tehnoloģijas nepārtraukti attīstās, uzņēmumiem ātri jāievieš tirgū produkti, kas ir uzticami, droši, viegli lietojami un savietojami, lai tie nepazustu ātrā tempā. tehnoloģiju pasaule. Šādā situācijā tradicionālais ūdenskrituma modelis, kurā programmatūras izstrādes process notiek stingri secīgi un testēšana tiek veikta pašās tā beigās, kļūst par pagātni. DevOps un Agile metodes kļūst arvien populārākas, jo tās ļauj inženieriem veikt uzdevumus, kas agrāk sekoja viens otram vienlaikus.

Veiktspējas pārbaude

Veiktspējas testēšanas fāzē, pirmkārt, tiek veikta 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ālajam darbības režīmam pietuvinātā režīmā.

Papildus slodzes testēšanai tiek veikti testi minimālās 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 - apjoma pārbaude.

Ir vēl viens testēšanas veids: stabilitātes un uzticamības testēšana, kas ietver ne tikai programmatūras produkta ilgstošu pārbaudi normālos apstākļos, bet arī tā spēju atgriezties normālā darbībā pēc īslaicīgām stresa slodzēm.

Dokumentācija pārbaudei

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

Testēšanai tiek izstrādāts testa gadījums, kurā jābūt 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.

Visu veidu veiktspējas testu veikšanai visbiežāk tiek izveidots tā sauktais datu ģenerators, kas ļauj automātiski izveidot pietiekamu datu apjomu, lai, izvērtējot veiktspēju, sasniegtu objektīvu rezultātu.

Testēšanas laikā tiek sastādīts testēšanas protokols, kurā tiek ievadīta informācija par visu testēšanas posmu un posmu norisi un pārbaužu laikā saņemtajiem komentāriem.

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šsuga. 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 programmatūras testēšanas virsotne. Ir pieejama augstas kvalitātes testēšana augsti kvalificētiem speciālistiem 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), spējas ātri iekļūt būtībā.

Stresa testēšana

Slodzes pārbaude ir testējamās sistēmas veiktspējas analīzes process slodžu ietekmē. 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 reālajiem 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 izcelt 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 savlaicīgi uzraudzīt skriptu izpildi un pārbaudāmās sistēmas reakciju. Lai atdarinātu lielas slodzes, 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 tiek 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.

Testa 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 uzņēmuma pārskatu) 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 uzturēšanas augsto izmaksu dēļ aptuveni 50% uzņēmumu joprojām izmanto galvenokārt manuālo testēšanu.

Lietojamības pārbaude

Katra lietotne ir paredzēta lietošanai. 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āju 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 aplikācija darbosies dažādās platformās, kas nozīmē maksimālo lietotāju skaitu. WEB lietojumprogrammām parasti tiek izvēlēta vairāku pārlūkprogrammu saderības pārbaude. Windows aplikācijām - testēšana uz dažādām operētājsistēmām un bitness (x86, x64). Svarīga konfigurācijas testēšanas sastāvdaļa ir testēšanas infrastruktūra: testēšanai ir 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 pārbaudīt mijiedarbību starp programmas daļām. Testēšana tiek panākta, izstrādājot un veicot "caur" 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 normālas darbības ierobežojums. Pārsniedzot limitu, sistēma nonāk stresa stāvoklī un būtiski maina savu uzvedību. Stresa testēšana pārbauda lietojumprogrammas veiktspēju normālās darbības robežu pārsniegšanas apstākļos. Tas ir īpaši svarīgi "kritiskajām" programmām: banku programmatūrai, aviācijas nozares programmām un medicīnai. Stresa testēšana tiek veikta ne tikai programmatūras izstrādes stadijā, bet arī visā darbības ciklā, lai iegūtu un apstrādātu datus par sistēmas uzvedību ilgā laika periodā.

Starp visiem funkcionālās pārbaudes veidiem tā pamatoti ieņem vadošo pozīciju, jo programmai, pirmkārt, ir jādarbojas pareizi, pretējā gadījumā no lietošanas vienkāršības, drošības un pietiekama ātruma nebūs nekādas jēgas. Papildus dažādu testēšanas paņēmienu apguvei katram speciālistam ir jāsaprot, kā pareizi testēt, 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 ;

Par "negatīviem" vai "pozitīviem" testiem.

Starp visām šīm darbības jomām ir svarīgi atrast pareizo ceļu, kas būs "vidējais", 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 testēšana.

Programma šajā gadījumā tiek prezentēta no "melnās kastes" viedokļa, un tests tiek veikts, lai noskaidrotu apstākļus, kādos programmas darbība neatbildīs specifikācijai. Visas kļūdas nosaka datu pārvaldība, kas tiek veikta ar izsmeļošas pārbaudes palīdzību, tas ir, izmantojot visas iespējamās

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 ir vienkārši neiespējami 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ē noviržu neesamību no specifikācijām.

Funkcionālā pārbaude ietver pareizu testa izvēli. Tajā pašā laikā ir ierasts atšķirt šādas komplektu veidošanas metodes:

Robežvērtību analīze;

Līdzvērtīgs nodalījums;

Kļūdas minējums;

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 pēc līdzīgu kļūdu noteikšanas principa. Ir vispārpieņemts, ka, ja vienas klases kopa konstatē kļūdu, tad līdzvērtīgas arī uz to norāda. Funkcionālā pārbaude, ko veic šī metode tiek veikta divos posmos: pirmajā tiek atlasītas ekvivalences klases, bet otrajā jau tiek veidoti īpaši testi.

Cēloņu un seku attiecību analīze. Pateicoties šādām pārbaudēm, sistēma var atlasīt testus ar augstu veiktspēju. Šajā gadījumā par iemeslu tiek uzskatīts atsevišķs ievades nosacījums, un izvades nosacījums tiek uzskatīts par sekām. 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 seku saraksts.

• izstrādātāju netīša novirze no darba standartiem vai ieviešanas plāniem;
• funkcionālo un interfeisa prasību specifikācijas tiek izpildītas, neievērojot izstrādes standartus, kas rada traucējumus programmu darbībā;
• izstrādes procesa organizācija - projekta vadītāja nepilnīga vai nepietiekama 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 uzskaitīsim kļūdu veidus, kas tiek atrasti 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, specifikācijas laikā rodas analītiķa kļūdas augstākais līmenis sistēmas un priekšmeta jomas konceptuālā modeļa veidošanu.

Tipiskas šī procesa kļūdas ir:

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

Projektēšanas process.Kļūdas komponentu projektēšanā var rasties, aprakstot algoritmus, vadības loģiku, datu struktūras, saskarnes, datu plūsmu modelēšanas loģiku, ievades-izejas formātus utt. Šo kļūdu pamatā ir analītiķu specifikāciju defekti un dizaineru 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 konstatēta, pārbaudot komponentu kompleksu);
• ar informācijas apstrādes procesa un procesu mijiedarbības definīciju (nepareizas sastāvdaļu un procesu attiecību definēšanas rezultāts);
• ar nepareizu datu un to struktūru piešķiršanu atsevišķu komponentu aprakstā un PS kopumā;
• ar nepareizu moduļu algoritmu aprakstu;
• ar iespējamo kļūdu rašanās nosacījumu definēšanu 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 procesā. 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 un tā paša nosaukuma lietoš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ģijas, izvēloties testa komplektus un testēšanas scenārijus utt. Šādu kļūdu izraisītas programmatūras kļūmes ir jāatklāj, jānovērš un neatspoguļo komponentu un programmatūras kļūdu statistikā. vispār.

Apkopes process.Apkopes procesā tiek konstatētas kļūdas, ko izraisa nepilnības un defekti ekspluatācijas dokumentācijā, nepietiekami modificējamības un lasāmības rādītāji, kā arī par programmatūras uzturēšanu un/vai uzlabošanu atbildīgo personu nekompetence. 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;
• I/O un datu manipulācijas kļūdas;
• saskarnes kļūdas;
• datu apjoma kļūdas utt.

Loģikas 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 rezultāts, 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ēļ. Izpildes laika kļūdas ir saistītas ar nespēju nodrošināt nepieciešamo vaicājumu apstrādes ātrumu vai programmas atkopšanas laiku.

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

Interfeisa kļūdas attiecas uz kļūdām atsevišķu elementu savstarpējā savienojumā, kas izpaužas, pārsūtot datus starp tiem, kā arī mijiedarbojoties ar funkcionējošo 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ātad, strādājot ar datu bāzi, ir kļūdas datu prezentācijā un manipulācijās, loģiskās kļūdas pielietoto datu apstrādes procedūru uzdevumā utt. Aprēķinu kļūdas dominē skaitļošanas programmās, bet loģiskās un funkcionālās kļūdas vadības un apstrādes programmās. Programmatūra, kas sastāv no daudzām dažādām programmām, kas ievieš dažādas funkcijas, var saturēt kļūdas. dažādi veidi. Interfeisa kļūdas un darbības jomas pārkāpumi ir izplatīti 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 (CASE tehnoloģijas, objektorientētas metodes un modeļu un programmu projektēšanas rīki) izstrādes stadijā tiek veikta tāda projektēšana, kurā programmatūra ir aizsargāta no visbiežāk sastopamajām kļūdām un tādējādi novērš programmatūras defektu parādīšanās.

Kļūdas saistīšana ar kļūmi.Kļūdas klātbūtne programmā, kā likums, noved pie programmatūras kļūmes tās darbības laikā. Lai analizētu cēloņu un seku attiecības "kļūda-neveiksme", 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, defektu 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, kas radušies kļūdu rezultātā projekta specifikācijā, programmas modeļos;
• pārbaude un aizsardzība pret kļūdām visos dzīves cikla posmos, kā arī defektu noteikšana katrā attīstības 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ācijai, apkopošanai un analīzei;
• pieeju izstrāde programmatūras dokumentācijas un testēšanas procesiem.

Kļūdu-neatteices cēloņsakarības galīgais mērķis ir noteikt metodes un rīkus noteiktu klašu kļūdu pārbaudei un noteikšanai, kā arī kritērijus datu kopu testēšanas pabeigšanai; nosakot veidus, kā uzlabot programmatūras izstrādes, testēšanas un uzturēšanas procesa organizāciju.

Mēs sniedzam šādu bojājumu veidu klasifikāciju:

• aparatūra, kurā nedarbojas visas sistēmas programmatūra;
• informatīvs, ko izraisa kļūdas ievades datos un datu pārraide pa sakaru kanāliem, kā arī ievades ierīču kļūmes (aparatūras kļūmju sekas);
• ergonomisks, ko izraisa operatora kļūdas, mijiedarbojoties ar mašīnu (šī kļūme ir sekundāra kļūme, kas var izraisīt informatīvas vai funkcionālas kļūmes);
• programmatūru, ja komponentos ir kļūdas 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 dažādos tās punktos.

Dažas programmas kļūdas var būt prasību definīcijas, dizaina, koda ģenerēšanas vai dokumentācijas nepilnības. Savukārt kļūdas rodas programmas vai tās elementu interfeisu izstrādes laikā (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 parādīšanās iemesls ir nepareiza izpratne par klienta prasībām; 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ā pasūtītājs iesaka. Šajā sakarā starp pasūtītāju un izstrādātāju notiek kopīga diskusija par dažām detaļām par prasībām to precizēšanai.

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