Keuntungan:
- Kemampuan untuk menghasilkan kode pengujian UI yang kuat dengan kecerdasan buatan, termasuk uji data, tunggu terbuka, dan pernyataan yang memverifikasi hasil pengguna sebenarnya
- Kemampuan untuk menghindari pengujian yang rapuh (pemilih buruk, penantian buta) dan membuat pengujian mudah dipertahankan dalam struktur Model Objek Halaman
- Kemampuan untuk menguji setiap pengujian UI yang dihasilkan dengan memecahkan kode dan mendeteksi serta memperbaiki pengujian yang lulus palsu
Setiap klik, setiap pengisian formulir, setiap transisi halaman yang dilakukan pengguna di browser tidak dapat diuji berulang kali secara manual — itulah sebabnya otomatisasi pengujian UI (antarmuka pengguna; pengujian ini meniru perilaku pengguna dengan menjalankan browser sebenarnya secara terprogram) ada. Selenium, Penulis Drama, dan Cypress adalah alat paling umum untuk pekerjaan ini. Kecerdasan buatan (AI) sangat ahli dalam menulis kode untuk alat-alat ini: Anda mendeskripsikan kasus uji, AI memberi Anda draf skrip otomatisasi yang bisa diterapkan. Namun di sini peringatan utama dari modul ini berperan lagi: kode pengujian UI yang dihasilkan AI sering kali merupakan pengujian rapuh yang “menyala hijau tetapi memverifikasi hal yang salah” atau gagal. Tugas Anda bukan menjalankan kode ini, namun memastikan bahwa kode tersebut benar-benar memverifikasi hal yang benar.
Dalam unit ini, kami bertujuan untuk menghasilkan pengujian UI yang kuat, dapat dipelihara, dan benar-benar tervalidasi dengan AI; Anda akan belajar menghindari ujian yang rapuh.
Tiga pilar pengujian UI yang solid
1. Pencari elemen yang benar. Pengujian menggunakan pemilih untuk menemukan elemen pada halaman. AI sering kali menghasilkan penyeleksi yang rapuh: jalur XPath yang panjang (alamat terlalu bergantung pada struktur halaman), penyeleksi berdasarkan nama kelas CSS (rusak saat desain berubah). Cara yang kuat adalah atribut stabil seperti data-testid yang ditambahkan pengembang untuk pengujian. Secara eksplisit memaksakan hal ini pada AI.
2. Penantian yang eksplisit. Sumber kerentanan nomor satu dalam pengujian UI adalah waktu. Sleep(3) (blind wait) yang terus-menerus adalah praktik yang buruk: terkadang tidak cukup, terkadang membuang-buang waktu. Cara yang benar adalah dengan menggunakan menunggu secara eksplisit, yang mengatakan "tunggu sampai elemen ini muncul". Penulis naskah drama melakukan hal ini secara otomatis; Di Selenium Anda harus memintanya secara eksplisit.
3. Penegasan yang bermakna. Pengujian tersebut harus memverifikasi hasil yang benar-benar akan dilihat pengguna — seperti “nomor pesanan muncul di layar”, bukan hanya “halaman dimuat”. Jika tes yang dihasilkan oleh AI tidak memiliki pernyataan atau tidak penting, tes tersebut menghasilkan pseudo-pass (unit pertama).
Perhatian: Saat Anda pertama kali melihat pengujian UI yang dihasilkan AI, periksa paling banyak tiga hal: apakah penyeleksi telah diterapkan (pengujian data), sedang menunggu (tidak ada blind sleep), dan apakah pernyataan tersebut memverifikasi hasil pengguna yang sebenarnya? Jika ketiganya baik-baik saja, tesnya mungkin solid.
Model Objek Halaman
Ketika tes bertambah besar, menulis penyeleksi di dalam setiap tes menjadi mimpi buruk pemeliharaan. Model Objek Halaman (POM — pola desain yang mengumpulkan penyeleksi dan tindakan untuk setiap halaman/layar ke dalam satu kelas) menjaga pemilih tetap di satu tempat; Saat antarmuka berubah, Anda memperbaruinya dalam satu file. Minta AI melakukan pengujian dalam struktur POM, bukan secara langsung; Hal ini membuat pemeliharaan jauh lebih mudah.
Perintah lemah / Perintah kuat
Lemah: "Tulis tes Selenium untuk halaman login."
Kuat: "Tulis pengujian alur masuk dengan Playwright (TypeScript). Penyeleksi hanya menggunakan data-testid; jangan gunakan kontrol atas apa yang dilihat pengguna, bukan judul halaman.”
Perintah yang kuat; Alat ini memberikan bahasa, kebijakan pemilih, strategi tunggu, arsitektur (POM), dan ekspektasi penegasan yang ekspresif.
Uji data dan kemandirian lingkungan
Pengujian UI yang solid tidak hanya ditulis dengan benar, tetapi juga membuat dan membersihkan data pengujiannya sendiri. Pengujian yang dihasilkan AI sering kali ditautkan ke pengguna atau data yang diasumsikan sudah ada di lingkungan (“log masuk sebagai pengguna admin”). Asumsi ini rusak ketika pengujian dijalankan di lingkungan lain atau setelah pengujian lain (masalah ketergantungan pesanan di unit 9). Faktanya adalah bahwa setiap pengujian menghasilkan data yang diperlukan di awal pengujian (atau menyiapkannya dengan panggilan API) dan membersihkannya di akhir. Secara eksplisit instruksikan AI untuk "menyiapkan data apa pun yang menjadi sandaran pengujian ini; jangan berasumsi data siap pakai dari luar."
Poin penting lainnya adalah tidak melakukan pengujian UI dengan data pengguna sebenarnya. Jika salinan database produksi digunakan dalam lingkungan pengujian, catatan ini adalah data orang sungguhan; tangkapan layar dan rekaman pengujian dapat mengungkapkan data ini. Gunakan akun pengujian sintetis (fiksi); ini melindungi kerahasiaan dan membuat pengujian dapat direproduksi. Melakukan pengujian "pembatalan pesanan" dengan akun pelanggan sebenarnya merupakan kesalahan etika dan operasional.
Tip: Pertahankan pengujian UI sesedikit mungkin; Serahkan verifikasi sebenarnya pada API dan pengujian unit, yang cepat dan stabil. Pengujian UI mahal dan rapuh — gunakan hanya untuk memvalidasi aliran pengguna end-to-end (uji logika piramida).
Perbandingan kendaraan
fitur
selenium
penulis naskah drama
cemara
bahasa
Jawa, C#, Python, JS
JS/TS, Python, .NET, Jawa
JavaScript/Skrip Ketik
siaga otomatis
Tidak (dengan tangan)
Ya (kuat)
Ya
Multi peramban
lebar
Kromium/Firefox/WebKit
Dominan kromium
kecenderungan kerapuhan
Tinggi (siaga manual)
rendah
rendah
Kemudahan belajar
sedang
mudah
mudah
operasi paralel
Diperlukan jaringan
bawaan
Penduduk/berbayar
Saat meminta kode dari AI, sebutkan dengan jelas kendaraan mana yang memilikinya; Jika tidak, ini mungkin menghasilkan kode yang membingungkan dan tidak berfungsi.
Empat templat yang dapat disalin
1) Pembuatan pengujian UI yang solid:
Peran Anda: insinyur otomasi pengujian senior. Tulis pengujian dengan [alat + bahasa] untuk alur berikut: [aliran]. Aturan: - Hanya penyeleksi data-testid; Menggunakan kelas XPath/CSS. - Tidak tidur buta; Gunakan menunggu eksplisit/otomatis. - Terapkan Model Objek Halaman. - Biarkan masing-masing penegasan memverifikasi hasil pengguna sebenarnya. Beri komentar di awal setiap tes kriteria penerimaan mana yang Anda validasi.
2) Pengendalian kerapuhan:
Periksa pengujian UI berikut untuk mengetahui kerapuhannya: - Apakah ada pemilih yang tidak stabil (panjang
3) Konversi ke Objek Halaman:
Ubah kode pengujian biasa berikut menjadi struktur Model Objek Halaman. Pindahkan penyeleksi dan tindakan ke kelas halaman; Biarkan file pengujian hanya membaca alur skenario. [Alat/bahasa].Kode: [tempel kode]
4) Bukti transisi semu:
Buktikan bahwa pengujian UI ini benar-benar memvalidasi: Perubahan apa yang saya lakukan pada kode aplikasi yang akan mengubah pengujian ini menjadi MERAH? Jika Anda tidak dapat menemukan perubahan yang dapat mematahkan ujian tersebut, maka ujian tersebut tidak memadai; tambahkan pernyataan yang hilang. Tes: [tempel tes]
tiga kasus mini
Kasus 1 — Pembebasan dari pemilih yang rapuh. Dari 40 pengujian yang dilakukan satu tim dengan AI, 70% rusak setelah pembaruan antarmuka; tidak ada satupun yang merupakan bug sebenarnya, semuanya adalah penyeleksi XPath yang rapuh. Tim mengubah pengujian menjadi basis pengujian data dengan templat "pemeriksaan kerapuhan". Selama tiga pembaruan antarmuka berikutnya, jumlah kerusakan palsu turun menjadi nol; waktu pemeliharaan berkurang dari 6 jam menjadi 30 menit per minggu.
Kasus 2 - Lulus tes UI palsu. AI melakukan pengujian “tambahkan ke troli”; tesnya berwarna hijau. Ketika templat "bukti bagian palsu" dijalankan, pengujian tampaknya hanya memeriksa klik tombol dan judul halaman, tidak pernah memverifikasi apakah penghitung keranjang telah bertambah atau tidak. Sekalipun logika keranjang benar-benar rusak, ujiannya berhasil. Menambahkan pernyataan yang benar (lencana keranjang menjadi "1").
Kasus 3 — Jebakan menunggu yang buta. Dalam pengujian Selenium yang dihasilkan oleh AI, terdapat sleep(2) setelah setiap langkah; 60 tes memakan waktu 14 menit dan kadang-kadang masih gagal. Setelah beralih ke open wait (tunggu hingga elemen dapat diklik) waktu berkurang menjadi 5 menit dan kerapuhannya hilang. Penantian buta itu lambat dan tidak bisa diandalkan.
Kesalahan umum
- Menyetujui penyeleksi yang rapuh. Menggunakan XPath panjang yang dihasilkan oleh AI apa adanya; Pengujian macet saat perubahan antarmuka pertama.
- Meninggalkan `tidur` yang buta. "Menyelesaikan" waktunya dengan menunggu tetap; lambat dan ragu-ragu.
- Hal sepele menegaskan. Verifikasi saja bahwa halaman telah dimuat; tidak memeriksa hasil pengguna sebenarnya (pass palsu).
- Tumbuh tanpa POM. Bagikan penyeleksi ke setiap tes; Memperbarui lusinan file secara manual saat antarmuka berubah.
- Tidak menentukan alatnya. Tidak memberi tahu AI alat/bahasa apa yang Anda inginkan; menjadi berantakan, kode tidak berfungsi.
- Percaya ketika Anda menjalankan kode yang dihasilkan dan lulus. Tidak menguji dengan memecahkan kode.
Singkatnya
Otomatisasi pengujian UI memverifikasi perilaku pengguna dengan mengarahkan browser sebenarnya dengan program tersebut. AI menghasilkan kode ini dengan cepat, tetapi ada dua kendala besar: pengujian rapuh (pemilih buruk, menunggu buta) dan pengujian kelulusan palsu (penegasan tidak lengkap/sepele). Tiga pilar pengujian UI yang solid adalah pemilih penerapan (data-testid), penantian eksplisit, dan penegasan yang memverifikasi hasil pengguna sebenarnya. Memiliki pengujian yang dihasilkan di Model Objek Halaman menyederhanakan pemeliharaan secara radikal. Uji setiap pengujian yang dihasilkan dengan pertanyaan "perubahan apa yang akan merusak ini?"
Tugas aplikasi
Pilih alur pengguna dari proyek Anda sendiri (misalnya login atau pencarian). Lakukan pengujian penulisan AI dengan template “pembuatan pengujian UI yang kuat”. Kemudian: (1) periksa dan perbaiki penyeleksi dan tunggu dengan "pemeriksaan kerapuhan", (2) buktikan bahwa setiap pengujian benar-benar divalidasi dengan "bukti kelulusan semu", (3) pecahkan kode dan amati bahwa pengujian berubah menjadi merah. Laporkan jumlah pengujian yang dilakukan dan diperbaiki, serta jumlah kerentanan dan kesalahan palsu yang Anda temukan.
daftar periksa
- [ ] Saya memberi AI alat, bahasa, kebijakan pemilih, dan arsitektur (POM) dengan jelas.
- [ ] Saya memverifikasi bahwa penyeleksinya adalah data-testid.
- [ ] Saya memastikan untuk menggunakan menunggu eksplisit/otomatis daripada tidur buta.
- [] Saya memeriksa bahwa setiap pernyataan memverifikasi hasil pengguna sebenarnya.
- [] Saya menguji setiap tes dengan memecahkan kode; Aku melihatnya berubah menjadi merah.
- [] Saya mengumpulkan tes dalam struktur Model Objek Halaman.