Phenquestions
Vieneto testavimas
„Unit Testing“ yra atskiros funkcijos, klasės ar modulio testavimas, atliekamas nepriklausomai nuo visiškai veikiančios programinės įrangos. Naudodamas vieneto testavimo sistemą, programuotojas gali sukurti bandomuosius atvejus su įvestimi ir laukiama išvestimi. Turėdami šimtus, tūkstančius ar keliasdešimt tūkstančių vienetų bandymų atvejų dideliam programinės įrangos projektui, užtikrinsite, kad visi atskiri vienetai veiks taip, kaip tikėtasi, nes toliau keisite kodą. Keičiant vienetą, kuriame yra bandymų atvejų, reikia ištirti to modulio bandymo atvejus ir nustatyti, ar reikalingi nauji bandymo atvejai, ar pasikeitė išvestis, ar dabartinius bandymo atvejus galima pašalinti kaip nebesvarbius. Sukurti daug vienetinių bandymų yra paprasčiausias būdas pasiekti didelę programinės įrangos kodo bandomųjų atvejų aprėptį, tačiau neužtikrinsite, kad galutinis produktas veikia kaip sistema, kaip tikėtasi.
Funkcinis testavimas
Funkcinis testavimas yra labiausiai paplitusi testavimo forma. Kai žmonės nurodo programinės įrangos testavimą be daug detalių, jie dažnai reiškia funkcinį testavimą. Funkcinis testavimas tikrins pagrindines programinės įrangos funkcijas, kaip tikėtasi. Galima būtų parašyti testavimo planą, kuris apibūdintų visus tikrintinus funkcinius bandymus, kurie atitinka pagrindines programinės įrangos savybes ir galimybes. Pagrindinis funkcionalumo testavimas bus „laimingas kelias “ bandymas, kuris nesistengia sugadinti programinės įrangos ar naudoti ją bet kokiuose iššūkių scenarijuose. Tai turėtų būti absoliutus bet kokio programinės įrangos projekto bandymų minimumas.
Integracijos testavimas
Po vieneto testavimo ir funkcinio patikrinimo gali būti keli moduliai arba visa sistema, kuri dar nėra išbandyta kaip visuma. Arba gali būti komponentų, kurie iš esmės yra nepriklausomi, tačiau kartais naudojami kartu. Bet kuriuo metu komponentai ar moduliai išbandomi atskirai, bet ne kaip visa sistema, tada reikia atlikti integravimo bandymus, kad komponentai veiktų kartu kaip veikianti sistema pagal vartotojo reikalavimus ir lūkesčius.
Streso testavimas
Pagalvokite apie testavimą nepalankiausiomis sąlygomis, pavyzdžiui, bandote kosminį autobusą ar lėktuvą. Ką reiškia programinę įrangą ar sistemą priskirti stresui? Stresas yra ne kas kita, kaip intensyvus tam tikro tipo krūvis, kuris greičiausiai sulaužys jūsų sistemą. Tai gali būti panašu į „Apkrovos testavimą“, kad jūsų sistema būtų labai suderinama su daugeliu vartotojų, kurie naudojasi sistema. Tačiau pabrėžti sistemą gali atsitikti ir kituose vektoriuose. Pavyzdžiui, aparatinės įrangos komponento programinės įrangos paleidimas, kai aparatinė įranga fiziškai sugedo ir veikia prastesnio režimo. Stresas yra būdingas visų tipų programinei įrangai, o sistemoms ir testavimui nepalankiausiomis sąlygomis reikia atsižvelgti į tai, kokios natūralios ar nenatūralios priežastys labiausiai gali sukelti jūsų programinei įrangai ar sistemai.
Apkrovos tikrinimas
Apkrovos testavimas yra tam tikras streso testavimo tipas, kaip aptarta pirmiau, kai automatizuojamas didelis skaičius tuo pačiu metu veikiančių vartotojų ryšių ir prieigų, kad būtų sukurtas daugybės autentiškų vartotojų, kurie tuo pačiu metu naudojasi jūsų programinės įrangos sistema, poveikio modeliavimas. Tikslas yra išsiaiškinti, kiek vartotojų gali vienu metu pasiekti jūsų sistemą, nesulaužant jūsų programinės įrangos sistemos. Jei jūsų sistema gali lengvai valdyti įprastą 10 000 vartotojų srautą, kas nutiks, jei jūsų svetainė ar programinė įranga taps virusinė ir sulauks 1 milijono vartotojų? Ar tai netikėta „KROVA“ sugadinti savo svetainę ar sistemą? Apkrovos bandymai tai imituos, todėl būsite patenkinti ateityje didėjančiu vartotojų skaičiumi, nes žinote, kad jūsų sistema gali atlaikyti padidintą apkrovą.
Našumo testavimas
Kai programinė įranga neatitinka jų našumo reikalavimų, žmonės gali visiškai nusivilti ir nusivilti. Našumas paprastai reiškia, kaip greitai galima atlikti svarbias funkcijas. Kuo sudėtingesnės ir dinamiškesnės funkcijos yra sistemoje, tuo svarbiau ir nėra akivaizdu išbandyti jos veikimą. Paimkime pagrindinį pavyzdį, „Windows“ arba „Linux“ operacinė sistema. Operacinė sistema yra labai sudėtingas programinės įrangos produktas, o atlikus jos sistemos testavimą gali reikėti tokių funkcijų kaip „Bootup“, programos diegimo, failo paieškos, skaičiavimų vykdymo GPU ir (arba) bet kurio kito greičio ir laiko. milijonai veiksmų, kuriuos galima atlikti. Renkantis eksploatacinių savybių bandymo atvejus reikia būti atsargiems, kad būtų užtikrintos svarbios ir tikėtina, kad gali sutrikti tikrinamos eksploatacinės savybės.
Mastelio tikrinimas
Testavimas nešiojamuoju kompiuteriu yra geras, bet nepakankamai geras, kai kuriate socialinį tinklą, el. Pašto sistemą ar superkompiuterio programinę įrangą. Kai jūsų programinę įrangą ketinama diegti 1000 serverių, kurie visi veikia vieningai, bandymai, kuriuos atliksite vietoje vienoje sistemoje, neatskleis klaidų, kurios atsiranda, kai programinė įranga yra įdiegta „At Scale“ šimtuose tūkstančių atvejų. Tikrovėje tikriausiai niekada nebus galima paleisti visu mastu prieš išleidžiant į gamybą, nes būtų per brangu ir netikslinga sukurti bandomąją sistemą su 1000 serverių, kainuojančių milijonus dolerių. Todėl mastelio tikrinimas atliekamas keliuose serveriuose, tačiau paprastai ne visas gamybinių serverių skaičius, siekiant išbandyti kai kuriuos defektus, kurie gali būti rasti, kai jūsų sistemos naudojamos didesnėje infrastruktūroje.
Statinės analizės testavimas
Statinė analizė yra bandymas, kuris atliekamas tikrinant programinės įrangos kodą, jo faktiškai nevykdant. Norėdami atlikti statinę analizę, paprastai naudosite įrankį, yra daug, vienas žinomas įrankis yra „Coverity“. Statinę analizę lengva paleisti prieš išleidžiant programinę įrangą. Joje galite rasti daug kokybės problemų, kurias galima išspręsti prieš išleidžiant. Galima rasti atminties klaidų, duomenų tipo apdorojimo klaidų, nulinių rodyklių išimčių, neinicijuotų kintamųjų ir daug daugiau defektų. Tokioms kalboms kaip C ir C ++ labai naudinga statinė analizė, nes kalbos suteikia didelę laisvę programuotojams mainais į didelę galią, tačiau tai taip pat gali sukurti didelių klaidų ir klaidų, kurias galima rasti naudojant statinės analizės testavimą.
Gedimų įpurškimo testavimas
Kai kurias klaidų sąlygas labai sunku imituoti ar suaktyvinti, todėl programinė įranga gali būti sukurta dirbtinai įterpti į problemą ar gedimą į sistemą be natūraliai atsirandančio defekto. Klaidų įpurškimo bandymo tikslas yra sužinoti, kaip programinė įranga tvarko šiuos netikėtus gedimus. Ar tai maloniai reaguoja į situaciją, ar sugenda, ar duoda netikėtų ir nenuspėjamų probleminių rezultatų? Pvz., Tarkime, kad mes turime bankų sistemą ir yra modulis, skirtas pervesti lėšas iš A sąskaitos į B sąskaitą. Tačiau ši perkėlimo operacija iškviečiama tik tada, kai prieš skambindama pervedimo operacijai sistema jau patikrino, ar šios paskyros egzistuoja. Nors manome, kad abi sąskaitos iš tikrųjų egzistuoja, perkėlimo operacija turi gedimo atvejį, kai nėra vienos tikslinės ar šaltinio paskyros, ir kad tai gali sukelti klaidą. Kadangi įprastomis aplinkybėmis šios klaidos niekada negauname dėl išankstinio įvesties patikrinimo, todėl norėdami patikrinti sistemos elgseną, kai pervedimas nepavyksta dėl neegzistuojančios paskyros, į sistemą įterpiame suklastotą klaidą, kuri grąžina neegzistuojančią sąskaitą ir patikrinkite, kaip tokiu atveju reaguoja likusi sistemos dalis. Labai svarbu, kad gedimo įpurškimo kodas būtų prieinamas tik testavimo scenarijuose ir nebūtų išleistas į gamybą, kur jis gali sukelti sumaištį.
Atminties viršijimo testavimas
Naudodamas tokias kalbas kaip C arba C ++, programuotojas turi didelę atsakomybę tiesiogiai spręsti atmintį, o tai gali sukelti programinės įrangos klaidas, jei padaroma klaidų. Pvz., Jei rodyklė yra nulinė ir nenurodyta, programinė įranga sugenda. Jei objektui priskiriama atmintis, o tada objekto atminties erdvėje nukopijuojama eilutė, nuoroda į objektą gali sukelti avariją ar net nenurodytą neteisingą elgesį. Todėl labai svarbu naudoti įrankį bandant užfiksuoti atminties prieigos klaidas programinėje įrangoje, naudojančioje tokias kalbas kaip C arba C ++, kurios gali turėti šių galimų problemų. Įrankiai, galintys atlikti tokio tipo bandymus, yra „Open Source“ „Valgrind“ arba patentuoti įrankiai, tokie kaip „PurifyPlus“. Šie įrankiai gali išgelbėti dieną, kai nėra aišku, kodėl programinė įranga sugenda ar netinkamai elgiasi, ir tiesiogiai nurodyti vietą kode, kuriame yra klaida. Nuostabu, tiesa?
Ribinių atvejų testavimas
Lengva padaryti klaidų koduojant, kai esate ant vadinamosios ribos. Pavyzdžiui, banko automatas sako, kad galite atsiimti ne daugiau kaip 300 USD. Taigi, įsivaizduokite, kad kurdamas šį reikalavimą koduotojas natūraliai parašė šį kodą:
Jei (amt < 300)startWithdrawl ()
Kitas
klaida („Galite atsiimti% s“, amt);
Ar galite pastebėti klaidą? Vartotojas, bandantis atsiimti 300 USD, gaus klaidą, nes ji yra ne mažesnė kaip 300 USD. Tai yra klaida. Todėl ribų testavimas atliekamas natūraliai. Reikalavimų ribos tada užtikrina, kad programinė įranga tinkamai veiktų abiejose ribos ir ribos pusėse.
Fuzz testavimas
Greitai generuojant įvestį į programinę įrangą, galima sukurti kuo daugiau įvesties derinių, net jei tie įvesties deriniai yra visiška nesąmonė ir niekada jų nepateiks tikras vartotojas. Šio tipo „fuzz“ bandymai gali rasti klaidų ir saugumo spragų, nerastų kitomis priemonėmis dėl didelio įvesties kiekio ir scenarijų, greitai išbandytų be rankinio bandymo atvejo generavimo.
Tiriamasis testavimas
Užmerkite akis ir įsivaizduokite, ką reiškia žodis „Naršyti“. Stebite ir tikrinate sistemą, kad sužinotumėte, kaip ji iš tikrųjų veikia. Įsivaizduokite, kad paštu gausite naują stalo kėdę, kurioje yra 28 dalys, atskirose plastikinėse maišeliuose be instrukcijų. Turite ištirti savo naują atvykimą, kad išsiaiškintumėte, kaip jis veikia ir kaip jis yra sudarytas. Su šia dvasia galite tapti tiriamuoju bandytoju. Neturėsite tiksliai apibrėžto bandymų atvejų testavimo plano. Išnagrinėsite ir ištirsite savo programinę įrangą, ieškodami dalykų, verčiančių pasakyti nuostabų žodį: „Įdomu!“. Sužinoję, jūs toliau tyrinėjate ir ieškote būdų, kaip sugadinti programinę įrangą, apie kurią dizaineriai niekada negalvojo, ir tada pateikti ataskaitą, kurioje išsamiai aprašyta daugybė blogų programinės įrangos prielaidų, gedimų ir rizikos. Sužinokite daugiau apie tai knygoje „Naršyti“.
Skverbimosi bandymai
Programinės įrangos saugumo pasaulyje skvarbos testavimas yra viena iš pagrindinių bandymų priemonių. Visos biologinės, fizinės ar programinės įrangos sistemos turi sienas ir ribas. Šios ribos yra skirtos leisti tik tam tikriems pranešimams, žmonėms ar komponentams patekti į sistemą. Konkrečiau apsvarstykime internetinės bankininkystės sistemą, kuri naudoja vartotojo autentifikavimą įeinant į svetainę. Jei svetainę galima nulaužti ir įvesti į vidinę programą be tinkamo autentifikavimo, tai būtų įsiskverbimas, kurį reikia apsaugoti. Skverbimosi bandymų tikslas yra naudoti žinomus ir eksperimentinius metodus, kad būtų išvengta įprastos programinės įrangos sistemos ar svetainės saugumo ribos. Skverbimosi bandymai dažnai apima visų klausomų prievadų patikrinimą ir bandymą įeiti į sistemą per atvirą prievadą. Kiti įprasti būdai yra SQL įvedimas arba slaptažodžių nulaužimas.
Regresijos testavimas
Turėdami veikiančią programinę įrangą, kuri yra įdiegta šioje srityje, labai svarbu užkirsti kelią klaidoms įvesti į jau veikiančią funkciją. Programinės įrangos kūrimo tikslas yra padidinti jūsų produkto galimybes, pristatyti klaidas arba nustoti veikti senoms funkcijoms, kurios vadinamos REGRESIJA. Regresija yra klaida ar defektas, kuris buvo pateiktas, kai anksčiau ši funkcija veikė taip, kaip tikėtasi. Niekas negali sugadinti jūsų programinės įrangos ar prekės ženklo reputacijos greičiau, nei įdiegti regresijos klaidas į savo programinę įrangą ir tikriems vartotojams rasti šias klaidas po leidimo.
Regresijos testavimo atvejai ir bandymų planai turėtų būti sudaryti iš pagrindinių funkcijų, kurios turi tęsti darbą, kad vartotojai turėtų gerą patirtį su jūsų programa. Visose pagrindinėse jūsų programinės įrangos funkcijose, kurias vartotojai tikisi veikti tam tikru būdu, turėtų būti regresijos testo atvejis, kurį galima atlikti, kad būtų išvengta funkcijų sulaužymo naujame leidime. Tai gali būti nuo 50 iki 50 000 bandomųjų atvejų, kurie apima pagrindinę jūsų programinės įrangos ar programos funkciją.
Šaltinio kodo padalijimo testavimas
Programinėje įrangoje buvo įvesta klaida, tačiau nėra akivaizdu, kuri leidimo versija pristatė naują klaidą. Įsivaizduokite, kad buvo 50 programinės įrangos įsipareigojimų nuo paskutinio žinomo laiko, kai programinė įranga veikė be klaidos, iki šiol, kai…
Lokalizavimo testavimas
Įsivaizduokite orų programą, kurioje būtų rodomi dabartiniai ir numatomi orai jūsų vietoje, taip pat oro sąlygų aprašymas. Pirmoji lokalizacijos testavimo dalis yra užtikrinti, kad teisinga kalba, abėcėlė ir simboliai būtų rodomi tinkamai, atsižvelgiant į vartotojo geografinę vietą. Jungtinėje Karalystėje esanti programa turėtų būti rodoma anglų kalba lotyniškais rašmenimis; ta pati programa Kinijoje turėtų būti rodoma kinų kalbos simboliais kinų kalba. Atliktas išsamesnis lokalizacijos bandymas, su programa sąveikaus platesnis žmonių skaičius iš skirtingų geografinių vietovių.
Prieinamumo testavimas
Kai kurie mūsų bendruomenės piliečiai turi negalią, todėl gali kilti problemų naudojant kuriamą programinę įrangą, todėl atliekami pritaikymo neįgaliesiems bandymai, siekiant užtikrinti, kad neįgalūs gyventojai vis tiek galėtų naudotis sistemos funkcijomis. Pvz., Jei manome, kad 1% gyventojų yra daltoniai, o mūsų programinės įrangos sąsajoje daroma prielaida, kad vartotojai gali atskirti raudoną ir žalią, tačiau tie spalvai akli asmenys NEGALI pasakyti skirtumo. Todėl gerai programinės įrangos sąsajoje bus papildomų užuominų, esančių už spalvos, kad nurodytų prasmę. Kiti scenarijai, be spalvinio aklumo testavimo, taip pat būtų įtraukti į programinės įrangos pritaikymo neįgaliesiems testus, tokie kaip visiškas regėjimas, apkurtimas ir daugelis kitų scenarijų. Geras programinės įrangos produktas turėtų būti prieinamas maksimaliam potencialių vartotojų procentui.
Naujovinimo testavimas
Reikia dažnai atnaujinti paprastas telefono programas, operacines sistemas, tokias kaip „Ubuntu“, „Windows“ ar „Linux Mint“, ir programinę įrangą, valdančią branduolinius povandeninius laivus. Pats naujovinimo procesas galėjo sukelti klaidų ir defektų, kurių nebūtų naujame diegime, nes aplinkos būklė buvo kitokia, o naujos programinės įrangos diegimo ant senosios procesas galėjo sukelti klaidų. Paimkime paprastą pavyzdį: mes turime nešiojamąjį kompiuterį, kuriame veikia „Ubuntu 18“.04, ir mes norime atnaujinti į „Ubuntu 20“.04. Tai kitoks operacinės sistemos diegimo procesas, nei tiesioginis kietojo disko valymas ir „Ubuntu 20“ diegimas.04. Todėl, įdiegus programinę įrangą ar bet kurią iš jos išvestinių funkcijų, ji gali neveikti 100%, kaip tikėtasi, arba tokia pati kaip tada, kai programinė įranga buvo ką tik įdiegta. Taigi pirmiausia turėtume apsvarstyti galimybę išbandyti patį naujovinimą daugeliu skirtingų atvejų ir scenarijų, kad įsitikintume, jog naujovinimas veikia iki galo. Tada mes taip pat turime apsvarstyti tikrojo sistemos testavimą po atnaujinimo, kad įsitikintume, jog programinė įranga buvo sukurta ir veikė taip, kaip tikėtasi. Mes nekartotume visų naujai įdiegtos sistemos bandymų atvejų, o tai būtų laiko švaistymas, tačiau gerai apgalvosime savo žinias apie sistemą, ką GALI nutraukti atnaujinimo metu ir strategiškai pridėtume tų funkcijų bandymų atvejus.
Juodosios dėžės ir baltosios dėžės testavimas
Juodoji dėžutė ir baltoji dėžutė yra mažiau specifinės bandymų metodikos ir daugiau kategorizavimo tipų bandymai. Iš esmės, juodosios dėžės testavimas, kuris daro prielaidą, kad testeris nieko nežino apie vidinį programinės įrangos darbą, ir sukuria testavimo planą ir bandymo atvejus, kurie tik pažvelgia į sistemą iš išorės, kad patikrintų jos funkciją. „Baltosios dėžės“ testavimą atlieka programinės įrangos architektai, kurie supranta vidinį programinės įrangos veikimą ir suprojektuoja atvejus žinodami, kas galėtų, turėtų, turėtų ir gali sulūžti. Atliekant tiek juodos, tiek baltos dėžės testus greičiausiai bus rasti skirtingų tipų defektai.
Dienoraščiai ir straipsniai apie programinės įrangos testavimą
Programinės įrangos testavimas yra dinamiška sritis ir daug įdomių leidinių bei straipsnių, kurie atnaujina bendruomenę apie naujausią mintį apie programinės įrangos testavimą. Mes visi galime pasinaudoti šiomis žiniomis. Čia pateikiami įdomių straipsnių iš skirtingų tinklaraščio šaltinių pavyzdžiai, kuriuos galbūt norėsite sekti:
- 7 patarimai, kurių reikia laikytis prieš bandant be reikalavimų; http: // www.testavimo žurnalai.com /
- 60 geriausių automatikos testavimo įrankių: „Ultimate List Guide“; https: // testguild.com /
- Atvirojo kodo duomenų bazių testavimo įrankiai; https: // www.minkšto bandymožurnalas.com /
- Nepakanka 100 procentų vieneto bandymo aprėpties; https: // www.lipdukai.com /
- „Google“ nestebimi testai ir kaip mes juos sušvelniname; https: // testavimas.googleblog.com /
- Kas yra regresijos testavimas? ; https: // testas.io / dienoraštis /
- 27 geriausi „Chrome“ plėtiniai kūrėjams 2020 m .; https: // www.lambdatest.com /
- 5 pagrindiniai programinės įrangos testavimo veiksmai, kuriuos turėtų atlikti kiekvienas inžinierius; https: // techbeacon.com /
Produktai programinės įrangos testavimui
Daugumą vertingų testavimo užduočių galima automatizuoti, todėl nenuostabu, kad naudoti įrankius ir produktus daugybei programinės įrangos kokybės užtikrinimo užduočių yra gera idėja. Žemiau pateiksime keletą svarbių ir labai vertingų programinės įrangos testavimo programinės įrangos įrankių, kuriuos galite ištirti ir sužinoti, ar jie gali padėti.
JUnit
Norėdami išbandyti „Java“ pagrįstą programinę įrangą, „JUnit“ pateikia išsamų „Java“ aplinkai draugiško kodo vieneto ir funkcinio testavimo rinkinį.
Selenas
Norėdami išbandyti žiniatinklio programas, „Selenium“ suteikia galimybę automatizuoti sąveiką su žiniatinklio naršyklėmis, įskaitant kelių naršyklių suderinamumo testavimą. Tai yra svarbiausia žiniatinklio bandymų automatizavimo bandymų infrastruktūra.
Agurkas
Į elgseną orientuoto testavimo sistema leidžia verslo vartotojams, produktų vadybininkams ir kūrėjams paaiškinti numatomą funkcionalumą natūralia kalba ir tada apibrėžti tą elgesį bandymo atvejais. Tai leidžia lengviau įskaityti bandomuosius atvejus ir aiškiai susieti planuojamas vartotojo funkcijas.
Išvalykite
Suraskite atminties nuotėkius ir atminties sugadinimus vykdymo metu, vykdydami savo programinę įrangą su įtaisyta „Purify Plus“ įranga, kuri stebi jūsų atminties naudojimą ir nurodo klaidas kode, kurių nėra lengva rasti be prietaisų.
Valgrindas
Atvirojo kodo įrankiai, kurie vykdys jūsų programinę įrangą ir leis su ja bendrauti, nurodydami kodavimo klaidų, tokių kaip atminties nutekėjimas ir sugadinimas, klaidų ataskaitą. Nereikia perkompiliuoti ar pridėti prietaisų į kompiliavimo procesą, nes „Valgrind“ turi galimybę dinamiškai suprasti jūsų kompiuterio kodą ir sklandžiai švirkšti instrumentus, kad rastų kodavimo klaidų ir padėtų tobulinti kodą.
Dangtis
Statinės analizės įrankis, kuris suras kodavimo klaidas jūsų programinėje įrangoje, net jei jūs dar nesudarėte ir nepaleidote kodo. „Coverity“ gali rasti saugumo spragų, kodavimo konvencijų pažeidimų, taip pat klaidų ir defektų, kurių jūsų kompiliatorius neras. Galima rasti negyvą kodą, neinicijuotus kintamuosius ir tūkstančius kitų defektų tipų. Prieš išleidžiant į gamybą, būtina išvalyti kodą atlikus statinę analizę.
JMeter
Atvirojo kodo sistema, skirta našumo testavimui, orientuota į „Java“ pagrįstus kūrėjus, taigi ir pavadinime „J“. Svetainės testavimas yra vienas iš pagrindinių „JMeter“ naudojimo atvejų, be duomenų bazių, pašto sistemų ir daugelio kitų serverio programų našumo testavimo.
Metasploit
Saugumo ir skverbties testavimui „Metasploit“ yra bendroji sistema, turinti tūkstančius funkcijų ir galimybių. Naudokite sąveikos konsolę, kad pasiektumėte iš anksto užkoduotus išnaudojimus ir bandykite patikrinti savo programos saugumą.
Programinės įrangos testavimo akademiniai tyrimai
- Šefildo universiteto testavimo tyrimų grupė
- Kentukio universiteto programinės įrangos patikrinimo ir patvirtinimo laboratorija
- Šiaurės Dakotos valstybinio universiteto programinės įrangos testavimo tyrimų grupė
- Sistemos testavimas „Intelligent Lab“; Čekijos technikos universitetas Prahoje
- NASA: Jon McBride programinės įrangos testavimas ir tyrimas (JSTAR)
- McMasterio universitetas; Programinės įrangos kokybės tyrimų laboratorija
- Ontarijo technikos universitetas; Programinės įrangos kokybės tyrimų laboratorija
- Teksaso universitetas @ Dalasas; STQA
Išvada
Programinės įrangos vaidmuo visuomenėje toliau auga, tuo pačiu metu pasaulio programinė įranga tampa vis sudėtingesnė. Kad pasaulis veiktų, turime turėti metodus ir strategijas, kaip išbandyti ir patvirtinti mūsų sukurtą programinę įrangą atliekant funkcijas, kurias ji ketina atlikti. Kiekvienai sudėtingai programinės įrangos sistemai turėtų būti parengta bandymų strategija ir bandymų planas, kad būtų galima toliau patvirtinti programinės įrangos funkcionalumą, nes jie ir toliau gerėja ir teikia savo funkcijas.
