Programinės įrangos testavimas yra neįtikėtinai sudėtinga ir intensyvi sritis, kurioje įmonės ir nepriklausomi kūrėjai siekia tobulinti savo produktus naudodami įvairius testavimo metodus.
Vienas iš dažniausiai įmonių naudojamų testavimo metodų yra „juodosios dėžės” testavimas – tai metodas, kuris sukuria atstumą tarp kūrėjų ir testuotojų, kad būtų gauti tikslūs rezultatai ir išvengta šališkumo.
Sužinokite daugiau apie tai, kas yra juodosios dėžės testavimas, kaip atlikti juodosios dėžės testavimą, ir apie kai kuriuos juodosios dėžės testavimo programinės įrangos inžinerijoje privalumus, naudodamiesi šiuo išsamiu vadovu.
Kas yra juodosios dėžės testavimas?
„Juodosios dėžės” testavimas – tai sistemos ar programinės įrangos testavimo procesas, kai sistema ar programinė įranga testuojama neturint jokių išankstinių žinių apie jos vidinį veikimą. Tai reiškia ne tik tai, kad nežinote apie patį pirminį kodą, bet ir tai, kad nesate matę jokių su programine įranga susijusių projektavimo dokumentų. Testuotojai tiesiog pateikia įvesties duomenis ir gauna išvesties rezultatus, kaip tai darytų galutinis vartotojas. Nors tai yra paprastas juodosios dėžės bandymų apibrėžimas, jis apibrėžia bendrą sistemą.
Juodosios dėžės testavimo tikslas – priversti naudotojus sąveikauti su programine įranga natūralesniu būdu nei įprastai, neturint jokio išankstinio nusistatymo, kurį lemia jau turimos žinios apie programinę įrangą.
Pagal šią metodiką už testų atlikimą atsakingi žmonės skiriasi nuo tų, kurie kūrė programinę įrangą, todėl abi komandos yra atskirtos.
1. Kada ir kodėl programinės įrangos testavime reikia atlikti juodosios dėžės testavimą?
Yra keli kūrimo ciklo etapai, kai idealiai tinka naudoti „juodosios dėžės” testavimą, o dažniausiai „juodosios dėžės” testavimas atliekamas kūrimo pabaigoje, prieš pat išleidimą.
Tai apima tokius metodus, kaip naudotojo priėmimo testavimas, kai programinė įranga išbandoma su tikslinės auditorijos nariais prieš išleidimą. Tai dažniau vadinama beta testavimu ir yra ideali priemonė bendrovei, nes didesnis poveikis reiškia, kad žmonės dažniau randa galimų programinės įrangos klaidų.
Darbas su juodosios dėžutės metodika kūrimo ciklo pabaigoje yra privalomas, nes tai yra versija, kurią naudotojas greičiausiai pasieks. Atskiroms funkcijoms galėtumėte naudoti juodosios dėžės testavimą, tačiau tai neatitiktų testavimo tikslo.
2. Kai nereikia atlikti juodosios dėžės testavimo
Juodosios dėžės testavimas ankstyvuosiuose kūrimo etapuose turi labai mažai reikšmės. Kai įmonė kuria pagrindines programinės įrangos funkcijas, ji naudoja „baltosios dėžutės” testavimą, kad kūrėjas galėtų pamatyti, kurioje kodo vietoje kyla problemų.
Juodosios dėžės testavimo nereikia ir tada, kai programinė įranga yra atvirojo kodo, palyginti paprasta žiniatinklio priemonė arba skirta padėti trečiosios šalies kodavimo projektams, nes naudotojo sąsaja yra palyginti paprasta, o naudotojas vis tiek gali susipažinti su programos išeities kodu. Jei tikitės, kad naudotojas turės prieigą prie pirminio kodo, juodosios dėžės testavimas praranda savo pagrindinę paskirtį.
3. Kas dalyvauja juodosios dėžės testavime?
Juodosios dėžės testavimo procese yra daug vaidmenų, kai kurie iš jų priklauso nuo įmonės, atliekančios testavimą, pobūdžio.
Svarbūs vaidmenys, susiję su juodosios dėžės testavimo procesu, yra šie:
– Testeris
Testuotojas yra atsakingas už rankinio testavimo atvejų atlikimą įmonėje, rašydamas išsamius testavimo atvejus, kuriuose išsamiai išnagrinėjama programa, prieš juos vykdydamas ir pranešdamas rezultatus. Šis vaidmuo visų pirma atliekamas rankinio testavimo procese, o automatizuotos sistemos atlieka šį vaidmenį, kai testavimas automatizuojamas.
– QA analitikas
QA analitikas yra atsakingas už testavimo atvejų programavimą QA procese, visų pirma tada, kai įmonė naudoja QA testavimo automatizavimo procesą.
Šis procesas apima ir išsamių bandymų atvejų, užtikrinančių aukštą funkcionalumo lygį, kūrimą, ir bandymų atvejų vykdymą bei rezultatų gavimą.
– Kūrėjas
Asmuo, atsakingas už programinės įrangos, kurią tikrina kokybės užtikrinimo komanda, kūrimą. Kūrėjas gauna grįžtamąjį ryšį iš bandytojų komandos ir atitinkamai atnaujina programinę įrangą, dirbdamas kaip kūrėjų komandos dalis, tačiau nuolat palaikydamas ryšį su bandytojais.
– QA vadovas
Kokybės užtikrinimo vadovas yra kokybės užtikrinimo grupės vadovas, atsakingas už visų testuotojų atliekamų užduočių valdymą.
Tai apima testavimo tvarkaraščio sudarymą, darbuotojų darbų sąrašo sudarymą ir bet kokių konfliktų komandoje sprendimą. Jie taip pat aiškina apie „juodosios dėžės” testavimą per naujų darbuotojų mokymus.
– Projekto vadovas
Už galutinio projekto kokybę atsakingas projekto vadovas prižiūri testavimo ir kūrimo procesą, užtikrindamas, kad klientas gautų visą užduotį atitinkantį programinės įrangos paketą.
Juodosios dėžės testavimo privalumai
Juodosios dėžės testavimo naudojimas kūrimo darbe turi keletą svarbių privalumų. Kuo daugiau žinote apie šiuos privalumus, tuo geriau galite jais pasinaudoti ir išnaudoti kuo daugiau technikos privalumų.
Kai kurie iš pagrindinių juodosios dėžės testavimo privalumų užtikrinant kokybę yra šie:
1. Nereikia techninių žinių
„Juodosios dėžės” metodas reiškia, kad nagrinėjant programą nereikia jokių techninių žinių.
Juodosios dėžės testavimo tikslas – ištirti, kaip programa veikia galutiniam naudotojui, o standartinis naudotojas dažniausiai neturi jokių pažangių techninių žinių. Tai gali sumažinti testavimo sąnaudas ir padėti organizacijai mažesnėmis sąnaudomis aptikti daugiau klaidų, taip užtikrinant didesnį finansinį efektyvumą.
2. Tiksliai sumodeliuoti naudotoją
Galutinis „juodosios dėžės” testavimo proceso tikslas – išsiaiškinti, kokių problemų kyla su programa, kai naudotojas kasdien su ja sąveikauja.
Kai kurie juodosios dėžės testavimo tipai, kuriuose daugiausia dėmesio skiriama naudotojo elgesio atkartojimui, labai tiksliai modeliuoja naudotojo elgesį. Ypač tai pasakytina apie naudotojo priėmimo bandymus, kurių metu galutiniai naudotojai susiduria su produktu, ne tik modeliuodami ar imituodami naudotojo elgesį, bet ir iš tikrųjų jį įgyvendindami.
Tikslus modeliavimas padeda atskleisti visas klaidas, kurios daro įtaką naudotojo faktinėms darbo eigoms.
3. Galimybė atlikti bandymus iš minios šaltinių
„Juodosios dėžės” testavimas yra lengvai prieinama testavimo forma, nes reikalauja palyginti nedaug įgūdžių.
Tai reiškia, kad įmonės gali ne tik samdyti mažiau techninių įgūdžių turinčius testuotojus, bet ir sutelktai perduoti testavimą aistringiems klientams. Tai vis dažniau pasitaiko žaidimų pramonėje, kai įmonės siūlo ankstyvosios prieigos versiją, laikui bėgant atnaujindamos žaidimą, kad išspręstų naudotojų rastas problemas.
Šiuo atveju rasti klaidų yra daug lengviau, nes visos funkcijos yra kur kas geriau atskleidžiamos.
Juodosios dėžės testavimo iššūkiai
Be „juodosios dėžės” testavimo privalumų, yra keletas pagrindinių problemų, į kurias turėsite atsižvelgti. Žinodami apie šiuos iššūkius, galite prie jų prisitaikyti ir padidinti savo testavimo standartus, sumažindami žalingą juodosios dėžės testavimo poveikį.
Kai kurie iš šių iššūkių:
1. Sunku rasti problemos priežastis
Vienas iš pagrindinių juodosios dėžės testavimo trūkumų yra tas, kad gali būti sunkiau nustatyti problemų priežastis, kai testuotojai neturi prieigos prie pirminio kodo.
Nors jie gali apibūdinti, kokia yra klaida ir kada ji atsiranda, jie neturi jokių duomenų apie tai, kuri šaltinio kodo dalis sukelia problemas ir kodėl.
Bandytojai gali šiek tiek sušvelninti šią problemą kruopščiai užsirašydami pastabas, o išsamūs kūrėjo pranešimai apie klaidas taip pat padės geriau suprasti būsimus atnaujinimus.
2. Automatizavimas yra sudėtingesnis
Kadangi aktyviai siekiate atkartoti naudotojo sąveikos su programinės įrangos paketu būdą, gali būti labai sunku automatizuoti juodosios dėžės testavimo procesą.
Pirmoji to priežastis yra ta, kad testuotojas neturi jokios prieigos prie pirminio kodo, todėl jam sunkiau sukurti tikslų testo atvejį. Be to, bandymai atliekami taip, kad būtų kuo labiau atkartojamas žmogaus elgesys, o automatikos priemonės specialiai sukurtos taip, kad veiktų kaip robotai.
Šią problemą galite subalansuoti automatizuodami smulkesnes užduotis ir, jei įmanoma, derindami automatizavimą su rankiniais testais.
3. Sunkumai atliekant didelės apimties bandymus
Minėtos automatizavimo problemos reiškia, kad didesnio masto testavimas yra sudėtingesnis. Didelės apimties bandymų metu įmonės gauna daug daugiau duomenų apie programinę įrangą, todėl klaidas lengviau rasti ir atkartoti.
Rankinio testavimo prioriteto reikalavimas reiškia, kad gali būti sunkiau organizuoti didesnio masto testavimą. Kai kurios įmonės tam priešinasi naudodamos atviros beta versijos sistemą, pagal kurią visi, besidomintys produktu, gali padėti atlikti bandymus prieš išleidimą ir paremti įmonę savanoriškai teikdami atsiliepimus apie ankstyvąsias versijas.
Juodosios dėžės bandymų charakteristikos
Reikia žinoti keletą pagrindinių juodosios dėžės testų ypatybių, kuriomis šis testavimas skiriasi nuo bet kurios kitos programinės įrangos kokybės užtikrinimo formos.
Šios savybės yra šios:
1. Jokių išankstinių vidinių žinių
Atliekant juodosios dėžės testus nereikia jokių išankstinių vidinių žinių apie programinę įrangą. Tam tikrais atvejais tai gali būti sudėtinga, nes bandytojai turi tam tikrą supratimą apie programinės įrangos, kurią jie bando, aspektus ir kai kurias ieškomas funkcijas, tačiau plačiąja prasme tai reiškia, kad jie negali matyti jokių vidaus dokumentų.
Paprasčiau tariant, jei informacija būtų matoma galutiniam vartotojui programėlių parduotuvėje arba svetainės atsisiuntimo puslapyje, ją galėtų matyti ir testuotojas.
2. Atskirti testuotojus ir kūrėjus
Testavimo ir kūrimo etapus atlieka skirtingi žmonės, kai atliekamas juodosios dėžės testavimas. Šis skirtumas atsiranda dėl to, kad testuotojams trūksta žinių, nes kūrėjai turi žinių apie pirminį kodą, nes jie buvo atsakingi už jo kūrimą.
Priklausomai nuo konkrečios situacijos, įmonės tai sprendžia keliais skirtingais būdais: kai kurios testavimui atlikti pasitelkia išorinę organizaciją, o didesnėse įmonėse šiam darbui atlikti yra specialūs testuotojų skyriai.
3. Vėlyvojo etapo bandymai
Tai reiškia vystymosi etapą, kuriame atliekami šie bandymai. „Juodosios dėžės” testai grindžiami gana pažangia esamos programos versija su išsamia vartotojo sąsaja, kuri leidžia visiškai naršyti po programinę įrangą ir naudotis kiekviena funkcija.
Tai reiškia, kad „juodosios dėžės” testus galima atlikti tik kai kuriais vėlesniais testavimo proceso etapais, kai visa tai jau yra sukurta. Nors laikui bėgant vartotojo sąsaja ir valdikliai gali būti keičiami, jie turi egzistuoti tam tikra forma, kad juodosios dėžutės testai galėtų pasiekti funkcionalumą.
Ką tikriname atlikdami juodosios dėžės testus
Atliekant juodosios dėžės bandymus nagrinėjami konkretūs programinės įrangos paketo aspektai, kai kuriose programinės įrangos srityse pateikiama papildomos informacijos, dėl kurios atnaujinimai pagerina bendrą gyvenimo kokybę.
Kai kurios pagrindinės programinės įrangos paketo dalys, kurias bandytojai tikrina atlikdami juodosios dėžės testą, yra šios:
1. Funkcionalumas
Kai kurie kūrėjai naudoja „juodosios dėžės” testavimą kaip priemonę užtikrinti, kad programinė įranga veiktų taip, kaip numatyta žmogui, neturinčiam žinių.
Didžioji dauguma žmonių, kurie naudoja bet kokią komercinę programinę įrangą, tai daro neturėdami jokio supratimo apie vidinį programinės įrangos veikimą, todėl testavimas turint šių žinių reiškia, kad žinote, kaip apeiti bet kokias esamas problemas.
Šis nuodugnus funkcionalumo testavimas užtikrina, kad visi patirtų tai, ką programa gali pasiūlyti geriausio, o ne susidurtų su klaidomis, kurios nepastebimos atliekant „baltosios dėžės” testavimą.
2. Vartotojo sąsaja
Vartotojo sąsaja – tai visi būdai, kuriais vartotojas praktiškai sąveikauja su programa, kad ji atliktų tam tikras užduotis. Tai apima meniu, su kuriais dirba naudotojas, konkrečius programoje esančius mygtukus ir programinėje įrangoje esantį prekės ženklą.
Kūrėjai didžiąją laiko dalį praleidžia siekdami užtikrinti, kad pati programa veiktų taip, kaip jie tikisi, todėl mažiau dėmesio skiriama naudotojo sąsajai.
Atliekant „juodosios dėžės” testavimą, testuotojams pateikiamos tik vartotojo programinės įrangos galutinės funkcijos, todėl daugiau dėmesio skiriama vartotojo sąsajai nei daugelyje kitų testavimo etapų.
3. Veiklos rezultatai
Norint, kad programa ne tik normaliai veiktų ir gerai atrodytų, bet ir patiktų klientams, labai svarbu, kaip ji veikia.
Našumas susijęs su keliais veiksniais, įskaitant programėlės greitį reaguojant į naudotojo įvestis ir išteklius, kuriuos ji naudoja bet kuriame įrenginyje.
Naudodami tokius testavimo formatus, kaip galutinis testavimas, kai tikrinamos visos programinės įrangos funkcijos, kūrėjai gali sužinoti, kiek programėlė naudoja atminties ir kurios funkcijos labiausiai apkrauna atitinkamus įrenginius, todėl vėlesnėse programėlės versijose galima atlikti su efektyvumu ir našumu susijusius atnaujinimus.
Išaiškinti tam tikrą painiavą:
Juodosios dėžės ir baltosios dėžės ir pilkosios dėžės testavimas
Juodosios dėžės testavimas – tai sąvoka, kuri skamba panašiai kaip pilkosios ir baltosios dėžės testavimas, tačiau šios idėjos iš esmės labai skiriasi viena nuo kitos. Jų supainiojimas gali sukelti rimtų bendravimo problemų kūrimo procese, o atnaujinimo procesas gali sulėtėti ir būti ne toks veiksmingas.
Skaitykite toliau, kad išsiaiškintumėte kai kuriuos neaiškumus, susijusius su skirtingais „dėžutės testavimo” tipais, kuo jie skiriasi vienas nuo kito ir kada juos naudoti.
1. Kas yra „baltosios dėžutės” testavimas?
„Baltosios dėžės” testavimas kartais vadinamas „stiklinės dėžės” testavimu ir reiškia testavimo procesą, kai testuotojas turi visišką prieigą prie visos programinės įrangos informacijos. Tai apima prieigą prie išeities kodo, projektavimo dokumentų ir paketo kliento santraukos.
Pavyzdžiui, jei testuotojas dirba ankstyviausiais kūrimo proceso etapais ir tikrina vieną funkciją, turėdamas galimybę matyti tos funkcijos pirminį kodą, jis gali iš karto rasti problemos priežastį.
Vienas geriausių momentų naudoti „baltosios dėžutės” testavimą – tai visų pirma vidinės užduotys. Tai susiję su ankstyvuoju funkcinės taikomosios programos dalies kūrimu, kai idealiai tinka greiti pataisymai, nes nėra jokios naudos užgožti kodą, kai nemodeliuojate naudotojo patirties. Baltojo kodo testavimas taip pat naudojamas atvirojo kodo sistemose, nes tokiais atvejais išeities kodas yra prieinamas visiems naudotojams.
Kuo skiriasi „baltosios ir juodosios dėžės” testavimas?
Pagrindinis funkcinis juodosios ir baltosios dėžės testavimo skirtumas yra testuotojo prieigos prie programinės įrangos lygis, tačiau tai turi daug didesnę įtaką testavimo aspektams, pvz., laikui.
Juodosios dėžutės testavimas dažniau naudojamas vėlesniuose proceso etapuose, kai produktas artėja prie išleidimo į rinką, o pagrindiniuose kūrimo etapuose naudingas baltosios dėžutės testavimo skaidrumas ir reakcija. Vertinant juodosios ir baltosios dėžės testą, šie du testai taip pat skiriasi reikalingų žinių lygiu, nes norint, kad baltosios dėžės testavimas būtų veiksmingesnis, reikia turėti žinių apie kodavimą ir kūrimą.
2. Kas yra pilkosios dėžės testavimas?
Pilkosios dėžutės testavimas – tai testavimo forma, kai naudotojas turi tam tikrą supratimą apie kodą, tačiau neturi visiškos prieigos prie jo. Tai reiškia, kad reikia turėti testuojamos funkcijos pirminį kodą arba susipažinti su kai kuriais projektavimo dokumentais, kad naudotojas suprastų, kokia yra bendra programinės įrangos paketo paskirtis.
Pavyzdžiui, jei testuotojas tikrina tik vieną iš programinės įrangos paketo funkcijų, jam gali būti suteikta prieiga prie tos vienos programos dalies išeities kodo.
Įmonės pirmiausia naudoja pilkosios dėžutės testavimą, kai tikrina, kaip programa integruota su trečiosios šalies įrankiu. Jie gali turėti prieigą tik prie vienos proceso dalies išeities kodo, todėl jų galimybės atlikti išsamų „baltosios dėžutės” testavimą yra ribotos. Vietoj to jie mato trečiosios šalies integracijos įvestis ir išvestis bei už integraciją atsakingą šaltinio kodą.
Testuotojai ją naudoja norėdami įvertinti, ar problemų kyla dėl programinės įrangos, trečiosios šalies programos ar jų integracijos.
Kuo skiriasi juodosios ir pilkosios dėžės testavimas?
Pagrindinis skirtumas tarp juodosios ir pilkosios dėžės testavimo vėlgi yra prieigos prie informacijos lygis, o testuojamos programinės įrangos tipas yra vienas iš pagrindinių veiksnių, skiriančių šiuos testavimo tipus.
Pilkosios dėžės testavimas paprastai apima trečiųjų šalių įrankius, pavyzdžiui, duomenų saugyklą debesyje arba išorinio apdorojimo įrankius, o juodosios dėžės sistemos paprastai yra vientisas vienetas. Daugeliui juodosios dėžės testų trečiosios šalys netrukdo, o integruotoms taikomosioms programoms beveik nėra kito pasirinkimo, kaip tik dirbti pagal pilkosios dėžės testavimo metodiką.
3. Išvada: Juodosios dėžės ir baltosios dėžės ir pilkosios dėžės testavimas
Galiausiai juodosios, pilkosios ir baltosios dėžutės testavimas iš esmės skiriasi, nes priklauso nuo to, ar testavimo komandai pateikiama užkulisinė informacija.
Juodosios ir baltosios dėžės testavimas yra šio spektro kraštutinumai, o pilkosios dėžės testavimas apima viską – nuo galimybės matyti visą, bet ne trečiosios šalies šaltinio kodą iki galimybės matyti tik konkrečios funkcijos kodą.
Tačiau visi šie testavimo metodai yra svarbūs programinės įrangos testavimo srityje, todėl būtina skirti laiko ir dėmesio jų mokymuisi ir veiksmingam įgyvendinimui.
Juodosios dėžės bandymų tipai
Yra trys pagrindiniai juodosios dėžės testavimo tipai, apimantys visus testus, kuriuos įmonė atlieka taikydama juodosios dėžės metodiką. Tai:
1. Funkcinis testavimas
Funkcinis testavimas apima viską, kas susiję su mechaniniu programos veikimu. Tai reiškia, kad reikia užtikrinti, jog duomenys būtų tvarkomi teisingai, naudotojai galėtų prisijungti naudodami tinkamus įgaliojimus ir informacija bei įvestys būtų apdorojamos taip, kaip tikimasi.
Funkcionalumo testavimas yra vienas iš svarbesnių proceso aspektų, apimantis tiek vietinį programos funkcionalumą, tiek jos sąveiką su išorinėmis priemonėmis ir programomis, pvz., debesijos paslaugomis ar vieno prisijungimo priemonėmis.
2. Nefunkcinis testavimas
Nefunkcinis testavimas – tai testavimas, kurio metu tikrinamas bet koks programinės įrangos aspektas, aiškiai nesusijęs su programos funkcionalumu. Tai reiškia, kad reikia nustatyti, ar programa yra tinkama naudoti ir lengvai suprantama naudotojams, suderinama su įvairiais įrenginiais ir operacinėmis sistemomis ir kaip ji veikia esant didelei apkrovai (nors tam tikrais momentais gali būti pereita prie funkcinio testavimo).
Tai dažniausiai įvyksta kūrimo proceso pabaigoje, kai visa programa jau yra parengta.
3. Regresijos testavimas
Po atnaujinimo testuotojai peržiūri programą, kad įsitikintų, jog ji atliko numatytą funkciją ir nėra nenumatytų šalutinių poveikių, dėl kurių programa atsistatytų.
Tai vadinamasis regresinis testavimas, kuris yra esminė dalis siekiant užtikrinti, kad programa būtų parengta pateikti rinkai.
Regresijos testavimas atliekamas po kiekvieno atnaujinimo, siekiant įsitikinti, kad tiek funkciniai, tiek nefunkciniai programos aspektai atitinka anksčiau pasiektą standartą.
Juodosios dėžės testavimo metodai
Atlikdami juodosios dėžės testavimo procesą, galite taikyti daugybę metodų, kurie pagerins jūsų darbo standartą. Keletas svarbiausių juodosios dėžės testavimo metodų, naudojamų kokybės užtikrinimo aplinkoje, yra šie:
1. Porinis testavimas
Porinis testavimas – tai testavimo forma, kai daugiausia dėmesio skiriama visų galimų programinės įrangos duomenų įvesties kombinacijų išbandymui.
Pavyzdžiui, jei viename stulpelyje yra visi galiojantys įrašai nuo vieno iki dešimties, o kitame – visi abėcėlės simboliai, atliekant porinį testavimą būtų tikrinami visi galimi deriniai nuo 1A iki 10Z. Šiam testavimui atlikti naudotojui gali prireikti daug laiko ir pastangų, todėl tai yra vienas iš metodų, kurie gali būti labiausiai pritaikyti hiperautomatizavimui. Tai itin kruopštus metodas, kuriuo nustatomos visos galimos duomenų įvedimo problemos.
2. Ribinių verčių analizė
Daugelyje programinės įrangos rūšių reikia įvesti duomenis, o duomenys turi konkrečias ribas, kurių klientas turi laikytis.
Pavyzdžiui, sistema, sukurta skaičiams nuo 1 iki 100 apskaičiuoti, gali susidurti su sunkumais, kai reikšmės yra 0 arba mažesnės, arba didesnės nei 100.
Ribinių verčių analizė apima šių ribų testavimą, įvedant skaičius ties ribomis, kurias programinė įranga testuoja, ir aplink jas, siekiant ištirti, ar yra klaidų programinės įrangos paketo numatyto veikimo diapazono ribose. Tai pirmiausia naudinga skaičiavimais grindžiamose sistemose ir gali padėti kūrėjams koreguoti ribas arba rasti problemų priežastis.
3. Būklės perėjimo testavimas
Daugelis programų yra skirtingų „būsenų” arba „režimų” ir reikalauja perėjimo iš vieno šio proceso etapo į kitą. Tinkamai veikiantys perėjimai reiškia, kad svetainė veikia taip, kaip tikisi naudotojas, ir nėra jokių netikėtų trikdžių.
Perėjimo iš vienos būsenos į kitą testavimas – tai testavimo forma, kurios metu tikrinami visi perėjimai iš vienos programinės įrangos būsenos į kitą, užtikrinant, kad jie yra funkcionalūs, ir suteikiant tikrumą, kad naudotojo srautai per programinę įrangą veikia be jokių nenumatytų trikdžių.
Juodosios dėžės testavimas programinės įrangos inžinerijos gyvavimo cikle
„Juodosios dėžės” testavimas – tai disciplina, kuri pirmiausia naudojama programinės įrangos inžinerijos gyvavimo ciklo pabaigoje. Tai apima viską – nuo naudotojų sąveikos su programine įranga testavimo iki visiškos beta versijos prieigos suteikimo, o „juodosios dėžės” testavimas pirmiausia atliekamas tada, kai visos funkcijos veikia taip, kaip tikimasi.
Tai sutaupo daug laiko ir pastangų, palyginti su „baltosios dėžutės” bandymais, kuriems atlikti reikia didelių žinių ir kuriuos geriausia atlikti, kai nereikia, kad kūrimo komanda iš karto pakeistų sistemos veikimą.
Rankiniai ar automatizuoti juodosios dėžės testai?
Programinės įrangos testavimas būna dviejų skirtingų formų: rankinis testavimas yra tradicinė forma, kai kiekviename proceso etape naudojami programinės įrangos testuotojai. Tai griežtai prieštarauja automatizuotam testavimui, kuris naudoja vis aukštesnio lygio dirbtinį intelektą ir mašininį mokymąsi užduotims atlikti be jokio žmogaus įsikišimo.
Skaitykite toliau ir sužinokite daugiau apie tai, kas yra rankinis ir automatinis testavimas, kokie yra kiekvieno iš jų iššūkiai ir kuris iš jų yra tinkamiausias įmonei.
1. Rankinis juodosios dėžutės testavimas – nauda, iššūkiai, procesas
Rankinis juodosios dėžės testavimas – tai procesas, kai juodosios dėžės testavimas atliekamas savarankiškai, pasitelkiant darbuotojus, kurie atlieka visas užduotis, o ne naudojant automatizavimo platformą kaip įmonės įrankių rinkinio dalį.
Vieni iš pagrindinių rankinio testavimo privalumų kuriant programinę įrangą yra tai, kad galima lanksčiau pasirinkti testavimo būdą ir kad kūrėjai gali gauti daug išsamesnę ir kokybiškesnę grįžtamąją informaciją.
Tačiau rankinio testavimo procesas susiduria su keliais natūraliais iššūkiais. Pirmoji iš jų yra ta, kad rankinis testavimas gali užtrukti daug laiko, nes žmonės užduotis atlieka lėčiau nei automatizuotos programos.
Kita priežastis – didesnė klaidų tikimybė, nes žmonės gali neteisingai spustelėti arba atlikti veiksmus netinkama tvarka. Galiausiai dėl to gali atsirasti netikslumų bandymų duomenyse.
Rankinis testavimas – tai procesas, kuris prasideda nuo įmonės lūkesčių, susijusių su taikomąja programa, sužinojimo, po to rašomi testavimo atvejai, kurie paneigia šią trumpą informaciją, vykdomi testavimo atvejai ir apie rezultatus pranešama kūrimo komandai.
2. Juodosios dėžės testavimo automatizavimas – nauda, iššūkiai, procesas
Automatiniai testai – tai testai, kuriuos įmonė atlieka su programinės įrangos paketu, atlikdama testavimo atvejus automatizuota sistema. Juose programinės įrangos paketui automatizuoti naudojamos trečiųjų šalių platformos, o visi automatizuoti veiksmai atliekami pagal specialiai parengtus bandymų atvejus.
Pagrindinis juodosios dėžės testavimo automatizavimo privalumas – greitis, nes automatizuotos programos užima daug mažiau laiko kiekvienam testo paleidimui. Tai leidžia sutaupyti daug laiko, kurį galite skirti programai kurti.
Kitas privalumas – tikslumas, nes geras automatizavimo įrankis kiekvieną kartą atlieka tas pačias užduotis ta pačia tvarka.
Dėl trūkumų vis dar gali kilti problemų atliekant juodosios dėžės bandymų automatizavimą, o viena iš pagrindinių problemų – dėmesys kiekybiniams duomenims. Tai puikiai tinka metrikai, tačiau tai reiškia, kad atliekant naudotojo priimtinumo bandymą galima gauti mažai vertingos informacijos.
Be to, automatizuotam testavimui trūksta lankstumo, nes analitikai, norėdami atlikti pakeitimus, turi kurti visiškai naujus testavimo atvejus.
Bandymų automatizavimo procesas prasideda nuo kelių bandymų atvejų, kurie koduojami sistemoje prieš atliekant bandymus, o po jų atlikimo pateikiama ataskaita.
3. Išvada: Rankinis ar juodosios dėžės testavimo automatizavimas?
Galiausiai pasirinkimas tarp rankinio ir automatinio juodosios dėžės testavimo yra sudėtingas ir priklauso nuo to, ko ieškote sistemoje.
Jei ieškote aukštos kokybės informacijos, kurią galėtumėte panaudoti galutiniam vartotojui skirtiems dizaino pakeitimams atlikti, rankinis testavimas yra kur kas geresnis pasirinkimas, o automatizuotas testavimas idealiai tinka funkciniams ir našumo proceso etapams.
Pagalvokite, ko ieškote kiekviename testavimo proceso etape, ir galėsite lengvai gauti vadovaujamus duomenis, kurie pagerins jūsų veiklą.
Ko reikia norint pradėti juodosios dėžės testavimą?
Prieš pradėdami juodosios dėžės testavimą turite turėti tam tikras išankstines sąlygas, kurių kiekviena padeda sukurti nuoseklesnį testavimo procesą.
Prieš pradėdami juodosios dėžės testavimo darbus, turite turėti šiuos dalykus:
1. Programinės įrangos reikalavimai
Reikalavimai programinei įrangai – tai konkretūs projektavimo užduoties punktai, kuriuos turi atitikti programinė įranga. Tai gali būti įvairūs dalykai – nuo būtinybės atlikti tam tikras užduotis iki tam tikros išvaizdos ir pojūčio naudojant.
Turėdami šią informaciją, galite nustatyti keletą konkrečių tikslų, kurių reikia siekti atliekant bandymus, o bandytojai sudaro bandymų tvarkaraštį ir planą, pagal kurį gaunami nuoseklesni rezultatai, informuojantys kūrėjus apie programinės įrangos problemas.
Kai kuriose įmonėse, kadangi tai yra „juodosios dėžės” testas, kūrėjai apriboja testuotojo prieigą prie trumposios versijos.
2. Parengta programinė įranga
Prieš pradėdama testuoti programinę įrangą, kokybės užtikrinimo komanda turi turėti prieigą prie programinės įrangos. Paprastai kūrėjai pateikia naujausią programinės įrangos versiją, o komanda gauna naudos iš to, kad turi visiškai šviežiai sukompiluotą programinės įrangos versiją, su kuria gali atlikti bandymus.
Naujausia versija reiškia, kad į testus įtrauktos naujausios pataisos, todėl jie tiksliai atspindi programinės įrangos veikimą.
3. Testavimo tikslai
Testuotojai paprastai pradeda testavimo laikotarpį turėdami tam tikrų konkrečių tikslų. Šiuose testavimo tiksluose tiksliai nurodoma, ką jie testuoja per ateinantį laikotarpį, nesvarbu, ar tai būtų naudotojo priimtinumas, ar galutinio funkcionalumo užtikrin imas, ar įsiskverbimo testavimas.
QA vadovai paprastai siekia šių tikslų, o kitas testavimo etapas paprastai priklauso nuo to, ką kūrėjų komanda dirbo ir kokioms programinės įrangos dalims šie darbai turi įtakos.
Juodosios dėžės testavimo procesas
„Juodosios dėžės” testavimo procesas yra gana tikslus, todėl įmonėms naudinga kuo tiksliau laikytis šio proceso etapų. Skirtingi juodosios dėžės testavimo proceso etapai:
1. Bandymų planavimas
Juodosios dėžės testavimo procesą pradėkite nuo sudėtingo planavimo proceso. Tai reiškia, kad reikia aptarti visus individualius testo tikslus, konkrečius programinės įrangos aspektus, kuriuos tikrinate, ir testavimui skirtus išteklius.
Kruopštesnis planavimas reiškia, kad visi žino, ką ir kada jie turi daryti, taip pat žino, kokiais metodais bus atliekami bandymai.
2. Testavimo atvejų rašymas
Kitas proceso etapas – testavimo atvejų rašymas. Testavimo atvejis – tai veiksmų, kuriuos reikia atlikti atliekant testą, seka, o išsamesni testavimo atvejai užtikrina didesnį nuoseklumą naudotojui.
Automatizuotame testavimo procese tai taip pat apima testavimo atvejo kodavimą bet kurioje automatizavimo priemonėje, kurią planuojate naudoti.
Dukart patikrinkite visus bandymų atvejus, kad įsitikintumėte, jog jie yra išsamūs ir aiškiai nurodo, kokius veiksmus reikia atlikti.
3. Testavimo atvejo vykdymas
Parengę bandymų atvejus, pradėkite juos vykdyti. Naudojant automatizavimą tai gali būti gana paprasta užduotis, kurią atliekant reikia nustatyti programą ir laukti rezultatų. Atliekant rankinį testavimą darbuotojai turi pakartotinai atlikti testavimo atvejus, o daugiau pakartojimų leidžia gauti nuoseklesnius ir kokybiškesnius duomenis.
Kuo kruopščiau atlikite kiekvieną testavimo atvejį, nes kuo tiksliau atliekami testavimo atvejai, tuo didesnė tikimybė, kad duomenys bus naudingi kūrimo komandai.
4. Galutinės ataskaitos
Galutinis ataskaitų teikimo etapas – tai proceso dalis, kai testavimo grupė pateikia ataskaitą kūrėjams.
Pradėkite nuo paprastos surinktos informacijos santraukos ir tik tada ją papildykite visais testuotojų surinktais rodikliais. Taip kūrėjams pateikiamos pradinės gairės, kokia kryptimi būtų geriausia rinktis kitą atnaujinimų seriją, ir tik tada jiems parodomi visi duomenys, kad jie galėtų geriau suprasti problemas.
Geriausia juodosios dėžės testavimo praktika
Nepriklausomai nuo jūsų pramonės šakos, laikytis geriausios praktikos yra būtina bet kuriai įmonei. Geroji praktika – tai elgesio ir metodų, kuriuos įmonė naudingai taiko kasdieniniame darbe, visuma, didinanti įmonės efektyvumą ir gerinanti įmonės naudojamos programinės įrangos standartus.
Kai kurios iš šių praktikų, padedančių įmonei pagerinti juodosios dėžės testavimo kokybę, yra šios:
1. Dėmesys įgūdžių ugdymui
Jei vadovaujate įmonei, kuri vienu metu dirba su keliais programinės įrangos elementais, apsvarstykite galimybę sutelkti dėmesį į testavimo įgūdžių ir specializacijų plėtojimą. Kuo daugiau laiko skirsite specializacijai ir tinkamų įgūdžių ugdymui, tuo daugiau šansų, kad išspręsite bet kokias savo produktų problemas.
Tai susiję su tinkamų įgūdžių turinčių žmonių samdymu, tačiau labiausiai tinka įmonėms, kuriose beveik nuolat atliekamas programinės įrangos testavimas, nes šių gebėjimų taikymas visada yra naudingas.
2. Subalansuoti darbo krūvį
Kai kurios testavimo grupės gali būti labai didelės, jose gali dirbti dešimtys ar net šimtai darbuotojų, kurie reguliariai atlieka testavimo atvejus.
Geriausia praktika, kaip maksimaliai išnaudoti šių darbuotojų galimybes, yra neskubėti ir atsargiai skirti jiems konkrečias užduotis. Dėl perdegimo programinės įrangos kūrimo pramonėje kyla rimtų problemų, tačiau to galima išvengti geriau valdant darbo krūvį.
3. Sukurti nuoseklius procesus
Įmonės yra sukurtos remiantis procesais, kuriuos jų darbuotojai atlieka kasdien, o testavimo procesai apima tai, kaip įmonė rašo testavimo atvejus, atlieka tyrimus ir bendrauja su įvairiais skyriais.
Nuoseklumas šiais atvejais yra labai svarbus, nes tai reiškia, kad atėję į įmonę žmonės greičiau išmoksta. Tai padeda greičiau prisitaikyti ir pasiekti geresnių rezultatų nei įmonėje, kurioje užduotys nėra nuoseklios.
Jei galite, šiuos procesus kurkite taip, kad darbuotojai dalyvautų sprendimų priėmimo procese, nes taip įsitikinsite, kad jie pritaria strategijai.
7 klaidos ir spąstai įgyvendinant juodosios dėžės bandymus
Klaidos yra natūralus dalykas bet kurioje pramonės šakoje, tačiau žinojimas apie klaidas prieš jas padarant gali sutaupyti daug laiko ir pastangų.
Dažniausios klaidos ir spąstai, į kuriuos patenka „juodosios dėžės” testuotojai, yra šie:
1. Nepakankamai apibrėžta testavimo apimtis
Kai kurios organizacijos pradeda bandyti savo produktus tinkamai nesuplanavusios procesų, o tai yra didelė klaida.
Nevykdydamos planavimo, įmonės gali prarasti testavimo apimtį. Sutartos apimties nustatymas padeda bandymą atlikti tinkamu mastu ir veiksmingai pasiekti rezultatų.
Jei prieš pradėdami bandymus nesusitarsite dėl jų apimties, kyla rimta rizika, kad bandymai bus per platūs ir užtruks per daug laiko, o jų rezultatai bus mažiau svarbūs.
2. Skubus testavimo procesas
Testavimas gali atrodyti kaip procesas, kuris trunka labai ilgai, ypač jei testavimo atvejai, skirti visai programai patikrinti, yra ilgi. Kai kurie žmonės gali būti linkę skubėti atlikti tyrimus, ypač kartoti ankstesnius tyrimus. Tai rimta klaida. Skubotai atliekant bandymus gali būti padaryta klaidų, dėl kurių gali sumažėti duomenų vertė, o galiausiai tuos pačius bandymus vis tiek reikės atlikti iš naujo.
3. Automatizavimas be patikrinimo proceso
Testavimo automatizavimas visų pirma skirtas įsitikinti, kad įvedus duomenų vertę proceso pabaigoje bus gautas tinkamas rezultatas. Automatizuojant šiuos bandymus patikrinama, ar automatizuoto proceso išvestis atitinka rezultatus, kurie turėtų būti gauti.
Kai kurie testuotojai daro didelę klaidą, nes patys neapskaičiuoja vertės, o tai reiškia, kad jie neturi galimybės patikrinti, ar išvestis yra teisinga, ir gali nepavykti aptikti svarbių visos sistemos klaidų.
4. Hibridinio testavimo nenaudojimas
Hibridinis testavimas – tai automatizavimo ir rankinio testavimo derinimas, nes šie du metodai veikia taip, kad puikiai pašalina vienas kito trūkumus.
Tačiau kai kurios organizacijos mieliau renkasi vieną iš šių dviejų metodų. Taip atlikdami bandymus galite susidurti su rimtomis problemomis ir netikslumais.
Atlikite hibridinį testavimą, kad testavimas būtų geriau subalansuotas ir kuo labiau sumažėtų klaidų skaičius.
5. Nebaigtas regresinis testavimas
Regresijos testavimas turėtų būti nuolatinis bet kurios veiksmingos programinės įrangos testavimo sistemos procesas, kurio metu nustatoma, ar programinės įrangos atnaujinimai nesukėlė problemų kitose sistemos dalyse. Nebaigus regresijos testavimo, funkcijos, kurias testavote ankstyvuoju proceso etapu, gali būti neveiksmingos jums patiems to nesuvokiant.
Atlikdami regresinį testavimą užtikrinate, kad pristatysite aukštesnės kokybės produktą, neįdėdami per daug papildomo darbo į kokybės užtikrinimo procesą.
6. Aktyvi klaidų medžioklė
Kai kurie mano, kad juodosios dėžės testavimo tikslas – rasti programinės įrangos paketo klaidų ir pranešti apie jas kūrimo komandai, ir nors tai yra vienas iš aspektų, jis nėra vienintelis. Testavimas atliekamas siekiant pagerinti programinės įrangos paketo standartą.
Pernelyg daug dėmesio skirdami programinės įrangos klaidoms, pradedate nesilaikyti standartinių darbo eigos principų, išeinate už testavimo ribų ir ignoruojate kai kurias svarbesnes programinės įrangos problemas mainais į galimai nereikšmingų kodo trūkumų paiešką.
7. Intuicijos ignoravimas
Atliekant rankinį testavimą, testuotojui tenka šis vaidmuo, nes jis turi intuiciją ir kodo žinias, kurios padeda atkreipti dėmesį į galimas problemas ir informuoja apie sritis, kurias reikia išnagrinėti, kai jis dirba.
Tačiau kai kurie, kurdami testavimo atvejus, nusprendžia visiškai ignoruoti šią intuiciją. Užsirašydami viską, ką norite patikrinti, ir tikrindami tai naujame testavimo atvejyje, galėsite pasinaudoti visomis savo techninėmis žiniomis ir kartu užbaigti parengtus testavimo atvejus.
Juodosios dėžės bandymų rezultatų tipai
Atliekant „juodosios dėžės” bandymus galima gauti kelių tipų rezultatus, iš kurių kiekvienas suteikia unikalių įžvalgų įmonei, siekiančiai atlikti atitinkamus produktų atnaujinimus ir pagerinti kokybę, kurią patiria klientai.
Pagrindiniai juodosios dėžės testų rezultatai yra šie:
1. Kokybiniai duomenys
Pirmoji išvesties forma, kurią galite gauti atlikę juodosios dėžės bandymą, yra kokybiniai duomenys. Tai informacija, kuri visų pirma apibūdina programą ir gaunama atlikus bandymus, pavyzdžiui, testavimą „nuo galo iki galo” ir tinkamumo naudoti bandymus.
Kokybiniai duomenys paprastai apibūdina taikomosios programos standartą, aptaria žmonių patirtį su programa ir paaiškina pakeitimus, kuriuos testuotojas norėtų padaryti.
Kurdamas šiuos duomenis, testuotojas paprastai rašo išsamią ataskaitą, kurioje pateikia visus savo argumentus ir kokybines nuomones pagrindžia papildomomis funkcijomis, pvz., ekrano nuotraukomis.
2. Kiekybiniai duomenys
Tai reiškia aiškius skaitinius duomenis metrikų pavidalu, kai testavimo darbuotojai atkreipia dėmesį į konkrečias programos dalis arba gauna skaitinius duomenis iš automatinio testavimo protokolo.
Kiekybinė informacija paprastai yra naudingesnė, nes padeda kūrėjams pateikti aiškias pataisas, nurodančias tokias taikomosios programos dalis kaip jos našumo lygis, jos efektyvumas naudojant išteklius ir taikomojoje programoje esančių klaidų bei problemų skaičius.
Kiekybinę informaciją paprasčiau analizuoti ir vertinti nei aprašomąją, nes jos nereikia interpretuoti.
3. Klaidų pranešimai
Klaidų pranešimai atsiranda, kai programinės įrangos funkcijos neveikia taip, kaip tikėtasi. Tai gali būti susiję su aparatinės arba programinės įrangos problemomis, paprastai pateikiamas trumpas problemos aprašymas ir klaidos kodas.
Kūrėjai sukuria klaidų kodų sistemą, kad galėtų tiksliau nustatyti, kurioje sistemos vietoje kyla problema, ir siūlo keletą idėjų, kaip ją įgyvendinti: pirmuoju skaitmeniu susiaurinti funkciją, kurioje kyla problema, antruoju apibūdinti, kas konkrečiai nepavyko, o trečiuoju nurodyti problemos priežastį.
Naudodami šią klaidų kodų sistemą kūrėjai iš karto sužino, kokia yra problema, ir gali ją išspręsti.
Juodosios dėžės bandymų pavyzdžiai
Nors juodosios dėžės testavimo teorija yra gana paprasta, praktinis jo įgyvendinimas gali būti sudėtingas procesas, ypač pradedančiajam testuotojui. Juodosios dėžės testavimo pavyzdys gali padėti organizuojant testavimą.
Keletas juodosios dėžės testavimo metodų pavyzdžių, įskaitant kelių tipų testavimą ir skirtingą sėkmės laipsnį:
1. Neefektyvus naudotojų priėmimo testavimas
Įmonė per artimiausias savaites ketina išleisti savo produktą, tačiau naudotojų priėmimo bandymai dar neįvyko. Ši paraiška yra mezgimo pamoka vyresnio amžiaus žmonėms.
Kūrėjai siekia pagreitinti šį procesą ir greitai surinkti bandytojų grupę, bandymams pasitelkdami tik trisdešimtmečius ne mezgėjus, nes jie buvo lengviau prieinama grupė. Ši grupė nemato jokių problemų dėl paraiškos ir suteikia jai žalią šviesą, kad ji būtų paskelbta viešai.
Dėl prieštaringo abiejų grupių techninių žinių lygio tikslinė auditorija, naudodamasi programine įranga, yra labiau sutrikusi ir negali naudotis daugeliu funkcijų. Reaguodama į tai, bendrovė priversta skubiai atlikti atnaujinimus.
Tokie nesėkmingi bandymai rodo, kaip svarbu kruopščiai pasiruošti.
2. Sėkmingas testavimas „nuo galo iki galo
„End-to-end” testavimas – tai testavimas, kuris atliekamas, kai programėlės funkcijos pirmą kartą visiškai sukomplektuojamos į vieną programinės įrangos paketą.
Įmonė kruopščiai suplanavo, kaip užbaigti visapusišką testavimo procesą, pasamdydama keletą darbuotojų, specialiai testavimo užduotims atlikti, o kiekvienam testavimo atvejui skirti du darbuotojai.
Vadovaudamiesi kruopščiu procesu, jie atlieka bandymų atvejus ir užrašo visus surinktus duomenis, o testavimo pabaigoje QA vadovas surenka duomenis į vientisą ataskaitą.
Kūrėjai šią ataskaitą naudoja planuodami kitas atnaujinimų ir pakeitimų serijas, taip gerokai patobulindami produktą.
3. Automatizuotas regresijos testavimas
Kūrėjas atliko keletą savo programinės įrangos, kuri iki atnaujinimų veikė, kaip tikėtasi, atnaujinimų. Po atnaujinimų testavimo komanda atlieka regresijos testavimo procesą, daugiausia dėmesio skirdama automatizavimui, ir gauna automatizuotą platformą visoms pagrindinėms funkcijoms atlikti.
Komanda parašo testavimo atvejo kodą ir vykdo testavimo atvejus, perskaito visus testų rezultatus ir nustato galimas problemas.
Taip užkertamas kelias problemoms kilti dėl to, kad organizacija atlieka atnaujinimus ir nepatikrina, ar juose yra problemų.
Klaidų ir klaidų, aptiktų atliekant juodosios dėžės testavimą, tipai
Nors juodosios dėžės testavimo procese klaidos ir klaidos nėra viskas, jos yra svarbi įmonių testavimo proceso dalis.
Žinant kai kuriuos pagrindinius klaidų ir klaidų tipus atliekant juodosios dėžės testavimą, galima suskirstyti visas problemas, su kuriomis susiduriate, ir geriau suprasti, kodėl jos atsiranda.
Pagrindinės klaidos ir klaidos, kurias galima aptikti atliekant „juodosios dėžės” testavimą, yra šios:
1. Naudojimo klaidos
Naudojamumo klaidos – tai programos trūkumai, kurie iš tikrųjų neturi įtakos funkcijoms, tačiau gali sukelti problemų naudotojui, bandančiam sąveikauti su programine įranga.
Pavyzdžiui, jei programa turi rimtų grafikos klaidų, ji vis dar techniškai veikia, tačiau be tinkamų piktogramų ir teksto galutinis naudotojas negali ja veiksmingai naudotis. Šios problemos dažniausiai susijusios su programėlės dizainu ir jos įkėlimo naudotojui būdu, o sudėtingesnėms programėlėms reikia sudėtingesnės grafikos nei paprastesnėse sąsajose.
2. Funkcinės klaidos
Funkcinės klaidos – tai problemos, kurios atsiranda, kai programos dalis neveikia taip, kaip tikėtasi.
Pavyzdžiui, jei naudojate duomenų bazės programinę įrangą ir bandote surūšiuoti informaciją pagal tam tikrą kategoriją, tačiau paaiškėja, kad tai neveikia. Tai pasakytina ir apie funkcijas, kurios iš viso neveikia, ir apie tas, kurios lyg ir veikia, bet veikia neteisingai.
Tai gali būti vienos svarbiausių programų problemų, kurios sukelia naudotojams daug nepatogumų ir pablogina kūrėjo reputaciją, nes produktas neveikia taip, kaip buvo skelbta.
3. Avarijos
Kai programinė įranga sutrinka, tai reiškia, kad programinė įranga iš esmės neveikia. Gali pasitaikyti kelių skirtingų formų gedimų, įskaitant tuos, kai programa uždaroma visa arba tiesiog užstringa viename proceso etape.
Avarija yra viena iš rimčiausių galimų problemų, nes nėra jokio būdo grąžinti programos funkcionalumą, išskyrus visišką jos uždarymą ir pakartotinį atidarymą. Nors kai kuriose programose fone vis dar vyksta procesai, nėra galimybės sąveikauti su programine įranga po šio taško.
Bendrieji juodosios dėžės testavimo rodikliai
Rankinis juodosios dėžės testavimas puikiai tinka kokybiniams duomenims gauti, tačiau kai daugiausia dėmesio skiriate kiekybiniams duomenims, turite žinoti, kokius rodiklius tikrinate. Visapusiškas šių rodiklių supratimas padeda suprasti platformos trūkumus ir nustatyti prioritetus įvairioms sritims, kuriose reikia dirbti.
Kai kurie dažniau pasitaikantys juodosios dėžės testavimo rodikliai, kuriuos rasite savo darbe, yra šie:
1. Klaidų lygis
Klaidų lygis gali reikšti kelis dalykus: grynąjį klaidų, įvykusių per programinės įrangos testavimo ciklą, skaičių arba klaidų, įvykusių per vieną testavimo valandą, skaičių. Valandiniai rodikliai yra geresni, nes jie parodo programinės įrangos klaidų tankį, o ne tiesiog nurodo skaičių, nes didesnės programos gali būti iškraipytos.
Kūrėjai siekia sumažinti klaidų skaičių savo programose, nes kuo mažiau klaidų bus programinės įrangos pakete, tuo geresnė bus kliento naudojimosi sistema patirtis.
2. Reakcijos laikas
Kai bandytojas nori išsiaiškinti daugiau apie naudotojo patiriamą našumo lygį, vienas iš pagrindinių aspektų, į kurį reikia atsižvelgti, yra atsako laikas. Tai reiškia laiką, per kurį programinė įranga atlieka užduotį po to, kai naudotojas įveda užklausą, o ilgesnis atsako laikas rodo, kad programa yra palyginti neveiksminga. Didesnis atsako laikas kelia susirūpinimą, nes naudotojai gali prarasti kantrybę, jei programa užtrunka per ilgai.
3. Vartotojų pasitenkinimas
Dauguma metrikų daugiausia dėmesio skiria gryniems skaičiams, kuriuos sukuria programinės įrangos paketas ir testavimo programinė įranga, tačiau kai kurios metrikos daugiausia dėmesio skiria nuomonei.
Pavyzdžiui, jei įmonė atlieka beta testą, kuriame dalyvauja 1000 testuotojų, ji gali surinkti duomenis apie patenkintų žmonių skaičių ir išreikšti juos procentais. Tai labai naudingas rodiklis, kurį galima gauti ciklo pabaigoje, nes didesnis naudotojų pasitenkinimas rodo, kad programa patinka daugiau žmonių, o tai reiškia, kad tikėtina, jog ji bus sėkminga ir ateityje.
Geriausi juodosios dėžės testavimo įrankiai
„Juodosios dėžės” testavimas – tai testavimo forma, kuriai atlikti labai svarbu turėti įrankius, skirtus tiek „juodosios dėžės” testavimui automatizuoti, tiek testų metu gautai informacijai tvarkyti.
Tinkamas įrankių derinys gali padėti jums ir jūsų komandai dirbti daug efektyviau ir sukurti veiksmingesnius procesus visame kokybės užtikrinimo skyriuje.
Toliau rasite keletą geriausių juodosios dėžės testavimo įrankių ir sužinosite, kaip tiksliai kiekvienas iš jų gali padėti jums klestėti:
5 geriausi nemokami juodosios dėžutės testavimo įrankiai
Mažos ir besikuriančios įmonės, pavyzdžiui, nepriklausomi kūrėjai, kurdami programinę įrangą neturi didelio biudžeto. Dėl to gali kilti įvairių iššūkių, įskaitant tinkamų darbo priemonių paiešką.
Toliau pateikiami keli geriausi nemokami įrankiai, kuriais gali naudotis nepriklausomi kūrėjai, norintys patobulinti savo darbo eigą turėdami mažą biudžetą:
1. „ZAPTEST” NEMOKAMAS LEIDIMAS
Nemokamas ZAPTEST leidimas yra puikus įvadas į programinės įrangos testavimo automatizavimą. Šis įrankis specialiai sukurtas automatizuoti bet kokią užduotį, kad galėtumėte dirbti greičiau ir efektyviau, nepriklausomai nuo atliekamos užduoties.
Nemokamoje ZAPTEST versijoje yra daugybė funkcijų, padedančių automatizuoti bet kokią programą… 1SCRIPT įgyvendinimas tarp naršyklių, įrenginių, programų ir lygiagretus vykdymas yra viena iš galimų funkcijų.
2. JIRA
Nemokamos „JIRA” versijos yra puikūs įrankiai, skirti klaidoms užrašyti, išsamiai aprašyti į bilietus ir nustatyti jų prioritetus bendraujant su kūrimo komanda.
Tačiau ši programa nėra universali automatizavimo priemonė, ji specializuojasi tik testavimo proceso projekto valdymo srityje.
3. Selenium IDE
Tai atvirojo kodo programa, kuri įrašo ir atkuria testavimo automatizavimą, ir yra geras įrankis, leidžiantis pamatyti, ką automatizavimo platforma mato atlikdama testą.
Vienas iš „Selenium” trūkumų – santykinai trūksta pažangių funkcijų, pvz., automatizuotų užduočių integravimo į įvairias platformas.
4. AutoHotkey
„AutoHotkey” yra visiškai nemokama atvirojo kodo scenarijų kalba, skirta „Windows” sistemai, kuria naudotojai gali kurti įvairaus dydžio scenarijus, kurie, įvedus vieną klavišų paspaudimą, atlieka tam tikras užduotis.
Nors „AutoHotkey” tinka paprastoms užduotims automatizuoti, ji gali susidurti su sunkumais, kai reikia atlikti didesnius scenarijus ir automatizavimo reikalavimus.
5. Appium
Ši programa yra ideali priemonė, kuri visų pirma puikiai tinka automatizuoti „iOS” programas, todėl ją galima naudoti norint pagerinti mobiliųjų programų kokybę.
Didžiausias „Appium” trūkumas yra tai, kad galite naudoti tik labai nedidelį produktų asortimentą, o tai labai sumažina jūsų turimą rinką.
5 geriausi įmonių juodosios dėžės testavimo įrankiai
Nemokami įrankiai yra gerai, tačiau įmonėms ir didelėms bendrovėms reikia daugiau funkcijų, kad galėtų nuodugniai išbandyti savo programinę įrangą. Laimei, kai kurios geriausios įmonių juodosios dėžės testavimo priemonės pasižymi išsamiomis funkcijomis ir padeda įmonėms gauti didelę investicijų į kokybės užtikrinimo procesus grąžą.
Keletas idealių įmonių juodosios dėžės testavimo įrankių, į kuriuos verta investuoti:
1. „ZAPTEST ENTERPRISE EDITION
„ZAPTEST Enterprise” versija yra vienas svarbiausių automatizavimo įrankių rinkoje, galintis užtikrinti iki 10 kartų didesnę investicijų į jūsų produktą grąžą.
Tokios funkcijos, kaip prieiga prie visą darbo dieną dirbančio ZAP eksperto, kuris yra nuotolinė jūsų komandos dalis, ir neribotas licencijų skaičius, užtikrina, kad juodosios dėžės bandymų automatizavimą galite įdiegti be didelių mokymosi sunkumų ir už fiksuotą kainą, nepriklausomai nuo to, kaip sparčiai augate.
2. TestRail
„TestRail” – tai platforma, skirta testavimui realiuoju laiku, kurios tikslas – sujungti jūsų testus su vientisa projektų valdymo platforma. Nors tai idealiai tinka komandos valdymo darbui centralizuoti, automatizavimo funkcijos toli gražu netinka kūrimo komandai, kuri nori daug dėmesio skirti automatizuotiems testams.
3. Opkey
„Opkey” yra platforma, kurioje daugiausia dėmesio skiriama automatizavimui be kodo, o tai reiškia, kad žmonės, neturintys techninių žinių, gali pradėti automatizuoti savo testavimo paslaugas.
Vienas iš pagrindinių „Opkey” trūkumų yra aktyvios bendruomenės, supančios programinę įrangą, trūkumas, todėl bandydami automatizuoti jums nauju būdu galite jaustis gana atsidūrę aklavietėje.
4. Perfecto
„Perfecto” – tai įrankis, kurio pagrindinis tikslas – padėti naudotojams automatizuoti mobiliąsias programas be jokių rimtų problemų, dirbti su įvairiais įrenginiais ir sutelkti dėmesį į visapusišką testavimą.
Tačiau programa veikia tikruose įrenginiuose, o ne virtualiose mašinose, o tai padidina ir taip gana brangią ribotų platformų testavimo priemonę.
5. JIRA Enterprise
Be automatinio testavimo užbaigimo, vis dar svarbus ir projektų valdymas, todėl čia praverčia „JIRA”. „Enterprise JIRA” turi daugiau saugyklos ir suteikia galimybę daugiau naudotojų naudotis platforma, tačiau gali kilti painiavos, nes kiekvienam naudotojui reikia nustatyti individualius leidimus ir prieigą. Tam reikia daug administracinio laiko.
Kada turėtumėte naudoti
Įmonių ir nemokamų juodųjų dėžučių įrankiai?
Pirmiausia dauguma įmonių naudosis nemokamomis „juodosios dėžutės” priemonėmis. Tai prasminga ekonominiu požiūriu, nes jokia protinga įmonė nenori investuoti į produktą, kurio iki galo nesupranta, nesvarbu, ar tai būtų projektų valdymo, ar automatizavimo požiūriu.
Nemokami įrankiai – tai ne tik visiškai nemokamos programėlės, bet ir nemokamos įmonių produktų versijos, kuriomis įmonė naudojasi mokydamasi, kaip įdiegti įrankį į savo procesus.
Idealus laikas organizacijai atnaujinti pasirinktą įrankį į įmonės versiją yra tada, kai dėl nemokamo įrankio įmonė pradeda patirti trikdžių testavimo procesuose. Nesvarbu, ar tai būtų nemokama priemonė, siūlanti tik tam tikrą licencijų skaičių, ar testavimo apimtis, kai tik pradedate jausti savo procesų neveiksmingumą dėl testavimo priemonių, turėtumėte pereiti prie įmonės versijos, atitinkančios visus jūsų poreikius.
Juodosios dėžės testavimo kontrolinis sąrašas, patarimai ir gudrybės
Kadangi juodosios dėžės testavimas yra labai sudėtingas testavimo metodas, suteikiantis daug galimybių gilinti žinias apie programinės įrangos paketą, reikia atkreipti dėmesį į keletą dalykų.
Keletas svarbių patarimų ir gudrybių, kuriuos reikėtų įtraukti į juodosios dėžės testavimo kontrolinį sąrašą:
– Trumpo supratimas
Prieš pradėdami planuoti bandymus, įsitikinkite, kad suprantate platesnį bandymų laikotarpio aprašą. Tai reiškia, kad reikia suprasti programinę įrangą tiek, kiek jums leidžiama, ir tiksliai sužinoti, ką turite išbandyti.
– Testo atvejo tikrinimas
Pasistenkite, kad visi testavimo dalyviai įvertintų testavimo atvejus, kuriuos naudojate atlikdami juodosios dėžės testavimą. Kuo daugiau akių matys testavimo atvejį prieš jį įgyvendinant, tuo didesnė tikimybė pašalinti bet kokias klaidas.
– Sudarykite darbų, kuriuos reikia atlikti, sąrašą
Netechninė pasirengimo juodosios dėžės testavimui pusė gali būti tokia pat svarbi kaip ir techninė. Planuodami sukurkite nuoseklų atliktinų darbų sąrašą, kuriame būtų nurodyta, kas ir kokią programinės įrangos dalį testuos konkrečiu laiku. Tai sumažina sumaištį, galimą perdegimą ir vėlavimą dėl kitų užduočių.
– Nedelsiant įrašykite rezultatus
Nedelsdami įrašykite visus testo rezultatus. Per ilgai laukdami rankiniu būdu atliekamų testų galite klaidingai įsiminti problemas, todėl momentinių užrašų darymas gerokai padidina tikslumą.
– Bendravimas su kūrėjais
Aptarkite testavimo tvarkaraštį ir strategiją su kūrėjais, kad jie suprastų, kas vyksta ir kada gali tikėtis dirbti su naujais atnaujinimais. Tai reiškia, kad reikia nustatyti aiškius procesus, pagal kuriuos skyriai bendrauja tarpusavyje.
– Veiksmingi duomenys
Rašydami ataskaitą įsitikinkite, kad visi duomenys, kuriuos pateikiate kūrėjui, yra tinkami naudoti. Tai padeda komandai kurti produktą, kuris reaguoja į jos problemas, o ne kūrėjui nesuprasti, kokius pakeitimus reikia atlikti.
– Supraskite savo prioritetus
Jūsų, kaip testavimo komandos, prioritetas – užtikrinti, kad įmonė naudotojams pateiktų aukštos kokybės produktą. Jei testavimas užtrunka šiek tiek ilgiau nei tikėtasi, nepamirškite, kad tai yra vertingas mainais į geresnę kokybę, kurią patiria klientas.
– Žinokite hierarchiją
Idealioje kūrimo įmonėje kūrėjai ir testuotojai yra to paties hierarchijos lygio ir turi vienodai svarbų balsą kuriant programinę įrangą. Supraskite, kokia hierarchija vyrauja jūsų organizacijoje, ir pasistenkite, kad visi suprastų gero testavimo vertę.
– Nuosekliai tvarkykite dokumentus
Saugokite visų bandymų metu gautų duomenų ir ataskaitų kopijas. Galite stebėti programėlės pakeitimus, už kuriuos atsakinga testavimo komanda, taip pat peržiūrėti senas klaidas, kad pamatytumėte, ar jos nepasikartojo būsimuose leidimuose.
Išvada
Juodosios dėžės testavimas yra viena svarbiausių programinės įrangos testavimo proceso dalių. Tai padeda įmonėms įsitikinti, kad jų siunčiami produktai atitinka aukščiausius įmanomus standartus, ir padeda pakeisti perspektyvą, kad būtų galima gauti unikalių įžvalgų apie tai, kaip programą suvokia ir įgyvendina išorės naudotojas.
Įmonė, kuri į savo procesus neįtraukia automatinio ir rankinio „juodosios dėžės” testavimo, praranda galimybę gerokai pagerinti savo programos kokybę. Testuokite protingai ir sulauksite naudos, kai klientai galės naudotis jūsų produktu.
DUK ir ištekliai
Nepriklausomai nuo to, kiek daug žinote apie juodosios dėžės testavimą, jums gali kilti daugiau klausimų ir norėsite geriau suprasti šį metodą. Norėdami sužinoti daugiau apie juodosios dėžės testavimą ir susipažinti su įvairiais ištekliais, kuriuose galite rasti daugiau informacijos apie šią metodiką, žr. toliau pateiktus dažniausiai užduodamus klausimus.
1. Geriausi juodosios dėžės testavimo automatizavimo kursai
Yra keletas juodosios dėžės testavimo automatizavimo kursų, kuriuos galite lankyti, ir kiekvienas iš jų padeda žmonėms pasiekti skirtingus testavimo standartus.
Kai kurie iš labiausiai vertinamų juodosios dėžės testavimo kursų:
– „Juodosios ir baltosios dėžės testavimas” pagal „Coursera
– „Juodosios dėžės programinės įrangos testavimo serija” pagal BBST
– „Įvadas į „juodosios dėžės” programinės įrangos testavimo metodus” pagal „Udemy
– „Programinės įrangos automatizavimo testavimas”, Londono naujųjų technologijų mokykla
– „Trys pagrindiniai „juodosios dėžės” testavimo metodai” pagal „Udemy
2. Kokie yra 5 svarbiausi interviu klausimai apie juodosios dėžės testavimą?
Programinės įrangos testavimas yra labai konkurencinga sritis, kurioje į kiekvieną laisvą darbo vietą pretenduoja daugybė kandidatų. Jei dalyvausite pokalbyje dėl darbo juodosios dėžės testavimo srityje, galbūt norėsite pasiruošti atsakyti į šiuos klausimus per pokalbį:
– Kokios patirties turite dirbant su juodosios dėžės testavimu?
– Kokie yra pagrindiniai juodosios ir baltosios dėžės testavimo skirtumai?
– Ar turite patirties dirbant su programinės įrangos automatizavimu ankstesnėse pareigose?
– Ar galite papasakoti, kada teko susidurti su sunkumais darbe ir kaip juos įveikėte?
– Kaip manote, kokia yra juodosios dėžės testavimo ateitis ir kaip jūsų įgūdžiai tinka ilgalaikei karjerai programinės įrangos testavimo srityje?
3. Geriausios „Youtube” pamokos apie juodosios dėžės testavimą
„YouTube” yra vienas iš svarbiausių mokymosi šaltinių, kuriais gali naudotis tobulinantys programinės įrangos testavimo įgūdžius, nes tai nemokamas informacijos šaltinis, kuriuo galite naudotis tobulindami savo techniką.
Keletas geriausių pamokų, kurias verta žiūrėti mokantis „juodosios dėžės” testavimo, yra šios:
– „Juodosios ir baltosios dėžutės testavimo įvadas – Georgia Tech – Programinės įrangos kūrimo procesas” pagal Udacity
– „Juodosios ir stiklinės dėžės testavimas”, MIT OpenCourseWare
– „7 „juodosios dėžės” testavimo metodai, kuriuos turėtų išmanyti kiekvienas QA” – „The Testing Academy
– „Juodosios dėžės testavimas | Kas yra juodosios dėžės testavimas | Sužinokite, kas yra juodosios dėžės testavimas”, Intellipaat
– „Kas yra baltosios ir pilkosios bei juodosios dėžės testavimas?” – ITProTV
4. Kaip išlaikyti juodosios dėžės testus?
Atliekant juodosios dėžės testus, nesvarbu, ar tai būtų rankiniai, ar automatiniai testai, reikia atkreipti dėmesį į atliekamus testus ir nuolat ieškoti pataisymų, jei kyla problemų.
Tai reiškia, kad reikia įsitikinti, jog visi bandymų atvejai kiekvieną kartą atliekami taip, kaip tikitės, ir patikrinti, ar automatinės priemonės atlieka visus teisingus veiksmus. Tai darykite kuo dažniau, kad jūsų standartai nenukristų, nes gerai prižiūrimas juodosios dėžės testas yra toks, kuris duoda kuo tikslesnius rezultatus.
5. Geriausios knygos apie juodosios dėžės testavimą
Nors juodosios dėžės testavimas ir apskritai programinės įrangos testavimas yra nuolat tobulėjanti sritis, yra keletas knygų, kurios išlieka aktualios ir suteikia daug įžvalgų, kaip patobulinti savo testavimo darbą.
Keletas geriausių knygų apie juodosios dėžės testavimą:
– „Juodosios dėžės” testavimas: Boris Beizer: „Programinės įrangos ir sistemų funkcinio testavimo metodai
– „Programinės įrangos testavimas: Srinivasan Desikan, Gopalaswamy Ramesh, „Principles and Practice”.
– „Programinės įrangos testavimo pagrindai”, Ralf Bierig, Stephen Brown, Edgar Galván
– „Programinės įrangos testavimo įvadas”, Paul Ammann, Jeff Offutt
