Voitot:
- Kyky erottaa, missä tekoäly säästää reaaliaikaa laadunvarmistusprosessissa ja missä laatupäätökset, kuten "valmis julkaistavaksi", jätetään ihmisille tehtävän riskitasosta riippuen
- Kyky tunnistaa väärien hyväksyntöjen riski ja ottaa käyttöön varmistuskuri, joka testaa jokaisen tekoälytestin tarkoituksella rikkomalla koodia
- Kyky suojata testidataa, henkilötietoja ja avaimia ja hankkia tapana suorittaa tietoturvatestauksia vain luvan puitteissa ja puolustustarkoituksiin.
Harkitse vapauttamisiltaa. Satoja testejä ajettiin, ne kaikki saivat vihreän valon, tiimi oli helpottunut ja ohjelmisto otettiin käyttöön. Seuraavana aamuna asiakas ilmoitti, että maksunäyttö oli kaatunut. Testit olivat vihreitä, mutta hän ei nähnyt virhettä. Tämä on laadunvarmistusammatin (QA) kavalin painajainen, eli sen kurinalaisuus, joka järjestelmällisesti varmistaa, että ohjelmisto on haluttu laatu: testi, joka hehkuu vihreänä, mutta ei varsinaisesti vahvista mitään. Kun tekoäly (AI - ohjelmisto, joka poimii kuvioita historiallisista tiedoista ja luo tekstiä ja koodia) tulee tähän ammattiin, tapahtuu sekä valtava kiihtyvyys että suurennos juuri tämä painajainen. Tämän moduulin alkuperäinen lupaus on selvä: tekoäly on testausassistentti, suunnitelmageneraattori ja ideoiden kertoja; Olet testaaja, joka allekirjoittaa "onko tämä ohjelmisto valmis julkaistavaksi" -päätöksen.
Tässä ensimmäisessä jaksossa keskitymme kuriin, emme työkaluun. Opit missä tekoäly säästää reaaliaikaa laadunvarmistusprosessissa, missä se on vaarallista, miksi petollinen vihreä niin kutsuttu "false-pass" on suurin riski, kuinka jokainen tulos tarkistetaan ja mitä tietoja voit antaa mille työkalulle. Ilman tätä perustaa seuraavat yksiköt pysyvät ilmassa.
Missä tekoäly on hyödyllinen testausprosessissa?
Jaetaan testaustyöt kahteen suureen klusteriin. Ensimmäinen klusteri: toistuvat, tuotettavat, luonnostyöt. Testitapauksen laatiminen vaatimuksesta, keskeytyskohtien luetteloiminen, automaatiokoodirungon kirjoittaminen näytölle, monimutkaisen virhetapauksen kääntäminen siistiksi virheraportiksi, satojen lokitiedostorivien yhteenveto, skeeman purkaminen API-vastauksesta. Näissä tehtävissä tekoäly lyhentää minuutteja sekunneiksi eikä väsy.
Toinen klusteri: päätökset, joiden tuloksena on laatu, luottamus ja vastuullisuus. Päätökset, kuten "voiko tämä versio julkaista", "onko tämä virhe kriittinen vai voidaanko sitä lykätä", "onko tämä testikattavuus riittävä", "kantaako tämä skenaario todellisen käyttäjäriskin" jne. vaativat kontekstia, tuotetietoa ja vastuuta. Täällä tekoäly luo vaihtoehtoja, luonnoksia – mutta sinä päätät "hyväksy/hylkää" ja "mennä/ei mene".
Selvennetään eroa yhdellä lauseella: AI on vahva siinä, "mitä tilanteita voidaan testata ja kuinka kirjoittaa koodia, joka testaa sitä"; Päätös on sinun, kun tulee kysymykseen "Toimiiko tämä ohjelmisto todella ja kuka takaa sen?"
Vinkki: Ennen kuin luovutat työn tekoälylle, kysy: "Mitä tapahtuu, jos tämä tulos on väärä, enkä huomaa?" Jos vastaus on "Hätän muutaman minuutin", delegoi helposti. Jos vastaus on "vikainen ohjelmisto lähtee käyttöön", anna tekoälyn tuottaa luonnos ja sinä teet päätöksen ja varmistuksen.
Väärä hyväksyntä: ykkönen tekoälyn riski laadunvarmistuksessa
Kun testi palaa vihreänä, se voi tarkoittaa kahta asiaa: joko ohjelmisto toimii oikein tai se ei näe virhettä, koska testi on kirjoitettu väärin. Toista kutsutaan vääräksi hyväksytyksi - testi sanoo "hyväksytty", mutta ei varsinaisesti vahvista mitään. Tämä riski kasvaa merkittävästi tekoälyllä tuotetuissa testeissä, koska tekoäly on erittäin onnistunut kirjoittamaan sujuvasti, sileän näköisiä mutta tyhjiä testejä.
Kolme yleisintä pseudo-hyväksynnän muotoa ovat: (1) Testaus ilman väitettä – koodi suoritetaan, ei sisällä väitteitä, läpäisee aina. (2) Itsevarmennustesti — testin odotettu arvo lasketaan testattavan koodin tulosteesta; Eli mitä tahansa koodi tuottaa, testi hyväksyy "oikeaksi". (3) Testi, joka vahvistaa väärän asian – väite on olemassa, mutta se tarkistaa jotain triviaalia (esim. "vastaus ei ole tyhjä"), ei varsinaista liiketoimintasääntöä.
Varoitus: Vihreä testipaneeli ei ole todiste laadusta; Parhaimmillaan siinä lukee "kirjoittamamme säätimet eivät ole rikki juuri nyt". Älä lohduta sitä, että näet tekoälyn tuottaman testin "hyväksynnän" – todellinen kysymys kuuluu: muuttuuko tämä testi punaiseksi, jos rikon koodin tarkoituksella? Jos se ei pyöri, tämä testi on koriste.
Kultainen sääntö, joka toistuu koko tässä moduulissa: testaa jokainen tekoälytesti tarkoituksella rikkomalla koodi. Jos testi on edelleen vihreä, testi ei toimi. (Syvennämme tätä ajatusta mutaatiotestauksena yksikössä 10.)
Varmistuskuri: kolme vaihetta
AI puhuu luottavaisesti; Se ei tarkoita, että se olisi totta. Kehitä kolmivaiheinen refleksi, jota sovelletaan jokaiseen tulokseen:
- Sido se vaatimukseen. Jokaisen testitapauksen ja väitteen, jonka mukaan tekoäly tuottaa, on perustuttava todellisiin vaatimuksiin tai hyväksymiskriteereihin (ehdot, jotka työn on täytettävä, jotta sitä voidaan pitää "tehtynä"). "Minkä säännön tämä skenaario vahvistaa?" kysyä.
- Nähdä punaista. Suorita luotu testi kerran rikkoen koodin. Jos se ei muutu punaiseksi, testi on virheellinen. Tämä on tekoälytestauksen ei-neuvoteltava vaihe.
- Vie se kontekstisuodattimen läpi. Vastaako tulos sitä, mitä tiedät olevan tuotteen käyttäytyminen, arkkitehtuuri, todellinen käyttäjävirta? Verkkotunnuksesi tietämys on viimeinen suodatin.
Tietosuoja ja tietoturva: mikä menee minne?
Testiympäristössä työskentelemäsi tiedot ovat usein arkaluonteisia: todelliset asiakastietueet, tuotantotietokannan kopiot, API-avaimet, sisäiset järjestelmäosoitteet, vielä julkistamattomat ominaisuudet. Tee yksinkertainen luokitus: Avoimet tiedot (dokumentoitu, julkisesti saatavilla) voivat syöttää minkä tahansa ajoneuvon. Sisäiset tiedot (lähdekoodin fragmentit, sisäinen dokumentaatio) vain viraston hyväksymille työkaluille. Luottamukselliset tiedot (oikeat asiakastiedot, henkilöllisyystiedot, haavoittuvuustiedot, avaimet) pääsevät vain laitoksen sopimustyökaluihin, joiden tiedot eivät mene mallikoulutukseen, mieluiten peitettynä.
Tietoturvatestauksen yhteydessä on lisärajoitus: kaikki tässä moduulissa opittu on puolustustarkoituksessa – oman tuotteesi turvallisuuden arvovaltaista testausta varten. Tekoälyn käyttäminen tunkeutumiseen jonkun toisen järjestelmään ilman lupaa, todellisten haavoittuvuuksien aseistamiseen tai sellaisen järjestelmän testaamiseen, johon sinulla ei ole valtuuksia, on sekä epäeettistä että rikollista. Mitään loukkaavaa testausta ei tehdä ilman lupaa (laajuus ja lupa).
Vinkki: Käytä synteettisiä (keinotekoisesti tuotettuja) testitietoja todellisten asiakastietojen sijaan. Tekoälyn pyytäminen "luomaan realistisia, mutta täysin kuvitteellisia testitietoja" sekä säilyttää yksityisyyden että monipuolistaa reunatapauksia.
kolme minilaukkua
Tapaus 1 – Ajansäästö oikeassa paikassa. Ekomerce-tiimin testaaja käytti kuusi tuntia manuaalisesti testiskenaarion luomiseen kunkin julkaisun 30-sivuisesta vaatimusasiakirjasta. Hän antoi asiakirjan (osan, joka ei sisältänyt liikesalaisuuksia) YZ:lle ja pyysi jäsenneltyä skenaarioluonnosta; Aikaa lyhennettiin 90 minuuttiin. Hän käytti säästettyä aikaa tarkistaakseen itse lisäämällä liiketoimintasääntöjen reunatapauksia, jotka tekoäly oli jättänyt huomiotta. Tekoäly vei pois toistuvan työn jättäen tuomion ihmiselle.
Tapaus 2 – Väärennössyöttäminen kiinni. Kehittäjällä oli tekoäly kirjoittaa 12 yksikkötestiä laskentafunktiolle; ne olivat kaikki vihreitä. Testaaja toteutti "katso punainen" -vaiheen: funktion sisällä olevan yhteenlaskumerkin muuttaminen kertolaskuksi. Vain kolme 12 testistä palasi punaisena. Muut 9 testiä eivät antaneet todellista vahvistusta; Se vain sanoi "se ei antanut virhettä". 9 koristetestiä poistettiin ja tilalle kirjoitettiin 5 todellista testiä.
Tapaus 3 – Paluu tietosuojaloukkauksesta. Harjoittelija liitti virhelokin, joka sisälsi todelliset asiakassähköpostit ja kortin neljä viimeistä numeroa tuotantotietokannasta julkiseen työkaluun ja sanoi "selitä tämä virhe". Laadunvarmistusjohtaja puuttui asiaan: tämä oli käsistä poikki henkilötietoja ja KVKK:n (henkilötietosuojalain) vastaista. Sama työ tehtiin laitoksen hyväksymässä ajoneuvossa, peittäen henkilökohtaiset alueet ja jättäen vain pinojäljen.
Neljä kopioitavaa mallia
1) Soveltuvuuden arviointi:
Tehtäväsi: vanhempi laadunvarmistusjohtaja. Kuvaan sinulle testaustyötä. Kerro minulle (1) onko tämä työ luonnos-/analyysityötä, joka voidaan turvallisesti delegoida tekoälylle, vai laatupäätös, joka ihmisen on tehtävä, (2) virheellisen tulosteen mahdolliset kustannukset, (3) tarkastus, joka minun pitäisi tehdä ennen delegoimista. Työ: [lisää työ tähän]
2) Pseudo-pass control:
Katso alla oleva testi. Kerro minulle: - Millaisen käyttäytymisen tämä testi vahvistaa? (yksi virke)- Kuinka voin rikkoa testattavan koodin niin, että testi muuttuu PUNAISEKSI?- Onko jokin heikkous, joka saattaisi aiheuttaa tämän testin aina läpäisemisen (puuttuva väite, itsevarmennus, triviaali tarkistus)?Testi: [liitä testi tähän]
3) Testaa tietojen peittämisen ohjaus:
Sinulle antamani loki/tiedot voivat sisältää henkilökohtaisia tai luottamuksellisia kenttiä (sähköpostiosoite, nimi, kortti, avain, sisäinen osoite). Listaa ensin kentät, jotka täytyy peittää. Peitän sen ja lähetän sen uudelleen. Älä analysoi sitä sellaisena kuin se on.
4) Synteettisten testitietojen luominen:
Luo 20 riviä täysin kuvitteellista, realistista testidataa [seuraavalle kenttärakenteelle]. Älä käytä oikeita henkilö-/organisaatiotietoja. Sisällytä myös reunakirjaimet: tyhjä tila, liian pitkä teksti, raja-arvot, virheellinen muoto.
Heikko kehote / Vahva kehote
Heikko: "Kirjoita kokeita tälle koodille."
Vahva: "Laske tämä Kirjoitusyksikkötestit alennusfunktiolle. Hyväksymiskriteerit funktiolle: 10% alennus yli 1000 TL, 20% alennus yli 5000 TL; negatiivisen summan pitäisi antaa virhe. Määritä kommenttirivillä, mitä sääntöä validoitat kullekin testille. Testaa raja-arvot erikseen (999, 1000, 0,0,01, 0,0 -01). väitteet, jotka muuttuvat punaisiksi, jos rikon koodin tyhjäksi tai en kirjoita triviaalia väitettä."
Tehokas kehote; Se sisältää hyväksymiskriteerit, raja-arvot, validointiodotukset ja nimenomaiset huijauksen torjuntaohjeet. Heikko kehote kehottaa tekoälyä kirjoittamaan koristeellisen testin.
Yleisiä virheitä
- Vihreään luottaen. Ajattele, että kokeen läpäiseminen on todiste. Todellinen kysymys on: muuttuuko se punaiseksi, kun rikot koodin?
- Testin pyytäminen ilman syytä. Tekoäly tuottaa yleisiä, usein hyödyttömiä testejä tietämättä, mitä on tarkistettava.
- Vahvistuksen ohittaminen. Sanotaan "AI kirjoitti sen, se on luultavasti totta". Vastuu on tulosten käyttäjällä.
- Todellisten/arkaluonteisten tietojen liittäminen työkaluun. Työskentely tuotantotietojen, avainten tai henkilötietojen kanssa.
- Luvaton tietoturvatestaus. Yritetään loukkaavaa testausta ilman laajuutta ja lupaa.
- Tekoälyn käyttäminen päätöksenteon delegoimiseen. Kysymys "Voiko tämä versio julkaista?" tekoälylle ja laittamalla vastauksen allekirjoitukseen.
Yhteenvetona
Tekoäly on tehokas apulainen laadunvarmistusprosessissa, joka nopeuttaa toistuvaa ja tuotettavaa työtä; Mutta vastuu laatupäätöksestä on ihmisellä. Tekoälyn ykkösriski tässä ammatissa on pseudo-pass: vihreät testit, jotka näyttävät siistiltä, mutta eivät vahvista mitään. Testaa jokainen tekoälytesti murtamalla koodi tarkoituksella; Jos se ei muutu punaiseksi, testi on koriste. Sido se vaatimukseen, katso punainen, vie se kontekstisuodattimen läpi. Peitä luottamukselliset tiedot, suorita turvallisuustestejä vain valtuutettuihin ja puolustustarkoituksiin.
Sovellustehtävä
Tee 5 tekoälyn luomaa (tai tekoälyn luomaa) yksikkötestiä omasta projektistasi. Jokaiselle: (1) kirjoita yhteen lauseeseen, minkä käyttäytymisen se vahvistaa, (2) tarkoituksella murtaa ja ajaa testattava koodi ja huomioi kuinka moni muuttuu punaiseksi, (3) merkitse ne, jotka eivät muutu punaisiksi, "sisustustesteiksi" ja kirjoita ne uudelleen todellisella väitteellä. Laita tulos taulukkoon: testin nimi / sääntö se vahvisti / oliko se rikki, kun se on rikki / toiminta.
tarkistuslista
- [ ] Ennen työn luovuttamista esitin kysymyksen "mitä menetän, jos se menee pieleen?"
- [ ] Testasin jokaisen tekoälytestin rikkomalla koodin; Vaihdoin sen, joka ei muuttunut punaiseksi, oikealla testillä.
- [ ] Linkitin testitapaukset todellisiin vaatimuksiin/hyväksymiskriteereihin.
- [ ] Peittelin arkaluontoiset/todelliset tiedot antamatta niitä työkalulle; Käytin synteettistä dataa, jos mahdollista.
- [ ] Harkitsin tietoturvatestausta vain valtuutuksen puitteissa ja puolustustarkoituksiin.
- [ ] Jätin päätöksen "julkaistaanko versio" itselleni, en tekoälylle.