Pengantar Pengujian Perangkat Lunak (Ammann & Offutt) menyebutkan pada hal. 32 model kematangan pengujian 5 tingkat:

Level 0 Tidak ada perbedaan antara pengujian dan debugging.

Level 1 Tujuan pengujian adalah untuk menunjukkan bahwa perangkat lunak berfungsi.

Level 2 Tujuan pengujian adalah untuk menunjukkan bahwa perangkat lunak tidak berfungsi.

Level 3 Tujuan pengujian bukan untuk membuktikan sesuatu yang spesifik, tetapi untuk mengurangi risiko menggunakan perangkat lunak.

Pengujian Level 4 adalah disiplin mental yang membantu semua profesional TI mengembangkan perangkat lunak berkualitas tinggi.

Meskipun mereka tidak menjelaskan lebih jauh. Apa perbedaan antara debugging dan pengujian?

Pengujian dimaksudkan untuk menemukan cacat dalam kode, atau dari sudut yang berbeda, untuk membuktikan ke tingkat yang sesuai (tidak pernah bisa 100%) bahwa program melakukan apa yang seharusnya dilakukan. Itu bisa manual atau otomatis, dan memiliki banyak jenis yang berbeda, seperti unit, integrasi, sistem / penerimaan, tekanan, beban, rendam dll pengujian.

Debugging adalah proses menemukan dan menghapus bug tertentu dari program. Itu selalu merupakan proses manual, sekali saja, karena semua bug berbeda.

Dugaan saya adalah bahwa penulis berarti, bahwa pada Level 0, hanya tes manual yang dilakukan, secara ad hoc, tanpa rencana pengujian atau apa pun untuk memastikan bahwa tester benar-benar menguji fitur yang sedang diuji, dan bahwa tes dapat dilakukan. diulangi dengan andal.

Debugging adalah proses langkah demi langkah manual yang terlibat, tidak terstruktur dan tidak dapat diandalkan. Dengan menguji melalui debugging Anda membuat skenario yang tidak dapat diulang karena itu tidak berguna untuk pengujian regresi. Semua level selain 0 (dalam contoh Anda) mengecualikan debugging dalam pandangan saya untuk alasan yang tepat ini.

Debugging adalah upaya untuk memperbaiki masalah yang diketahui dan tidak diketahui dengan secara sistematis memeriksa kode. Saat Anda debug, Anda biasanya tidak fokus pada kode secara keseluruhan, dan Anda hampir selalu bekerja di backend, dalam kode aktual.

Pengujian adalah upaya untuk membuat masalah melalui berbagai cara menggunakan kode yang kemudian dapat di-debug. Ini hampir selalu dilakukan di userspace, di mana Anda menjalankan kode sebagai pengguna akhir akan menjalankannya, dan mencoba membuatnya rusak.

Secara sederhana, "bug" dikatakan telah terjadi ketika program Anda, saat dieksekusi, tidak berperilaku seperti seharusnya. Itu tidak menghasilkan output atau hasil yang diharapkan. Setiap upaya untuk menemukan sumber bug ini, menemukan cara untuk memperbaiki perilaku dan membuat perubahan pada kode atau konfigurasi untuk memperbaiki masalah dapat disebut debugging.

Pengujian adalah di mana Anda memastikan program atau kode bekerja dengan benar dan dengan cara yang kuat di bawah kondisi yang berbeda: Anda "menguji" kode Anda dengan memberikan input, input yang benar standar, input yang sengaja salah, nilai batas, lingkungan yang berubah (OS, file konfigurasi) . Pada dasarnya, kami dapat mengatakan bahwa Anda mencoba menemukan bug dan akhirnya "men-debug" mereka dalam proses pengujian. Semoga itu bisa membantu.

Tidak ada. Jika Anda melakukannya dengan benar:

Hit 'em High, Hit' em Low :

Pengujian Regresi dan Squeeze Saff

Kent Beck, Institut Three Rivers

Abstrak: Untuk mengisolasi cacat secara efektif, mulailah dengan tes tingkat sistem dan secara bertahap sebaris dan pangkas sampai Anda memiliki tes sekecil mungkin yang menunjukkan cacat.

Pengujian adalah hak istimewa yang Anda nikmati sebelum merilis ke klien.

Bug adalah mimpi buruk yang Anda alami setelah melepaskannya ke klien.

Yang lain telah menyebutkan apa perbedaan antara pengujian dan debugging.

Saya ingin menekankan bagian yang umum . Ketika seorang penguji menemukan cacat, itu harus diisolasi. Debugging adalah salah satu teknik untuk mengisolasi masalah dan menemukan akar penyebab dengan menganalisis status aplikasi dan kode saat runtime. Bahkan, debugging didefinisikan oleh Oxford Dictionaries sebagai "proses mengidentifikasi dan menghapus kesalahan dari perangkat keras atau perangkat lunak komputer."

Siapa yang akan mengisolasi (atau men-debug khususnya) cacat, apakah itu akan menjadi tester atau pengembang, adalah pertanyaan sekunder.

Model kematangan pengujian yang telah Anda daftarkan adalah deskripsi mentalitas tim pengembangan.

Apa yang tersirat dalam daftar, tanpa mengatakan secara eksplisit, adalah bagaimana perubahan mentalitas mempengaruhi cara pengujian dilakukan.

Saat tim pengembangan maju ke tingkat berikutnya, cakupan pengujian diperluas.

Pada Level 0, tidak ada pengujian yang dilakukan, karena tim berpikir itu tidak perlu.

Pada Level 1, pengujian dilakukan untuk memberikan cakupan nominal fungsi dasar.

Di Level 2, pengujian diperluas untuk mencakup semua yang ada di Level 1, dan menambahkan pengujian destruktif (tim uji khusus yang memiliki akses ke semua informasi yang memiliki akses pengembang, termasuk kode sumber dan binari, dan mencoba untuk menemukan bug yang dapat dipicu dari peran pengguna)

Di Level 3, selain semua yang ada di Level 1-2, pengujian berbasis non-fungsional / pengujian berbasis non-kebenaran (seperti karakteristik kinerja) ditambahkan.

Pada Level 4, tujuan pengujian perangkat lunak dipahami dengan baik oleh setiap orang, termasuk staf TI yang menghadapi pelanggan. Dengan demikian, staf TI akan dapat memberikan umpan balik tentang skenario apa yang akan diuji, meningkatkan cakupan risiko Level 4.

(Penafian: Saya tidak memiliki akses ke buku teks, oleh karena itu istilah saya mungkin salah.)

Bug adalah kesalahan yang terlihat. Debugging adalah proses yang dimulai setelah desain kasus uji. Ini adalah tugas yang lebih sulit daripada pengujian, karena dalam proses debugging kita perlu mencari tahu sumber kesalahan dan menghapusnya, jadi terkadang debugging membuat frustasi pengguna.

Berbicara dalam istilah sehari-hari, praktis, saya pikir itu sepenuhnya tergantung pada konteksnya .

Dalam tim med-besar, bekerja dengan standar tinggi / sangat tinggi (berpikir perbankan, militer, skala besar, anggaran tinggi atau sistem bisnis kritis) maka saya pikir dengan jelas "debugging" harus "hasil pengujian" , dan mereka jelas hal yang sangat berbeda . Idealnya pengujian mengarah ke debugging (dalam lingkungan pementasan) dan dalam produksi kita perlu mendekati nol dari keduanya.

Pengujian dalam cakupan luas, teratur dan sangat formal - sementara debugging adalah proses tertentu yang terjadi sesekali ketika ada kebutuhan untuk memperbaiki kegagalan tertentu - yang tidak jelas dan membutuhkan penyelidikan yang lebih dalam dari fungsi sistem dan hasil keluaran.

Di sini, dalam pengujian pikiran saya adalah sesuatu yang penting, sedangkan debugging adalah alat khusus yang diperlukan hanya ketika resolusi kegagalan adalah buram.

Saya benar-benar memahami utilitas yang jelas dalam TDD untuk tim dan atau sistem besar daripada tidak mampu menjadi "kereta". Ini juga jelas masuk akal untuk sistem yang kompleks (sering kali "back-end") atau jika ada proporsi kompleksitas yang tinggi dalam kode dibandingkan dengan output. Kemudian "pengujian" memiliki peluang yang realistis untuk menginformasikan kapan dan mengapa kegagalan terjadi. Sistem yang melakukan banyak pekerjaan kompleks dan atau menghasilkan output yang terukur jelas umumnya mudah diuji, dan pengujian berbeda dari debugging. Dalam kasus-kasus ini pengujian sangat menyiratkan metode yang berdasarkan prosedur, metode formal untuk mengkonfirmasi atau mengacaukan kesesuaian antara harapan dan hasil aktual. Pengujian terjadi setiap saat, dan kadang-kadang memberi tahu kami tentang kebutuhan untuk debugging.

Akan menyenangkan jika ini adalah kebenaran di mana-mana, saya akan senang jika siklus dev saya dibatasi oleh keluaran biner yang jelas (merah, hijau) tetapi ...

Dalam kasus saya (yang secara khusus diakui - bekerja 98% solo pada sistem web perusahaan yang berukuran kecil, kurang dana, dan fokus pada data admin) Saya benar-benar tidak dapat melihat bagaimana TDD dapat membantu saya. Atau lebih tepatnya "debugging" dan "testing" secara virtual sama.

Terutama meskipun penggunaan istilah "pengujian" menyiratkan / erat terkait dengan metodologi TDD.

Saya tahu ini benar - benar, sama sekali tidak Zeitgeist "hindari orang yang tidak percaya, hindari, hindari", hal yang sangat tidak keren untuk dikatakan. Tetapi memikirkan konteks saya, dengan topi praktis yang tidak saya singgung, dalam imajinasi terliar saya melihat bagaimana TDD dapat membantu saya memberikan nilai lebih untuk uang kepada klien saya.

Atau lebih tepatnya, saya sangat tidak setuju dengan asumsi umum bahwa "pengujian" adalah proses berbasis kode formal.

Keberatan dasar saya (berlaku dalam konteks * * khusus saya ) adalah ...

Jika saya tidak bisa menulis kode yang bekerja andal - maka bagaimana sih aku bisa menulis kode yang bekerja andal untuk tes kata mungkin sub standar kode.

Bagi saya, saya belum pernah melihat contoh atau argumen yang (dalam konteks khusus saya) cukup menggembirakan saya bahkan untuk berpikir tentang menulis satu tes , saya mungkin sedang menulis beberapa kode pengujian yang benar-benar menggelikan saat ini, mungkin "apakah repositori saya mengembalikan seorang Pengguna entitas dengan Nama == X, ketika saya menanyakannya dengan tepat - dan hanya - itu? ", tetapi mungkin ada lebih banyak utilitas dalam diri saya menulis streaming ini, mungkin-internet-benar-benar-benar-benar-benar-benar-murni-bodoh-semburan- sampah yang memuaskan diri sendiri, sangat kurang informasi, darah mendidih, berlebih-lebih-sia-sia-sia-sia, tapi aku hanya merasa perlu berperan sebagai penasihat iblis di sini. (Agak berharap seseorang akan menunjukkan kepada saya cahaya dan mempertobatkan saya, mungkin ini akan memberi klien saya nilai uang yang lebih baik?).

Bisa dibilang "debugging" terkadang sama dengan "pengujian". Maksud saya ini adalah bahwa dalam kehidupan kerja sehari-hari saya, saya menghabiskan setidaknya sepertiga dari waktu saya bermain-main dengan versi lokal dari sistem saya di browser yang berbeda, mati-matian mencoba berbagai hal aneh dalam upaya untuk menghancurkan pekerjaan saya dan kemudian menyelidiki alasan mengapa itu gagal dan mengoreksi mereka.

Saya 100% setuju dengan utilitas yang jelas dalam mantra TDD "merah / hijau / refactor", tetapi bagi saya (bekerja dengan anggaran rendah, solo dev RIA land) saya benar-benar akan sangat menyukai seseorang untuk tolong tunjukkan saya bagaimana saya bisa mungkin , secara logis dan sangat realistis mendapatkan nilai tambahan dari menulis lebih banyak ( sama seperti kode pengujian yang berpotensi cacat ) daripada yang saya lakukan dari benar-benar berinteraksi dengan output penuh (dan pada dasarnya hanya) dari upaya saya yang pada dasarnya terikat pada interaksi manusia nyata.

Bagi saya ketika pengembang berbicara tentang "pengujian" itu biasanya menyiratkan TDD.

Saya mencoba kode seolah-olah ada tes, saya pikir semua pola / praktik dan tren yang didorong oleh semua pengembangan pengujian ini fantastis dan indah, tetapi bagi saya di dunia kecil saya "pengujian" tidak menulis lebih banyak kode, sebenarnya menguji keluaran dunia nyata dengan pendekatan realistis, dan itu hampir sama dengan debugging, atau lebih tepatnya perubahan aktif di sini adalah "debugging" yang merupakan akibat langsung dari manusia, "pengujian" output centric non otomatis. Ini berbeda dengan pandangan yang diterima secara umum tentang "pengujian" sebagai sesuatu yang otomatis dan formal, dan "debugging" sebagai sesuatu yang manusiawi dan ad-hoc atau tidak terstruktur.

Jika tujuannya benar-benar bernilai untuk uang / usaha, dan Anda membuat aplikasi interaktif berbasis web, maka output dari upaya adalah halaman web dan pada dasarnya bagaimana mereka bereaksi terhadap input manusia - jadi "pengujian" terbaik dicapai dengan menguji halaman-halaman web, melalui interaksi manusia nyata. Ketika interaksi ini mengarah ke hasil yang tidak diharapkan atau tidak diinginkan, maka "debugging" terjadi. Debugging juga terkait erat dengan ide inspeksi waktu nyata dari keadaan program. Pengujian umumnya terkait dengan otomatisasi yang menurut saya sering merupakan hubungan yang tidak menguntungkan.

Jika tujuannya benar-benar bernilai untuk usaha, dan pengujian otomatis efisien dan sangat bermanfaat, sementara debugging hanyalah output dari pengujian itu, atau pengganti yang buruk untuk pengujian otomatis, lalu mengapa situs web yang paling banyak dikunjungi kedua di dunia (Facebook ) begitu sering penuh dengan bug yang jelas menyilaukan (untuk pengguna, tetapi jelas bukan tim pengujian dan kode pengujian)?

Mungkin karena mereka berkonsentrasi pada lampu hijau yang meyakinkan dan lupa untuk benar-benar menggunakan hasil karya mereka?

Apakah terlalu banyak pengembang berpikir pengujian adalah sesuatu yang Anda lakukan dengan kode, dan debugging adalah sesuatu yang sesekali Anda lakukan dengan IDE karena ikon berubah menjadi merah dan Anda tidak dapat mengetahui alasannya? Saya pikir kata-kata ini memiliki penilaian nilai malang terkait dengan mereka, yang umumnya mengaburkan realitas praktis dari apa yang harus kita fokuskan untuk menutup kesenjangan antara harapan dan hasil.

Secara sederhana,

Pengujian berarti, menemukan input yang menyebabkan Perangkat Lunak gagal saat debugging adalah proses menemukan kesalahan dari kegagalan yang diberikan.