Testpõlvkond tehisintellektiga: ühiku-, liidese- ja automatiseerimistestid

Kasu:

• Võimalus toota tehisintellektiga ühiku-, integratsiooni- ja kasutajaliidese teste vastavalt testimispüramiidile ning katta nii piir- ja veaolukordi kui ka õnnelikke stsenaariume
• Võimalus välja rookida tühjad/kasutud testid ja ülepaisutatud katvus, kontrollides, kas iga loodud test tegelikult kinnitab käitumist
• Tagada, et test tabab vea ja takistab sellel viga parandamast, öeldes tehisintellektile, mida kood peaks tegema

Koodi kirjutamine on pool tööd; Koodi korrektse toimimise tõestamine on teine ​​pool. Mobiilirakendused puutuvad kokku sadade erinevate seadmete, ekraanisuuruste, operatsioonisüsteemi versioonide ja kasutajate käitumisega. Neid kõiki on võimatu käsitsi testida; Seetõttu on automaattestimine (koodi testimise kood – testimine, mis töötab ilma inimese klõpsamiseta) mobiilse kvaliteedi selgroog. AI on testide kirjutamisel uskumatult tõhus, sest testide kirjutamine on täpselt selline mustritöö, mis talle meeldib: konkreetse käitumise kinnitamine konkreetsete sisendite jaoks. Selles üksuses õpime, kuidas kiirendada üksuste testimist, liideste testimist ja automatiseerimist tehisintellektiga, kuid tagada testi kvaliteet läbi inimsilma.

Testimispüramiid: mida ja kui palju testida

Tervislik testimisstrateegia meenutab püramiidi. Alus sisaldab suurt hulka ühikuteste (kiirtestimine, mis testib üksikut funktsiooni või klassi eraldi); need on kiired ja odavad. Keskel on vähem integratsiooni testimist (mitme osa koos toimimise testimine). Ülaosas on minimaalne kasutajaliidese / otsast lõpuni testimine (testimine toimub ekraanil klõpsates, nagu kasutaja seda teeb); need on realistlikud, kuid aeglased ja haprad. AI aitab igas kihis, kuid kõige suurem väärtus on aluses: äriloogika ühikutestide kiire koostamine.

Testi tüüp

Ulatus

kiirust

AI tõhusus

ühiku testimine

Üks funktsioon/klass

väga kiire

väga kõrge

integratsiooni

vahekiht

keskmine

kõrge

UI / otsast lõpuni

Kogu ekraani voog

aeglane

Keskmine (habras)

Näpunäide. Kui käsite tehisintellektil "selle funktsiooni jaoks testid genereerida", küsige selgesõnaliselt servajuhtumeid: tühi sisend, null, negatiivne arv, väga suur väärtus, võrguviga. AI loob õnneliku tee kergesti; Tõelised vead peituvad piirides ja hüppavad välja, kui te neid seal ei taha.

AI-ga testide kirjutamise sammud

1. Määratlege testitav käitumine. "See funktsioon peaks andma selle väljundi sellele sisendile."
2. Täpsustage raamistik. JUnit + MockK Androidis, XCTest iOS-is, Espresso (Android) või XCUITest (iOS) kasutajaliidese jaoks.
3. Küsi piirolekuid. Õnnelik stsenaarium + viga + katkestuspunktid.
4. Pildiobjektide haldamine. Testimiseks emuleeritakse väliseid sõltuvusi, nagu võrk ja andmebaas (tegeliku teenuse asemel imitatsioon – kontrollitud pilk).
5. Käivitage test ja kontrollige. Kas test läbib, kas see kinnitab midagi tõeliselt tähenduslikku?

Viies samm on kriitiline. AI toodab mõnikord kasutuid teste, mis "alati läbivad"; näiteks test, mis ei kontrolli midagi või kontrollib enda võltsandmeid. Testi sooritamine ja väärtuslik test on erinevad asjad.

Ettevaatust. See, et AI suudab toota, ei tähenda, et test oleks õige. Mõnikord aktsepteerib AI koodi praegust (võib-olla vigast) käitumist "õigeks" ja kirjutab vastavalt testid. Selline testimine pigem parandab vea kui püüab seda. Saate määrata, mida test ootab; Öelge tehisintellektile, mida ta peaks tegema, mitte seda, mida kood teeb.

Testi katvuse mõõt ja ekslikkus

Testi katvus (mitu protsenti koodist testid käivitavad) on kasulik, kuid eksitav mõõdik. 90% katvus näitab, et 90% koodist on täidetud; kuid pole kontrollitud, kas need liinid töötavad õigesti. Test, mis jookseb rida ja ei kontrolli tulemust, suurendab ulatust, kuid ei paku turvalisust. Eesmärk pole mitte suured numbrid, vaid sisukas valideerimine. Tehisintellektiga saate kiiresti mastaapi suurendada, kuid veenduge, et iga test testib käitumist.

kolm minikarpi

Juhtum 1 – piiripealne olukord tabati. Tehisintellektil paluti teha pangarakenduse rahaülekande funktsiooni teste ning lisati konkreetselt "negatiivse summa" ja "saldo ülejäägi" stsenaariumid. Test näitas, et ülekannet ei blokeeritud negatiivse summaga; see oleks tootmises suur turvahaavatavus. Suletakse üherealise juhtelemendi lisamisega. Õppetund: piiritestid on kõige väärtuslikumad testid.

2. juhtum – võltstest. Üks meeskond tundis kergendust, kui 40 tehisintellekti toodetud ühikutestiga suurendas leviala 85%-ni. Kontrollimise ajal oli näha, et enamik teste ei kontrollinud tegelikult ühtegi väljundit, nad lihtsalt kutsusid funktsiooni ja kirjutasid assertTrue(true). Katvus oli kõrge, kuid kaitse oli null. Testid vaadati üle ja kirjutati ümber tõeliste kinnitustega. Õppetund: levinumbrid võivad valetada.

Juhtum 3 – kasutajaliidese testimine kiirendati. E-kaubanduse meeskond kirjutas 20 minutiga tehisintellektiga ostukorvi lisamise voo XCUITesti skripti; Kui see oleks käsitsi kirjutatud, kuluks pool päeva. AI arvatud ekraanielementide identifikaatorid; Meeskond sobitas need tegeliku koodiga ja parandas need. Mustandi kiirus on tõeline, kuid identifikaatori kontrollimine on inimese töö.

Nõrk viip / Tugev viip

Nõrk viip: "Kirjutage selle funktsiooni test."

Võimas viip: "Tootke selle Kotlini funktsiooni jaoks ühikutestid koos JUnit5 + MockK-ga. Funktsioon: rahaülekanne (summa, allikas, sihtmärk). Testitavad käitumised (mida kood peaks tegema):- Kehtiv ülekanne peab olema edukas- negatiivne või null summa tuleb tagasi lükata- saldost suurem summa tuleb tagasi lükata- Iga asi peab olema erand, test viga peab kontrollima ainult ühte, nende nime peaks kontrollima, motiiv välisteenus, ärge kirjutage tühja väidet."

Kopeeritavad mallid

Ühiku testimall: "Loo [JUnit/XCTest] ühikutestid selle funktsiooni jaoks [keele] jaoks. Eeldatav käitumine: [mida teha]. Kaasake: õnnelik stsenaarium, nullsisend, katkestuspunktid, veajuhtum. Laske igal testil kontrollida ühte käitumist; kasutage tähenduslikku väidet; pilka. [kood]"

Kasutajaliidese testimise mall: "Kirjutage [Espresso/XCUITest] abil järgmise voo kasutajaliidese test: [kasutaja voog samm-sammult]. Valige juurdepääsetavuse ID-ga ekraanielemendid, kasutage teksti asemel ID-d. Lisage ootestrateegia. Tuleta meelde, et elementide ID-d tegeliku koodiga sobiksin."

Testi auditi mall: "Uurige neid teste: 1) kas need kontrollivad tegelikult väljundit/käitumist või on need tühised? 2) Kas need hõlmavad piirjuhtumeid? 3) Kas need parandavad koodi või eeldavad korrektset käitumist? Märgistage ja tugevdage nõrku teste. [testid]"

Katvuse optimeerimise mall: "Tuvastage selle klassi testimata osad ja soovitage sisukaid teste. Seadistage prioriteediks tõelise riskiga teed, mitte ainult katete arv. [kood]"

Levinud vead

• Lihtsalt katsetame õnnelikku stsenaariumi. Vead salvestatakse piirolekus; Küsige neid avalikult.
• Tühja/kasutu testi vastuvõtmine. AssertTrue(true) tüüpi testid suurendavad ulatust ega paku kaitset.
• Laske tehisintellektil kontrollida, mida kood teeb. Testimine peaks eeldama, mida kood peaks tegema; muidu parandab vea.
• Eesmärgiga seotud ulatuse numbri eksimus. 90% katvus ei tähenda 90% täpsust.
• Tekstiga linkimine kasutajaliidese testimisel. Test katkeb, kui tekst muutub; Kasutage stabiilset identifikaatorit (id).
• Piltide seadistamine valesti. Tegelikule teenusele kutsuv "üksuse test" on aeglane ja rabe.

Kokkuvõttes

Testimine on mobiilse kvaliteedi selgroog ja AI on selles valdkonnas väga tõhus, eriti ühikutestimisel. Järgige testimispüramiidi: palju ühikuid, keskmine integratsioon, vähe kasutajaliidese testimist. Küsige AI-lt selgesõnaliselt õnnelikku stsenaariumi ning piirake juhtumeid ja veateid. Veenduge, et iga loodud test kinnitab käitumist; Tühjad testid ja ülepaisutatud katvus on eksitavad. Kõige tähtsam on öelda AI-le, mida kood peaks tegema, mitte seda, mida see teeb, nii et test tuvastab vea, mitte ei paranda seda.

Rakenduse ülesanne

Taotlege tehisintellektilt teste, kasutades äriloogika funktsiooni (nt allahindluse arvutamine või vormi kinnitamine) jaoks ühikutesti malli, ja määrake selgelt piirjuhtumid (null, negatiivne, liiga suur). Käivitage loodud testid, seejärel laske samad testid auditeerida "Testi auditi malliga". Otsige üles vähemalt üks nõrk test, tugevdage seda ja kontrollige, kas testid tuvastavad funktsiooni tegeliku vea (lisades väikese vea).

kontrollnimekiri

• [ ] Valisin testpüramiidi jaoks sobiva kihi (prioriteediühik)
• [ ] Soovisin lisaks õnnelikule stsenaariumile piir- ja veajuhtumeid
• [ ] Kontrollisin, et iga test sisaldab sisukat väidet
• [ ] Ma ütlesin tehisintellektile, mida kood peaks tegema, mitte mida see teeb
• [ ] Keskendusin tegelikele riskiteedele, mitte katete arvule
• [ ] Kasutasin kasutajaliidese testides stabiilset identifikaatorit, ma ei sidunud tekstiga