Kasu:
- Võimalus kujundada tehisintellekti ja inimeste heakskiidupunktide roll täielikus kvaliteedikontrolli voos ideest väljalaskeni CI/CD kontekstis
- CI/CD puhul ei lubata AI-l testi automaatselt "läbida", vaid rakendatakse piiranguid konfidentsiaalsete andmete ja võtmete kaitsmiseks
- Võimalus teostada turvateste volituste piires ja kaitseotstarbel ning võtta kasutusele vastutustundliku avalikustamise ja eetilise läbipaistvuse põhimõtted.
Eelmises kümnes üksuses kasutasime tehisintellekti üksikutes ülesannetes: stsenaariumide genereerimine, automatiseerimiskood, veateade, katvuse analüüs, mutatsioonide testimine. See viimane üksus ühendab need kõik üheks vastutustundlikuks töövooguks. Kaasaegne kvaliteedi tagamine ei ole töö, mis lõpeb ühe inimese laua taga; See on protsess, mis elab CI/CD-s (Continuous Integration / Continuous Delivery – konveier, kus koodi pidevalt kombineeritakse, testitakse automaatselt ja valmistatakse sageli ja ohutult avaldamiseks ette). AI võib puudutada selle protsessi kõiki etappe. Kuid tehisintellekti võimsuse kasvades kasvab ka selle vastutustundliku kasutamise olulisus: privaatsus, autoriteet turvatestimisel, eetika ja mis kõige tähtsam, kvaliteediotsuse hoidmine inimese enda teha. Selles õppetükis õpite tundma voogu ja piire.
AI-toitel otsast lõpuni töötav QA voog
AI roll funktsiooni teekonnal ideest väljalaskeni:
1. Nõuete analüüs. AI märgib nõuete ebaselgused ja puuduvad aktsepteerimiskriteeriumid ("see reegel ei ütle, mitu tähemärki parool on minimaalne").
2. Testi disain. Stsenaariumi- ja juhtumikavandid (üksus 2), servajuhtumid (üksus 3) kuuluvad aktsepteerimise kriteeriumide hulka.
3. Automatiseerimine. Üksuse (6), API (5) ja kasutajaliidese (4) testkoodi mustandid; igaüks neist on kinnitatud mutatsiooniga (10).
4. CI/CD integreerimine. Testid käitatakse automaatselt iga koodiühendamisega. AI koostab torujuhtme konfiguratsiooni (YAML), teeb kokkuvõtte ebaõnnestunud testide logidest, soovitab võimalikku algpõhjust.
5. Vabastamise otsus. Riskianalüüsi (8) ja regressiooni (9) tulemused kogutakse, kuid ekspert otsustab, kas see võib olla edukas.
6. Tootmise jälgimine ja tagasiside. Vead otseülekandes muutuvad tulevasteks testideks; AI pakub välja tootmisdefekti regressioonijuhtumi.
Näpunäide. Seadistage AI kihina CI/CD-s, mis "kiirendab inimeste poolt ülevaadatud mustandeid", mitte "kirjutab teste ja teeb otsuseid". Ükski automaatselt genereeritud test ei tohi siseneda konveierisse, ilma et inimene need üle vaataks ja heaks kiidab.
AI CI/CD-s: kus jah, kus ei
Lava
AI sobib
inimene on hädavajalik
Testi koodi mustand
Jah
Revisjon + mutatsioon
Torujuhtme YAML mustand
Jah
Autentimine + salajase võtme kontroll
Logi kokkuvõte ebaõnnestus
Jah
Algpõhjuse kinnitus
Habras testi diagnoos
Jah
Püsiv lahendusotsus
"Kas saab olla versiooni?"
ei
Eksperthinnang ja vastutus
Testi "läbi" automaatselt
mitte kunagi
—
Ettevaatust. Ärge kunagi andke tehisintellektile CI/CD-s mandaati, näiteks "parandada see ebaõnnestunud testi läbimiseks". See kaotab testimise eesmärgi ja varjab vead automaatselt. AI oskab viga selgitada, soovitada parandust; aga "testi roheliseks värvimine" peab olema inimese teadlik, põhjendatud otsus.
Privaatsus, andmed ja turvalisus: muutumatud piirid
Privaatsus. Testkeskkonnas on tundlikud tegelikud kliendiandmed, tootmisandmebaasi koopiad, API võtmed ja süsteemisisene teave. Ärge andke neid avalikele AI-tööriistadele. Isikuandmetele kehtivad KVKK jms regulatsioonid; Maski logid ja ekraanipildid. Kasutage võimaluse korral sünteetilisi (väljamõeldud) testiandmeid.
Turvatestimine – kaitsev ja volitatud. Selles moodulis õpitud turbetestid (volitus-/IDOR-testid, failide üleslaadimise piirangud, sisendi valideerimine) on mõeldud ainult teie enda toote testimiseks kirjaliku volituse ja määratletud ulatuses. Tehisintellekti kasutamine kellegi teise süsteemile loata juurde pääsemiseks, tõeliste haavatavuste relvastamiseks või reguleerimisalaväliste testide tegemiseks on nii ebaeetiline kui ka ebaseaduslik. Turvanõrkuse avastamisel järgige vastutustundliku avalikustamise põhimõtet – hoidke haavatavus konfidentsiaalsena ja teavitage sellest vastavat osapoolt, et see saaks parandada.
Eetika ja läbipaistvus. Ärge esitage tehisintellekti loodud teste oma tööna; Teatamine, et kasutate meeskonnas tehisintellekti, on läbipaistvus. Teie vastutate tehisintellekti toodetud väljundi ebatäpsuse eest – "AI kirjutas selle" ei ole vabandus.
Nõrk viip / Tugev viip
Nõrk: "Seadista CI testkonveier."
Tugev: "Koosta CI töövoo YAML GitHubi toimingute jaoks: käivitage iga PR-i jaoks üksus + API-testid, looge katvuse aruanne, käivitage mutatsioonitestid (Stryker) kord nädalas. Ärge manustage koodi saladusi; kasutage ainult saladuste viidet. Blokeeri liitmine, kui testid on punased. See on MUSTAND; Ma vaatan üle ja redigeerin salajase võtme haldamist ja automatiseerimist, MITTE kinnitada." 'migratsiooni' samm."
Võimas viip; See seab piirangud konfidentsiaalsusele, inimlikule ülevaatamisele ja "automaatse testimise puudumisele".
Neli kopeeritavat malli
1) Täielik testimise plaan:
Teie roll: vanem QA juht. Koostage täieliku testimise plaan ideest väljalaseni järgmise funktsiooni jaoks: [funktsioon + aktsepteerimiskriteeriumid].Etapid: nõuete analüüs (määramatused), testimise ülesehitus, automatiseerimiskihid (üksus/API/UI), CI/CD integreerimine, väljalaskeotsuse kriteeriumid, tootmise jälgimine. Määrake tehisintellekti ja INIMESE kinnituspunktide roll igas etapis eraldi.
2) CI/CD konveier:
CI YAML-i mustand [GitHubi toimingute / GitLabi CI / Azure'i torujuhtmete jaoks]:- üksus + API test + ulatus PR-is - Ühendamise vältimine punase testiga - Salajased väärtused ainult saladustega; manustamine koodiSee on mustand; Vaatan üle võtmehalduse ja kinnitamise etapid. Automaatse korrigeerimise/läbi testimise etapi lisamine.
3) Ebaõnnestunud testilogi analüüs:
Sellel CI-trükil on testid punased. Uurige logi; rühmitage tõrked, eristage võimalik algpõhjus ja MILLES võib olla tegelik rike ja mis võib olla habras test/keskkonnaprobleem. Kui on isikuandmeid, maskeerige need. Otsus ja parandus on minu teha. Logi: [kleebi]
4) Turvalisuse/privaatsuse eelkontroll:
Enne nende testandmete/logi saatmist tehisintellekti tööriistale kontrollige: kas see sisaldab isikuandmeid, API võtit, süsteemi sisemist aadressi, tootmisandmeid? Loetlege, millised alad (kui neid on) tuleb maskeerida/eemaldada. Töötlemine nii nagu see on. Sisu: [kleebi]
kolm minikarpi
Juhtum 1 – otsast lõpuni voolu kiirus. Üks meeskond tegeles uue „tellimuse uuendamise” funktsiooniga koos tehisintellektil töötava otsast lõpuni: nõuete ebakindlus märgistati ette, koostati kolmekihilised testid ja kinnitati mutatsioonid, mis on seotud CI-ga. Funktsioon vähendas testimistsüklit, mis traditsioonilises protsessis võttis aega 5 päeva, 2 päevani; kuid inimlik heakskiit säilis igal etapil ja nõuete määramatus (mis juhtub, kui värskendamine ebaõnnestub) suleti enne kasutust.
Juhtum 2 – tagasitulek võtmelekkest. Arendaja lasi AI-l genereerida CI YAML-i ja AI manustas näitena YAML-i reaalse välimusega API-võtme. „Turvalisuse/privaatsuse eelkontrolli” samm tabas seda; võti teisendati saladuste viiteks. Ilma auditietapita lekiks võti versioonikontrolli (giti ajalugu).
Juhtum 3 – volituste piirang. Meeskonnaliige soovis oma õpitud IDOR-testi rakendada äripartneri reaalajas süsteemis, kui ütlesin "Olin uudishimulik". Kvaliteedikontrolli juht lõpetas: teise süsteemi turvatestide läbiviimine ilma kirjaliku loata ja määratletud ulatuseta on ebaseaduslik. Testimine viidi läbi ainult oma toodete testkeskkonnas, volitustega; Avatud vastutaja teavitati vastavat meeskonda.
Levinud vead
- Tehisintellekti vabastamise otsuste tegemine. Esitades küsimuse "Kas seda saab vabastada?" tehisintellektile ja pannes vastuse allkirja asemele.
- Automatiseeritud testi "läbimine". CI-s, lasta tehisintellektil värvida test roheliseks; vigade varjamine.
- Konfidentsiaalsete andmete/võtme andmine sõidukile. Tootmisandmete, isikuandmete või API-võtmete jagamine ilma järelevalveta.
- Volitamata turvatestid. Ründaja testimine teises süsteemis ilma ulatuse ja loata.
- Katsete sisseviimine torujuhtmesse ilma läbivaatamiseta. Käivitage AI-sketš automaatselt ilma inimese nõusolekuta.
- Süüdistades tehisintellekti. Vale väljundi kaitsmine, öeldes: "AI kirjutas selle".
Kokkuvõttes
End-to-end QA on protsess, mis ulatub nõuetest tootmise jälgimiseni ja kestab CI/CD piires; Igas etapis koostab AI mustandeid, teeb logist kokkuvõtte ja pakub välja algpõhjused. Kuid piirid on muutumatud: inimesed teevad katsetamisotsuseid ja vabastavad heakskiidu; AI-le ei anta kunagi volitusi testi automaatselt "läbida"; konfidentsiaalsed andmed ja võtmed ei sisene sõidukisse; Turvatestid viiakse läbi ainult teie enda tootele, kirjaliku loa ja määratletud ulatuse piires, kaitseotstarbel ning leidudest teavitatakse vastutustundlikult. AI kasutamisel olge läbipaistev; Sina vastutad väljundi täpsuse eest. AI kiirendab; Te garanteerite kvaliteedi ja eetika.
Rakenduse ülesanne
Koostage oma projekti funktsiooni jaoks plaan ideest väljalaskeni koos täieliku testiplaani malliga; Märkige tehisintellekti ja inimeste heakskiidupunktide roll igas etapis eraldi. Seejärel looge YAML koos „CI/CD konveieri kontuuriga” ja rakendage sellele YAML-ile „turvalisuse/privaatsuse eelkontroll”, et kontrollida manustatud võtme/salajaste andmete olemasolu. Lõpuks loetlege kõik oma plaani "inimliku otsuse" punktid ja põhjendage ühe lausega, miks ei saa neid otsuseid tehisintellektile delegeerida.
kontrollnimekiri
- [ ] Ma omistan vabastamise ja testimise otsused inimese heakskiidule; Ma ei andnud seda AI-le üle.
- [ ] CI/CD puhul ei andnud ma AI-le luba testi automaatselt "läbi/parandada".
- [ ] Kontrollisin ja maskeerisin konfidentsiaalsed andmed, isikuandmed ja võtmed enne nende sõidukisse saatmist.
- [ ] Olen kaalunud ainult oma toote turvatestimist kirjaliku loa ja ulatuse piires.
- [ ] Käsitlesin leitud nõrku kohti vastutustundliku avalikustamise põhimõttega.
- [ ] Ütlesin läbipaistvalt, et kasutasin tehisintellekti ja vastutan väljundi täpsuse eest.
Mooduli eksam
1. Kuidas on QA kontekstis kõige täpsemalt määratletud valesobivus?
- A) Kuigi test muutub roheliseks, ei kinnita see tegelikult mingit käitumist; ✔ Ei muutu punaseks isegi siis, kui kood on rikutud
- B) Test töötab väga aeglaselt ja aegub.
- C) Test tuvastab tõelise vea ja muutub punaseks
- D) Test töötab ainult tootmiskeskkonnas
Selgitus: pseudo-sobiv on see, kui test ütleb "sobib", kuid tegelikult ei kinnita midagi tähenduslikku; Test on roheline, kuid isegi kui tarkvara on vigane, ei saa see seda kinni. See on QA-s tehisintellekti risk number üks, sest AI kipub tootma teste, mis näevad välja korralikud, kuid on õõnsad.
2. Milline on tehisintellekti kõige täpsem positsioneerimine testimise ja kvaliteedi tagamise protsessis?
- A) Tehisintellekt võib otsustada, kas versiooni saab avaldada ilma inimese nõusolekuta
- B) Tehisintellekt on assistent, kes genereerib mustandeid ja ideid; Otsus ja vastutus, kas see on avaldamiseks valmis, kuulub eksperdile ✔
- C) Tehisintellekt kirjutab ainult teksti ja ei saa testkoodiga üldse hakkama
- D) Tehisintellekt kirjutab alati õige testi kui inimene, seega pole ülevaatamine vajalik
Kirjeldus: Tehisintellekt on testimisassistent, mustandite generaator ja ideede kordaja; toodab teststsenaariume, automatiseerimiskoode ja aruannete kavandeid. Kvaliteediotsuste, näiteks „kas see tarkvara on avaldamiseks valmis” või „kas see test on läbitud”, vastutus ja lõplik kinnitamine kuulub siiski pädevale eksperdile.
3. Kui võtta aluseks tõsiasi, et vead esinevad enamasti läviväärtuste juures, siis milline testi kavandamise tehnika on 17, 18 ja 19 eraldi testimine vanusepiirangu 18 puhul?
- A) Oleku ülemineku test
- B) Otsustabel
- C) Piirväärtuste analüüs ✔
- D) Uurimuslik katsetamine
Selgitus: Piirväärtuste analüüs põhineb tähelepanekul, et vead esinevad kõige sagedamini piiridel, ja testib eraldi läviväärtusi (veidi alla, veidi üle ja veidi üle piiri). See on võimas tehnika, mis täiendab samaväärsuse klasse.
4. Millist lähenemist tuleks eelistada elementide valikul, et vähendada tehisintellektiga toodetud kasutajaliidese testimise automatiseerimiskoodi haprust?
- A) Pikima võimaliku XPath-tee kasutamine
- B) Elemendi valimine selle piksli asukoha järgi ekraanil
- C) Selektorite kasutamine CSS-klasside nimede põhjal
- D) Testimiseks lisatud stabiilsete atribuutide (data-testid) kasutamine ✔
Selgitus: Pikad XPathi teed ja CSS-klassi nimed sõltuvad äärmiselt lehe struktuurist ja kujundusest; See puruneb väikseima liidese muudatuse korral. Spetsiaalselt testimiseks lisatud stabiilseid atribuute (nt data-testid) disainimuudatused ei mõjuta ja need muudavad testid tugevaks.
5. Miks API-testist ei piisa ainult HTTP olekukoodi (nt 200) kontrollimisest?
- A) Kuna õige olekukoodiga kehaandmed võivad olla rikutud ja olekukontroll üksi seda ei taba (pseudousaldus) ✔
- B) Kuna olekukoodid pole API testides üldse usaldusväärsed
- C) Kuna olekukoodi kontrollimine aeglustab testi oluliselt
- D) Kuna olekukoodi ei tagastata kunagi API testides
Selgitus. Kuigi server tagastab õige olekukoodi, võib see tagastada sisus rikutud andmed (vale tüüp, puuduv väli, valesti arvutatud väärtus). Test, mis vaatab ainult olukorda, ei näe seda ja annab vale enesekindluse. Seega tuleks lisada ka skeemi/lepingu ja ärireeglite valideerimine.
6. Miks on ühikutestide printimisel ülioluline käskida AI-l „arvutada eeldatav väärtus käsitsi aktsepteerimisreegli järgi, mitte viitada funktsiooni praegusele väljundile”?
- A) Kuna käsitsi arvutamine käivitab testid kiiremini
- B) Kuna vastasel juhul tunnistab test koodi praeguse (võib-olla lollaka) käitumise "õigeks" ja kinnitab vea ✔
- C) Kuna tehisintellekt ei suuda kümnendarvusid üldse arvutada
- D) Kuna testides ei kasutata kunagi aktsepteerimisreegleid
Selgitus: kui AI tuletab eeldatava väärtuse testitava funktsiooni väljundist, teeb see testi "läbituks" isegi siis, kui funktsioon on vigane; See tähendab, et olenemata koodist, loetakse test tõeseks. Oodatava väärtuse arvutamine aktsepteerimisreeglist sõltumatult tagab, et test on reegli väravavaht, mitte koodi peegel.
7. Milline järgmistest on hea vearaporti kõige eristavam omadus?
- A) Olla võimalikult pikk ja tehniline
- B) Tehisintellekti poolt kirjutatud
- C) Sisaldab deterministlikke reprodutseerimise etappe, mida arendaja saab iseseisvalt järgida ja tekitada vea ✔
- D) See on lihtsalt ekraanipilt
Selgitus. Veaaruande tegelik väärtus seisneb selles, et arendaja saab vea ilma teie abita reprodutseerida. Selle tagavad deterministlikud, nullist jälgitavad reprodutseerimise etapid; Kui need sammud puuduvad, suletakse aruanne sageli teatega „ei õnnestunud koostada”.
8. Milline on kõige täpsem väljendus tõsiduse ja prioriteedi seose kohta avalehel ettevõtte nime valesti kirjutamise vea korral?
- A) Intensiivsus ja prioriteet peaks alati olema sama väärtusega
- B) Nii selle vea tõsidus kui ka prioriteet on kindlasti madal
- C) Raskusaste ja prioriteetsus on sama mõiste, ühest märgisest piisab
- D) Tehniline intensiivsus võib olla madal, kuid äriline prioriteet (maine) võib olla kõrge; Neid kahte hinnatakse erinevalt ✔
Selgitus: raskusaste on vea tehniline mõju (kirjaviga tehniliselt madal), prioriteet on see, kui kiiresti see tuleb parandada (kõrge, kuna see on maine element, mida iga külastaja näeb). Need kaks ei lähe alati samas suunas; See näide on madala raskusastmega ja kõrge prioriteediga olukord.
9. Milline on 90% liinikattusega testkomplekti kõige täpsem tõlgendus?
- A) See näitab, et read on täidetud, kuid ei tõesta, et need käituvad õigesti; ✔ kõrge katvus võib anda vale kindlustunde
- B) Tõestab veenvalt, et 90% tarkvarast on vigadeta
- C) See on suurepärase testikvaliteedi lõplik mõõt.
- D) Näitab, et täiendavaid teste pole enam vaja kirjutada
Selgitus: ridade katvus näitab, et täideti ainult ridu; See ei tõesta, et see annab õigeid tulemusi. Isegi enesekindlate testidega on võimalik saavutada 90% katvus. Ulatus on kaart „pole kunagi vaadanud kuhu” ega tagatis „kõik on testitud”; tegelikku kaitset mõõdetakse mutatsioonitestiga.
10. Kuidas arvutatakse riskipõhise testimise korral funktsiooni risk, mis suunab piiratud testimistegevust?
- A) Ainult koodiridade arvu järgi
- B) Korrutades rikke tõenäosuse ja selle purunemisel tekkiva efekti ✔
- C) Ainult funktsiooni väljatöötamise järjekorras
- D) Eelistades ainult seda funktsiooni, mille jaoks on kõige lihtsam teste kirjutada
Selgitus: Riskipõhises testimises hinnatakse riski tõenäosusena = tõenäosus (rikke tõenäosus) × mõju (kahju purunemisel). Suure tõenäosusega ja suure mõjuga domeenid (makse, autentimine) väärivad kõige intensiivsemat testimist, samas kui madala × madala domeenid saavad kerget testimist.
11. Mis on peamine oht korduskatse lisamisel testile, mis mõnikord läbib ja mõnikord ebaõnnestub (habras/helbeline), kuigi kood pole muutunud?
- A) Katse aja lühendamine
- B) Vähendab katvuse protsenti
- C) Tõelise samaaegsusvea või algpõhjuse varjamine ja sümptomi mahasurumine ✔
- D) Testi nime muutmine
Selgitus: Korduskatse on diagnostikavahend, mitte ravi. Otsustamatus tuleneb sageli tegelikust rassiseisundist või sõltuvusest; Testi korduskatsega läbimine katab selle tõelise vea ja võib otse-eetris tõsiseid probleeme tekitada. Kõigepealt tuleb leida algpõhjus.
12. Kuidas mutatsioonitestimine, kõige ausam meetod mõõtmaks, kas testikomplekt tegelikult kaitseb, töötab?
- A) Mõõtes katsete jooksukiirust
- B) Loendades, mitu rida koodi kirjutati
- C) Testide läbiviimisel erinevates järjestustes
- D) Luues koodis teadlikult väikseid katkestusi ja mõõtes, kas testid tabavad neid ✔
Kirjeldus: mutatsioonide testimine tekitab lähtekoodis väikseid tahtlikke moonutusi (mutatsioone); Hea testkomplekt peaks need moonutused tabama ja punaseks muutuma. Mutatsioonid, mida ei püüta (ellu jääda), näitavad, et testid ei säilita seda käitumist. Mutatsiooniskoor on palju ausam kvaliteedinäitaja kui protsentuaalne katvus.
13. Mis on peamine piirmäär, mida turvatestide (nt autoriseerimis-/IDOR-testid) läbiviimisel järgida?
- A) Seda tuleks teha ainult tema enda tootel, kirjaliku loa ja määratletud ulatusega, kaitseotstarbel ✔
- B) Seda saab vabalt rakendada igale huvipakkuvale süsteemile
- C) Seda saab ilma loata proovida äripartnerite reaalajas süsteemides
- D) Kõik leitud haavatavused tuleks viivitamatult avalikult avaldada.
Kirjeldus: Selles moodulis õpitud turbetestid on mõeldud ainult teie enda toote testimiseks kaitseotstarbel kirjaliku loa ja määratletud ulatuse piires. Juurdepääs kellegi teise süsteemile ilma loata või valdkonnavälise testimise läbiviimine on nii ebaeetiline kui ka ebaseaduslik; Kõigist leitud haavatavustest teavitatakse vastutustundliku avalikustamise kaudu.
14. Milliseid volitusi ei tohiks kunagi anda tehisintellektile CI/CD torujuhtmes?
- A) Ebaõnnestunud testide logide kokkuvõte
- B) Õigus ebaõnnestunud (punane) test automaatselt "läbida" või värvida see roheliseks ✔
- C) Testkoodi mustandi väljapakkumine
- D) YAML-faili koostamine torujuhtme kaudu
Kirjeldus: AI suudab toota CI/CD-s testikoodi kontuuri, konveieri YAML-i ja logi kokkuvõtte; Siiski ei tohiks kunagi anda ebaõnnestunud testi automaatse "läbimise/parandamise" võimalust. See kaotab testimise eesmärgi ja varjab vead automaatselt. Testi roheliseks värvimine peaks olema inimese teadlik ja põhjendatud otsus.