Yunit 9 / 11

Pagsusuri ng Regression, Pagpapanatili ng Pagsusulit, at Paglaban sa Mga Marupok na Pagsusuri

Mga nadagdag:

  • Unawain ang layunin ng pagsusuri sa regression at makapili ng mga pagsubok at makagawa ng mga kaso ng regression ayon sa mga pagbabago gamit ang artificial intelligence
  • Kakayahang mag-diagnose ng mga ugat na sanhi ng marupok na mga pagsusuri (timing, order dependency, shared state, external dependency) at maglapat ng mga permanenteng solusyon nang hindi pinipigilan ang sintomas
  • Kakayahang mapanatili ang disiplina sa pagpapatakbo ng buong package pre-release habang pinapanatili ang regression suite na mabilis, independyente at maaasahan sa pamamagitan ng pag-aalis ng duplicate na pagsubok

Patuloy na nagbabago ang software; Ang bawat bagong feature, bawat pag-aayos, ay maaaring masira ang isang bagay na nagtrabaho noon. Ang kasunod na pagkagambala ng isang dating gumaganang function ay tinatawag na regression. Ang regression testing ay muling sinusuri ang umiiral nang functionality sa bawat pagbabago para mahuli ang mga degradasyong ito. Sa paglipas ng panahon, lumalaki ang mga test suite na ito — libu-libong pagsubok — at dalawang malalaking problema ang lumitaw: bumagal ang suite, at mga patumpik-tumpik na pagsubok — mga hindi mapagkakatiwalaang pagsubok na minsan ay pumasa at minsan ay nabigo sa parehong code — sumisira sa tiwala ng koponan sa mga resulta ng pagsubok. Ang artificial intelligence (AI) ay isang makapangyarihang tulong sa pagpapanatiling maayos, mabilis at maaasahan ang regression suite. Ngunit nananatili ang gitnang caveat: Bagama't maaaring mag-alok ang AI na "ipasa" ang isang marupok na pagsubok, madalas itong makagawa ng isang patch na sumasaklaw sa isang tunay na bug. Ang iyong trabaho ay hanapin ang ugat ng kawalang-tatag, hindi sugpuin ang sintomas.

Mga ugat na sanhi ng marupok na mga pagsubok

Ang marupok na pagsubok ay ang pinaka mapanlinlang na problema sa pagsubok: ito ay hindi mapagkakatiwalaan kung ito ay pumasa o nabigo, na nagtutulak sa koponan sa ugali na "ito ay dapat na-stuck muli, patakbuhin ito muli" — at ang ugali na ito ay balang-araw ay balewalain ang isang tunay na bug bilang "tumpik-tumpik". Mga pangunahing sanhi ng:

  • Kondisyon sa timing/race: Sinusuri ng pagsubok ang resulta nang hindi naghihintay na matapos ang isang operasyon. Ang pinakakaraniwang dahilan.
  • Dependency sa order: Nakadepende ang mga pagsubok sa data na iniwan ng bawat isa; Nasira ito kapag nagbago ang order.
  • Nakabahaging kaso: Maraming pagsubok ang gumagamit ng parehong data ng pagsubok/user, magkasalungat.
  • Panlabas na dependency: Tunay na network, serbisyo ng third-party, oras ng system, random na halaga.
  • Pagkakaiba sa kapaligiran: Lumipat sa lokal, nananatili sa CI (continuous integration environment).
Mag-ingat: Ang pagpasa sa isang marupok na pagsubok sa pamamagitan ng "muling pagsubok ng ilang beses" ay kadalasang nagtatakip ng isang tunay na concurrency error. Ang muling subukan ay isang diagnostic tool, hindi isang paggamot. Hanapin muna ang ugat; Gamitin lamang ang muling subukan bilang huling paraan para sa dokumentado, tunay na panlabas na kawalang-tatag.

Pagpapanatili ng pagsubok: pagpapanatiling malusog ang pakete

Ang regression suite ay parang hardin; Kung hindi aalagaan, ang mga damo ang hahabulin. Tumutulong ang AI sa tatlong gawain sa pagpapanatili:

1. Duplicate/hindi kinakailangang pagsubok na paglilinis. Sa paglipas ng panahon ang isang malaking bilang ng mga kaso ay nag-iipon ng pagsubok sa parehong bagay. Iminumungkahi ng AI ang pagpapangkat at pagsasama-sama ng mga katulad na pagsubok.

2. Marupok na pagsusuri sa pagsusuri. Ibinibigay mo sa AI ang test code at ang pattern ng kawalang-tatag; nagmumungkahi ng mga posibleng ugat na sanhi at permanenteng solusyon.

3. Pagsubok sa pagpili/pagbibigay-priyoridad. Mahal na patakbuhin ang buong pakete sa bawat pagbabago. Sa pagsusuri ng epekto ng pagsubok (pagpili lamang ng mga nauugnay na pagsubok batay sa binagong code), inirerekomenda ng AI kung aling mga pagsubok ang dapat unang tumakbo. Gayunpaman, ang buong pakete ng pre-release ay kinakailangan.

Quarantine: tamang pamamahala sa marupok na pagsubok

Nalaman mo na ang isang pagsubok ay marupok, ngunit wala kang oras upang ayusin kaagad ang ugat. Ano ang gagawin? Mayroong dalawang maling paraan: upang ganap na tanggalin ang pagsubok (ang pag-uugali na iyon ay hindi na napanatili) o patahimikin ito sa isang muling pagsubok (pagtakpan ang totoong bug). Ang tamang paraan ay ang pag-quarantine (pansamantalang ihihiwalay ang marupok na pagsubok mula sa pangunahing pakete at subaybayan ito sa isang hiwalay na listahan). Hindi pinipigilan ng quarantine na pagsubok ang pagsasama ng bersyon, ngunit nananatiling nakikitang utang at regular na tinutugunan. Ang kritikal na punto ay ito: ang quarantine ay isang waiting room, hindi isang basurahan. Kung ang listahan ng quarantine ay lumalaki, ito ay isang alarma na ang pagsubok sa kalusugan ng koponan ay lumalala. Maaaring pana-panahong suriin ng AI ang iyong listahan ng quarantine at ipangkat ito ayon sa mga pattern ng ugat; Nagbibigay-daan ito sa mga kolektibong solusyon sa pamamagitan ng paglalahad ng mga karaniwang dahilan, gaya ng "lahat ng 6 na pagsubok ay konektado sa parehong nakabahaging gumagamit ng pagsubok."

Tip: Magdagdag ng "may-ari" at "huling nasuri na petsa" sa bawat tala ng quarantine. Ang derelict quarantine ay nagiging permanenteng dump; Ang mga malutong na pagsubok ay nabubuhay doon magpakailanman dahil walang nagmamalasakit.

Talahanayan ng diskarte sa pagbabalik

Katayuan

Diskarte

Papel ng AI

maliit na pagwawasto

Apektadong lugar + pagsubok sa usok

Pumili ng mga nauugnay na pagsubok

bagong feature

Kaugnay na module + integration

Magmungkahi ng bagong regression case

malaking refactor

Buong pakete ng regression

Pagsusuri ng agwat ng saklaw

pre-release

Buong pakete + paggalugad

Pagtatantya ng priyoridad at tagal

Apurahang live na pag-aayos

Nakatuon + kritikal na landas

Minimum na set ng ligtas na pagsubok

Mahinang prompt / Malakas na prompt

Mahina: "Ang pagsubok na ito kung minsan ay nabigo, ayusin ito."
Strong: "Ang pagsusulit na ito ay nabigo sa 3 sa 10 na pagtakbo, hindi nabago ang code. I-diagnose ang ugat na sanhi ng kawalang-tatag: maaaring timing/race, order dependency, shared state, external dependency, o environment difference. Ipakita kung aling linya sa pagsubok ang tumuturo sa bawat posibleng dahilan. Magmungkahi ng permanenteng solusyon; HUWAG magmungkahi ng symptom-suppressing solution gaya ng 'add retryable' — malinaw na dahilan kung hindi.

Napakahusay na prompt; nagdidirekta ng diagnosis sa ugat na sanhi at tahasang ipinagbabawal ang pagpigil sa sintomas.

Apat na maaaring kopyahin na mga template

1) Marupok na pagsusuri sa pagsusuri:

Ang test code na ito kung minsan ay pumasa at kung minsan ay nabigo nang walang pagbabago. Ilista ang mga kandidatong pinag-ugatan (lahi, order dependency, shared state, external dependency, orasan/random, environment difference) at ipakita ang linya ng ebidensya sa pagsusulit para sa bawat isa. Magmungkahi ng permanenteng solusyon; markahan ang suppressive na solusyon tulad ng muling subukan bilang huling paraan at may katwiran. Pagsubok: [code] / Instability pattern: [ilang beses sa ilang pagtakbo]

2) Pagmumungkahi ng isang regression case:

Ang sumusunod na pagbabago ay ginawa: [change/PR summary].Ilista ang KASALUKUYANG pag-uugali na masisira ng pagbabagong ito at magmungkahi ng regression test case para sa bawat isa. Partikular na i-highlight ang mga lugar ng mga side effect at shared dependencies.

3) Duplicate na paglilinis ng pagsubok:

Tingnan ang test suite sa ibaba. Igrupo ang duplicate o overlapping na mga kaso na sumusubok sa parehong gawi; Magmungkahi kung alin ang dapat kong panatilihin at kung alin ang dapat kong pagsamahin para sa bawat pangkat. Magbabala kung may panganib na mawalan ng coverage. Mga pagsubok: [listahan/code]

4) Pagpili ng epekto ng pagsubok:

Ang mga sumusunod na file/function ay nagbago: [list]. Mula sa umiiral na test suite, piliin at bigyang-katwiran ang mga pagsubok na kailangan kong patakbuhin muna (yaong mga direktang/di-tuwirang naka-link sa binagong code). Tandaan: ipaalala sa akin na tatakbo pa rin ako sa buong pre-release suite.

tatlong mini case

Case 1 — Ang totoong pagkakamali ay tinakpan ng Subukang Muli. Nagdagdag ang isang koponan ng 3 muling pagsubok sa paminsan-minsang natitirang pagsubok sa payout; Ang pagsubok ay palaging "pagpapasa" ngayon. Ang paglalapat ng "fragile test diagnostic" ay natagpuan na ang kawalang-tatag ay nagmula sa isang tunay na kondisyon ng lahi: sa mataas na pagkarga, minsan ay doble-proseso ang kumpirmasyon ng pagbabayad. Sa loob ng maraming buwan, Retry na tinakpan ang isang bug na maaaring magresulta sa aktwal na pagkawala ng pera nang live. Naayos ang sanhi ng ugat, muling subukang alisin.

Kaso 2 — Lumiit ang package, tumaas ang bilis. Ang isang regression suite ng 1,400 na pagsubok ay tumagal ng 55 minuto. Sa pamamagitan ng "duplicate test cleaning", 380 na pagsubok ay naging mga duplicate o sakop; pinagsanib. Ang pakete ay nabawasan sa 900 mga pagsubok, ang oras ay nabawasan sa 34 minuto, ang saklaw ay hindi masusukat na nabawasan. Hinikayat ng mas mabilis na feedback ang koponan na subukan ang mas madalas.

Kaso 3 — Pagdepende sa order. Ang isang pagsubok ay palaging pumasa sa lokal, ngunit ito ay random na mabibigo sa CI. Ipinakita ng mga diagnostic ng AI na ang pagsubok ay nakadepende sa user na ginawa ng isa pang pagsubok, sa CI ito ay nasira dahil ang mga pagsubok ay tumakbo sa parallel/iba't ibang pagkakasunud-sunod. Ang bawat pagsubok ay ginawa upang magtatag ng sarili nitong data; Tapos na ang pag-aalinlangan.

Mga karaniwang pagkakamali

  • Pinapatahimik ang marupok na pagsubok sa muling pagsubok. Sinusubukang muli nang hindi hinahanap ang ugat na dahilan; pagtakpan ang tunay na pagkakamali.
  • "Natigil muli" kultura. Regular na hindi pinapansin ang mga pulang resulta; Isang araw, laktawan ang tunay na pagkakamali.
  • Hindi pinuputol ang pakete sa lahat. Nagbibigay-daan sa mga duplicate na pagsubok na itambak at pabagalin ang package.
  • Dependency sa pagitan ng mga pagsubok. Ang mga pagsusulit ay batay sa karaniwang kondisyon/pagkakasunod-sunod; pinagmulan ng kawalan ng katiyakan.
  • Sinusuri lamang ang binagong bahagi at laktawan ang buong pakete. Pre-release shortcut; Nakatakas ang mga nakatagong side effect.
  • Umaasa sa panlabas na dependency. Mga pagsubok batay sa aktwal na halaga ng network/orasan/random; natural na hindi matatag.

Sa buod

Ang pagsubok ng regression ay nakakakuha ng mga pagbabago na sumisira sa mga dating gumaganang function; Ngunit habang lumalaki ang mga pakete, ang kabagalan at malutong na pagsubok ay nakakasira ng tiwala. Ang pangunahing sanhi ng marupok na pagsubok ay karaniwang timing, order dependency, shared state, at external na dependencies. Ang AI ay isang malakas na tulong sa pagsusuri, paglilinis at pagpili ng pagsubok; Ngunit ang pagpigil sa pag-aalinlangan sa pamamagitan ng muling pagsubok ay sumasaklaw sa mga tunay na pagkakamali. Hanapin ang ugat na sanhi, gumawa ng mga pagsusulit na independyente at deterministiko, putulin ang pakete nang regular, patakbuhin ang buong pakete bago ilabas.

Gawain ng aplikasyon

Pumili ng pagsubok mula sa sarili mong proyekto na alam mong marupok (o parang hindi matatag). I-extract ang mga kandidato sa ugat at i-verify ang mga linya ng ebidensya sa pagsusulit gamit ang template na "fragile test diagnosis". Kilalanin ang ugat na sanhi at ipatupad ang isang permanenteng solusyon nang hindi sinusubukang muli. Pagkatapos ay pumili ng 10 pagsubok mula sa iyong package at hanapin ang mga maaaring isama sa "duplicate na paglilinis ng pagsubok." Iulat kung gaano karaming mga pagsubok na kawalang-katatagan ang iyong nalutas mula sa kanilang ugat at kung gaano karaming mga hindi kinakailangang kaso ang iyong inalis mula sa suite.

checklist

  • [ ] Nasuri ko ang ugat ng marupok na pagsubok; Hindi ko pinigilan ang sintomas.
  • [ ] Itinuring kong Retry bilang isang makatwirang huling paraan, hindi isang lunas.
  • [ ] Ginawa kong independyente at deterministiko ang mga pagsusulit (nahihiwalay sa mga panlabas na dependency).
  • [ ] Pinutol ko ang mga duplicate/hindi kinakailangang pagsubok mula sa regression suite.
  • [ ] Pinili kong subukan batay sa pagbabago, ngunit pinatakbo ang buong package na pre-release.
  • [ ] Sineseryoso ko ang bawat pula, laban sa kulturang "natigil muli, pumasa".