Pola otomatisasi UI dan praktik terbaik untuk aplikasi desktop

Latar Belakang

Saat ini saya mengotomatisasi beberapa tes untuk plugin untuk MS Office. Kami sedang membuat tes Coded UI di VS 2010. Saya kira saya bisa menggunakan alat " Coded UI test builder ", tetapi tidak benar-benar sesuai dengan kasus khusus saya.

Karena itu saya membuat kelas Peta UI saya sendiri dan metode ekstensi untuk setiap Kontrol UI / Peta tempat saya menambahkan fungsionalitas tindakan yang berbeda. Misalnya menekan tombol atau menyatakan beberapa nilai UI.

Skenario kasus uji ada di kelas tes.

Saya baru di bidang ini dan juga baru dalam bekerja sebagai penguji otomatisasi.

Pertanyaan

Apakah orang akan berbaik hati untuk berbagi pengalaman dan saran mereka untuk beberapa praktik yang baik untuk otomatisasi pengujian pada aplikasi desktop dari sudut pandang pemrograman / desain?

Praktik terbaik untuk Pengujian Otomasi UI adalah melakukan sesedikit mungkin. UI sering berubah, yang berarti Anda harus terus memperbarui otomasi Anda. Biasanya lebih disukai untuk menyusun kode produk dengan cara yang memungkinkan pengujian otomatis tanpa UI Automation.

Yang mengatakan, Anda tidak selalu dapat menyingkirkan Otomasi UI. Anda menyebutkan office jadi saya berasumsi Anda sedang mengkode untuk Windows dan menggunakan .Net. Saya melakukan sedikit pekerjaan saya saat ini. Inilah beberapa hal yang telah saya pelajari.

1) Lihatlah perpustakaan UIAutomation yang diperkenalkan di .Net 3.0. Mereka menyediakan perpustakaan yang luas dan cukup mudah digunakan untuk otomatisasi. (http://msdn.microsoft.com/en-us/library/ms753107.aspx)

2) Unduh UISpy (http://msdn.microsoft.com/en-us/library/ms727247.aspx)

3) Jadikan UI produk Anda Automatable.

3a) Jika WPF menempatkan AutomationIDs pada segalanya.

3b) Cobalah untuk membuat kontrol khusus dan nama kelas jendela (Nama Kelas UI, bukan nama kelas kode sumber). Jika Anda tidak tahu apa yang saya maksud, muat UI Spy dan mulai melihat windows. Perhatikan berapa banyak jendela di berbagai aplikasi yang memiliki nama kelas # 32770. Ini adalah nama kelas untuk Kotak Dialog Windows. Jendela apa pun yang memperluas dialog dan tidak menetapkan namanya sendiri, default untuk ini. Ini menyebabkan segala macam kesedihan dari sudut pandang Otomatisasi UI.

4) Hindari pernyataan Thread.Sleep (). Cobalah untuk menggunakan Pelayan (lihat dokumen UIAutomation) sebagai gantinya.

5) JANGAN PERNAH mencampur kode uji dengan kode Otomatisasi UI. Buat perpustakaan terpisah untuk melakukan Otomasi UI. Panggil perpustakaan ini dari tes Anda. Ketika UI berubah, ini akan membuatnya lebih mudah untuk memperbarui otomasi.

6) Selalu daftarkan pendengar untuk Acara UI sebelum melakukan tindakan yang akan menyebabkan acara tersebut menyala. Dalam praktiknya, ini berarti Anda akan bekerja dengan utas.

6a) Contoh: jangan mulai menunggu acara Buka Jendela setelah Anda mengklik tombol untuk membuka jendela. Jendela dapat terbuka sebelum pelayan terdaftar dan tidak pernah mendapatkan acara tersebut.

7) Jangan pernah menganggap jendela yang baru saja dibuka adalah yang Anda inginkan. Semua jenis jendela mungkin terbuka secara tak terduga di Windows.

Saya bisa melanjutkan lebih, tapi ini agak lama.

Buat tes fungsional dari kasus penggunaan yang dapat digunakan kembali

Ketika tiba saatnya untuk menguji aplikasi Anda ujung ke ujung in-situ, Anda melakukan pengujian fungsional. Biasanya Anda akan memiliki serangkaian persyaratan yang Anda uji terhadapnya dan Anda akan dapat membuat berbagai kasus penggunaan yang mewakili mereka.

Sebagai contoh, pertimbangkan kasus penggunaan "Masuk sebagai pengguna standar". Kerangka pengujian Anda menjalankan aplikasi, menunggu layar masuk, memasuki beberapa kredensial, mengklik tombol masuk dan memverifikasi bahwa layar yang sesuai sekarang menunjukkan bahwa masuk berhasil.

Setelah Anda menggunakan kasing kasus "Masuk sebagai pengguna standar", Anda ingin membuatnya menggunakan kasing lain, mungkin kasing "Edit detail pengguna saya". Anda tidak ingin mengulangi semua kode dari case penggunaan "Login sebagai pengguna standar", jadi Anda hanya membuat referensi ke kode kerangka uji yang melakukan itu.

Ini menyiratkan bahwa Anda memiliki semacam tes fungsional melengkung yang berisi daftar kasus penggunaan. Kasing yang digunakan ini berisi metode kerangka uji untuk menyebabkan perilaku aplikasi (klik tombol X) dan memverifikasi perilaku (layar berubah menjadi biru).

Secara keseluruhan, Anda dapat membangun tubuh kasus penggunaan yang dapat digunakan kembali yang menargetkan urutan spesifik dan menguji respons spesifik, dan kemudian menggabungkannya ke dalam berbagai tes fungsional yang berkorelasi erat dengan persyaratan bisnis. Setelah Anda melakukannya, maka Anda berada dalam posisi yang bagus untuk mengotomatisasi seluruh proses pembuatan Anda .

Jika Anda tertarik membaca lebih lanjut, saya telah menulis tentang pendekatan ini di tempat lain, tetapi artikel ini menargetkan aplikasi web di Java (menggunakan Maven dan SeleniumRC) daripada aplikasi desktop yang Anda minta.