Pelnas:
- Galimybė atlikti vienetinius, integravimo ir vartotojo sąsajos testus su dirbtiniu intelektu pagal testavimo piramidę ir aprėpti ribines ir klaidų situacijas bei laimingus scenarijus
- Galimybė pašalinti tuščius / nenaudingus testus ir išpūstą aprėptį tikrinant, ar kiekvienas sugeneruotas testas iš tikrųjų patvirtina elgesį
- Užtikrinant, kad testas sugautų klaidą ir neleistų jam ištaisyti klaidos, nurodant AI, ką kodas turi daryti
Rašyti kodą yra pusė darbo; Įrodymas, kad kodas veikia teisingai, yra antroji pusė. Programėlės mobiliesiems susiduria su šimtais skirtingų įrenginių, ekranų dydžių, operacinės sistemos versijų ir naudotojų elgsenos. Neįmanoma visų šių dalykų patikrinti rankiniu būdu; Štai kodėl automatizuotas testavimas (kodo testavimo kodas – testavimas, kuris vykdomas be žmogaus paspaudimo) yra mobiliojo ryšio kokybės pagrindas. AI yra neįtikėtinai efektyvus rašant testus, nes rašymo testai yra būtent tokio modelio darbas, kuris jai patinka: tam tikros įvesties elgsenos patvirtinimas. Šiame skyriuje išmoksime paspartinti vienetų testavimą, sąsajų testavimą ir automatizavimą naudojant AI, tačiau užtikrinti testo kokybę žmogaus akimis.
Testavimo piramidė: ką ir kiek išbandyti
Sveiko testavimo strategija primena piramidę. Bazėje yra daug vienetų testų (greitasis testavimas, kuris tikrina vieną funkciją arba klasę atskirai); jie greiti ir pigūs. Viduryje yra mažiau integracijos testavimo (tikrinama, kaip kelios dalys veikia kartu). Viršuje yra minimalus UI/end-to-end testavimas (testavimas atliekamas spustelėjus ekraną, kaip tai daro vartotojas); jie realistiški, bet lėti ir trapūs. AI padeda kiekviename lygmenyje, tačiau didžiausia vertė yra bazėje: greitai sukuriami verslo logikos vienetiniai testai.
Bandymo tipas
Taikymo sritis
greitis
AI efektyvumas
vieneto bandymas
Viena funkcija / klasė
labai greitai
labai aukštas
integracija
tarpsluoksnis
vidutinis
aukštas
UI / nuo galo iki galo
Visas ekrano srautas
lėtas
Vidutinis (trapus)
Patarimas: liepdami AI „generuoti šios funkcijos testus“, aiškiai paprašykite kraštinių atvejų: tuščia įvestis, nulis, neigiamas skaičius, labai didelė reikšmė, tinklo klaida. AI lengvai sukuria laimingą kelią; Tikrosios klaidos slepiasi ribose ir iššoka, jei nenori jų ten.
Testų rašymo su AI žingsniai
- Apibrėžkite elgesį, kurį reikia išbandyti. "Ši funkcija turėtų suteikti šią išvestį šiam įėjimui."
- Nurodykite rėmą. JUnit + MockK „Android“, „XCTest“ „iOS“, „Espresso“ („Android“) arba „XCUITest“ („iOS“), skirta vartotojo sąsajai.
- Klauskite ribinių būsenų. Laimingas scenarijus + klaida + lūžio taškai.
- Tvarkykite netikrus objektus. Išorinės priklausomybės, tokios kaip tinklas ir duomenų bazė, yra emuliuojamos testavimui (pasivaizdavimas – kontroliuojamas pasimetimas, o ne tikroji paslauga).
- Paleiskite testą ir patikrinkite. Ar testas išlaikomas, ar jis patvirtina ką nors tikrai prasmingo?
Penktasis žingsnis yra labai svarbus. AI kartais sukuria nenaudingus testus, kurie „visada praeina“; pavyzdžiui, testas, kuris nieko netikrina arba tikrina savo netikrus duomenis. Išlaikytas egzaminas ir vertingas testas yra skirtingi dalykai.
Atsargiai: vien todėl, kad AI gali sukurti, nereiškia, kad testas yra teisingas. Kartais AI priima dabartinį (galbūt klaidingą) kodo elgesį kaip „teisingą“ ir atitinkamai rašo testus. Toks testavimas klaidą ištaiso, o ne ją pagauna. Jūs nustatote, ko laukia testas; Pasakykite AI, ką jis turėtų daryti, o ne ką daro kodas.
Bandymo aprėpties matas ir klaidingumas
Testo aprėptis (kiek procentų kodo paleidžiama testais) yra naudinga, bet klaidinanti metrika. 90% aprėptis rodo, kad 90% kodo buvo įvykdyta; bet nebuvo patikrinta, ar tos linijos veikia tinkamai. Bandymas, kuris paleidžia eilutę ir netikrina rezultato, padidina taikymo sritį, bet neužtikrina saugumo. Tikslas – ne dideli skaičiai, o prasmingas patvirtinimas. Galite greitai padidinti mastą naudodami AI, tačiau įsitikinkite, kad kiekvienas testas iš tikrųjų patikrina elgseną.
trys mini dėklai
1 atvejis – užfiksuota pasienio padėtis. AI buvo paprašyta atlikti pinigų pervedimo funkcijos bandymus banko programoje ir konkrečiai buvo pridėti „neigiamos sumos“ ir „daugiau nei likučio“ scenarijai. Testas atskleidė, kad pervedimas nebuvo užblokuotas su neigiama suma; tai būtų didelis gamybos saugumo spragas. Uždaryta pridedant vienos eilutės valdiklį. Pamoka: ribiniai testai yra patys vertingiausi.
2 atvejis – netikras testas. Vienai komandai palengvėjo padidinus aprėptį iki 85 %, atlikus 40 AI atliktų vienetų testų. Patikrinimo metu buvo pastebėta, kad dauguma testų iš tikrųjų nepatvirtino jokios išvesties, jie tiesiog iškvietė funkciją ir parašė assertTrue(true). Aprėptis buvo didelė, bet apsauga nulinė. Testai buvo kapitališkai suremontuoti ir perrašyti su tikrais patvirtinimais. Pamoka: aprėpties skaičiai gali meluoti.
3 atvejis – paspartintas vartotojo sąsajos testavimas. El. prekybos komanda per 20 minučių parašė XCUITest scenarijų, skirtą pridėti prie krepšelio srauto su AI; Jei būtų rašoma ranka, tai užtruktų pusę dienos. AI atspėti ekrano elementų identifikatoriai; Komanda juos suderino su tikru kodu ir ištaisė. Juostos greitis yra tikras, tačiau identifikatoriaus patikrinimas yra žmogaus darbas.
Silpnas raginimas / Stiprus raginimas
Silpnas raginimas: „Parašykite šios funkcijos testą“.
Galingas raginimas: "Sukurkite šios Kotlin funkcijos vienetų testus su JUnit5 + MockK. Funkcija: pinigų pervedimas (suma, šaltinis, tikslas). Testuotinos elgsenos (ką turėtų DARYTI kodas): - Galiojantis pervedimas turi būti sėkmingas - Neigiama arba nulinė suma turi būti atmesta - Turi būti atmesta suma, didesnė už likutį - Kiekviena išimtis, bandymo klaida turi būti tik vienas dalykas, tikrinimo klaida turi būti tinkamas, jų pavadinimas turi būti tinkamas. išorinė tarnyba nerašykite tuščio tvirtinimo.
Kopijuojami šablonai
Vieneto testo šablonas: „Generuokite [JUnit/XCTest] vienetų testus šiai funkcijai [kalba]. Numatoma elgsena: [ką daryti]. Įtraukite: laimingas scenarijus, nulinė įvestis, lūžio taškai, klaidos atvejis. Leiskite kiekvienam bandymui patikrinti vieną elgseną; naudokite prasmingą tvirtinimą; pasityčiokite. [kodas]“
UI testavimo šablonas: "Parašykite šio srauto NS testą naudodami [Espresso/XCUITest]: [naudotojo srautas žingsnis po žingsnio]. Pasirinkite ekrano elementus su pritaikymo neįgaliesiems ID, naudokite id vietoj teksto. Pridėkite laukimo strategiją. Priminti, kad elementų ID atitiktų faktinį kodą."
Bandymo audito šablonas: „Išnagrinėkite šiuos testus: 1) ar jie iš tikrųjų patvirtina išvestį / elgesį, ar jie yra niekiniai? 2) Ar jie apima ribinius atvejus? 3) Ar jie ištaiso kodą ar tikisi teisingo elgesio? Pažymėkite ir sustiprinkite silpnus testus. [testai]"
Aprėpties optimizavimo šablonas: „Nustatykite neišbandytas šios klasės dalis ir pasiūlykite prasmingų testų. Pirmenybę teikite keliams su realia rizika, o ne tik aprėpčių skaičiumi. [kodas]“
Dažnos klaidos
- Tiesiog išbandžiau laimingą scenarijų. Klaidos saugomos ribinėse būsenose; Paprašykite jų atvirai.
- Tuščio / nenaudingo testo priėmimas. AssertTrue(true) tipo testai padidina taikymo sritį ir nesuteikia jokios apsaugos.
- AI patikrins, ką daro kodas. Testuojant reikia tikėtis, ką kodas turėtų daryti; kitu atveju klaidą ištaiso.
- Klaidingas taikymo srities numeris pagal paskirtį. 90% aprėptis nereiškia 90% tikslumo.
- Nuoroda į tekstą atliekant vartotojo sąsajos testavimą. Pasikeitus tekstui testas sulaužomas; Naudokite stabilų identifikatorių (id).
- Neteisingai nustatomi juokeliai. „Įrenginio testas“, kuris iškviečia tikrąją paslaugą, bus lėtas ir trapus.
Apibendrinant
Testavimas yra mobiliojo ryšio kokybės pagrindas, o dirbtinis intelektas šioje srityje yra labai efektyvus, ypač atliekant vienetų testavimą. Sekite testavimo piramidę: daug vienetų, vidutinė integracija, mažai UI testavimo. Aiškiai paprašykite AI dėl laimingo scenarijaus, taip pat apribokite atvejus ir klaidų kelius. Įsitikinkite, kad kiekvienas sugeneruotas testas iš tikrųjų patvirtina elgesį; Tušti testai ir padidinta aprėptis yra klaidinantys. Svarbiausia, pasakykite AI, ką kodas turėtų daryti, o ne ką jis daro, kad testas sugautų klaidą, o ne ją ištaisytų.
Taikymo užduotis
Prašykite dirbtinio intelekto bandymų naudodami verslo logikos funkcijos vieneto testavimo šabloną (pvz., nuolaidos apskaičiavimą arba formos patvirtinimą) ir aiškiai nurodykite ribinius atvejus (nulinis, neigiamas, per didelis). Vykdykite sugeneruotus testus, tada patikrinkite tuos pačius testus naudodami „Test audito šabloną“. Raskite bent vieną silpną testą, sustiprinkite jį ir patikrinkite, ar testai neužfiksuoja tikrosios funkcijos klaidos (pridedant nedidelę klaidą).
kontrolinis sąrašas
- [ ] Aš pasirinkau atitinkamą bandomosios piramidės sluoksnį (prioritetinis vienetas)
- [ ] Norėjau ne tik laimingo scenarijaus, bet ir ribinių ir klaidų atvejų
- [ ] Patikrinau, kad kiekviename teste yra prasmingas tvirtinimas
- [ ] Aš pasakiau AI, ką kodas turi daryti, o ne ką jis daro
- [ ] Aš sutelkiau dėmesį į faktinius rizikos kelius, o ne į aprėpčių skaičių
- [ ] UI testuose naudojau stabilų identifikatorių, nesusiejau su tekstu