Pelnas:
- Gebėjimas sukurti dirbtinio intelekto ir žmogaus patvirtinimo taškų vaidmenį galutinio kokybės užtikrinimo sraute nuo idėjos iki išleidimo CI / CD kontekste
- CI / CD neleidžia AI automatiškai „išlaikyti“ testo, bet taiko apribojimus, kad apsaugotų konfidencialius duomenis ir raktus
- Gebėjimas atlikti saugumo testus valdžios ir gynybos tikslais bei laikytis atsakingo atskleidimo ir etinio skaidrumo principų.
Ankstesniuose dešimtyje vienetų AI naudojome atliekant atskiras užduotis: scenarijų generavimą, automatizavimo kodą, klaidų ataskaitų teikimą, aprėpties analizę, mutacijų testavimą. Šis galutinis blokas sujungia juos į vieną atsakingą darbo eigą. Šiuolaikinis kokybės užtikrinimas nėra darbas, kuris baigiasi prie vieno žmogaus stalo; Tai procesas, vykstantis CI/CD (Continuous Integration / Continuous Delivery – vamzdynas, kuriame kodas nuolat derinamas, automatiškai tikrinamas ir ruošiamas publikuoti dažnai ir saugiai). AI gali paliesti kiekvieną šio proceso etapą. Tačiau augant dirbtinio intelekto galiai, didėja ir atsakingo jo naudojimo svarba: privatumas, autoritetas atliekant saugumo testavimą, etika ir, svarbiausia, priimti sprendimą dėl kokybės priklauso nuo žmogaus. Šiame skyriuje jūs išmoksite srauto iki galo ir ribų.
Nuo galo iki galo DI maitinamas QA srautas
AI vaidmuo funkcijos kelionėje nuo idėjos iki išleidimo:
1. Reikalavimų analizė. AI pažymi reikalavimo neaiškumus ir trūkstamus priėmimo kriterijus („ši taisyklė nenurodo, kiek slaptažodžio simbolių turi būti minimalus“).
2. Bandymo dizainas. Scenarijų ir atvejo juodraščiai (2 skyrius), kraštiniai atvejai (3 skyrius) yra tarp priėmimo kriterijų.
3. Automatika. Vieneto (6), API (5) ir UI (4) testavimo kodo juodraščiai; kiekvieną patvirtina mutacija (10).
4. CI/CD integravimas. Testai vykdomi automatiškai kiekvieną kartą sujungiant kodą. AI parengia dujotiekio konfigūraciją (YAML), apibendrina nepavykusių bandymų žurnalus, siūlo galimas pagrindines priežastis.
5. Sprendimas paleisti. Surenkami rizikos analizės (8) ir regresijos (9) rezultatai, tačiau ekspertas nusprendžia, ar tai gali būti sėkminga.
6. Gamybos stebėjimas ir grįžtamasis ryšys. Klaidos gyvai tampa ateities išbandymais; AI siūlo regresijos atvejį dėl gamybos defekto.
Patarimas: AI nustatykite kaip CI / CD sluoksnį, kuris „spartina žmonių peržiūrėtus juodraščius“, o ne „rašo testus ir priima sprendimus“. Jokie automatiškai sugeneruoti testai neturėtų patekti į dujotiekį be žmogaus peržiūros ir patvirtinimo.
AI CI/CD: kur taip, kur ne
Scena
AI tinka
žmogus yra būtinas
Bandymo kodo juodraštis
Taip
Revizija + mutacija
Dujotiekio YAML projektas
Taip
Autentifikavimas + slaptojo rakto patikrinimas
Žurnalo suvestinė nepavyko
Taip
Pagrindinės priežasties patvirtinimas
Trapi testo diagnozė
Taip
Nuolatinis sprendimo sprendimas
– Ar gali būti versija?
ne
Ekspertinis sprendimas ir atsakomybė
Automatiškai „išlaikyti“ testą
niekada
—
Atsargiai: niekada nesuteikite dirbtiniam intelektui įpareigojimo, pvz., „pataisyti, kad išlaikytų nesėkmingą testą“ CI / CD. Tai pažeidžia testavimo tikslą ir automatiškai uždengia klaidas. AI gali paaiškinti klaidą, pasiūlyti pataisymą; bet „testo dažymas žaliai“ turi būti sąmoningas, argumentuotas žmogaus sprendimas.
Privatumas, duomenys ir saugumas: nekeičiamos ribos
Privatumas. Bandomojoje aplinkoje faktiniai klientų duomenys, gamybos duomenų bazės kopijos, API raktai ir vidinė sistemos informacija yra jautrūs. Neperduokite jų viešiesiems AI įrankiams. Asmens duomenims taikomos KVKK ir panašios normos; Užmaskuoti žurnalus ir ekrano kopijas. Jei įmanoma, naudokite sintetinius (išgalvotus) bandymo duomenis.
Saugumo testas – gynybinis ir įgaliotas. Šiame modulyje išmokti saugos testai (autorizacijos / IDOR testai, failų įkėlimo ribos, įvesties patvirtinimas) yra skirti tik jūsų gaminiui išbandyti pagal raštišką leidimą ir apibrėžtą sritį. Naudoti dirbtinį intelektą norint be leidimo pasiekti kažkieno sistemą, ginkluoti tikrus pažeidžiamumus arba atlikti testus, kurie neatitinka taikymo srities, yra neetiška ir neteisėta. Radę saugos pažeidžiamumą, laikykitės atsakingo atskleidimo principo – saugokite pažeidžiamumą konfidencialiai ir praneškite apie tai atitinkamai šaliai, kad ją būtų galima ištaisyti.
Etika ir skaidrumas. Nepristatykite AI sukurtų testų kaip savo darbo; Nurodymas, kad komandoje naudojate AI, yra skaidrumas. Jūs esate atsakingas už AI sukurtos išvesties netikslumą – „AI parašė tai“ nėra pasiteisinimas.
Silpnas raginimas / Stiprus raginimas
Silpnas: „Nustatykite CI bandomąjį dujotiekį“.
Stiprus: "Sukurkite CI darbo eigos YAML projektą, skirtą GitHub Actions: vykdykite vieneto + API testus kiekviename PR, generuokite aprėpties ataskaitą, kas savaitę vykdykite mutacijų testavimą (Stryker). Neįterpkite paslapčių į kodą; naudokite tik paslapčių nuorodą. Blokuokite sujungimą, jei testai yra raudoni. Tai yra JUODRAŠTIS; Aš peržiūrėsiu ir redaguosiu slaptojo rakto valdymo ir tikrinimo veiksmus, NEGALIMA taisyti. „migracijos“ žingsnis“.
Galingas raginimas; Ji nustato konfidencialumo, žmogaus peržiūros ir „jokio automatizuoto testavimo“ apribojimus.
Keturi kopijuojami šablonai
1) Nuolatinio testavimo planas:
Jūsų vaidmuo: vyresnysis kokybės užtikrinimo vadovas. Sudarykite šios funkcijos galutinio testavimo planą nuo idėjos iki leidimo: [funkcija + priėmimo kriterijai]. Fazės: reikalavimų analizė (neapibrėžtumai), bandymo dizainas, automatizavimo sluoksniai (įrenginys / API / vartotojo sąsaja), CI / kompaktinio disko integravimas, išleidimo sprendimo kriterijai, gamybos stebėjimas. Nurodykite AI ir ŽMOGAUS patvirtinimo taškų vaidmenį kiekviename etape atskirai.
2) CI / CD dujotiekio kontūras:
CI YAML juodraštis, skirtas [GitHub Actions / GitLab CI / Azure Pipelines]: - vienetas + API testas + apimtis PR - Neleiskite sujungti raudonos spalvos bandymo - Slaptos reikšmės tik su paslaptimis; įterpimas į kodąTai juodraštis; Peržiūrėsiu pagrindinius valdymo ir patvirtinimo veiksmus. Pridedamas automatinio taisymo / išlaikymo bandymo veiksmas.
3) Nepavykusio bandymo žurnalo analizė:
Tame CI spaudinyje testai yra raudoni. Išnagrinėti žurnalą; sugrupuokite gedimus, atskirkite galimą pagrindinę priežastį ir KURI gali būti tikroji gedimas ir kuri gali būti trapi bandymo/aplinkos problema. Jei yra asmens duomenų, užmaskuokite juos. Sprendimas ir pataisymas bus mano. Žurnalas: [įklijuoti]
4) Išankstinė saugos / privatumo patikra:
Prieš siunčiant šiuos bandymo duomenis / žurnalą į AI įrankį, patikrinkite: ar jame yra asmens duomenų, API rakto, vidinio sistemos adreso, gamybos duomenų? Išvardykite, kurias sritis, jei tokių yra, reikia užmaskuoti / pašalinti. Apdorojimas toks, koks yra. Turinys: [įklijuoti]
trys mini dėklai
1 atvejis – srauto nuo galo iki galo greitis. Viena komanda sprendė naują „prenumeratos atnaujinimo“ funkciją, naudodama AI valdomą tiesioginį srautą: reikalavimų neapibrėžtumai buvo pažymėti iš anksto, parengti trijų sluoksnių testai ir patvirtinti mutacijos, susieti su CI. Ši funkcija sumažino testavimo ciklą, kuris įprastu būdu truko 5 dienas, iki 2 dienų; bet žmogaus pritarimas buvo išsaugotas kiekviename etape, o reikalavimų neapibrėžtumas (kas atsitiks, jei nepavyks atnaujinti) buvo uždarytas prieš pradedant naudoti.
2 atvejis – grįžimas iš rakto nuotėkio. Kūrėjas AI sugeneravo CI YAML, o AI kaip pavyzdį į YAML įdėjo realiai atrodantį API raktą. „Išankstinis saugumo / privatumo patikrinimas“ tai užfiksavo; raktas konvertuotas į paslapčių nuorodą. Be audito žingsnio raktas nutekėtų į versijos valdymą (git istoriją).
3 atvejis. Įgaliojimų ribos. Komandos narys išmoktą IDOR testą norėjo pritaikyti verslo partnerio tiesioginėje sistemoje iš „man buvo įdomu“. Kokybės užtikrinimo vadovas sustojo: atlikti saugumo testavimą kitoje sistemoje be raštiško leidimo ir apibrėžtos apimties yra neteisėta. Testavimas buvo atliktas tik jų pačių gaminių testavimo aplinkoje, turint įgaliojimus; Atvira atsakinga šalis buvo informuota atitinkamai komandai.
Dažnos klaidos
- Priversdamas dirbtinį intelektą priimti sprendimus dėl išleidimo. Užduodamas klausimą "Ar jį galima išleisti?" į AI ir įdėkite atsakymą vietoje parašo.
- Automatinio testo „išlaikymas“. CI atveju, kai AI nudažo testą žaliai; klaidų dangstymas.
- Konfidencialių duomenų / automobilio rakto suteikimas. Gamybos duomenų, asmeninių duomenų ar API raktų bendrinimas be priežiūros.
- Neteisėtas saugumo patikrinimas. Užpuoliko bandymai kitoje sistemoje be apimties ir leidimo.
- Bandymų įvedimas į dujotiekį be peržiūros. Automatiškai paleiskite AI eskizą be žmogaus sutikimo.
- Kaltinti AI. Neteisingo išvesties gynimas sakydamas „AI parašė“.
Apibendrinant
Visapusiškas kokybės užtikrinimas yra procesas, apimantis nuo reikalavimų iki gamybos stebėjimo ir gyvavimo CI / CD; Kiekviename etape AI sukuria juodraščius, apibendrina žurnalą ir siūlo pagrindines priežastis. Tačiau ribos yra nekeičiamos: žmonės priima bandymo sprendimus ir išleidžia patvirtinimą; AI niekada nesuteikiama teisė automatiškai „išlaikyti“ testą; į transporto priemonę nepatenka konfidencialūs duomenys ir raktai; Saugumo bandymai atliekami tik jūsų gaminiui, laikantis raštiško įgaliojimo ir apibrėžtos apimties, gynybos tikslais, o apie išvadas pranešama atsakingai atskleidžiant. Būkite skaidrūs, kai naudojate AI; Jūs esate atsakingi už išvesties tikslumą. AI pagreitina; Jūs garantuojate kokybę ir etiką.
Taikymo užduotis
Sukurkite planą nuo idėjos iki leidimo, naudodami „visiško bandymo plano“ šabloną savo projekto funkcijai; Kiekviename etape atskirai pažymėkite AI ir žmogaus patvirtinimo taškų vaidmenį. Tada sugeneruokite YAML su „CI / CD konvejeriu“ ir šiam YAML pritaikykite „saugumo / privatumo išankstinį patikrinimą“, kad patikrintumėte, ar nėra įterptųjų raktų / slaptų duomenų. Galiausiai išvardykite visus „žmogaus sprendimų“ punktus savo plane ir vienu sakiniu pagrįskite, kodėl šių sprendimų negalima deleguoti AI.
kontrolinis sąrašas
- [ ] Išleidimo ir bandymo sprendimus priskiriu žmogaus patvirtinimui; Aš jo neperdaviau AI.
- [ ] CI/CD nesudaviau AI leidimo automatiškai „išlaikyti/pataisyti“ testo.
- [ ] Patikrinau ir užmaskavau konfidencialius duomenis, asmens duomenis ir raktus prieš siųsdamas juos į transporto priemonę.
- [ ] Apsvarsčiau tik savo gaminio saugos testavimą pagal raštišką leidimą ir apimtį.
- [ ] Aptiktas spragas sprendžiau taikydamas atsakingo atskleidimo principą.
- [ ] Aš aiškiai pareiškiau, kad naudojau AI, ir laikiau save atsakinga už išvesties tikslumą.
Modulio egzaminas
1. Kaip „klaidinga atitiktis“ tiksliausiai apibrėžiama kokybės užtikrinimo kontekste?
- A) Nors testas tampa žalias, jis iš tikrųjų nepatvirtina jokio elgesio; ✔ Netampa raudona, net jei kodas sugadintas
- B) Bandymas vyksta labai lėtai ir baigiasi laikas.
- C) Testas aptinka tikrą klaidą ir tampa raudonas
- D) Bandymas vykdomas tik gamybinėje aplinkoje
Paaiškinimas: pseudo patvirtinimas yra tada, kai testas sako „išlaikytas“, bet iš tikrųjų nepatvirtina nieko reikšmingo; Testas yra žalias, bet net jei programinė įranga yra sugedusi, ji jo nepagaus. Tai yra didžiausia AI rizika kokybės užtikrinime, nes DI paprastai atlieka testus, kurie atrodo tvarkingi, bet yra tuščiaviduriai.
2. Koks yra tiksliausias dirbtinio intelekto pozicionavimas testavimo ir kokybės užtikrinimo procese?
- A) Dirbtinis intelektas gali nuspręsti, ar versija gali būti išleista be žmogaus sutikimo
- B) Dirbtinis intelektas yra asistentas, generuojantis juodraščius ir idėjas; Sprendimas ir atsakomybė „ar paruošta publikuoti“ priklauso ekspertui ✔
- C) Dirbtinis intelektas rašo tik tekstą ir visiškai negali susidoroti su testiniu kodu
- D) Dirbtinis intelektas visada rašo teisingą testą nei žmogus, todėl peržiūra nereikalinga
Aprašymas: Dirbtinis intelektas yra testavimo asistentas, juodraščių generatorius ir idėjų daugiklis; gamina bandymų scenarijus, automatizavimo kodą ir ataskaitų juodraščius. Tačiau atsakomybė ir galutinis sprendimų dėl kokybės patvirtinimas, pvz., „ar ši programinė įranga paruošta publikavimui“ arba „ar šis testas išlaikytas“, priklauso kompetentingam ekspertui.
3. Atsižvelgiant į tai, kad klaidos dažniausiai pasitaiko esant ribinėms vertėms, kuri bandymo projektavimo technika yra 17, 18 ir 19 atskirai tikrinti 18 metų amžiaus ribą?
- A) Būsenos perėjimo testas
- B) Sprendimų lentelė
- C) Ribinės vertės analizė ✔
- D) tiriamasis bandymas
Paaiškinimas: ribinių verčių analizė pagrįsta pastebėjimu, kad klaidos dažniausiai pasitaiko ties ribomis, ir atskirai tikrinamos slenkstinės vertės (šiek tiek žemiau, kiek aukščiau ir šiek tiek virš ribos). Tai galinga technika, papildanti lygiavertiškumo klases.
4. Kuriam požiūriui turėtų būti teikiama pirmenybė renkantis elementus, siekiant sumažinti UI testavimo automatizavimo kodo, sukurto naudojant dirbtinį intelektą, pažeidžiamumą?
- A) Naudojant ilgiausią galimą XPath kelią
- B) Elemento pasirinkimas pagal jo pikselių padėtį ekrane
- C) Selektorių naudojimas pagal CSS klasių pavadinimus
- D) Testavimui pridėtų stabilių atributų (data-testid) naudojimas ✔
Paaiškinimas: Ilgi XPath keliai ir CSS klasių pavadinimai labai priklauso nuo puslapio struktūros ir dizaino; Jis sugenda po menkiausio sąsajos pakeitimo. Stabilūs atributai, pridėti specialiai testavimui (pvz., data-testid), neturi įtakos dizaino pakeitimams, todėl testai yra patikimi.
5. Kodėl API testui nepakanka tik patikrinti HTTP būsenos kodą (pvz., 200)?
- A) Kadangi kūno duomenys su teisingu būsenos kodu gali būti sugadinti ir vien tik būsenos patikra to nepastebės (pseudo pasitikėjimas) ✔
- B) Kadangi būsenos kodai nėra patikimi API testuose
- C) Kadangi būsenos kodo tikrinimas labai sulėtina testą
- D) Kadangi būsenos kodas niekada nepateikiamas atliekant API testus
Paaiškinimas: Nors serveris pateikia teisingą būsenos kodą, jis gali grąžinti sugadintus duomenis (netinkamo tipo, trūksta lauko, neteisingai apskaičiuota reikšmė). Testas, kuris žiūri tik į situaciją, to nemato ir suteikia klaidingą pasitikėjimą. Taigi taip pat reikėtų pridėti schemos / sutarties ir verslo taisyklių patvirtinimą.
6. Kodėl labai svarbu nurodyti AI „rankiniu būdu apskaičiuoti numatomą vertę pagal priėmimo taisyklę, neatsižvelgti į esamą funkcijos išvestį“, kai spausdinami vienetai?
- A) Nes rankinis skaičiavimas greičiau atlieka testus
- B) Nes priešingu atveju testas priima dabartinį (galbūt klaidingą) kodo elgesį kaip „teisingą“ ir patvirtina klaidą ✔
- C) Nes dirbtinis intelektas išvis negali apskaičiuoti dešimtainių skaičių
- D) Kadangi priėmimo taisyklės niekada nenaudojamos testuose
Paaiškinimas: jei AI išveda laukiamą vertę iš bandomosios funkcijos išvesties, testą „išlaikys“, net jei funkcija yra sugedusi; Tai yra, kad ir koks kodas būtų sukurtas, testas laikomas teisingu. Tikėtinos vertės apskaičiavimas nepriklausomai nuo priėmimo taisyklės užtikrina, kad testas yra taisyklės sergėtojas, o ne kodo veidrodis.
7. Kuris iš toliau nurodytų dalykų yra ryškiausias gero pranešimo apie klaidas bruožas?
- A) Kad būtų kuo ilgesnis ir techniškesnis
- B) Parašyta dirbtinio intelekto
- C) Yra deterministinių atkūrimo veiksmų, kuriuos kūrėjas gali atlikti savarankiškai ir sukelti klaidą ✔
- D) Tai tik ekrano kopija
Paaiškinimas: tikroji pranešimo apie riktą vertė yra ta, kad kūrėjas gali atkurti klaidą be jūsų pagalbos. Tai užtikrina deterministiniai, atsekami atkūrimo žingsniai nuo nulio; Jei šių veiksmų nėra, ataskaita dažnai uždaroma kaip „nepavyko parengti“.
8. Kokia yra tiksliausia sunkumo ir prioriteto santykio išraiška, kai pagrindiniame puslapyje klaidingai parašytas įmonės pavadinimas?
- A) Intensyvumas ir prioritetas visada turi būti vienodi
- B) Šios klaidos sunkumas ir prioritetas yra tikrai žemi
- C) Sunkumas ir prioritetas yra ta pati sąvoka, užtenka vienos etiketės
- D) Techninis intensyvumas gali būti mažas, bet verslo prioritetas (reputacija) gali būti didelis; Jie abu vertinami skirtingai ✔
Paaiškinimas: Klaidos sunkumas yra techninis klaidos poveikis (spausdinimo klaida techniškai maža), prioritetas – kaip skubiai ją reikia ištaisyti (didelis, nes tai reputacijos elementas, kurį mato kiekvienas lankytojas). Abu ne visada eina ta pačia kryptimi; Šis pavyzdys yra mažo sunkumo ir didelio prioriteto situacija.
9. Kuris yra tiksliausias testų rinkinio, kai linijos aprėptis yra 90 %, interpretacija?
- A) Tai rodo, kad eilutės vykdomos, bet neįrodo, kad jos elgiasi teisingai; ✔ Didelė aprėptis gali suteikti klaidingą pasitikėjimą
- B) Įtikinamai įrodo, kad 90% programinės įrangos yra be klaidų
- C) Tai yra galutinis puikios bandymo kokybės matas.
- D) Nurodo, kad jokių papildomų testų rašyti nebereikia
Paaiškinimas: eilutės aprėptis rodo, kad buvo vykdomos tik eilutės; Tai neįrodo, kad duoda teisingų rezultatų. Net ir atliekant nenuoseklius testus, galima pasiekti 90 % aprėptį. Taikymo sritis yra žemėlapis „niekada nežiūrėjau kur“, o ne „viskas išbandyta“ garantija; tikroji apsauga matuojama mutacijų testavimu.
10. Kaip apskaičiuojama rizika, kad funkcijos rizika nukreipiama į ribotas testavimo pastangas atliekant rizika pagrįstą testavimą?
- A) Tik pagal kodo eilučių skaičių
- B) Padauginus gedimo tikimybę ir efektą, kuris atsiras jam sugedus ✔
- C) Tik ta tvarka, kuria funkcija buvo sukurta
- D) Pirmenybė teikiama tik tai funkcijai, kuriai lengviausia parašyti testus
Paaiškinimas: Rizika pagrįsto bandymo metu rizika vertinama kaip tikimybė = tikimybė (gedimo tikimybė) × poveikis (pažeidimas sugedus). Didelės tikimybės ir didelio poveikio domenai (mokėjimas, autentifikavimas) nusipelno intensyviausio testavimo, o maži × maži domenai – lengvi.
11. Kokia yra pagrindinė rizika pridedant pakartotinį bandymą prie testo, kuris kartais pavyksta, o kartais nepavyksta (trupus / dribsniai), nors kodas nepasikeitė?
- A) Bandymo trukmės sutrumpinimas
- B) Sumažėja padengimo procentas
- C) Tikros sutapimo klaidos arba pagrindinės priežasties nuslėpimas ir simptomo slopinimas ✔
- D) Testo pavadinimo keitimas
Paaiškinimas: Bandymas iš naujo yra diagnostikos įrankis, o ne gydymas. Neryžtingumas dažnai kyla dėl tikrosios rasės būklės arba priklausomybės; Bandymas „išlaikyti“ dar kartą uždengia šią tikrą klaidą ir gali sukelti rimtų problemų tiesioginiame gyvenime. Pirmiausia reikia rasti pagrindinę priežastį.
12. Kaip veikia mutacijų tyrimas, sąžiningiausias metodas, leidžiantis išmatuoti, ar testų rinkinys iš tikrųjų apsaugo?
- A) Matuojant bandymų eigos greitį
- B) Suskaičiavus, kiek kodo eilučių buvo parašyta
- C) Vykdydami testus skirtingomis eilėmis
- D) Sąmoningai sukuriant mažas kode pertraukas ir matuojant, ar testai jas pagauna ✔
Aprašymas: Mutacijų testavimas sukuria nedidelius tyčinius šaltinio kodo iškraipymus (mutacijas); Geras bandymų rinkinys turėtų sugauti šiuos iškraipymus ir tapti raudonas. Nepagautos (išgyventos) mutacijos rodo, kad testai tokio elgesio neišsaugo. Mutacijos balas yra daug sąžiningesnis kokybės matas nei procentinė aprėptis.
13. Kokia yra pagrindinė riba, kurios reikia laikytis atliekant saugumo testavimą (pvz., autorizacijos / IDOR testus)?
- A) Apsaugos tikslais tai turėtų būti daroma tik su atskiru gaminiu, turint raštišką leidimą ir apibrėžtą taikymo sritį ✔
- B) Jis gali būti laisvai taikomas bet kuriai palūkanų sistemai
- C) Jį galima išbandyti tiesioginėse verslo partnerių sistemose be leidimo
- D) Bet koks aptiktas pažeidžiamumas turėtų būti nedelsiant paskelbtas viešai.
Aprašymas: Šiame modulyje išmokti saugos testai skirti tik jūsų gaminiui išbandyti gynybos tikslais, laikantis raštiško įgaliojimo ir apibrėžtos apimties. Prieiga prie kieno nors kito sistemos be leidimo arba atlikti testus, kurie nepatenka į taikymo sritį, yra neetiška ir neteisėta; Apie visus rastus pažeidžiamumus pranešama atsakingai atskleidžiant.
14. Kokie įgaliojimai niekada neturėtų būti suteikiami dirbtiniam intelektui CI/CD konvejeryje?
- A) Nepavykusių bandymų žurnalų apibendrinimas
- B) Įgaliojimas automatiškai „išlaikyti“ neišlaikytą (raudoną) testą arba nudažyti jį žalia spalva ✔
- C) Pasiūlyti testo kodo projektą
- D) YAML failo projektavimas
Aprašymas: AI gali sukurti bandomojo kodo kontūrą, YAML konvejerį ir žurnalo santrauką CI / CD; tačiau galimybė automatiškai „išlaikyti/ištaisyti“ nepavykusį testą niekada neturėtų būti suteikta. Tai pažeidžia testavimo tikslą ir automatiškai uždengia klaidas. Testo dažymas žaliai turėtų būti sąmoningas ir pagrįstas žmogaus sprendimas.