Izmantojiet testus kā pierādījumus

Sāciet ar prasību

Testi ir pierādījumi konkrētiem apgalvojumiem. Veiksmīga testu izpilde nepierāda visas programmatūras īpašības. Pirms testu pieprasīšanas nosakiet būtisko darbību un defektu, kas katrai pārbaudei jāatklāj.

Izdomātam organizācijas eksportam galvenā prasība ir datu izolācija. Organizācijas A lietotājs nedrīkst saņemt organizācijas B ierakstus. Tests, kas pārbauda tikai veiksmīgu lejupielādi, šo prasību nepierāda.

Lūdziet aģentam izskaidrot saikni starp prasību un testa pārbaudes nosacījumu. Tas atvieglo trūkstošu gadījumu atklāšanu, pirms testu kopa kļuvusi liela.

Izvēlieties piemērotu testa tvērumu

Vienībtests var ātri pārbaudīt nelielu pārveidojumu. Integrācijas tests var pārbaudīt komponentu sadarbību. Pilna procesa tests var pārbaudīt būtisku lietotāja darbību secību izvietotā vai tai atbilstošā lietotnē.

Izmantojiet šaurāko tvērumu, kas sniedz nepieciešamos pierādījumus. Formatētājam nevajag pilnu pārlūka testu katrai ievadei. Autorizācijas robežai var vajadzēt īstu maršrutu un datu piekļuves ceļu. Kritiskai pārlūka mijiedarbībai vajag pierādījumus par atveidoto saskarni.

Neviena fiksēta testu veidu proporcija neder visām sistēmām. Izvēlieties pēc kļūmes, kas jāatklāj, un pārbaudes uzturēšanas izmaksām.

Izvairieties no kopīga nepareiza pieņēmuma

Aģents var uzrakstīt īstenojumu un testus pēc viena un tā paša pārpratuma. Abi var sakrist, lai gan prasība paliek neizpildīta.

Pieņemsim, ka īstenojums filtrē ierakstus pēc pieprasījumā sniegtā organizācijas ID. Tests izmanto vienu un to pašu ID pieslēgtajam lietotājam un pieprasījumam. Tas izdodas. Trūkst gadījuma, kurā lietotājs pieprasa citas organizācijas ID.

Pievienojiet šo gadījumu, izmantojot faktisko uzticamo identitāti un autorizācijas ceļu. Imitācija, kas vienmēr atgriež „atļauts“, nevar pierādīt nomnieku izolāciju. Tā pierāda tikai darbību pēc veiksmīgas autorizācijas.

Pārbaudiet, vai tests spēj neizdoties

Zināmam defektam palaidiet jauno regresijas testu pret kļūdaino versiju izolētā zarā. Apstipriniet, ka tas neizdodas paredzētā iemesla dēļ. Tad piemērojiet labojumu un palaidiet to vēlreiz.

Tests, kas neizdodas, jo nevar ielādēt testa datus, vēl nav pierādījums par biznesa darbību. Pārbaudiet kļūmi, ne tikai izejas kodu.

Plašākām izmaiņām mutāciju testēšana var palīdzēt novērtēt, vai izvēlētas koda izmaiņas izraisa testu neveiksmes. Tai ir izmaksas, un tā neaizstāj prasību pārskatīšanu. Izmantojiet to tur, kur papildu pierādījumi pamato būtisku lēmumu.

Saglabājiet pierādījumu saikni ar izmaiņu

Veiciet attiecīgās pārbaudes galīgajai versijai. Reģistrējiet izlaistās pārbaudes un to iemeslus. Agrāka commit rezultāts pēc pārskatīšanas labojuma var vairs neattiekties uz izmaiņu.

Saglabājiet testus saprotamus. Dodiet priekšroku skaidrai sagatavošanai un pārbaudes nosacījumam, nevis lielai palīgfunkcijai, kas slēpj būtisko nosacījumu. Noņemiet liekas pārbaudes, ja tās palielina uzturēšanas izmaksas, neatklājot citu kļūmi.

Pārskatītājam jāspēj pateikt, ko testi pierāda un kas paliek neskaidrs. Šis skaidrojums ir noderīgāks par lielu testu skaitu.