Sistēmas testēšana ir programmatūras testēšanas veids, kas veic visas sistēmas pārbaudes.
Tā ietver visu izstrādāto programmatūras moduļu un komponentu integrēšanu, lai pārbaudītu, vai sistēma darbojas kopā, kā paredzēts.
Sistēmas testēšana ir būtisks programmatūras testēšanas posms, kas ļaus testēšanas komandām pārbaudīt izveides kvalitāti, pirms tā tiek nodota galalietotājiem.
Šajā rakstā aplūkosim sistēmas testēšanu: kas tā ir, kā tā darbojas, kas veic sistēmas testēšanu un kādas pieejas un rīkus testēšanas komandas var izmantot, lai padarītu sistēmas testēšanu ātrāku un uzticamāku.
Īsumā, šeit atradīsiet visu, kas jums jāzina par sistēmas testēšanu.
Kas ir sistēmas testēšana?
Sistēmas testēšana ir programmatūras testēšanas veids, kas vienmēr tiek veikta visai sistēmai. Tā pārbauda, vai sistēma atbilst tās prasībām neatkarīgi no tā, kādas tās ir.
Testētāji veic sistēmas testēšanu, lai novērtētu gan sistēmas funkcionālās, gan nefunkcionālās prasības pēc atsevišķu moduļu un komponentu integrēšanas.
Sistēmas testēšana ir melnās kastes testēšanas kategorija, kas nozīmē, ka tā testē tikai programmatūras ārējās darbības funkcijas, nevis testē lietojumprogrammas iekšējo konstrukciju.
Testētājiem nav nepieciešamas zināšanas par programmatūras koda programmēšanu un struktūru, lai sistēmas testēšanas laikā pilnībā novērtētu programmatūras izveidi. Tā vietā testētāji vienkārši novērtē programmatūras veiktspēju no lietotāja viedokļa.
1. Kad jāveic sistēmas testēšana?
Sistēmas testēšana tiek veikta pēc integrācijas testēšanas un pirms pieņemšanas testēšanas. Sistēmas testēšanu regulāri veic programmatūras testēšanas komanda, lai nodrošinātu, ka sistēma galvenajos izstrādes posmos darbojas, kā tai vajadzētu.
Daži piemēri, kad tiek veikta sistēmas testēšana:
● Jaunu programmatūras versiju izstrādes laikā.
● lietojumprogrammas palaišanas laikā, kad notiek alfa un beta testēšana.
● Pēc vienības un integrācijas testēšanas pabeigšanas.
● Kad sistēmas izveides prasības ir izpildītas.
● Ja ir izpildīti citi testēšanas nosacījumi.
Tāpat kā citus programmatūras testēšanas veidus, ir ieteicams regulāri veikt sistēmas testēšanu, lai pārliecinātos, ka programmatūra darbojas, kā tai vajadzētu.
Sistēmas testēšanas biežums ir atkarīgs no jūsu komandas resursiem un pieejām un rīkiem, ko izmantojat, lai veiktu sistēmas programmatūras testēšanu.
2. Kad nav nepieciešami sistēmas testi
Ja vēl neesat veicis sākotnējos testus, piemēram, ” dūmu” testus, vienības testus un integrācijas testus, tad neesat gatavs sākt sistēmas testēšanu.
Vienmēr ir svarīgi veikt sistēmas testēšanu pēc integrācijas testēšanas pabeigšanas, bet, ja rodas kļūdas un problēmas, kuru dēļ sistēmas tests neizdodas, varat pārtraukt sistēmas testēšanu un atgriezties pie izstrādes un kļūdu novēršanas, pirms turpināt darbu.
3. Kas ir iesaistīts sistēmas testēšanā?
Sistēmas testēšanu veic testētāji un QA komandas, nevis izstrādātāji. Sistēmas testēšanā tiek ņemti vērā tikai programmatūras ārējie elementi jeb, citiem vārdiem sakot, lietotāju pieredze, mēģinot piekļūt programmatūras funkcijām.
Tas nozīmē, ka testētājiem, kuri veic sistēmu testēšanu, nav nepieciešamas nekādas tehniskās zināšanas par datorkodēšanu, programmēšanu un citiem programmatūras izstrādes aspektiem, kas varētu prasīt izstrādātāju ieguldījumu.
Vienīgais izņēmums ir automatizēta sistēmas testēšana, kas var prasīt zināmu izstrādātāju ieguldījumu atkarībā no tā, kā jūs to veicat.
Ko mēs testējam, veicot sistēmas testēšanu?
Sistēmas testēšana ir programmatūras testēšanas veids, ko izmanto, lai pārbaudītu gan programmatūras funkcionālos, gan nefunkcionālos aspektus.
To var izmantot, lai pārbaudītu ļoti dažādas funkcijas un iezīmes, no kurām daudzas ir sīkāk aprakstītas sadaļā “Sistēmas testēšanas veidi”.
Daži no programmatūras aspektiem, kurus pārbauda ar sistēmas testēšanu, ir sīkāk aprakstīti turpmāk.
1. Funkcionalitāte
Testētāji izmanto sistēmas testēšanu, lai pārbaudītu, vai dažādi pabeigtas sistēmas aspekti darbojas, kā tiem vajadzētu.
Iepriekšējo testēšanu var izmantot, lai novērtētu iekšējā koda struktūru un loģiku, kā arī dažādu moduļu savstarpējo integrāciju, taču sistēmas testēšana ir pirmais solis, kas šādi pārbauda programmatūras funkcionalitāti kopumā.
2. Integrācija
Sistēmas testēšana pārbauda, kā dažādas programmatūras sastāvdaļas darbojas kopā un vai tās ir savstarpēji integrētas.
Testētāji var testēt arī ārējās perifērijas ierīces, lai novērtētu, kā tās mijiedarbojas ar programmatūru un vai tās darbojas pareizi.
3. Gaidāmā produkcija
Testētāji izmanto programmatūru tāpat kā lietotājs sistēmas testēšanas laikā, lai pārbaudītu programmatūras rezultātus parastas lietošanas laikā. Tie pārbauda, vai katras programmatūras funkcionālās un nefunkcionālās funkcijas rezultāti ir atbilstoši gaidītajam.
Ja programmatūra nedarbojas tā, kā tai vajadzētu, ir acīmredzams secinājums, ka tai ir nepieciešams papildu izstrādes darbs.
4. Kļūdas un kļūdas
Sistēmas testēšanu izmanto, lai novērtētu programmatūras funkcionalitāti un uzticamību vairākās platformās un operētājsistēmās.
Sistēmas testētāji pārbauda, vai programmatūrā nav kļūdu, veiktspējas problēmu un savietojamības problēmu visās platformās, kurās programmatūru paredzēts izmantot.
Ieejas un izejas kritēriji
Ieejas un izejas kritērijus izmanto sistēmas testos, lai noteiktu, vai sistēma ir vai nav gatava sistēmas testēšanai un vai ir vai nav izpildītas sistēmas testēšanas prasības.
Citiem vārdiem sakot, ieejas un izejas kritēriji palīdz testētājiem novērtēt, kad jāsāk un kad jāpabeidz sistēmas testēšana.
Ieejas kritēriji
Ieejas kritēriji nosaka, kad testētājiem jāuzsāk sistēmas testēšana.
Ieejas kritēriji dažādos projektos var atšķirties atkarībā no testēšanas mērķa un izmantotās testēšanas stratēģijas.
Ieejas kritēriji norāda nosacījumus, kas jāizpilda pirms sistēmas testēšanas uzsākšanas.
1. Testēšanas posms
Vairumā gadījumu ir svarīgi, lai testējamā sistēma jau būtu pabeigusi integrācijas testēšanu un atbilstu integrācijas testēšanas izejas prasībām pirms sistēmas testēšanas uzsākšanas.
Integrācijas testēšanā nedrīkstēja atklāt būtiskas kļūdas vai problēmas ar komponentu integrāciju.
2. Plāni un scenāriji
Pirms sistēmas testēšana var sākties, testa plānam jābūt uzrakstītam, parakstītam un apstiprinātam.
Jums būs arī iepriekš jāsagatavo testēšanas gadījumi, kā arī jāizstrādā testēšanas skripti, kas būs gatavi izpildei.
3. Gatavība
Pārbaudiet, vai testēšanas vide ir gatava un vai ir pieejamas visas testa nefunkcionālās prasības.
Gatavības kritēriji dažādos projektos var atšķirties.
Iziešanas kritēriji
Iziešanas kritēriji nosaka sistēmas testēšanas beigu posmu un nosaka prasības, kas jāizpilda, lai sistēmas testēšana tiktu uzskatīta par pabeigtu.
Iziešanas kritēriji bieži vien tiek iesniegti kā vienots dokuments, kurā vienkārši norādīti šīs testēšanas fāzes rezultāti.
1. Izpilde
Svarīgākais sistēmas testēšanas pabeigšanas kritērijs ir tas, ka visi sistēmas testēšanas plānos aprakstītie testēšanas gadījumi un ieejas kritēriji ir pareizi izpildīti.
2. Kļūdas
Pirms izejat no sistēmas testēšanas, pārbaudiet, vai nav atvērta neviena kritiska vai prioritāra kļūda.
Vidējas un zemas prioritātes kļūdas var atstāt atvērtā stāvoklī, ja tās tiek ieviestas ar klienta vai galalietotāja piekrišanu.
3. Ziņošana
Pirms sistēmas testēšanas beigām jāiesniedz izejas ziņojums. Šajā ziņojumā ir apkopoti sistēmas testu rezultāti un pierādīts, ka testēšana ir izpildījusi nepieciešamos izejas kritērijus.
Sistēmas testēšanas dzīves cikls
Sistēmas testēšanas dzīves cikls apraksta katru sistēmas testēšanas posmu no plānošanas posma līdz ziņošanai un pabeigšanai.
Izpratne par katru sistēmas testēšanas dzīves cikla posmu palīdzēs jums saprast, kā veikt sistēmas testēšanu un kā tā darbojas.
1. posms: Izveidojiet testēšanas plānu
Sistēmas testēšanas pirmais posms ir sistēmas testēšanas plāna izveide.
Testēšanas plāna mērķis ir izklāstīt testēšanas gadījumu gaidas, kā arī testēšanas stratēģiju.
Testēšanas plānā parasti tiek definēti testēšanas mērķi un uzdevumi, darbības joma, jomas, sasniedzamie rezultāti, grafiks, ieejas un izejas kritēriji, testēšanas vide, kā arī programmatūras sistēmas testēšanā iesaistīto cilvēku lomas un pienākumi.
2. posms: Izveidojiet testa gadījumus
Nākamais sistēmas testēšanas posms ir testa gadījumu izveide.
Testēšanas gadījumi nosaka precīzas funkcijas, raksturlielumus un rādītājus, kurus testēsiet sistēmas testēšanas laikā. Piemēram, varat pārbaudīt, kā darbojas kāda konkrēta funkcija vai cik ilgs ir noteikts ielādes laiks.
Katram testa gadījumam norādiet testa gadījuma ID un nosaukumu, kā arī informāciju par to, kā pārbaudīt šo scenāriju un kāds ir testa gadījuma gaidāmais rezultāts.
Šeit varat arī izklāstīt katra testa gadījuma apstiprināšanas/neapstiprināšanas kritērijus.
3. posms: Testa datu izveide
Kad esat izveidojis testēšanas gadījumus, varat izveidot testēšanas datus, kas būs nepieciešami, lai veiktu testus.
Testa dati apraksta ievades datus, kas testēšanas komandai būs nepieciešami, lai pārbaudītu, vai tās darbības rada gaidītos rezultātus.
4. posms: Izpildīt testa gadījumus
Šis posms ir tas, ko lielākā daļa cilvēku, domājot par sistēmas testēšanu, var iedomāties: testa gadījumu izpilde vai pati testēšana.
Testēšanas komanda izpildīs katru testa gadījumu atsevišķi, vienlaikus uzraugot katra testa rezultātus un reģistrējot visas konstatētās kļūdas vai defektus.
5. posms: Ziņošana un kļūdu labošana
Pēc testēšanas gadījumu izpildes testētāji sagatavo sistēmas testēšanas ziņojumu, kurā sīki aprakstītas visas testēšanas laikā radušās problēmas un kļūdas.
Dažas no pārbaudē atklātajām kļūdām var būt nelielas un viegli novēršamas, bet citas var kavēt salikšanas procesu. Pēc kļūdu novēršanas un atkārtot testēšanas ciklu (kas ietver arī citus programmatūras testēšanas veidus, piemēram, ” dūmu” testēšanu), līdz tas tiek veikts bez būtiskām kļūdām.
Neskaidrību novēršana: Sistēmas testēšana vs integrācijas testēšana vs lietotāja pieņemšanas testēšana
Daudzi cilvēki jauc sistēmas testēšanu ar citiem programmatūras testēšanas veidiem, piemēram, integrācijas testēšanu un lietotāju pieņemšanas testēšanu.
Lai gan sistēmas testēšanai, integrācijas testēšanai un lietotāja pieņemšanas testēšanai ir dažas kopīgas iezīmes, tie ir dažādi testēšanas veidi, kas kalpo dažādiem mērķiem, un katrs testēšanas veids ir jāveic neatkarīgi no citiem.
Kas ir integrācijas testēšana?
Integrācijas testēšana ir programmatūras testēšanas veids, kurā programmatūras moduļi un komponenti tiek testēti kā grupa, lai novērtētu, cik labi tie ir integrēti kopā.
Integrācijas testēšana ir pirmais programmatūras testēšanas veids, ko izmanto, lai pārbaudītu atsevišķu moduļu savstarpējo darbību.
Integrācijas testēšanu veic testētāji QA vidē, un tā ir būtiska, jo tā atklāj defektus, kas var rasties, kad atsevišķi kodētas sastāvdaļas mijiedarbojas kopā.
Kādas ir atšķirības starp sistēmas testēšanu un integrācijas testēšanu?
Lai gan gan sistēmas testēšana, gan integrācijas testēšana testē programmatūras kopumu kopumā, tie ir dažādi programmatūras testēšanas veidi, kas darbojas atšķirīgi.
Vispirms tiek veikta integrācijas testēšana, bet pēc integrācijas testēšanas tiek veikta sistēmas testēšana. Citas galvenās atšķirības starp sistēmas testēšanu un integrācijas testēšanu ir šādas:
1. Mērķis:
Integrācijas testēšanas mērķis ir novērtēt, vai integrētie moduļi pareizi darbojas kopā. Sistēmas testēšanas mērķis ir pārbaudīt, kā sistēma darbojas kopumā.
2. Veids:
Integrācijas testēšana pārbauda tikai funkcionalitāti, un tā nav akcepttestēšanas veids.
Turpretī sistēmas testēšana pārbauda gan funkcionālās, gan nefunkcionālās funkcijas, un tā ietilpst pieņemšanas testēšanas kategorijā (bet ne lietotāja pieņemšanas testēšanā).
3. Tehnika:
Integrācijas testēšanā izmanto gan melnās kastes, gan baltās kastes testēšanu, lai novērtētu programmatūras izveidi gan no lietotāja, gan izstrādātāja perspektīvas, savukārt sistēmas testēšanā izmanto tikai melnās kastes testēšanas metodes, lai testētu programmatūru no lietotāja perspektīvas.
4. Vērtība:
Integrācijas testēšanu izmanto, lai identificētu saskarnes kļūdas, bet sistēmas testēšanu izmanto, lai identificētu sistēmas kļūdas.
Kas ir lietotāja pieņemšanas testēšana?
Lietotāja pieņemšanas testēšana jeb UAT ir programmatūras testēšanas veids, ko veic galalietotājs vai klients, lai pārbaudītu, vai programmatūra atbilst vēlamajām prasībām.
Lietotāja pieņemšanas testēšana ir pēdējais testēšanas veids, kas jāveic pirms programmatūras ievietošanas ražošanas vidē.
Tas notiek pēc tam, kad jau ir pabeigta funkcionālā testēšana, integrācijas testēšana un sistēmas testēšana.
Kādas ir atšķirības starp sistēmas testēšanu un lietotāja pieņemšanas testēšanu?
Gan lietotāja pieņemšanas testēšana, gan integrācijas testēšana pārbauda, vai programmatūras izveides process darbojas, kā tam vajadzētu, un abos testēšanas veidos galvenā uzmanība tiek pievērsta tam, kā programmatūra darbojas kopumā.
Tomēr starp sistēmas testēšanu un lietotāja pieņemšanas testēšanu ir daudz atšķirību:
1. Testētāji:
Sistēmas testēšanu veic testētāji (un dažkārt arī izstrādātāji), bet lietotāja pieņemšanas testēšanu veic galalietotāji.
2. Mērķis:
Lietotāja pieņemšanas testēšanas mērķis ir novērtēt, vai programmatūras izveides rezultāts atbilst galalietotāja prasībām, bet sistēmas testēšanas mērķis ir pārbaudīt, vai sistēma atbilst testētāja prasībām.
3. Metode:
Sistēmas testēšanas laikā atsevišķas programmatūras izveides vienības tiek integrētas un testētas kā vienots veselums. Lietotāja pieņemšanas testēšanas laikā galalietotājs testē sistēmu kopumā.
4. Posms:
Sistēmas testēšana tiek veikta, tiklīdz ir pabeigta integrācijas testēšana un pirms tiek veikta lietotāja pieņemšanas testēšana. Lietotāju pieņemšanas testēšana notiek tieši pirms produkta izlaišanas pārāk agrīniem lietotājiem.
Sistēmas testēšanas veidi
Ja vēlaties pārbaudīt, kā jūsu programmatūra darbojas pilnībā, varat izmantot vairāk nekā 50 dažādus sistēmas testēšanas veidus.
Tomēr praksē lielākā daļa testēšanas komandu izmanto tikai dažus no šiem sistēmu testēšanas veidiem.
Sistēmas testēšanas veids ir atkarīgs no daudziem dažādiem faktoriem, tostarp jūsu budžeta, laika ierobežojumiem, prioritātēm un resursiem.
1. Funkcionalitātes testēšana
Funkcionalitātes testēšana ir sistēmas testēšanas veids, kura mērķis ir pārbaudīt atsevišķas programmatūras iespējas un funkcijas un novērtēt, vai tās darbojas, kā tām vajadzētu.
Šo sistēmas testēšanas veidu var veikt manuāli vai automātiski, un tas ir viens no galvenajiem sistēmas testēšanas veidiem, ko veic testēšanas komandas.
2. Veiktspējas testēšana
Veiktspējas testēšana ir sistēmas testēšanas veids, kas ietver testēšanu, cik labi lietojumprogramma darbojas parastas lietošanas laikā.
To sauc arī par atbilstības testēšanu, un parasti tā nozīmē lietojumprogrammas veiktspējas testēšanu, kad to vienlaicīgi izmanto vairāki lietotāji.
Veiktspējas testēšanas laikā testētāji pārbauda iekraušanas laiku, kā arī kļūdas un citas problēmas.
3. Slodzes testēšana
Slodzes testēšana ir sistēmas testēšanas veids, ko testētāji veic, lai novērtētu, cik labi lietojumprogramma tiek galā ar lielām slodzēm.
Piemēram, testētāji var pārbaudīt, cik labi lietojumprogramma darbojas, kad daudzi lietotāji vienlaicīgi mēģina veikt vienu un to pašu uzdevumu, vai arī cik labi lietojumprogramma veic vairākus uzdevumus vienlaicīgi.
4. Mērogojamības testēšana
Mērogojamības testēšana ir programmatūras sistēmas testēšanas veids, ar kuru pārbauda, cik labi programmatūra ir mērogojama, lai atbilstu dažādu projektu un komandu vajadzībām.
Tas ir nefunkcionālās testēšanas veids, kas ietver novērtēšanu, kā programmatūra darbojas dažādiem lietotājiem vai kad to izmanto dažādās vietās un ar dažādiem resursiem.
5. Lietderības testēšana
Lietderības testēšana ir sistēmas testēšanas veids, kas ietver lietojumprogrammas lietojamības pārbaudi.
Tas nozīmē, ka testētāji novērtē un izvērtē, cik viegli lietojumprogrammu ir pārvietoties un lietot, cik intuitīvas ir tās funkcijas un vai ir kādas kļūdas vai problēmas, kas var radīt lietojamības problēmas.
6. Uzticamības testēšana
Uzticamības testēšana ir sistēmas integrācijas testēšanas veids, kas pārbauda programmatūras uzticamību.
Lai novērtētu, vai vienreizējo pārbaužu rezultāti ir ticami un atkārtojami, programmatūras funkcijas un veiktspēja jāpārbauda kontrolētā vidē.
7. Konfigurācijas testēšana
Konfigurācijas testēšana ir sistēmas testēšanas veids, kurā novērtē, cik labi sistēma darbojas, strādājot kopā ar dažāda veida programmatūru un aparatūru.
Konfigurācijas testēšanas mērķis ir noteikt labāko programmatūras un aparatūras konfigurāciju, lai maksimāli palielinātu sistēmas veiktspēju kopumā.
8. Drošības testēšana
Drošības testēšana ir sistēmas testēšanas veids, kurā novērtē, kā programmatūra darbojas saistībā ar drošību un konfidencialitāti.
Drošības testēšanas mērķis ir identificēt visas iespējamās neaizsargātības un apdraudējumus, kas varētu būt datu aizsardzības pārkāpumu un pārkāpumu avots, kuru rezultātā varētu tikt zaudēta nauda, konfidenciāli dati un citi svarīgi aktīvi.
9. Migrācijas testēšana
Migrācijas testēšana ir sistēmas testēšanas veids, kas tiek veikta programmatūras sistēmām, lai novērtētu, kā tās varētu mijiedarboties ar vecāku vai jaunāku infrastruktūru.
Piemēram, testētāji var novērtēt, vai vecāki programmatūras elementi var migrēt uz jauno infrastruktūru bez kļūdu un kļūdu rašanās.
Kas jums nepieciešams, lai sāktu sistēmas testēšanu
Pirms sistēmas testēšanas uzsākšanas ir svarīgi, lai jums būtu skaidrs plāns, kā apvienot resursus un rīkus, kas nepieciešami veiksmīgam un raitam sistēmas testēšanas procesam.
Neatkarīgi no tā, vai testēšana tiek veikta manuāli, automātiski vai izmantojot abas pieejas, tas ir samērā sarežģīts process, tāpēc, pirms sākat testēšanu, vislabāk ir zināt, kas jums būs nepieciešams, lai samazinātu kavēšanās un traucējumu risku testēšanas laikā.
1. Stabila uzbūve, kas ir gandrīz gatava palaišanai
Sistēmas testēšana ir viens no pēdējiem programmatūras testēšanas posmiem, kas notiek pirms izlaišanas: vienīgais testēšanas veids, kas notiek pēc sistēmas testēšanas, ir lietotāja pieņemšanas testēšana.
Pirms sākat sistēmas testēšanu, ir svarīgi, lai jau būtu veikta cita veida programmatūras testēšana, tostarp funkcionālā testēšana, regresijas testēšana un integrācijas testēšana, un lai jūsu programmatūras izveide atbilstu katra no šiem programmatūras testu veidiem izejas kritērijiem.
2. Sistēmas testēšanas plāni
Pirms sākat testēšanu, sastādiet oficiālu dokumentāciju, kurā izklāstīts veicamo testu mērķis un uzdevumi, kā arī definēti sistēmas testēšanas sākuma un beigu kritēriji.
Šo plānu var izmantot, lai izklāstītu atsevišķus testēšanas scenārijus, kurus plānojat pārbaudīt, vai lai definētu savas gaidas par to, kā sistēma darbosies.
Sistēmas testēšanas plānam ir jāļauj testētājiem viegli izstrādāt un veikt sistēmas testēšanu, ievērojot plānu.
3. Testēšanas gadījumi
Pirms sistēmas testēšanas uzsākšanas ir svarīgi ieskicēt testēšanas gadījumus, kurus testēsiet sistēmas testēšanas laikā.
Testēšanas gadījumi var nebūt izsmeļoši, taču tiem jābūt pietiekami pilnīgiem, lai pārbaudītu svarīgākās sistēmas funkcionālās un nefunkcionālās funkcijas un sniegtu precīzu pārskatu par sistēmas darbību kopumā.
4. Prasmes un laiks
Pārliecinieties, ka sistēmas testēšanai pirms sistēmas testu uzsākšanas esat atvēlējuši pietiekamus resursus.
Sistēmas testēšana var aizņemt salīdzinoši ilgu laiku, īpaši salīdzinājumā ar citiem testēšanas veidiem, piemēram, dūmu testēšanu.
Jums būs jānosaka, kuri cilvēki jūsu komandā veiks testēšanu un cik ilgs laiks viņiem būs nepieciešams pirms testēšanas sākuma.
5. Sistēmas testēšanas rīki
Sistēmas testēšanu var veikt manuāli vai automatizēti, taču neatkarīgi no tā, kādu pieeju izvēlaties testēšanai, ir iespējams racionalizēt un optimizēt sistēmas testēšanas darba procesus, izmantojot rīkus un tehnoloģijas, kas palīdz dažādos testēšanas aspektos.
Piemēram, varat izmantot mākslīgā intelekta rīkus, lai automatizētu dažus sistēmas testus, vai arī izmantot dokumentu pārvaldības programmatūru, lai palīdzētu izsekot testēšanas gaitai un rezultātiem.
Sistēmas testēšanas process
Pirms sākat, ir svarīgi saprast sistēmas testēšanas procesu un to, kā veikt katru tā posmu.
Šis pakāpeniskais plāns atbilst iepriekš aprakstītajam sistēmas testēšanas dzīves ciklam, taču tajā sīkāk izklāstīti atsevišķi sistēmas testēšanas posmi.
1. solis: Izveidojiet sistēmas testēšanas plānu
Pirms sistēmas testēšanas uzsākšanas izveidojiet sistēmas testēšanas plānu. Katras sistēmas testēšanas plāns būs atšķirīgs, taču plānā jāiekļauj vismaz testēšanas mērķa izklāsts, kā arī attiecīgie ieejas un izejas kritēriji, kas nosaka, kad testēšana jāsāk un kad tā jāpabeidz.
2. posms: Izveidojiet testa scenārijus un testa gadījumus
Nākamais posms ir testēšanas scenāriju un testēšanas gadījumu ģenerēšana, kuros ir precīzi aprakstīts, ko un kā jūs testēsiet.
Ietveriet reālus testēšanas scenārijus, kas pārbauda, kā programmatūra darbojas tipiskā lietošanas režīmā, un katram testēšanas gadījumam, ko rakstāt, iekļaujiet sīkāku informāciju par testa izturēšanas un neizturēšanas kritērijiem un gaidāmo rezultātu.
3. solis: Izveidojiet nepieciešamos testa datus
Izveidojiet nepieciešamos testa datus katram testēšanas scenārijam, ko plānojat izpildīt.
Testa dati, kas jums būs nepieciešami katram plānotajam testa scenārijam, ir visi testa dati, kas ietekmē vai kurus ietekmē katrs konkrētais tests.
Testa datus ir iespējams ģenerēt manuāli vai arī šo posmu var automatizēt, ja vēlaties ietaupīt laiku un jums ir pietiekami resursi, lai to izdarītu.
4. solis: Testēšanas vides iestatīšana
Nākamais solis ir izveidot testēšanas vidi, kas ir gatava sistēmas testu veikšanai. Sistēmas testēšanas rezultāti būs labāki, ja izveidosiet ražošanas videi līdzīgu testēšanas vidi.
Pārliecinieties, ka testēšanas vidē ir iekļauta visa programmatūra un aparatūra, ko vēlaties testēt konfigurācijas un integrācijas testēšanas laikā.
5. solis: Izpildiet testa gadījumus
Kad testēšanas vide ir iestatīta, varat izpildīt otrajā solī izveidotos testēšanas gadījumus.
Šos testa gadījumus var izpildīt manuāli vai arī var automatizēt testa gadījumu izpildi, izmantojot skriptu.
Veicot katru testa gadījumu, atzīmējiet testa rezultātus.
6. posms: Sagatavojiet ziņojumus par kļūdām
Kad esat izpildījis visus norādītos testēšanas gadījumus, varat izmantot katra testa rezultātus, lai sagatavotu kļūdu ziņojumus, kuros detalizēti norādītas visas sistēmas testos konstatētās kļūdas un defekti.
Nododiet šo ziņojumu izstrādātājiem kļūdu labošanai un labojumiem. Atkarībā no identificēto kļūdu sarežģītības un smaguma pakāpes kļūdu labošanas posms var aizņemt zināmu laiku.
7. posms: atkārtots tests pēc kļūdu labošanas
Pēc tam, kad programmatūras izstrādātāji pēc kļūdu novēršanas ir nosūtījuši programmatūru atpakaļ turpmākai testēšanai, ir svarīgi vēlreiz pārbaudīt programmatūras kopumu.
Būtiski, ka sistēmas testēšana nav uzskatāma par pabeigtu, kamēr šis posms nav izturēts bez kļūdām vai defektiem.
Nepietiek ar pieņēmumu, ka visas kļūdas ir novērstas un ka izveides sagatavošana ir gatava pārejai uz lietotāja pieņemšanas testēšanu.
8. solis: atkārtojiet ciklu
Pēdējais solis ir vienkārši atkārtot šo ciklu tik reižu, cik nepieciešams, lai izietu septīto soli, neatklājot kļūdas vai defektus.
Kad sistēmas tests ir izturēts un ir izpildīti visi sistēmas testēšanas plānā noteiktie izejas kritēriji, ir pienācis laiks pāriet pie lietotāja pieņemšanas testēšanas un, visbeidzot, produkta izlaišanas.
Manuālie un automatizētie sistēmas testi
Tāpat kā citus programmatūras testēšanas veidus, arī sistēmu testēšanu var veikt vai nu manuāli, izmantojot testētājus, vai vismaz daļēji automatizēt ar programmatūru. Programmatūras testēšanas automatizācija racionalizē testēšanas procesu un ietaupa laiku un naudu, taču dažkārt ir svarīgi veikt arī manuālu sistēmas testēšanu.
Gan manuālai, gan automatizētai sistēmas testēšanai ir gan plusi, gan mīnusi, un ir svarīgi tos izprast, pirms izlemt, kuru sistēmas testēšanas veidu vēlaties veikt.
Manuāla sistēmas testēšana
Manuāla sistēmas testēšana nozīmē manuālu sistēmas testēšanu, neautomatizējot daļu no visa testēšanas procesa.
Manuālai sistēmas testēšanai ir nepieciešams ilgāks laiks nekā automatizētai testēšanai, taču tas nozīmē arī to, ka testēšanas procesā tiek izmantota cilvēka izpratne un vērtējums.
Manuālā testēšana bieži tiek kombinēta ar automātisko testēšanu, lai maksimāli palielinātu sistēmas testēšanas un citu programmatūras testu veidu efektivitāti un precizitāti.
1. Manuālas sistēmas testēšanas priekšrocības
Manuālai sistēmas testēšanai ir daudz priekšrocību, un šīs priekšrocības izskaidro, kāpēc daudzas testēšanas komandas izvēlas turpināt manuālo testēšanu, kā arī automatizēto testēšanu pat pēc testēšanas skriptu automatizēšanas.
Sarežģītība
Manuālā testēšana ir piemērota sarežģītu testēšanas scenāriju testēšanai, kurus ne vienmēr ir viegli automatizēt.
Ja jūsu sistēmas testēšanas prasības ir sarežģītas vai detalizētas, jums var būt vieglāk šos scenārijus testēt manuāli, nevis rakstīt automatizētus testēšanas skriptus.
Izpētes testēšana
Automatizējot jebkāda veida programmatūras testu, tests seko savam skriptam un pārbauda tikai tās funkcijas, kuru novērtēšanai ir ieprogrammēts tests.
Turpretī, veicot manuālo testēšanu, varat izpētīt dažādas funkcijas, kad tās jūs ieinteresē, piemēram, ja pamanāt, ka programmatūras saskarnē kaut kas neizskatās tā, kā tam vajadzētu izskatīties.
Vienkāršība
Kad esat uzrakstījis automatizētos testēšanas skriptus, automatizētā testēšana ir vienkārša. Taču, lai rakstītu testēšanas skriptus, parasti ir nepieciešamas izstrādes zināšanas, un mazākām testēšanas komandām var nebūt resursu, lai to paveiktu.
Manuālai testēšanai nav nepieciešamas tehniskās zināšanas vai zināšanas par kodēšanu.
2. Manuālo sistēmas testu izaicinājumi
Manuālā testēšana arī rada savas problēmas. Programmatūras testēšanas komandas, kas veic tikai manuālu sistēmas testēšanu, neiekļaujot automatizētas testēšanas elementus, var nonākt neizdevīgākā situācijā salīdzinājumā ar tām komandām, kas izmanto abas pieejas.
Laiietilpīgs
Kā jau varēja gaidīt, manuāla sistēmas testēšana ir laikietilpīgāka nekā automatizēta sistēmas testēšana. Tas ir īpaši vājš trūkums, ja ir nepieciešama veikla testēšana.
Tas nozīmē, ka ir mazāk praktiski veikt regulārus vai ļoti rūpīgus sistēmas testus, un tas savukārt var ietekmēt rezultātu ticamību un apjomu.
Cilvēka kļūda
Ja testēšanu manuāli veic cilvēki, vienmēr ir iespējamas cilvēciskas kļūdas. Cilvēki pieļauj kļūdas, viņiem kļūst garlaicīgi vai izklaidīgi, un tas ir īpaši iespējams, veicot atkārtotus, laikietilpīgus testus, kas var vairāk nogurdināt testētājus.
Testa pārklājums
Manuālie testi nepiedāvā tik plašu pārklājumu kā automatizētie testi.
Tā kā testētājiem pašiem ir jāveic manuālie testi, manuāli testējot nav iespējams aptvert tikpat daudz informācijas, salīdzinot ar automatizēto testēšanu, un tas var novest pie mazāk visaptverošiem testu rezultātiem.
Kad izmantot manuālo programmatūras testēšanu
Manuālo programmatūras testēšanu nav aizstājusi automatizētā testēšana, un manuālā testēšana joprojām ir svarīgs sistēmas testēšanas procesa posms.
Manuālā testēšana ir piemērota mazākām programmatūras komandām, kurām var nebūt resursu, lai patstāvīgi automatizētu sistēmas testēšanu, un pat komandām, kas ir ieviesušas automatizētu testēšanu, vajadzētu izmantot manuālo testēšanu, lai novērtētu sarežģītākus testēšanas scenārijus vai testēšanas gadījumus, kuros izpētes testēšana ir lietderīga.
Sistēmas testēšanas automatizācija
Sistēmas testēšanu ir iespējams automatizēt, pašiem rakstot testēšanas skriptus vai izmantojot hiperautomatizācijas rīkus un procesus, lai daļēji vai pilnībā automatizētu sistēmas testēšanas procesu.
Visbiežāk automatizētā sistēmas testēšana tiek kombinēta ar manuālo sistēmas testēšanu, lai nodrošinātu vislabāko pārklājuma, efektivitātes un precizitātes līdzsvaru.
1. Sistēmas testēšanas automatizācijas priekšrocības
Automatizētā sistēmu testēšana kļūst arvien populārāka, daļēji pateicoties plašai automatizētās testēšanas rīku pieejamībai, kas ļauj viegli automatizēt programmatūras sistēmu testēšanu.
Automatizētai sistēmas testēšanai ir daudz priekšrocību, jo īpaši, ja to apvieno ar manuālo testēšanu.
Efektivitāte
Automatizētā testēšana ir efektīvāka nekā manuālā testēšana, jo automātiskos testus ir iespējams palaist fonā, kamēr testētāji un izstrādātāji veic citus uzdevumus.
Tādējādi automatizēto testēšanu ir praktiskāk veikt regulāri un samazinās nepieciešamība deleģēt lielu skaitu resursu testēšanai pēc tam, kad ir izveidoti automatizētie testi.
Lielāks testu pārklājums
Automatizētie testi bieži vien var aptvert lielāku programmatūras izveides apgabalu nekā manuālie testi, lielā mērā tāpēc, ka to efektivitāte ir lielāka.
Kad testētāji veic sistēmas testēšanu manuāli, viņiem ir jāizvēlas svarīgākie testēšanas gadījumi, kurus novērtēt, savukārt automatizētā testēšana dod programmatūras komandām iespēju elastīgi testēt vairāk scenāriju īsākā laikā.
Cilvēka kļūdas novēršana
Automatizētie testi nav tikpat neaizsargāti pret cilvēka kļūdām kā manuālie testi.
Veicot atkārtotus, laikietilpīgus testus, kas var nogurdināt manuālos testētājus, automatizētie testi turpina pārbaudīt programmatūru ar tādu pašu ātrumu un precizitāti.
Cilvēki arī biežāk koncentrējas uz vieglu kļūdu meklēšanu nekā uz sarežģītu kļūdu meklēšanu, tāpēc dažas svarīgas, bet mazāk pamanāmas kļūdas var tikt palaistas garām.
Testēšanas standartizēšana
Kad rakstāt skriptu sistēmas testēšanas automatizēšanai, jūs izveidojat instrukciju kopumu, pēc kura programmatūras testēšanas rīks jāvadās.
Tas efektīvi standartizē programmatūras testus, ko veicat, un nodrošina, ka katru reizi, kad veicat testu, veicat vienu un to pašu testu un testējat programmatūru atbilstoši vieniem un tiem pašiem standartiem.
2. Sistēmas testēšanas automatizācijas izaicinājumi
Automatizētā sistēmas testēšana nav nevainojama, tāpēc, lai iegūtu labākos rezultātus, to bieži veic paralēli manuālajai testēšanai. Tā ir efektīvāka nekā manuālā testēšana, taču var nepiedāvāt tik daudz padziļinātu vai kvalitatīvu datu.
Elastība
Tā kā automatizētā testēšana vienmēr notiek pēc skripta, nav iespējams elastīgi testēt mehānismus vai funkcijas, kas nav iekļautas testēšanas skripta tekstā.
Lai gan tas nodrošina konsekvenci, tomēr tas nozīmē, ka var nepamanīt kļūdas un neprecizitātes, ja tās nav ņemtas vērā plānošanas posmā.
Resursi
Automatizētu testu izveidei ir nepieciešams laiks un resursi.
Lai gan ir iespējams automatizēt sistēmas testēšanu, izmantojot gatavu programmatūru un rīkus, lielākoties tos joprojām ir nepieciešams pielāgot jūsu programmatūras prasībām.
Tradicionāli automatizēta testēšana ir nozīmējusi veltīt tehniskos resursus, lai pareizi uzrakstītu un palaistu automatizētus testus, lai gan arvien vairāk rīku, piemēram, ZAPTEST, nodrošina progresīvu datorredzes programmatūras automatizāciju bez koda saskarnē.
Sarežģīti testa gadījumi
Vairumā gadījumu nav iespējams 100% automatizēt sistēmas testēšanu, nepaļaujoties uz manuālu testēšanu.
Tas jo īpaši attiecas uz gadījumiem, kad ir nepieciešams testēt sarežģītus testēšanas scenārijus, kurus lielākā daļa automatizācijas rīku nav spējīgi testēt.
3. Kad ieviest automatizētu sistēmas testēšanu
Ja jūsu testēšanas komandai ir resursi, lai īstenotu automatizētu testēšanu, rakstot pielāgotus testēšanas skriptus vai izmantojot automatizācijas rīkus, automatizētā testēšana var padarīt sistēmas testēšanu efektīvāku un uzticamāku.
Tomēr vienmēr ir svarīgi turpināt manuālo testēšanu pat tad, ja esat pārliecināts par automatizēto testu kvalitāti un pārklājumu, jo automatizētā testēšana nevar atkārtot dziļumu un izpratni, ko var sniegt tikai manuālā testēšana.
Secinājums: Automatizēta sistēmas testēšana pret manuālu sistēmas testēšanu
Programmatūras izstrādes testēšanas posmā ir svarīga gan automatizētā sistēmas testēšana, gan manuālā sistēmas testēšana.
Lai gan mazāki uzņēmumi var sākt tikai ar manuālo sistēmas testēšanu, jo automatizētā testēšana prasa papildu ieguldījumus vai resursus, lielākā daļa testēšanas komandu izmanto kombinētu pieeju, kas ietver automatizētu testēšanu, tiklīdz tas ir praktiski iespējams.
Apvienojot automatizēto testēšanu ar manuālo testēšanu, testēšanas komandas var palielināt efektivitāti, precizitāti un elastīgumu, neapdraudot nevienu no sistēmas testēšanas rezultātiem.
Labākā sistēmas testēšanas prakse
Ja vēlaties optimizēt sistēmas testēšanas darba procesus, lai nodrošinātu maksimālu efektivitāti un precizitāti, labākais veids, kā to izdarīt, ir ievērot sistēmas testēšanas paraugpraksi.
Labākā prakse var palīdzēt jums nodrošināt, lai sistēmas testēšanas posmā nekas netiktu palaists garām, un garantēt, ka jūsu sistēmas testi vienmēr atbilst nemainīgi augstiem standartiem.
1. Pienācīgi plānojiet sistēmas testus
Visi sistēmu testi jāsāk ar oficiālu testēšanas plānu, kurā skaidri izklāstīti testēšanas gadījumi un testēšanas laikā izmantojamās pieejas.
Sākot ar oficiālu plānu, tiek samazināts risks, ka testēšanas laikā var rasties aizkavēšanās, un novērsti traucējumi, kas var rasties neskaidrību dēļ.
Tā nodrošina, ka visas attiecīgās puses zina, kāda ir to loma un par ko tās ir atbildīgas.
2. Vienmēr sastādiet detalizētus un precīzus ziņojumus
Ir svarīgi, lai sistēmas testēšana vienmēr būtu labi dokumentēta, pretējā gadījumā testētājiem un programmatūras izstrādātājiem var nebūt viegli izmantot jūsu testu rezultātus.
Par katru veikto testu sastādiet skaidrus, pamatīgus ziņojumus, kuros detalizēti aprakstītas atrastās kļūdas, precīzi parādīts, kā tās atkārtot, un norādīts, kā programmatūrai būtu jāuzvedas pēc novēršanas.
Pārliecinieties, ka ziņojumi par kļūdām ir nepārprotami un viegli saprotami.
3. Testēšana reālās ierīcēs
Bieži vien testēšanas komandas izvēlas atkārtot dažādas ierīces testēšanas vidē, faktiski netestējot programmatūru dažādās ierīcēs.
Ja veidojat programmatūru, ko paredzēts izmantot dažādās platformās, piemēram, mobilajos tālruņos, t.i. Android, iOS u. c. planšetdatori, tīmeklis un galddatori, t. i. Windows ,Linux u.c., pārbaudiet tos šajās ierīcēs, lai novērtētu, kā tie darbojas ar dažādām slodzēm un vai tīkla savienojuma problēmas var radīt problēmas konkrētās platformās.
4. Automatizēt testēšanu, ja iespējams
Lai iegūtu labākos rezultātus, parasti ir vislabāk apvienot manuālo sistēmas testēšanu ar automatizēto sistēmas testēšanu.
Ja vēl neesat eksperimentējis ar automatizētu sistēmas integrācijas testēšanu, izmēģiniet RPA + programmatūras testēšanas rīkus, kas var palīdzēt automatizēt vismaz dažus no jūsu sistēmas testiem, un tas ļaus jums palielināt pārklājumu un efektivitāti, neapdraudot rezultātu precizitāti.
5. Testējiet vienu funkciju katrā gadījumā
Kad rakstāt testēšanas gadījumus, koncentrējieties uz vienas funkcijas testēšanu katrā gadījumā, ja iespējams.
Tas atvieglo šo testu gadījumu atkārtotu izmantošanu turpmākajos testos un ļauj izstrādātājiem skaidrāk saprast, kā rodas kļūdas un kuras funkcijas tās izraisa.
Sistēmas testu rezultātu veidi
Veicot sistēmas testus, ir svarīgi zināt, kāda veida rezultātus sagaidīt no testiem un kā šos rezultātus izmantot, lai informētu par turpmāko izstrādi un testēšanu.
Testu rezultāti ir līdzekļi un informācija, kas iegūta, veicot sistēmas testus.
1. Testa rezultāti
Testēšanas rezultāti ietver datus par to, kā programmatūra darbojās katrā testēšanas gadījumā, ko veicāt, kā arī salīdzinājumu ar to, kā jūs paredzējāt, ka programmatūra darbosies.
Šie rezultāti palīdz noteikt, vai katrs testa gadījums ir vai nav izturējis testu, jo, ja programmatūra darbojas tā, kā jūs negaidījāt, tas parasti nozīmē, ka tā nav izturējusi testu.
2. Defektu žurnāls
Defektu žurnāli ir visu sistēmas testēšanas laikā atklāto kļūdu un defektu žurnāli.
Defektu žurnālā ir uzskaitītas visas atrastās kļūdas, kā arī cita svarīga informācija, piemēram, katras kļūdas prioritāte, nopietnība, kā arī kļūdas simptomi un apraksts.
Jāpieraksta arī kļūdas atklāšanas datums un cita informācija, kas palīdzēs izstrādātājiem atkārtoti atkārtot kļūdu.
3. Testa ziņojums
Testa ziņojums parasti ir daļa no sistēmas testēšanas pabeigšanas kritērijiem, un tajā parasti ir iekļauts veiktās testēšanas kopsavilkums, GO/No-Go ieteikumi, informācija par fāzi un iterāciju, kā arī testēšanas datums.
Varat arī iekļaut citu svarīgu informāciju par testa rezultātiem vai pievienot šim ziņojumam defektu saraksta kopiju.
Sistēmas testu piemēri
Sistēmas testi ir paredzēti, lai pārbaudītu sistēmu kopumā, kas nozīmē, ka tiek pārbaudītas visas dažādās programmatūras vienības, kas darbojas kopā kā sistēma.
Sistēmas testu piemēri var palīdzēt jums labāk saprast, kas ir sistēmas tests un ko tas pārbauda.
1. Funkcionalitātes testēšana
Programmatūras inženieru komanda izstrādā jaunu iepirkšanās lietotni, kas palīdz pārtikas veikaliem efektīvāk komplektēt un iepakot tiešsaistes pasūtījumus.
Lietotne sastāv no vairākiem dažādiem moduļiem, no kuriem katrs jau ir pārbaudīts atsevišķi, veicot vienības testēšanu, un kopā ar citiem moduļiem, veicot integrācijas testēšanu.
Sistēmas testēšana ir pirmā reize, kad visi moduļi tiek testēti vienkopus, un testētāji izstrādā testēšanas gadījumus, lai novērtētu katru atsevišķu lietojumprogrammas funkciju un pārbaudītu, vai tās darbojas, kā paredzēts, kad visi moduļi darbojas kopā.
2. Iekraušanas laika testēšana
Programmatūras testētāju komanda testē, cik ātri lietojumprogramma tiek ielādēta dažādos punktos pie dažādiem stresa līmeņiem.
Viņi izveido testēšanas gadījumus, kuros aprakstīts, kāda veida slodze tiek radīta lietojumprogrammai (piemēram, cik lietotāju to izmanto vienlaicīgi) un kādas funkcijas un funkcijas lietotājs mēģina ielādēt.
Sistēmas testēšanas laikā slodzes laiki tiek reģistrēti testēšanas pārskatā, un slodzes laiki, kas tiek uzskatīti par pārāk lēniem, izraisa citu izstrādes posmu.
3. Testēšanas konfigurācija
Veidojot videospēli, ko var izmantot ar daudzām dažādām perifērijas ierīcēm, tostarp datora peli, VR austiņām un spēļu paliktni, programmatūras testētāji veic konfigurācijas testēšanu, lai pārbaudītu, cik labi katra no šīm perifērijas ierīcēm darbojas ar spēli.
Viņi strādā ar katru testa scenāriju, pārbaudot katru perifēro ierīci atsevišķi un kopā, pierakstot, kā katra perifērā ierīce darbojas dažādos spēles posmos un vai veiktspēja ir pat sliktāka, nekā gaidīts.
Sistēmas testēšanas laikā atklāto kļūdu un kļūdu veidi
Veicot sistēmas testēšanu, veiktie testi ļaus identificēt programmatūras kļūdas un defektus, kas nav atrasti vienības testēšanā un integrācijas testēšanā.
Sistēmas testēšanas laikā ir iespējams identificēt dažāda veida kļūdas, dažkārt tāpēc, ka tās iepriekš nav pamanītas, vai parasti tāpēc, ka tās parādās tikai tad, kad sistēma darbojas kā vienots veselums.
1. Veiktspējas kļūdas
Sistēmas testēšana var izcelt veiktspējas kļūdas saistībā ar programmatūras izveides ātrumu, konsekvenci un reakcijas laiku.
Testētāji var novērtēt, kā programmatūra darbojas, veicot dažādus uzdevumus, un atzīmēt jebkādas kļūdas vai kavējumus, kas rodas lietošanas laikā. Tie ir veiktspējas defekti, kurus var uzskatīt vai neuzskatīt par pietiekami nopietniem, lai būtu nepieciešama turpmāka izstrāde.
2. Drošības kļūdas
Sistēmas testēšanas laikā ir iespējams identificēt drošības kļūdas, kas izceļ sistēmas drošības slāņa ievainojamību.
Drošības testēšana notiek sistēmas testēšanas posmā, un to var izmantot, lai identificētu šifrēšanas kļūdas, loģiskās kļūdas un XSS ievainojamības programmatūrā.
3. Lietojamības kļūdas
Lietojamības kļūdas ir kļūdas, kas apgrūtina lietotnes lietošanu tā, kā tā ir paredzēta. Tie var radīt neērtības lietotājiem, kas savukārt var likt lietotājiem atteikties no lietotnes.
Daži lietojamības kļūdu piemēri ir sarežģīta navigācijas sistēma vai izkārtojums, kurā nav viegli pārvietoties pa visiem platformas aspektiem.
Izmantojot lietojamības rīkus, kļūdas var identificēt testēšanas procesa sākumā, taču tās var atklāties arī sistēmas testēšanas laikā.
4. Komunikācijas kļūdas
Komunikācijas kļūdas rodas, kad daļa programmatūras mēģina sazināties ar citu moduli un kļūda izraisa šīs saziņas neveiksmi.
Piemēram, ja programmatūra lietotājam piedāvā lejupielādēt jaunu atjauninājumu, bet, kad lietotājs noklikšķina uz atjauninājuma lejupielādes pogas, atjauninājumu nevar atrast, tā ir saziņas kļūda.
5. Kļūdu apstrāde
Kļūdas dažkārt rodas pat tad, ja programmatūra darbojas, kā tai vajadzētu. Iespējams, tāpēc, ka komponents nav pareizi instalēts vai lietotājs ar to nedarbojas pareizi.
Tomēr sistēmai jāspēj pareizi apstrādāt šīs kļūdas tā, lai palīdzētu lietotājiem identificēt un novērst problēmu.
Ja kļūdas ziņojumos nav atbilstošas informācijas par kļūdu, lietotāji nevarēs novērst kļūdu.
Bieži izmantotās sistēmas testēšanas metrikas
Veicot sistēmas testēšanu, jūs varat izsekot noteiktus testēšanas rādītājus, lai palīdzētu testēšanas komandai uzraudzīt, cik efektīva ir sistēmas testēšana, cik bieži tiek atrastas kļūdas un vai sistēmas testēšana notiek pareizajā testēšanas cikla posmā.
Piemēram, ja jūs sekojat līdzi testu skaitam, kas ir izturējuši un neizturējuši testus, un konstatējat, ka liela daļa sistēmas testu ir neizturēti, varat secināt, ka testēšanas cikla sākumā ir nepieciešams veikt rūpīgāku testēšanu, lai identificētu kļūdas pirms sistēmas testēšanas uzsākšanas.
1. Absolūtie rādītāji
Absolūtie skaitļi ir tie rādītāji, kas vienkārši norāda absolūto skaitli, nevis proporciju vai attiecību.
Absolūtie rādītāji var būt noderīgi, taču, tā kā tie ir absolūti skaitļi, ne vienmēr ir viegli interpretēt to nozīmi.
Daži absolūto metriku piemēri ietver sistēmas testēšanas ilgumu, sistēmas testa veikšanai nepieciešamo laiku un kopējo sistēmas testēšanas laikā atklāto defektu skaitu.
2. Testa efektivitātes rādītāji
Testēšanas efektivitātes rādītāji palīdz testēšanas komandām saprast, cik efektīvas ir to pašreizējās sistēmas testēšanas procedūras, lai gan tie nesniedz nekādu informāciju par sistēmas testu kvalitāti.
Daži testēšanas efektivitātes metriku piemēri ir, piemēram, nokārtoto testu procentuālais īpatsvars un izlaboto defektu procentuālais īpatsvars.
Izturētie testi var jums parādīt, vai jūs veicat pārāk daudz testu un tādējādi izlaižat kļūdas, jo īpaši, ja redzat augstu izturēto testu rādītāju līdztekus augstam defektu novēršanas rādītājam.
3. Testa efektivitātes rādītāji
Testu efektivitātes rādītāji testētājiem sniedz informāciju par veikto sistēmas testu kvalitāti.
Ar tiem mēra, cik efektīvi sistēmas testi spēj identificēt un novērtēt sistēmas kļūdas un defektus.
Kopējā defektu ierobežošanas efektivitāte ir testēšanas efektivitātes metrikas piemērs, kas parāda testēšanas posmā atklāto kļūdu attiecību pret kļūdām, kas atrastas pēc izlaišanas.
4. Testa pārklājuma metrikas
Testa pārklājuma metrikas palīdz testētājiem saprast, cik pilnīgs ir viņu veiktais pārklājums visā sistēmā, kuru viņi mēģina testēt.
Piemēram, jūs varat noteikt, cik procentu no jūsu sistēmas testiem ir automatizēti vai cik daudz no nepieciešamajiem testiem ir izpildīti līdz šim.
Prasību pārklājuma metrika arī palīdz testētājiem izsekot, kāda daļa no nepieciešamajām funkcijām ir aptverta testēšanā.
5. Defektu rādītāji
Defektu metrikas ir metrikas, kas dažādos veidos mēra defektu klātbūtni. Dažas defektu metrikas var būt vērstas uz defektu nopietnību, bet citas – uz defektu veidu vai galveno cēloni.
Viens no izplatītākajiem defektu metrikas piemēriem ir defektu blīvums, kas mēra kopējo defektu skaitu visā laidienā.
Defektu blīvumu parasti norāda kā defektu skaitu uz 1000 koda rindiņām.
Sistēmas pārbaudes gadījumi
Sistēmas testēšanas gadījumi ir testēšanas scenāriji, ko izmanto sistēmas testēšanā, lai pārbaudītu, kā programmatūra darbojas un vai tā atbilst izstrādātāju, testētāju, lietotāju un ieinteresēto personu gaidām.
1. Kas ir testa gadījumi sistēmas testēšanā?
Testēšanas gadījumi būtībā ir instrukcijas, kas nosaka, kas ir jāpārbauda un kādas darbības testētājam ir jāveic, lai pārbaudītu katru atsevišķu gadījumu.
Rakstot sistēmas testu gadījumus, ir svarīgi iekļaut visu informāciju, kas testētājiem nepieciešama, lai izpildītu katru testu. Katram testa gadījumam norādiet testa gadījuma ID un informāciju par to, kā izpildīt testu un kādus rezultātus sagaidāt, kā arī, ja nepieciešams, katra testa gadījuma apstiprināšanas un noraidīšanas kritērijus.
2. Kā rakstīt sistēmas testēšanas gadījumus
Ja testēšanas gadījumu rakstīšanā esat iesācējs, varat izpildīt tālāk aprakstītās darbības, lai rakstītu testēšanas gadījumus sistēmas testēšanai. Testēšanas gadījumu rakstīšana citiem programmatūras testēšanas veidiem ir ļoti līdzīgs process.
- Nosakiet jomu, kuru vēlaties, lai aptver jūsu testa gadījums.
- Pārliecinieties, ka testa gadījumu ir viegli pārbaudīt.
- Katram testa gadījumam piemēro attiecīgus testēšanas plānus.
- Katram testa gadījumam piešķiriet unikālu testa gadījuma ID.
- Ietveriet skaidru aprakstu par to, kā palaist katru testa gadījumu.
- Pievienojiet katram testa gadījumam pirmnosacījumus un pēcnosacījumus.
- Norādiet, kādu rezultātu sagaidāt no katra testa gadījuma.
- Aprakstiet izmantojamās testēšanas metodes.
- Pirms turpināt darbu, palūdziet kolēģim veikt katra testa gadījuma salīdzinošo pārskatīšanu.
3. Sistēmas testa gadījumu piemēri
Testēšanas gadījumu piemēru izmantošana var palīdzēt jums uzrakstīt savus testēšanas gadījumus. Tālāk ir sniegti divi piemēri sistēmas pārbaudes gadījumiem, kurus testētāji var izmantot, lai pārbaudītu lietojumprogrammas vai programmatūras darbību.
Pārtikas preču skenēšanas lietotnes cenu apstiprināšana
Testa ID: 0788
Testēšanas gadījums: Apstiprināt preces cenu
Testa gadījuma apraksts: Skenēt preci un pārbaudīt tās cenu.
Paredzamie rezultāti: Skenētajai cenai būtu jāsakrīt ar pašreizējo akciju cenu.
Rezultāts: Tas atbilst pašreizējai akciju cenai.
Izturējis/neizturējis: Izturējis/neizturējusi.
Pārvaldības programmatūras end-to-end transakcijas reakcijas laiks
Testa ID: 0321
Testēšanas gadījums: Sākuma ekrāna ielādes laiks
Testa gadījuma apraksts: Pārliecinieties, ka lietotnes ielādes ekrāns tiek ielādēts noteiktā laikā.
Gaidāmie rezultāti: Ekrānam vajadzētu ielādēties četru sekunžu laikā vai ātrāk.
Rezultāts: Ekrāns ielādējās 6 sekunžu laikā.
Izturējis/neizturējis: Nesaņemts/neizturēts.
Labākie sistēmas testēšanas rīki
Sistēmas testēšanas rīku izmantošana ir viens no vienkāršākajiem veidiem, kā racionalizēt testēšanas procesu un samazināt laiku, ko testēšanas komandas pavada, veicot laikietilpīgus manuālus uzdevumus.
Sistēmas testēšanas rīki var vai nu automatizēt sistēmas testēšanas procesa elementus jūsu vietā, vai arī tie var atvieglot testēšanas gadījumu rakstīšanu un testēšanas progresa izsekošanu.
Pieci labākie bezmaksas sistēmas testēšanas rīki
Ja neesat gatavs tērēt lielu daļu sava budžeta sistēmas testēšanas rīkiem, bet vēlaties izpētīt, kas ir pieejams, un, iespējams, vienlaikus uzlabot savu sistēmas testēšanas procesu efektivitāti, laba ziņa ir tā, ka tiešsaistē ir pieejami daudzi bezmaksas testēšanas rīki.
Bezmaksas testēšanas rīki nepiedāvā tādu pašu funkcionalitāti kā maksas testēšanas rīki, taču tie var nodrošināt mazākiem uzņēmumiem rentablu veidu, kā izpētīt programmatūras automatizāciju un RPA.
1. ZAPTEST BEZMAKSAS izdevums
ZAPTEST ir programmatūras testēšanas rīku komplekts, ko var izmantot sistēmu testēšanai un cita veida programmatūras testēšanai.
ZAPTEST ir pieejams gan kā bezmaksas, gan kā maksas uzņēmuma izdevums, taču bezmaksas izdevums ir ideāls ievads automatizētai sistēmu testēšanai mazākiem uzņēmumiem un uzņēmumiem, kas vēlas spert pirmos soļus testēšanas automatizācijas virzienā.
ZAPTEST var automatizēt sistēmas testus gan datoriem, gan portatīvajām ierīcēm un ļauj testētājiem automatizēt testus bez kodēšanas.
2. Selēns
Selenium ir viens no pazīstamākajiem tirgū pieejamajiem atvērtā koda testēšanas rīkiem.
Selenium bezmaksas versija piedāvā automatizētas testēšanas rīkus, kurus var izmantot sistēmas testēšanā, regresijas testēšanā un kļūdu pavairošanā, un to var izmantot, lai izveidotu savus testēšanas skriptus daudziem dažādiem testēšanas scenārijiem.
Tomēr tas tiek darīts uz vienkāršības un lietošanas ērtuma rēķina, un to var būt diezgan grūti apgūt lietotājiem, kas nav tehniskie speciālisti.
3. Appium
Appium ir bezmaksas sistēmas testēšanas rīks, kas ir piemērots lietošanai tieši ar mobilajām lietojumprogrammām.
Izmantojot Appium, varat automatizēt sistēmas testēšanu lietotnēm, kas paredzētas lietošanai ar iOS un Android viedtālruņiem un planšetdatoriem.
Šis bezmaksas rīks nav piemērots darbvirsmas lietojumprogrammu lietošanai, un tas ir viens no tā lielākajiem trūkumiem.
3. Testlink
Ja vienkārši vēlaties atvieglot sistēmas testēšanas plānošanu, sagatavošanu un dokumentēšanu, Testlink ir lielisks bezmaksas rīks, kas padara testēšanas dokumentācijas pārvaldību vienkāršu.
Izmantojot Testlink, varat viegli sakārtot pārskatus sadaļās, lai atrastu vajadzīgo informāciju, kad tā nepieciešama.
Testlink ir vērtīgs testēšanas rīks neatkarīgi no tā, vai veicat sistēmas testēšanu, “dūmu” testēšanu vai jebkāda cita veida programmatūras testēšanu.
5. Loadium
Loadium ir bezmaksas testēšanas rīks, kas ir īpaši izstrādāts veiktspējas testēšanai un slodzes testēšanai.
Tomēr tā koncentrēšanās uz veiktspējas un slodzes testēšanu ir būtisks trūkums lietotājiem, kuri vēlas automatizēt visu komplekso testu spektru.
4 labākie uzņēmumu sistēmu testēšanas rīki
Uzņēmumam augot, var izrādīties, ka bezmaksas testēšanas rīki vairs neatbilst jūsu prasībām. Daudzi bezmaksas rīki, piemēram, ZAPTEST, piedāvā gan uzņēmumu, gan bezmaksas versijas.
1. ZAPTEST Enterprise edition
ZAPTEST piedāvā sava testēšanas rīka korporatīvo versiju, kas var lepoties ar tādām pašām viegli lietojamām funkcijām un intuitīvu interfeisu kā bezmaksas rīks, taču to var labāk izmantot lielākas komandas, kurām var būt nepieciešama intensīvāka testēšana vai kuras vēlas testēt sarežģītākas programmatūras veidnes.
ZAPTEST korporatīvā versija piedāvā neierobežotu veiktspējas testēšanu un neierobežotu skaitu iterāciju, kā arī piesaistītu ZAP sertificētu ekspertu, kas strādā kā daļa no klienta komandas (tas pats par sevi ir būtiska priekšrocība, salīdzinot ar citiem pieejamiem automatizācijas rīkiem).
Tā neierobežotu licenču modelis ir arī vadošais piedāvājums tirgū, kas nodrošina, ka uzņēmumiem vienmēr būs fiksētas izmaksas neatkarīgi no to izaugsmes ātruma.
2. SoapUI
SoapUI ir testēšanas rīks, kas ļauj pārvaldīt un izpildīt sistēmas testus dažādām tīmekļa pakalpojumu platformām un API.
Testēšanas komandas var izmantot SoapUI, lai samazinātu laiku, ko tās pavada laikietilpīgiem uzdevumiem, un izstrādātu rūpīgākas un efektīvākas testēšanas stratēģijas.
3. Testsigma
Testsigma ir programmatūras testēšanas platforma, kas darbojas bez plauktiem. Tas ļauj produktu komandām automātiski plānot un veikt programmatūras testus tīmekļa vietnēm, mobilajām lietotnēm un API.
Platforma ir veidota, izmantojot Java, bet tā darbojas ar vienkāršā angļu valodā rakstītiem testu skriptiem.
4. TestingBot
TestingBot ir salīdzinoši lēts uzņēmuma risinājums uzņēmumiem, kas vēlas eksperimentēt šajā nozarē, no sākuma netērējot daudz naudas. TestingBot piedāvā testētājiem vienkāršu veidu, kā testēt gan vietnes, gan mobilās lietotnes, izmantojot 3200 pārlūkprogrammu un mobilo ierīču kombināciju tīklu.
Tam trūkst lielāku uzņēmumu rīku funkcionalitātes, taču tas ir labs risinājums uzņēmumiem ar mazāku budžetu.
Kad jāizmanto uzņēmuma un kad bezmaksas sistēmas testēšanas rīki
Tas, vai izvēlaties izmantot uzņēmuma vai bezmaksas sistēmas testēšanas rīkus, ir atkarīgs no jūsu komandas vajadzībām, budžeta, prioritātēm un darba grafika.
Pats par sevi saprotams, ka uzņēmumu rīki piedāvā vairāk funkciju un funkcionalitātes, salīdzinot ar bezmaksas rīkiem, taču mazākiem uzņēmumiem, kuriem budžetā nav daudz vietas, bezmaksas rīki ir fantastiska iespēja.
Ja jūsu uzņēmums aug vai ja konstatējat, ka jūsu testēšanas komanda sistēmas testēšanai un cita veida programmatūras testēšanai tērē vairāk laika, nekā vēlētos, uzņēmuma testēšanas rīku modernizēšana un mācīšanās, kā pilnībā izmantot šo rīku priekšrocības, varētu palīdzēt jums paplašināt uzņēmumu, lai apmierinātu augošo pieprasījumu.
Turklāt, izmantojot tādus rīkus kā ZAPTEST Enterprise, kas piedāvā inovatīvus programmatūras + pakalpojumu modeļus un neierobežotu licenču modeļus, jūs garantēti novērsīsiet gan tehnisko zināšanu plaisu, gan saglabāsiet nemainīgas izmaksas neatkarīgi no tā, cik strauji jūs augat un cik daudz izmantojat rīkus.
Sistēmas testēšanas kontrolsaraksts, padomi un triki
Pirms sākat sistēmas testēšanu, izlasiet turpmāk sniegto sistēmas testēšanas kontrolsarakstu un ievērojiet šos padomus, lai optimizētu sistēmas testēšanu, nodrošinot precizitāti, efektivitāti un pārklājumu.
Sistēmas testēšanas pārbaudes kontrolsaraksts var palīdzēt pārliecināties, ka, turpinot sistēmas testēšanu, ir iekļauts viss nepieciešamais.
1. Iesaistiet testētājus projektēšanas posmā
Lai gan testētāji parasti nestrādā ar programmatūru, kamēr nav pabeigta izstrādes un projektēšanas fāze, iesaistot testētājus jau agrīnā posmā, testētājiem ir vieglāk saprast, kā dažādas sastāvdaļas darbojas kopā, un ņemt to vērā testēšanā.
Tas bieži vien ļauj veikt padziļinātu izpētes testēšanu.
2. Rakstīt skaidrus testēšanas gadījumus
Rakstot testēšanas gadījumus, pārliecinieties, ka tie ir skaidri un nepārprotami.
Testētājiem jāspēj izlasīt testēšanas gadījumus un uzreiz saprast, kas un kā ir jātestē.
Ja nepieciešams, paskaidrojiet, kur atrast testējamo funkciju un kādas darbības jāveic sistēmas testēšanas procesā.
3. Maksimizēt testu pārklājumu
Veicot sistēmas testēšanu, parasti nav iespējams panākt 100% testēšanas pārklājumu, pat ja izmantojat automatizācijas rīkus.
Tomēr, jo lielāks ir testēšanas pārklājums, jo lielāka ir iespēja identificēt un novērst kļūdas pirms izlaišanas.
Mēģiniet panākt, lai testu pārklājums būtu vismaz 90 % vai pēc iespējas tuvāks šim rādītājam.
4. Rūpīga rezultātu analīze
Rūpīgi analizējiet katra sistēmas testa rezultātus un dokumentācijā skaidri norādiet kļūdas un defektus.
Jo sīkāku informāciju par kļūdām varat sniegt, jo vieglāk izstrādātājiem vēlāk būs šīs kļūdas atkārtot.
Ja jums ir idejas par kļūdu rašanās iemesliem un to, kā kļūdas varētu novērst, iekļaujiet tās testēšanas rezultātos.
5. Iziet ārpus prasību testēšanas
Netestējiet lietojumprogrammas tikai tāpēc, lai pārbaudītu, vai tās dara to, kas tām jādara.
Pārbaudiet, kā jūsu programmatūra darbojas ārpus tās prasībām, lai redzētu, kā tā reaģē uz uzdevumiem un darbībām, kas nav paredzētas izmantošanai. Tas var palīdzēt identificēt kļūdas un defektus, kurus citādi jūs nepamanītu.
7 kļūdas un lamatas, no kurām jāizvairās, ieviešot sistēmas testus
Pirmo reizi ieviešot sistēmas testus, ir svarīgi apzināties biežāk pieļautās kļūdas un slazdus, ko bieži pieļauj testēšanas komandas.
Zinot, kādas ir šīs kļūdas, būs vieglāk izvairīties no to pieļaušanas, un tas palielinās jūsu sistēmas testēšanas efektivitāti un precizitāti.
1. Sākot bez testēšanas plāna
Pirms sistēmas testēšanas uzsākšanas ir svarīgi izveidot detalizētu testēšanas plānu.
Ja sākat integrācijas testēšanu bez plāna, ir viegli aizmirst dažus testēšanas gadījumus, kurus plānojat izpildīt, vai testēšanas gadījumus ārpus testēšanas plāna.
Lielākā daļa cilvēku nevar atcerēties visu testēšanas plāna informāciju, ja tā nav skaidri dokumentēta, un tas arī neļauj komandām nodot to citiem testētājiem.
2. Sistēmas testēšanas jomas nenoteikšana
Sistēmas testēšana ir daudzdimensionāls uzdevums, kas ietver daudzu dažādu vienas programmatūras izveides aspektu testēšanu.
Atkarībā no izstrādājamās programmatūras veida un līdz šim testētās programmatūras, sistēmas testēšanas apjoms dažādos testos var ievērojami atšķirties.
Pirms testēšanas uzsākšanas ir svarīgi definēt testēšanas darbības jomu un nodrošināt, lai visi testēšanas komandas locekļi šo darbības jomu izprastu.
3. Viltus pozitīvu un viltus negatīvu rezultātu ignorēšana
Viltus pozitīvie rezultāti rodas tad, ja sistēmas testi ir veiksmīgi, lai gan testa scenāriji faktiski nedarbojas, kā paredzēts.
Līdzīgi var rasties arī kļūdaini negatīvi rezultāti, ja tests neizdodas, lai gan darbojas, kā paredzēts.
Dažreiz var būt grūti noteikt viltus pozitīvos un viltus negatīvos rezultātus, īpaši, ja jūs vienkārši aplūkojat testa rezultātus, neiedziļinoties faktiskajos testa rezultātos. Veicot automatizētu sistēmas testēšanu, viltus pozitīvie un negatīvie rezultāti ir īpaši iespējami un tos ir viegli nepamanīt.
4. Testēšana ar līdzīga veida testa datiem
Ja izmantojat vairākus dažādus testēšanas datu veidus, pēc iespējas dažādojot izmantoto testēšanas datu atribūtus, palielināsiet sistēmas testēšanas pārklājumu.
Tas nozīmē, ka ir mazāka iespēja palaist garām kļūdas un defektus, un tas palielina jūsu veiktās testēšanas vērtību.
Izmantojot dažāda veida testēšanas datus, iegūsiet detalizētāku priekšstatu par to, kā produkts darbosies pēc izlaišanas.
5. Izpētes testēšanas ignorēšana
Lai gan ir svarīgi ievērot testēšanas plānu, ir svarīgi arī atvēlēt vietu izpētes testēšanai un ļaut testētājiem izmēģināt dažādas iespējas un funkcijas, kad viņi tās atrod testēšanas laikā.
Izpētes testēšana bieži var atklāt jaunas kļūdas, kas citādi netiktu pamanītas, vai kļūdas, kas jau ir pamanītas citos testēšanas posmos.
Jūs pat varat plānot izpētes testēšanas sesijas, organizējot testu sesijas, kurās visi testētāji noteiktu laiku veic neplānotu sistēmas testēšanu.
6. Regulāra testu automatizācijas rezultātu nepārskatīšana
Ja esat iesācējs programmatūras sistēmu testēšanā un jo īpaši automatizētajā testēšanā, jūs, iespējams, domājat, ka varat vienkārši iestatīt testa izpildi un atstāt to.
Taču ir svarīgi regulāri pārskatīt testēšanas automatizācijas rezultātus un vajadzības gadījumā veikt izmaiņas testēšanas automatizācijas kodā.
Piemēram, ja testējamā programmatūrā tiek veiktas kādas izmaiņas, tām jāatspoguļojas automātisko testu kodā.
Rūpīgi izlasiet automātisko testu rezultātus, lai saprastu visus testa rezultātus, nevis tikai pozitīvos/negatīvos rezultātus.
7. Nepareiza automatizācijas rīka izmantošana
Mūsdienās ir pieejami daudzi automatizācijas rīki, no kuriem dažus var izmantot bez maksas, bet par citiem lietotājiem jāmaksā ikmēneša maksa.
Lai gan iesācēji parasti izvēlas atvērtā koda rīkus, ir svarīgi pārliecināties, vai izvēlētais rīks atbilst jūsu prasībām un piedāvā nepieciešamās funkcijas.
Piemēram, atvērtā koda rīki ir labi pazīstami ar savu ierobežoto funkcionalitāti, neintuitīvo lietotāja interfeisu un ļoti sarežģīto mācīšanās līkni.Turpretī pilnas paketes testēšanas rīki, piemēram, ZAPTEST Free Edition, nodrošina augstākās klases testēšanas un RPA funkcionalitāti, piemēram, 1SCRIPT, Cross Browser, Cross Device, Cross Platform Technology, viegli lietojamā interfeisā bez koda, kas ir piemērots gan netehniskajiem, gan pieredzējušiem testētājiem.
Turklāt dažkārt ir vērts ieguldīt līdzekļus nedaudz dārgākā uzņēmuma līmeņa automatizācijas rīkā, ja tā piedāvātās funkcijas ir daudz piemērotākas jūsu projektam.
Secinājums
Sistēmas testēšana ir svarīgs programmatūras testēšanas posms, kas pārbauda sistēmu kopumā un pārliecinās, ka katra atsevišķa komponente darbojas vienoti, vienmērīgi un efektīvi.
Tas ir programmatūras testēšanas posms pēc integrācijas testēšanas un pirms lietotāja pieņemšanas testēšanas, un tas ir viens no pēdējiem oficiālajiem programmatūras testēšanas posmiem pirms sākotnējās izlaišanas.
Sistēmas testēšana ļauj testētājiem identificēt dažāda veida kļūdas, tostarp funkcionālās un nefunkcionālās kļūdas, kā arī lietojamības kļūdas un konfigurācijas defektus.
Sistēmas testēšanu ir iespējams veikt manuāli vai automatizēt sistēmas testēšanu, lai gan vairumā gadījumu ir ieteicams izmantot hibrīda pieeju, lai palielinātu efektivitāti, vienlaikus atvēlot vietu izpētes testēšanai.
Ievērojot paraugpraksi un izvairoties no sistēmas testēšanā bieži sastopamajām kļūdām, testēšanas komandas var veikt precīzus un efektīvus sistēmas testus, kas aptver lielāko daļu svarīgāko izveides jomu.
Biežāk uzdotie jautājumi un resursi
Ja esat iesācējs sistēmu testēšanā, tiešsaistē ir pieejami daudzi resursi, kas var palīdzēt jums uzzināt vairāk par sistēmu testēšanu un to, kā veikt sistēmu testus.
Zemāk ir sniegta informācija par dažiem noderīgiem tiešsaistes sistēmas testēšanas resursiem, kā arī atbildes uz dažiem visbiežāk uzdotajiem jautājumiem par sistēmas testiem.
1. Labākie kursi par sistēmu testēšanu
Tiešsaistes kursu apmeklēšana sistēmu testēšanā vai programmatūras testēšanā var palīdzēt QA speciālistiem pilnveidot izpratni par sistēmu testēšanu un iegūt kvalifikāciju, kas apliecina šīs zināšanas.
Tiešsaistes mācību vietnes, piemēram, Coursera, Udemy, edX un Pluralsight, piedāvā bezmaksas un maksas kursus programmatūras testēšanas un automatizācijas jomā profesionāļiem un iesācējiem.
Daži tiešsaistes kursu piemēri sistēmu testēšanā ir šādi:
- Pilnīgs 2023 programmatūras testēšanas sākumlapa, Udemy
- Programmatūras testēšanas un automatizācijas specializācija, Coursera
- Automatizēta programmatūras testēšana, edX
- Automatizēta programmatūras testēšana ar Python, Udemy
- Biznesa analītiķis: Programmatūras testēšanas procesi un metodes, Udemy
Meklējiet tiešsaistes kursus, kas atbilst jūsu pieredzes līmenim un budžetam. Ja strādājat kvalitātes nodrošināšanas jomā, iespējams, varēsiet lūgt darba devēju sponsorēt akreditētu programmatūras testēšanas kursu.
2. Kādi ir 5 svarīgākie intervijas jautājumi par sistēmu testēšanu?
Ja gatavojaties intervijai par amatu, kas varētu būt saistīts ar sistēmu testēšanu vai cita veida programmatūras testēšanu, iepriekš sagatavojot atbildes uz biežāk uzdotajiem intervijas jautājumiem, varat uzlabot savu sniegumu intervijas laikā.
Daži no biežāk uzdotajiem intervijas jautājumiem par sistēmu testēšanu ir šādi:
- Ar ko sistēmas testēšana atšķiras no integrācijas testēšanas?
- Kādi ir automatizētas sistēmas testēšanas plusi un mīnusi?
- Cik daudz sistēmu testēšanas veidu jūs varat nosaukt?
- Kā jūs varētu maksimāli palielināt testu pārklājumu sistēmas testēšanas laikā?
- Kāda veida kļūdas un defektus jūs sagaidītu atrast sistēmas testos?
Varat izmantot šos jautājumus, lai jau pirms intervijas sagatavotu atbildes pēc STAR struktūras, izmantojot karjeras piemērus, lai parādītu savas zināšanas par sistēmu testēšanu un citiem programmatūras testēšanas veidiem.
3. Labākās YouTube pamācības par sistēmas testēšanu
Ja esat vizuāli domājošs skolēns, jums, iespējams, būs vieglāk saprast, kas ir sistēmas testēšana un kā tā darbojas līdzās citiem programmatūras testēšanas veidiem, skatoties videoklipus par sistēmas testēšanu.
Vietnē YouTube ir pieejami daudzi videoklipi, kuros izskaidrots, kas ir sistēmas testēšana un kā sākt sistēmas testēšanu neatkarīgi no tā, vai vēlaties to veikt manuāli vai ar automatizācijas rīkiem. Dažas no labākajām YouTube pamācībām par sistēmas testēšanu:
- Kas ir sistēmas testēšana?
- Pieņemšanas testēšana un sistēmas testēšana
- Kas ir sistēmas testēšana un kā tā darbojas?
- Sistēmas integrācijas testēšana ar reālā laika piemēru
- Kas ir sistēmas testēšana programmatūras testēšanā?
4. Kā uzturēt sistēmas testus
Testu uzturēšana ir sistēmas testu un cita veida programmatūras testu pielāgošanas un uzturēšanas process, lai tos atjauninātu, kad tiek veiktas izmaiņas programmatūras izveidē vai mainīts kods.
Piemēram, ja veicat sistēmas testēšanu un atklājat kļūdas un defektus, jūs nosūtīsiet programmatūras kopumu atpakaļ izstrādātājiem, lai tie veiktu korekcijas. Testēšanas komandām var nākties uzturēt testēšanas skriptus, lai pārliecinātos, ka tās pienācīgi testē jauno programmatūras kopumu, kad ir pienācis laiks testēt vēlreiz.
Testu uzturēšana ir svarīgs programmatūras testēšanas aspekts, un testētāji var nodrošināt programmatūras uzturēšanu, ievērojot uzturēšanas paraugpraksi.
Tie ietver:
1. Sadarbība:
Izstrādātājiem un testētājiem ir jāsadarbojas, lai nodrošinātu, ka testētāji zina, kuri koda aspekti ir mainīti un kā tas var ietekmēt testa skriptus.
2. Dizains:
Izstrādājiet testu skriptus, pirms sākat automatizēt testus. Tas nodrošina, ka automatizētie testi vienmēr ir piemēroti paredzētajam mērķim.
3. Process:
Projektēšanas procesā ņemiet vērā programmatūras testēšanas uzturēšanu. Atcerieties, ka jums būs jāuztur testi, un ņemiet to vērā plānošanā, testu plānos un testu izstrādē.
4. Ērtība:
Ja iespējams, atjauniniet visus testus, tostarp sistēmas testus un pareizības testus, no viena paneļa.
Tas nozīmē, ka testu atjaunināšana ir daudz ātrāka un ērtāka, kā arī samazina risku aizmirst atjaunināt konkrētu testu, ja programmatūras komplektā ir veiktas izmaiņas.
Vai sistēmas testēšana ir “baltās kastes” vai “melnās kastes” testēšana?
Sistēmas testēšana ir “melnās kastes” testēšanas veids.
Melnās kastes testēšana atšķiras no baltās kastes testēšanas ar to, ka tajā tiek ņemtas vērā tikai programmatūras ārējās funkcijas un īpašības. Baltās kastes testēšana pārbauda, kā programmatūra darbojas iekšēji, piemēram, kā kods darbojas un darbojas kopā.
Melnās kastes testēšanai nav nepieciešamas zināšanas par sistēmas iekšējo darbību vai kodu, tā vietā testētājiem ir vienkārši jāpārbauda programmatūras lietojumprogrammas rezultāti un funkcijas un jānovērtē to atbilstība noteiktiem kritērijiem.
Sistēmas testēšana ietver gan funkcionālo, gan nefunkcionālo testēšanu, taču testētāji izmanto melnās kastes tehniku, lai testētu pat nefunkcionālos izveides aspektus.
Šā iemesla dēļ sistēmas testēšana parasti tiek uzskatīta par “melnās kastes” testēšanas veidu.
