Keuntungan:
- Keupayaan untuk menghasilkan kod ujian UI yang mantap dengan kecerdasan buatan, termasuk data-testid, menunggu terbuka dan menegaskan yang mengesahkan hasil pengguna sebenar
- Keupayaan untuk mengelakkan ujian rapuh (pemilih yang buruk, menunggu buta) dan menjadikan ujian mudah dikekalkan dalam struktur Model Objek Halaman
- Keupayaan untuk menguji setiap ujian UI yang dihasilkan dengan memecahkan kod dan mengesan serta membetulkan ujian lulus palsu
Setiap klik, setiap pengisian borang, setiap peralihan halaman yang dibuat pengguna dalam penyemak imbas tidak boleh diuji berulang kali dengan tangan — itulah sebabnya automasi ujian UI (antara muka pengguna; ujian ini meniru gelagat pengguna dengan memacu penyemak imbas sebenar secara pemprograman) wujud. Selenium, Drama dan Cypress ialah alat yang paling biasa untuk kerja ini. Kecerdasan buatan (AI) sangat mahir dalam menulis kod untuk alatan ini: anda menerangkan kes ujian, AI memberi anda draf skrip automasi yang boleh dilaksanakan. Tetapi di sini amaran utama modul ini kembali dimainkan: Kod ujian UI yang dihasilkan AI selalunya boleh menjadi ujian rapuh yang "menyala hijau tetapi mengesahkan perkara yang salah" atau mengepakkan angin. Tugas anda bukan untuk menjalankan kod ini, tetapi untuk memastikan ia benar-benar mengesahkan perkara yang betul dengan mantap.
Dalam unit ini, kami menyasarkan untuk menghasilkan ujian UI yang mantap, boleh diselenggara dan benar-benar mengesahkan dengan AI; Anda akan belajar untuk mengelakkan ujian yang rapuh.
Tiga tonggak ujian UI yang kukuh
1. Pencari elemen yang betul. Ujian menggunakan pemilih untuk mencari elemen pada halaman. AI sering menghasilkan pemilih rapuh: laluan XPath yang panjang (alamat terlalu bergantung pada struktur halaman), pemilih berdasarkan nama kelas CSS (pecah apabila reka bentuk berubah). Cara yang teguh ialah atribut yang stabil seperti data-testid yang ditambahkan oleh pembangun untuk ujian. Kenakan ini secara eksplisit pada AI.
2. Penantian yang jelas. Sumber kelemahan nombor satu dalam ujian UI ialah masa. Tidur yang berterusan(3) (menunggu buta) adalah amalan buruk: kadang-kadang tidak cukup, kadang-kadang membuang masa. Cara yang betul ialah menggunakan tunggu eksplisit, yang mengatakan "tunggu sehingga elemen ini muncul". Penulis drama melakukan ini secara automatik; Dalam Selenium anda mesti memintanya secara eksplisit.
3. Penegasan yang bermakna. Ujian harus mengesahkan hasil yang sebenarnya akan dilihat pengguna — seperti "nombor pesanan muncul pada skrin", bukan hanya "halaman dimuatkan". Jika ujian yang dihasilkan oleh AI tidak mempunyai penegasan atau tidak penting, ujian itu menghasilkan pseudo-pass (unit pertama).
Awas: Apabila anda mula-mula melihat ujian UI yang dijana AI, semak tiga perkara paling banyak: adakah pemilih komited (data-testid), sedang menunggu (tiada tidur buta) dan adakah assert mengesahkan keputusan pengguna sebenar? Jika ketiga-tiga ini OK, ujian itu mungkin kukuh.
Model Objek Halaman
Apabila ujian semakin besar, menulis pemilih di dalam setiap ujian menjadi mimpi ngeri penyelenggaraan. Model Objek Halaman (POM — corak reka bentuk yang mengumpulkan pemilih dan tindakan untuk setiap halaman/skrin ke dalam satu kelas) menyimpan pemilih di satu tempat; Apabila antara muka berubah, anda mengemas kininya dalam satu fail. Minta AI menghasilkan ujian dalam struktur POM, bukannya secara langsung; Ini menjadikan penyelenggaraan secara radikal lebih mudah.
Gesaan lemah / Gesaan kuat
Lemah: "Tulis ujian Selenium untuk halaman log masuk."
Kuat: "Tulis ujian aliran log masuk dengan Playwright (TypeScript). Pemilih hanya menggunakan data-testid; jangan gunakan kawalan perkara yang dilihat pengguna, bukan tajuk halaman."
Gesaan yang kuat; Alat ini memberikan bahasa, dasar pemilih, strategi tunggu, seni bina (POM) dan jangkaan tegas yang ekspresif.
Data ujian dan kebebasan persekitaran
Ujian UI yang kukuh bukan sahaja ditulis dengan betul, tetapi juga membina dan membersihkan data ujiannya sendiri. Ujian yang dijana AI selalunya dipautkan kepada pengguna atau rekod yang diandaikan telah wujud dalam persekitaran (“log masuk sebagai pengguna pentadbir”). Andaian ini terputus apabila ujian dijalankan dalam persekitaran lain atau selepas ujian lain (masalah pergantungan pesanan dalam unit 9). Hakikatnya ialah setiap ujian mencipta data yang diperlukan pada permulaan ujian (atau menyediakannya dengan panggilan API) dan membersihkannya pada penghujungnya. Arahkan AI secara eksplisit untuk "menyediakan sebarang data yang bergantung kepada ujian ini dalam ujian; jangan menganggap data siap sedia dari luar."
Satu lagi perkara kritikal ialah tidak melakukan ujian UI dengan data pengguna sebenar. Jika salinan pangkalan data pengeluaran digunakan dalam persekitaran ujian, rekod ini adalah data orang sebenar; tangkapan skrin dan rakaman ujian mungkin mendedahkan data ini. Gunakan akaun ujian sintetik (fiksyen); ia melindungi kerahsiaan dan menjadikan ujian boleh dihasilkan semula. Menjalankan ujian "pembatalan pesanan" dengan akaun pelanggan sebenar adalah kesilapan etika dan operasi.
Petua: Pastikan ujian UI sesedikit mungkin; Serahkan pengesahan sebenar kepada ujian API dan unit, yang pantas dan stabil. Ujian UI mahal dan rapuh — hanya gunakannya untuk mengesahkan aliran pengguna yang benar-benar hujung-ke-hujung (uji logik piramid).
Perbandingan kenderaan
ciri
selenium
pengarang drama
cemara
bahasa
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
siap sedia automatik
Tidak (dengan tangan)
Ya (kuat)
ya
Pelayar berbilang
luas
Chromium/Firefox/WebKit
Chromium-dominan
kecenderungan kepada kerapuhan
Tinggi (siap sedia manual)
rendah
rendah
Kemudahan belajar
sederhana
mudah
mudah
operasi selari
Grid diperlukan
terbina dalam
Pemastautin/dibayar
Apabila meminta kod daripada AI, nyatakan dengan jelas kenderaan itu miliknya; Jika tidak, ia mungkin menghasilkan kod yang mengelirukan dan tidak berfungsi.
Empat templat yang boleh disalin
1) Penjanaan ujian UI pepejal:
Peranan anda: jurutera automasi ujian kanan.Tulis ujian dengan [alat + bahasa] untuk aliran berikut: [aliran].Peraturan:- Pemilih data-testid sahaja; Menggunakan kelas XPath/CSS. - Tiada tidur buta; Gunakan penantian eksplisit/automatik. - Guna Model Objek Halaman. - Biarkan setiap menegaskan mengesahkan keputusan pengguna sebenar. Komen pada permulaan setiap ujian kriteria penerimaan yang anda sahkan.
2) Kawalan kerapuhan:
Periksa ujian UI berikut untuk kerapuhan:- Adakah terdapat pemilih yang tidak stabil (long
3) Penukaran ke Objek Halaman:
Tukar kod ujian biasa berikut kepada struktur Model Objek Halaman. Alihkan pemilih dan tindakan ke kelas halaman; Biarkan fail ujian membaca aliran senario sahaja. [Alat/bahasa].Kod: [tampal kod]
4) Bukti peralihan pseudo:
Buktikan bahawa ujian UI ini sebenarnya mengesahkan: Apakah perubahan tunggal yang saya lakukan pada kod aplikasi yang akan menjadikan ujian ini MERAH? Jika anda tidak dapat mencari perubahan yang akan memecahkan ujian, ujian itu tidak mencukupi; tambah penegasan yang hilang.Ujian: [paste test]
tiga kes mini
Kes 1 — Pembebasan daripada pemilih rapuh. Daripada 40 ujian satu pasukan yang dihasilkan dengan AI, 70% telah rosak selepas kemas kini antara muka; tiada satu pun daripada mereka adalah pepijat sebenar, mereka semua adalah pemilih XPath yang rapuh. Pasukan itu menukar ujian kepada pangkalan data-testid dengan templat "semakan kerapuhan". Sepanjang tiga kemas kini antara muka seterusnya, bilangan pecahan palsu menurun kepada sifar; masa penyelenggaraan berkurangan daripada 6 jam kepada 30 minit seminggu.
Kes 2 — Ujian UI lulus palsu. AI menghasilkan ujian "tambah ke troli"; ujian itu hijau. Apabila templat "bukti laluan palsu" dijalankan, ujian nampaknya hanya menyemak klik butang dan tajuk halaman, tidak sekali-kali mengesahkan sama ada kaunter troli telah meningkat atau tidak. Walaupun logik troli telah rosak sepenuhnya, ujian itu lulus. Tegas benar ditambahkan (lencana troli ialah "1").
Kes 3 — Perangkap menunggu buta. Dalam ujian Selenium yang dihasilkan oleh AI, terdapat tidur(2) selepas setiap langkah; 60 ujian mengambil masa 14 minit dan masih terputus sekali-sekala. Selepas bertukar kepada buka tunggu (tunggu elemen boleh diklik) masa turun kepada 5 minit dan kerapuhan hilang. Penantian buta adalah lambat dan tidak boleh dipercayai.
Kesilapan biasa
- Bersetuju kepada pemilih yang rapuh. Menggunakan XPaths panjang yang dihasilkan oleh AI sebagaimana adanya; Ujian ranap pada perubahan antara muka pertama.
- Meninggalkan `tidur` buta. "Menyelesaikan" masa dengan menunggu tetap; kedua-duanya perlahan dan tidak pasti.
- Penegasan remeh. Hanya sahkan bahawa halaman telah dimuatkan; tidak menyemak keputusan pengguna sebenar (fake-pass).
- Tumbuh tanpa POM. Edarkan pemilih kepada setiap ujian; Mengemas kini berpuluh-puluh fail secara manual apabila antara muka berubah.
- Tidak menyatakan alat. Tidak memberitahu AI alat/bahasa yang anda mahukan; semakin kusut, kod tidak berfungsi.
- Mempercayai apabila anda menjalankan kod yang dijana dan lulus. Tidak menguji dengan memecahkan kod.
Secara ringkasnya
Automasi ujian UI mengesahkan tingkah laku pengguna dengan memacu penyemak imbas sebenar dengan program. AI menjana kod ini dengan cepat, tetapi terdapat dua perangkap besar: ujian rapuh (pemilih buruk, menunggu buta) dan ujian lulus palsu (penegasan tidak lengkap/remeh). Tiga tiang ujian UI pepejal ialah pemilih komit (data-testid), penantian eksplisit dan penegasan yang mengesahkan hasil pengguna sebenar. Mempunyai ujian yang dijana dalam Model Objek Halaman secara radikal memudahkan penyelenggaraan. Uji setiap ujian yang dihasilkan dengan soalan "perubahan apakah yang akan memecahkan ini?"
Tugasan permohonan
Pilih aliran pengguna daripada projek anda sendiri (cth. log masuk atau carian). Dapatkan ujian tulis AI dengan templat "penjanaan ujian UI yang teguh". Kemudian: (1) semak dan betulkan pemilih dan tunggu dengan "pemeriksaan kerapuhan", (2) buktikan bahawa setiap ujian benar-benar mengesahkan dengan "bukti pseudo-pass", (3) pecahkan kod dan perhatikan bahawa ujian bertukar menjadi merah. Laporkan bilangan ujian yang dihasilkan dan diperbetulkan, dan bilangan kelemahan dan pas pseudo yang anda temui.
senarai semak
- [ ] Saya memberikan AI alat, bahasa, dasar pemilih dan seni bina (POM) dengan jelas.
- [ ] Saya mengesahkan bahawa pemilih adalah data-testid.
- [ ] Saya memastikan untuk menggunakan penantian eksplisit/automatik dan bukannya tidur buta.
- [ ] Saya menyemak bahawa setiap penegasan mengesahkan keputusan pengguna sebenar.
- [ ] Saya menguji setiap ujian dengan memecahkan kod; Saya melihat ia menjadi merah.
- [ ] Saya mengumpul ujian dalam struktur Model Objek Halaman.