fbpx

 

Sistemos testavimas – tai programinės įrangos testavimo rūšis, kai tikrinama visa sistema.

Tai apima visų atskirų sukurtos programinės įrangos modulių ir komponentų integravimą, siekiant patikrinti, ar sistema veikia taip, kaip tikėtasi.

Sistemos testavimas yra esminis programinės įrangos testavimo etapas, kuris dar labiau leis testavimo komandoms patikrinti sukurto produkto kokybę prieš jį pateikiant galutiniams naudotojams.

Šiame straipsnyje nagrinėsime sistemos testavimą: kas tai yra, kaip jis veikia, kas atlieka sistemos testavimą ir kokius metodus bei įrankius gali naudoti testavimo komandos, kad sistemos testavimas būtų greitesnis ir patikimesnis.

Trumpai tariant, čia rasite viską, ką reikia žinoti apie sistemos testavimą.

 

Table of Contents

Kas yra sistemos testavimas?

 

Sistemos testavimas – tai programinės įrangos testavimo rūšis, kai visada testuojama visa sistema. Ji tikrina, ar sistema atitinka jai keliamus reikalavimus, kad ir kokie jie būtų.

Testuotojai atlieka sistemos testavimą, kad įvertintų sistemos funkcinius ir nefunkcinius reikalavimus po to, kai atskiri moduliai ir komponentai buvo integruoti kartu.

Sistemos testavimas yra juodosios dėžės testavimo kategorija, t. y. testuojamos tik išorinės veikiančios programinės įrangos funkcijos, o ne vidinė programos konstrukcija.

Testuotojams nereikia jokių programavimo ir programinės įrangos kodo struktūros žinių, kad galėtų visapusiškai įvertinti programinės įrangos kūrimą atliekant sistemos testavimą. Vietoj to testuotojai tiesiog vertina programinės įrangos veikimą iš naudotojo perspektyvos.

 

1. Kada reikia atlikti sistemos testavimą?

 

Sistemos testavimas atliekamas po integracijos testavimo ir prieš priėmimo testavimą. Sistemos testavimą reguliariai atlieka programinės įrangos testavimo komanda, kad užtikrintų, jog sistema veikia taip, kaip turėtų veikti svarbiausiais kūrimo etapais.

Keletas pavyzdžių, kai atliekamas sistemos testavimas:

● Kuriant naujas programinės įrangos versijas.

● Programos paleidimo metu, kai vyksta alfa ir beta testavimas.

● Baigus vieneto ir integracijos testavimą.

● Kai sistemos kūrimo reikalavimai yra įvykdyti.

● Kai tenkinamos kitos testavimo sąlygos.

Kaip ir kitus programinės įrangos testavimo būdus, rekomenduojama reguliariai atlikti sistemos testavimą, kad būtų užtikrinta, jog programinė įranga veikia taip, kaip turi veikti.

Sistemos testavimo dažnumas priklauso nuo jūsų komandos išteklių ir metodų bei įrankių, kuriuos naudojate sisteminei programinei įrangai testuoti.

 

2. Kai nereikia sistemos testų

 

Jei dar neatlikote preliminarių bandymų, pavyzdžiui, ” dūmų” testų, vieneto testų ir integracijos testų, vadinasi, dar nesate pasirengę pradėti sistemos testavimo.

Visada svarbu atlikti sistemos testavimą baigus integracinį testavimą, tačiau jei susidūrėte su klaidomis ir problemomis, dėl kurių sistemos testas nepavyko, galite nutraukti sistemos testavimą ir grįžti prie kūrimo bei klaidų taisymo prieš tęsdami tolesnius veiksmus.

 

3. Kas dalyvauja sistemos testavime?

 

Sistemos testavimą atlieka ne kūrėjai, o testuotojai ir kokybės užtikrinimo komandos. Atliekant sistemos bandymus atsižvelgiama tik į išorinius programinės įrangos elementus arba, kitaip tariant, į naudotojų, bandančių naudotis programinės įrangos funkcijomis, patirtį.

Tai reiškia, kad testuotojams, atliekantiems sistemos testavimą, nereikia jokių techninių žinių apie kompiuterių kodavimą, programavimą ir kitus programinės įrangos kūrimo aspektus, kuriuos gali reikėti įvesti iš kūrėjų.

Vienintelė išimtis – automatinis sistemos testavimas, kuriam gali prireikti tam tikro kūrėjų indėlio, priklausomai nuo to, kaip į tai žiūrite.

 

Ką tikriname atlikdami sistemos testavimą?

 

Sistemos testavimas – tai programinės įrangos testavimo rūšis, naudojama tiek funkciniams, tiek nefunkciniams programinės įrangos aspektams testuoti.

Ją galima naudoti įvairiausioms funkcijoms ir savybėms testuoti, daugelis iš jų išsamiau aprašytos sistemos testavimo tipuose.

Toliau išsamiai aprašyti kai kurie programinės įrangos aspektai, kuriuos tikrina sistemos testavimas.

 

1. Funkcionalumas

Testuotojai naudoja sistemos testavimą, kad patikrintų, ar įvairūs užbaigtos sistemos aspektai veikia taip, kaip turėtų veikti.

Atliekant išankstinį testavimą galima įvertinti vidinio kodo struktūrą ir logiką, taip pat tai, kaip skirtingi moduliai integruojami tarpusavyje, tačiau sistemos testavimas – tai pirmasis žingsnis, kurio metu tokiu būdu tikrinamas visos programinės įrangos funkcionalumas.

 

2. Integracija

Testuojant sistemą tikrinama, kaip skirtingi programinės įrangos komponentai veikia kartu ir ar jie sklandžiai dera tarpusavyje.

Testuotojai taip pat gali išbandyti išorinius periferinius įrenginius ir įvertinti, kaip jie sąveikauja su programine įranga ir ar tinkamai veikia.

 

3. Laukiama produkcija

Testuotojai naudoja programinę įrangą taip, kaip naudotojas ją naudotų sistemos testavimo metu, kad patikrintų programinės įrangos rezultatus įprasto naudojimo metu. Jie tikrina, ar kiekvienos programinės įrangos funkcinės ir nefunkcinės savybės išvestis atitinka lūkesčius.

Jei programinė įranga nesielgia taip, kaip turėtų, akivaizdu, kad ją reikia toliau tobulinti.

 

4. Klaidos ir klaidos

Sistemos testavimas naudojamas programinės įrangos funkcionalumui ir patikimumui įvairiose platformose ir operacinėse sistemose įvertinti.

Sistemos bandytojai tikrina, ar programinėje įrangoje nėra klaidų, našumo problemų ir suderinamumo problemų visose platformose, kuriose programinė įranga turėtų veikti.

 

Įėjimo ir išėjimo kriterijai

 

Įėjimo ir išėjimo kriterijai naudojami sistemos bandymuose, siekiant nustatyti, ar sistema yra parengta sistemos bandymams ir ar įvykdyti sistemos bandymų reikalavimai.

Kitaip tariant, įėjimo ir išėjimo kriterijai padeda testuotojams įvertinti, kada pradėti ir kada baigti sistemos testavimą.

 

Stojimo kriterijai

Įvedimo kriterijai nustato, kada testuotojai turėtų pradėti sistemos testavimą.

Priklausomai nuo testavimo tikslo ir taikomos testavimo strategijos, skirtinguose projektuose gali skirtis įtraukimo kriterijai.

Įvedimo kriterijai nurodo sąlygas, kurios turi būti įvykdytos prieš pradedant sistemos testavimą.

 

1. Testavimo etapas

Daugeliu atvejų, prieš pradedant sistemos testavimą, svarbu, kad testuojama sistema jau būtų baigusi integracijos testavimą ir atitiktų integracijos testavimui keliamus išėjimo reikalavimus.

Atliekant integracijos bandymus neturėjo būti nustatyta didelių klaidų ar problemų, susijusių su komponentų integracija.

 

2. Planai ir scenarijai

Prieš pradedant sistemos bandymus, reikia parašyti, pasirašyti ir patvirtinti bandymų planą.

Taip pat turėsite iš anksto parengti testavimo atvejus ir testavimo scenarijus, kurie bus paruošti vykdymui.

 

3. Pasirengimas

Patikrinkite, ar parengta testavimo aplinka ir ar yra visi nefunkciniai testo reikalavimai.

Skirtinguose projektuose pasirengimo kriterijai gali skirtis.

 

Išėjimo kriterijai

 

Išeities kriterijai apibrėžia galutinį sistemos testavimo etapą ir nustato reikalavimus, kurie turi būti įvykdyti, kad sistemos testavimas būtų laikomas baigtu.

Išėjimo kriterijai dažnai pateikiami kaip vienas dokumentas, kuriame tiesiog nurodomi šio testavimo etapo rezultatai.

 

1. Vykdymas

Pats svarbiausias sistemos testavimo užbaigimo kriterijus yra tas, kad visi testavimo atvejai, nurodyti sistemos testavimo planuose ir įvesties kriterijuose, buvo tinkamai atlikti.

 

2. Klaidos

Prieš baigdami sistemos testavimą patikrinkite, ar nėra kritinių arba prioritetinių klaidų.

Vidutinio ir mažo prioriteto klaidos gali būti paliktos atviros, jei joms įgyvendinti pritaria klientas arba galutinis naudotojas.

 

3. Ataskaitų teikimas

Prieš pasibaigiant sistemos bandymams, reikia pateikti išėjimo ataskaitą. Šioje ataskaitoje užfiksuojami sistemos bandymų rezultatai ir įrodoma, kad bandymai atitiko reikalaujamus išėjimo kriterijus.

 

Sistemos testavimo gyvavimo ciklas

 

Sistemos testavimo gyvavimo ciklas apibūdina kiekvieną sistemos testavimo etapą nuo planavimo etapų iki ataskaitų pateikimo ir užbaigimo.

Suprasdami kiekvieną sistemos testavimo gyvavimo ciklo etapą, suprasite, kaip atlikti sistemos testavimą ir kaip jis veikia.

 

1 etapas: sukurti bandymų planą

 

Pirmasis sistemos testavimo etapas – sistemos testavimo plano sudarymas.

Bandymų plano tikslas – apibrėžti bandymų atvejų lūkesčius ir bandymų strategiją.

Testavimo plane paprastai apibrėžiami testavimo tikslai ir uždaviniai, apimtis, sritys, rezultatai, tvarkaraštis, įėjimo ir išėjimo kriterijai, testavimo aplinka, programinės įrangos sistemos testavime dalyvaujančių žmonių vaidmenys ir atsakomybė.

 

2 etapas: sukurti testavimo atvejus

 

Kitas sistemos testavimo etapas – testavimo atvejų kūrimas.

Testavimo atvejai apibrėžia tikslias funkcijas, ypatybes ir rodiklius, kuriuos ketinate tikrinti sistemos testavimo metu. Pavyzdžiui, galite išbandyti, kaip veikia tam tikra funkcija arba kiek laiko trunka tam tikras įkrovimo laikas.

Kiekvienam bandymo atvejui nurodykite bandymo atvejo ID ir pavadinimą, taip pat informaciją apie tai, kaip testuoti šį scenarijų ir koks yra tikėtinas bandymo atvejo rezultatas.

Čia taip pat galite išdėstyti kiekvieno testavimo atvejo įveikimo/neįveikimo kriterijus.

 

3 etapas: sukurti bandomuosius duomenis

 

Sukūrę bandymų atvejus, galite sukurti bandymų duomenis, kurie bus reikalingi bandymams atlikti.

Testavimo duomenys apibūdina įvesties duomenis, kurių testavimo komandai reikės norint patikrinti, ar jų veiksmai duoda laukiamus rezultatus.

 

4 etapas: testavimo atvejų vykdymas

 

Dauguma žmonių, galvodami apie sistemos testavimą, galvoja apie šį etapą: testavimo atvejų vykdymą arba patį testavimą.

Testavimo komanda vykdys kiekvieną testavimo atvejį atskirai, stebėdama kiekvieno testo rezultatus ir fiksuodama visas aptiktas klaidas ar gedimus.

 

5 etapas: Praneškite apie klaidas ir jas ištaisykite

 

Atlikę testavimo atvejus, testuotojai parengia sistemos testavimo ataskaitą, kurioje išsamiai aprašo visas testavimo metu iškilusias problemas ir klaidas.

Kai kurios testo metu aptiktos klaidos gali būti nedidelės ir lengvai ištaisomos, o kitos gali trukdyti kurti. Ištaisykite atsiradusias klaidas ir vėl pakartokite testavimo ciklą (į kurį įeina ir kiti programinės įrangos testavimo būdai, pvz., ” dūmų” testavimas), kol bus ištaisyta be didesnių klaidų.

 

Išaiškinti painiavą: Sistemos testavimas vs integracijos testavimas vs naudotojo priėmimo testavimas

 

Daugelis žmonių painioja sistemos testavimą su kitų tipų programinės įrangos testavimu, pavyzdžiui, integracijos testavimu ir vartotojo priėmimo testavimu.

Nors sistemos testavimas, integracinis testavimas ir naudotojo priėmimo testavimas turi tam tikrų bendrų bruožų, tai yra skirtingi testavimo tipai, skirti skirtingiems tikslams, ir kiekvienas testavimo tipas turi būti atliekamas nepriklausomai nuo kitų.

 

Kas yra integracijos testavimas?

 

Integracijos testavimas – tai programinės įrangos testavimo rūšis, kai programinės įrangos moduliai ir komponentai testuojami kaip grupė, kad būtų galima įvertinti, kaip gerai jie tarpusavyje integruoti.

Integracijos testavimas – tai pirmasis programinės įrangos testavimo tipas, naudojamas atskiriems moduliams, veikiantiems kartu, išbandyti.

Integracijos testavimą atlieka QA aplinkos testuotojai, ir jis yra labai svarbus, nes atskleidžia defektus, kurie gali atsirasti, kai atskirai koduojami komponentai sąveikauja tarpusavyje.

 

Kuo skiriasi sistemos testavimas ir integracijos testavimas?

 

Nors tiek sistemos testavimas, tiek integracinis testavimas tikrina programinės įrangos kūrimą kaip visumą, tai yra skirtingi programinės įrangos testavimo tipai, kurie veikia skirtingai.

Pirmiausia atliekami integracijos bandymai, o sistemos bandymai atliekami baigus integracijos bandymus. Kiti pagrindiniai skirtumai tarp sistemos testavimo ir integracinio testavimo yra šie:

 

1. Tikslas:

Integracijos testavimo tikslas – įvertinti, ar integruoti atskiri moduliai tinkamai veikia kartu. Sistemos testavimo tikslas – patikrinti, kaip sistema veikia kaip visuma.

 

2. Tipas:

Integracijos testavimu tikrinamas tik funkcionalumas, ir tai nėra priėmimo testavimo rūšis.

Priešingai, atliekant sistemos testavimą tikrinamos ir funkcinės, ir nefunkcinės funkcijos, ir jis priskiriamas priėmimo testavimo kategorijai (bet ne naudotojo priėmimo testavimui).

 

3. Technika:

Integracijos testavimui naudojami ir juodosios, ir baltosios dėžės testavimo metodai, kad būtų galima įvertinti sukurtą programinę įrangą iš naudotojo ir kūrėjo perspektyvos, o sistemos testavimui naudojami tik juodosios dėžės testavimo metodai, kad būtų galima patikrinti programinę įrangą iš naudotojo perspektyvos.

 

4. Vertė:

Integracijos testavimas naudojamas sąsajos klaidoms nustatyti, o sistemos testavimas – sistemos klaidoms nustatyti.

 

Kas yra naudotojo priėmimo testavimas?

 

Vartotojo priėmimo testavimas (angl. User acceptance testing, UAT) – tai programinės įrangos testavimas, kurį atlieka galutinis vartotojas arba klientas, norėdamas patikrinti, ar programinė įranga atitinka pageidaujamus reikalavimus.

Vartotojo priėmimo testavimas yra paskutinė testavimo forma, kuri atliekama prieš programinės įrangos perkėlimą į gamybinę aplinką.

Jis atliekamas po to, kai jau yra atlikti funkciniai, integraciniai ir sistemos bandymai.

 

Kokie yra skirtumai tarp sistemos testavimo ir naudotojo priėmimo testavimo?

 

Naudotojo priėmimo testavimu ir integravimo testavimu patvirtinama, ar programinė įranga veikia taip, kaip turi veikti, ir abiejų tipų testavimuose daugiausia dėmesio skiriama tam, kaip programinė įranga veikia kaip visuma.

Tačiau yra daug skirtumų tarp sistemos testavimo ir naudotojo priėmimo testavimo:

 

1. Bandymų atlikėjai:

Sistemos testavimą atlieka testuotojai (ir kartais kūrėjai), o naudotojo priėmimo testavimą atlieka galutiniai naudotojai.

 

2. Tikslas:

Vartotojo priėmimo testavimo tikslas – įvertinti, ar programinė įranga atitinka galutinio naudotojo reikalavimus, o sistemos testavimo tikslas – patikrinti, ar sistema atitinka testuotojo reikalavimus.

 

3. Metodas:

Atliekant sistemos testavimą, atskiri programinės įrangos kūrimo vienetai integruojami ir testuojami kaip visuma. Naudotojo priėmimo testavimo metu galutinis naudotojas testuoja visą sistemą.

 

4. Etapas:

Sistemos testavimas atliekamas iškart po to, kai baigiamas integracinis testavimas, ir prieš atliekant naudotojo priėmimo testavimą. Vartotojo priėmimo testavimas atliekamas prieš pat išleidžiant gaminį, kai jį dar tik pradeda naudoti pirmieji vartotojai.

 

Sistemos testavimo tipai

 

Yra daugiau kaip 50 skirtingų sistemos testavimo tipų, kuriuos galite taikyti, jei norite patikrinti, kaip veikia visa jūsų programinės įrangos sąranka.

Tačiau praktikoje dauguma testavimo komandų iš tikrųjų naudoja tik kelis iš šių sistemos testavimo tipų.

Tai, kokį sistemos testavimo būdą pasirinksite, priklauso nuo daugybės įvairių veiksnių, įskaitant biudžetą, laiko apribojimus, prioritetus ir išteklius.

 

1. Funkcionalumo testavimas

 

Funkcionalumo testavimas – tai sistemos testavimo rūšis, kurios tikslas – patikrinti atskiras programinės įrangos savybes ir funkcijas ir įvertinti, ar jos veikia taip, kaip turėtų.

Šis sistemos testavimo tipas gali būti atliekamas rankiniu arba automatiniu būdu ir yra vienas iš pagrindinių sistemos testavimo tipų, kurį atlieka testavimo komandos.

 

2. Veiklos testavimas

 

Našumo testavimas – tai sistemos testavimo rūšis, kai tikrinama, kaip gerai programa veikia įprasto naudojimo metu.

Tai taip pat vadinama atitikties testavimu, kuris paprastai reiškia, kad testuojamas programos veikimas, kai ja vienu metu naudojasi keli naudotojai.

Atlikdami našumo bandymus testuotojai tikrina įkrovimo laiką, taip pat klaidas ir kitas problemas.

 

3. Apkrovos testavimas

 

Apkrovos testavimas – tai sistemos testavimo rūšis, kurią testuotojai atlieka norėdami įvertinti, kaip gerai programa susidoroja su didelėmis apkrovomis.

Pavyzdžiui, bandytojai gali tikrinti, kaip gerai programa veikia, kai daugybė naudotojų vienu metu bando atlikti tą pačią užduotį, arba kaip gerai programa atlieka kelias užduotis vienu metu.

 

4. Masteliškumo testavimas

 

Masteliškumo testavimas – tai programinės įrangos sistemos testavimo tipas, kuriuo tikrinama, kaip gerai programinė įranga pritaikoma įvairių projektų ir komandų poreikiams.

Tai nefunkcinio testavimo rūšis, kai vertinama, kaip programinė įranga veikia skirtingam naudotojų skaičiui arba kai ji naudojama skirtingose vietose ir su skirtingais ištekliais.

 

5. Naudojamumo testavimas

 

Naudojamumo testavimas – tai sistemos testavimo rūšis, kurios metu tikrinama, ar programa yra tinkama naudoti.

Tai reiškia, kad testuotojai vertina ir įvertina, kaip lengva naršyti ir naudotis programa, kiek intuityvios jos funkcijos, ar nėra klaidų ir problemų, dėl kurių gali kilti naudojimo patogumo problemų.

 

6. Patikimumo testavimas

 

Patikimumo testavimas – tai sistemos integracijos testavimo rūšis, kuria tikrinama, ar programinė įranga yra patikima.

Tam reikia išbandyti programinės įrangos funkcijas ir veikimą kontroliuojamoje aplinkoje, kad būtų galima įvertinti, ar vienkartinių bandymų rezultatai yra patikimi ir pakartojami.

 

7. Konfigūracijos testavimas

 

Konfigūracijos testavimas – tai sistemos testavimo rūšis, kai vertinama, kaip sistema veikia kartu su įvairių tipų programine ir technine įranga.

Konfigūracijos testavimo tikslas – nustatyti geriausią programinės ir aparatinės įrangos konfigūraciją, kad būtų maksimaliai padidintas visos sistemos našumas.

 

8. Saugumo testavimas

 

Saugumo testavimas – tai sistemos testavimo rūšis, kai vertinama, kaip programinė įranga veikia saugumo ir konfidencialumo atžvilgiu.

Saugumo testavimo tikslas – nustatyti visas galimas silpnąsias vietas ir pavojus, dėl kurių gali būti pažeisti duomenys ir padaryti pažeidimai, dėl kurių gali būti prarasti pinigai, konfidencialūs duomenys ir kitas svarbus turtas.

 

9. Migracijos testavimas

Migracijos testavimas – tai tam tikras sistemos testavimas, atliekamas su programinės įrangos sistemomis, siekiant įvertinti, kaip jos gali sąveikauti su senesnėmis ar naujesnėmis infrastruktūromis.

Pavyzdžiui, bandytojai gali įvertinti, ar senesni programinės įrangos elementai gali būti perkelti į naują infrastruktūrą be klaidų ir klaidų.

 

Ko reikia norint pradėti vykdyti sistemos testavimą

 

Prieš pradedant sistemos testavimą svarbu turėti aiškų planą, kaip sutelkti išteklius ir priemones, kurių reikia sėkmingam ir sklandžiam sistemos testavimo procesui.

Tai gana sudėtingas procesas, nesvarbu, ar testuojate rankiniu, automatiniu, ar abiem būdais, todėl, prieš pradėdami testuoti, žinokite, ko jums reikės, ir taip sumažinsite vėlavimo ir trikdžių testavimo metu riziką.

 

1. Stabilus beveik paruoštas paleidimui

 

Sistemos testavimas yra vienas iš paskutiniųjų programinės įrangos testavimo etapų prieš išleidimą: vienintelis testavimo tipas, kuris atliekamas po sistemos testavimo, yra naudotojo priėmimo testavimas.

Svarbu, kad prieš pradėdami sistemos testavimą jau būtumėte atlikę kitų tipų programinės įrangos testavimą, įskaitant funkcinį testavimą, regresijos testavimą ir integracinį testavimą, ir kad jūsų programinės įrangos kūrimas atitiktų kiekvieno iš šių tipų programinės įrangos testų išėjimo kriterijus.

 

2. Sistemos testavimo planai

 

Prieš pradėdami testavimą, parengkite oficialius dokumentus, kuriuose būtų aprašyta ketinamų atlikti testų paskirtis ir tikslai bei apibrėžti sistemos testavimo pradžios ir pabaigos kriterijai.

Šį planą galite naudoti atskiriems bandymų scenarijams, kuriuos ketinate išbandyti, arba lūkesčiams, kaip sistema veiks, apibrėžti.

Sistemos testavimo planas turėtų palengvinti testuotojams sukurti ir atlikti sistemos testavimą laikantis plano.

 

3. Testavimo atvejai

 

Prieš pradedant sistemos testavimą svarbu apsibrėžti testavimo atvejus, kuriuos ketinate testuoti sistemos testavimo metu.

Testavimo atvejai gali būti neišsamūs, tačiau jie turi būti pakankamai išsamūs, kad būtų galima patikrinti svarbiausias funkcines ir nefunkcines sistemos savybes ir tiksliai apžvelgti visą sistemos veikimą.

 

4. Įgūdžiai ir laikas

 

Prieš pradėdami sistemos bandymus įsitikinkite, kad sistemos bandymams skirsite pakankamai išteklių.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

Sistemos testavimas gali užtrukti gana ilgai, ypač palyginti su kitais testavimo būdais, pvz., „dūmų” testavimu.

Turėsite nustatyti, kurie jūsų komandos žmonės atliks testavimą ir kiek laiko jiems reikės skirti iki testavimo pradžios.

 

5. Sistemos testavimo įrankiai

 

Sistemos testavimą galima atlikti rankiniu būdu arba automatizuotai, tačiau nepriklausomai nuo to, kokio požiūrio į testavimą laikotės, galima supaprastinti ir optimizuoti sistemos testavimo darbo eigą naudojant įrankius ir technologijas, padedančias atlikti įvairius testavimo aspektus.

Pavyzdžiui, galite naudoti dirbtinio intelekto įrankius, kad automatizuotumėte kai kuriuos sistemos bandymus, arba dokumentų valdymo programinę įrangą, kad galėtumėte stebėti bandymų eigą ir rezultatus.

 

Sistemos testavimo procesas

 

Prieš pradedant svarbu suprasti sistemos testavimo procesą ir kaip atlikti kiekvieną jo etapą.

Šis žingsnis po žingsnio planas atitinka anksčiau aprašytą sistemos testavimo gyvavimo ciklą, tačiau jame išsamiau aprašomi atskiri sistemos testavimo etapai.

 

1 žingsnis: Sukurkite sistemos testavimo planą

 

Prieš pradėdami sistemos testavimą, sukurkite sistemos testavimo planą. Kiekvienos sistemos testavimo planas bus skirtingas, tačiau į planą turėtų būti įtrauktas bent jau testavimo tikslas, taip pat atitinkami įėjimo ir išėjimo kriterijai, pagal kuriuos nustatoma, kada testavimas turi būti pradėtas ir kada baigtas.

 

2 veiksmas: sukurkite bandymų scenarijus ir bandymų atvejus

 

Kitas etapas – sukurti testavimo scenarijus ir testavimo atvejus, kuriuose tiksliai nurodoma, ką ir kaip ketinate testuoti.

Įtraukite realius bandymų scenarijus, kuriais tikrinama, kaip programinė įranga veikia įprastomis naudojimo sąlygomis, ir į kiekvieną parašytą bandymų atvejį įtraukite išsamią informaciją apie testo teigiamo ir neigiamo rezultato kriterijus ir tikėtiną rezultatą.

 

3 žingsnis: Sukurkite reikiamus bandymų duomenis

 

Sukurkite reikiamus bandymų duomenis kiekvienam planuojamam vykdyti bandymų scenarijui.

Bandymų duomenys, kurių reikės kiekvienam planuojamam vykdyti bandymų scenarijui, – tai visi bandymų duomenys, kurie turi įtakos kiekvienam konkrečiam bandymui arba kuriuos jis veikia.

Testavimo duomenis galima generuoti rankiniu būdu arba šį etapą galima automatizuoti, jei norite sutaupyti laiko ir turite tam reikalingų išteklių.

 

4 veiksmas: sukurkite bandomąją aplinką

 

Kitas žingsnis – sukurti bandymų aplinką, paruoštą sistemos bandymams atlikti. Sistemos testavimo rezultatai bus geresni, jei sukursite į gamybinę panašią testavimo aplinką.

Įsitikinkite, kad jūsų testavimo aplinkoje yra visa programinė ir techninė įranga, kurią norite išbandyti konfigūravimo ir integravimo testavimo metu.

 

5 veiksmas: Atlikti bandymų atvejus

 

Sukūrę testavimo aplinką, galite vykdyti antrajame žingsnyje sukurtus testavimo atvejus.

Šiuos testavimo atvejus galite atlikti rankiniu būdu arba galite automatizuoti testavimo atvejų vykdymą naudodami scenarijų.

Atlikdami kiekvieną testavimo atvejį, pasižymėkite testo rezultatus.

 

6 veiksmas: Parengti pranešimus apie klaidas

 

Atlikę visus nurodytus bandymų atvejus, galite pasinaudoti kiekvieno bandymo rezultatais ir parengti klaidų ataskaitas, kuriose išsamiai nurodysite visas sistemos bandymų metu nustatytas klaidas ir defektus.

Perduokite šį pranešimą kūrėjams, kad jie ištaisytų klaidas ir jas ištaisytų. Klaidų taisymo etapas gali užtrukti šiek tiek laiko, priklausomai nuo nustatytų klaidų sudėtingumo ir rimtumo.

 

7 veiksmas: pakartotinis bandymas po klaidų taisymo

 

Kai programinės įrangos kūrėjai, ištaisę klaidas, išsiunčia programinę įrangą tolesniam testavimui, svarbu dar kartą išbandyti programinės įrangos rinkinį.

Labai svarbu, kad sistemos testavimas būtų laikomas baigtu tik tada, kai šis etapas baigiamas ir nėra jokių klaidų ar defektų.

Nepakanka manyti, kad visos klaidos ištaisytos ir kad jau galima pereiti prie naudotojo priėmimo testavimo.

 

8 veiksmas: pakartokite ciklą

 

Paskutinis žingsnis – tiesiog pakartoti šį ciklą tiek kartų, kiek reikia, kad pereitumėte septintąjį žingsnį nenustatę jokių klaidų ar defektų.

Kai sistemos testas bus sėkmingas ir įvykdyti visi sistemos testavimo plane nurodyti išėjimo kriterijai, laikas pereiti prie naudotojo priėmimo testavimo ir galiausiai prie produkto išleidimo.

 

Rankiniai ir automatiniai sistemos testai

 

Kaip ir kitų tipų programinės įrangos testavimas, sistemos testavimas gali būti atliekamas rankiniu būdu testuotojų arba bent iš dalies automatizuotas naudojant programinę įrangą. Programinės įrangos testavimo automatizavimas supaprastina testavimo procesą ir taupo laiką bei pinigus, tačiau kartais svarbu atlikti ir rankinį sistemos testavimą.

Tiek rankinis, tiek automatinis sistemos testavimas turi privalumų ir trūkumų, todėl svarbu juos suprasti prieš nusprendžiant, kurio tipo sistemos testavimą norite atlikti.

 

Rankinis sistemos testavimas

 

Rankinis sistemos testavimas reiškia, kad sistemos testavimas atliekamas rankiniu būdu, neautomatizuojant dalies viso testavimo proceso.

Rankinis sistemos testavimas trunka ilgiau nei automatinis, tačiau tai taip pat reiškia, kad testavimo procesas yra paremtas žmogaus įžvalgomis ir vertinimu.

Rankinis testavimas dažnai derinamas su automatizuotu testavimu, siekiant padidinti sistemos testavimo ir kitų tipų programinės įrangos testų veiksmingumą ir tikslumą.

 

1. Rankinio sistemos testavimo privalumai

 

Rankinis sistemos testavimas turi daug privalumų, todėl daugelis testavimo komandų, net ir automatizavusios testavimo scenarijus, nusprendžia tęsti rankinį ir automatinį testavimą.

 

Sudėtingumas

Rankinis testavimas tinka sudėtingiems testavimo scenarijams, kuriuos ne visada lengva automatizuoti, testuoti.

Jei sistemos testavimo reikalavimai yra sudėtingi arba išsamūs, gali būti lengviau šiuos scenarijus testuoti rankiniu būdu, nei rašyti automatizuotus testavimo scenarijus.

 

Žvalgomasis testavimas

Kai automatizuojate bet kokį programinės įrangos testą, testas atlieka savo scenarijų ir tikrina tik tas funkcijas, kurias užprogramavote įvertinti.

Priešingai, atlikdami testavimą rankiniu būdu, įvairias funkcijas galite tyrinėti tada, kai jos jus sudomina, pavyzdžiui, jei pastebėjote, kad programinės įrangos sąsajoje kažkas atrodo ne taip, kaip turėtų.

 

Paprastumas

Parašius automatinio testavimo scenarijus, automatizuotą testavimą atlikti paprasta. Tačiau norint parašyti testavimo scenarijus, paprastai reikia turėti kūrimo patirties, o mažesnės testavimo komandos gali neturėti tam reikalingų išteklių.

Atliekant rankinį testavimą nereikia jokių techninių žinių ar kodavimo žinių.

 

2. Rankinio sistemos testavimo iššūkiai

 

Rankinis testavimas taip pat kelia savų iššūkių. Programinės įrangos testavimo komandos, kurios atlieka tik rankinį sistemos testavimą, neįtraukdamos automatizuoto testavimo elementų, gali atsidurti nepalankioje padėtyje, palyginti su tomis komandomis, kurios taiko abu metodus.

 

Daug laiko reikalaujantis

Kaip ir galima tikėtis, rankinis sistemos testavimas užima daugiau laiko nei automatinis sistemos testavimas. Tai ypač silpnas trūkumas, kai reikia atlikti judrų testavimą.

Tai reiškia, kad mažiau praktiška atlikti reguliarius ar labai išsamius sistemos bandymus, o tai savo ruožtu gali turėti įtakos rezultatų patikimumui ir apimčiai.

 

Žmogiškoji klaida

Kai testavimą rankiniu būdu atlieka žmonės, visuomet galima žmogiškoji klaida. Žmonės daro klaidų, nuobodžiauja arba išsiblaško, o tai ypač tikėtina atliekant pasikartojančius, daug laiko reikalaujančius bandymus, kurie gali labiau nuvarginti testuotojus.

 

Bandymų aprėptis

Rankiniu būdu atliekami testai neturi tokios plačios aprėpties kaip automatiniai testai.

Kadangi testuotojams tenka patiems atlikti rankinius testus, atliekant rankinį testavimą neįmanoma aprėpti tiek pat sričių, kiek atliekant automatizuotą testavimą, todėl testavimo rezultatai gali būti ne tokie išsamūs.

 

Kada naudoti rankinį programinės įrangos testavimą

Rankinio programinės įrangos testavimo nepakeitė automatinis testavimas, o rankinis testavimas vis dar yra svarbus sistemos testavimo proceso etapas.

Rankinis testavimas tinka mažesnėms programinės įrangos komandoms, kurios gali neturėti išteklių savarankiškai automatizuoti sistemos testavimą, ir net automatizuotą testavimą įdiegusios komandos turėtų naudoti rankinį testavimą, kad įvertintų sudėtingesnius testavimo scenarijus arba testavimo atvejus, kai žvalgomasis testavimas yra naudingas.

 

Sistemos testavimo automatizavimas

Sistemos testavimą galima automatizuoti patiems rašant testavimo scenarijus arba naudojant hiperautomatizavimo įrankius ir procesus, kurie iš dalies arba visiškai automatizuoja sistemos testavimo procesą.

Dažniausiai automatinis sistemos testavimas derinamas su rankiniu sistemos testavimu, kad būtų užtikrintas geriausias aprėpties, efektyvumo ir tikslumo santykis.

 

1. Sistemos testavimo automatizavimo nauda

 

Automatizuotas sistemų testavimas populiarėja iš dalies dėl to, kad yra daug automatizuoto testavimo įrankių, kuriais lengva automatizuoti programinės įrangos sistemų testavimą.

Automatinis sistemos testavimas turi daug privalumų, ypač kai jis derinamas su rankiniu testavimu.

 

Efektyvumas

Automatinis testavimas yra efektyvesnis nei rankinis, nes automatinius testus galima paleisti fone, kol testuotojai ir kūrėjai atlieka kitas užduotis.

Dėl to praktiškiau reguliariai atlikti automatizuotus bandymus ir sumažėja poreikis deleguoti daug išteklių bandymams atlikti po to, kai automatizuoti bandymai jau buvo sukurti.

 

Didesnė testų aprėptis

Automatiniai testai dažnai gali apimti didesnę programinės įrangos kūrimo sritį nei rankiniai testai, iš esmės dėl didesnio jų efektyvumo.

Atlikdami sistemos testavimą rankiniu būdu, testuotojai turi pasirinkti svarbiausius testavimo atvejus, o automatinis testavimas suteikia programinės įrangos komandoms galimybę lanksčiai išbandyti daugiau scenarijų per trumpesnį laiką.

 

Pašalinti žmogiškąsias klaidas

Automatiniai testai nėra pažeidžiami žmogaus klaidų taip, kaip rankiniai testai.

Atliekant pasikartojančius, daug laiko reikalaujančius testus, kurie gali nuvarginti rankinius testuotojus, automatiniai testai ir toliau testuoja programinę įrangą tokiu pačiu greičiu ir tikslumu.

Be to, žmonės labiau linkę sutelkti dėmesį į lengvų klaidų paiešką nei į sudėtingų, todėl gali būti nepastebėtos kai kurios svarbios, bet ne tokios akivaizdžios klaidos.

 

Standartizuoti testavimą

Rašydami scenarijų sistemos testavimui automatizuoti, sukuriate instrukcijų rinkinį, kuriuo turi vadovautis programinės įrangos testavimo įrankis.

Taip veiksmingai standartizuojami atliekami programinės įrangos bandymai ir užtikrinama, kad kiekvieną kartą, kai atliekate bandymą, atliekate tą patį bandymą ir testuojate programinę įrangą pagal tuos pačius standartus.

 

2. Sistemos testavimo automatizavimo iššūkiai

 

Automatizuotas sistemos testavimas nėra tobulas, todėl, siekiant geriausių rezultatų, jis dažnai atliekamas kartu su rankiniu testavimu. Tai efektyvesnis būdas nei rankinis testavimas, tačiau jis gali būti ne toks nuodugnus ir ne toks kokybiškas.

 

Lankstumas

Kadangi automatinis testavimas visada atliekamas pagal scenarijų, nėra galimybės lanksčiai išbandyti mechanizmus ar funkcijas, kurie nėra įrašyti į testavimo scenarijų.

Nors taip užtikrinamas nuoseklumas, tai reiškia, kad klaidų ir trūkumų galima nepastebėti, jei į juos nebuvo atsižvelgta planavimo etapuose.

 

Ištekliai

Automatizuotiems testams sukurti reikia laiko ir išteklių.

Nors sistemos testavimą galima automatizuoti naudojant gatavą programinę įrangą ir įrankius, dažniausiai juos vis tiek reikia pritaikyti prie programinės įrangos reikalavimų.

Tradiciškai automatizuotas testavimas reiškė techninių išteklių skyrimą automatiniams testams tinkamai parašyti ir paleisti, nors vis daugiau įrankių, tokių kaip ZAPTEST, suteikia pažangią kompiuterinės regos programinės įrangos automatizavimo galimybę naudojant bekodę sąsają.

 

Sudėtingi testavimo atvejai

Daugeliu atvejų neįmanoma 100 % automatizuoti sistemos testavimo ir visiškai nesiremti rankiniu testavimu.

Tai ypač aktualu, kai reikia išbandyti sudėtingus testavimo scenarijus, kurių dauguma automatizavimo įrankių nesugeba patikrinti.

 

3. Kada įdiegti automatizuotą sistemos testavimą

 

Jei jūsų testavimo komanda turi išteklių automatizuotam testavimui įgyvendinti, rašydama pasirinktinius testavimo scenarijus arba naudodama automatizavimo įrankius, automatizuotas testavimas gali padaryti sistemos testavimą veiksmingesnį ir patikimesnį.

Tačiau visada svarbu tęsti testavimą rankiniu būdu net ir tada, kai esate įsitikinę automatinių testų kokybe ir aprėptimi, nes automatinis testavimas negali atkartoti gilumo ir įžvalgų, kurias gali suteikti tik rankinis testavimas.

 

Išvados: Automatizuotas sistemos testavimas ir rankinis sistemos testavimas

 

Programinės įrangos kūrimo testavimo etape svarbus ir automatizuotas sistemos testavimas, ir rankinis sistemos testavimas.

Nors mažesnės įmonės gali pradėti tik nuo rankinio sistemos testavimo dėl papildomų investicijų ar išteklių, kurių reikalauja automatizuotas testavimas, dauguma testavimo komandų taiko kombinuotą metodą, apimantį automatizuotą testavimą, kai tik praktiškai gali tai padaryti.

Derindamos automatizuotą testavimą su rankiniu testavimu, testavimo komandos gali padidinti efektyvumą, tikslumą ir lankstumą, nesumažindamos jokių sistemos testavimo rezultatų.

 

Geriausia sistemos testavimo praktika

 

Jei norite optimizuoti sistemos testavimo darbo eigą, kad ji būtų maksimaliai efektyvi ir tiksli, geriausias būdas tai padaryti – vadovautis geriausia sistemos testavimo praktika.

Geriausia praktika gali padėti užtikrinti, kad sistemos testavimo etape nieko nepraleisite, ir garantuoti, kad jūsų sistemos testai visada bus nuosekliai aukšto lygio.

 

1. Tinkamai suplanuokite sistemos bandymus

 

Visi sistemų bandymai turėtų prasidėti nuo oficialaus bandymų plano, kuriame aiškiai išdėstyti bandymų atvejai ir metodai, kurie bus naudojami atliekant bandymus.

Pradedant nuo oficialaus plano, sumažėja vėlavimo atliekant bandymus rizika ir išvengiama trikdžių, galinčių kilti dėl neaiškumų.

Taip užtikrinama, kad visos susijusios šalys žinotų, koks yra jų vaidmuo ir už ką jos yra atsakingos.

 

2. Visada rašykite išsamias ir tikslias ataskaitas.

 

Svarbu, kad sistemos testavimas visada būtų gerai dokumentuotas, kitaip testuotojams ir programinės įrangos kūrėjams gali būti nelengva naudotis testų rezultatais.

Rašykite aiškias, išsamias kiekvieno atlikto bandymo ataskaitas, kuriose išsamiai aprašykite visas rastas klaidas, tiksliai parodykite, kaip jas atkartoti, ir nurodykite, kaip programinė įranga turėtų elgtis, kai bus ištaisyta.

Įsitikinkite, kad pranešimai apie klaidas yra nedviprasmiški ir lengvai suprantami.

 

3. Testavimas tikruose įrenginiuose

 

Dažnai testavimo grupės nusprendžia bandymų aplinkoje atkartoti skirtingus įrenginius, tačiau iš tikrųjų netestuoja programinės įrangos skirtinguose įrenginiuose.

Jei kuriate programinę įrangą, kuri bus naudojama įvairiose platformose, pvz., mobiliuosiuose telefonuose, t. y. „Android”, „iOS” ir kt. planšetės, žiniatinklis ir staliniai kompiuteriai, t. y. „Windows”, Linux” ir kt., būtinai išbandykite juos šiuose įrenginiuose, kad įvertintumėte, kaip jie veikia esant skirtingoms apkrovoms ir ar tinklo ryšio problemos gali sukelti problemų tam tikrose platformose.

 

4. Kur įmanoma, automatizuoti testavimą

 

Norint pasiekti geriausių rezultatų, paprastai geriausia derinti rankinį sistemos testavimą su automatizuotu sistemos testavimu.

Jei dar neeksperimentavote su automatizuotu sistemos integracijos testavimu, išbandykite RPA + programinės įrangos testavimo įrankius, kurie gali padėti automatizuoti bent dalį sistemos testų, ir padidinsite aprėptį bei efektyvumą, nesumažindami rezultatų tikslumo.

 

5. Kiekvieno atvejo testavimas po vieną funkciją

 

Rašydami testavimo atvejus, jei įmanoma, sutelkite dėmesį į vienos funkcijos testavimą.

Tai palengvina pakartotinį šių bandymų atvejų naudojimą būsimuose bandymuose ir leidžia kūrėjams aiškiau suprasti, kaip atsiranda klaidų ir kokios funkcijos jas sukelia.

 

Sistemos bandymų rezultatų tipai

 

Atliekant sistemos testus svarbu žinoti, kokių rezultatų tikėtis iš testų ir kaip šiuos rezultatus naudoti ateityje kuriant ir testuojant.

Bandymų rezultatai – tai turtas ir informacija, kurią gaunate atlikdami sistemos bandymus.

 

1. Bandymų rezultatai

Testavimo rezultatai apima duomenis apie tai, kaip programinė įranga veikė kiekvieno atlikto testo atveju, ir palyginimą, kaip tikėjotės, kad programinė įranga veiks.

Šie rezultatai padeda nustatyti, ar kiekvienas testavimo atvejis yra teigiamas, ar neigiamas, nes jei programinė įranga veikė taip, kaip nesitikėjote, paprastai tai reiškia, kad ji nepavyko.

 

2. Defektų registravimo žurnalas

Defektų žurnalai – tai visų sistemos testavimo metu rastų klaidų ir defektų žurnalai.

Defektų žurnale nurodomos visos rastos klaidos ir kita svarbi informacija, pvz., kiekvienos klaidos prioritetas, rimtumas, simptomai ir klaidos aprašymas.

Taip pat turėtumėte užsirašyti klaidos aptikimo datą ir kitą informaciją, kuri padėtų programuotojams dar kartą atkurti klaidą.

 

3. Bandymo ataskaita

Bandymų ataskaita paprastai yra baigiamųjų kriterijų, kuriais baigiamas sistemos testavimas, dalis, joje paprastai pateikiama atliktų bandymų santrauka, „GO/No-Go” rekomendacijos, informacija apie etapus ir iteracijas bei testavimo data.

Taip pat galite įtraukti bet kokią kitą svarbią informaciją apie bandymų rezultatus arba prie šios ataskaitos pridėti defektų sąrašo kopiją.

 

Sistemos testų pavyzdžiai

 

Sistemos testai skirti visai sistemai išbandyti, t. y. jais išbandomi visi skirtingi programinės įrangos vienetai, veikiantys kartu kaip sistema.

Sistemos testų pavyzdžiai gali padėti geriau suprasti, kas yra sistemos testas ir ką jis tikrina.

 

1. Funkcionalumo testavimas

 

Programinės įrangos inžinierių komanda kuria naują apsipirkimo programėlę, kuri padės maisto prekių parduotuvėms efektyviau surinkti ir supakuoti užsakymus internetu.

Programą sudaro keli skirtingi moduliai, kurių kiekvienas jau buvo išbandytas atskirai atliekant vienetų testavimą ir kartu su kitais moduliais atliekant integracinį testavimą.

Sistemos testavimas – tai pirmas kartas, kai visi moduliai testuojami kartu, o testuotojai sukuria testavimo atvejus, kad įvertintų kiekvieną atskirą taikomosios programos funkciją ir patikrintų, ar jos veikia taip, kaip tikimasi, kai visi moduliai veikia kartu.

 

2. Įkrovimo laiko testavimas

 

Programinės įrangos testuotojų komanda tikrina, kaip greitai programa įkraunama įvairiuose taškuose, esant skirtingiems apkrovos lygiams.

Jie sukuria bandymų atvejus, kuriuose aprašoma, koks krūvis tenka programai (pavyzdžiui, kiek naudotojų ja naudojasi vienu metu) ir kokias funkcijas bei ypatybes naudotojas bando įkelti.

Atliekant sistemos bandymus, apkrovos laikas registruojamas bandymų ataskaitoje, o jei apkrovos laikas laikomas per lėtu, pradedamas kitas kūrimo etapas.

 

3. Bandomoji konfigūracija

 

Kurdami vaizdo žaidimą, kurį galima naudoti su daugybe skirtingų periferinių įrenginių, įskaitant kompiuterio pelę, VR ausines ir žaidimų kilimėlį, programinės įrangos bandytojai atlieka konfigūracijos bandymus, kad patikrintų, kaip gerai kiekvienas iš šių periferinių įrenginių veikia su žaidimu.

Jie atlieka kiekvieną bandymų scenarijų, išbandydami kiekvieną periferinį įrenginį atskirai ir kartu, užrašydami, kaip kiekvienas periferinis įrenginys veikia skirtingais žaidimo etapais ir ar jo veikimas yra dar prastesnis, nei tikėtasi.

 

Sistemos testavimo metu aptiktų klaidų ir klaidų tipai

 

Atlikdami sistemos testavimą, galėsite nustatyti programinės įrangos klaidas ir klaidas, kurių nepavyko aptikti atliekant vienetų testavimą ir integracinį testavimą.

Atliekant sistemos bandymus galima aptikti įvairių rūšių klaidų, kartais dėl to, kad jų anksčiau nebuvo pastebėta, arba dažniausiai dėl to, kad jos atsiranda tik sistemai veikiant kaip visumai.

 

1. Veiklos klaidos

Sistemos testavimas gali išryškinti programinės įrangos kūrimo greičio, nuoseklumo ir atsako laiko klaidas.

Testuotojai gali įvertinti, kaip programinė įranga veikia atliekant įvairias užduotis, ir pasižymėti bet kokias klaidas ar vėlavimus, atsiradusius naudojant. Tai yra veikimo trūkumai, kurie gali būti laikomi arba nelaikomi pakankamai rimtais, kad juos reikėtų toliau tobulinti.

 

2. Saugumo klaidos

Testuojant sistemą galima nustatyti saugumo klaidų, kurios išryškina sistemos saugumo sluoksnio pažeidžiamumą.

Saugumo testavimas atliekamas sistemos testavimo etape ir gali būti naudojamas šifravimo klaidoms, loginėms klaidoms ir XSS pažeidžiamoms programinei įrangai nustatyti.

 

3. Naudojimo klaidos

Naudojamumo klaidos – tai klaidos, dėl kurių sunku naudotis programėle taip, kaip ji skirta. Jie gali sukelti nepatogumų naudotojams, o tai savo ruožtu gali paskatinti naudotojus atsisakyti programėlės.

Kai kurie patogumo klaidų pavyzdžiai – sudėtinga navigacijos sistema arba išdėstymas, kuriame nėra lengva naršyti visais platformos aspektais.

Naudojant tinkamumo naudoti įrankius klaidas galima nustatyti ankstesniame testavimo proceso etape, tačiau jos gali išryškėti ir atliekant sistemos testavimą.

 

4. Komunikacijos klaidos

Ryšio klaidos atsiranda, kai dalis programinės įrangos bando susisiekti su kitu moduliu ir dėl klaidos šis ryšys nutrūksta.

Pavyzdžiui, jei programinė įranga paragina naudotoją atsisiųsti naują naujinį, bet kai naudotojas spusteli naujinio atsisiuntimo mygtuką, naujinio neįmanoma rasti, tai yra ryšio klaida.

 

5. Klaidų tvarkymo klaidos

Klaidų kartais pasitaiko net tada, kai programinė įranga veikia taip, kaip turėtų. Galbūt dėl to, kad komponentas nebuvo tinkamai įdiegtas arba kad naudotojas netinkamai juo naudojasi.

Tačiau sistema turi gebėti tinkamai tvarkyti šias klaidas taip, kad padėtų naudotojams nustatyti ir išspręsti problemą.

Jei klaidų pranešimuose nepateikiama tinkama informacija apie klaidą, naudotojai negalės jos ištaisyti.

 

Bendrosios sistemos testavimo metrikos

 

Atlikdami sistemos testavimą galite stebėti tam tikrus testavimo rodiklius, kad padėtumėte savo testavimo komandai stebėti, kaip veiksmingai atliekamas sistemos testavimas, kaip dažnai randama klaidų ir ar sistemos testavimas atliekamas tinkamame testavimo ciklo etape.

Pavyzdžiui, jei stebite testų, kurie buvo atlikti, ir testų, kurie nepavyko, skaičių ir nustatote, kad didelė dalis sistemos testų nepavyko, galite daryti išvadą, kad reikia atlikti išsamesnius testus ankstesnėje testavimo ciklo stadijoje, kad būtų galima nustatyti klaidas ir klaidas prieš pradedant sistemos testavimą.

 

1. Absoliutūs rodikliai

 

Absoliutūs skaičiai – tai tokie rodikliai, kurie tiesiog nurodo absoliutų skaičių, o ne proporciją ar santykį.

Absoliutūs rodikliai gali būti naudingi, tačiau kadangi tai absoliutūs skaičiai, ne visada lengva interpretuoti jų reikšmę.

Keletas absoliučių rodiklių pavyzdžių: sistemos testavimo trukmė, laikas, per kurį atliekamas sistemos testas, ir bendras sistemos testavimo metu rastų defektų skaičius.

 

2. Bandymų efektyvumo rodikliai

 

Testavimo efektyvumo rodikliai padeda testavimo komandoms suprasti, kiek efektyvios yra dabartinės sistemos testavimo procedūros, tačiau jie nesuteikia jokios informacijos apie sistemos testų kokybę.

Keletas testavimo efektyvumo rodiklių pavyzdžių: išlaikytų testų procentinė dalis ir ištaisytų defektų procentinė dalis.

Išlaikyti testai gali parodyti, ar nevykdote per daug testų ir todėl nepastebite klaidų, ypač jei matote aukštą išlaikytų testų rodiklį ir aukštą defektų išvengimo rodiklį.

 

3. Bandymų efektyvumo rodikliai

 

Testavimo efektyvumo rodikliai testuotojams pasako apie jų atliekamų sistemos testų kokybę.

Jais vertinama, kaip veiksmingai sistemos testai padeda nustatyti ir įvertinti sistemos klaidas ir defektus.

Bendras defektų suvaldymo efektyvumas yra testavimo efektyvumo metrikos pavyzdys, rodantis testavimo etape rastų klaidų santykį su klaidomis, rastomis po išleidimo.

 

4. Testų aprėpties metrikos

 

Testavimo aprėpties rodikliai padeda testuotojams suprasti, kaip išsamiai jie aprėpia visą sistemą, kurią bando testuoti.

Pavyzdžiui, galite įvertinti, kokia dalis jūsų sistemos testų yra automatizuota arba kiek reikiamų testų jau atlikta.

Reikalavimų aprėpties rodiklis taip pat padeda testuotojams stebėti, kokią dalį reikalaujamų funkcijų pavyko aprėpti testuojant.

 

5. Defektų rodikliai

 

Defektų metrikos – tai metrikos, kurios įvairiais būdais matuoja defektų buvimą. Kai kurie defektų rodikliai gali būti orientuoti į defektų sunkumą, o kiti – į defektų tipą arba pagrindinę jų priežastį.

Vienas iš įprastų defektų rodiklių pavyzdžių yra defektų tankis, kuriuo matuojamas bendras defektų skaičius per visą leidinį.

Defektų tankis paprastai pateikiamas kaip defektų skaičius 1000 kodo eilučių.

 

Sistemos bandymų atvejai

 

Sistemos testavimo atvejai – tai testavimo scenarijai, kurie naudojami atliekant sistemos testavimą, siekiant patikrinti, kaip veikia programinė įranga ir ar ji atitinka kūrėjų, testuotojų, naudotojų ir suinteresuotųjų šalių lūkesčius.

 

1. Kas yra testavimo atvejai sistemos testavime?

 

Testavimo atvejai iš esmės yra instrukcijos, kuriose apibrėžiama, ką reikia testuoti ir kokius veiksmus testuotojas turi atlikti, kad išbandytų kiekvieną atskirą atvejį.

Kai rašote sistemos testų atvejus, svarbu įtraukti visą informaciją, kurios testuotojams reikia kiekvienam testui atlikti. Įtraukite kiekvieno bandymo atvejo ID ir informaciją apie tai, kaip atlikti bandymą ir kokių rezultatų tikitės, taip pat, jei reikia, kiekvieno bandymo atvejo teigiamo ir neigiamo rezultato kriterijus.

 

2. Kaip rašyti sistemos testavimo atvejus

 

Jei bandymų atvejų rašymas yra naujiena, galite atlikti toliau nurodytus veiksmus, kad parašytumėte bandymų atvejus sistemos testavimui. Kitų tipų programinės įrangos testavimo atvejų rašymas yra labai panašus procesas.

  • Apibrėžkite sritį, kurią norite, kad testavimo atvejis apimtų.
  • Įsitikinkite, kad testavimo atvejį lengva testuoti.
  • Kiekvienam bandymų atvejui taikyti atitinkamus bandymų projektus.
  • Kiekvienam testavimo atvejui priskirkite unikalų testavimo atvejo ID.
  • Pateikite aiškų aprašymą, kaip atlikti kiekvieną testavimo atvejį.
  • Pridėkite išankstines ir paskesnes sąlygas kiekvienam bandymo atvejui.
  • Nurodykite, kokio rezultato tikitės iš kiekvieno bandymo atvejo.
  • Apibūdinkite naudotinus testavimo metodus.
  • Prieš pradėdami darbą, paprašykite kolegos peržiūrėti kiekvieną testavimo atvejį.

 

3. Sistemos testavimo atvejų pavyzdžiai

 

Naudodami pavyzdinius testavimo atvejus galite lengviau parašyti savo testavimo atvejus. Toliau pateikiami du sistemos testavimo atvejų pavyzdžiai, kuriuos testuotojai gali naudoti programos ar programinės įrangos funkcijai patikrinti.

 

Maisto prekių nuskaitymo programos kainų patvirtinimas

Testo ID: 0788
Bandymo atvejis: Patvirtinti prekės kainą
Testavimo atvejo aprašymas: Skenuokite prekę ir patikrinkite jos kainą.
Laukiami rezultatai: Rezultatai: nuskaityta kaina turėtų sutapti su dabartine akcijų kaina.
Rezultatas: Tai atitinka dabartinę akcijų kainą.
Įskaityta/neįskaityta: Įskaityta.

 

Valdymo programinės įrangos galutinio sandorio atsako laikas

Testo ID: 0321
Bandymo atvejis: Pagrindinio ekrano įkėlimo laikas
Testavimo atvejo aprašymas: Užtikrinkite, kad programėlės pakrovimo ekranas būtų įkeltas per tinkamą laiką.
Laukiami rezultatai: Ekranas turėtų būti įkeltas per keturias sekundes ar greičiau.
Rezultatas: Ekranas buvo įkeltas per 6 sekundes.
Įskaityta/neįskaityta: Neįvykdyta.

 

Geriausi sistemos testavimo įrankiai

 

Sistemos testavimo įrankių naudojimas yra vienas paprasčiausių būdų supaprastinti testavimo procesą ir sumažinti laiką, kurį testavimo komandos praleidžia atlikdamos daug laiko reikalaujančias rankines užduotis.

Sistemos testavimo įrankiai gali automatizuoti sistemos testavimo proceso elementus arba palengvinti testavimo atvejų rašymą ir testavimo eigos stebėjimą.

 

Penki geriausi nemokami sistemos testavimo įrankiai

 

Jei nesate pasiruošę išleisti didelės biudžeto dalies sistemos testavimo įrankiams, bet norite ištirti, kas ten yra, ir galbūt tuo pačiu metu padidinti savo sistemos testavimo procesų efektyvumą, gera žinia ta, kad internete yra daug nemokamų testavimo įrankių.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

Nemokamos testavimo priemonės neturi tokių pačių funkcijų kaip mokamos testavimo priemonės, tačiau mažesnėms įmonėms jos gali būti ekonomiškas būdas ištirti programinės įrangos automatizavimo ir RPA galimybes.

 

1. ZAPTEST FREE Edition

ZAPTEST – tai programinės įrangos testavimo įrankių rinkinys, kurį galima naudoti sistemos testavimui ir kitų tipų programinės įrangos testavimui.

„ZAPTEST” galima įsigyti ir nemokamą, ir mokamą verslui skirtą versiją, tačiau nemokama versija yra puikus įvadas į automatizuotą sistemos testavimą mažesnėms įmonėms ir verslininkams, norintiems žengti pirmuosius žingsnius į testavimo automatizavimą.

„ZAPTEST” gali automatizuoti sistemos testus tiek staliniams, tiek delniniams įrenginiams ir leidžia testuotojams automatizuoti testus nekoduojant.

 

2. Selenas

„Selenium” yra vienas iš žinomiausių rinkoje esančių atvirojo kodo testavimo įrankių.

Nemokamoje „Selenium” versijoje siūlomi automatizuoti testavimo įrankiai, kuriuos galima naudoti sistemos testavimui, regresijos testavimui ir klaidų atkūrimui, be to, jais galite kurti savo testavimo scenarijus įvairiems testavimo scenarijams.

Vis dėlto tai daroma paprastumo ir naudojimo patogumo sąskaita, todėl ne techninio profilio naudotojams gali būti gana sudėtinga išmokti.

 

3. Appium

„Appium” yra nemokama sistemos testavimo priemonė, tinkama naudoti būtent su mobiliosiomis programomis.

Naudodami „Appium” galite automatizuoti programų, skirtų naudoti „iOS” ir „Android” išmaniuosiuose telefonuose ir planšetiniuose kompiuteriuose, sistemos testavimą.

Šis nemokamas įrankis netinka naudoti su darbalaukio programomis, o tai yra vienas didžiausių jo trūkumų.

 

3. Testlink

Jei tiesiog norite lengviau planuoti, rengti ir dokumentuoti sistemos testavimą, „Testlink” yra puikus nemokamas įrankis, kuris palengvina testavimo dokumentacijos valdymą.

Naudodamiesi „Testlink” galite lengvai rūšiuoti ataskaitas į skyrius, kad rastumėte reikiamą informaciją tada, kai jos reikia.

„Testlink” yra vertingas testavimo įrankis, nepriklausomai nuo to, ar atliekate sistemos testavimą, „dūmų” testavimą, ar bet kokį kitą programinės įrangos testavimą.

 

5. Loadium

„Loadium” yra nemokama testavimo priemonė, specialiai sukurta našumo testavimui ir apkrovos testavimui.

Tačiau naudotojams, norintiems automatizuoti visą spektrą testų „nuo pradžios iki galo”, ji yra silpnoji vieta, nes daugiausia dėmesio skiriama našumo ir apkrovos testavimui.

 

4 geriausi įmonių sistemų testavimo įrankiai

 

Augant verslui gali paaiškėti, kad nemokami testavimo įrankiai nebeatitinka jūsų reikalavimų. Daugelis nemokamų įrankių, pavyzdžiui, ZAPTEST, siūlo ne tik nemokamas, bet ir versijas įmonėms.

 

1. ZAPTEST Enterprise edition

 

„ZAPTEST” siūlo testavimo įrankio versiją verslui, kuri pasižymi tomis pačiomis lengvai naudojamomis funkcijomis ir intuityvia nemokamo įrankio sąsaja, tačiau ją galima geriau pritaikyti didesnėms komandoms, kurioms gali reikėti intensyvesnio testavimo arba kurios nori testuoti sudėtingesnius programinės įrangos rinkinius.

Įmonėms skirta ZAPTEST versija siūlo neribotą našumo testavimą ir neribotą iteracijų skaičių, taip pat priskirtą ZAP sertifikuotą ekspertą, dirbantį kaip kliento komandos dalis (tai savaime yra didelis pranašumas, palyginti su kitomis turimomis automatizavimo priemonėmis).

Neribotų licencijų modelis taip pat yra pirmaujantis pasiūlymas rinkoje, užtikrinantis, kad įmonės visada turės fiksuotas išlaidas, nepriklausomai nuo to, kaip sparčiai jos auga.

 

2. SoapUI

„SoapUI” yra testavimo įrankis, leidžiantis valdyti ir vykdyti įvairių žiniatinklio paslaugų platformų ir API sistemos testus.

Testavimo komandos gali naudoti „SoapUI”, kad sumažintų laiko sąnaudas, skiriamas daug laiko reikalaujančioms užduotims atlikti, ir sukurtų išsamesnes bei veiksmingesnes testavimo strategijas.

 

3. Testai

„Testsigma” – tai programinės įrangos testavimo platforma, kuri veikia ne iš lentynos. Ji leidžia produktų komandoms automatiškai planuoti ir vykdyti programinės įrangos testus svetainėse, mobiliosiose programėlėse ir API.

Platforma sukurta naudojant „Java”, tačiau ji veikia su paprasta anglų kalba parašytais bandymų scenarijais.

 

4. TestingBot

„TestingBot” yra palyginti nebrangus verslo sprendimas įmonėms, kurios nori eksperimentuoti šiame sektoriuje neišleisdamos daug pinigų iš pat pradžių. TestingBot siūlo testuotojams paprastą būdą testuoti ir svetaines, ir mobiliąsias programėles naudojant 3200 naršyklių ir mobiliųjų įrenginių kombinacijų tinklelį.

Jai trūksta didesnių įmonių įrankių funkcijų, tačiau ji yra geras pasirinkimas mažesnį biudžetą turinčioms įmonėms.

 

Kada turėtumėte naudoti įmonių ir nemokamus sistemos testavimo įrankius

 

Tai, ar pasirinksite įmonės, ar nemokamus sistemos testavimo įrankius, priklauso nuo jūsų komandos poreikių, biudžeto, prioritetų ir darbo grafiko.

Savaime suprantama, kad įmonių įrankiai turi daugiau funkcijų ir funkcijų, palyginti su nemokamais įrankiais, tačiau mažesnėms įmonėms, neturinčioms daug vietos biudžete, nemokami įrankiai yra puikus pasirinkimas.

Jei jūsų verslas auga arba jei pastebite, kad jūsų testavimo komanda sugaišta daugiau laiko, nei norėtumėte, sistemos testavimui ir kitų tipų programinės įrangos testavimui, įmonės testavimo įrankių atnaujinimas ir mokymasis, kaip išnaudoti visus šių įrankių privalumus, gali padėti toliau plėsti verslą ir patenkinti augančią paklausą.

Be to, naudodami tokius įrankius kaip „ZAPTEST Enterprise”, kurie siūlo naujoviškus programinės įrangos ir paslaugų modelius bei neribotų licencijų modelius, garantuotai panaikinsite techninių žinių spragą ir išlaikysite pastovias sąnaudas, nepriklausomai nuo to, kaip sparčiai augate ir kiek naudojate įrankius.

 

Sistemos testavimo kontrolinis sąrašas, patarimai ir gudrybės

 

Prieš pradėdami sistemos testavimą, peržiūrėkite toliau pateiktą sistemos testavimo kontrolinį sąrašą ir vadovaukitės šiais patarimais, kad optimizuotumėte savo sistemos testavimą, siekdami tikslumo, efektyvumo ir aprėpties.

Sistemos testavimo kontrolinis sąrašas gali padėti užtikrinti, kad atliekant sistemos testavimą aprėptumėte viską, ko reikia.

 

1. Įtraukite testuotojus į projektavimo etapą

 

Nors testuotojai paprastai nedirba su programine įranga, kol nebaigtas kūrimo ir projektavimo etapas, įtraukus testuotojus ankstyvuoju etapu, jiems lengviau suprasti, kaip skirtingi komponentai veikia kartu, ir atsižvelgti į tai atliekant testavimą.

Tai dažnai padeda atlikti įžvalgesnius tiriamuosius bandymus.

 

2. Parašykite aiškius testavimo atvejus

 

Rašydami testavimo atvejus įsitikinkite, kad jie yra aiškūs ir nedviprasmiški.

Testuotojai turėtų gebėti perskaityti testavimo atvejus ir iš karto suprasti, ką ir kaip reikia testuoti.

Jei reikia, paaiškinkite, kur rasti funkciją, kurią reikia išbandyti, ir kokius veiksmus reikia atlikti atliekant sistemos bandymus.

 

3. Maksimaliai padidinti testų aprėptį

 

Atliekant sistemos testavimą paprastai neįmanoma pasiekti 100 proc. testavimo aprėpties, net jei naudojate automatizavimo įrankius.

Tačiau kuo didesnė bandymų aprėptis, tuo didesnė tikimybė, kad klaidas nustatysite ir ištaisysite dar prieš išleidimą.

Stenkitės pasiekti bent 90 % arba kuo artimesnę bandymų aprėptį.

 

4. Kruopščiai išanalizuokite rezultatus

 

Kruopščiai išanalizuokite kiekvieno sistemos testo rezultatus ir dokumentuose aiškiai nurodykite klaidas ir defektus.

Kuo daugiau informacijos apie klaidas galite pateikti, tuo lengviau kūrėjams bus vėliau tas klaidas atkurti.

Jei turite idėjų, kodėl atsiranda klaidų ir kaip jas ištaisyti, įtraukite jas į bandymų rezultatus.

 

5. Neapsiribokite vien reikalavimų testavimu

 

Testuokite programas ne tik tam, kad įsitikintumėte, ar jos daro tai, ką turėtų daryti.

Patikrinkite, kaip jūsų programinė įranga veikia ne pagal reikalavimus, kad sužinotumėte, kaip ji reaguoja į užduotis ir operacijas, nesusijusias su numatytu naudojimu. Tai gali padėti nustatyti klaidas ir defektus, kurių kitu atveju nepastebėtumėte.

 

7 klaidos ir spąstai, kurių reikia vengti įgyvendinant sistemos testus

 

Įgyvendinant sistemos testus pirmą kartą, svarbu žinoti apie dažniausiai pasitaikančias klaidas ir spąstus, kuriuos dažnai daro testavimo komandos.

Žinodami, kokios yra šios klaidos, galėsite jų išvengti, o tai turėtų padidinti jūsų sistemos testavimo veiksmingumą ir tikslumą.

 

1. Pradėti be testavimo plano

 

Prieš pradedant sistemos testavimą svarbu sukurti išsamų testavimo planą.

Jei integracijos testavimą pradedate neturėdami plano, lengva pamiršti kai kuriuos testavimo atvejus, kuriuos ketinate atlikti, arba testavimo atvejus, kurie neįtraukti į testavimo planą.

Dauguma žmonių negali atsiminti visų testavimo plano detalių, jei jis nėra aiškiai dokumentuotas, be to, tai trukdo komandoms perduoti jį kitiems testuotojams.

 

2. Sistemos testavimo apimties neapibrėžimas

 

Sistemos testavimas yra daugialypė užduotis, apimanti daugelio skirtingų vienos programinės įrangos kūrimo aspektų testavimą.

Priklausomai nuo kuriamos programinės įrangos tipo ir nuo to, ką iki šiol išbandėte, sistemos testavimo apimtis gali labai skirtis.

Prieš pradedant testavimą svarbu apibrėžti testavimo apimtį ir užtikrinti, kad ją suprastų visi testavimo komandos nariai.

 

3. Klaidingai teigiamų ir klaidingai neigiamų rezultatų ignoravimas

 

Klaidingai teigiami rezultatai gaunami tada, kai sistemos testai būna teigiami, nors bandymų scenarijai iš tikrųjų neveikia taip, kaip tikėtasi.

Panašiai klaidingai neigiami rezultatai gali atsirasti tada, kai testas nepavyksta, nors veikia taip, kaip tikėtasi.

Kartais gali būti sunku pastebėti klaidingai teigiamus ir klaidingai neigiamus rezultatus, ypač jei paprasčiausiai žiūrite į testo rezultatus, nesigilindami į tikruosius testo rezultatus. Atliekant automatinį sistemos testavimą ypač tikėtini ir lengvai praleidžiami klaidingi teigiami ir neigiami rezultatai.

 

4. Testavimas naudojant panašaus tipo bandymų duomenis

 

Jei naudojate kelių skirtingų tipų bandomuosius duomenis, kuo labiau keiskite naudojamų bandomųjų duomenų atributus, taip padidinsite sistemos bandymų aprėptį.

Tai reiškia, kad yra mažesnė tikimybė nepastebėti klaidų ir defektų, be to, atliekami bandymai turi pridėtinę vertę.

Apimdami įvairių tipų bandymų duomenis, galėsite susidaryti išsamesnį vaizdą apie tai, kaip produktas elgsis po išleidimo.

 

5. Žvalgomojo testavimo ignoravimas

 

Nors svarbu laikytis testavimo plano, taip pat svarbu skirti vietos žvalgomajam testavimui ir leisti testuotojams išbandyti įvairias funkcijas ir ypatybes, kai jie jas randa testavimo metu.

Atliekant tiriamąjį testavimą dažnai galima aptikti naujų klaidų, kurių kitu atveju nebūtų pastebėta, arba klaidų, kurios jau buvo nepastebėtos kituose testavimo etapuose.

Galite netgi suplanuoti žvalgomojo testavimo sesijas, organizuodami „Test Jam” sesijas, kuriose visi testuotojai tam tikrą laiką atlieka neplanuotą sistemos testavimą.

 

6. Reguliariai neperžiūrima bandymų automatizavimo rezultatų

 

Jei esate naujokas programinės įrangos sistemų testavimo ir ypač automatinio testavimo srityje, galite manyti, kad galite tiesiog paleisti testą ir jį palikti.

Tačiau svarbu reguliariai peržiūrėti testavimo automatizavimo rezultatus ir prireikus keisti testavimo automatizavimo kodą.

Pavyzdžiui, jei atliekate kokius nors testuojamos programinės įrangos pakeitimus, jie turėtų atsispindėti automatinių testų kode.

Atidžiai perskaitykite automatinio testavimo rezultatus, kad suprastumėte kiekvieną testo rezultatą, o ne tik teigiamą/neigiamą rezultatą.

 

7. Netinkamos automatizavimo priemonės naudojimas

 

Šiuo metu yra daug automatizavimo įrankių, kai kuriais iš jų galima naudotis nemokamai, o už kitus reikia mokėti mėnesinį mokestį.

Nors pradedantieji dažniausiai renkasi atvirojo kodo įrankius, svarbu įsitikinti, kad pasirinktas įrankis atitinka jūsų reikalavimus ir turi jums reikalingas funkcijas.

Pavyzdžiui, atvirojo kodo įrankiai yra gerai žinomi dėl riboto funkcionalumo, neintuityvios vartotojo sąsajos ir labai sudėtingos mokymosi kreivės.Priešingai, pilno paketo testavimo įrankiai, tokie kaip ZAPTEST Free Edition, suteikia aukščiausio lygio testavimo ir RPA funkcijas, tokias kaip 1SCRIPT, Cross Browser, Cross Device, Cross Platform Technology, lengvai naudojamoje sąsajoje be kodo, tinkančioje tiek netechniškiems, tiek patyrusiems testuotojams.

Kartais verta investuoti į šiek tiek brangesnį įmonės lygio automatizavimo įrankį, jei jo siūlomos funkcijos geriau tinka jūsų projektui.

 

Išvada

 

Sistemos testavimas yra svarbus programinės įrangos testavimo etapas, kurio metu tikrinama visa sistema ir įsitikinama, kad kiekvienas atskiras komponentas veikia sklandžiai ir efektyviai.

Tai programinės įrangos testavimo etapas, kuris vyksta po integracinio testavimo ir prieš vartotojo priėmimo testavimą, ir vienas iš paskutinių oficialių programinės įrangos testavimo etapų, vykstančių prieš pirminį išleidimą.

Sistemos testavimas leidžia testuotojams nustatyti įvairių rūšių klaidas, įskaitant funkcines ir nefunkcines klaidas, taip pat tinkamumo naudoti klaidas ir konfigūracijos defektus.

Sistemos testavimą galima atlikti rankiniu būdu arba automatizuoti sistemos testavimą, tačiau daugeliu atvejų rekomenduojama rinktis mišrųjį metodą, kad būtų pasiektas kuo didesnis efektyvumas ir liktų vietos žvalgomajam testavimui.

Laikydamosi geriausios praktikos ir vengdamos dažniausiai pasitaikančių sistemos testavimo spąstų, testavimo komandos gali atlikti tikslius ir veiksmingus sistemos testus, kurie apima daugumą pagrindinių kūrimo sričių.

 

DUK ir ištekliai

 

Jei esate naujokas sistemų testavimo srityje, internete rasite daugybę šaltinių, kurie padės jums sužinoti daugiau apie sistemų testavimą ir kaip atlikti sistemų testus.

Toliau pateikiama informacija apie kai kuriuos naudingus internetinius sistemų testavimo išteklius ir atsakymai į dažniausiai užduodamus klausimus apie sistemų testavimą.

 

1. Geriausi sistemų testavimo kursai

 

Sistemų testavimo arba programinės įrangos testavimo internetiniai kursai gali padėti kokybės užtikrinimo specialistams geriau suprasti sistemų testavimą ir įgyti šias žinias patvirtinančią kvalifikaciją.

Tokiose internetinėse mokymo svetainėse kaip „Coursera”, „Udemy”, „edX” ir „Pluralsight” siūlomi nemokami ir mokami programinės įrangos testavimo ir automatizavimo kursai profesionalams ir pradedantiesiems.

Keletas internetinių sistemų testavimo kursų pavyzdžių:

  • Pilnas 2023 m. programinės įrangos testavimo stovykla, „Udemy
  • Programinės įrangos testavimo ir automatizavimo specializacija, „Coursera
  • Automatinis programinės įrangos testavimas, edX
  • Automatizuotas programinės įrangos testavimas su „Python”, „Udemy
  • Verslo analitikas: Programinės įrangos testavimo procesai ir metodai, Udemy

Ieškokite internetinių kursų, kurie atitiktų jūsų patirties lygį ir jūsų biudžetą. Jei dirbate kokybės užtikrinimo srityje, galite paprašyti darbdavio paremti jus, kad išklausytumėte akredituotus programinės įrangos testavimo kursus.

 

2. Kokie yra 5 svarbiausi interviu klausimai apie sistemų testavimą?

 

Jei ruošiatės pokalbiui dėl pareigų, kurios gali būti susijusios su sistemų testavimu ar kitų tipų programinės įrangos testavimu, iš anksto pasiruošę atsakymus į dažniausiai pasitaikančius pokalbio klausimus, galite geriau pasirodyti pokalbio metu.

Vieni iš dažniausiai pasitaikančių klausimų pokalbyje apie sistemų testavimą yra šie:

  • Kuo sistemos testavimas skiriasi nuo integracijos testavimo?
  • Kokie yra automatizuoto sistemos testavimo privalumai ir trūkumai?
  • Kiek sistemų testavimo tipų galite išvardyti?
  • Kaip maksimaliai padidinti testų aprėptį atliekant sistemos testavimą?
  • Kokių klaidų ir defektų tikėtumėtės rasti atlikdami sistemos testus?

Naudodamiesi šiais klausimais, prieš pokalbį galite pasirengti atsakymus pagal STAR struktūrą, remdamiesi savo karjeros pavyzdžiais, kad pademonstruotumėte savo žinias apie sistemų testavimą ir kitų tipų programinės įrangos testavimą.

 

3. Geriausios „YouTube” pamokos apie sistemos testavimą

 

Jei mokotės vizualiai, jums gali būti lengviau suprasti, kas yra sistemos testavimas ir kaip jis veikia kartu su kitais programinės įrangos testavimo būdais, žiūrėdami vaizdo įrašus apie sistemos testavimą.

„YouTube” yra daug mokomųjų vaizdo įrašų, kuriuose paaiškinama, kas yra sistemos testavimas ir kaip pradėti sistemos testavimą, nesvarbu, ar norite jį atlikti rankiniu būdu, ar naudodami automatizavimo įrankius. Keletas geriausių „YouTube” pamokų apie sistemos testavimą:

 

4. Kaip prižiūrėti sistemos testus

 

Testų priežiūra – tai sistemos testų ir kitų rūšių programinės įrangos testų pritaikymo ir priežiūros procesas, kurio metu jie atnaujinami atliekant programinės įrangos kūrimo pakeitimus arba keičiant kodą.

Pavyzdžiui, jei atliekate sistemos testavimą ir aptinkate klaidų bei defektų, programinę įrangą grąžinsite kūrėjams, kad jie ją pakoreguotų. Tuomet testavimo komandoms gali tekti prižiūrėti testavimo scenarijus, kad būtų užtikrinta, jog jos tinkamai išbandys naują programinės įrangos kūrimą, kai ateis laikas vėl testuoti.

Testų priežiūra yra svarbus programinės įrangos testavimo aspektas, o testuotojai gali užtikrinti, kad jų programinė įranga bus prižiūrima, jei laikysis geriausios priežiūros praktikos.

 

Tai:

 

1. Bendradarbiavimas:

Kūrėjai ir testuotojai turėtų bendradarbiauti, kad testuotojai žinotų, kurie kodo aspektai buvo pakeisti ir kaip tai gali paveikti testų scenarijus.

 

2. Dizainas:

Prieš pradėdami automatizuoti bandymus, sukurkite bandymų scenarijus. Taip užtikrinama, kad automatizuoti testai visada atitiktų paskirtį.

 

3. Procesas:

Projektavimo proceso metu atsižvelkite į programinės įrangos testavimo priežiūrą. Nepamirškite, kad turėsite prižiūrėti testus, ir atsižvelkite į tai sudarydami tvarkaraščius, testų planus ir testų dizainą.

 

4. Patogumas:

Jei įmanoma, atnaujinkite visus testus, įskaitant sistemos testus ir tinkamumo testus, iš vieno prietaisų skydelio.

Tai reiškia, kad testus galima atnaujinti daug greičiau ir patogiau, be to, sumažėja rizika pamiršti atnaujinti tam tikrą testą, kai buvo atlikti programinės įrangos kūrimo pakeitimai.

 

Ar sistemos testavimas yra baltosios, ar juodosios dėžės testavimas?

 

Sistemos testavimas yra juodosios dėžės testavimo forma.

Juodosios dėžės testavimas skiriasi nuo baltosios dėžės testavimo tuo, kad jo metu vertinamos tik išorinės programinės įrangos funkcijos ir ypatybės. Baltosios dėžutės testavimu tikrinama, kaip programinė įranga veikia iš vidaus, pavyzdžiui, kaip kodas veikia ir veikia kartu.

Atliekant juodosios dėžės testavimą nereikia žinoti vidinės sistemos ar kodo struktūros, o tiesiog reikalaujama, kad testuotojai išbandytų programinės įrangos programos išvestis ir funkcijas ir įvertintų jas pagal nustatytus kriterijus.

Sistemos testavimas apima funkcinį ir nefunkcinį testavimą, tačiau testuotojai naudoja „juodosios dėžės” metodą, kad patikrintų net ir nefunkcinius kūrimo aspektus.

Dėl šios priežasties sistemos testavimas paprastai laikomas juodosios dėžutės testavimu.

Download post as PDF

Alex Zap Chernyak

Alex Zap Chernyak

Founder and CEO of ZAPTEST, with 20 years of experience in Software Automation for Testing + RPA processes, and application development. Read Alex Zap Chernyak's full executive profile on Forbes.

Get PDF-file of this post

Virtual Expert

ZAPTEST

ZAPTEST Logo