Robert Whitney
Preciziškas ir teisingas programinės įrangos testavimas remiasi daugybe principų. Tarptautinė programinės įrangos testavimo kvalifikacijų taryba išskiria septynis pagrindinius, apie kuriuos mes šiandien kalbėsime. Įdomu sužinoti? Perskaitykite straipsnį apie pagrindinius ISTQB testavimo principus!
ISTQB testavimo principai – turinys:
- Testavimas atskleidžia trūkumus, bet negali įrodyti jų nebuvimo
- Išsamus testavimas yra neįmanomas
- Ankstyvas testavimas taupo laiką ir pinigus
- Klaidos sniego gniūžtės efektas
- Pesticidų paradoksas
- Tai priklauso nuo konteksto
- Reklamuoti nepriekaištingą programinę įrangą yra nepriimtina
- Santrauka
Testavimas atskleidžia trūkumus, bet negali įrodyti jų nebuvimo
Testavimas didina klaidų radimo tikimybę, kas savo ruožtu palengvina galimybes jas ištaisyti. Tačiau jis negali visiškai garantuoti, kad programinė įranga yra be visų trūkumų, net jei didžioji dalis jų yra pastebima ir ištaisoma. Dėl neįmanomybės sukurti nepriekaištingą programinę įrangą, daugelis šį procesą laiko neigiamu pagal dizainą, nes niekada negausite teigiamo rezultato ir visada rasite šiek tiek „purvo“ programose.
Išsamus testavimas yra neįmanomas
Aukščiau pateiktas principas teigia, kad visų programinės įrangos gedimų nustatymas yra beprasmiškas. Tačiau tai netaikoma paprastoms trumpoms programoms. Tai, savo ruožtu, rodo, kad yra galimybė pamatyti visas įvesties ir išankstinių sąlygų kombinacijas, kad būtų galima visiškai ištestuoti kai kurias programas. Vertinant sudėtingą programinę įrangą, net geriausia dirbtinio intelekto sistema negali atlikti visų būtinų matavimų, nekalbant jau apie rankinius testuotojus. Automatizuoti vertintojai programėlėse veiks efektyviau ir tiksliau, tačiau vis tiek negali garantuoti nepriekaištingo veikimo. Tam reikia imtis papildomų užduočių, tokių kaip prioritetų nustatymas, rizikos analizė, taip pat kitų testavimo metodų paieška ir taikymas.
Ankstyvas testavimas taupo laiką ir pinigus
Daugelis specialistų šį principą taip pat vadina “kairiuoju poslinkiu.” Kuo anksčiau pastebėsite trūkumus, tuo lengviau juos ištaisyti, todėl statinis ir dinaminis testavimas turėtų prasidėti kuo anksčiau. Trumpai tariant:
- Statinis testavimas – produkto vertinimas neįvykdžius kodo.
- Dinaminis testavimas – modulio ar sistemos kodo vertinimas jos veikimo metu
Trūkumų nustatymas pirmosiose įgyvendinimo fazėse palengvina tolesnę diagnostiką. Tačiau kai dvi programinės įrangos sritys sąveikauja, trūkumų taisymas tampa sudėtingas dėl negebėjimo tiksliai nustatyti, kur yra klaida. Tokiais atvejais reikia papildomo laiko, pastangų ir darbo jėgos. Iš esmės, greitas atsakas į iškilusias kliūtis gali užkirsti kelią įtrūkimų plitimui.
Klaidos sniego gniūžtės efektas
Dauguma gedimų linkę susikaupti kritiniuose moduliuose, todėl jų išsamus tyrimas atskleidžia ir pakankamai pašalina daugumą. Šios grupės tampa pagrindiniu rizikos analizės centru, siekiant sužinoti ir nustatyti būsimus veiksmus. Dauguma trūkumų pasirodo po to, kai sekame vartotojų pasirinktas kelias, tačiau šiais atvejais žinios vienos nepakanka, kad moduliai būtų nepriekaištingi.
Pareto principas sako, kad 80% rezultatų kyla iš tik 20% priežasčių. Kitaip tariant, 80% klaidų egzistuoja 20% modulių. Jei susiduriate su daugybe gedimų modulyje, tęskite tyrimą, nes jie ten bus.
Pesticidų paradoksas
Pakartotinai vykdant tuos pačius testus gali nepavykti, nes jie galėjo būti neteisingai sukurti iš pradžių ir niekada nepasiteisins. Turite pataisyti ir atnaujinti testavimą, kad padidintumėte galimybę rasti naujų klaidų programinėje įrangoje.
Visiškai naujos diagnostikos sistemos sukūrimas taip pat nepadės. Sekant ankstesnes kombinacijas, vertinimo procesas gali sustoti tame pačiame lygyje. Šis principas vadinamas ‘pesticidų paradoksu’, nes pesticidai, kurie kontroliuoja kenkėjus, taip pat praranda efektyvumą po tam tikro naudojimo laiko.
Tai priklauso nuo konteksto
Testavimo vykdymo būdas priklauso nuo tiriamų objektų. Taigi, testuojant apskaitos programą, vaizdo žaidimą ar socialinės žiniasklaidos programą, rezultatai labai skiriasi. Tai taip pat priklauso nuo situacijos, pavyzdžiui, analizė, orientuota į programos praktiškumą, kaip patrauklumą vartotojams, naudojimo paprastumą, vizualinį sluoksnį ir kt., taip pat skiriasi nuo tų vertinimų, kurie orientuoti į programos funkcinius atributus, pvz., teisingų skaičiavimų atlikimą.
Reklamuoti nepriekaištingą programinę įrangą yra nepriimtina
Įvairių diagnostikos įrankių taikymas negali garantuoti tiksliai veikiančių programų. Daugelis, kurie teigia ir reklamuoja savo programas kaip tokias, klysta, tačiau greičiausiai tai tik dėl rinkodaros pastangų jie daro tokią teigimą. Galite atlikti daugybę rankinių ir automatizuotų testų, kad padidintumėte galimybę atskleisti ir ištaisyti kuo daugiau klaidų, tačiau vis tiek nėra garantijos dėl tobulos veiklos. Kai kuriais atvejais kliūtys susijusios su veikiančia programine įranga, pvz., programa gali neatitikti visų vartotojų lūkesčių.
ISTQB testavimo principai – santrauka
Taip ISTQB, pagrindiniu lygiu, pristato septynis ISTQB testavimo principus, kurių turėtų laikytis programinės įrangos testuotojas. Pirmiausia jie nurodo, kad visiškas programinės įrangos diagnostikos neįmanoma, todėl svarbu, be kitų dalykų, keisti testus, taip pat atlikti išsamų paiešką pagrindiniuose moduliuose. Šie veiksmai pagerina didžiosios dalies trūkumų paiešką ir šalinimą, sumažindami ateities gedimų tikimybę.
Ką reiškia programinės įrangos testavimas? Dabar žinote atsakymą! Patikrinkite mūsų kitas serijas apie Python ir Javascript!
Jei jums patinka mūsų turinys, prisijunkite prie mūsų užimtų bičių bendruomenės Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Robert Whitney
JavaScript ekspertas ir instruktorius, kuris moko IT skyrius. Jo pagrindinis tikslas yra padidinti komandos produktyvumą, mokant kitus, kaip efektyviai bendradarbiauti programuojant.
