Mga nadagdag:
- Kakayahang gumawa ng matatag na UI test code na may artificial intelligence, kabilang ang data-testid, bukas na paghihintay, at paggigiit na nagbe-verify sa totoong resulta ng user
- Kakayahang maiwasan ang mga marupok na pagsubok (masamang tagapili, bulag na paghihintay) at gawing madaling mapanatili ang mga pagsubok sa istruktura ng Modelo ng Bagay ng Pahina
- Kakayahang subukan ang bawat pagsubok sa UI na ginawa sa pamamagitan ng pagsira sa code at pag-detect at pag-aayos ng mga pekeng naipasa na pagsubok
Ang bawat pag-click, bawat pagpuno ng form, bawat paglipat ng pahina na ginagawa ng isang user sa isang browser ay hindi maaaring subukan nang paulit-ulit sa pamamagitan ng kamay — kaya naman umiiral ang UI test automation (user interface; ginagaya ng mga pagsubok na ito ang gawi ng user sa pamamagitan ng programmatically driving a real browser). Ang Selenium, Playwright at Cypress ay ang pinakakaraniwang tool para sa trabahong ito. Napakahusay ng Artificial Intelligence (AI) sa pagsulat ng code para sa mga tool na ito: inilalarawan mo ang isang test case, binibigyan ka ng AI ng draft ng isang workable automation script. Ngunit narito ang pangunahing babala ng modyul na ito ay muling gumaganap: Ang UI test code na ginagawa ng AI ay kadalasang mga marupok na pagsubok na "nagpapailaw na berde ngunit nagpapatunay sa maling bagay" o pumapatak sa hangin. Ang iyong trabaho ay hindi upang patakbuhin ang code na ito, ngunit upang matiyak na ito ay talagang matatag na nagbe-verify ng tamang bagay.
Sa unit na ito, nilalayon naming gumawa ng matatag, mapanatili at tunay na pagpapatunay ng mga pagsubok sa UI gamit ang AI; Matututo kang umiwas sa mga marupok na pagsubok.
Ang tatlong haligi ng solidong pagsubok sa UI
1. Tamang tagahanap ng elemento. Ang isang pagsubok ay gumagamit ng isang tagapili upang mahanap ang elemento sa pahina. Ang AI ay madalas na gumagawa ng mga malutong na tagapili: mahahabang XPath na mga landas (address na labis na nakadepende sa istraktura ng pahina), mga tagapili batay sa mga pangalan ng klase ng CSS (masira kapag nagbago ang disenyo). Ang matatag na paraan ay ang mga matatag na katangian tulad ng data-testid na idinagdag ng developer para sa pagsubok. Tahasang ipataw ito sa AI.
2. Tahasang paghihintay. Ang numero unong pinagmumulan ng kahinaan sa UI testing ay timing. Ang palagiang pagtulog(3) (bulag na paghihintay) ay masamang gawain: minsan hindi sapat, minsan ay nag-aaksaya ng oras. Ang tamang paraan ay ang paggamit ng tahasang paghihintay, na nagsasabing "maghintay hanggang lumitaw ang elementong ito". Awtomatikong ginagawa ito ng playwright; Sa Selenium dapat mong tahasan itong hilingin.
3. Makabuluhang paninindigan. Dapat i-verify ng pagsubok ang resulta na aktwal na makikita ng user — tulad ng "numero ng order na lumabas sa screen," hindi lang "na-load ang pahina." Kung ang pagsubok na ginawa ng AI ay walang assertion o hindi mahalaga, ang pagsubok na iyon ay gumagawa ng isang pseudo-pass (1st unit).
Babala: Kapag una kang nakakita ng AI-generated UI test, tingnan ang tatlong bagay sa pinakamaraming: ang mga selector ba ay nakatuon (data-testid), naghihintay (walang blind sleep), at ang assert ba ay nagpapatunay sa aktwal na resulta ng user? Kung OK ang tatlong ito, malamang na solid ang pagsubok.
Modelo ng Bagay sa Pahina
Habang lumalaki ang mga pagsubok, ang pagsusulat ng mga tagapili sa loob ng bawat pagsubok ay nagiging isang bangungot sa pagpapanatili. Page Object Model (POM — pattern ng disenyo na nangongolekta ng mga selector at aksyon para sa bawat page/screen sa isang klase) na nagpapanatili sa selector sa isang lugar; Kapag nagbago ang interface, ina-update mo ito sa isang file. Hayaang gawin ng AI ang mga pagsubok sa isang istraktura ng POM, sa halip na direkta; Pinapadali nito ang pagpapanatili.
Mahinang prompt / Malakas na prompt
Mahina: "Sumulat ng Selenium test para sa login page."
Strong: "Sumulat ng pagsubok sa daloy ng pag-log in gamit ang Playwright (TypeScript). Gumagamit lang ang mga pumipili ng data-testid; huwag gumamit ng kontrol kung ano ang nakikita ng user, hindi ang pamagat ng page."
Napakahusay na prompt; Ang tool ay nagbibigay ng wika, patakaran sa tagapili, diskarte sa paghihintay, arkitektura (POM) at nagpapahayag ng pag-asa.
Data ng pagsubok at pagsasarili sa kapaligiran
Ang isang matatag na pagsubok sa UI ay hindi lamang nakasulat nang tama, ngunit bumubuo at nililinis din ang sarili nitong data ng pagsubok. Ang mga pagsubok na binuo ng AI ay kadalasang nagli-link sa isang user o record na ipinapalagay na umiiral na sa kapaligiran ("mag-log in bilang admin user"). Mawawala ang pagpapalagay na ito kapag tumakbo ang pagsubok sa ibang kapaligiran o pagkatapos ng isa pang pagsubok (problema sa dependency ng order sa unit 9). Ang katotohanan ay ang bawat pagsubok ay lumilikha ng data na kailangan nito sa simula ng pagsubok (o inihahanda ito gamit ang isang API na tawag) at nililinis ito sa dulo. Tahasang atasan ang AI na "i-set up ang anumang data na nakasalalay sa pagsubok na ito sa loob ng pagsubok; huwag ipagpalagay na handa na ang data mula sa labas."
Ang isa pang kritikal na punto ay ang hindi paggawa ng pagsubok sa UI gamit ang totoong data ng user. Kung ang isang kopya ng database ng produksyon ay ginagamit sa kapaligiran ng pagsubok, ang mga talaang ito ay data ng mga totoong tao; ang mga screenshot at pag-record ng pagsubok ay maaaring magbunyag ng data na ito. Gumamit ng mga synthetic (fictional) na account sa pagsubok; pareho nitong pinoprotektahan ang pagiging kompidensiyal at ginagawang reproducible ang mga pagsubok. Ang pagsasagawa ng pagsubok na "pagkansela ng order" gamit ang isang tunay na account ng customer ay parehong etikal at pagkakamali sa pagpapatakbo.
Tip: Panatilihing kakaunti ang mga pagsubok sa UI hangga't maaari; Iwanan ang aktwal na pag-verify sa API at mga unit test, na mabilis at matatag. Mahal at malutong ang pagsubok sa UI — gamitin lang ito para patunayan ang tunay na end-to-end na daloy ng user (test pyramid logic).
Paghahambing ng sasakyan
tampok
siliniyum
mandudula
sipres
mga wika
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
auto standby
Hindi (sa kamay)
Oo (malakas)
Oo
Multi browser
malawak
Chromium/Firefox/WebKit
Chromium-dominant
pagkahilig sa brittleness
Mataas (manu-manong standby)
mababa
mababa
Dali ng pag-aaral
daluyan
madali
madali
parallel operation
Kinakailangan ang grid
built-in
Naninirahan/may bayad
Kapag humihiling ng code mula sa AI, sabihin nang malinaw kung saang sasakyan ito kabilang; Kung hindi, maaari itong makagawa ng nakakalito, hindi gumaganang code.
Apat na maaaring kopyahin na mga template
1) Solid UI test generation:
Ang iyong tungkulin: senior test automation engineer. Sumulat ng mga pagsubok gamit ang [tool + language] para sa sumusunod na daloy: [flow].Mga Panuntunan:- Mga Selector data-testid lang; Gamit ang XPath/CSS-class. - Walang bulag na pagtulog; Gumamit ng tahasan/awtomatikong paghihintay. - Ilapat ang Modelo ng Bagay sa Pahina. - Hayaang i-verify ng bawat isa ang aktwal na resulta ng user. Magkomento sa simula ng bawat pagsusulit kung aling pamantayan sa pagtanggap ang iyong pinapatunayan.
2) Pagkontrol sa fragility:
Suriin ang sumusunod na pagsubok sa UI para sa brittleness:- Mayroon bang hindi matatag na tagapili (long
3) Conversion sa Page Object:
I-convert ang sumusunod na plain test code sa Page Object Model structure. Ilipat ang mga tagapili at pagkilos sa mga klase ng page; Hayaang basahin lamang ng test file ang daloy ng senaryo. [Tool/language].Code: [paste code]
4) Pseudo-transition proof:
Patunayan na ang UI test na ito ay aktwal na nagpapatunay: Anong solong pagbabago ang gagawin ko sa application code na magpapa-RED sa pagsubok na ito? Kung hindi mo mahanap ang isang pagbabago na makakasira sa pagsubok, ang pagsubok ay hindi sapat; magdagdag ng mga nawawalang asserts.Test: [paste test]
tatlong mini case
Kaso 1 — Paglaya mula sa marupok na tagapili. Sa 40 pagsubok na ginawa ng isang koponan gamit ang AI, 70% ang nasira pagkatapos ng pag-update ng interface; wala sa kanila ang aktwal na mga bug, lahat sila ay marupok na mga pumipili ng XPath. Na-convert ng team ang mga pagsubok sa isang data-testid base na may template na "fragility check." Sa susunod na tatlong pag-update ng interface, ang bilang ng mga false break ay bumaba sa zero; nabawasan ang oras ng pagpapanatili mula 6 na oras hanggang 30 minuto bawat linggo.
Case 2 — Fake-passing UI test. Gumawa ang AI ng pagsubok na "idagdag sa cart"; ang pagsubok ay berde. Noong pinatakbo ang template na "fake-proof-of-passage", ang pagsubok ay lumilitaw na suriin lamang ang pag-click sa button at pamagat ng pahina, hindi kailanman nabe-verify kung tumaas ang cart counter o hindi. Kahit na ang lohika ng cart ay ganap na nasira, ang pagsubok ay pumasa. Nagdagdag ng totoong paninindigan (ang cart badge ay "1").
Kaso 3 — Blind waiting trap. Sa Selenium test na ginawa ng AI, mayroong sleep(2) pagkatapos ng bawat hakbang; Ang 60 na pagsusulit ay tumagal ng 14 na minuto at nasira pa rin paminsan-minsan. Pagkatapos lumipat sa bukas na paghihintay (hintayin na ma-click ang elemento) bumaba ang oras sa 5 minuto at nawala ang brittleness. Ang bulag na paghihintay ay parehong mabagal at hindi mapagkakatiwalaan.
Mga karaniwang pagkakamali
- Sumasang-ayon sa mga marupok na pumipili. Gamit ang mahahabang XPath na nabuo ng AI tulad ng; Nag-crash ang mga pagsubok sa unang pagbabago ng interface.
- Nag-iiwan ng bulag na `tulog`. "Paglutas" sa timing na may nakapirming paghihintay; parehong mabagal at hindi tiyak.
- Walang kuwentang paninindigan. I-verify lang na na-load ang page; hindi sinusuri ang aktwal na resulta ng user (fake-pass).
- Lumaki nang walang POM. Ipamahagi ang mga tagapili sa bawat pagsubok; Manu-manong pag-update ng dose-dosenang mga file kapag nagbago ang interface.
- Hindi tinukoy ang tool. Hindi sinasabi sa AI kung anong tool/wika ang gusto mo; nagiging magulo, hindi gumaganang code.
- Nagtitiwala kapag pinatakbo mo ang nabuong code at pumasa. Hindi pagsubok sa pamamagitan ng pagsira sa code.
Sa buod
Bine-verify ng automation ng UI testing ang gawi ng user sa pamamagitan ng pagmamaneho sa aktwal na browser gamit ang program. Mabilis na nabuo ng AI ang code na ito, ngunit mayroong dalawang malalaking pitfalls: mga malutong na pagsubok (masamang tagapili, naghihintay ng bulag) at mga pekeng pagpasa ng mga pagsubok (hindi kumpleto/walang kuwenta na pahayag). Ang tatlong haligi ng solidong pagsubok sa UI ay ang commit selector (data-testid), tahasang paghihintay, at igiit na nagbe-verify sa aktwal na resulta ng user. Ang pagkakaroon ng mga pagsubok na nabuo sa Modelo ng Bagay ng Pahina ay lubos na nagpapadali sa pagpapanatili. Subukan ang bawat nabuong pagsubok na may tanong na "anong pagbabago ang makakasira dito?"
Gawain ng aplikasyon
Pumili ng daloy ng user mula sa sarili mong proyekto (hal. login o paghahanap). Ipasulat sa AI ang mga pagsubok gamit ang template na "matatag na UI test generation". Pagkatapos: (1) suriin at ayusin ang mga pumipili at maghintay gamit ang isang "fragility check", (2) patunayan na ang bawat pagsubok ay aktwal na nagpapatunay gamit ang isang "pseudo-pass proof", (3) sirain ang code at obserbahan na ang pagsubok ay nagiging pula. Iulat ang bilang ng mga pagsubok na ginawa at naitama, at ang bilang ng mga kahinaan at pseudo-pass na iyong nakita.
checklist
- [ ] Ibinigay ko sa AI ang tool, wika, patakaran ng tagapili at arkitektura (POM) nang malinaw.
- [ ] Na-verify ko na ang mga pumipili ay data-testid.
- [ ] Tiniyak kong gumamit ng tahasan/awtomatikong paghihintay sa halip na bulag na pagtulog.
- [ ] Sinuri ko na ang bawat assert ay nagpapatunay sa aktwal na resulta ng user.
- [ ] Sinubukan ko ang bawat pagsubok sa pamamagitan ng pagsira sa code; Nakita kong naging pula ito.
- [ ] Kinolekta ko ang mga pagsubok sa istruktura ng Modelo ng Bagay ng Pahina.