Voitot:
- Kyky suunnitella tekoälyn ja ihmisen hyväksyntäpisteiden roolia päästä päähän laadunvarmistusprosessissa ideasta julkaisuun CI/CD:n yhteydessä
- CI/CD:ssä ei anneta tekoälylle lupaa "läpäistä" testi automaattisesti, vaan sovelletaan rajoituksia luottamuksellisten tietojen ja avainten suojaamiseksi
- Kyky suorittaa tietoturvatestauksia viranomaisen puitteissa ja puolustustarkoituksessa sekä omaksua vastuullisen julkistamisen ja eettisen läpinäkyvyyden periaatteet.
Edellisessä kymmenessä yksikössä käytimme tekoälyä yksittäisissä tehtävissä: skenaarioiden luominen, automaatiokoodi, vikaraportointi, kattavuusanalyysi, mutaatiotestaukset. Tämä viimeinen yksikkö yhdistää ne kaikki yhdeksi vastuulliseen työnkulkuun. Nykyaikainen laadunvarmistus ei ole työtä, joka päättyy yhden henkilön pöydälle; Se on prosessi, joka elää CI/CD:ssä (Continuous Integration / Continuous Delivery – prosessi, jossa koodia yhdistetään jatkuvasti, testataan automaattisesti ja valmistetaan julkaistavaksi usein ja turvallisesti). Tekoäly voi koskettaa tämän prosessin jokaista vaihetta. Mutta kun tekoälyn voima kasvaa, sen vastuullisen käytön merkitys kasvaa: yksityisyys, auktoriteetti tietoturvatestauksessa, etiikka ja mikä tärkeintä, laatupäätöksen pitäminen ihmisen vastuulla. Tässä osiossa opit päästä päähän -kulkua ja rajoja.
Päästä päähän AI-käyttöinen laadunvarmistusvirta
Tekoälyn rooli ominaisuuden matkalla ideasta julkaisuun:
1. Vaatimusanalyysi. Tekoäly ilmoittaa vaatimuksen epäselvyydet ja puuttuvat hyväksymiskriteerit ("tämä sääntö ei kerro kuinka monta merkkiä salasana on vähimmäismäärä").
2. Testisuunnittelu. Skenaario- ja tapausluonnokset (yksikkö 2), reunatapaukset (yksikkö 3) ovat hyväksymiskriteereitä.
3. Automaatio. Unit (6), API (5) ja UI (4) testikoodiluonnokset; jokainen on vahvistettu mutaatiolla (10).
4. CI/CD-integrointi. Testit suoritetaan automaattisesti jokaisen koodin yhdistämisen yhteydessä. AI luonnostelee liukuhihnan konfiguraatiota (YAML), tekee yhteenvedon epäonnistuneiden testien lokeista ja ehdottaa mahdollista perimmäistä syytä.
5. Vapautuspäätös. Riskianalyysin (8) ja regression (9) tulokset kerätään, mutta asiantuntija päättää, voiko se onnistua.
6. Tuotannon seuranta ja palaute. Virheistä live-tilassa tulee tulevia testejä; Tekoäly ehdottaa regressiotapausta valmistusvirheestä.
Vinkki: Aseta tekoäly CI/CD:ssä kerrokseksi, joka "nopeuttaa ihmisten arvioimia luonnoksia" sen sijaan, että "kirjoittaisi testejä ja tekee päätöksiä". Mitään automaattisesti luotuja testejä ei saa päästää putkistoon ilman, että ihminen on tarkistanut ja hyväksynyt ne.
AI CI/CD:ssä: missä kyllä, missä ei
Vaihe
AI sopii
ihminen on välttämätön
Testikoodiluonnos
Kyllä
Revisio + mutaatio
YAML-luonnos
Kyllä
Todennus + salaisen avaimen tarkistus
Epäonnistui lokin yhteenveto
Kyllä
Perussyyn vahvistus
Hauras testidiagnoosi
Kyllä
Pysyvä ratkaisupäätös
"Voiko versio olla?"
ei
Asiantuntevaa harkintaa ja vastuuta
"Läpäise" testi automaattisesti
ei koskaan
—
Varoitus: Älä koskaan anna tekoälylle käskyä, kuten "korjaa se läpäisemään epäonnistunut testi" CI/CD:ssä. Tämä kumoaa testauksen tarkoituksen ja peittää virheet automaattisesti. AI voi selittää virheen, ehdottaa korjausta; mutta "testin vihreäksi maalaamisen" täytyy olla ihmisen tietoinen, perusteltu päätös.
Yksityisyys, tiedot ja turvallisuus: muuttumattomat rajat
Yksityisyys. Testiympäristössä todelliset asiakastiedot, tuotantotietokannan kopiot, API-avaimet ja sisäiset järjestelmätiedot ovat arkaluonteisia. Älä anna näitä julkisille tekoälytyökaluille. Henkilötietoihin sovelletaan KVKK:ta ja vastaavia määräyksiä; Maski lokit ja kuvakaappaukset. Käytä synteettistä (fiktiivistä) testidataa aina kun mahdollista.
Turvatestaus – puolustava ja valtuutettu. Tässä moduulissa opitut tietoturvatestit (valtuutus/IDOR-testit, tiedostojen latausrajat, syötteiden validointi) on tarkoitettu vain oman tuotteen testaamiseen kirjallisen valtuutuksen ja määritellyn laajuuden puitteissa. Tekoälyn käyttäminen jonkun toisen järjestelmän käyttämiseen ilman lupaa, todellisten haavoittuvuuksien aseistamiseen tai soveltamisalan ulkopuolisten testausten suorittamiseen on sekä epäeettistä että laitonta. Kun löydät tietoturvahaavoittuvuuden, noudata vastuullisen paljastamisen periaatetta – haavoittuvuuden pitäminen luottamuksellisena ja siitä ilmoittaminen asianomaiselle osapuolelle, jotta se voidaan korjata.
Etiikka ja avoimuus. Älä esitä tekoälyn tuottamia testejä omana työnäsi; Toteaminen, että käytät tekoälyä tiimissä, on läpinäkyvyyttä. Olet vastuussa tekoälyn tuottaman tulosteen epätarkkuudesta - "AI kirjoitti sen" ei ole tekosyy.
Heikko kehote / Vahva kehote
Heikko: "Määritä testiputki CI:lle."
Vahva: "Luonnos CI-työnkulku YAML GitHub Actionsille: suorita yksikkö + API-testejä jokaiselle PR:lle, luo kattavuusraportti, suorita mutaatiotestaus (Stryker) viikoittain. Älä upota salaisuuksia koodiin; käytä vain salaisuuksien viittausta. Estä yhdistäminen, jos testit ovat punaisia. Tämä on LUONNOS; Tarkastelen ja muokkaan salaisen avaimen hallintaa ja testausta, EI korjausta tai vahvistusta. "siirrä" -vaihe."
Tehokas kehote; Se asettaa rajoituksia luottamuksellisuudelle, ihmisen arvioinnille ja "ei automaattista testausta".
Neljä kopioitavaa mallia
1) Päästä päähän -testaussuunnitelma:
Tehtäväsi: vanhempi laadunvarmistusjohtaja. Laadi seuraavan ominaisuuden kattava testaussuunnitelma ideasta julkaisuun: [ominaisuus + hyväksymiskriteerit]. Vaiheet: vaatimusanalyysi (epävarmuustekijät), testisuunnittelu, automaatiotasot (yksikkö/API/UI), CI/CD-integrointi, julkaisupäätöksen kriteerit, tuotannon seuranta. Määritä tekoälyn ja IHMISEN hyväksymispisteiden rooli kussakin vaiheessa erikseen.
2) CI/CD-putkilinjan ääriviivat:
CI YAML-luonnos [GitHub Actions / GitLab CI / Azure Pipelines]: - Yksikkö + API-testi + laajuus PR:ssa - Estä yhdistäminen punaisella testillä - Salaiset arvot vain salaisuuksilla; upottaminen koodiinTämä on luonnos; Käyn läpi avainhallinta- ja hyväksymisvaiheet. Automaattisen korjauksen/läpäisytestin vaiheen lisääminen.
3) Epäonnistunut testilokin analyysi:
Tuossa CI-tulosteessa testit ovat punaisia. Tutki lokia; ryhmittele viat, erottele mahdollinen perimmäinen syy ja MIKÄ voi olla todellinen vika ja mikä voi olla hauras testi/ympäristöongelma. Jos on henkilötietoja, peitä ne. Päätös ja korjaus on minun. Loki: [liitä]
4) Turvallisuuden/yksityisyyden ennakkotarkastus:
Ennen kuin tämä testidata/loki lähetetään tekoälytyökaluun, tarkista: sisältääkö se henkilötietoja, API-avainta, sisäistä järjestelmäosoitetta, tuotantotietoja? Luettele, mitkä alueet, jos sellaisia on, täytyy peittää/poistaa. Käsittely sellaisenaan. Sisältö: [liitä]
kolme minilaukkua
Tapaus 1 – päästä päähän -virtauksen nopeus. Yksi tiimi käsitteli uutta "tilauksen uusimis"-ominaisuutta tekoälyllä toimivalla päästä päähän -virtauksella: vaatimusepävarmuudet ilmoitettiin etukäteen, laadittiin kolmikerroksiset testit ja vahvistettiin mutaatiot, sidottu CI:hen. Ominaisuus lyhensi testausjakson, joka kesti 5 päivää perinteisessä prosessissa, 2 päivään; mutta ihmisten hyväksyntä säilyi joka vaiheessa, ja vaatimusepävarmuus (mitä tapahtuu, jos päivitys epäonnistuu) suljettiin ennen liveä.
Tapaus 2 — Paluu avaimen vuodosta. Eräs kehittäjä sai tekoälyllä luomaan CI YAML:n, ja tekoäly upottaa aidon näköisen API-avaimen YAML:iin esimerkkinä. "Turvallisuus/yksityisyyden esitarkastus" -vaihe valloitti tämän; avain muutettu salaisuuksien viitteeksi. Ilman auditointivaihetta avain vuotaisi versionhallintaan (git-historiaan).
Tapaus 3 – Valtuutuksen raja. Eräs tiimin jäsen halusi soveltaa oppimaansa IDOR-testiä liikekumppanin live-järjestelmään "Olin utelias". Laadunvarmistusjohtaja pysähtyi: on laitonta suorittaa tietoturvatestauksia toisessa järjestelmässä ilman kirjallista lupaa ja määriteltyä laajuutta. Testaus tehtiin vain heidän omien tuotteidensa testiympäristössä valtuutetulla tavalla; Avoin vastuuhenkilö ilmoitettiin asianomaiselle tiimille.
Yleisiä virheitä
- Tekoälyn saaminen tekemään julkaisupäätöksiä. Kysymys "Voiko se vapauttaa?" tekoälylle ja laittaa vastauksen allekirjoituksen tilalle.
- Automaattisen testin "läpäiseminen". CI:ssä AI maalaa testi vihreäksi; virheiden peittämistä.
- Luottamuksellisten tietojen/avaimen antaminen ajoneuvoon. Tuotantotietojen, henkilötietojen tai API-avaimien jakaminen ilman valvontaa.
- Luvaton tietoturvatestaus. Hyökkääjien testaus toisessa järjestelmässä ilman laajuutta ja lupaa.
- Testien ottaminen käyttöön ilman tarkistusta. Suorita AI-luonnos automaattisesti ilman ihmisen hyväksyntää.
- Tekoälyn syyttäminen. Väärän tulosteen puolustaminen sanomalla "AI kirjoitti sen".
Yhteenvetona
Päästä päähän QA on prosessi, joka ulottuu vaatimuksista tuotannon seurantaan ja kestää CI/CD:ssä. Tekoäly tuottaa joka vaiheessa luonnoksia, tekee yhteenvedon lokista ja ehdottaa perimmäisiä syitä. Mutta rajat ovat muuttumattomat: ihmiset tekevät testauspäätöksiä ja vapauttavat hyväksynnän; Tekoälylle ei koskaan anneta oikeutta "läpäistä" testi automaattisesti; luottamukselliset tiedot ja avaimet eivät pääse ajoneuvoon; Turvatestaus suoritetaan vain omalle tuotteellesi, kirjallisen luvan ja määritellyn laajuuden puitteissa, puolustustarkoituksessa, ja havainnot raportoidaan vastuullisesti. Ole läpinäkyvä, kun käytät tekoälyä; Olet vastuussa tulosteen tarkkuudesta. AI kiihtyy; Takaat laadun ja eettisyyden.
Sovellustehtävä
Laadi suunnitelma ideasta julkaisuun "päästä päähän -testisuunnitelma" -mallin avulla oman projektisi ominaisuudelle; Merkitse tekoälyn ja ihmisen hyväksymispisteiden rooli erikseen kussakin vaiheessa. Luo sitten YAML, jossa on "CI/CD pipeline outline" ja käytä "suojaus/tietosuoja-esitarkistus" tähän YAML:ään tarkistaaksesi upotetun avaimen/salaisuuden tiedot. Lopuksi luettele kaikki "ihmisen päätöksen" kohdat suunnitelmassasi ja perustele yhdellä lauseella, miksi näitä päätöksiä ei voida delegoida tekoälylle.
tarkistuslista
- [ ] Pidän julkaisu- ja testauspäätökset ihmisen hyväksynnällä; En luovuttanut sitä AI:lle.
- [ ] CI/CD:ssä en antanut tekoälylle lupaa automaattisesti "läpäistä/korjata" testiä.
- [ ] Tarkastin ja peitin luottamukselliset tiedot, henkilötiedot ja avaimet ennen niiden lähettämistä ajoneuvoon.
- [ ] Olen harkinnut vain oman tuotteeni tietoturvatestausta kirjallisen luvan ja laajuuden puitteissa.
- [ ] Ratkaisin löydetyt haavoittuvuudet vastuullisen paljastamisen periaatteella.
- [ ] Sanoin avoimesti, että käytin tekoälyä ja pidin itseäni vastuussa tulosteen tarkkuudesta.
Moduulin tentti
1. Miten "false pass" määritellään tarkimmin laadunvarmistuskontekstissa?
- A) Vaikka testi muuttuu vihreäksi, se ei varsinaisesti vahvista toimintaa; ✔ Ei muutu punaiseksi, vaikka koodi olisi vioittunut
- B) Testi toimii hyvin hitaasti ja aikakatkaisee.
- C) Testi havaitsee todellisen virheen ja muuttuu punaiseksi
- D) Testi suoritetaan vain tuotantoympäristössä
Selitys: Pseudohyväksytty on, kun testi sanoo "hyväksytty", mutta ei varsinaisesti vahvista mitään merkityksellistä; Testi on vihreä, mutta vaikka ohjelmisto olisi viallinen, se ei saa sitä kiinni. Tämä on ykkönen tekoälyn riski laadunvarmistuksessa, koska tekoäly tuottaa yleensä siistiltä näyttäviä, mutta onttoja testejä.
2. Mikä on tekoälyn tarkin paikannus testaus- ja laadunvarmistusprosessissa?
- A) Tekoäly voi päättää, voidaanko versio julkaista ilman ihmisen hyväksyntää
- B) Tekoäly on apulainen, joka luo luonnoksia ja ideoita; Päätös ja vastuu 'on valmis julkaistavaksi' kuuluu asiantuntijalle ✔
- C) Tekoäly kirjoittaa vain tekstiä eikä pysty käsittelemään testikoodia ollenkaan
- D) Tekoäly kirjoittaa aina oikean testin kuin ihminen, joten tarkistus on tarpeeton
Kuvaus: Tekoäly on testausavustaja, luonnosgeneraattori ja ideoiden kertoja; tuottaa testiskenaarioita, automaatiokoodia ja raporttiluonnoksia. Laatupäätösten, kuten "onko tämä ohjelmisto valmis julkaistavaksi" tai "onko tämä testi läpäissyt", vastuu ja lopullinen hyväksyntä kuuluu kuitenkin toimivaltaiselle asiantuntijalle.
3. Perustuen siihen, että virheet esiintyvät enimmäkseen kynnysarvoilla, mikä testisuunnittelutekniikka on testata 17, 18 ja 19 erikseen 18 vuoden ikärajalle?
- A) Tilasiirtymätesti
- B) Päätöstaulukko
- C) Raja-arvoanalyysi ✔
- D) Tutkiva testaus
Selitys: Raja-arvoanalyysi perustuu havaintoon, jonka mukaan virheitä esiintyy useimmiten rajoilla, ja testaa kynnysarvot (juuri rajan alapuolella, juuri yläpuolella ja yläpuolella) erikseen. Se on tehokas tekniikka, joka täydentää ekvivalenssiluokkia.
4. Mitä lähestymistapaa tulisi suosia elementtien valinnassa keinoälyllä tuotetun käyttöliittymätestin automaatiokoodin haurauden vähentämiseksi?
- A) Käytä pisintä mahdollista XPath-polkua
- B) Elementin valinta sen pikselin sijainnin mukaan näytöllä
- C) CSS-luokan nimiin perustuvien valitsimien käyttäminen
- D) Testaukseen lisättyjen stabiilien attribuuttien (data-testid) käyttö ✔
Selitys: Pitkät XPath-polut ja CSS-luokan nimet ovat erittäin riippuvaisia sivun rakenteesta ja suunnittelusta. Se katkeaa pienimmässäkin käyttöliittymämuutoksessa. Suunnittelumuutokset eivät vaikuta erityisesti testausta varten lisättyihin vakaisiin määritteisiin (esim. data-testid), ja ne tekevät testeistä kestäviä.
5. Miksi API-testin pelkkä HTTP-tilakoodin (esim. 200) tarkistaminen ei riitä?
- A) Koska kehotiedot, joissa on oikea tilakoodi, voivat vioittua, eikä pelkkä tilantarkistus selvitä tätä (pseudoluottamus) ✔
- B) Koska tilakoodit eivät ole luotettavia API-testeissä
- C) Koska tilakoodin tarkistus hidastaa testiä paljon
- D) Koska tilakoodia ei koskaan palauteta API-testeissä
Selitys: Vaikka palvelin palauttaa oikean tilakoodin, se saattaa palauttaa vioittuneita tietoja rungossa (väärä tyyppi, puuttuva kenttä, väärin laskettu arvo). Vain tilannetta tarkasteleva testi ei näe tätä ja antaa väärää luottamusta. Joten skeeman/sopimuksen ja liiketoimintasäännön validointi tulisi myös lisätä.
6. Miksi on tärkeää käskeä AI:ta "laskemaan odotusarvo manuaalisesti hyväksymissäännön mukaisesti, älä viittaa funktion nykyiseen ulostuloon" tulostettaessa yksikkötestejä?
- A) Koska manuaalinen laskenta suorittaa testit nopeammin
- B) Koska muuten testi hyväksyy koodin nykyisen (ehkä bugisen) käyttäytymisen 'oikeaksi' ja vahvistaa vian ✔
- C) Koska tekoäly ei voi laskea desimaalilukuja ollenkaan
- D) Koska hyväksymissääntöjä ei koskaan käytetä testeissä
Selitys: Jos tekoäly saa odotetun arvon testattavan toiminnon lähdöstä, se antaa testin "läpäisemään", vaikka toiminto olisi viallinen; Eli mitä tahansa koodi tuottaa, testi lasketaan todeksi. Odotetun arvon laskeminen hyväksymissäännöstä riippumatta varmistaa, että testi on säännön portinvartija, ei koodin peili.
7. Mikä seuraavista on hyvän virheraportin erottuvin piirre?
- A) Olla mahdollisimman pitkä ja tekninen
- B) Tekoälyn kirjoittama
- C) Sisältää deterministisiä toistovaiheita, joita kehittäjä voi seurata itsenäisesti ja aiheuttaa virheen ✔
- D) Se on vain kuvakaappaus
Selitys: Virheraportin todellinen arvo on, että kehittäjä voi toistaa vian ilman apuasi. Deterministiset, jäljitettävät toistovaiheet alusta alkaen varmistavat tämän; Jos nämä vaiheet puuttuvat, raportti usein sulkeutuu "ei voitu tuottaa".
8. Mikä on tarkin ilmaus vakavuuden ja prioriteetin väliselle suhteelle yrityksen nimen väärinkirjoitusvirheessä kotisivulla?
- A) Intensiteetillä ja prioriteetilla tulee aina olla sama arvo
- B) Tämän virheen vakavuus ja prioriteetti ovat ehdottomasti alhaiset
- C) Vakavuus ja prioriteetti ovat sama käsite, yksi tarra riittää
- D) Tekninen intensiteetti voi olla alhainen, mutta liiketoiminnan prioriteetti (maine) voi olla korkea; Näitä kahta arvioidaan eri tavalla ✔
Selitys: Vakavuus on virheen tekninen vaikutus (teknisesti pieni kirjoitusvirhe), prioriteetti on se, kuinka nopeasti se on korjattava (korkea, koska se on maine-elementti, jonka jokainen vierailija näkee). Nämä kaksi eivät aina mene samaan suuntaan; Tämä esimerkki on matalan vakavuuden ja korkean prioriteetin tilanne.
9. Mikä on tarkin tulkinta testisarjasta, jonka linjapeitto on 90 %?
- A) Se osoittaa, että rivit suoritetaan, mutta se ei todista, että ne toimivat oikein; ✔ Korkea peitto voi antaa väärää luottamusta
- B) Todistaa vakuuttavasti, että 90% ohjelmistosta on virheetön
- C) Se on ehdoton mitta erinomaisesta testilaadusta.
- D) Ilmaisee, että lisäkokeita ei enää tarvitse kirjoittaa
Selitys: Rivien peitto osoittaa, että vain rivit suoritettiin; Se ei todista, että se tuottaa oikeita tuloksia. Jopa vakuuttamattomilla testeillä voidaan saavuttaa 90 % kattavuus. Laajuus on "ei koskaan katsonut minne" -kartta, ei "kaikki on testattu" -vakuutus; todellinen suoja mitataan mutaatiotestauksella.
10. Miten riskiperusteisessa testauksessa ominaisuuden riski lasketaan ohjaamaan rajoitettua testaustyötä?
- A) Vain koodirivien lukumäärän mukaan
- B) Kertomalla epäonnistumisen todennäköisyys ja sen rikkoutuessa ilmenevä vaikutus ✔
- C) Vain siinä järjestyksessä, jossa ominaisuus kehitettiin
- D) Priorisoi vain se ominaisuus, jolle on helpoin kirjoittaa testejä
Selitys: Riskiperusteisessa testauksessa riskiä arvioidaan todennäköisyydellä = todennäköisyys (erittelyn todennäköisyys) × vaikutus (vaurio jos rikkoutuu). Suuren todennäköisyyden ja suuren vaikutuksen verkkotunnukset (maksu, todennus) ansaitsevat intensiivisimmän testauksen, kun taas matala × matala -alueet saavat kevyttä testausta.
11. Mikä on suurin riski, jos testiin lisätään uudelleenyritys, joka joskus onnistuu ja joskus epäonnistuu (hauras/hilseilevä), vaikka koodi ei ole muuttunut?
- A) Testin suoritusajan lyhentäminen
- B) Vähentää peittoprosenttia
- C) Todellisen samanaikaisuusvirheen tai perimmäisen syyn peittäminen ja oireen tukahduttaminen ✔
- D) Testin nimen muuttaminen
Selitys: Retry on diagnostinen työkalu, ei hoito. Päättämättömyys johtuu usein todellisesta rodusta tai riippuvuudesta; Testin läpäiseminen uudelleen yrittämällä peittää tämän todellisen virheen ja voi aiheuttaa vakavia ongelmia live-tilassa. Perimmäinen syy on löydettävä ensin.
12. Miten mutaatiotestaus, rehellisin tapa mitata, suojaako testisarja todella, toimii?
- A) Mittaamalla testien kulkunopeutta
- B) Laskemalla kuinka monta koodiriviä kirjoitettiin
- C) Suorittamalla testit eri järjestyksessä
- D) Luomalla tietoisesti pieniä katkoksia koodiin ja mittaamalla, saavatko testit ne kiinni ✔
Kuvaus: Mutaatiotestaus tuottaa pieniä tahallisia vääristymiä (mutaatioita) lähdekoodiin; Hyvän testisarjan pitäisi saada nämä vääristymät kiinni ja muuttua punaiseksi. Mutaatiot, joita ei saada kiinni (selviytyivät), osoittavat, että testit eivät säilytä tätä käyttäytymistä. Mutaatiopisteet ovat paljon rehellisempi laadun mitta kuin prosenttiosuus.
13. Mikä on pääasiallinen rajoitus, jota on noudatettava suoritettaessa tietoturvatestauksia (esim. valtuutus-/IDOR-testejä)?
- A) Se tulisi tehdä vain omalle tuotteelleen, kirjallisen luvan ja määritellyn laajuuden puitteissa, puolustustarkoituksessa ✔
- B) Sitä voidaan vapaasti soveltaa mihin tahansa kiinnostavaan järjestelmään
- C) Sitä voidaan kokeilla liikekumppaneiden reaaliaikaisissa järjestelmissä ilman lupaa
- D) Kaikki löydetyt haavoittuvuudet tulee julkaista välittömästi.
Kuvaus: Tässä moduulissa opitut turvatestit on tarkoitettu vain oman tuotteen testaamiseen puolustustarkoituksessa kirjallisen luvan ja määritellyn laajuuden puitteissa. Toisen järjestelmän käyttäminen ilman lupaa tai soveltumattomien testausten suorittaminen on sekä epäeettistä että laitonta. Kaikista löydetyistä haavoittuvuuksista ilmoitetaan vastuullisen paljastamisen kautta.
14. Mitä valtuuksia ei koskaan pitäisi antaa tekoälylle CI/CD-putkessa?
- A) Epäonnistuneiden testilokien yhteenveto
- B) Oikeus automaattisesti "läpäistä" epäonnistunut (punainen) testi tai maalata se vihreäksi ✔
- C) Testikoodiluonnoksen ehdottaminen
- D) YAML-tiedoston luonnos
Kuvaus: AI voi tuottaa testikoodin ääriviivat, liukuhihnan YAML:n ja lokiyhteenvedon CI/CD:llä; Mahdollisuutta läpäistä/korjata epäonnistunut testi ei kuitenkaan koskaan tulisi antaa. Tämä kumoaa testauksen tarkoituksen ja peittää virheet automaattisesti. Testin vihreäksi maalaamisen tulee olla ihmisen tietoinen ja perusteltu päätös.