Vienība 1 / 11

Ievads mākslīgajā intelektā programmatūras testēšanā un kvalitātes nodrošināšanā: lomas, robežas, viltojumu risks un validācija

Ieguvumi:

  • Spēja atšķirt, kur mākslīgais intelekts ietaupa reālo laiku kvalitātes nodrošināšanas procesā un kur kvalitātes lēmumi, piemēram, “gatavs publicēšanai”, tiek atstāti cilvēku ziņā atkarībā no uzdevuma riska līmeņa
  • Spēja atpazīt viltus izturēšanas risku un ieviest pārbaudes disciplīnu, kas pārbauda katru AI testu, apzināti laužot kodu
  • Spēja aizsargāt testa datus, personas datus un atslēgas un iegūt ieradumu veikt drošības testēšanu tikai autorizācijas ietvaros un aizsardzības nolūkos.

Apsveriet atbrīvošanas vakaru. Tika izpildīti simtiem testu, tie visi saņēma zaļo gaismu, komanda tika atvieglota un programmatūra sāka darboties. Nākamajā rītā klients ziņoja, ka maksājuma ekrāns ir avarējis. Pārbaudes bija zaļas, bet viņš neredzēja kļūdu. Šis ir kvalitātes nodrošināšanas (QA) profesijas mānīgākais murgs, tas ir, disciplīna, kas sistemātiski nodrošina, lai programmatūra būtu vēlamajā kvalitātē: tests, kas spīd zaļā krāsā, bet faktiski neko neapstiprina. Kad šajā profesijā ienāk mākslīgais intelekts (AI — programmatūra, kas izvelk modeļus no vēsturiskiem datiem un ģenerē tekstu un kodu), notiek gan milzīgs paātrinājums, gan tieši šī murga palielinājums. Sākotnējais šī moduļa solījums ir skaidrs: AI ir testēšanas palīgs, projektu ģenerators un ideju pavairotājs; Jūs esat testētājs, kurš parakstās par lēmumu “vai šī programmatūra ir gatava izlaišanai”.

Šajā pirmajā nodaļā mēs koncentrēsimies uz disciplīnu, nevis instrumentu. Jūs uzzināsit, kur AI ietaupa reālo laiku kvalitātes nodrošināšanas procesā, kur tas ir bīstami, kāpēc maldinošā zaļā tā sauktā "viltus piespēle" ir lielākais risks, kā pārbaudīt katru izvadi un kādus datus varat sniegt kādam rīkam. Neliekot šo pamatu, turpmākās vienības paliks gaisā.

Kur AI noder testēšanas procesā?

Sadalīsim testēšanas darbus divās lielās kopās. Pirmā grupa: atkārtoti, producējami, melnraksti darbi. Pārbaudes gadījuma sastādīšana no prasības, pārtraukuma punktu uzskaitīšana, automatizācijas koda skeleta rakstīšana ekrānam, sarežģīta kļūdas gadījuma pārvēršana glītā kļūdu ziņojumā, simtiem žurnālfailu rindu apkopošana, shēmas izvilkšana no API atbildes. Veicot šos uzdevumus, mākslīgais intelekts samazina minūtes līdz sekundēm un nenogurst.

Otrais klasteris: lēmumi, kuru rezultāts ir kvalitāte, uzticēšanās un atbildība. Lai pieņemtu lēmumus, piemēram, "vai šī versija var tikt nodota tiešsaistē", "vai šī kļūda ir kritiska vai to var atlikt", "vai šis testa pārklājums ir pietiekams", "vai šis scenārijs aptver reālu lietotāja risku" utt., Nepieciešams konteksts, zināšanas par produktu un atbildība. Šeit mākslīgais intelekts ģenerē opcijas, melnrakstus, bet jūs izlemjat “atbilst/neatbilst” un “aiziet/neiet”.

Noskaidrosim atšķirību vienā teikumā: AI ir spēcīgs, "kādas situācijas var pārbaudīt un kā uzrakstīt kodu, kas to pārbauda"; Lēmums ir jūsu ziņā, ja runa ir par jautājumu "Vai šī programmatūra patiešām darbojas un kas par to garantē?"

Padoms. Pirms nododat darbu AI, jautājiet: “Kas notiek, ja šī izvade ir nepareiza un es nepamanu?” Ja atbilde ir "Es zaudēšu dažas minūtes", deleģējiet to viegli. Ja atbilde ir "bojāta programmatūra darbojas tiešsaistē", ļaujiet AI sagatavot melnrakstu, un jūs pieņemat lēmumu un pārbaudiet.

Viltus apstiprinājums: AI risks numur viens kvalitātes nodrošināšanā

Kad tests iedegas zaļā krāsā, tas var nozīmēt divas lietas: vai nu programmatūra faktiski darbojas pareizi, vai arī tā neredz kļūdu, jo tests ir uzrakstīts nepareizi. Otro sauc par viltus nokārtošanu — tests saka "ieskaitīts", bet faktiski neko neapstiprina. Šis risks ievērojami palielinās testos, kas izgatavoti ar AI, jo AI ļoti veiksmīgi raksta raitu, gludu, bet tukšu testu.

Trīs visizplatītākie pseidopārbaudes veidi ir: (1) Testēšana bez apgalvojuma — kods darbojas, nesatur apgalvojumus, vienmēr iztur. (2) Pašpārbaudes tests — testa paredzamo vērtību aprēķina no pārbaudāmā koda izvades; Tas ir, neatkarīgi no koda radītā testa pieņem kā "pareizu". (3) Tests, kas pārbauda nepareizo lietu — apgalvojums pastāv, bet pārbauda kaut ko nenozīmīgu (piemēram, “atbilde nav nulles”), nevis faktisko uzņēmējdarbības noteikumu.

Uzmanību: zaļš testa panelis nav kvalitātes pierādījums; Labākajā gadījumā tas saka: "vadības ierīces, kuras mēs rakstījām, šobrīd nav bojātas". Neļaujiet sevi mierināt, redzot, ka mākslīgais intelekts ir izturējis testu — patiesais jautājums ir: vai šis tests kļūs sarkans, ja es apzināti pārkāpšu kodu? Ja tas negriežas, šis tests ir dekorācija.

Zelta likums, kas atkārtojas visā šajā modulī: pārbaudiet katru AI testu, apzināti laužot kodu. Ja tests joprojām ir zaļš, šis tests nedarbojas. (Mēs padziļināsim šo ideju kā mutāciju testēšanu 10. nodaļā.)

Pārbaudes disciplīna: trīs soļi

AI runā ar pārliecību; Tas nenozīmē, ka tā ir patiesība. Izstrādājiet trīspakāpju refleksu, ko piemērot katram rezultātam:

  1. Piesaistiet to prasībai. Katram testa piemēram un apgalvojumam, ka AI ražo, ir jābalstās uz reālām prasībām vai pieņemšanas kritērijiem (nosacījumiem, kuriem ir jāatbilst darbam, lai to uzskatītu par "pabeigtu"). "Kuru noteikumu apstiprina šis scenārijs?" jautāt.
  2. Skatīt sarkano. Vienreiz palaidiet ģenerēto testu, pārtraucot kodu. Ja tas nekļūst sarkans, tests ir nederīgs. Šis ir neapspriežams solis AI testēšanā.
  3. Izlaidiet to caur konteksta filtru. Vai izvade atbilst produkta uzvedībai, arhitektūrai, faktiskajai lietotāju plūsmai? Jūsu domēna zināšanas ir pēdējais filtrs.

Datu konfidencialitāte un drošība: kas kur nonāk?

Dati, ar kuriem strādājat testa vidē, bieži ir sensitīvi: reāli klientu ieraksti, ražošanas datu bāzes kopijas, API atslēgas, iekšējās sistēmas adreses, līdzekļi, kas vēl nav paziņoti. Izveidojiet vienkāršu klasifikāciju: atvērtos datus (dokumentēti, publiski pieejami) var ievadīt jebkurā transportlīdzeklī. Iekšējie dati (avota koda fragmenti, iekšējā dokumentācija) tikai aģentūras apstiprinātiem rīkiem. Konfidenciālie dati (reālie klienta dati, identitātes informācija, ievainojamības detaļas, atslēgas) nonāk tikai iestādes līgumā noslēgtajos rīkos, kuru dati nenonāk modeļu apmācībā, vēlams maskēti.

Drošības testēšanas kontekstā ir papildu ierobežojums: viss, kas šajā modulī tiek apgūts, ir paredzēts aizsardzības nolūkos — lai autoritatīvi pārbaudītu sava produkta drošību. AI izmantošana, lai bez atļaujas iefiltrētos kāda cita sistēmā, izmantotu reālas ievainojamības vai pārbaudītu sistēmu, kurai jums nav pilnvaru, ir gan neētiska, gan noziedzīga. Neviena aizskaroša pārbaude netiks veikta bez atļaujas (joma un atļaujas).

Padoms. Izmantojiet sintētiskos (mākslīgi iegūtos) testa datus, nevis reālus klientu datus. Lūdzot AI “ģenerēt reālistiskus, bet pilnīgi izdomātus testa datus”, tiek saglabāta privātums un dažādoti malu gadījumi.

trīs mini futrāļi

1. gadījums — laika taupītājs īstajā vietā. Ekomerce komandas testētājs pavadīja 6 stundas, manuāli izveidojot testa scenāriju no 30 lappušu garā prasību dokumenta katram laidienam. Viņš iedeva dokumentu (to daļu, kurā nebija komercnoslēpumu) YZ un lūdza strukturētu scenārija projektu; Laiks tika samazināts līdz 90 minūtēm. Ietaupīto laiku viņš veltīja, lai pats pārbaudītu, pievienojot biznesa noteikumu malas gadījumus, kurus AI bija palaidis garām. AI atņēma atkārtoto darbu, atstājot spriedumu cilvēka ziņā.

2. gadījums — pieķerta viltota piespēle. Izstrādātājs AI lika rakstīt 12 vienību testus skaitļošanas funkcijai; viņi visi bija zaļi. Testētājs ieviesa darbību "skatīt sarkano": apzināti nomainot saskaitīšanas zīmi funkcijas iekšienē uz reizināšanu. Tikai 3 no 12 testiem bija sarkani. Pārējie 9 testi nesniedza reālu apstiprinājumu; Tas vienkārši teica: "Tas neizlaida kļūdu". Tika dzēsti 9 dekoratīvie testi un to vietā uzrakstīti 5 reāli testi.

3. gadījums — atgriešanās pēc privātuma pārkāpuma. Kāds praktikants publiskā rīkā ielīmēja kļūdu žurnālu, kurā bija reāli klientu e-pasta ziņojumi un kartes pēdējie četri cipari no ražošanas datu bāzes, un teica: "izskaidrojiet šo kļūdu". Kvalitātes nodrošināšanas vadītājs iejaucās: tie bija personas dati ārpus kontroles un KVKK (Personas datu aizsardzības likuma) pārkāpums. Tas pats darbs tika veikts iestādes apstiprinātā transportlīdzeklī, maskējot personīgās vietas un atstājot tikai skursteņa pēdas.

Četras kopējamas veidnes

1) Darba piemērotības novērtējums:

Jūsu loma: vecākais kvalitātes nodrošināšanas vadītājs. Es jums aprakstīšu pārbaudes darbu. Pastāstiet man (1) vai šis darbs ir izstrādes/analīzes darbs, ko var droši deleģēt AI, vai kvalitatīvs lēmums, kas jāpieņem cilvēkam, (2) iespējamās izmaksas par nepareizu rezultātu, (3) pārbaude, kas jāveic pirms deleģēšanas. Darbs: [ievietot darbu šeit]

2) Pseido caurlaides kontrole:

Pārbaudiet zemāk esošo testu. Pastāsti man:- Kādu uzvedību apstiprina šis tests? (viens teikums)- Kā es varu sabojāt pārbaudāmo kodu, lai tests kļūtu SARKANS?- Vai ir kāds trūkums, kura dēļ šis tests vienmēr var tikt izturēts (trūkst apstiprinājuma, pašpārbaudes, triviālas pārbaudes)?Pārbaude: [ielīmēt testu šeit]

3) Testa datu maskēšanas kontrole:

Žurnāls/dati, ko es jums sniegšu, var saturēt personiskus vai konfidenciālus laukus (e-pasts, vārds, karte, atslēga, iekšējā adrese). Vispirms uzskaitiet laukus, kas ir jāmaskē; Es maskēšu un nosūtīšu vēlreiz. Neanalizējiet to tādu, kāds tas ir.

4) Sintētisko testu datu ģenerēšana:

Ģenerējiet 20 rindas ar pilnīgi izdomātiem, reālistiskiem testa datiem [šādai lauka struktūrai]. Neizmantojiet reālas personas/organizācijas datus. Iekļaujiet arī malas gadījumus: tukša vieta, pārāk garš teksts, robežvērtības, nederīgs formāts.

Vāja uzvedne / spēcīga uzvedne

Vāji: "Rakstiet šī koda testus."
Strong: "Aprēķiniet šo Ierakstiet vienību testus atlaides funkcijai. Pieņemšanas kritēriji funkcijai: 10% atlaide virs 1000 TL, 20% atlaide virs 5000 TL; negatīvai summai jāmet kļūda. Komentāra rindiņā norādiet, kuru kārtulu validējat katram testam. Pārbaudiet robežvērtības (999, 1000, 0, 0,0) atsevišķi. apgalvojumi, kas kļūs sarkani, ja es pārkāpšu kodu vai nerakstīšu triviālu apgalvojumu.

Spēcīga uzvedne; Tajā ir sniegti pieņemšanas kritēriji, robežvērtības, apstiprināšanas prognozes un skaidri norādījumi pret viltošanu. Vāja uzvedne aicina AI uzrakstīt dekoratīvu testu.

Biežas kļūdas

  • Uzticoties zaļajam. Domāšana, ka eksāmena nokārtošana ir pierādījums. Patiesais jautājums ir: vai tas kļūst sarkans, kad pārtraucat kodu?
  • Pārbaudes pieprasīšana, nenorādot iemeslu. AI ražo vispārīgus, bieži vien bezjēdzīgus testus, nezinot, kas ir jāpārbauda.
  • Verifikācijas izlaišana. Sakot: "AI to uzrakstīja, iespējams, tā ir taisnība". Atbildība gulstas uz personu, kas izmanto produkciju.
  • Reālu/sensitīvu datu ielīmēšana rīkā. Darbs ar ražošanas datiem, atslēgām vai personas datiem.
  • Neatļauta drošības pārbaude. Aizskarošas pārbaudes mēģinājums bez darbības jomas un atļaujas.
  • AI izmantošana lēmumu pieņemšanas deleģēšanai. Uzdodot jautājumu "Vai šo versiju var izlaist?" AI un ievietojot atbildi parakstā.

Rezumējot

AI ir spēcīgs palīgs kvalitātes nodrošināšanas procesā, kas paātrina atkārtotu un produktīvu darbu; Bet atbildība par kvalitatīvu lēmumu gulstas uz cilvēku. Galvenais mākslīgā intelekta risks šajā profesijā ir pseido-pass: zaļie testi, kas izskatās glīti, bet neko neapstiprina. Pārbaudiet katru AI testu, apzināti laužot kodu; Ja tas nekļūst sarkans, šis tests ir dekorācija. Piesaistiet to prasībai, skatiet sarkano krāsu, izlaidiet to caur konteksta filtru. Maskējiet konfidenciālos datus, veiciet drošības pārbaudi tikai autorizētos un aizsardzības nolūkos.

Lietojumprogrammas uzdevums

Veiciet 5 AI ģenerētu (vai AI ģenerētu) vienību testus no sava projekta. Katram: (1) vienā teikumā pierakstiet, kādu uzvedību tas pārbauda, ​​(2) apzināti pārtrauciet un palaidiet pārbaudāmo kodu un atzīmējiet, cik daudz no tiem kļūst sarkani, (3) atzīmējiet tos, kas nekļūst sarkani, kā "dekoru testus" un pārrakstiet tos ar patieso apgalvojumu. Ievietojiet rezultātu tabulā: testa nosaukums / noteikums, ko tas pārbaudīja / vai tas tika bojāts, kad tika bojāts / darbība.

kontrolsaraksts

  • [ ] Pirms darba nodošanas uzdevu jautājumu "ko es zaudēšu, ja noies greizi?"
  • [ ] Es pārbaudīju katru AI testu, pārtraucot kodu; To, kas nekļuva sarkans, nomainīju pret īsto testu.
  • [ ] Es saistīju pārbaudes gadījumus ar faktiskajām prasībām/pieņemšanas kritērijiem.
  • [ ] Es maskēju sensitīvus/reālus datus, nenododot tos rīkam; Ja iespējams, izmantoju sintētiskos datus.
  • [ ] Es apsvēru drošības testēšanu tikai pilnvaru ietvaros un aizsardzības nolūkos.
  • [ ] Lēmumu "vai versija tiks izlaista" es atstāju sev, nevis AI ziņā.