Bagaimana orang-orang mempertahankan ruang tes mereka?


17

Secara khusus, saya ingin tahu tentang aspek-aspek berikut:

  1. Bagaimana Anda tahu bahwa kasus pengujian Anda salah (atau kedaluwarsa) dan perlu diperbaiki (atau dibuang)? Maksud saya, bahkan jika suatu test case menjadi tidak valid, itu mungkin masih berlalu dan tetap diam, yang dapat membuat Anda secara salah percaya bahwa perangkat lunak Anda bekerja dengan baik. Jadi, bagaimana Anda menyadari masalah seperti pada test suite Anda?

  2. Bagaimana Anda tahu bahwa test suite Anda tidak lagi memadai dan bahwa test case baru harus ditambahkan? Saya kira ini ada hubungannya dengan perubahan persyaratan, tetapi apakah ada pendekatan sistematis untuk memeriksa kecukupan test suite?


4
Untuk parafrase: siapa yang menguji tes?
Konrad Rudolph

Jawaban:


11

Jawaban singkat: gunakan alat yang dikenal yang membantu menjaga kualitas kasus uji seperti cakupan kode berikut dan alat kualitas kode: Cobertura, PMD, Sonar, dll. Yang akan membantu Anda memperhatikan ketika komponen penting dari program tidak cukup diuji. Juga, tulis tes integrasi, yang kemungkinan besar akan rusak lebih dulu setiap kali terjadi kesalahan.

Jawaban panjang:

Bagaimana Anda tahu bahwa kasus pengujian Anda salah (atau kedaluwarsa) dan perlu diperbaiki (atau dibuang)? Maksud saya, bahkan jika suatu test case menjadi tidak valid, itu mungkin masih berlalu dan tetap diam, yang dapat membuat Anda secara salah percaya bahwa perangkat lunak Anda bekerja dengan baik. Jadi, bagaimana Anda menyadari masalah seperti pada test suite Anda?

  • Menggunakan alat cakupan kode seperti Cobertura , Anda dapat mendeteksi bahwa kasus uji untuk kelas tertentu, atau metode kompleks, tidak lagi memadai. Anda tidak perlu mencapai cakupan kode 100% di mana-mana dan dalam kebanyakan kasus akan sulit untuk dicapai dan belum tentu berguna; tetapi tes untuk aspek paling kritis dari suatu program harus dipertahankan dengan tujuan setidaknya 80% dari cakupan kode.
  • Menggunakan alat membangun dan integrasi berkelanjutan , seperti Jenkins yang sangat saya sukai, dalam kombinasi dengan plugin Sonar , Anda dapat mengatur pemicu yang mengirim email dan jenis peringatan lainnya kepada orang yang bertanggung jawab atas perubahan terbaru. Berbagai grafik dan statistik (Sonar juga menggunakan Cobertura di antara banyak alat lain) membantu peninjau kode dan pengembang uji kasus untuk fokus pada apa yang penting.

Bagaimana Anda tahu bahwa test suite Anda tidak lagi memadai dan bahwa test case baru harus ditambahkan? Saya kira ini ada hubungannya dengan perubahan persyaratan, tetapi apakah ada pendekatan sistematis untuk memeriksa kecukupan test suite?

Apa yang saya tulis untuk pertanyaan pertama adalah bagian dari jawaban untuk pertanyaan kedua Anda. Saya juga akan menambahkan poin-poin berikut di sini:

  • Tulis kasus uji integrasi (atau kasus "bisnis" jika Anda mau) sebagai tambahan dari kasus uji. Ini kemungkinan besar akan berubah / rusak terlebih dahulu karena mereka sering bergantung pada beberapa kelas / metode. Dan karena mereka sering pecah, kecil kemungkinannya akan dilupakan. Satu-satunya pendekatan / metodologi yang, dari pengalaman pribadi saya, membantu menulis tes yang baik adalah Test-Driven Development . Terutama jika orang yang menulis test case BUKAN orang yang sama menulis kode untuk itu. Menulis kasus uji yang baik menggunakan TDD juga membutuhkan waktu, tetapi hasilnya, setidaknya bagi saya, sangat memuaskan.
  • Setiap kali bug keluar, tulis perbaikannya dan test case yang menyertainya. Kasing uji hanya akan mencakup bug khusus ini. Karena Anda telah sepenuhnya menutupi kode yang bertanggung jawab atas bug, itu tidak akan keluar lagi.

Saya setuju dengan itu semua kecuali untuk orang yang menulis tes tidak sama dengan orang yang menulis kode. Ini kedengarannya bagus secara teori, dan akan bagus jika tidak begitu tidak efisien. Tidak peduli seberapa hebat basis kode Anda, jika ukurannya berapa pun, butuh beberapa jam hanya untuk membiasakan diri dengan bagaimana sebagian dari kerjanya. Jadi, alih-alih, penulis tes sudah terbiasa dengan cdoe dan bagaimana berfungsi, orang lain harus masuk dan belajar sedikit dan keluar, dan kemudian menulis tes. Jika kualitas kode bukan yang terbaik, mungkin perlu berhari-hari untuk menulis tes komprehensif
Earlz

@ Earlz Saya setuju dengan Anda jika kedua orang tersebut tidak mengerjakan proyek yang sama. Jika kedua pengembang bekerja pada proyek yang sama, yang dapat digunakan secara konsisten dengan kerangka kerja yang sama, perpustakaan dan metodologi pengembangan, ia seharusnya tidak memiliki masalah, KECUALI jika itu merupakan persyaratan bisnis yang kompleks.
Jalayn

@ Jalayn untuk kasus saya, produknya sangat kompleks. Kualitas kode bukan yang terbaik, tapi jelas bukan yang terburuk (kami melakukan refactoring secara teratur). Kami menegakkan memiliki tester terpisah, tetapi untuk unit test orang yang menyelesaikan pekerjaan melakukannya. Produk kami terdiri dari ratusan (mungkin ribuan?) Kelas yang berurusan dengan subjek yang kompleks, kebingungan.
Earlz

@Jalayn Terima kasih telah menyebutkan alat-alat itu. Tetapi seperti untuk alat cakupan, Anda tidak dapat menjalankannya sepanjang waktu, bukan? Jadi pada titik mana perlu menjalankan alat tersebut? Setelah beberapa perubahan pada kode sumber? Atau setelah beberapa pembaruan pengujian? Apakah ada pedoman umum untuk ini?
Ida

1
Nah, jika Anda memiliki server build kontinu, aplikasi Anda dapat dibangun dan diuji setiap kali ada sesuatu yang dilakukan pada repositori (kami melakukannya di tempat kerja). Dapat dikonfigurasi, misalnya Anda dapat membangun setiap 15 menit. Adapun cakupan kode, ini diaktifkan selama kasus uji dan tidak menambahkan banyak overhead. Namun, build dengan pemeriksaan kualitas kode lengkap diaktifkan, seperti Sonar, biasanya memakan waktu sangat lama, ini dijalankan setiap malam misalnya. Idealnya, Anda tidak harus menjalankan alat ini secara manual.
Jalayn

9

Sebenarnya tidak ada cara untuk memastikan kasus pengujian Anda benar, kecuali dengan berkonsentrasi dengan sangat baik saat membuatnya - memahami persyaratan, memahami kode, dan memastikan bahwa mereka setuju. Intinya memiliki test suite adalah Anda hanya perlu melakukan ini sekali saja, dan sejak saat itu Anda dapat menjalankan kembali tes dan memastikan bahwa tes tersebut lulus, sedangkan tanpa test suite Anda harus berkonsentrasi sangat keras setiap saat. , yaitu setiap kali Anda melakukan sesuatu pada basis kode Anda. Tetapi masalah mendasar karena harus memastikan bahwa Anda melakukan hal yang benar tetap ada - komputer memang tidak cukup cerdas untuk membebaskan kita dari tugas itu.

Karena itu, (1) jika ruang tes Anda tidak lengkap, tidak ada cara sederhana untuk melihatnya. Analisis cakupan kode dapat membuktikan bahwa beberapa baris kode tidak pernah dieksekusi, yaitu bahwa suite kekurangan dalam beberapa hal, tetapi tidak seberapa parah kekurangan itu, dan tidak pernah dapat membuktikan bahwa itu cukup. Bahkan dengan cakupan kode 100% Anda tidak memiliki jaminan bahwa semua negara yang relevandari sistem dilaksanakan, dan cakupan negara lengkap tidak dapat dicapai untuk sistem realistis karena jumlah kombinasi dari negara yang bisa ada. Salah satu teknik yang baik untuk memastikan bahwa Anda menguji kasus setidaknya benar untuk memeriksa hal yang ingin Anda periksa adalah menulis tes, memverifikasi bahwa itu memang gagal, menulis / mengubah kode, dan kemudian memverifikasi bahwa itu sudah lewat. Karena itu, antusiasme untuk pengembangan yang digerakkan oleh tes: tes ini memungkinkan Anda untuk cukup yakin bahwa tes individu melakukan hal yang benar, dan jika Anda membuat seluruh basis kode Anda dengan cara itu, Anda bisa mendapatkan tingkat kepercayaan yang serupa bahkan dalam sistem yang besar.

(2) Paket uji biasanya menjadi tidak memadai setiap kali persyaratan berubah - Anda tidak perlu menebak. Jika pelanggan menginginkan beberapa perilaku tertentu diubah, dan pengujian Anda akan berhasil sebelum dan sesudah perubahan, maka jelas mereka tidak menggunakan hubungan input / output tertentu.

Mengenai sistem warisan yang tidak memiliki cakupan tes, atau di mana Anda tidak tahu apa cakupannya, tidak ada bukti formal, tetapi (penasehat orang tua: pendapat pribadi mengikuti!) Berbicara dari pengalaman, sangat mungkin bahwa tes yang tidak memadai. Ketika pengujian dipandang sebagai aktivitas setelah-fakta-opsional, opsional, peningkatan kualitas-tetapi-tidak-benar-benar-diperlukan, itu cenderung tidak lengkap dan tidak sistematis karena insentif untuk memastikan tes mengikuti kode dasar hanya tidak di sana.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.