Šī apmācība iepazīstina ar septiņiem programmatūras testēšanas pamatprincipiem, kas jāzina katram programmatūras testētājam un kvalitātes nodrošināšanas profesionālim.
7 programmatūras testēšanas principi
- Testēšana parāda defektu klātbūtni
- Pilnīga pārbaude nav iespējama
- Agrīna pārbaude
- Defektu grupēšana
- Pesticīdu paradokss
- Testēšana ir atkarīga no konteksta
- Kļūdu neesamība
Apgūsim testēšanas principus, izmantojot šo video piemēru-
Noklikšķiniet šeit, ja videoklips nav pieejams
Priekšvēsture
Ir svarīgi, lai jūs sasniegtu optimālos testa rezultātus, vienlaikus veicot programmatūras testēšanu, neatkāpjoties no mērķa. Bet kā jūs nosakāt, ka ievērojat pareizo testēšanas stratēģiju? Lai to izdarītu, jums jāievēro daži pārbaudes principi. Šeit ir septiņi kopējie testēšanas principi, kas tiek plaši izmantoti programmatūras nozarē.
Lai to saprastu, apsveriet scenāriju, kurā failu pārvietojat no mapes A uz mapi B.
Padomājiet par visiem iespējamiem veidiem, kā to pārbaudīt.
Papildus parastajiem scenārijiem varat pārbaudīt arī šādus nosacījumus
- Mēģina pārvietot failu, kad tas ir atvērts
- Jums nav drošības tiesību ielīmēt failu mapē B
- Mape B atrodas koplietojamā diskā, un atmiņas ietilpība ir pilna.
- Mapē B jau ir fails ar tādu pašu nosaukumu, patiesībā saraksts ir bezgalīgs
- Vai arī pieņemsim, ka jums ir 15 testējami ievades lauki, kuriem katram ir 5 iespējamās vērtības, pārbaudāmo kombināciju skaits būtu 5 15
Ja pārbaudītu visas iespējamās kombinācijas, EXECUTION LAIKS UN IZMAKSAS pieaugs eksponenciāli. Mums ir nepieciešami noteikti principi un stratēģijas, lai optimizētu testēšanas centienus
Šeit ir 7 principi:
1) Pilnīga pārbaude nav iespējama
Jā! Pilnīga pārbaude nav iespējama. Tā vietā mums ir nepieciešams optimāls testēšanas apjoms, pamatojoties uz lietojumprogrammas riska novērtējumu.
Miljonu dolāru jautājums ir, kā jūs varat noteikt šo risku?
Lai atbildētu uz to, izdarīsim vingrinājumu
Jūsuprāt, kura darbība, visticamāk, izraisīs jūsu operētājsistēmas kļūmi?
Esmu pārliecināts, ka lielākā daļa no jums būtu uzminējuši, vienlaikus atverot 10 dažādas lietojumprogrammas.
Tātad, ja jūs testētu šo operētājsistēmu, jūs saprastu, ka defekti, visticamāk, tiek atrasti daudzuzdevumu darbībā un tie ir rūpīgi jāpārbauda, kas mūs noved pie mūsu nākamā principa Defektu kopēšana
2) Defektu kopu veidošana
Defektu kopa, kas norāda, ka neliels moduļu skaits satur lielāko daļu atklāto defektu. Tā ir Pareto principa piemērošana programmatūras testēšanai: aptuveni 80% problēmu ir sastopamas 20% moduļu.
Pēc pieredzes jūs varat identificēt šādus riskantus moduļus. Bet šai pieejai ir savas problēmas
Ja tos pašus testus atkārto vēl un vēl, galu galā tie paši testa gadījumi vairs neatradīs jaunas kļūdas.
3) Pesticīdu paradokss
Atkārtota viena un tā paša pesticīdu maisījuma izmantošana kukaiņu izskaušanai audzēšanas laikā laika gaitā novedīs pie kukaiņu izturības pret pesticīdiem, tādējādi pesticīdu neefektīva uz kukaiņiem. Tas pats attiecas uz programmatūras testēšanu. Ja tiek veikts viens un tas pats atkārtoto testu komplekts, metode būs nederīga jaunu defektu atklāšanai.
Lai to pārvarētu, testa gadījumi regulāri jāpārskata un jāpārskata, pievienojot jaunus un dažādus testa gadījumus, lai palīdzētu atrast vairāk defektu.
Testētāji nevar būt vienkārši atkarīgi no esošajām testēšanas metodēm. Viņam nepārtraukti jāuzmanās, lai uzlabotu esošās metodes, lai testēšana būtu efektīvāka. Bet pat pēc visu šo sviedru un smagā darba testēšanas laikā jūs nekad nevarat apgalvot, ka jūsu produktam nav kļūdu. Lai brauktu mājās, apskatīsim šo video par Windows 98 publisko palaišanu
Jūs domājat, ka tāds uzņēmums kā MICROSOFT nebūtu rūpīgi pārbaudījis savu operētājsistēmu un riskētu ar savu reputāciju, lai tikai redzētu, kā viņu operētājsistēma sabrūk publiskās palaišanas laikā!
4) Testēšana parāda defektu klātbūtni
Tādējādi testēšanas princips nosaka, ka - testēšana runā par defektu klātbūtni un nerunā par defektu neesamību. Ti programmatūras testēšana samazina varbūtību, ka programmatūrā paliek neatklāti defekti, taču pat tad, ja defekti netiek atrasti, tas nav pareizības pierādījums.
Bet ko darīt, ja jūs strādājat īpaši smagi, ievērojot visus piesardzības pasākumus un padarot savu programmatūras produktu par 99% bez kļūdām. Programmatūra neatbilst klientu vajadzībām un prasībām.
Tas mūs noved pie mūsu nākamā principa, kas to apgalvo - Kļūdu neesamība
5) Kļūdas neesamība - maldība
Iespējams, ka programmatūra, kurā nav kļūdu, ir 99%, joprojām nav izmantojama. Tas var notikt, ja sistēmā tiek rūpīgi pārbaudītas nepareizas prasības. Programmatūras testēšana nav tikai defektu atrašana, bet arī pārbaude, vai programmatūra atbilst biznesa vajadzībām. Kļūdu neesamība ir kļūda, ti, defektu atrašana un novēršana nepalīdz, ja sistēmas uzbūve nav izmantojama un neatbilst lietotāja vajadzībām un prasībām.
Lai atrisinātu šo problēmu, nākamais testēšanas princips nosaka, ka agrīnā testēšana
6) Agrīna testēšana
Agrīna testēšana - testēšana jāsāk pēc iespējas agrāk programmatūras izstrādes dzīves ciklā. Lai visi prasību vai projektēšanas posma defekti tiktu novērsti agrīnā stadijā. Testēšanas sākumposmā ir daudz lētāk novērst defektu. Bet cik agri vajadzētu sākt testēšanu? Kļūdu ieteicams sākt meklēt brīdī, kad tiek noteiktas prasības. Vairāk par šo principu vēlāk apmācības apmācībā.
7) Testēšana ir atkarīga no konteksta
Testēšana ir atkarīga no konteksta, kas būtībā nozīmē, ka veids, kā pārbaudāt e-komercijas vietni, atšķirsies no tā, kā pārbaudāt komerciālu lietojumprogrammu. Visas izstrādātās programmatūras nav identiskas. Jūs varat izmantot atšķirīgu pieeju, metodiku, paņēmienus un testēšanas veidus atkarībā no lietojumprogrammas veida. Piemēram, jebkura mazumtirdzniecības veikala POS sistēma atšķiras no bankomāta testēšanas.
Mīts: "Principi ir tikai atsaucei. Es tos nelietošu praksē."
Tas ir tik ļoti nepatiesi. Pārbaudes principi palīdzēs jums izveidot efektīvu testēšanas stratēģiju un sagatavot kļūdu uztveršanas pārbaudes gadījumus.
Bet testēšanas principu apguve ir gluži kā iemācīšanās braukt pirmo reizi.
Sākotnēji, kamēr jūs iemācāties braukt, jūs pievēršat uzmanību katram, piemēram, pārnesumu pārslēgšanai, ātrumam, sajūga vadīšanai utt. Bet, ņemot vērā pieredzi, jūs vienkārši koncentrējaties uz braukšanu, pārējais notiek dabiski. Tāds, ka jūs pat sarunājaties ar citiem pasažieriem automašīnā.
Tas pats attiecas uz testēšanas principiem. Pieredzējuši testētāji ir internalizējuši šos principus tādā līmenī, lai tos pielietotu pat nedomājot. Tāpēc mīts, ka principi netiek izmantoti praksē, vienkārši nav patiess.