Ieguvumi:
- Spēja veikt vienību testēšanu, malu gadījumus un pārklājuma atstarpes analīzi, izmantojot AI
- Iespēja drukāt testa cerības, pamatojoties uz specifikāciju, nevis pašreizējo koda uzvedību
- Spēja pārbaudīt, vai tests patiešām aizsargā, ievadot kļūdas
Testu rakstīšana ir viens no visvairāk vērtību radošajiem uzdevumiem, ko lielākā daļa izstrādātāju atliek. Labs testu komplekts ir pierādījums tam, ka kods darbojas, kā paredzēts, un glābšanas riņķis turpmākajām izmaiņām. Problēma ir tā, ka testu rakstīšana ir atkārtota un laikietilpīga — tieši tāds darbs, kurā AI spīd. Taču ir kāds āķis: AI bieži pārbauda esošo koda uzvedību, nevis uzvedību, kādai tai vajadzētu būt. Šīs atšķirības pārvaldīšana ir šīs vienības būtība.
Šajā nodaļā jūs apgūsit vienību testēšanu (testēšanu, kas pārbauda funkciju atsevišķi, atsevišķi), malas gadījumu testus un testa datu ģenerēšanu ar AI; novērst nepilnības testa pārklājumā; un kāpēc akli uzticēties AI testiem ir bīstami.
Testēšanas divas puses: uzvedības labošana salīdzinājumā ar pārbaudi
Pārbaude var kalpot diviem dažādiem mērķiem. Pirmā ir pārbaude: tā pārbauda, vai kods ir pareizs, vai tas atbilst specifikācijai. Otrais ir regresijas aizsardzība: tā šodien iesaldē koda uzvedību, tāpēc, ja kāds to nejauši mainīs rīt, tests pārtrauks un paziņos.
AI ir ļoti labs pēdējā; Tas aplūko kodu un ģenerē gadījumus, kas pārbauda, "ko tas pašlaik dara". Bet, ja kods ir nepareizs jau no paša sākuma, AI var norādīt šo nepareizo uzvedību kā “pareizu”. Tāpēc jums ir jāpārskata apgalvojums par katru AI sagatavoto testu: "Kods atgriež 42 un tests sagaida 42" nenozīmē, ka 42 ir pareizā atbilde.
Uzmanību: ja AI iztur pārbaudi, tas nenozīmē, ka kods "darbojas"; tas vienkārši nozīmē "tas uzvedas tā, kā AI sagaida". Jūs izlemjat, vai cerības ir pareizas vai nē, apskatot specifikāciju.
Soli pa solim: stingru testu rakstīšana ar AI
- Norādiet specifikāciju, ne tikai kodu. Ja pievienojat informāciju "Šai funkcijai tas jādara", AI var ierakstīt pareizo cerību; Tas pārbaudīs pašreizējo darbību, ja jūs vienkārši ievadīsit kodu.
- Jautājiet par malām. Tukšs, nulle, nulle, negatīvs, pārāk liels, slikts formāts, vienlaicīgums — nepārprotami apgalvojiet, ka esat laimīgs.
- Norādiet testēšanas sistēmu un stilu. "izmantot pytest", "Arrange-Act-Assert modeli", "ļaujiet katram testam pārbaudīt vienu lietu" utt.
- Pārbaudiet cerības (apgalvojumu). Salīdziniet ar specifikāciju, kurā katrs apgalvojums pārbauda pareizo vērtību.
- Novērsiet darbības jomas nepilnības. Sniedziet esošos testus un jautājiet "kuras filiāles un gadījumi nav pārbaudīti?" likt tev jautāt; pēc tam pārbaudiet veiktos papildu testus.
Trīs mini futrāļi
1. gadījums — segums no 52% līdz 85%. Viena servisa moduļa testu pārklājums bija 52%. Komanda ievadīja AI esošos testus, lika tai uzskaitīt nepārbaudītās filiāles un ģenerēt tiem testus. Pārskatot cilvēkus, pārklājums palielinājās līdz 85%; Šajā procesā AI atklāja faktisku kļūdu (ceļu, kas atgrieza nepareizu kļūdas kodu) kļūdu atzarā, kas nekad iepriekš nebija pārbaudīta.
2. gadījums — viltus gaidu fiksācijas slazds. Naudas noapaļošanas funkcija patiesībā bija nepareiza; Tā vietā, lai noapaļotu 2,675 uz 2,67, tā noapaļoja 2,67, nevis 2,68. AI apskatīja kodu un uzrakstīja apgalvojumu round_money(2.675) == 2.67 — kļūdas iesaldēšana kā “true”. Kad izstrādātājs izlasīja specifikāciju, viņš laboja cerības un noķēra īsto kļūdu. Noteikuma, nevis koda pārbaude radīja atšķirību.
3. gadījums — malas stāvokļa eksplozija. Pieprasot AI datu diapazona funkcijai tikai “malas gadījumus”; Tas radīja 8 gadījumus, piemēram, sākums = beigas, apgrieztais intervāls, garais gads 29. februāris, dažādas laika zonas un nulles intervāls. Divi no tiem (apgrieztā atstarpe un garais gads) faktiski izraisīja kļūdu. Šo gadījumu manuāla izskatīšana bieži tiek izlaista; AI šeit kļuva par "prāta vētras" partneri.
Četras kopējamas veidnes
Uz specifikācijām balstīta testa ģenerēšana:
Loma: izstrādātājs, kurš raksta testus. Ietvars: {{pytest/JUnit/Jest...}}. Kā funkcijai JĀDARA (specifikācija): {{noteikums}}Uzrakstiet šādas funkcijas testus. Uzrakstiet cerības saskaņā ar specifikāciju, NEVIS pašreizējo koda izvadi. Laimīgs ceļš + pievienojiet vismaz 4 malas gadījumus. Ļaujiet katram testam pārbaudīt vienu lietu, izmantojiet aprakstošu nosaukumu. {{funkcija}}
Edge lietas prāta vētra:
Uzskaitiet malas/kļūmes gadījumus, kas jāizmēģina šīs funkcijas pārbaudē (nulle, null, pārtraukuma punkti, slikts formāts, vienlaicīgums, ārējā kļūda). Katram gadījumam: ievade, paredzamā darbība. Vēl NERAKSTI kodu, vienkārši uzskaiti.{{funkcija}}
Pārklājuma atšķirības analīze:
Tālāk ir norādītas funkcijas un pieejamie testi. Kuras filiāles, nosacījumi un gadījumi nav pārbaudīti? Uzskaitiet trūkumus un rakstiet jaunus testus tikai par trūkumiem. Neatkārtojiet esošos. Funkcija:{{function}}Pārbaudes:{{existing_tests}}
Testa datu / imitācijas objekta ģenerēšana:
Ģenerējiet reālistiskus testa datus {{function/service}} testiem: derīgi paraugi, apmales paraugi un nederīgi paraugi atsevišķi. Iesakiet ārējai atkarībai {{X}} vienkāršu viltotu darbību. Izmantojot patiesi konfidenciālus datus/PII; Ģenerējiet viltus datus.
Vāja uzvedne / spēcīga uzvedne
Vāji: "Uzrakstiet šīs funkcijas testu."
Strong: "ar pytest. Funkcija apply_discount(kopā, procenti) — noteikums: atlaidei ir jābūt 0%–30%, ārpus robežām jāmet ValueError, rezultāts ir jānoapaļo līdz 2 cipariem aiz komata. Uzrakstiet cerības pēc šī NOTEIKUMA (nevis pēc koda). Laimīgs ceļš + šie malas gadījumi: 0%, 30%, 31% (kļūda.), negatīvs, koda kopskaits"=0.
Viņš sniedz stingro atbrīvošanas noteikumu un saka "rakstiet cerības saskaņā ar noteikumu, nevis kodu"; Šis viens teikums aizver slazdu mākslīgā intelekta labošanai.
Pārbaudes veids
AI ieguldījums
cilvēka kontrole
Laimīgu ceļa vienības testēšanu
ātrs skelets
Vai cerības ir pareizas?
Malu futrāļi
Plaša prāta vētra
Likvidējiet nebūtisko
Darbības jomas spraugu aizpildīšana
Atrod izlaistos zarus
Apstipriniet nozīmi
Pārbaudes dati/izspēles
Izgatavo reālistisku paraugu
Nav PII, reālisma kontrole
Testi pārvalda kvalitāti, nevis to garantē
Augsts testa pārklājums sniedz pārliecību, taču tas var būt arī maldinošs: 100 procentu pārklājums nozīmē, ka "ikviena rinda ir izpildīta", nevis "katra rinda ir pareiza". Ir viegli palielināt pārklājumu ar AI; Patiesā vērtība ir jēgpilnu cerību rakstīšana. Pārbaudes vērtība ir tā spēja sabojāt un brīdināt jūs, kad kods ir bojāts. Tāpēc AI ģenerētie testi ir balstīti uz jautājumu "vai kods patiešām sabojājas, kad tas mainās?" Pārbaudi to ar jautājumu; Apzināta līnijas pārkāpšana un testa pārtraukuma (mutācijas ideja) redzēšana ir pierādījums tam, ka tests darbojās.
Padoms. Lai redzētu, vai AI rakstītais tests darbojas, izveidojiet nelielu kļūdu kodā (piem., mainiet + uz -) un pārbaudiet, vai tests nedarbojas. Ja tas nesadalās, šis tests jūs nepasargā.
Biežas kļūdas
- Prasa testu, nedodot noteikumu. Modelis iesaldē pašreizējo uzvedību; izlabo kļūdu kā "patiesu".
- Pieņemt cerības, tās neizlasot. Pārbaude ir maldinoša, ja nepārbaudāt, vai apgalvojumi pārbauda pareizo vērtību.
- Vienkārši pārbaudu laimīgo ceļu. Reālas kļūdas dzīvo uz robežas; Lūdziet skaidras lietas.
- Sajaucot darbības jomu ar mērķi. Augsts procents negarantē pareizu uzvedību.
- Padarīt reālus/slēptus datus par testa datiem. Klienta dati vai noslēpumi nedrīkst iekļūt testēšanā un glabāšanā; Ģenerējiet sintētiskos datus.
Rezumējot
AI noņem lielu daļu atkārtotā sloga, ko rada testu rakstīšana: tas rada ātrus skeletus, lielus malu gadījumu sarakstus un pārklājuma trūkumu analīzi. Bet viskritiskākais punkts ir cerības: AI mēdz pārbaudīt pašreizējo koda uzvedību, turpretim testēšana ir jāraksta saskaņā ar specifikāciju. Sniedziet noteikumu, pārbaudiet cerības, ieviesiet malas gadījumus un pārbaudiet, vai testi patiešām aizsargā, ievadot kļūdu. Testa pārklājums ir rīks, nevis mērķis.
Lietojumprogrammas uzdevums
Izvēlieties funkciju un vispirms izdrukājiet AI testu, vienkārši norādot tā kodu; Ievērojiet cerības. Pēc tam vēlreiz izdrukājiet testu, norādot specifikāciju (nepieciešamo darbību) tai pašai funkcijai. Salīdziniet abu testu komplektu cerības: vai ir kādas atšķirības, un kurā no tām tiek atklāta patiesa kļūda? Visbeidzot pārbaudiet, vai viens no ģenerētajiem testiem darbojās, kodam pievienojot tīšu kļūdu un redzot pārbaudes pārtraukumu.
kontrolsaraksts
- [ ] Es nošķiru, vai pārbaude ir paredzēta uzvedības labošanai vai pārbaudei.
- [ ] Kad es pieprasu testu, es dodu noteikumu (specifikāciju), kam jābūt vietā, nevis kodu.
- [ ] Es salīdzinu katru ģenerēto apgalvojumu ar specifikāciju.
- [ ] Es skaidri pieprasu malu un kļūmju gadījumus.
- [ ] Es uzskatu procentuālo segumu kā līdzekli, nevis mērķi.
- [ ] Es pārbaudu, vai tests patiešām aizsargā, ievadot kļūdas.