Pengujian otomatis secara aktif berkembang untuk proyek web dan seluler. Namun aplikasi desktop masih harus diuji: masih digunakan oleh perusahaan keuangan, manufaktur, dan segmen HoReCa. Pergi ke bank, kafe, restoran terdekat - di mana pun Anda melihatnya Desktop Windows. Pada saat yang sama, pengujian aplikasi semacam itu hampir tidak dikembangkan, dan hanya ada sedikit informasi tentangnya.

Artikel ini ditulis berdasarkan pengalaman salah satu proyek kami: hal itu perlu pengujian Windows Aplikasi desktop dengan puluhan ribu baris kode. Pemeriksaan manual Solusi seperti itu akan memakan banyak waktu, jadi kami memutuskan untuk mengembangkan versi uji coba autotest untuk menyelesaikan proyek tersebut.

Saat memilih alat untuk tugas ini, kami dihadapkan pada kenyataan bahwa fungsi studio komersial difokuskan terutama pada web dan seluler, solusinya sendiri meningkatkan biaya proyek secara tidak wajar, dan tidak sepenuhnya jelas apa yang mereka miliki “dibawah kap mesin”. Kami berusaha untuk memahami sepenuhnya: apa sebenarnya yang kami tawarkan kepada klien, bagaimana kami menggunakannya, jadi kami beralih ke pencarian alat sumber terbuka dan memilih yang optimal.

Jadi, tugas kita adalah membuat versi percontohan AT (autotests). Tujuan utamanya adalah untuk mengotomatisasi pengujian aplikasi desktop .NET yang kompleks. Saat memilih alat, persyaratan berikut diajukan:

Efisiensi. Kemampuan untuk "dalam perjalanan keluar" melihat laporan dari CI dengan menjalankan enam tes ini setiap malam (atau menerima surat yang menjelaskan tes "gagal").

Transparansi. Tim penguji perlu memahami apa sebenarnya yang diperiksa di setiap langkah pengujian, dan manajer dapat membaca laporan dalam bentuk yang dapat dimengerti olehnya (misalnya: "jendela n tidak ada kolom masukan ketiga") .

Harga. Anda memerlukan alat yang tidak menambah biaya yang tidak perlu pada proyek.

Perbandingan kerangka kerja gratis

Solusi pertama yang diuji untuk tugas kami adalah UI Berkode Visual Studio.

Kelebihan:

Teknologi yang sama dalam pengujian seperti dalam pengembangan produk.

Ada perekam tes.

Bekerja dengan WinForm.

Bekerja dengan kontrol UI DevExpress.

Kontra:

Sejumlah kecil dokumentasi.

Berbayar VS.

Perekam pengujian menghasilkan kode yang tidak didukung dengan baik: pengujian langsung “gagal” setelah direkam dan dijalankan (mungkin tidak dapat direproduksi pada antarmuka “sederhana”).

Kasus uji penulisan BDD (menggunakan, misalnya, salah satu kerangka kerja paling populer di C# - Specflow) tidak kompatibel dengan Coded UI.

Keterbatasan pencarian dan bekerja dengan elemen antarmuka pengguna, diberlakukan oleh UIA API v.1 - MSAA.

Kelebihan:

Alat untuk menulis tes sepenuhnya dalam C#.

Kompatibel dengan kerangka kerja BDD.

Kontra:

Tidak ada cara untuk mengidentifikasi semua elemen UI dengan benar. Tidak berfungsi dengan elemen DevExpress.

Paket Nuget belum diperbarui sejak 2016.

Sedikit dokumentasi, komunitas kecil.

Lambatnya eksekusi kasus-kasus dasar (“buka aplikasi”, “periksa konten bilah status”)

Uji kerangka waktu pengembangan. Dukungan dan stabilitas pengujian UI

Enam skenario Regres yang cukup banyak dari contoh ini memerlukan tiga bulan pengembangan dari awal, termasuk pengenalan proyek, penelitian terhadap kerangka kerja yang tersedia yang dijelaskan di atas, pembuatan kerangka proyek AT, pengaturan CI (integrasi berkelanjutan), pengelolaan dan komunikasi, dan dokumentasi yang menyertainya. Proyek selesai dan selesai tepat waktu.

Karena kami terus mencakup skenario pengujian dengan autotest, operasi persiapan tentu saja akan memakan waktu lebih sedikit karena diterapkan pada tahap percontohan.

Menguji Integrasi Berkelanjutan

Kedua kerangka kerja mendukung pengujian yang berjalan menggunakan sistem integrasi berkelanjutan. Tim kami menggunakan TC dan TFS.

Saat menggunakan kerangka FLAUI, kerangka SpecFlow, dan pengujian yang ditulis dalam C#, tidak ada yang istimewa dalam membuat rakitan (svc - build - run), kecuali untuk memenuhi beberapa kondisi pada agen pelaksana pengujian:

Agen pembangunan diluncurkan sebagai utilitas dari baris perintah(bukan layanan), kedua sistem mendukung hal ini. Penting untuk menginstal autostart dari agen tersebut.

Pengaturan masuk otomatis (Gunakan SysInternals Autologon untuk Windows karena mengenkripsi kata sandi Anda di registri).

Nonaktifkan screen saver.

Nonaktifkan Pelaporan Kesalahan Windows. Bantuan pada Intinya: NonaktifkanWER.reg

Penting untuk memiliki sesi desktop aktif pada mesin tempat pengujian dirakit dan dijalankan. Cukup menggunakan aplikasi Windows standar untuk ini.

RDC. Namun Anda sering kali menemukan saran untuk menggunakan VNC(dengan argumen bahwa:saat menghubungkan melalui Remote Desktop dan kemudian memutuskan sambungan, desktop akan terkunciSaat Anda terhubung menggunakan Remote desktop, lalu putuskan sambungan, desktop akan terkunci, dan Otomatisasi UI akan gagal)

Kerangka kerja BDD Specflow memiliki integrasi langsung dengan TC dan TFS. Itu. Laporan pengujian yang berhasil dan gagal ditampilkan langsung saat pengujian dijalankan.

Contoh ROI autotest

Sebelum menerapkan otomatisasi, sulit untuk menghitung ROI, karena memang ada jumlah yang sangat besar faktor dan koefisien yang tidak diketahui. (Dan lebih baik tidak mempercayai perhitungan ROI di bagian harga Uji Selesai).

Namun setelah implementasi proyek otomasi percontohan, beberapa angka dapat diberikan. Ayo ambil yang terbaik rumus sederhana ROI:

ROI = (Keuntungan Investasi - Biaya Investasi) / Biaya Investasi

Biaya proyek otomasi untuk tahun pertama (tanpa dukungan):

3 bulan untuk menutupi proses Regresi dengan pengujian otomatis ketika salah satu insinyur pengembangan sedang mengerjakan pengujian: ternyata seperti itu500 jam * Kecepatan pengembangan per jam. Katakanlah biaya solusi (Biaya investasi) dibayar penuh oleh pelanggan pada tahun pertama (tidak dibagi menjadi beberapa bagian, dan tidak ada pinjaman yang diambil untuk membeli solusi).

Keuntungan:

Pada artikel pertama, kami menghitung bahwa “pengoperasian” pengujian regresi secara manual membutuhkan waktu 1 bulan: 2 minggu pengujian primer + 2 minggu pengujian sekunder (tanpa memeriksa pengujian baru dan biaya terkait).

Setelah mengembangkan regresi AT (3 bulan), uji regresi manual tidak dijalankan selama 9 bulan dalam setahun. Kami akan berasumsi bahwa sumber daya yang dibebaskan digunakan untuk proyek lain di perusahaan. Disimpan:1500 jam * Tarif QA per jam * 2 orang per tim.

ROI = (1500*QA*2 - 500*Pengembangan) / 500 * Pengembangan = (6*QA - 1*Pengembangan) / Pengembangan

Mengambil nilai pasar rata-rata QA rate = n, Dev rate = 1,5n kita mendapatkan:

ROI = (6n - 1,5n) / 1,5n = 3.

Tahun pertama, tentu saja, selalu memiliki pengembalian yang lebih rendah; angka-angka untuk tahun-tahun berikutnya akan berbeda secara signifikan karena kurangnya Biaya.

Tentu saja ini adalah perhitungan yang paling umum dan tidak memperhitungkan dukungan, penyusutan, peningkatan pelaporan, serta kualitas autotest itu sendiri. Penghitungan ROI kedua direkomendasikan setelah tahun pertama penggunaan AT, dengan mempertimbangkan fakta tambahan berikut.

Hasil

Pengujian otomatis yang dikembangkan menggantikan upaya manual tim QA dan membebaskan tim yang terdiri dari dua orang untuk tugas proyek yang lebih penting. Hal ini memastikan penggunaan sumber daya proyek secara optimal.

Ya, pengujian manual adalah bagian penting dari pengembangan. Namun jika perangkat lunak tersebut terdiri dari puluhan ribu baris kode dan memerlukan dua hingga tiga minggu pengembangan fitur baru Sebelum dirilis, otomatisasi sangatlah penting. Untuk memahami apakah menguntungkan untuk mencakup semua pekerjaan dengan pengujian otomatis dan apakah mungkin, tim kami menggunakan strategi Do Pilot: yaitu, mengotomatiskan bagian pekerjaan menggunakan kerangka kerja yang dipilih.

Namun, jika Anda menggunakan semuanya dalam solusi “kotak” berbayar untuk AT fungsi yang diperlukan dan meningkatkan skala tim menjadi setidaknya dua insinyur - mendukung solusi tersebut akan meningkatkan biaya proyek. Agar pelanggan perangkat lunak tidak perlu membayar di awal untuk solusi itu sendiri, dan kemudian - setiap tahun - untuk dukungannya, kami meninjau beberapa kerangka AT open source. Dari proposal kami memilih yang cocok untuk kami. Dua solusi yang ditemukan digunakan untuk pekerjaan.

Otomatisasi pengujian, meskipun memerlukan pelatihan dalam menemukan kerangka kerja dan mengembangkan pengujian otomatis itu sendiri, ternyata jauh lebih menguntungkan daripada “berjalan” secara manual.

Jika Anda perlu menguji aplikasi Anda dalam jangka waktu optimal dan tanpa menambah biaya yang tidak perlu, kami akan dengan senang hati menjawab pertanyaan Anda:

Telepon: +7 812 407 2350

E-mail: [dilindungi email]

• aplikasi
• FlaUI
• Jaminan Kualitas
• TestStack.Putih
• Studio Visual UI berkode
• WinAppDriver
• Desktop Windows
• Winium.Desktop
• otomatisasi pengujian

Halo, warga Khabrovsk yang terkasih!
Saya dan rekan saya sedang mempersiapkan laporan untuk konferensi tentang topik pengujian otomatisasi aplikasi desktop. Nilai dan kegunaan laporan akan semakin meningkat jika kita dapat menggunakan hasil survei komunitas profesional dalam pidato kita.
Saya akan membagikan hasilnya di Habré.

Pada dasarnya, pertanyaannya berkaitan dengan alat yang digunakan dalam proses pengujian perangkat lunak. Alat pengujian berarti: sistem pelacakan bug, sistem virtualisasi, sistem build, sistem kontrol versi, pengujian otomatis.

Ada tiga pertanyaan yang bisa diperdebatkan - semuanya dapat dijawab di sini di komentar.
Ikuti tautan http://www.surveymonkey.com/s/DJTFHFH – 10 pertanyaan pilihan ganda. Anda hanya membutuhkan waktu tidak lebih dari 2,5 menit untuk menjawabnya.

Acara ini akan berlangsung pada tanggal 20 Mei, jadi harap jawab pertanyaan survei paling lambat tanggal 18 Mei.
Terima kasih atas partisipasi Anda!

I. Gratis vs. Perangkat lunak komersial (berlisensi).

A. Menurut Anda, bagaimana pengaruh hal ini terhadap kualitas proses pengujian?
B. Dalam hal apa sebaiknya menggunakan perangkat lunak gratis untuk pengujian?

II. Menguji aplikasi desktop

Jika ya, apa tantangan utama yang Anda hadapi?

AKU AKU AKU. Pertanyaan umum dan alat tes (10 soal pilihan ganda =< 2,5 мин)
http://www.surveymonkey.com/s/DJTFHFH

P.S.
Survei ini sedang berlangsung, dan hasilnya menjanjikan representatif - pada 12 Mei, 123 orang merespons. Dan yang paling tidak terduga adalah setelah jumlah balasan melebihi 100, saya menerima pesan berikut saat memeriksa hasilnya:

Monyet Jajak Pendapat yang tidak tahu malu meminta 25 euro untuk melihat hasil lebih dari seratus responden - dan ini di tengah krisis mata uang di Belarus!
Teruslah menjawab dan kami akan menyelesaikannya :)

Pembaruan. Hasilnya dapat dilihat di

Aplikasi desktop - Ini adalah program berfitur lengkap yang bekerja secara independen dari aplikasi lain dan memerlukan operator. Untuk beroperasi, mereka memerlukan sumber daya perangkat keras komputer yang memadai, aplikasi itu sendiri, dan serangkaian fungsi untuk bekerja dengan aplikasi tersebut.

Aplikasi tersebut dihosting di komputer pengguna. Mereka tidak memerlukan koneksi Internet untuk beroperasi, berinteraksi dengan pengguna melalui antarmuka standar, memiliki kinerja lebih tinggi, dan bergantung pada perangkat yang digunakan. sistem operasi dan memerlukan instalasi di setiap komputer pengguna yang ingin bekerja dengan aplikasi ini. Ini editor teks, pemutar media, program perhitungan, kalkulus, studi - secara umum semua program yang diinstal di komputer kita adalah aplikasi desktop. Karena kami memiliki akses ke file sistem program, tipe ini aplikasi lebih rentan dan bergantung sepenuhnya pada tindakan pengguna.

Fitur utama pengujian aplikasi desktop adalah sebagai berikut:

Saat menguji aplikasi desktop, fitur-fitur yang tercantum di atas perlu diperhitungkan.

Jenis pengujian yang perlu dilakukan pada aplikasi desktop, selain yang utama (fungsional, GUI, kegunaan, dll), juga memiliki ciri khasnya masing-masing:

• pengujian instalasi
• menguji pembaruan
• pengujian penghapusan instalasi

Melaksanakan pengujian instalasi diperiksa:

1. Apakah program dimulai setelah instalasi?
2. Lokasi program di sistem file bawaan
3. Lokasi program dalam sistem file jika jalur penyimpanan diubah oleh pengguna
4. Ketersediaan shortcut di desktop
5. Apakah disana komponen yang dipasang di menu Mulai > Program
6. Saat memasang, perhatikan penerbitnya
7. Menginstal program untuk pengguna saat ini/untuk semua pengguna komputer
8. Instalasi oleh pengguna dengan hak admin
9. Instalasi oleh pengguna tanpa hak admin

Untuk menguji pembaruan, mereka menginstal secara khusus versi lama program, ia segera menemukan pembaruan dan diperbarui. Melaksanakanpengujian pembaruan perlu:

1. Periksa apakah data pengguna tidak rusak setelah menginstal pembaruan
2. Periksa apakah semua file yang sebelumnya dibuat oleh pengguna tetap dapat diakses

Melaksanakan pengujian penghapusan memeriksa:

1. File-file tersebut harus dihapus
2. Pintasan desktop telah hilang
3. Apakah entri tersebut dihapus dari Mulai > Semua Program?
4. Jalankan perintah %userprofile% melalui baris perintah untuk membuka folder pribadi pengguna saat ini. Pastikan tidak ada folder dengan nama program

Namun pada tahun 2018, masih perlu mengembangkan aplikasi desktop dan mendukung proyek lama. Bank, departemen keuangan perusahaan, produksi dan laboratorium, segmen HoReCa menggunakan aplikasi Windows Desktop. Banyak bisnis arah yang berbeda mereka digunakan untuk akuntansi, organisasi dan otomatisasi proses bisnis.

Mesin pengguna memberikan peluang yang tidak kalah dengan web. Dan terkadang lebih. Misalnya, ini bekerja dengan file lokal dan perangkat: pemrosesan data besar, kemampuan untuk menggunakan peralatan tertentu, akses berbagai layanan. Ada banyak alasan untuk tetap menggunakan aplikasi desktop:

• Koneksi perangkat eksternal. Misalnya menggunakan pemindai sidik jari untuk identifikasi, pemindai paspor dan perangkat lainnya.
• Kepatuhan dengan kebijakan keamanan. Misalnya di pabrik atau bank yang akses internetnya dilarang.
• Armada mesin yang sudah ada, yang mungkin terdiri dari, misalnya, PC yang menjalankan Windows 7.

Semua hal di atas adalah kebutuhan pelanggan nyata, dan pencapaian web tidak berlaku untuk tugas tersebut.

Apakah pengujian memakan waktu berbulan-bulan? Lakukan Strategi Percontohan

Pelanggan kami menggunakan aplikasi desktop (.NET) untuk pekerjaan kantor, organisasi dan pemeliharaan proses bisnis, yang telah dikembangkan dan dikembangkan selama bertahun-tahun.

Sekarang terdiri dari puluhan ribu baris kode, yang berarti ratusan pengujian dan diperlukan waktu sekitar satu setengah bulan untuk pengujian manual awal:

Dua minggu untuk menjalankan uji regresi manual secara manual.

Dua minggu untuk pengulangan.

Saatnya memperbaiki bug dan kemungkinan tumpang tindih.

Ketika kesalahan diperbaiki, waktu yang dihabiskan bertambah, dan tumpang tindih mungkin terjadi selama perencanaan dan pengendalian. Jumlah -sekitar 1,5 bulan pengerjaan oleh dua insinyur, yang biasanya terlibat dalam melakukan pemeriksaan regresi.

Setengah seperempat untuk pabrik, produksi atau bank, ketika Anda sangat perlu meningkatkan fungsionalitas, melakukan pengeditan, menambahkan modul, berubah menjadi kerugian uang.

Pelanggan memerlukan iterasi rilis cepat: permintaan, pengembangan, pengujian singkat, dan implementasi. Hal utama adalah menjaga kualitas pada tingkat yang sama, atau lebih baik lagi, meningkatkannya sesuai dengan kriteria kuantitatif yang obyektif. Di sinilah kebutuhan akan otomatisasi pengujian muncul.

Tentu saja, tidak semua hal dalam pengujian dapat diotomatisasi, dan beberapa tugas masih harus dilakukan secara manual. Namun jika Anda perlu mengetahui bagaimana otomatisasi dapat dilakukan, berguna, dan cocok untuk proyek tertentu, tim WaveAccess akan menggunakannyamengelola pola pengujian otomatis “Do Pilot”(“buat percontohan”).

Strategi Do Pilot adalah mengotomatiskan sebagian pekerjaan dan mengevaluasi hasilnya: waktu yang dihabiskan, skalabilitas pengujian, biaya dukungannya. Yaitu, membuat versi percontohan dari Autotest (AT), dan kemudian memutuskan apakah akan mentransfer semua pengujian ke otomatisasi.

Selalu lebih mudah menghabiskan beberapa minggu untuk memahami: ditemukan alat yang berguna, cocok untuk bisnis, atau hanya membuang-buang waktu.

Lakukan Percontohan pada proyek WaveAccess: persyaratan dan kemampuan

Jadi, kami memutuskan untuk mengimplementasikan versi percontohan AT untuk aplikasi .NET Windows Desktop klien kami yang besar. Untuk ini kami memilih versi stabil aplikasi dan memilih enam skenario pengujian utama, ditandai dengan tag Smoke atau Regress, yang mana bagian tersebut menjamin hal tersebut fungsi utama aplikasi yang diuji bekerja sesuai dengan spesifikasi teknis.

Persyaratan berikut diajukan untuk hasilnya:

Efisiensi. Dimungkinkan untuk melihat laporan "pada keluaran" dari CI (Integrasi Berkelanjutan) dengan menjalankan 6 pengujian ini setiap malam atau menerima surat yang menjelaskan pengujian "gagal".

Transparansi. Tim penguji memahami apa sebenarnya yang diperiksa di setiap langkah pengujian, dan manajer dapat membaca laporan, yang ditulis dalam bentuk yang dapat dimengerti olehnya (misalnya, "jendela n tidak memiliki kolom masukan ketiga").

Harga. Dipilih danAlat ini tidak menambah biaya proyek secara tidak perlu.

Pertanyaan utama yang kami hadapi adalah menemukan alat yang cocok untuk menulis AT yang dapat menjawabnya setiap orang kriteria.

Ikhtisar Solusi Pengujian Otomatis

Seperti yang kami katakan di atas: pengujian otomatis kini mendominasi teknologi web dan seluler. Mari kita lihat apa yang dapat ditemukan di bidang ini untuk Desktop Windows.

Alat berbayar. Tes Selesai

Salah satu pemimpin dalam kerangka berbayar adalah yang lengkapstudio untuk AT TestComplete dari SmartBear . Solusinya memiliki masa uji coba dan mendapat ulasan positif dari pengguna.

Kami memilih solusi out-of-the-box untuk satu pengguna:

Kami memilih solusi khusus, menghapus "Web" dan "Seluler".

Kami berusaha menurunkan harga semaksimal mungkin. Untuk kemungkinan pengujian tanpa batas dan tambahan lain yang diperlukan harus membayar ekstra 1700€ untuk satu lisensi.

Anda dapat mengajari tim pengujian Anda cara menggunakan studio TestComplete dengan menerimasertifikat untuk 150-700€ masing-masing . Mari kita ambil satu hal mendasar Tes Sertifikasi Lengkap.

Total:

Jadi, 4000€ per studio dan satu tahun dukungan per 1 pengguna. Namun, kami ingin menawarkan kepada pelanggan sebuah solusi yang, dengan tetap menjaga kualitas solusi berbayar “out of the box,” tidak akan memaksanya untuk membayar jumlah tersebut kepada kami, dan setelah satu tahun, terus membayar untuk perpanjangan lisensi.

Alat berbayar. Studio Tes Telerik

Alat berbayar berikutnya adalah Telerik Test Studio. Harganya:

Tapi Anda harus membayar untuk setiap fungsi tambahan:

Jumlah ini adalah 2499 + 899 +599 = 4000$ - hanya mencakupsatu pengguna dan satu tahun dukungan. Mengalikannya dengan jumlah pengguna, dan dengan proyek ini Tim WaveAccess terdiri dari dua insinyur,kita mendapatkan harga akhir: $8000 per tahun. Dan banyak framework berbayar lainnya juga memberikan kejutan dengan harganya.

Kesimpulan tentang kerangka yang dipertimbangkan

Kami berupaya mengoptimalkan sumber daya dengan tetap menjaga kualitas. Namun yang terpenting adalah kami berusaha untuk memahami sepenuhnya: apa sebenarnya yang kami tawarkan kepada klien, bagaimana kami menggunakannya. Oleh karena itu, perangkat lunak sumber terbuka kode program lebih disukai daripada solusi kotak - semacam "pig in a poke".

Bagian II: Ikhtisar Kerangka Open Source

Pengujian otomatis secara aktif berkembang untuk proyek web dan seluler. Namun aplikasi desktop masih harus diuji: masih digunakan oleh perusahaan keuangan, manufaktur, dan segmen HoReCa. Pergi ke bank, kafe, restoran terdekat - Anda akan melihat Windows Desktop di mana-mana. Pada saat yang sama, pengujian aplikasi semacam itu hampir tidak dikembangkan, dan hanya ada sedikit informasi tentangnya.

Artikel ini ditulis berdasarkan pengalaman salah satu proyek kami: kami perlu menguji aplikasi Desktop Windows dengan puluhan ribu baris kode. Pengujian manual terhadap solusi semacam itu akan memakan banyak waktu, jadi kami memutuskan untuk mengembangkan versi percontohan pengujian otomatis untuk menyelesaikan proyek.

Saat memilih alat untuk tugas ini, kami dihadapkan pada kenyataan bahwa fungsi studio komersial difokuskan terutama pada web dan seluler, solusinya sendiri meningkatkan biaya proyek secara tidak wajar, dan tidak sepenuhnya jelas apa yang mereka miliki “dibawah kap mesin”. Kami berusaha untuk sepenuhnya memahami apa sebenarnya yang kami tawarkan kepada klien dan bagaimana kami menggunakannya, jadi kami beralih ke pencarian alat sumber terbuka dan memilih yang terbaik.

Jadi, tugas kita adalah membuat versi percontohan AT (autotests). Tujuan utamanya adalah untuk mengotomatisasi pengujian aplikasi desktop .NET yang kompleks. Saat memilih alat, persyaratan berikut diajukan:

Efisiensi. Kemampuan untuk "dalam perjalanan keluar" melihat laporan dari CI dengan menjalankan enam tes ini setiap malam (atau menerima surat yang menjelaskan tes "gagal").

Transparansi. Tim penguji perlu memahami apa sebenarnya yang diperiksa di setiap langkah pengujian, dan manajer dapat membaca laporan dalam bentuk yang dapat dimengerti olehnya (misalnya: "jendela n tidak ada kolom masukan ketiga") .

Harga. Anda memerlukan alat yang tidak menambah biaya yang tidak perlu pada proyek.

Perbandingan kerangka kerja gratis

Solusi pertama yang diuji untuk tugas kami adalah UI Berkode Visual Studio.

Kelebihan:

Teknologi yang sama dalam pengujian seperti dalam pengembangan produk.

Ada perekam tes.

Bekerja dengan WinForm.

Bekerja dengan kontrol UI DevExpress.

Kontra:

Sejumlah kecil dokumentasi.

Berbayar VS.

Perekam pengujian menghasilkan kode yang tidak didukung dengan baik: pengujian langsung “gagal” setelah direkam dan dijalankan (mungkin tidak dapat direproduksi pada antarmuka “sederhana”).

Kasus uji penulisan BDD (menggunakan, misalnya, salah satu kerangka kerja paling populer di C# - Specflow) tidak kompatibel dengan Coded UI.

Pembatasan pencarian dan bekerja dengan elemen antarmuka pengguna diberlakukan oleh UIA API v.1 - MSAA.

Kelebihan:

Alat untuk menulis tes sepenuhnya dalam C#.

Kompatibel dengan kerangka kerja BDD.

Kontra:

Tidak ada cara untuk mengidentifikasi semua elemen UI dengan benar. Tidak berfungsi dengan elemen DevExpress.

Paket Nuget belum diperbarui sejak 2016.

Sedikit dokumentasi, komunitas kecil.

Lambatnya eksekusi kasus-kasus dasar (“buka aplikasi”, “periksa konten bilah status”)

Uji kerangka waktu pengembangan. Dukungan dan stabilitas pengujian UI

Enam skenario Regres yang cukup banyak dari contoh ini memerlukan tiga bulan pengembangan dari awal, termasuk pengenalan proyek, penelitian terhadap kerangka kerja yang tersedia yang dijelaskan di atas, pembuatan kerangka proyek AT, pengaturan CI (integrasi berkelanjutan), pengelolaan dan komunikasi, dan dokumentasi yang menyertainya. Proyek selesai dan selesai tepat waktu.

Karena kami terus mencakup skenario pengujian dengan autotest, operasi persiapan tentu saja akan memakan waktu lebih sedikit karena diterapkan pada tahap percontohan.

Menguji Integrasi Berkelanjutan

Kedua kerangka kerja mendukung pengujian yang berjalan menggunakan sistem integrasi berkelanjutan. Tim kami menggunakan TC dan TFS.

Saat menggunakan kerangka FLAUI, kerangka SpecFlow, dan pengujian yang ditulis dalam C#, tidak ada yang istimewa dalam membuat rakitan (svc - build - run), kecuali untuk memenuhi beberapa kondisi pada agen pelaksana pengujian:

Agen pembangunan diluncurkan sebagai utilitas baris perintah (bukan layanan), kedua sistem mendukung hal ini. Penting untuk menginstal autostart dari agen tersebut.

Pengaturan masuk otomatis (Gunakan SysInternals Autologon untuk Windows karena mengenkripsi kata sandi Anda di registri).

Nonaktifkan screen saver.

Nonaktifkan Pelaporan Kesalahan Windows. Bantuan pada Intinya: NonaktifkanWER.reg


Penting untuk memiliki sesi desktop aktif pada mesin tempat pengujian dirakit dan dijalankan. Cukup menggunakan aplikasi Windows standar untuk ini.

RDC. Namun Anda sering kali menemukan saran untuk menggunakan VNC(dengan argumen bahwa:saat menghubungkan melalui Remote Desktop dan kemudian memutuskan sambungan, desktop akan terkunciSaat Anda terhubung menggunakan Remote desktop, lalu putuskan sambungan, desktop akan terkunci, dan Otomatisasi UI akan gagal)

Kerangka kerja BDD Specflow memiliki integrasi langsung dengan TC dan TFS. Itu. Laporan pengujian yang berhasil dan gagal ditampilkan langsung saat pengujian dijalankan.

Contoh ROI autotest

Sebelum menerapkan otomatisasi, sulit untuk menghitung ROI, karena ada banyak sekali faktor dan koefisien yang tidak diketahui. (Dan lebih baik tidak mempercayai perhitungan ROI di bagian harga Uji Selesai).

Namun setelah implementasi proyek otomasi percontohan, beberapa angka dapat diberikan. Mari kita ambil rumus ROI paling sederhana:

ROI = (Keuntungan Investasi - Biaya Investasi) / Biaya Investasi

Biaya proyek otomasi untuk tahun pertama (tanpa dukungan):

3 bulan untuk menutupi proses Regresi dengan pengujian otomatis ketika salah satu insinyur pengembangan sedang mengerjakan pengujian: ternyata seperti itu500 jam * Kecepatan pengembangan per jam. Katakanlah biaya solusi (Biaya investasi) dibayar penuh oleh pelanggan pada tahun pertama (tidak dibagi menjadi beberapa bagian, dan tidak ada pinjaman yang diambil untuk membeli solusi).

Keuntungan:

Pada artikel pertama, kami menghitung bahwa “pengoperasian” pengujian regresi secara manual membutuhkan waktu 1 bulan: 2 minggu pengujian primer + 2 minggu pengujian sekunder (tanpa memeriksa pengujian baru dan biaya terkait).

Setelah mengembangkan regresi AT (3 bulan), uji regresi manual tidak dijalankan selama 9 bulan dalam setahun. Kami akan berasumsi bahwa sumber daya yang dibebaskan digunakan untuk proyek lain di perusahaan. Disimpan:1500 jam * Tarif QA per jam * 2 orang per tim.

ROI = (1500*QA*2 - 500*Pengembangan) / 500 * Pengembangan = (6*QA - 1*Pengembangan) / Pengembangan

Mengambil nilai pasar rata-rata QA rate = n, Dev rate = 1,5n kita mendapatkan:

ROI = (6n - 1,5n) / 1,5n = 3.

Tahun pertama, tentu saja, selalu memiliki pengembalian yang lebih rendah; angka-angka untuk tahun-tahun berikutnya akan berbeda secara signifikan karena kurangnya Biaya.

Tentu saja ini adalah perhitungan yang paling umum dan tidak memperhitungkan dukungan, penyusutan, peningkatan pelaporan, serta kualitas autotest itu sendiri. Penghitungan ROI kedua direkomendasikan setelah tahun pertama penggunaan AT, dengan mempertimbangkan fakta tambahan berikut.

Hasil

Pengujian otomatis yang dikembangkan menggantikan upaya manual tim QA dan membebaskan tim yang terdiri dari dua orang untuk tugas proyek yang lebih penting. Hal ini memastikan penggunaan sumber daya proyek secara optimal.

Ya, pengujian manual adalah bagian penting dari pengembangan. Namun ketika perangkat lunak terdiri dari puluhan ribu baris kode dan memerlukan waktu dua hingga tiga minggu sejak pengembangan fitur baru hingga dirilis, otomatisasi menjadi sangat penting. Untuk memahami apakah menguntungkan untuk mencakup semua pekerjaan dengan pengujian otomatis dan apakah mungkin, tim kami menggunakan strategi Do Pilot: yaitu, mengotomatiskan bagian pekerjaan menggunakan kerangka kerja yang dipilih.

Namun, jika Anda menggunakan semua fungsi yang diperlukan dalam solusi “kotak” berbayar untuk AT dan menskalakan tim menjadi setidaknya dua insinyur, mendukung solusi tersebut akan meningkatkan biaya proyek. Agar pelanggan perangkat lunak tidak perlu membayar di awal untuk solusi itu sendiri, dan kemudian - setiap tahun - untuk dukungannya, kami meninjau beberapa kerangka AT open source. Dari proposal kami memilih yang cocok untuk kami. Dua solusi yang ditemukan digunakan untuk pekerjaan.

Otomatisasi pengujian, meskipun memerlukan pelatihan dalam menemukan kerangka kerja dan mengembangkan pengujian otomatis itu sendiri, ternyata jauh lebih menguntungkan daripada “berjalan” secara manual.

saya datang ke menguji program desktop setelah 2 tahun pengujian web dan aplikasi seluler. Secara umum banyak sekali ilmu yang bermanfaat dan bisa saya terapkan dalam praktek.

Prinsip pengujiannya tetap sama. Dasar-dasarnya sama. Parameter input dan output, hasil yang diharapkan dan aktual, mencari perbedaan; tentu saja, semua ini berlaku dalam pengujian aplikasi desktop.

Perbedaan utama dalam pengujian desktop dan web

Dalam pengujian layanan web, klien utamanya adalah browser. Mereka dibagi menjadi seluler/desktop dan lainnya. Dan dalam pengujian aplikasi desktop, klien utamanya adalah sistem operasi.

Untuk produk kami, dua cabang OS utama adalah Windows dan Server Windows. Versi saat ini Windows - XP (SP1, SP2, SP3), Windows Vista, Windows 7, Windows 8, Windows 10. Server - Windows Server 2003, Windows Sever 2008, Windows Server 2010.

Di mana mulai menguji aplikasi desktop

Saya mulai dengan mengenal HELP - manual produk. Bagi saya itu adalah daerah baru dan saya sangat beruntung karena ada banyak sekali dokumentasi yang tersedia untuk pemula.

Mari kita lihat kasus uji menggunakan contoh Ms Office yang terkenal, juga tersedia sebagai layanan awan Kantor 360.

Persyaratan Sistem

Pengujian persyaratan sistem

Prosesor. Set instruksi SSE2 minimum . Jika prosesor Anda tidak mendukung persyaratan ini, program akan menampilkan pesan yang menunjukkan bahwa instalasi tidak mungkin dilakukan. Saat ini sulit untuk menemukan prosesor yang tidak mendukung SSE2, hanya ada beberapa jenis dari tahun 2002-2004, bahkan jarang. Sekarang ini tidak penting untuk produk kami, jadi kami melewatkannya kasus uji. Tapi jangan lupakan yang umum prosesor AMD, yang tidak mendukung instruksi jenis ini. Dalam kasus seperti ini, program akan crash. Jika Windows berhasil mencegat proses dan menimbulkan kesalahan, maka ada kemungkinan untuk menangkap bug ini.

Selama saya bekerja di perusahaan tersebut, ada kasus setelah rilis banyak keluhan mulai diterima dari pelanggan. Namun menangkap bug tersebut sangat bermasalah, karena tidak ada konfigurasi perangkat keras yang sesuai. Hanya programmer yang berhasil menangkapnya dengan bantuan hati-hati tinjauan kode. Rilis ini mencakup transisi dari perpustakaan lama ke perpustakaan baru, dan karenanya persyaratan minimum meningkat menjadi besi. Akibatnya, pengguna dengan perangkat keras lama tidak dapat memperbarui aplikasi.

Setelah perbaikan bug, kode sudah memperhitungkan semua persyaratan minimum. Kami juga telah memperbarui deskripsi produk untuk menyertakan spesifikasi minimum yang disarankan.

RAM Komputer. Kami melakukan uji kasus positif dan negatif. Mari kita lihat bagaimana program ini akan beroperasi kapan<= 2ГБ ПЗУ, >=ROM 2GB. Seringkali saya lewat gambar maya Kotak Oracle.

-ku tes kewarasan:

• Kami meningkatkan mesin virtual dengan RAM 2GB.
• Mari kita luncurkan programnya. Semuanya baik-baik saja.
• Kemudian kita kurangi di setting virtual menjadi 1GB, 512MB dan seterusnya
• Mari kita luncurkan programnya. Bingo!

Harddisk . Mirip dengan ROM. Anda dapat menambahkan tes negatif, ketika Anda tidak memiliki ruang disk dan Anda sedang menginstal program dan/atau sudah menjalankannya. Lain halnya ketika program dijalankan dan ditulis ke disk. Aplikasi harus menangani situasi ketika tidak ada cukup ruang perekaman dengan benar.

Menampilkan . Kasus utamanya adalah berbagai resolusi, dari minimum hingga 4K. Jenis monitor ini mulai lebih sering ditemukan. Perhatian khusus Anda juga perlu memperhatikan penyimpanan jendela aplikasi. Coba perkecil/perluas/pulihkan/ubah ukuran dan tutup aplikasi. Pertimbangkan situasi dengan 2 layar, sekarang ada beberapa di antaranya. Dalam kasus ini, program harus mengingat dimensi dan parameter tampilan saat program diluncurkan.

Subsistem grafis . Kami melihat persyaratan minimum dan meluncurkannya. Komputer/laptop modern, bahkan dengan kartu video internal, dapat menjalankan sebagian besar aplikasi. Proyek saya tidak memerlukan sumber daya yang besar, jadi kami jarang bekerja dengan tumpukan kartu video yang besar.

Pengujian sistem operasi

Selalu perhatikan kedalaman bit sistem operasi. Dia punya nilai yang besar. Jika program Anda terkait dengan perhitungan matematis, maka pada OS dengan kedalaman bit berbeda, hasilnya bisa sangat berbeda. Selalu uji aplikasi dengan mempertimbangkan pembaruan Microsoft. Mereka cenderung sering menambal lubang. A pembaruan yang sering sistem operasi dapat membahayakan program Anda.

Di server dan reguler Versi Windows Ada diferensiasi hak akses. Administrator, tamu dan lain-lain. Penting untuk mempertimbangkan semua peran ini dan dapat menginstal program bahkan dalam mode tamu. Meskipun tamu tidak memiliki akses tulis ke file program,dia harus memiliki miliknya sendiri direktori sementara dan instal program di folder ini.

Tes negatif juga mungkin. Misalnya, coba instal program Anda di folder tanpa izin menulis atau membaca.

Peramban. Dia juga menemukan tempat di sini. Seringkali aplikasi menggunakan mesin asli peramban Windows, dalam kasus kami yaitu. Maupun Aplikasi Android dapat dibangun di Webview. Windows 10 menggunakan MS Edge, Windows 8.1 IE 11, Windows XP SP3 versi maksimal ini IE8. Jika persyaratan minimum untuk produk Anda adalah IE9+, maka pengguna Windows XP tidak akan puas.

Dalam proyek saya, saya terutama menggunakan pengujian kotak hitam, kami tidak memiliki akses ke kode tersebut, dan tidak ada debugger umum (seperti pembakar) di sini. Namun jangan lupa tentang otomatisasi; saya akan menceritakannya kepada Anda di artikel berikutnya. Saya akan dengan senang hati menjawab pertanyaan Anda!