Ieguvumi:
- Spēja izstrādāt mākslīgā intelekta un cilvēku apstiprināšanas punktu lomu pilnīgas kvalitātes nodrošināšanas plūsmā no idejas līdz izlaidumam CI/CD kontekstā
- CI/CD neļauj AI automātiski “izturēt” pārbaudi, bet piemēro ierobežojumus, lai aizsargātu konfidenciālus datus un atslēgas
- Spēja veikt drošības testēšanu autoritātes ietvaros un aizsardzības nolūkos, kā arī pieņemt atbildīgas izpaušanas un ētiskās caurskatāmības principus.
Iepriekšējās desmit vienībās mēs izmantojām AI atsevišķos uzdevumos: scenāriju ģenerēšana, automatizācijas kods, kļūdu ziņošana, pārklājuma analīze, mutāciju pārbaude. Šī pēdējā vienība tos visus apvieno vienā atbildīgā darbplūsmā. Mūsdienu kvalitātes nodrošināšana nav darbs, kas beidzas pie viena cilvēka galda; Tas ir process, kas darbojas CI/CD (Continuous Integration / Continuous Delivery — konveijerā, kurā kods tiek pastāvīgi apvienots, automātiski pārbaudīts un sagatavots publicēšanai bieži un droši). AI var pieskarties katram šī procesa posmam. Taču, pieaugot mākslīgā intelekta spēkam, pieaug arī tā atbildīgas izmantošanas nozīme: privātums, autoritāte drošības pārbaudēs, ētika un, pats galvenais, lēmumu par kvalitāti paturēt cilvēka ziņā. Šajā nodaļā jūs apgūsit plūsmu no gala līdz galam un robežas.
Pilnīga ar AI darbināma kvalitātes nodrošināšanas plūsma
AI loma funkcijas ceļā no idejas līdz izlaišanai:
1. Prasību analīze. AI atzīmē neskaidrības prasībās un trūkstošos pieņemšanas kritērijus ("šis noteikums nenorāda, cik rakstzīmju parolei ir jābūt vismaz").
2. Testa dizains. Scenāriju un gadījumu melnraksti (2. vienība), malas gadījumi (3. vienība) ir vieni no pieņemšanas kritērijiem.
3. Automatizācija. Vienības (6), API (5) un UI (4) testa kodu melnraksti; katru apstiprina mutācija (10).
4. CI/CD integrācija. Testi tiek veikti automātiski ar katru koda sapludināšanu. AI sastāda cauruļvada konfigurācijas (YAML) projektus, apkopo neveiksmīgo testu žurnālus, ierosina iespējamo galveno cēloni.
5. Lēmums par atbrīvošanu. Tiek apkopoti riska analīzes (8) un regresijas (9) rezultāti, taču eksperts izlemj, vai tas var būt veiksmīgs.
6. Ražošanas uzraudzība un atgriezeniskā saite. Kļūdas tiešraidē kļūst par nākotnes pārbaudēm; AI piedāvā regresijas gadījumu no ražošanas defekta.
Padoms. Iestatiet AI kā slāni CI/CD, kas “paātrina cilvēku pārskatītos melnrakstus”, nevis “raksta testus un pieņem lēmumus”. Neviens automātiski ģenerēts tests nedrīkst iekļūt konveijerā, ja cilvēks tos nav pārskatījis un neapstiprinājis.
AI CI/CD: kur jā, kur nē
Skatuves
AI piemērots
cilvēks ir būtisks
Testa koda melnraksts
Jā
Pārskatīšana + mutācija
Cauruļvada YAML projekts
Jā
Autentifikācija + slepenās atslēgas pārbaude
Neizdevās žurnāla kopsavilkums
Jā
Pamatcēloņa apstiprinājums
Trauslā testa diagnoze
Jā
Pastāvīgs risinājuma lēmums
"Vai var būt versija?"
nē
Ekspertu spriedums un atbildība
Automātiski "nokārtot" testu
nekad
—
Uzmanību: CI/CD nekad nedodiet mākslīgajam intelektam tādu pilnvaru kā “labot to, lai izturētu nesekmīgu testu”. Tas pārspēj testēšanas mērķi un automātiski aizsedz kļūdas. AI var izskaidrot kļūdu, ieteikt labojumus; bet "pārbaudes nokrāsošanai zaļā krāsā" ir jābūt cilvēka apzinātam, argumentētam lēmumam.
Privātums, dati un drošība: nemainīgas robežas
Privātums. Testa vidē faktiskie klientu dati, ražošanas datu bāzes kopijas, API atslēgas un iekšējā sistēmas informācija ir sensitīva. Nenododiet tos publiskiem AI rīkiem. Uz personas datiem attiecas KVKK un līdzīgi noteikumi; Maskēt žurnālus un ekrānuzņēmumus. Kad vien iespējams, izmantojiet sintētiskos (izdomātus) testa datus.
Drošības pārbaude — aizsardzības un autorizēta. Šajā modulī apgūtie drošības testi (autorizācijas/IDOR testi, failu augšupielādes ierobežojumi, ievades validācija) ir paredzēti tikai jūsu produkta testēšanai rakstiskās atļaujas ietvaros un noteiktā apjomā. AI izmantošana, lai bez atļaujas piekļūtu kāda cita sistēmai, izmantotu reālas ievainojamības vai veiktu ārpus darbības jomas pārbaudes, ir gan neētiska, gan nelikumīga. Atklājot drošības ievainojamību, ievērojiet atbildīgas izpaušanas principu — saglabājiet ievainojamības konfidencialitāti un ziņojiet par to attiecīgajai pusei, lai to varētu novērst.
Ētika un caurspīdīgums. Nepasniedziet mākslīgā intelekta radītos testus kā savu darbu; Paziņojums, ka komandā izmantojat AI, ir caurspīdīgums. Jūs esat atbildīgs par mākslīgā intelekta radītās izvades neprecizitāti — “AI uzrakstīja to” nav attaisnojums.
Vāja uzvedne / spēcīga uzvedne
Vāji: "Iestatiet CI testa konveijeru."
Spēcīgs: "Izstrādājiet CI darbplūsmas YAML uzmetumu GitHub darbībām: palaidiet vienības + API testus katrā PR, ģenerējiet pārklājuma pārskatu, palaidiet mutāciju testēšanu (Stryker) katru nedēļu. Neieguliet kodā noslēpumus; izmantojiet tikai atsauces uz noslēpumiem. Bloķējiet sapludināšanu, ja testi ir sarkani. Šis ir MELNSTRĀNS; Es pārskatīšu un rediģēšu slepenās atslēgas pārvaldību un NElaboju pārbaudes darbības. “migrācijas” solis."
Spēcīga uzvedne; Tas nosaka ierobežojumus konfidencialitātei, cilvēka pārbaudei un "nav automātiskas testēšanas".
Četras kopējamas veidnes
1) Pilnīgas pārbaudes plāns:
Jūsu loma: vecākais kvalitātes nodrošināšanas vadītājs. Izstrādājiet pilnīgas testēšanas plānu no idejas līdz izlaidumam šādai funkcijai: [funkcija + pieņemšanas kritēriji]. Fāzes: prasību analīze (nenoteiktības), testēšanas dizains, automatizācijas slāņi (vienība/API/UI), CI/CD integrācija, izlaišanas lēmuma kritēriji, ražošanas izsekošana. Norādiet AI un CILVĒKU apstiprināšanas punktu lomu katrā posmā atsevišķi.
2) CI/CD konveijera kontūra:
CI YAML melnraksts [GitHub Actions/GitLab CI/Azure Pipelines]:- vienība + API tests + darbības joma PR- Novērst sapludināšanu sarkanā testā- Slepenās vērtības tikai ar noslēpumiem; iegulšana kodāŠis ir melnraksts; Es pārskatīšu galvenās pārvaldības un apstiprināšanas darbības. Tiek pievienots automātiskās labošanas/izturēšanas testa solis.
3) Neveiksmīga testa žurnāla analīze:
Šajā CI izdrukā testi ir sarkani. Pārbaudi žurnālu; grupējiet kļūmes, nošķiriet iespējamos pamatcēloņus un KURA var būt patiesā kļūme un kas var būt trausla testa/vides problēma. Ja ir personas dati, maskējiet tos. Lēmums un labojums būs mans. Žurnāls: [ielīmēt]
4) Drošības/privātuma iepriekšēja pārbaude:
Pirms šie testa dati/žurnāls tiek nosūtīts uz AI rīku, pārbaudiet: vai tajā ir personas dati, API atslēga, iekšējā sistēmas adrese, ražošanas dati? Uzskaitiet, kuras vietas, ja tādas ir, ir jāmaskē/jānoņem. Apstrāde tāda, kāda tā ir. Saturs: [ielīmēt]
trīs mini futrāļi
1. gadījums — plūsmas ātrums no gala līdz galam. Viena komanda pievērsās jaunai “abonementa atjaunošanas” funkcijai ar mākslīgā intelekta darbināmu tiešu plūsmu: prasību nenoteiktības tika atzīmētas iepriekš, trīs slāņu testi tika izstrādāti un mutāciju apstiprināti, saistīti ar CI. Šī funkcija samazināja testēšanas ciklu, kas tradicionālajā procesā ilga 5 dienas, līdz 2 dienām; taču cilvēku apstiprinājums tika saglabāts katrā posmā, un prasību nenoteiktība (kas notiek, ja atsvaidzināšana neizdodas) tika slēgta pirms tiešraides.
2. gadījums — atgriešanās no atslēgas noplūdes. Izstrādātājs lika AI ģenerēt CI YAML, un AI kā piemēru YAML iegula reāla izskata API atslēgu. “Drošības/privātuma iepriekšējās pārbaudes” darbība to fiksēja; atslēga ir pārveidota par noslēpumu atsauci. Bez audita posma atslēga nonāktu versiju kontrolē (git vēsturē).
3. gadījums — pilnvaru ierobežojums. Komandas loceklis vēlējās piemērot IDOR testu, ko viņš iemācījās biznesa partnera tiešraidē, no "es biju ziņkārīgs". QA vadītājs apstājās: ir nelikumīgi veikt drošības testēšanu citā sistēmā bez rakstiskas atļaujas un noteikta apjoma. Testēšana tika veikta tikai viņu pašu produktu testa vidē, ar autoritāti; Atklātā atbildīgā puse tika informēta attiecīgajai komandai.
Biežas kļūdas
- AI liek pieņemt lēmumus par atbrīvošanu. Uzdodot jautājumu "Vai to var atbrīvot?" AI un ievietojot atbildi paraksta vietā.
- Automātiskā testa "nokārtošana". CI gadījumā, ja AI krāso testu zaļā krāsā; kļūdu piesegšana.
- Konfidenciālu datu/atslēgas nodošana transportlīdzeklim. Ražošanas datu, personas datu vai API atslēgu koplietošana bez uzraudzības.
- Neatļauta drošības pārbaude. Uzbrucēju testēšana citā sistēmā bez darbības jomas un atļaujas.
- Pārbaužu ieviešana cauruļvadā bez pārskatīšanas. Automātiski palaist AI skici bez cilvēka apstiprinājuma.
- Vainu uzvelkot AI. Nepareizas izvades aizstāvēšana, sakot "AI uzrakstīja to".
Rezumējot
Pilnīga kvalitātes nodrošināšana ir process, kas sniedzas no prasībām līdz ražošanas izsekošana un darbojas CI/CD; Katrā posmā AI veido melnrakstus, apkopo žurnālu un ierosina galvenos cēloņus. Taču robežas ir nemainīgas: cilvēki pieņem testēšanas lēmumus un atbrīvo apstiprinājumu; AI nekad netiek piešķirtas pilnvaras automātiski “nokārtot” testu; konfidenciāli dati un atslēgas neietilpst transportlīdzeklī; Drošības pārbaudes tiek veiktas tikai jūsu paša izstrādājumam, ievērojot rakstisku atļauju un noteiktu darbības jomu, aizsardzības nolūkos, un par konstatējumiem tiek ziņots, atbildīgi atklājot. Esiet caurspīdīgs, kad izmantojat AI; Jūs esat atbildīgs par izvades precizitāti. AI paātrina; Jūs garantējat kvalitāti un ētiku.
Lietojumprogrammas uzdevums
Izveidojiet plānu no idejas līdz izlaidumam, izmantojot “pilnīga testa plāna” veidni kādai funkcijai no sava projekta; Katrā posmā atsevišķi atzīmējiet AI un cilvēku apstiprināšanas punktu lomu. Pēc tam ģenerējiet YAML ar “CI/CD konveijera kontūru” un veiciet šim YAML “drošības/privātuma priekšpārbaudi”, lai pārbaudītu, vai nav iegulto atslēgu/slepeno datu. Visbeidzot, savā plānā uzskaitiet visus “cilvēka lēmumu” punktus un vienā teikumā pamatojiet, kāpēc šos lēmumus nevar deleģēt AI.
kontrolsaraksts
- [ ] Izlaišanas un testēšanas lēmumus es attiecinu uz cilvēka apstiprinājumu; Es to nenodevu AI.
- [ ] CI/CD es nedevu AI atļauju automātiski "nokārtot/labot" testu.
- [ ] Es pārbaudīju un maskēju konfidenciālus datus, personas datus un atslēgas pirms to nosūtīšanas uz transportlīdzekli.
- [ ] Esmu apsvēris tikai sava produkta drošības testēšanu rakstiskās atļaujas un darbības jomas ietvaros.
- [ ] Es pievērsos atklātajām ievainojamībām, ievērojot atbildīgas izpaušanas principu.
- [ ] Es skaidri paziņoju, ka izmantoju AI, un esmu atbildīgs par izvades precizitāti.
Moduļa eksāmens
1. Kā QA kontekstā visprecīzāk tiek definēta “viltus atbilstība”?
- A) Lai gan tests kļūst zaļš, tas faktiski neapstiprina nekādu uzvedību; ✔ Nekļūst sarkans pat tad, ja kods ir bojāts
- B) Pārbaude norit ļoti lēni un beidzas.
- C) Pārbaude atklāj reālu kļūdu un kļūst sarkana
- D) Tests tiek veikts tikai ražošanas vidē
Paskaidrojums: pseido-ieskaitīts ir tad, kad tests saka "ieskaitīts", bet faktiski neapstiprina neko nozīmīgu; Pārbaude ir zaļā krāsā, taču pat tad, ja programmatūra ir bojāta, tā to neuztvers. Šis ir AI risks numur viens kvalitātes nodrošināšanā, jo AI mēdz radīt testus, kas izskatās glīti, bet ir tukši.
2. Kāda ir visprecīzākā mākslīgā intelekta pozicionēšana testēšanas un kvalitātes nodrošināšanas procesā?
- A) Mākslīgais intelekts var izlemt, vai versiju var izlaist bez cilvēka apstiprinājuma
- B) Mākslīgais intelekts ir palīgs, kas ģenerē melnrakstus un idejas; Lēmums un atbildība par to, vai tas ir gatavs publicēšanai, ir ekspertam ✔
- C) Mākslīgais intelekts raksta tikai tekstu un vispār nevar tikt galā ar testa kodu
- D) Mākslīgais intelekts vienmēr raksta pareizu testu nekā cilvēks, tāpēc pārskatīšana nav nepieciešama
Apraksts: Mākslīgais intelekts ir testēšanas palīgs, projektu ģenerators un ideju pavairotājs; ražo testa scenārijus, automatizācijas kodu un atskaišu projektus. Tomēr atbildība un galīgais apstiprinājums par tādiem kvalitātes lēmumiem kā “vai šī programmatūra ir gatava publicēšanai” vai “vai šī pārbaude ir izturēta” pieder kompetentajam ekspertam.
3. Pamatojoties uz to, ka kļūdas galvenokārt rodas pie robežvērtībām, kāds testa projektēšanas paņēmiens ir atsevišķi pārbaudīt 17, 18 un 19 vecuma ierobežojumu 18 gadu vecumam?
- A) Stāvokļa pārejas tests
- B) Lēmumu tabula
- C) Robežvērtību analīze ✔
- D) Izpētes pārbaude
Paskaidrojums: Robežvērtību analīze balstās uz novērojumu, ka kļūdas visbiežāk rodas robežās, un atsevišķi pārbauda sliekšņa vērtības (tieši zem, nedaudz virs un nedaudz virs robežas). Tā ir spēcīga tehnika, kas papildina ekvivalences klases.
4. Kurai pieejai būtu jādod priekšroka elementu atlasē, lai samazinātu trauslumu UI testa automatizācijas kodā, kas izveidots ar mākslīgo intelektu?
- A) Izmantojot garāko iespējamo XPath ceļu
- B) Elementa atlase atbilstoši tā pikseļu pozīcijai ekrānā
- C) Selektoru izmantošana, pamatojoties uz CSS klašu nosaukumiem
- D) Testēšanai pievienoto stabilu atribūtu (data-testid) izmantošana ✔
Paskaidrojums: garie XPath ceļi un CSS klašu nosaukumi ir ļoti atkarīgi no lapas struktūras un dizaina; Tas sabojājas pie mazākajām saskarnes izmaiņām. Stabilus atribūtus, kas pievienoti īpaši testēšanai (piemēram, datu testēšana), dizaina izmaiņas neietekmē, un tie padara testus stabilus.
5. Kāpēc API testā nepietiek tikai ar HTTP statusa koda pārbaudi (piem., 200)?
- A) Tā kā ķermeņa dati ar pareizu statusa kodu var tikt bojāti, un tikai statusa pārbaude to nenovērs (pseidouzticība) ✔
- B) Jo statusa kodi API testos vispār nav uzticami
- C) Jo statusa koda pārbaude ļoti palēnina testu
- D) jo statusa kods nekad netiek atgriezts API testos
Paskaidrojums. Lai gan serveris atgriež pareizo statusa kodu, tas var atgriezt bojātus datus pamattekstā (nepareizs veids, trūkst lauka, nepareizi aprēķināta vērtība). Tests, kas skatās tikai uz situāciju, to nevar redzēt un sniedz nepatiesu pārliecību. Tātad jāpievieno arī shēmas/līguma un biznesa noteikumu validācija.
6. Kāpēc ir ļoti svarīgi norādīt AI “manuāli aprēķināt sagaidāmo vērtību saskaņā ar pieņemšanas noteikumu, neatsaucoties uz funkcijas pašreizējo izvadi”, drukājot vienību testus?
- A) Tā kā manuālais aprēķins testus veic ātrāk
- B) Jo pretējā gadījumā tests pieņem pašreizējo (iespējams, kļūdaino) koda uzvedību kā "pareizu" un apstiprina kļūdu ✔
- C) Jo mākslīgais intelekts vispār nevar aprēķināt decimālskaitļus
- D) Tā kā testos nekad neizmanto pieņemšanas noteikumus
Paskaidrojums: ja AI iegūst sagaidāmo vērtību no pārbaudāmās funkcijas izvades, tas liks testam “izturēt” pat tad, ja funkcija ir bojāta; Tas nozīmē, ka neatkarīgi no koda radītā pārbaude tiek uzskatīta par patiesu. Paredzamās vērtības aprēķināšana neatkarīgi no pieņemšanas noteikuma nodrošina, ka tests ir noteikuma vārtsargs, nevis koda spogulis.
7. Kura no šīm iezīmēm ir vislabākā kļūdu ziņojuma atšķirīgā iezīme?
- A) Lai tas būtu pēc iespējas garāks un tehniskāks
- B) Rakstījis mākslīgais intelekts
- C) satur deterministiskas reproducēšanas darbības, kurām izstrādātājs var sekot neatkarīgi un radīt kļūdu ✔
- D) Tas ir tikai ekrānuzņēmums
Paskaidrojums. Kļūdu ziņojuma patiesā vērtība ir tāda, ka izstrādātājs var reproducēt kļūdu bez jūsu palīdzības. To nodrošina deterministiski, izsekojami reproducēšanas soļi no nulles; Ja šīs darbības nav veiktas, pārskats bieži tiek aizvērts ar paziņojumu “nevarēja izveidot”.
8. Kura ir visprecīzākā izteiksme attiecībā uz smaguma pakāpi un prioritāti uzņēmuma nosaukuma nepareizas rakstības kļūdā mājaslapā?
- A) Intensitātei un prioritātei vienmēr jābūt vienādai vērtībai
- B) Gan šīs kļūdas smagums, gan prioritāte noteikti ir zema
- C) Smagums un prioritāte ir viens un tas pats jēdziens, pietiek ar vienu etiķeti
- D) Tehniskā intensitāte var būt zema, bet biznesa prioritāte (reputācija) var būt augsta; Abas tiek vērtētas atšķirīgi ✔
Paskaidrojums: Nopietnība ir kļūdas tehniskā ietekme (tehniski zema drukas kļūda), prioritāte ir tas, cik steidzami tā ir jānovērš (augsta, jo tas ir reputācijas elements, ko redz katrs apmeklētājs). Abi ne vienmēr iet vienā virzienā; Šis piemērs ir zemas smaguma pakāpes un augstas prioritātes situācija.
9. Kura ir visprecīzākā testa komplekta interpretācija ar 90% līnijas pārklājumu?
- A) Tas parāda, ka līnijas ir izpildītas, bet nepierāda, ka tās darbojas pareizi; ✔ augsts pārklājums var radīt nepatiesu pārliecību
- B) pārliecinoši pierāda, ka 90% programmatūras ir bez kļūdām
- C) Tas ir galīgs izcilas testa kvalitātes rādītājs.
- D) Norāda, ka vairs nav jāraksta papildu testi
Paskaidrojums: rindu pārklājums norāda, ka tika izpildītas tikai rindas; Tas nepierāda, ka tas rada pareizus rezultātus. Pat ar nepārliecinošiem testiem var sasniegt 90% pārklājumu. Darbības joma ir karte, kur nekad nav skatījies, nevis garantija, ka viss ir pārbaudīts; faktisko aizsardzību mēra ar mutāciju testēšanu.
10. Kā uz risku balstītā testēšanā tiek aprēķināts funkcijas risks, lai novirzītu ierobežotu testēšanas piepūli?
- A) Tikai pēc koda rindu skaita
- B) reizinot kļūmes iespējamību un efektu, kas radīsies, kad tas sabojājas ✔
- C) Tikai tādā secībā, kādā tika izstrādāta funkcija
- D) Dodiet priekšroku tikai tam līdzeklim, kuram ir visvieglāk rakstīt testus
Paskaidrojums. Uz risku balstītā testēšanā risku novērtē kā varbūtību = varbūtību (bojājuma iespējamību) × ietekmi (bojājumu, ja sabojājas). Augstas varbūtības un lielas ietekmes domēni (maksājums, autentifikācija) ir pelnījuši visintensīvāko pārbaudi, savukārt zema × zema domēni saņem vieglu testēšanu.
11. Kāds ir galvenais risks, pievienojot atkārtotu mēģinājumu pārbaudei, kas dažkārt izdodas un dažreiz neizdodas (trausls/pārslāņojošs), lai gan kods nav mainījies?
- A) Testa darbības laika saīsināšana
- B) Samazina pārklājuma procentus
- C) Patiesas vienlaicības kļūdas vai pamatcēloņa slēpšana un simptoma nomākšana ✔
- D) Pārbaudes nosaukuma maiņa
Paskaidrojums: Atkārtots mēģinājums ir diagnostikas rīks, nevis ārstēšana. Neizlēmība bieži rodas no faktiskā rases stāvokļa vai atkarības; Atkārtoti mēģinot testu izturēt, šī patiesā kļūda tiek noslēpta un var radīt nopietnas problēmas tiešraidē. Vispirms ir jāatrod galvenais cēlonis.
12. Kā darbojas mutāciju testēšana, visgodīgākā metode, kā noteikt, vai testa komplekts patiešām aizsargā?
- A) Mērot testu braukšanas ātrumu
- B) Saskaitot, cik koda rindiņas tika uzrakstītas
- C) Izpildot testus dažādos secībās
- D) apzināti veidojot nelielus pārtraukumus kodā un izmērot, vai testi tos uztver ✔
Apraksts: mutāciju pārbaude rada nelielus tīšus izkropļojumus (mutācijas) avota kodā; Labam testa komplektam vajadzētu uztvert šos traucējumus un kļūt sarkaniem. Mutācijas, kas nav noķertas (izdzīvojušas), norāda, ka testi nesaglabā šo uzvedību. Mutācijas rādītājs ir daudz godīgāks kvalitātes rādītājs nekā procentuālais pārklājums.
13. Kāds ir galvenais ierobežojums, kas jāievēro, veicot drošības testus (piem., autorizācijas/IDOR testus)?
- A) Aizsardzības nolūkos to drīkst darīt tikai ar savu produktu, ievērojot rakstisku atļauju un noteiktu darbības jomu ✔
- B) To var brīvi piemērot jebkurai interešu sistēmai
- C) To var izmēģināt biznesa partneru dzīvajās sistēmās bez atļaujas
- D) Visas atklātās ievainojamības nekavējoties jāpublicē publiski.
Apraksts: Šajā modulī apgūtās drošības pārbaudes ir paredzētas tikai jūsu produkta testēšanai aizsardzības nolūkos, ievērojot rakstisku atļauju un noteiktu darbības jomu. Piekļuve kāda cita sistēmai bez atļaujas vai ārpus darbības jomas pārbaudes ir gan neētiska, gan nelikumīga; Par visām atklātajām ievainojamībām tiek ziņots, atbildīgi atklājot informāciju.
14. Kādas pilnvaras nekādā gadījumā nedrīkst piešķirt AI CI/CD konveijerā?
- A) Nesekmīgo testu žurnālu apkopošana
- B) Pilnvara automātiski “nokārtot” nesekmīgu (sarkano) testu vai nokrāsot to zaļā krāsā ✔
- C) Testa koda uzmetuma ieteikšana
- D) Cauruļvada YAML faila izstrāde
Apraksts: AI var izveidot testa koda kontūru, konveijera YAML un žurnāla kopsavilkumu CI/CD; tomēr nekad nevajadzētu dot iespēju automātiski “nokārtot/labot” nesekmīgu testu. Tas pārspēj testēšanas mērķi un automātiski aizsedz kļūdas. Testa krāsošanai zaļā krāsā ir jābūt cilvēka apzinātam un pamatotam lēmumam.