Testsukupolvi tekoälyllä: yksikkö-, käyttöliittymä- ja automaatiotestit

Voitot:

• Kyky tuottaa yksikkö-, integraatio- ja käyttöliittymätestejä tekoälyllä testauspyramidin mukaisesti ja kattaa raja- ja virhetilanteet sekä onnelliset skenaariot
• Mahdollisuus karsia pois tyhjät/hyödyttömät testit ja paisunut kattavuus tarkistamalla, että jokainen luotu testi todella vahvistaa käyttäytymisen
• Varmistamalla, että testi havaitsee virheen ja estää sitä korjaamasta virhettä kertomalla tekoälylle, mitä koodin tulee tehdä

Koodin kirjoittaminen on puoli työtä; Todistaminen, että koodi toimii oikein, on toinen puoli. Mobiilisovellukset kohtaavat satoja erilaisia ​​laitteita, näyttökokoja, käyttöjärjestelmäversioita ja käyttäjien käyttäytymistä. Näitä kaikkia on mahdotonta testata manuaalisesti; Tästä syystä automaattinen testaus (kooditestauskoodi – testaus, joka toimii ilman ihmisen napsautusta) on mobiililaadun selkäranka. Tekoäly on uskomattoman tehokas kirjoittamaan testejä, koska testien kirjoittaminen on juuri sellaista mallityötä, josta se pitää: tietyn käyttäytymisen validointi tietyille syötteille. Tässä osiossa opimme nopeuttamaan yksikkötestausta, käyttöliittymätestausta ja automaatiota tekoälyn avulla, mutta varmistamaan testin laadun ihmissilmän kautta.

Testauspyramidi: mitä testata ja kuinka paljon

Terve testausstrategia muistuttaa pyramidia. Perus sisältää suuren määrän yksikkötestejä (nopea testaus, joka testaa yksittäisen funktion tai luokan erikseen); ne ovat nopeita ja halpoja. Keskellä on vähemmän integraatiotestausta (testataan kuinka useat osat toimivat yhdessä). Yläosassa on minimaalinen käyttöliittymä/päästä päähän -testaus (testaus tehdään napsauttamalla näyttöä käyttäjän tapaan); ne ovat realistisia, mutta hitaita ja hauraita. Tekoäly auttaa joka tasolla, mutta suurin arvo on pohjalla: liiketoimintalogiikan yksikkötestien nopea tuottaminen.

Testityyppi

Laajuus

nopeus

AI tehokkuus

yksikkötestaus

Yksi toiminto/luokka

erittäin nopea

erittäin korkea

integraatio

välikerros

keskikokoinen

korkea

Käyttöliittymä / päästä päähän

Kaikki näytön stream

hidas

Keskikokoinen (herkkä)

Vihje: Kun käsket tekoälyä "luomaan testejä tälle toiminnolle", kysy nimenomaisesti reunatapauksia: tyhjä syöttö, nolla, negatiivinen luku, erittäin suuri arvo, verkkovirhe. AI tuottaa onnellisen polun helposti; Todelliset virheet piiloutuvat rajoihin ja hyppäävät ulos, jos et halua niitä sinne.

Testien kirjoittamisen vaiheet tekoälyllä

1. Määrittele testattava käyttäytyminen. "Tämän toiminnon pitäisi antaa tämä tulos tälle tulolle."
2. Määritä kehys. JUnit + MockK Androidissa, XCTest iOS:ssä, Espresso (Android) tai XCUITest (iOS) käyttöliittymälle.
3. Kysy rajatiloja. Onnellinen skenaario + virhe + keskeytyspisteet.
4. Hallitse valeobjekteja. Ulkoisia riippuvuuksia, kuten verkkoa ja tietokantaa, emuloidaan testausta varten (mock - ohjattu pila todellisen palvelun sijaan).
5. Suorita testi ja varmista. Meneekö testi läpi, vahvistaako se jotain todella merkityksellistä?

Viides vaihe on kriittinen. Tekoäly tuottaa joskus hyödyttömiä testejä, jotka "läpäisevät aina"; esimerkiksi testi, joka ei varmista mitään tai tarkistaa omat väärennetyt tiedot. Testin läpäiseminen ja arvokas koe ovat eri asioita.

Varoitus: Se, että tekoäly pystyy tuottamaan, ei tarkoita, että testi olisi oikea. Joskus tekoäly hyväksyy koodin nykyisen (ehkä viallisen) käyttäytymisen "oikeaksi" ja kirjoittaa testejä sen mukaisesti. Tällainen testaus korjaa vian sen sijaan, että se kiinnittäisi sitä. Päätät, mitä testi odottaa; Kerro tekoälylle, mitä sen pitäisi tehdä, älä mitä koodi tekee.

Testaa kattavuuden mitta ja virhe

Testin kattavuus (kuinka prosenttiosuus koodista testit suoritetaan) on hyödyllinen mutta harhaanjohtava mittari. 90 % peitto osoittaa, että 90 % koodista on suoritettu; mutta ei ole varmistettu, että nämä linjat toimivat oikein. Testi, joka suorittaa rivin eikä tarkista tulosta, laajentaa laajuutta, mutta ei tarjoa turvallisuutta. Tavoitteena ei ole suuria lukuja, vaan mielekästä validointia. Voit nopeasti laajentaa toimintaa tekoälyllä, mutta varmista, että jokainen testi todella testaa käyttäytymistä.

kolme minilaukkua

Tapaus 1 – Rajatilanne havaittu. Tekoälyä pyydettiin testaamaan rahansiirtotoimintoa pankkisovelluksessa, ja erityisesti "negatiivinen summa" ja "enemmän kuin saldo" -skenaariot lisättiin. Testi paljasti, että siirtoa ei estetty negatiivisella summalla; tämä olisi suuri tietoturvahaavoittuvuus tuotannossa. Suljetaan lisäämällä yhden rivin ohjausobjekti. Oppitunti: rajatestit ovat arvokkaimpia testejä.

Tapaus 2 – Väärennetyt testit. Yksi tiimi sai helpotuksesta nostaa kattavuuden 85 prosenttiin 40 tekoälyn tuottaman yksikkötestin avulla. Tarkastuksen aikana havaittiin, että suurin osa testeistä ei varsinaisesti vahvistanut mitään lähtöä, he vain kutsuivat funktiota ja kirjoittivat assertTrue(true). Kattavuus oli korkea, mutta suojaus oli nolla. Testit tarkistettiin ja kirjoitettiin uudelleen todellisilla validoinneilla. Oppitunti: peittoluvut voivat valehdella.

Tapaus 3 – Käyttöliittymätestausta nopeutettiin. Verkkokauppatiimi kirjoitti XCUITest-skriptin ostoskoriin lisäämisestä tekoälyllä 20 minuutissa; Jos se kirjoitettaisiin käsin, siihen menisi puoli päivää. Tekoälyn arvatut näyttöelementtien tunnisteet; Tiimi sovitti ne oikeaan koodiin ja korjasi ne. Vedon nopeus on todellinen, mutta tunnisteen todentaminen on ihmisen työtä.

Heikko kehote / Vahva kehote

Heikko kehote: "Kirjoita testi tälle funktiolle."

Tehokas kehote: "Tuota tälle Kotlin-funktiolle yksikkötestejä JUnit5 + MockK:lla. Toiminto: rahansiirto (summa, lähde, kohde). Testattavat käytökset (mitä koodin pitäisi TEHDÄ): - Kelvollisen siirron on oltava onnistunut - Negatiivinen tai nolla summa on hylättävä - Saldoa suurempi määrä on hylättävä - Poikkeus, testausvirheen tulee heittää vain yksi asia, komentovirheen tulee heittää asianmukainen ulkoiseen palveluun älä kirjoita tyhjää väitettä."

Kopioitavat mallit

Yksikkötestimalli: "Luo [JUnit/XCTest] yksikkötestit tälle funktiolle [kieli]. Odotettu toiminta: [mitä tehdä]. Sisällytä: onnellinen skenaario, tyhjä syöttö, keskeytyskohdat, virhetapaus. Anna jokaisen testin vahvistaa yksittäinen käyttäytyminen; käytä mielekästä väitettä; pilkkaa. [koodi]"

Käyttöliittymän testausmalli: "Kirjoita käyttöliittymätesti seuraavasta kulusta [Espresso/XCUITest]:llä: [käyttäjän kulku vaihe vaiheelta]. Valitse näyttöelementit esteettömyystunnuksella, käytä id:tä tekstin sijaan. Lisää odotusstrategia. Muistuta minua sovittamaan elementtien tunnukset todelliseen koodiin."

Testin tarkastusmalli: "Tarkista nämä testit: 1) Vahvistavatko ne todella tuotoksen/käyttäytymisen vai ovatko ne nolla? 2) Kattavatko ne rajatapaukset? 3) Korjaavatko ne koodia vai odottavatko ne oikeaa toimintaa? Merkitse ja vahvista heikkoja testejä. [testit]"

Kattavuuden optimointimalli: "Tunnista tämän luokan testaamattomat osat ja ehdota mielekkäitä testejä. Priorisoi polut, joissa on todellista riskiä, ei vain peittojen määrää. [koodi]"

Yleisiä virheitä

• Testaillaan vain onnellista skenaariota. Virheet tallennetaan rajatiloihin; Pyydä niitä avoimesti.
• Tyhjän/turhan testin hyväksyminen. AssertTrue(true)-tyyppiset testit lisäävät laajuutta eivätkä tarjoa suojaa.
• AI tarkistaa, mitä koodi tekee. Testauksen pitäisi odottaa mitä koodin pitäisi tehdä; muuten se korjaa vian.
• Säteilyn numero on väärä tarkoitukseen. 90 % kattavuus ei tarkoita 90 % tarkkuutta.
• Linkittäminen tekstiin käyttöliittymätestauksessa. Testi katkeaa, kun teksti muuttuu; Käytä vakaata tunnistetta (id).
• Mocks-asettelu väärin. Varsinaista palvelua kutsuva "yksikkötesti" on hidas ja hauras.

Yhteenvetona

Testaus on mobiililaadun selkäranka, ja tekoäly on erittäin tehokas tällä alueella, erityisesti yksikkötestauksessa. Seuraa testauspyramidia: monta yksikköä, keskikokoinen integraatio, vähän käyttöliittymätestausta. Pyydä tekoälyltä nimenomaisesti onnellista skenaariota sekä rajatapauksia ja virhepolkuja. Varmista, että jokainen luotu testi todella vahvistaa käyttäytymisen; Tyhjät testit ja liian korkea kattavuus ovat harhaanjohtavia. Mikä tärkeintä, kerro tekoälylle, mitä koodin pitäisi tehdä, ei mitä se tekee, jotta testi havaitsee vian, ei korjaa sitä.

Sovellustehtävä

Pyydä tekoälyltä testejä käyttämällä "Yksikkötestimallia" liiketoimintalogiikkafunktiolle (esim. alennuslaskelma tai lomakkeen validointi) ja määritä rajatapaukset nimenomaisesti (nolla, negatiivinen, liian suuri). Suorita luodut testit ja tarkasta sitten samat testit "Testitarkastusmallilla". Etsi vähintään yksi heikko testi, vahvista sitä ja testaa, havaitsevatko testit funktion todellisen virheen (lisäämällä pienen bugin).

tarkistuslista

• [ ] Valitsin testipyramidille sopivan kerroksen (prioriteettiyksikkö)
• [ ] Halusin raja- ja virhetapauksia onnellisen skenaarion lisäksi
• [ ] Varmistin, että jokainen testi sisältää merkityksellisen väitteen
• [ ] Kerroin tekoälylle, mitä koodin pitäisi tehdä, en mitä se tekee
• [ ] Keskityin todellisiin riskipolkuihin, en peittojen määrään
• [ ] Käytin käyttöliittymätesteissä vakaata tunnistetta, en sidonut tekstiin