Katsetootmine ja kvaliteedi tagamine

Kasu:

• Võimalus teha tehisintellektiga ühikuteste, servajuhtumeid ja katvuse lünkade analüüsi
• Võimalus printida testi ootusi spetsifikatsiooni, mitte koodi praeguse käitumise põhjal
• Võimalus testida, kas test tegelikult kaitseb vigade sisestamisega

Testide kirjutamine on üks väärtust tootvamaid ülesandeid, mida enamik arendajaid edasi lükkab. Hea testikomplekt on tõend, et kood töötab ootuspäraselt, ja päästerõngas tulevaste muudatuste jaoks. Probleem on selles, et testide kirjutamine on korduv ja aeganõudev – täpselt selline töö, kus AI paistab. Kuid sellel on konks: AI testib sageli koodi olemasolevat käitumist, mitte käitumist, mis see peaks olema. Selle erinevuse haldamine on selle üksuse põhiolemus.

Selles üksuses õpite ühikutestimist (testimine, mis testib funktsiooni üksinda, eraldiseisvalt), servajuhtude teste ja testandmete genereerimist tehisintellektiga; lünkade sulgemine testi katvuses; ja miks on AI-testide pimesi usaldamine ohtlik.

Testimise kaks poolt: käitumise parandamine vs. kontrollimine

Test võib teenida kahte erinevat eesmärki. Esimene on kontrollimine: see testib, kas kood on õige, kas see vastab spetsifikatsioonile. Teine on regressioonikaitse: see külmutab täna koodi käitumise, nii et kui keegi seda homme kogemata muudab, läheb test katki ja annab sellest teada.

AI on viimases väga hea; See vaatab koodi ja genereerib juhtumeid, mis testivad "mida see praegu teeb". Kuid kui kood on algusest peale vale, võib AI selle vale käitumise "õigeks" kinnitada. Seega peate üle vaatama iga AI tehtud testi väite: "Kood tagastab 42 ja test ootab 42" ei tähenda, et 42 on õige vastus.

Ettevaatust: kui AI läbib testi, ei tähenda see, et kood "töötab"; see tähendab lihtsalt "see käitub nii, nagu AI eeldab". Otsustate, kas ootus on õige või mitte, vaadates spetsifikatsiooni.

Samm-sammult: tehisintellektiga tugevate testide kirjutamine

1. Andke spetsifikatsioon, mitte ainult kood. Kui lisate teabe "See funktsioon peaks seda tegema", saab AI kirjutada õige ootuse; See testib praegust käitumist, kui sisestate lihtsalt koodi.
2. Küsi servi. Tühi, null, null, negatiivne, liiga suur, halb vorming, samaaegsus – väida selgelt õnnelikust teest.
3. Määrake testimise raamistik ja stiil. "kasuta pytesti", "Arrange-Act-Assert muster", "las iga test testib ühte asja" jne.
4. Kontrolli ootusi (väide). Võrrelge spetsifikatsiooniga, mida iga väide õiget väärtust kontrollib.
5. Sulgege lüngad ulatuses. Esitage olemasolevad testid ja küsige "milliseid harusid ja juhtumeid pole testitud?" pane sind küsima; seejärel kontrollige tehtud täiendavaid teste.

Kolm miniümbrist

Juhtum 1 – katvus 52% kuni 85%. Ühe teenindusmooduli testikatvus oli 52%. Meeskond edastas olemasolevad testid tehisintellektile, lasi sellel loetleda testimata harud ja luua nende jaoks testid. Inimeste läbivaatamisega suurenes katvus 85%-ni; Selle käigus avastas AI veaharus tegeliku vea (tee, mis tagastas vale veakoodi), mida polnud kunagi varem testitud.

Juhtum 2 – valeootuse fikseerimise lõks. Raha ümardamise funktsioon oli tegelikult vale; Selle asemel, et ümardada 2,675-ks 2,67-ks, ümardati 2,68 asemel 2,67. Tehisintellekt vaatas koodi ja kirjutas kinnituse round_money(2.675) == 2.67 – külmutas vea kui "tõene". Kui arendaja luges spetsifikatsiooni, parandas ta ootust ja tabas tegeliku vea. Erinevust tegi reegli, mitte koodi testimine.

Juhtum 3 – ääreseisundi plahvatus. Kui küsite AI-lt kuupäevavahemiku funktsiooni jaoks ainult "servajuhtumeid"; See andis 8 juhtumit, näiteks algus=lõpp, vastupidine intervall, liigaasta 29. veebruar, erinevad ajavööndid ja nullintervall. Kaks neist (tagurpidi vahekaugus ja liigaasta) põhjustasid tegelikult vea. Nende juhtumite käsitsi käsitlemine jäetakse sageli vahele; Tehisintellektist sai siin „äärmusliku ajurünnaku“ partner.

Neli kopeeritavat malli

Spetsifikatsioonipõhine testi genereerimine:

Roll: arendaja, kes kirjutab teste. Raamistik: {{pytest/JUnit/Jest...}}. Mida funktsioon PEAKS TEGEMA (spetsifikatsioon): {{reegel}}Kirjutage testid järgmise funktsiooni jaoks. Kirjuta ootused vastavalt spetsifikatsioonile, MITTE koodi hetkeväljundile. Õnnelik tee + lisa vähemalt 4 servajuhtumit. Laske igal testil testida ühte asja, kasutage kirjeldavat nime. {{funktsioon}}

Edge case’i ajurünnak:

Loetlege serva-/tõrkejuhud, mida tuleks selle funktsiooni testimisel proovida (null, null, katkestuspunktid, halb vorming, samaaegsus, väline viga). Igal juhul: sisend, eeldatav käitumine. ÄRGE veel koodi kirjutage, vaid loetlege.{{function}}

Katvuse lõhe analüüs:

Allpool on toodud funktsioonid ja saadaolevad testid. Milliseid harusid, tingimusi ja juhtumeid pole testitud? Loetlege puudused ja kirjutage uued testid ainult puuduste kohta. Ärge korrake olemasolevaid. Funktsioon:{{function}}Testid:{{olemasolevad_testid}}

Testiandmete / näidisobjekti genereerimine:

Looge {{function/service}} testide jaoks realistlikud testiandmed: kehtivad näidised, ääriste näidised ja kehtetud näidised eraldi. Soovitage välise sõltuvuse {{X}} jaoks lihtsat näidiskäitumist. Tõeliste konfidentsiaalsete andmete/PII kasutamine; Looge võltsandmeid.

Nõrk viip / Tugev viip

Nõrk: "Kirjutage selle funktsiooni test."

Tugev: "koos pytestiga. Funktsioon apply_discount(kokku, protsenti) — reegel: allahindlus peab olema 0%–30%, piiridest väljas peaks viskama ValueError, tulemus tuleks ümardada 2 kümnendkohani. Kirjutage ootused selle REEGLI järgi (mitte koodi järgi). Õnnelik tee + need servajuhtumid: 0%, 30%, 31% (viga.])

Ta annab tugeva vabastamise reegli ja ütleb "kirjutage ootus reegli, mitte koodi järgi"; See üksainus lause sulgeb AI väärkäitumise parandamise lõksu.

Testi tüüp

AI panus

inimese kontroll

Head teeüksuse testimist

kiire luustik

Kas ootus on õige?

Ääreümbrised

Ulatuslik ajurünnak

Likvideerige ebaoluline

Ulatuse lünkade täitmine

Leiab vahele jäetud oksad

Kinnitage tähtsust

Katseandmed/pilt

Toodab realistlikku näidist

Ilma isikuandmeteta, realismi kontroll

Testid juhivad kvaliteeti, mitte ei taga seda

Testi kõrge katvus annab kindlustunde, kuid võib olla ka eksitav: 100-protsendiline katvus tähendab, et "iga rida on läbi viidud", mitte "iga rida on õige". AI-ga on katvust lihtne suurendada; Tõeline väärtus on mõtestatud ootuste kirjutamises. Testi väärtus on selle võime murda ja hoiatada teid, kui kood on katki. Seetõttu põhinevad AI-ga loodud testid küsimusel "kas kood tõesti puruneb, kui see muutub?" Testige seda küsimusega; Tahtlik joone katkestamine ja testi katkemise nägemine (mutatsiooniidee) on tõestuseks, et test toimis.

Näpunäide. Et näha, kas tehisintellekti kirjutatud test töötab, looge koodis väike viga (nt muutke + märgiks -) ja vaadake, kas test katkeb. Kui see ei purune, ei kaitse see test teid.

Levinud vead

• Testi küsimine ilma reeglit andmata. Mudel külmutab praeguse käitumise; parandab vea kui "tõene".
• Ootuste aktsepteerimine neid lugemata. Testimine on eksitav, kui te ei kontrolli, kas väited kontrollivad õiget väärtust.
• Lihtsalt proovin õnnelikku teed. Tõelised vead elavad äärel; Küsige selgesõnaliselt servajuhtumeid.
• Ulatuse eksitamine eesmärgiga. Kõrge protsent ei garanteeri õiget käitumist.
• Reaalsete/varjatud andmete muutmine testandmeteks. Kliendiandmed või saladused ei tohiks siseneda testimisse ega salvestusruumi; Looge sünteetilisi andmeid.

Kokkuvõttes

AI eemaldab suure osa testide kirjutamisel tekkivast korduvast koormusest: see loob kiireid luukere, suuri äärejuhtumite loendeid ja katvuse lünkade analüüse. Kuid kõige kriitilisem punkt on ootused: AI kipub testima koodi praegust käitumist, samas kui testimine peaks olema kirjutatud vastavalt spetsifikatsioonile. Esitage reegel, kontrollige ootusi, jõustage äärmuslikke juhtumeid ja testige, kas testid tõesti kaitsevad vea süstimisega. Testi katvus on tööriist, mitte eesmärk.

Rakenduse ülesanne

Valige funktsioon ja printige esmalt AI-le test, andes lihtsalt selle koodi; Pange tähele ootusi. Seejärel printige test uuesti, andes sama funktsiooni spetsifikatsiooni (nõutav käitumine). Võrrelge kahe testikomplekti ootusi: kas need erinevad, kumb paljastab tõelise vea? Lõpuks kontrollige, kas üks loodud testidest töötas, lisades koodi tahtliku vea ja nägema testi katkemist.

kontrollnimekiri

• [ ] Ma eristan, kas test on käitumise parandamiseks või kontrollimiseks.
• [ ] Kui taotlen testi, annan ma reegli (spetsifikatsiooni), mis peaks paigas olema, mitte koodi.
• [ ] Võrdlen iga genereeritud väidet spetsifikatsiooniga.
• [ ] Nõuan selgesõnaliselt serva- ja tõrkejuhtumeid.
• [ ] Ma vaatan protsentuaalset katvust kui vahendit, mitte eesmärki.
• [ ] Testin, kas test tegelikult kaitseb vigade sisestamisega.