Sering terjadi bahwa aplikasi web terdiri dari sejumlah besar bentuk restrukturisasi dinamis dengan teks dan kontrol yang berbeda. Menguji aplikasi seperti itu berubah menjadi mimpi buruk.Anda perlu mengklik 100500 halaman dan memeriksa semua fungsi ... Dan sebelum rilis berikutnya, periksa lagi ... Dan lagi ... Dan besok lagi. Pada titik tertentu, verifikasi mulai memakan waktu lebih lama daripada pengembangan fungsionalitas baru. "Bagaimana dengan tes e2e?" - Anda bertanya. Tapi, pertama, masih perlu ditulis. Dan kedua, sebelum Anda mulai menulisnya, Anda perlu menulis test case. Banyak kasus uji.Jika saat membaca kalimat-kalimat ini dahi Anda tertutup keringat, jangan khawatir. Pada artikel ini, saya akan berbagi dengan Anda gagasan tentang bagaimana kami di Tinkoff melakukan pengujian otomatis terhadap salah satu aplikasi web tanpa menulis satu test case dan e2e test.
Secara otomatis menulis test case
Kebetulan bahwa pengujian aplikasi web kami terutama terkait dengan pemeriksaan antarmuka. Anda perlu memeriksa bahwa tombol ada di layar, judul dan teks yang diinginkan ditampilkan, dan ketika Anda memasukkan nilai input yang tidak valid , pesan kesalahan muncul.Karena itu, saat menulis kasus uji, Anda harus mencatat semua tindakan:- "Menekan tombol"
- "Masukkan nilai XXX"
- “Memilih nilai YYY di daftar turun bawah”
dan memeriksa:- “Teks muncul: XXX”
- "Pesan kesalahan muncul: YYY"
- "Judulnya muncul: ZZZ"
Setelah menganalisis semua fungsi aplikasi web kami, kami mengidentifikasi sekitar 30 tindakan dan pemeriksaan unik. Menjadi jelas bahwa proses ini dapat otomatis. Untuk melakukan ini, Anda hanya perlu melacak semua tindakan penguji di halaman dan reaksi situs terhadap tindakan ini.Mari kita mulai dengan mencegat acara. Untuk melacak interaksi dengan kontrol seperti tombol, tombol radio dan kotak centang, Anda harus berlangganan ke acara klik. Setiap kerangka kerja memiliki metode sendiri untuk ini. Misalnya, dariEvent di Angular dan document.addEventListener di JavaScript dan React. Untuk kontrol input, seperti kalender atau input, hanya jenis acara yang Anda ingin berlangganan akan berubah: alih-alih klik, fokus akan menjadi.fromEvent(this.elementRef.nativeElement, 'click')
.subscribe(tagName => {
if (tagName === 'BUTTON') {
this.testCaseService.addAction(` "${action.name}"`);
} else if (tagName === 'INPUT-CALENDAR') {
this.testCaseService
.addAction(` "${action.name}" "${action.value}"`);
}
});
Dan akhirnya, yang paling penting adalah memeriksa. Cara situs harus berperilaku dalam menanggapi tindakan penguji.Apa yang biasanya diperiksa oleh tester? Misalnya, ia memasukkan nilai input yang tidak valid , situs merespons dengan pesan kesalahan. Atau, katakanlah kita mengklik tombol dan sebagai respons layar baru muncul, judul berubah, teks baru muncul, dan kontrol dibangun kembali. Semua perubahan ini terkait dengan perubahan pada pohon DOM. Ada banyak opsi untuk melacaknya. Anda dapat, misalnya, menggunakan MutationObserver di Bereaksi dan JavaScript atau ngAfterViewInit di Angular (menempatkan arahan pada elemen bentuk yang menarik di situs).ngAfterViewInit() {
const tagName = this.nativeElement.nodeName;
const text = this.nativeElement.textContent;
if (['SPAN', 'P'].includes(tagName)) {
this.testCaseService.addContent(`** ** "${text}"\n`);
} else if (tagName === 'H1') {
this.testCaseService.addContent(`** ** "${text}"\n`);
} …
}
Kode akan sangat tergantung pada tata letak. Mari kita lihat markupnya. Tombol-tombol ini diambil dari penerjemah Google.
<div class="tlid-input-button input-button header-button tlid-input-button-text text-icon" role="tab" tabindex="-1">
<div class="text"></div>
</div>
<div class="tlid-input-button input-button header-button tlid-input-button-docs documents-icon" role="tab" tabindex="-1">
<div class="text"></div>
</div>
Terlepas dari kenyataan bahwa tombol tidak direpresentasikan sebagai tag tombol , melihat markup, Anda dapat memilih semua tombol pada halaman menggunakan kelas css "tombol-input", dan Anda bisa mendapatkan nama tombol dari kelas "teks" css yang bersarang.Setengah pekerjaan sudah selesai, hanya menuliskan semua yang kami lacak ke dalam test case.Kami menyertakan intersepsi semua tindakan di situs untuk kombinasi tombol tertentu dan hanya di sirkuit uji. Kami menghentikan intersepsi semua peristiwa di situs dengan kombinasi tombol tertentu. Ini memungkinkan Anda untuk memulai dan menghentikan rekaman otomatis dari test case dari mana saja.Secara otomatis menulis tes e2e
Jika Anda melihat kotak uji yang dibuat secara otomatis, maka pada dasarnya ini adalah skrip pengguna yang direduksi menjadi bentuk yang sama. Jadi, mereka dapat dikonversi menjadi tes e2e. Anda bahkan dapat segera menulis tes e2e setelah mencegat semua tindakan dan memeriksa, melewati kasus uji.Sekarang ada sejumlah besar kerangka kerja yang berbeda dengan notasi gherkin berdasarkan skrip perilaku: SpecFlow, xBehave.net., Cucumber.js, CodeceptJS, dll.Untuk mendapatkan fitur dari case uji, Anda perlu menambahkan kata kunci When sebelum tindakan dan sebelum semua cek Lalu dan Dan.Dapatkan tes e2e yang dibuat secara otomatis:Feature: 2-
Background:
When "" ""
Scenario:
When " - "
Then " "
And " - "
When " " ""
When "" " "
When ""
Untuk menjalankan uji coba, fitur yang dihasilkan sedikit - Anda harus menulis penangan untuk semua tindakan dan pemeriksaan.Ada kabar baik: Anda tidak perlu menulis handler untuk setiap fitur. Seperti yang sudah saya katakan, meskipun sejumlah besar formulir berbeda di situs, kami hanya mendapat 30 tindakan dan pemeriksaan unik, yang berarti bahwa jumlah metode yang persis sama akan ada di prosesor umum untuk semua tes e2e. Kode akan sedikit berbeda - tergantung pada kerangka yang dipilih dengan notasi gherkin dan tata letak di situs. Tetapi menulis pawang itu sendiri tidak membutuhkan banyak waktu.When(' {string}', async function (button: string) {
const xpath = "//button"
const btn = await getItemByText(xpath, button)
await waitAndClick(btn)
})
When(' {string} {string}', async function (label: string, text: string) {
const xpath = "//*[contains(text(),'" + label + "')]/ancestor::outline"
await inputSendKeys(currentBrowser().element(by.xpath(xpath)), text)
})
Sekarang, memeriksa tugas selanjutnya, test case secara otomatis ditulis untuk tester dan tes e2e yang dihasilkan secara otomatis dijalankan.Singkatnya, Anda perlu:- Berlangganan acara interaksi dengan kontrol dan reaksi situs terhadap tindakan ini (melalui pelacakan pembangunan kembali pohon DOM).
- Konversi data dari paragraf 1 ke pengujian e2e.
- Tulis penangan umum untuk menjalankan tes e2e.
Pendekatan ini akan membantu Anda menjauh dari rutinitas. Anda dapat mengotomatiskan penulisan kasus uji dan tes e2e untuk pemeriksaan sederhana yang terkait dengan antarmuka. Kami telah melangkah lebih jauh dan memeriksa secara otomatis juga catatan dalam database dan mengirim ke layanan pihak ketiga.Saya membicarakan hal ini, juga versi, tumpukan teknologi, dan bahkan tentang masalah pada tahap pertama implementasi dan solusi mereka pada konferensi Heisenbug-2019 di Moskow .Dalam artikel ini, saya mencoba menyampaikan ide utama tanpa merinci.Kesimpulan
Sekarang kita membutuhkan 2 menit rata-rata untuk menulis test case dan e2e test - ini 60 kali lebih cepat dari perhitungan awal, ketika kita ingin menulis case test dan e2e test secara manual.Kami tidak mengubah proses dalam tim. Tidak perlu lagi mengalokasikan kapasitas tes untuk menulis kasus uji dan membawanya ke tim otomasi.Kami sepenuhnya pergi dari gagasan regresi. Jika sebelumnya, dengan sprint dua minggu, regresi membawa kami lebih dari 3 hari, sekarang regresi membutuhkan waktu untuk menjalankan semua tes e2e, dan ini hanya 2 jam.Saat menulis tes e2e secara manual, sangat sulit untuk paralel dengan pengujian. Sekarang, tes e2e ditulis secara otomatis selama pengujian tugas, dan tester tidak perlu memeriksa fungsi yang sama dua kali.Hasilnya, tim kami, tanpa mengubah komposisi, mulai bekerja jauh lebih efisien.