Pagsubok sa Produksyon at Quality Assurance

Mga nadagdag:

• Kakayahang gumawa ng unit testing, edge cases, at coverage gap analysis gamit ang AI
• Kakayahang mag-print ng mga inaasahan sa pagsubok batay sa detalye, hindi ang kasalukuyang gawi ng code
• Kakayahang subukan kung talagang nagpoprotekta ang isang pagsubok sa pamamagitan ng mga error sa pag-inject

Ang mga pagsusulit sa pagsulat ay isa sa mga gawaing nagbibigay ng halaga na pinakawalan ng karamihan sa mga developer. Ang isang magandang test suite ay patunay na gumagana ang code gaya ng inaasahan at isang lifeline para sa mga pagbabago sa hinaharap. Ang problema ay ang pagsusulat ng mga pagsusulit ay paulit-ulit at nakakaubos ng oras — eksakto ang uri ng trabaho kung saan kumikinang ang AI. Ngunit mayroong isang catch: madalas na sinusubok ng AI ang umiiral na pag-uugali ng code, hindi ang dapat na pag-uugali. Ang pamamahala sa pagkakaibang ito ay ang kakanyahan ng yunit na ito.

Sa unit na ito, matututo ka ng unit testing (pagsubok na sumusubok sa isang function na nag-iisa, sa paghihiwalay), edge case test at pagbuo ng data ng pagsubok gamit ang AI; pagsasara ng mga puwang sa saklaw ng pagsubok; at bakit mapanganib ang walang taros na pagtitiwala sa mga pagsubok sa AI.

Ang Dalawang Panig ng Pagsubok: Pag-aayos ng Gawi kumpara sa pag-verify

Ang pagsusulit ay maaaring maghatid ng dalawang magkaibang layunin. Ang una ay pag-verify: sinusubok nito kung tama ang code, na sumusunod ito sa detalye. Ang pangalawa ay ang proteksyon ng regression: pinapa-freeze nito ang pag-uugali ng code ngayon, kaya kung may isang tao na hindi sinasadyang baguhin ito bukas, ang pagsubok ay masisira at aabisuhan.

Ang AI ay napakahusay sa huli; Tinitingnan nito ang code at bumubuo ng mga kaso na sumusubok sa "kung ano ang ginagawa nito ngayon." Ngunit kung mali ang code sa simula, maaaring i-pin ng AI ang maling gawi na iyon bilang "tama." Kaya dapat mong suriin ang assertion ng bawat pagsubok na ginawa ng AI: "Ang code ay nagbabalik ng 42 at ang pagsubok ay umaasa ng 42" ay hindi nangangahulugan na ang 42 ay ang tamang sagot.

Pag-iingat: Kung ang AI ay pumasa sa pagsubok, hindi ito nangangahulugan na ang code ay "gumagana"; ibig sabihin lang nito ay "ito ay kumikilos gaya ng inaasahan ng AI". Ikaw ang magpapasya kung ang inaasahan ay tama o hindi sa pamamagitan ng pagtingin sa detalye.

Hakbang sa Hakbang: Pagsusulat ng Matatag na Pagsusulit gamit ang AI

1. Ibigay ang detalye, hindi lang ang code. Kung idagdag mo ang impormasyong "Dapat gawin ito ng function na ito", maaaring isulat ng AI ang tamang inaasahan; Susubukan nito ang kasalukuyang pag-uugali kung ibibigay mo lang ang code.
2. Humingi ng mga edge case. Walang laman, null, zero, negatibo, masyadong malaki, masamang format, concurrency — tahasang inaangkin ang masayang landas.
3. Tukuyin ang balangkas at istilo ng pagsubok. "gumamit ng pytest", "Arrange-Act-Assert pattern", "hayaan ang bawat pagsubok na sumubok ng isang bagay" atbp.
4. Suriin ang mga inaasahan (assertion). Ihambing sa detalye na sinusuri ng bawat iginiit ang tamang halaga.
5. Isara ang mga puwang sa saklaw. Magbigay ng mga kasalukuyang pagsusuri at magtanong "aling mga sangay at kaso ang hindi pa nasusuri?" itanong mo; pagkatapos ay i-verify ang mga karagdagang pagsubok na ginawa.

Tatlong Mini Case

Kaso 1 — Saklaw mula 52% hanggang 85%. Ang saklaw ng pagsubok ng isang module ng serbisyo ay 52%. Pinakain ng koponan ang mga kasalukuyang pagsubok sa AI, pinalista nito ang mga hindi pa nasusubukang sangay at gumawa ng mga pagsubok para sa kanila. Sa pagsusuri ng tao, tumaas ang saklaw sa 85%; Sa proseso, natuklasan ng AI ang isang aktwal na bug (isang landas na nagbalik ng maling error code) sa isang sangay ng bug na hindi pa nasusubukan noon.

Kaso 2 — Ang maling bitag sa pag-aayos ng inaasahan. Ang isang function ng money rounding ay talagang mali; Sa halip na i-round 2.675 hanggang 2.67, ito ay 2.67 sa halip na 2.68. Tiningnan ng AI ang code at nagsulat ng assert round_money(2.675) == 2.67 — pinalamig ang error bilang “totoo”. Nang basahin ng developer ang detalye, itinuwid niya ang inaasahan at nahuli ang totoong bug. Ang pagsubok sa panuntunan, hindi sa code, ang gumawa ng pagkakaiba.

Kaso 3 — Pagsabog ng estado ng gilid. Kapag humihiling sa AI para lamang sa "mga edge case" para sa isang function ng hanay ng petsa; Gumawa ito ng 8 kaso gaya ng start=end, reverse interval, leap year February 29, iba't ibang time zone at null interval. Dalawa sa mga ito (reverse spacing at leap year) ang talagang nagdudulot ng error. Isinasaalang-alang ang mga kasong ito nang manu-mano ay madalas na nilaktawan; Ang AI ay naging isang "edge-case brainstorming" na kasosyo dito.

Apat na Nakokopyang Template

Pagbuo ng pagsubok na batay sa pagtutukoy:

Tungkulin: Isang developer na nagsusulat ng mga pagsubok. Framework: {{pytest/JUnit/Jest...}}.Ano ang DAPAT GAWIN ng function (specification): {{rule}}Sumulat ng mga pagsubok para sa sumusunod na function. Isulat ang mga inaasahan ayon sa detalye, HINDI ang kasalukuyang output ng code. Maligayang landas + magdagdag ng hindi bababa sa 4 na edge case. Hayaang subukan ng bawat pagsubok ang isang bagay, gumamit ng mapaglarawang pangalan. {{function}}

Edge case brainstorming:

Maglista ng mga kaso ng gilid/pagkabigo na dapat subukan sa pagsubok para sa function na ito (null, null, breakpoints, masamang format, concurrency, external na error). Para sa bawat kaso: input, inaasahang pag-uugali. HUWAG pang magsulat ng code, ilista lang.{{function}}

Pagsusuri ng agwat ng saklaw:

Nasa ibaba ang mga function at magagamit na mga pagsubok. Aling mga sangay, kundisyon at kaso ang hindi pa nasusuri? Ilista ang mga kakulangan at sumulat ng mga bagong pagsusulit para lamang sa mga kakulangan. Huwag ulitin ang mga dati. Function:{{function}}Mga Pagsubok:{{existing_tests}}

Pagsubok ng data / paggawa ng mock object:

Bumuo ng makatotohanang data ng pagsubok para sa mga pagsubok sa {{function/service}}: magkahiwalay na mga wastong sample, mga sample ng hangganan at mga di-wastong sample. Magmungkahi ng simpleng mock na gawi para sa panlabas na dependency {{X}}. Paggamit ng tunay na kumpidensyal na data/PII; Bumuo ng pekeng data.

Mahinang prompt / Malakas na prompt

Mahina: "Sumulat ng pagsubok para sa function na ito."

Strong: "with pytest. Function apply_discount(total, percent) — rule: dapat 0%–30% ang discount, out of bounds dapat itapon ang ValueError, dapat bilugan ang resulta sa 2 decimals. Sumulat ng mga inaasahan ayon sa RULE na ito (hindi ayon sa code). Happy path + these edge cases: 0%, 30%, 31%"=0. [negative]

Ibinigay niya ang malakas na tuntunin sa pagpapalabas at nagsasabing "isulat ang inaasahan ayon sa panuntunan, hindi ang code"; Isinasara ng solong pangungusap na ito ang bitag ng AI sa pag-aayos ng maling pag-uugali.

Uri ng pagsubok

kontribusyon ng AI

kontrol ng tao

Maligayang pagsubok sa unit ng kalsada

mabilis na balangkas

Tama ba ang inaasahan?

Mga kaso sa gilid

Malawak na brainstorming

Tanggalin ang hindi nauugnay

Pagpuno ng puwang sa saklaw

Nakahanap ng mga nilaktawan na sanga

Kumpirmahin ang kahalagahan

Subukan ang data/pangungutya

Gumagawa ng makatotohanang sample

Walang PII, realism control

Ang Mga Pagsubok ay Pamamahala ng Kalidad, Hindi Ito Ginagarantiya

Ang mataas na saklaw ng pagsubok ay nagbibigay ng kumpiyansa, ngunit maaari rin itong mapanlinlang: 100 porsiyentong saklaw ay nangangahulugang "bawat linya ay pinatakbo," hindi "bawat linya ay tama." Madaling pataasin ang saklaw sa AI; Ang tunay na halaga ay sa pagsulat ng makabuluhang mga inaasahan. Ang halaga ng isang pagsubok ay ang kakayahang masira at alertuhan ka kapag nasira ang code. Iyon ang dahilan kung bakit ang mga pagsubok na binuo ng AI ay batay sa tanong na "talaga bang nasisira ang code kapag nagbago ito?" Subukan ito sa tanong; Ang sadyang pagsira ng linya at makita ang break ng pagsubok (ideya ng mutation) ay patunay na gumana ang pagsubok.

Tip: Upang makita kung gumagana ang isang pagsubok na isinulat ng AI, gumawa ng maliit na bug sa code (hal. baguhin ang isang + sa isang -) at tingnan kung masira ang pagsubok. Kung hindi ito masira, hindi ka mapoprotektahan ng pagsubok na iyon.

Mga karaniwang pagkakamali

• Humihingi ng pagsusulit nang hindi nagbibigay ng panuntunan. Ang modelo ay nag-freeze ng kasalukuyang pag-uugali; inaayos ang error bilang "totoo".
• Pagtanggap ng mga inaasahan nang hindi binabasa ang mga ito. Nakakapanlinlang ang pagsubok kung hindi mo susuriin kung ang mga paggiit ay sinusuri ang tamang halaga.
• Sinusubukan lang ang masayang landas. Ang mga tunay na pagkakamali ay nabubuhay sa mga gilid; Tahasang humingi ng mga edge case.
• Pagkakamali sa saklaw para sa layunin. Ang mataas na porsyento ay hindi garantiya ng tamang pag-uugali.
• Paggawa ng tunay/nakatagong data bilang data ng pagsubok. Ang data o mga lihim ng customer ay hindi dapat pumasok sa pagsubok at imbakan; Bumuo ng sintetikong data.

Sa buod

Kinukuha ng AI ang karamihan sa paulit-ulit na pasanin mula sa mga pagsusulit sa pagsulat: gumagawa ito ng mga mabilis na skeleton, malalaking listahan ng mga edge case, at mga pagsusuri sa saklaw ng gap. Ngunit ang pinakamahalagang punto ay ang mga inaasahan: May posibilidad na subukan ng AI ang kasalukuyang pag-uugali ng code, samantalang ang pagsubok ay dapat na nakasulat ayon sa detalye. Ibigay ang panuntunan, suriin ang mga inaasahan, ipatupad ang mga edge case, at subukan kung talagang nagpoprotekta ang mga pagsubok sa pamamagitan ng pag-iniksyon ng bug. Ang saklaw ng pagsubok ay isang tool, hindi isang layunin.

Gawain ng aplikasyon

Pumili ng isang function at unang mag-print ng pagsubok sa AI sa pamamagitan lamang ng pagbibigay ng code nito; Tandaan ang mga inaasahan. Pagkatapos ay i-print muli ang pagsubok, na nagbibigay ng detalye (kinakailangang pag-uugali) para sa parehong function. Ihambing ang mga inaasahan ng dalawang set ng pagsubok: mayroon bang iba, alin ang nagpapakita ng totoong bug? Panghuli, i-verify na gumana ang isa sa mga nabuong pagsubok sa pamamagitan ng pagdaragdag ng sinasadyang bug sa code at makita ang break na pagsubok.

checklist

• [ ] Tinutukoy ko kung ang pagsubok ay upang ayusin o i-verify ang gawi.
• [ ] Kapag humiling ako ng pagsusulit, ibinibigay ko ang panuntunan (specification) na dapat nasa lugar, hindi ang code.
• [ ] Inihahambing ko ang bawat nabuong assertion sa detalye.
• [ ] Tahasang humihiling ako ng mga kaso ng edge at failure.
• [ ] Tinitingnan ko ang porsyento ng coverage bilang isang tool, hindi isang layunin.
• [ ] Sinusubukan ko kung talagang nagpoprotekta ang isang pagsubok sa pamamagitan ng mga error sa pag-inject.