Qazanclar:
- Data-testid, açıq gözləmə və real istifadəçi nəticəsini təsdiq edən təsdiq daxil olmaqla, süni intellektlə möhkəm UI test kodunu hazırlamaq bacarığı
- Kövrək testlərdən (pis seçici, kor gözləmə) qarşısını almaq və Səhifə Obyekt Modeli strukturunda testləri asanlaşdırmaq imkanı
- Kodu pozmaqla istehsal olunan hər bir UI testini sınaqdan keçirmək və saxta keçmiş testləri aşkar etmək və düzəltmək bacarığı
İstifadəçinin brauzerdə etdiyi hər klik, hər forma doldurma, hər səhifə keçidi əl ilə təkrar-təkrar sınaqdan keçirilə bilməz – buna görə də UI test avtomatlaşdırılması (istifadəçi interfeysi; bu testlər real brauzeri proqramlı şəkildə idarə etməklə istifadəçi davranışını təqlid edir) mövcuddur. Selenium, Dramaturq və Cypress bu iş üçün ən çox yayılmış vasitələrdir. Süni intellekt (AI) bu alətlər üçün kodu yazmaqda yüksək bacarıqlıdır: siz sınaq işini təsvir edirsiniz, AI sizə işlək avtomatlaşdırma skriptinin layihəsini təqdim edir. Ancaq burada bu modulun mərkəzi xəbərdarlığı yenidən işə düşür: AI-nin istehsal etdiyi UI test kodu tez-tez "yaşıl yanan, lakin yanlış şeyi təsdiqləyən" və ya küləkdə çırpılan kövrək testlər ola bilər. Sizin işiniz bu kodu işlətmək deyil, onun həqiqətən doğru şeyi etibarlı şəkildə təsdiqlədiyinə əmin olmaqdır.
Bu bölmədə biz AI ilə möhkəm, davamlı və həqiqətən təsdiqlənən UI testləri hazırlamağı hədəfləyirik; Kövrək sınaqlardan qaçmağı öyrənəcəksiniz.
Möhkəm UI testinin üç sütunu
1. Düzgün element lokatoru. Test səhifədəki elementi tapmaq üçün seçicidən istifadə edir. Süni intellekt tez-tez kövrək seçicilər istehsal edir: uzun XPath yolları (ünvan səhifə strukturundan həddən artıq asılıdır), CSS sinif adlarına əsaslanan seçicilər (dizayn dəyişikliyi zamanı fasilə). Sağlam yol, tərtibatçının sınaq üçün əlavə etdiyi data-testid kimi sabit atributlardır. Bunu AI-yə açıq şəkildə tətbiq edin.
2. Açıq gözləmə. UI testində zəifliyin bir nömrəli mənbəyi vaxtdır. Daimi yuxu (3) (kor-koranə gözləmə) pis təcrübədir: bəzən kifayət etmir, bəzən isə vaxt itirir. Doğru yol, "bu element görünənə qədər gözləyin" deyən açıq gözləmədən istifadə etməkdir. Dramaturq bunu əsasən avtomatik edir; Seleniumda siz bunu açıq şəkildə tələb etməlisiniz.
3. Mənalı iddia. Test, istifadəçinin həqiqətən görəcəyi nəticəni yoxlamalıdır - məsələn, "sifariş nömrəsi ekranda göründü", "səhifə yükləndi" deyil. AI tərəfindən hazırlanmış testin təsdiqi yoxdursa və ya əhəmiyyətsizdirsə, bu test psevdo-pass (1-ci vahid) yaradır.
Diqqət: Süni intellekt tərəfindən yaradılan UI testini ilk dəfə görəndə ən çoxu üç şeyi yoxlayın: seçicilər yerinə yetirilibmi (məlumat testi), gözləyirlərmi (kor yuxu yoxdur) və təsdiq faktiki istifadəçi nəticəsini təsdiqləyirmi? Bu üçü qaydasındadırsa, test yəqin ki, möhkəmdir.
Səhifə Obyekt Modeli
Testlər böyüdükcə, hər bir testin içərisində seçicilərin yazılması baxım kabusuna çevrilir. Səhifə Obyekt Modeli (POM — hər səhifə/ekran üçün seçiciləri və hərəkətləri vahid sinifdə toplayan dizayn nümunəsi) selektoru bir yerdə saxlayır; İnterfeys dəyişdikdə, onu bir faylda yeniləyirsiniz. AI testləri birbaşa deyil, POM strukturunda istehsal etsin; Bu, təmiri kökündən asanlaşdırır.
Zəif məlumat / Güclü göstəriş
Zəif: "Giriş səhifəsi üçün Selenium testi yazın."
Güclü: "Playwright (TypeScript) ilə giriş axını testi yazın. Seçicilər yalnız data-testid istifadə edir; səhifənin başlığından yox, istifadəçinin gördüyünə nəzarətdən istifadə etməyin."
Güclü tez; Alət dil, seçici siyasəti, gözləmə strategiyası, arxitektura (POM) və ifadəli təsdiq gözləntisini verir.
Test məlumatları və ətraf mühitin müstəqilliyi
Möhkəm UI testi yalnız düzgün yazılmır, həm də öz test məlumatlarını qurur və təmizləyir. Süni intellekt tərəfindən yaradılan testlər çox vaxt mühitdə artıq mövcud olduğu güman edilən istifadəçi və ya qeydlə əlaqələndirilir (“inzibatçı istifadəçi kimi daxil olun”). Sınaq başqa mühitdə və ya başqa bir sınaqdan sonra işlədikdə bu fərziyyə pozulur (9-cu bölmədə sifarişdən asılılıq problemi). Həqiqət budur ki, hər bir test testin əvvəlində ehtiyac duyduğu məlumatları yaradır (yaxud onu API çağırışı ilə hazırlayır) və sonunda təmizləyir. Süni intellektə açıq şəkildə göstəriş verin ki, "bu test test daxilində asılı olan hər hansı bir məlumat qursun; kənardan hazır məlumatları qəbul etməyin".
Başqa bir kritik məqam, real istifadəçi məlumatları ilə UI testi etməməkdir. İstehsal məlumat bazasının surəti sınaq mühitində istifadə olunarsa, bu qeydlər fiziki şəxslərin məlumatlarıdır; ekran görüntüləri və sınaq qeydləri bu məlumatları aşkar edə bilər. Sintetik (uydurma) test hesablarından istifadə edin; həm məxfiliyi qoruyur, həm də testləri təkrarlana bilən edir. Real müştəri hesabı ilə “sifarişin ləğvi” testinin keçirilməsi həm etik, həm də əməliyyat səhvidir.
İpucu: UI testlərini mümkün qədər az saxlayın; Faktiki yoxlamanı sürətli və sabit olan API və vahid testlərinə buraxın. UI testi bahalı və kövrəkdir - yalnız həqiqətən son istifadəçi axınını yoxlamaq üçün istifadə edin (test piramida məntiqi).
Avtomobilin müqayisəsi
xüsusiyyət
selenium
dramaturq
sərv
dillər
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
avtomatik gözləmə rejimi
Xeyr (əl ilə)
Bəli (güclü)
Bəli
Çox brauzer
geniş
Chromium/Firefox/WebKit
Xrom-dominant
kövrəkliyə meyl
Yüksək (əl ilə gözləmə rejimi)
aşağı
aşağı
Öyrənmə asanlığı
orta
asan
asan
paralel əməliyyat
Şəbəkə tələb olunur
daxili
Sakin/ödənişli
Süni intellektdən kod tələb edərkən onun hansı nəqliyyat vasitəsinə aid olduğunu açıq şəkildə bildirin; Əks halda, çaşdırıcı, işlək olmayan kod yarada bilər.
Dörd kopyalana bilən şablon
1) Bərk UI test generasiyası:
Rolunuz: baş sınaq avtomatlaşdırma mühəndisi. Aşağıdakı axın üçün [alət + dil] ilə testlər yazın: [axın].Qaydalar:- Seçicilər yalnız data-testid; XPath/CSS sinifindən istifadə. - Kor yuxu yoxdur; Açıq/avtomatik gözləmədən istifadə edin. - Səhifə Obyekt Modelini tətbiq edin. - Hər bir təsdiqin faktiki istifadəçi nəticəsini yoxlamasına icazə verin. Hər bir testin əvvəlində hansı qəbul meyarlarını təsdiq etdiyinizi şərh edin.
2) Kövrəkliyə nəzarət:
Aşağıdakı UI testini kövrəklik üçün yoxlayın: - Qeyri-sabit seçici varmı (uzun
3) Səhifə obyektinə çevrilmə:
Aşağıdakı sadə test kodunu Səhifə Obyekt Modeli strukturuna çevirin. Seçiciləri və hərəkətləri səhifə siniflərinə köçürün; Test faylının yalnız ssenari axını oxumasına icazə verin. [Alət/dil].Kod: [kodu yapışdırın]
4) Pseudo-keçid sübutu:
Bu UI testinin həqiqətən təsdiq etdiyini sübut edin: Bu testi QIRMIZI rəngə çevirəcək tətbiq kodunda hansı tək dəyişiklik etməliyəm? Testi pozacaq bir dəyişiklik tapa bilmirsinizsə, test qeyri-adekvatdır; çatışmayan təsdiqləri əlavə edin. Test: [test yapışdırın]
üç mini qutu
1-ci hal - Kövrək seçicidən qurtulma. Bir komandanın AI ilə hazırladığı 40 testdən 70%-i interfeys yeniləməsindən sonra pozulub; onların heç biri faktiki səhvlər deyildi, hamısı kövrək XPath seçiciləri idi. Komanda testləri "kövrəklik yoxlaması" şablonu ilə məlumat testi bazasına çevirdi. Növbəti üç interfeys yeniləməsində yalançı fasilələrin sayı sıfıra endi; baxım müddəti həftədə 6 saatdan 30 dəqiqəyə endirildi.
Case 2 - Saxta keçid UI testi. AI "səbətə əlavə et" testi hazırladı; test yaşıl idi. "Saxta keçid" şablonu işə salındıqda, test yalnız düymənin kliklənməsini və səhifənin başlığını yoxlayır, araba sayğacının artıb-artmadığını heç vaxt yoxlayır. Araba məntiqi tamamilə pozulsa belə, test keçdi. Həqiqi təsdiq əlavə edildi (səbət nişanı "1"dir).
3-cü vəziyyət - Kor gözləmə tələsi. AI tərəfindən istehsal edilən Selenium testində hər addımdan sonra yuxu (2) var idi; 60 test 14 dəqiqə çəkdi və yenə də bəzən qırıldı. Açıq gözləmə rejiminə keçdikdən sonra (elementin kliklənməsini gözləyin) vaxt 5 dəqiqəyə qədər azaldı və kövrəklik yox oldu. Kor gözləmə həm yavaş, həm də etibarsız idi.
Ümumi səhvlər
- Kövrək seçicilərlə razılaşmaq. AI tərəfindən yaradılan uzun XPath-lardan olduğu kimi istifadə etmək; Testlər ilk interfeys dəyişikliyində qəzaya uğrayır.
- Kor `yuxu` buraxmaq. Sabit bir gözləmə ilə vaxtı "həll etmək"; həm yavaş, həm də qərarsız.
- Önəmsiz iddia. Sadəcə səhifənin yükləndiyini yoxlayın; faktiki istifadəçi nəticəsinin yoxlanılmaması (saxta keçid).
- POM olmadan inkişaf edin. Seçiciləri hər bir testə paylayın; İnterfeys dəyişdikdə onlarla faylın əl ilə yenilənməsi.
- Aləti qeyd etməmək. Süni intellektə hansı alət/dil istədiyinizi bildirməmək; qarışıq, işləməyən kod əldə etmək.
- Yaradılan kodu işə saldıqda və keçdikdə güvənmək. Kodu pozaraq sınaqdan keçirilmir.
Xülasə
UI testinin avtomatlaşdırılması faktiki brauzeri proqramla idarə etməklə istifadəçi davranışını yoxlayır. Süni intellekt bu kodu tez yaradır, lakin iki böyük tələ var: kövrək testlər (pis seçici, kor gözləyir) və saxta keçid testləri (natamam/əhəmiyyətsiz iddia). Möhkəm UI testinin üç sütunu öhdəliyin seçicisidir (data-testid), açıq gözləyin və faktiki istifadəçi nəticəsini təsdiqləyən təsdiqdir. Səhifə Obyekt Modelində yaradılan testlərə sahib olmaq texniki xidməti kökündən asanlaşdırır. Hər yaradılan testi "hansı dəyişiklik bunu pozacaq?" sualı ilə yoxlayın.
Tətbiq tapşırığı
Öz layihənizdən istifadəçi axını seçin (məsələn, giriş və ya axtarış). Süni intellektə “sağlam UI test nəsli” şablonu ilə testlər yazdırın. Sonra: (1) seçiciləri yoxlayın və düzəldin və "kövrəklik yoxlanışı" ilə gözləyin, (2) hər bir testin həqiqətən "psevdo-keçmə sübutu" ilə doğrulandığını sübut edin, (3) kodu pozun və testin qırmızıya çevrildiyini müşahidə edin. Hazırlanmış və düzəldilmiş testlərin sayını, aşkar etdiyiniz zəifliklərin və psevdo-keçidlərin sayını bildirin.
yoxlama siyahısı
- [ ] Mən süni intellektə alət, dil, seçici siyasəti və arxitekturasını (POM) aydın şəkildə verdim.
- [ ] Seçicilərin data-testid olduğunu təsdiqlədim.
- [ ] Mən kor yuxu əvəzinə açıq/avtomatik gözləmədən istifadə etdiyimə əmin oldum.
- [ ] Hər təsdiqin faktiki istifadəçi nəticəsini təsdiq etdiyini yoxladım.
- [ ] Mən kodu pozaraq hər testi sınaqdan keçirdim; Gördüm qırmızı oldu.
- [ ] Testləri Səhifə Obyekt Modeli strukturunda topladım.