Ieguvumi:
- Spēja ražot vienību, integrācijas un lietotāja interfeisa testus ar mākslīgo intelektu atbilstoši testēšanas piramīdai un aptver limitu un kļūdu situācijas, kā arī laimīgus scenārijus
- Iespēja atsijāt tukšus/bezjēdzīgus testus un uzpūstu pārklājumu, pārbaudot, vai katrs ģenerētais tests patiešām apstiprina uzvedību
- Nodrošinot, ka pārbaude uztver kļūdu un neļauj tai novērst kļūdu, norādot AI, kas kodam jādara
Koda rakstīšana ir puse no darba; Pierādīt, ka kods darbojas pareizi, ir otra puse. Mobilās lietotnes saskaras ar simtiem dažādu ierīču, ekrāna izmēru, operētājsistēmas versiju un lietotāju darbības. To visu nav iespējams pārbaudīt manuāli; Tāpēc automātiskā testēšana (koda testēšanas kods — testēšana, kas darbojas bez cilvēka klikšķa) ir mobilās kvalitātes pamats. AI ir neticami efektīva testu rakstīšanā, jo testu rakstīšana ir tieši tāda veida darbs, kas tai patīk: noteiktas darbības apstiprināšana konkrētām ievadēm. Šajā nodaļā mēs uzzināsim, kā paātrināt vienību testēšanu, saskarnes testēšanu un automatizāciju ar AI, bet nodrošināt testa kvalitāti ar cilvēka acīm.
Testēšanas piramīda: ko pārbaudīt un cik daudz
Veselīga testēšanas stratēģija atgādina piramīdu. Pamatā ir iekļauts liels skaits vienību testu (ātrā pārbaude, kas pārbauda vienu funkciju vai klasi atsevišķi); tie ir ātri un lēti. Pa vidu ir mazāka integrācijas pārbaude (pārbaude, kā vairākas daļas darbojas kopā). Augšpusē ir minimāla lietotāja saskarne / pilnīga pārbaude (testēšana tiek veikta, noklikšķinot uz ekrāna, kā to dara lietotājs); tie ir reālistiski, bet lēni un trausli. AI palīdz katrā slānī, bet vislielākā vērtība ir pamatā: ātri izveidojot biznesa loģikas vienības testus.
Pārbaudes veids
Darbības joma
ātrumu
AI efektivitāte
vienību pārbaude
Viena funkcija/klase
ļoti ātri
ļoti augsts
integrācija
starpslānis
vidējs
augsts
UI / no gala līdz galam
Visa ekrāna straume
lēns
Vidēja (trausla)
Padoms. Sakot AI "ģenerēt šīs funkcijas testus", skaidri pieprasiet malas gadījumus: tukša ievade, nulle, negatīvs skaitlis, ļoti liela vērtība, tīkla kļūda. AI viegli rada laimīgu ceļu; Patiesās kļūdas slēpjas robežās un izlec, ja nevēlaties, lai tās tur atrastos.
Testu rakstīšanas soļi ar AI
- Definējiet pārbaudāmo uzvedību. "Šai funkcijai vajadzētu piešķirt šo izvadi šai ievadei."
- Norādiet ietvaru. JUnit + MockK operētājsistēmā Android, XCTest operētājsistēmā iOS, Espresso (Android) vai XCUITest (iOS) lietotāja saskarnei.
- Jautājiet par robežstāvokļiem. Laimīgs scenārijs + kļūda + pārtraukuma punkti.
- Pārvaldiet izspēles objektus. Ārējās atkarības, piemēram, tīkls un datubāze, tiek emulētas testēšanai (izmēģinājums — kontrolēts izspēles faktiskā pakalpojuma vietā).
- Palaidiet testu un pārbaudiet. Vai tests ir izturēts, vai tas apstiprina kaut ko patiesi nozīmīgu?
Piektais solis ir kritisks. AI dažreiz rada bezjēdzīgus testus, kas “vienmēr iztur”; piemēram, tests, kas neko nepārbauda vai pārbauda savus viltus datus. Pārbaudes nokārtošana un vērtīgs pārbaudījums ir dažādas lietas.
Uzmanību: tas, ka AI spēj radīt, nenozīmē, ka tests ir pareizs. Dažreiz AI pieņem pašreizējo (iespējams, kļūdaino) koda uzvedību kā "pareizu" un attiecīgi raksta testus. Šāda pārbaude kļūdu novērš, nevis novērš to. Jūs nosakāt, ko sagaida tests; Pastāstiet AI, kas tam jādara, nevis ko dara kods.
Pārbaudes pārklājuma mērs un kļūda
Testa pārklājums (kādu procentuālo daļu koda izpilda testi) ir noderīgs, bet maldinošs rādītājs. 90% pārklājums norāda, ka 90% koda ir izpildīti; taču nav pārbaudīts, vai šīs līnijas darbojas pareizi. Tests, kas vada līniju un nepārbauda rezultātu, palielina darbības jomu, bet nenodrošina drošību. Mērķis nav lieli skaitļi, bet gan jēgpilna apstiprināšana. Varat ātri palielināt mērogu, izmantojot AI, taču pārliecinieties, ka katrs tests patiešām pārbauda uzvedību.
trīs mini futrāļi
1. gadījums — konstatēta robežsituācija. AI tika lūgts pārbaudīt naudas pārveduma funkciju bankas lietojumprogrammā, un īpaši tika pievienoti scenāriji "negatīva summa" un "vairāk nekā atlikums". Pārbaudē atklājās, ka pārskaitījums nav bloķēts ar negatīvu summu; tā būtu liela drošības ievainojamība ražošanā. Slēgts, pievienojot vienas rindiņas vadīklu. Nodarbība: robežpārbaudes ir visvērtīgākās pārbaudes.
2. gadījums — viltus tests. Vienai komandai bija atvieglojums palielināt pārklājumu līdz 85%, izmantojot 40 MI veiktās vienības. Pārbaudes laikā tika konstatēts, ka lielākā daļa testu faktiski nepārbaudīja nekādu izvadi, viņi vienkārši izsauca funkciju un uzrakstīja assertTrue(true). Pārklājums bija augsts, bet aizsardzība bija nulle. Testi tika pārskatīti un pārrakstīti ar reāliem apstiprinājumiem. Nodarbība: pārklājuma skaitļi var melot.
3. gadījums — UI testēšana ir paātrināta. E-komercijas komanda 20 minūšu laikā uzrakstīja XCUITest skriptu pievienošanas grozam plūsmai, izmantojot AI; Ja tas būtu rakstīts ar roku, tas aizņemtu pusi dienas. AI uzminētie ekrāna elementu identifikatori; Komanda tos saskaņoja ar reālo kodu un salaboja. Melnraksta ātrums ir reāls, bet identifikatora pārbaude ir cilvēka darbs.
Vāja uzvedne / spēcīga uzvedne
Vāja uzvedne: "Uzrakstiet šīs funkcijas testu."
Spēcīga uzvedne: "Izveidojiet vienību testus šai Kotlin funkcijai, izmantojot JUnit5 + MockK. Funkcija: naudas pārskaitījums (summa, avots, mērķis). Pārbaudāmās darbības (ko kodu vajadzētu DARĪT): - Derīgam pārskaitījumam jābūt veiksmīgam - Ir jānoraida negatīva vai nulles summa; ārējais dienests neraksti tukšu apgalvojumu.
Kopējamas veidnes
Vienības pārbaudes veidne: "Ģenerējiet [JUnit/XCTest] vienību testus šai funkcijai [valoda]. Paredzamā darbība: [ko darīt]. Iekļauts: veiksmīgs scenārijs, nulles ievade, pārtraukuma punkti, kļūdas gadījums. Ļaujiet katram testam pārbaudīt vienu uzvedību; izmantojiet jēgpilnu apgalvojumu; izspēles. [kods]."
UI testēšanas veidne: "Uzrakstiet šādas plūsmas lietotāja interfeisa testu, izmantojot [Espresso/XCUITest]: [lietotāja plūsma soli pa solim]. Atlasiet ekrāna elementus ar pieejamības ID, teksta vietā izmantojiet id. Pievienojiet gaidīšanas stratēģiju. Atgādināt, lai elementu ID atbilstu faktiskajam kodam."
Pārbaudes audita veidne: "Pārbaudiet šos testus: 1) vai tie patiešām pārbauda rezultātu/uzvedību, vai arī tie ir nederīgi? 2) Vai tie attiecas uz ierobežotiem gadījumiem? 3) Vai tie novērš koda kļūdu vai sagaida pareizu darbību? Atzīmējiet un pastipriniet vājos testus. [testi]."
Pārklājuma optimizācijas veidne: "Identificējiet šīs klases nepārbaudītās daļas un iesakiet jēgpilnus testus. Nosakiet prioritāti ceļiem ar reālu risku, nevis tikai pārklājumu skaitu. [kods]."
Biežas kļūdas
- Vienkārši pārbaudu laimīgo scenāriju. Kļūdas tiek saglabātas robežstāvokļos; Lūdziet tos atklāti.
- Tukša/bezjēdzīga testa pieņemšana. AssertTrue(true) tipa testi palielina darbības jomu un nesniedz nekādu aizsardzību.
- Liekot AI pārbaudīt, ko kods dara. Testēšanai vajadzētu sagaidīt, ko kodam vajadzētu darīt; pretējā gadījumā tas novērš kļūdu.
- Tvēruma numurs ir sajaukts ar mērķi. 90% pārklājums nenozīmē 90% precizitāti.
- Saites uz tekstu izveide lietotāja saskarnes testēšanā. Pārbaude tiek pārtraukta, mainoties tekstam; Izmantojiet stabilu identifikatoru (id).
- Izsmieklu iestatīšana ir nepareiza. "Vienības pārbaude", kas izsauc faktisko pakalpojumu, būs lēna un trausla.
Rezumējot
Testēšana ir mobilās kvalitātes mugurkauls, un AI šajā jomā ir ļoti efektīva, jo īpaši vienību testēšanā. Sekojiet testēšanas piramīdai: daudz vienību, vidēja integrācija, maz UI testēšanas. Skaidri pieprasiet AI laimīgo scenāriju, kā arī ierobežojiet gadījumus un kļūdu ceļus. Pārliecinieties, vai katrs ģenerētais tests patiešām apstiprina uzvedību; Tukšas pārbaudes un palielināts pārklājums ir maldinoši. Vissvarīgākais ir pastāstīt AI, kas kodam ir jādara, nevis ko tas dara, lai pārbaude uztvertu kļūdu, nevis to izlabo.
Lietojumprogrammas uzdevums
Pieprasiet AI testus, izmantojot “vienības testa veidni” biznesa loģikas funkcijai (piemēram, atlaides aprēķināšanai vai veidlapas validācijai), un skaidri norādiet limita gadījumus (nulle, negatīva, pārāk liela). Palaidiet ģenerētos testus un pēc tam veiciet tos pašus testus, izmantojot “Pārbaudes audita veidni”. Atrodiet vismaz vienu vāju testu, pastipriniet to un pārbaudiet, vai testi uztver faktisku funkcijas kļūdu (pievienojot nelielu kļūdu).
kontrolsaraksts
- [ ] Es izvēlējos atbilstošo testa piramīdas slāni (prioritātes vienība)
- [ ] Es vēlējos ne tikai laimīgo scenāriju, bet arī ierobežojumu un kļūdu gadījumus
- [ ] Es pārbaudīju, vai katrā testā ir ietverts jēgpilns apgalvojums
- [ ] Es teicu AI, kas kodam ir jādara, nevis ko tas dara
- [ ] Es koncentrējos uz faktiskajiem riska ceļiem, nevis segumu skaitu
- [ ] UI testos izmantoju stabilu identifikatoru, nesaistīju ar tekstu