Apa kerugian dari pengujian otomatis?


49

Ada sejumlah pertanyaan di situs ini yang memberikan banyak informasi tentang manfaat yang dapat diperoleh dari pengujian otomatis. Tetapi saya tidak melihat apa pun yang mewakili sisi lain dari koin: apa kerugiannya? Segala sesuatu dalam hidup adalah pengorbanan dan tidak ada peluru perak, jadi pasti harus ada beberapa alasan yang sah untuk tidak melakukan pengujian otomatis. Apakah mereka?

Inilah beberapa yang saya buat:

  • Membutuhkan lebih banyak waktu pengembang awal untuk fitur yang diberikan
  • Membutuhkan tingkat keterampilan yang lebih tinggi dari anggota tim
  • Tingkatkan kebutuhan alat (uji pelari, kerangka kerja, dll.)
  • Analisis kompleks diperlukan ketika tes gagal ditemukan - apakah tes ini usang karena perubahan saya atau apakah itu memberitahu saya bahwa saya membuat kesalahan?

Sunting
Saya harus mengatakan bahwa saya adalah pendukung besar pengujian otomatis, dan saya tidak ingin diyakinkan untuk melakukannya. Saya mencari untuk memahami apa kerugiannya sehingga ketika saya pergi ke perusahaan saya untuk membuat kasus untuk itu saya tidak terlihat seperti sedang melempar peluru perak imajiner berikutnya.

Juga, saya jelas tidak mencari seseorang untuk membantah contoh saya di atas. Saya menganggap benar bahwa pasti ada beberapa kerugian (semuanya memiliki trade-off) dan saya ingin memahami apa itu.


18
"Analisis kompleks diperlukan ..." tes bukanlah penyebab kegagalan, ini adalah indikator. Mengatakan tidak memiliki tes berarti tidak diperlukan analisis kegagalan yang rumit tidak lebih baik daripada menjulurkan kepala ke lumpur.
P.Brian.Mackey

1
* waktu pengembangan lebih lama saat pengujian dijalankan setiap pembangunan, dan kode berulang saat pengujian berada pada level yang sangat rendah (pengujian getter dan setter)
ratchet freak

2
1. jika pengembang menggunakan waktu untuk menguji fitur baru, risiko kegagalan mereka menurun berarti produk Anda lebih stabil. 2. Mendidik anggota tim Anda untuk pendekatan fokus-tes adalah hal yang baik, mereka dapat menggunakan pengetahuan ini untuk hal-hal lain dalam pekerjaan (dan kehidupan). 3. Buat instalasi otomatis untuk lingkungan pengujian 4. Ini memberi tahu saya bahwa 1 tes terlalu banyak.
CS01

1
Jika pengembang yang sama mengkode tes seperti halnya mengkode kode yang sebenarnya, maka mereka hanya akan memikirkan kasus pengujian yang sama untuk menulis tes sebagai yang mereka pikirkan ketika mereka coding.
Paul Tomblin

Saya baru saja mengirim jawaban untuk pertanyaan terkait dan merasa seperti saya setidaknya harus mengomentari yang satu ini. IMO, hampir semua kerugian yang disebutkan di sini (dan dalam balasan) terlihat salah dan menyesatkan jika kita berbicara tentang proyek langsung yang sebenarnya dan bukan tentang sesuatu yang Anda kode dengan cepat dan lupa. Saya khawatir pertanyaan seperti ini dapat digunakan sebagai alasan untuk berkembang tanpa tes otomatis dan dalam banyak kasus ini akan menyebabkan kematian proyek atau pengerjaan ulang total.
Boris Serebrov

Jawaban:


26

Anda cukup banyak memaku yang paling penting. Saya memiliki beberapa tambahan kecil, ditambah kelemahan dari tes yang sebenarnya berhasil - ketika Anda tidak benar-benar menginginkannya (lihat di bawah).

  • Waktu pengembangan: Dengan pengembangan yang digerakkan oleh tes, ini sudah diperhitungkan untuk pengujian unit, tetapi Anda masih memerlukan pengujian integrasi dan sistem, yang mungkin memerlukan kode otomatisasi juga. Kode yang ditulis satu kali biasanya diuji pada beberapa tahap selanjutnya.

  • Level keterampilan: tentu saja, alat harus didukung. Tapi itu bukan hanya tim Anda sendiri. Dalam proyek yang lebih besar, Anda mungkin memiliki tim pengujian terpisah yang menulis tes untuk memeriksa antarmuka antara produk tim Anda dan yang lain. Begitu banyak orang harus memiliki lebih banyak pengetahuan.

  • Kebutuhan alat: Anda tepat di sana. Tidak banyak yang ditambahkan ke ini.

  • Tes gagal: Ini adalah bugger nyata (bagi saya bagaimanapun). Ada banyak alasan berbeda, masing-masing dapat dianggap sebagai kerugian. Dan kerugian terbesarnya adalah waktu yang diperlukan untuk memutuskan mana dari alasan-alasan ini yang benar-benar berlaku untuk tes gagal Anda.

    • gagal, karena bug yang sebenarnya. (hanya untuk kelengkapan, karena ini tentu saja menguntungkan)
    • gagal, karena kode pengujian Anda telah ditulis dengan bug tradisional.
    • gagal, karena kode pengujian Anda telah ditulis untuk versi produk Anda yang lebih lama dan tidak lagi kompatibel
    • gagal, karena persyaratan telah berubah dan perilaku yang diuji sekarang dianggap 'benar'
  • Tes yang tidak gagal: Ini juga merupakan kerugian dan bisa sangat buruk. Itu kebanyakan terjadi, ketika Anda mengubah banyak hal dan mendekati apa yang dijawab Adam. Jika Anda mengubah sesuatu dalam kode produk Anda, tetapi tes tidak menjelaskannya sama sekali, maka itu memberi Anda "rasa aman yang salah".

    Aspek penting dari tes yang tidak gagal adalah bahwa perubahan persyaratan dapat menyebabkan perilaku sebelumnya menjadi tidak valid. Jika Anda memiliki keterlacakan yang layak, perubahan persyaratan harus dapat dicocokkan dengan kode pengujian Anda dan Anda tahu Anda tidak lagi bisa mempercayai pengujian itu. Tentu saja, mempertahankan keterlacakan ini adalah satu lagi kelemahan. Dan jika tidak, Anda berakhir dengan tes yang tidak gagal, tetapi sebenarnya memverifikasi bahwa produk Anda berfungsi dengan salah . Di suatu tempat di jalan ini akan memukul Anda .. biasanya kapan / di mana Anda tidak mengharapkannya.

  • Biaya penempatan tambahan: Anda tidak hanya menjalankan tes unit sebagai pengembang di komputer Anda sendiri. Dengan tes otomatis, Anda ingin menjalankannya berdasarkan komit dari orang lain di suatu tempat pusat untuk mencari tahu ketika seseorang merusak pekerjaan Anda. Ini bagus, tetapi juga perlu diatur dan dipelihara.


1
Pada tes yang gagal, jika persyaratan berubah yang menyebabkan tes saat ini gagal, tes lulus karena implementasi sebelumnya tidak lagi valid, jika tidak gagal itu berarti implementasi tidak sesuai dengan persyaratan ...
CS01

Kasus 4 (b) adalah soal pengembangan yang didorong oleh tes: Anda menulis tes yang gagal, kemudian Anda memperluas produk, kemudian Anda memverifikasi bahwa perubahan ini membuat tes berhasil. Ini melindungi Anda terhadap ujian tertulis yang salah yang selalu berhasil, atau selalu gagal.
Kilian Foth

@ Jujur terima kasih atas jawabannya. Ada banyak wawasan di sana. Saya terutama menghargai perbedaan dari berbagai penyebab tes gagal. Biaya penyebaran tambahan adalah poin bagus lainnya.
RationalGeek

Hal yang lucu yang saya temukan adalah bahwa bug saya per rasio LOC jauh lebih buruk untuk tes daripada kode nyata. Saya menghabiskan lebih banyak waktu untuk menemukan dan memperbaiki bug pengujian daripada yang asli. :-)
Brian Knoblauch

gagal, karena kode pengujian Anda telah ditulis untuk versi produk Anda yang lebih lama dan tidak lagi kompatibel - jika pengujian Anda gagal karena ini, maka kemungkinan pengujian Anda menguji rincian implantasi daripada perilaku. CalculateHighestNumber v1 masih harus mengembalikan hasil yang sama seperti CalculateHighestNumber v2
Tom Squires

29

Baru saja mulai mencoba tes otomatis di tim kami, kerugian terbesar yang saya lihat adalah sangat sulit untuk menerapkan kode legacy yang tidak dirancang dengan pengujian otomatis. Tidak diragukan lagi akan meningkatkan kode kita dalam jangka panjang, tetapi tingkat refactoring yang diperlukan untuk pengujian otomatis sambil mempertahankan kewarasan kita adalah penghalang yang sangat tinggi untuk masuk dalam jangka pendek, artinya kita harus sangat selektif dalam memperkenalkan otomatis unit testing untuk memenuhi komitmen jangka pendek kami. Dengan kata lain, jauh lebih sulit untuk melunasi kartu kredit ketika Anda sudah tenggelam dalam utang teknis.


2
Sebagai seseorang yang bekerja 80% dari basis kode warisan yang sangat besar, saya sangat setuju. Namun, untuk mengurangi ini, saya telah menggunakan ini di [link] amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/… layak untuk dilihat.
DevSolo

1
Itu buku yang sangat bagus, saya dapat banyak hal. Tiga poin utama, ayo, sedikit demi sedikit. Beberapa tes yang baik lebih baik daripada tidak ada tes. Tetap dalam ruang lingkup, jangan refactor semua yang perlu refactoring sekaligus. Sangat jelas di mana batas antara kode yang dapat diuji dan yang tidak dapat diuji. Pastikan semua orang tahu juga.
Tony Hopkinson

21

Mungkin kelemahan paling penting adalah ... tes adalah kode produksi . Setiap tes yang Anda tulis menambahkan kode ke basis kode Anda yang perlu dipertahankan dan didukung. Gagal melakukannya menyebabkan Anda tidak percaya akan hasil tes, jadi Anda tidak punya pilihan lain. Jangan salah paham - Saya pendukung besar pengujian otomatis. Tapi semuanya memiliki biaya, dan ini yang besar.


Poin bagusnya Ross itu adalah cara yang menarik untuk menggambarkannya.
RationalGeek

Setuju, meskipun menurut pengalaman saya, waktu yang dihemat karena unit test langsung menemukan bug potensial dalam kode yang baru ditulis (yaitu tes regresi) telah melebihi waktu perawatan tambahan ini.
dodgy_coder

15

Saya tidak akan mengatakan ini sepenuhnya kerugian yang berlaku, tetapi beberapa yang paling saya hit adalah:

  • Waktu yang diperlukan untuk mengatur pengujian dalam aplikasi perusahaan yang kompleks.
  • Menangani tes lama yang gagal secara salah, dengan kata lain, sistem telah berevolusi dan sekarang tes salah.
  • Keyakinan salah dari cakupan pengujian yang tidak jelas atau tidak diketahui.

Cakupan uji yang tidak merata dapat menyebabkan rasa aman yang salah. Jika Anda melakukan refactor dan menggunakan tes untuk membuktikan validitasnya, apa yang telah membuktikan tes Anda dapat membuktikan ini?

Waktu yang diperlukan untuk membuat tes terkadang menjadi masalah bagi kami. Pengujian otomatis kami tidak hanya mencakup uji unit, tetapi juga menggunakan uji kasus. Ini cenderung lebih luas dan membutuhkan konteks.

Tentu saja, perspektif saya berasal dari aplikasi yang lebih tua dari tes unitnya.


OP sudah membahas waktu dan kode usang dalam pertanyaan.
P.Brian.Mackey

@ P.Brian.Mackey sebenarnya elemen waktu itu subyektif. Waktu yang diperlukan untuk mengkodekan tes berbeda dari waktu yang diperlukan untuk memahami apa yang diperlukan tes dan mengkode tes dengan benar.
Adam Houldsworth

@AdamHouldsworth Terima kasih itu adalah beberapa contoh kerugian yang baik. Saya belum benar-benar mempertimbangkan sudut kepercayaan salah.
RationalGeek

9

Saya akan mengatakan masalah utama dengan mereka adalah mereka dapat memberikan rasa aman yang salah . Hanya karena Anda memiliki unit test, itu tidak berarti mereka benar-benar melakukan sesuatu dan itu termasuk menguji persyaratan dengan benar.

Selain itu tes otomatis juga dapat mencakup bug sendiri , sehingga menimbulkan pertanyaan apakah unit test perlu menguji diri mereka sendiri sehingga tidak perlu mencapai apa pun.


Pengembangan Test Driven membantu yang pertama dengan meminta tes yang gagal sebelum menulis kode fitur. Sekarang Anda tahu bahwa jika fitur rusak, tes akan rusak. Untuk yang kedua, kode uji yang rumit adalah bau kode. Sekali lagi, dengan menulis tes terlebih dahulu Anda dapat berusaha membuatnya sederhana dan memasukkan pekerjaan yang sulit ke dalam kode fitur yang memperbaiki tes.
David Harkness

Kode yang sulit diuji bukan bau kode. Kode termudah untuk diuji adalah rantai fungsi raksasa yang memanggil kelas.
Erik Reppen

4

Meskipun pengujian otomatisasi memiliki banyak keuntungan, ia memiliki kelemahannya sendiri juga. Beberapa kelemahannya adalah:

  • Kemahiran diperlukan untuk menulis skrip tes otomatisasi.
  • Men-debug skrip pengujian adalah masalah utama. Jika ada kesalahan dalam skrip uji, kadang-kadang dapat menyebabkan konsekuensi yang mematikan.
  • Pemeliharaan pengujian mahal jika menggunakan metode pemutaran. Meskipun perubahan kecil terjadi pada GUI, skrip uji harus direkam ulang atau diganti dengan skrip pengujian baru.
  • Pemeliharaan file data uji sulit, jika skrip uji menguji lebih banyak layar.

Beberapa kelemahan di atas sering mengurangi manfaat yang diperoleh dari skrip otomatis. Meskipun pengujian otomatisasi memiliki kelebihan dan kekurangan, pengujian ini diadaptasi secara luas di seluruh dunia.


Terima kasih. Poin bagus. Saya mengedit posting Anda untuk tata bahasa dan pemformatan. Semoga kamu tidak keberatan.
RationalGeek

3

Saya baru-baru ini mengajukan pertanyaan tentang tes dalam pengembangan game - ini BTW bagaimana saya tahu tentang ini. Jawaban di sana menunjukkan beberapa kelemahan spesifik yang aneh:

  1. Itu mahal untuk dilakukan ketika kode Anda harus sangat digabungkan .
  2. Sulit untuk dilakukan ketika Anda harus menyadari berbagai platform perangkat keras, ketika Anda harus menganalisis output kepada pengguna dan hasil kode hanya masuk akal dalam konteks yang lebih luas .
  3. Pengujian UI dan UX sangat sulit .
  4. Dan terutama, tes otomatis bisa lebih mahal dan kurang efektif daripada sekelompok penguji beta yang sangat murah (atau gratis) .

Poin ke-4 membuat saya ingat beberapa pengalaman saya. Saya bekerja pada perusahaan Scrum yang dikelola sangat ramping, berorientasi XP, di mana unit test sangat dianjurkan. Namun, dalam perjalanannya ke gaya yang lebih ramping, kurang birokratis, perusahaan hanya mengabaikan pembangunan tim QA - kami tidak memiliki penguji. Seringkali pelanggan menemukan bug sepele menggunakan beberapa sistem, bahkan dengan cakupan uji> 95%. Jadi saya akan menambahkan poin lain:

  • Tes otomatis dapat membuat Anda merasa bahwa QA dan pengujian tidak penting.

Juga, saya memikirkan hari-hari itu tentang dokumentasi dan merenungkan sebuah hipotesis yang mungkin valid (sampai batas yang lebih rendah) untuk menguji dua. Saya hanya merasa bahwa kode berkembang sangat cepat sehingga cukup sulit untuk membuat dokumentasi yang mengikuti kecepatan seperti itu, jadi lebih berharga menghabiskan waktu membuat kode dapat dibaca daripada menulis dokumentasi yang berat dan mudah usang. (Tentu saja, ini tidak berlaku untuk API, tetapi hanya untuk implementasi internal.) Tes menderita sedikit dari masalah yang sama: mungkin terlalu lambat untuk menulis bila dibandingkan dengan kode yang diuji. OTOH, ini adalah masalah yang lebih kecil karena tes memperingatkan mereka sudah usang, sementara dokumentasi Anda akan tetap diam selama Anda tidak membaca ulang dengan sangat, sangat hati-hati .

Akhirnya, kadang-kadang saya menemukan masalah: pengujian otomatis mungkin bergantung pada alat, dan alat itu mungkin ditulis dengan buruk. Saya memulai sebuah proyek menggunakan XUL beberapa waktu lalu dan, bung, ini menyakitkan untuk menulis unit test untuk platform semacam itu. Saya memulai aplikasi lain menggunakan Objective-C, Cocoa dan Xcode 3 dan model pengujian pada dasarnya adalah sekelompok solusi.

Saya memiliki pengalaman lain tentang kelemahan pengujian otomatis, tetapi kebanyakan dari mereka terdaftar dalam jawaban lain. Meskipun demikian, saya seorang pendukung keras pengujian otomatis. Ini menghemat banyak pekerjaan dan sakit kepala dan saya selalu merekomendasikannya secara default. Saya menilai kerugian tersebut hanyalah detail belaka jika dibandingkan dengan manfaat pengujian otomatis. (Adalah penting untuk selalu menyatakan iman Anda setelah Anda mengomentari ajaran sesat untuk menghindari auto da fé.)


3

Dua yang tidak disebutkan adalah:

  • Durasi waktu yang diperlukan untuk menjalankan test suite yang besar

Saya telah menjadi bagian dari upaya QA otomatis di mana butuh setengah hari untuk menjalankan tes, karena tes lambat. Jika Anda tidak berhati-hati dalam menulis tes, rangkaian tes Anda bisa berubah juga. Ini tidak terdengar seperti masalah besar sampai Anda sekarang mengelola waktu itu, "Oh, saya baru saja melakukan perbaikan, tetapi akan memakan waktu 4 jam untuk membuktikan kebenarannya".

  • Kecurangan beberapa metode penulisan tes

Beberapa metode pengujian (seperti mengotomatiskan UI) tampaknya rusak setiap kali Anda berbalik. Terutama menyakitkan jika skrip Anda, katakanlah, menunda proses pengujian karena menunggu tombol muncul - tetapi tombol telah diganti namanya.

Ini adalah kedua hal yang dapat Anda selesaikan, dengan praktik pengujian yang baik: temukan cara untuk menjaga suite pengujian Anda tetap cepat (bahkan jika Anda harus melakukan trik seperti mendistribusikan pengujian di mesin / CPU). Demikian juga, beberapa kehati-hatian dapat diambil untuk menghindari metode ujian menulis yang lemah.


2

Saya ingin menambahkan satu lagi, rasa aman palsu.

Di luar set masalah yang didefinisikan dengan sangat kecil, tidak mungkin membuat tes komprehensif. Mungkin ada dan seringkali masih ada bug dalam perangkat lunak kami yang tidak diuji secara otomatis oleh pengujian otomatis. Ketika tes otomatis lulus, kita terlalu sering menganggap tidak ada bug dalam kode.


0

Sulit untuk meyakinkan manajemen / kapitalis ventura

  • testautomation meningkatkan biaya dimuka.
  • testautomation meningkatkan waktu ke pasar.
  • manfaat dari testautomation datang di pertengahan dan logterm. persaingan ketat lebih berfokus pada manfaat jangka pendek.

lihat Pengujian Unit Berbasis Pasar untuk detailnya.


-1

Salah satu kelemahan utama dapat diatasi dengan menggunakan tes belajar mandiri. Dalam situasi ini, hasil yang diharapkan semua disimpan sebagai data dan dapat diperbarui dengan ulasan minimal oleh pengguna test suite dalam mode belajar mandiri (tunjukkan perbedaan antara hasil yang diharapkan lama dan hasil aktual yang baru - pembaruan diharapkan jika tekan y). Mode pembelajaran testuite ini perlu digunakan dengan hati-hati sehingga perilaku buggy tidak dipelajari sebagai hal yang dapat diterima.

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.