Ieguvumi:
- Spēja atpazīt trīs pseidouzticības šķautnes (nepārliecinošs, pašapliecinošs, triviāls apgalvojums) un pielietot pretlīdzekļus
- Spēja izmantot mutāciju testēšanu un mutāciju rezultātu kā precīzāku kvalitātes mērauklu nekā procentuālais pārklājums ar instrumentu vai roku
- Spēja pozicionēt AI kā sarkano komandu pret testēšanu un meklēt pārbaudes nepilnības, neiekrītot slavēšanas slazdā
Šī moduļa pamatā ir atkārtots brīdinājums: zaļi mirdzošs testa panelis neliecina par kvalitāti. Ja jūsu testi sniedz jums pārliecību, jums jāzina, vai šī pārliecība ir patiesa vai viltota. Mākslīgā intelekta (AI) laikmetā šis jautājums ir kritiskāks nekā jebkad agrāk, jo mākslīgais intelekts spēj radīt plūstošus, gludus, bet tukšus testus. Nepatiesa pārliecība — uzskatīt, ka programmatūra ir pareiza, jo testi ir zaļi, lai gan patiesībā testi neko nepārbauda, ir visbīstamākā lieta, kas var notikt ar kvalitātes nodrošināšanas komandu; jo tas slēpj nevis to, ka kļūdu nav, bet gan to, ka jūs nevarat redzēt kļūdas. Šī vienība apvieno visa moduļa validācijas filozofiju vienā disciplīnā: testu testēšana.
Zelta standarts testēšanas kvalitātes mērīšanai: mutāciju pārbaude
Visefektīvākais veids, kā saprast, vai tests patiešām aizsargā vai nē, ir mutāciju pārbaude (mutāciju pārbaude — metode, kas rada tīšus nelielus izkropļojumus/mutācijas avota kodā un nosaka, vai testi atklāj šos traucējumus). Loģika ir vienkārša: ja jūs apzināti pārtraucat kodu (padarot + par -, > par >=, patiesu par false), labam testa komplektam vajadzētu uztvert šo bojājumu un kļūt sarkanam. Ja tā nenotiek, šis traucējums ir izdzīvojis mutants, tāpēc jūsu testi faktiski nesaglabā šo uzvedību.
Mutācijas rādītājs = mutācija nogalināta / kopējā mutācija. Paketē ar 90% līnijas pārklājumu mutācijas rādītājs var būt 40%; Tas norāda, ka līnijas darbojas, bet darbība nav pārbaudīta. Mutācijas rādītājs ir daudz godīgāks kvalitātes rādītājs nekā procentuālais pārklājums.
Padoms: ir automātiskie mutācijas rīki (PIT/Pitest Java, Stryker JavaScript/TypeScript, Stryker.NET .NET, mutmut Python). Tie automātiski ģenerē un pārbauda simtiem mutāciju. Ja jums nav rīka, pat manuālā metode "pārtraukt kodu testu" ir nenovērtējama kritisko funkciju veikšanai.
Pseidouzticības trīs sejas un tās pretlīdzeklis
Pseidouzticības forma
simptoms
pretlīdzeklis
Pārbaude bez apgalvojuma
Kods darbojas, nekas nav apstiprināts
Patiess apgalvojums katrā pārbaudē; tests ar mutāciju
pašpārbaudes tests
Paredzētais = koda izvade
Neatkarīgi aprēķiniet paredzamo vērtību
Triviāls apgalvojums
"nav null", "200 atgriezti"
Apstipriniet biznesa noteikumu/faktisko rezultātu
Liela apjoma maldīšanās
90% līniju, zema aizsardzība
Apskatiet mutācijas punktu skaitu
Trauslā testa tolerance
"Atkal iestrēdzis, iet garām"
Galvenais cēlonis + deterministiskā pārbaude
AI kā “sarkanās komandas” izmantošana
AI var gan radīt pseidouzticību, gan būt spēcīgs sabiedrotais tās medībās. Izmantojiet AI kā sarkano komandu pret saviem testiem: palūdziet “rakstīt kodu, kas iztur šos testus, bet ir nepareizs” vai “atrodi subversiju, kas apmānīs šos testus”. Ja AI jūsu pārbaudēs atklāj nepilnības, šīs nepilnības ir reāls risks.
Uzmanību: nejautājiet AI "Vai mana testa kvalitāte ir laba?" un uztveriet atbildi "jā, lieliski" kā pārliecību. AI mēdz būt laipns. Tā vietā izaiciniet AI veikt konkrētu uzdevumu: "izveidojiet kļūdu, kas iztur šos testus." Ja tas to var radīt, jūsu testi ir akli pret šo kļūdu.
Līdzvērtīgas mutācijas un punktu robežas
Mutāciju pārbaude ir spēcīga, taču tai ir āķis: dažas mutācijas nemaz nemaina koda uzvedību. Tās sauc par līdzvērtīgām mutācijām (ekvivalents mutants — bojāts kods, mutācija, kas rada tieši tādu pašu rezultātu kā oriģināls). Piemēram, mainot sākotnējo vērtību mainīgajam, kas nekad netiek izmantots, neietekmē izvadi; Neviens tests to nevar un nedrīkst uztvert. Tāpēc 100% mutācijas rezultāts praksē bieži vien nav sasniedzams, un tas nav mērķis. Līdzvērtīgu mutāciju atsijāšana ar rokām ir darbietilpīga; Tāpēc nelasiet mutācijas rezultātu kā absolūtu eksāmena rezultātu, bet gan kā godīgu rādītāju "vai mani testi patiešām aizsargā?"
Praktiskā pieeja ir šāda: tā vietā, lai pastāvīgi veiktu mutāciju testēšanu visā koda bāzē, palaidiet to moduļos, kas satur visaugstāko risku un sarežģītākos biznesa noteikumus. Pa vienam pārbaudiet šajos moduļos izdzīvojušās mutācijas; Ja tā ir reāla nepilnība, pievienojiet testu; ja tā ir līdzvērtīga mutācija, atzīmē to ar pamatojumu un nokārto. AI var veikt sākotnējo skrīningu, lai novērtētu, vai izdzīvojusi mutācija ir līdzvērtīga; bet galīgo lēmumu pieņemat jūs, kas zināt, ko dara kods.
Uzmanību: mutāciju pārbaude ir skaitļošanas ziņā dārga (visi attiecīgie testi tiek atkārtoti veikti katrai mutācijai). Tāpēc izplatīta un saprātīga stratēģija ir ieplānot to kā iknedēļas vai pirmsizlaides padziļinātu pārbaudi kritiskajiem moduļiem, nevis katru sapludināšanu.
Vāja uzvedne / spēcīga uzvedne
Vājš: "Vai mani testi ir pietiekami?"
Spēcīgi: "Rīkojieties kā sarkanā komanda šai funkcijai un testu komplektam. (1) Ģenerējiet 8 kodā mutācijas, kuras var iznīcināt (operatora aizstāšana, robežu maiņa, nosacījumu inversija, atgriežamās vērtības aizstāšana). (2) Katrai mutācijai norādiet arī, kurš no esošajiem testiem to uztvers un kurš NE. (3) Katrai mutācijai, kas izdzīvo, uzrakstiet jaunu piemēru, ja varat to iznīcināt (4), kas izturēs kodu. visus šos testus, bet pārkāpj uzņēmējdarbības noteikumu Kods+testi: [ielīmēt].
Spēcīga uzvedne; Tas pozicionē AI kā pārbaudes veicēju, nevis slavēšanas iekārtu.
Četras kopējamas veidnes
1) Manuāla mutāciju kontrole:
Šim kodam ģenerējiet 8 nozīmīgas mutācijas (nelielus apzinātus traucējumus): aritmētiskā operatora aizstāšana, salīdzināšanas robeža (> vs >=), loģiskā inversija, atgriešana/konstante aizstāšana, nosacījumu izlaišana. Katrai mutācijai paredziet, kurš no pieejamajiem testiem to uztvers vai nē. Kods + testi: [ielīmēt]
2) Izdzīvojušās mutācijas nogalināšana:
Šajā mutāciju testa ziņojumā ir iekļautas izdzīvojušās (nenoķertās) mutācijas: [saraksts/ziņojums]. Katram uzrakstiet minimālu testu, kas nogalinās šo mutāciju (kods kļūs sarkans, ja tas tiek sabojāts). Komentējiet, kādu uzvedību tests apstiprina.
3) Sarkanā komanda — asins analīzes:
Vai varat uzrakstīt kodu, kas IZTURĒ VISUS tālāk norādītos testus, bet pārkāpj šādu uzņēmējdarbības noteikumu: [biznesa noteikums]. Ja jā, kāda nepilnība šajos testos to pieļauj? Pievienojiet testu, kas novērsīs šo nepilnību. Pārbaudes: [ielīmēt]
4) Testa kvalitātes pārbaude:
Pārbaudiet šī testa komplekta kvalitāti. Atzīmējiet katru testu:- Vai ir patiess apgalvojums vai tas ir rekvizīti?- Vai paredzamā vērtība ir neatkarīga, iegūta no koda?- Vai tā pārbauda biznesa noteikumu vai kaut ko nenozīmīgu? Visbeidzot norādiet aptuveno "patieso apgalvojumu rezultātu" un 3 vājākos testus. Pārbaudes: [ielīmēt]
trīs mini futrāļi
1. gadījums — pārklājums 92%, mutācijas rādītājs 38%. Viena komanda paļāvās uz augstu pārklājumu. Kad mutāciju testēšana tika veikta ar Stryker, rezultāts bija 38%: lielākā daļa radīto mutāciju izdzīvoja. Tas bija pierādījums tam, ka testi nedarbojās un nepārbaudīja uzvedību. Komanda ieguldīja trīs nedēļas kvalitātes testēšanā; Mutāciju rādītājs palielinājās līdz 81%, un nākamajā laidienā šajos pastiprinātajos testos tika konstatētas divas reālas aprēķinu kļūdas.
2. gadījums — AI piemānīja testu. Izmantojot “sarkanās komandas” veidni, eksperts lūdza AI kodu, kas izturēja esošos testus, bet pārkāpa atlaides noteikumu. AI uzrakstīja kodu, kas vienmēr atgrieza nulles atlaidi, un visi testi palika zaļi, jo neviens tests nepārbaudīja faktisko atlaides vērtību. Redzams robs, pievienoti patiesi apgalvojumi.
3. gadījums — uzslavu slazds. Jaunākais testētājs jautāja AI: "Vai mani testi ir labi?" un jutās atvieglots, dzirdot atbildi: "Ļoti visaptveroša." Viņa vecākajam kolēģim tie paši testi tika pārbaudīti, izmantojot veidni "testa kvalitātes audits"; Izrādījās, ka 12 no 20 testiem bija dekori (bez apgalvojuma vai junk). Pareizais jautājums radīja pareizo atbildi.
Biežas kļūdas
- Kvalitātes maldināšana. Paļaujoties uz augstu rindu pārklājumu un vispār neskatoties uz mutācijas rādītāju.
- Uzticoties AI uzslavām. Jautāt: "Vai jūsu testi ir labi?" un uzskatot pozitīvo atbildi par pārliecību.
- Paredzamās vērtības atvasināšana no koda. Pašpārbaudes testi, kas apstiprina kļūdainu kodu.
- Esiet apmierināts ar triviāliem apgalvojumiem. Pārbaudes, kas neapstiprina faktisko kārtulu, piemēram, "not null", "200 return".
- Izdzīvojušo mutāciju ignorēšana. Ignorējot to, kas nebija notverts mutācijas ziņojumā.
- Pat nemēģinot manuāli mutēt kritisko kodu. Ja rīks nav pieejams, tiek izlaista darbība “pārlauzt kodu un pārbaudīt”.
Rezumējot
Pseidouzticība uzskata, ka programmatūra ir pareiza, jo testi ir zaļi; tā kā testi var neko neapstiprināt. Zelta standarts tā mērīšanai ir mutāciju pārbaude: apzināti laužot kodu un izmērot, vai testi to uztver. Mutācijas rādītājs ir daudz godīgāks kvalitātes rādītājs nekā procentuālais pārklājums. AI gan rada pseidouzticību, gan kļūst par spēcīgu sarkano komandu tās meklēšanā — palūdziet “izveidot kļūdu, kas iztur šos testus”. Pārbaudiet savus testus: patiess apgalvojums, neatkarīga paredzamā vērtība, biznesa noteikumu validācija un iznīcinātas mutācijas.
Lietojumprogrammas uzdevums
Importējiet funkciju, kurā ir biznesa kārtula un tās testi, no sava projekta. Ja iespējams, palaidiet mutācijas rīku (Stryker/Pitest/mutmut) un izmēra mutācijas punktu skaitu; Ja rīka nav, ģenerējiet vismaz 8 mutācijas ar "manuālās mutācijas kontroles" veidni un izmēģiniet tās manuāli. Katrai izdzīvojušajai mutācijai uzrakstiet jaunu testu ar veidni "nogalināt izdzīvojušo mutāciju". Visbeidzot, izmantojot “sarkanās komandas” modeli, pārbaudiet, vai AI var radīt kodu, kas maldina jūsu pārbaudes. Ziņojiet par sākuma un beigu mutācijas rezultātu (vai noķerto/kopējo mutāciju līmeni).
kontrolsaraksts
- [ ] Es novērtēju testa kvalitāti pēc mutācijas rādītāja, nevis pārklājuma.
- [ ] Es veicu mutāciju testēšanu (ar rīku vai manuāli) kritiskajam kodam.
- [ ] Es uzrakstīju jaunus testus katrai izdzīvojušajai mutācijai.
- [ ] Es izmantoju AI kā sarkano komandu un savos testos meklēju nepilnības.
- [ ] Es neuztvēru AI uzslavu “Jūsu testi ir labi” kā pārliecību.
- [ ] Es pārbaudīju, vai katrs tests pārbauda faktisko apgalvojumu, neatkarīgu paredzamo vērtību un biznesa noteikumu.