Bisakah kita berasumsi saat menguji perangkat lunak bahwa pengguna tidak akan melakukan tindakan konyol pada perangkat lunak?


71

Misalnya: Saat melakukan pengujian fungsional formulir dalam aplikasi web, kami akan menguji bidang dengan memasukkan berbagai jenis nilai input acak.

Secara umum, kita sebagai pengguna aplikasi web tidak benar-benar memasukkan nilai acak ke dalam bidang.

Jadi apa gunanya menggabungkan semua testcases yang mungkin / mungkin tidak menyebabkan bug, ketika kemungkinan muncul masalah seperti ini dalam produksi jauh lebih sedikit?

Catatan: Contoh di atas hanya contoh kasus; masalah seperti itu dapat terjadi pada segala jenis fitur / modul.

Saya mengajukan pertanyaan ini hanya untuk mengetahui apakah ada praktik standar yang harus diikuti atau sepenuhnya bergantung pada produk, domain, dan semua faktor lainnya.


4
Mungkin relevan: pengujian monyet , dengan pro dan kontra
Christophe

Jawaban:


190

Anda mungkin tidak memasukkan nilai acak ke bidang aplikasi web, tetapi tentu saja ada orang di luar sana yang melakukan hal itu.

Beberapa orang masuk secara acak tanpa sengaja dan yang lain melakukannya dengan sengaja mencoba untuk merusak aplikasi. Dalam kedua kasus, Anda tidak ingin aplikasi mogok atau menunjukkan perilaku yang tidak diinginkan lainnya.
Untuk tipe pengguna pertama, Anda tidak menginginkannya karena itu memberi mereka pengalaman buruk dan mungkin menolaknya.
Untuk tipe pengguna kedua, mereka biasanya tidak memiliki niat yang terhormat dan Anda tidak ingin membiarkan mereka memiliki akses ke informasi yang seharusnya tidak dapat mereka akses atau memungkinkan mereka untuk menolak akses pengguna asli ke layanan Anda.

Praktik standar untuk pengujian adalah untuk memverifikasi tidak hanya bahwa kasing cuaca bagus bekerja, tetapi juga kasing tepi yang tidak biasa dieksplorasi untuk menemukan potensi masalah dan memiliki keyakinan bahwa penyerang tidak dapat dengan mudah mendapatkan akses ke sistem Anda. Jika aplikasi Anda sudah mogok dengan input acak, Anda tidak ingin tahu apa yang bisa dilakukan penyerang dengan input yang dibuat khusus.


16
Dan kemudian ada hal-hal yang bukan orang yang melakukannya. 👽
kojiro

110
Atau mereka mungkin mencoba memasukkan nama resmi mereka yang sebenarnya, seperti "O'Malley", "姓名" atau "Robert '); DROP TABEL Siswa; - ” .
l0b0

90
Atau mungkin nama perusahaan asli, ; DROP TABEL "PERUSAHAAN"; - LTD .
Ben

25
Saya pikir paragraf terakhir dapat dibuat lebih kuat dengan menekankan bahwa jika sebuah program crash dengan input acak kucing berjalan di keyboard, hampir pasti akan crash (dan lebih buruk) dengan input berbahaya .
phihag

11
Juga, banyak orang memasukkan input acak karena mereka tidak ingin memberikan data nyata (seperti nama, tanggal lahir, dll.). Beberapa orang juga menganggap komputer itu sepintar petugas, dan mungkin mengetik sesuatu seperti "tahun lalu" dan bukan "2016" dan mengharapkan aplikasi Anda untuk menghadapinya, seperti halnya manusia.
Luaan

102

Jangan Menganggap Apa Pun

Anda tidak dapat berasumsi bahwa pengguna mana pun tidak akan melakukan sesuatu "bodoh" dengan perangkat lunak Anda secara tidak sengaja atau sengaja. Pengguna dapat secara tidak sengaja menekan tombol yang salah, kucing dapat berjalan di atas keyboard, sistem dapat mengalami kegagalan fungsi, komputer mereka dapat dibajak oleh perangkat lunak berbahaya, dll.

Lebih jauh, pengguna itu sendiri mungkin jahat, dengan sengaja mencari cara untuk menghancurkan perangkat lunak Anda dengan harapan mereka dapat menemukan cara untuk mengeksploitasinya demi keuntungan mereka. Bahkan jika mereka menemukan bug yang tidak dapat mereka eksploitasi, apa pun yang mereka temukan dapat memacu mereka untuk menyelidiki sistem Anda untuk sesuatu yang dapat mereka serang, mengetahui bahwa prosedur QA Anda kurang.

Sejauh menyangkut pengujian, hal ini berguna untuk menjaga terhadap input acak, namun memilih input pengujian sepenuhnya secara acak (yaitu tanpa pertimbangan khusus terhadap setiap use case atau case edge) berbatasan dengan tidak berguna. Tujuan pengujian adalah untuk memvalidasi solusi Anda terhadap persyaratan dan harapan majikan / klien / pengguna Anda; ini berarti Anda harus fokus pada penargetan semua kasus tepi dan kondisi batas, serta kasus 'merosot' yang tidak cocok dengan alur kerja yang diharapkan pengguna.

Tentu saja, Anda dapat menjalankan tes yang mengungkapkan bug yang kemudian Anda putuskan tidak layak untuk diperbaiki; ini mungkin karena semua jenis alasan - bug mungkin terlalu mahal untuk diperbaiki relatif terhadap dampaknya pada pengguna, atau Anda mungkin menemukan bug dalam fitur yang tidak digunakan siapa pun, atau bug mungkin sudah sangat mapan dalam sistem yang sudah ada sehingga beberapa pengguna memperlakukannya sebagai fitur.

Atau, Anda mungkin menulis beberapa perangkat lunak yang dipesan lebih dahulu yang memiliki audiensi terbatas dari pengguna 'ahli' di mana tidak ada manfaat komersial untuk menghabiskan waktu memperbaiki bug, karena para pengguna tersebut mampu melakukan pekerjaan mereka dengan perangkat lunak kereta (misalnya, alat diagnostik digunakan oleh tim TI internal tidak memberikan pendapatan apa pun, jadi jika kadang-kadang macet, maka tidak ada yang mau membayar waktu yang diperlukan untuk memperbaikinya - mereka hanya akan memberitahu tim TI untuk hidup dengan bug sebagai gantinya) .

Namun, Anda hanya dapat membuat keputusan ini jika Anda tahu tentang bug ini. Misalnya, pengguna dapat memasukkan input berbahaya yang menghapus seluruh database - jika Anda belum secara eksplisit melindungi dan menguji skenario ini, maka tidak ada cara Anda bisa memastikan apakah ini bisa terjadi atau tidak. Risiko meninggalkan bug yang belum ditemukan dalam sistem berarti bahwa Anda berpotensi membiarkan diri Anda terbuka terhadap masalah nyata jika salah satu bug itu muncul di dunia nyata dan memiliki dampak besar pada pengguna Anda.

Jadi, sementara keputusan untuk memperbaiki bug mungkin memerlukan beberapa masukan dari pemilik perangkat lunak (biasanya siapa pun yang membayar gaji Anda), keputusan apakah akan menguji bug, dan kasus mana yang akan diuji adalah masalah teknis yang perlu diperhatikan. diperhitungkan dalam perkiraan dan perencanaan proyek, di mana tujuannya harus untuk sesuatu yang sedekat mungkin dengan cakupan semaksimal mungkin mengingat kendala waktu / uang / sumber daya.


12
Meskipun pengujian sepenuhnya secara acak tidak berguna, dan Anda harus secara eksplisit menguji sebanyak mungkin kasus tepi yang Anda pikirkan, sejumlah fuzzing acak kadang-kadang juga berguna untuk memeriksa masalah yang mungkin tidak Anda lihat sebelumnya.
Sean Burton

10
Kami memiliki pepatah: "Sangat sulit untuk menulis perangkat lunak idiot-bukti karena idiot adalah orang yang sangat pintar". Jadi, lakukan tes untuk input "omong kosong"!
Ralf Kleberhoff

For example, a user may enter a malicious input which wipes the entire database - if you haven't explicitly protected against and tested for this scenario, then there's no way you can be sure whether or not this can happen.Suka Bobby Tables kecil dari komik XKCD ini ? ;)
nick012000

12
"Jangan pernah menganggap apa pun." Saya menganggap ini adalah saran yang bagus.
candied_orange

Terima kasih telah menunjukkan bahwa tidak semua "bug" adalah "perbaikan". Ada perbedaan besar dalam menyadari kasus tepi, dan menghabiskan waktu dan uang memperbaiki kasus tepi. Tentunya akan sangat bagus untuk memungkinkan input apa pun yang mungkin ke formulir web dan memiliki tanggapan yang ditetapkan untuk semua kasus, tetapi mungkin itu tidak relevan dengan perangkat lunak spesifik Anda. Mungkin input Anda hanya membolehkan angka di ujung depan, jadi tidak mungkin menerima non-angka di ujung belakang. "Memperbaiki" bug potensial dari memiliki non-angka dalam bentuk hanya angka Anda adalah buang-buang waktu dan uang.
EvSunWoodard

60

Ada beberapa faktor yang perlu dipertimbangkan. Untuk mengilustrasikan poin-poin itu, saya akan menggunakan contoh bidang di mana pengguna harus memasukkan persentase dalam konteks kuota yang ditentukan untuk tugas tertentu dalam hal berapa banyak ruang disk yang bisa digunakan tugas tersebut. 0% berarti tugas tidak akan bisa menulis apa pun ke disk; 100% berarti tugas bisa mengisi semua ruang disk. Nilai-nilai di antaranya berarti apa yang dimaksud.

Sebagai pengembang, Anda mungkin mempertimbangkan bahwa nilai yang dapat diterima adalah [0, 1, 2, 3, ⋯ 99, 100], dan yang lainnya konyol. Mari kita lihat mengapa pengguna masih bisa memasukkan nilai-nilai "konyol" itu.

Salah ketik

%^

Pengguna memasukkan nilai 56, tetapi secara keliru ditekan Shiftsaat memasukkannya (misalnya karena pada keyboard Prancis, Anda harus menekan Shiftuntuk memasukkan angka, dan pengguna terus-menerus beralih antara keyboard Prancis dan QWERTY).

Dengan cara yang sama, Anda bisa mendapatkan nomor, dengan sesuatu setelah atau sebelum itu, atau di antaranya:

56q

Di sini, pengguna mungkin memasukkan digit, diikuti oleh tab untuk pindah ke bidang berikutnya. Alih-alih menekan   ⇆  , pengguna menekan tombol tetangga.

Kesalahpahaman dan salah tafsir

Input kosong mungkin yang paling biasa. Pengguna membayangkan bahwa bidang itu opsional, atau tidak tahu apa yang harus dimasukkan dalam bidang ini.

56.5

Pengguna berpikir bahwa nilai floating point dapat diterima. Entah pengguna salah, dan aplikasi harus dengan sopan menjelaskan mengapa hanya nilai integer yang diterima, atau persyaratan awal yang salah, dan masuk akal untuk membiarkan pengguna memasukkan nilai floating point.

none

Pengguna salah mengerti bahwa ketika diminta untuk ruang tugas yang bisa diambil, aplikasi mengharapkan nomor. Ini bisa menunjukkan antarmuka pengguna yang buruk. Misalnya, menanyakan kepada pengguna "Berapa banyak ruang disk yang harus diambil oleh tugas?" Mengundang masukan semacam ini, sementara bidang dengan tanda persen berikut akan menerima lebih sedikit dari masukan semacam itu, karena "tidak ada%" tidak menghasilkan banyak akal.

150

Pengguna salah mengerti apa artinya persentase dalam kasus ini. Mungkin pengguna ingin memberi tahu bahwa tugas tersebut dapat mengambil 150% dari ruang yang saat ini digunakan, jadi jika pada disk 2 TB, 100 GB digunakan, tugas tersebut dapat menggunakan 150 GB. Sekali lagi, antarmuka pengguna yang lebih baik bisa membantu. Misalnya, alih-alih memiliki bidang masukan kosong dengan tanda persen ditambahkan padanya, orang dapat memilikinya:

[____] % of disk space (2 TB)

Ketika pengguna mulai mengetik, itu akan mengubah teks dengan cepat menjadi ini:

[5___] % of disk space (102.4 GB of 2 TB)

Representasi

Angka besar atau angka dengan floating point dapat direpresentasikan secara berbeda. Misalnya, sejumlah 1234,56 dapat ditulis seperti itu: 1,234.56. Bergantung pada budaya, representasi teks dari nomor yang sama akan berbeda. Di Prancis, jumlah yang sama akan ditulis seperti ini: 1 234,56. Lihat, koma di mana Anda tidak akan mengharapkan satu, dan spasi.

Selalu mengharapkan format tertentu menggunakan lokal tertentu akan membuat Anda cepat atau lambat, karena pengguna dari berbagai negara akan memiliki kebiasaan berbeda dalam menulis angka, tanggal dan waktu, dll.

Manusia vs. komputer

Twenty-four

Manusia biasa tidak berpikir dengan cara yang sama seperti komputer. "Dua puluh empat" adalah angka aktual, terlepas dari apa yang PC katakan kepada Anda.

Meskipun (1) kebanyakan sistem tidak menangani semua jenis input ini dan (2) hampir setiap pengguna tidak akan membayangkan memasukkan nomor yang ditulis dalam huruf penuh, itu tidak berarti bahwa input seperti itu konyol. Dalam Tentang Wajah 3 , Alan Cooper menunjukkan bahwa tidak menangani input tersebut merupakan indikasi ketidakmampuan komputer untuk beradaptasi dengan manusia, dan idealnya, antarmuka harus dapat menangani input tersebut dengan benar.

Satu-satunya hal yang harus saya tambahkan ke buku Alan Cooper adalah bahwa dalam banyak kasus, angka ditulis dalam digit karena kesalahan . Fakta bahwa komputer mengharapkan penggunanya melakukan kesalahan (dan tidak akan mentolerir pengguna yang menulis dengan benar) sangat menjengkelkan.

Unicode

5𝟨

Unicode menyimpan kejutannya sendiri: karakter yang bisa terlihat sama tidak sama. Tidak meyakinkan? Salin-tempel "5𝟨" === "56"ke alat pengembang browser Anda, dan tekan Enter.

Alasan bahwa string tersebut tidak sama adalah bahwa karakter Unicode 𝟨tidak sama dengan karakter 6. Ini akan menciptakan situasi di mana pelanggan yang marah akan menelepon, memberi tahu bahwa aplikasi Anda tidak berfungsi, memberikan tangkapan layar dari input yang terlihat sah, dan aplikasi Anda mengklaim bahwa input tersebut tidak valid.

Mengapa ada orang yang memasukkan karakter Unicode yang mirip digit, Anda akan bertanya? Sementara saya tidak akan mengharapkan pengguna memasukkan satu secara tidak sengaja, copy-paste dari sumber yang berbeda dapat menyebabkan itu, dan saya punya kasus di mana pengguna benar-benar melakukan copy-paste dari string yang berisi karakter Unicode yang tidak akan muncul di layar.

Kesimpulan

Itu adalah kasus yang Anda dapatkan untuk bidang input angka dasar. Saya akan membiarkan Anda membayangkan apa yang bisa Anda tangani untuk formulir yang lebih kompleks, seperti kencan, atau alamat.

Jawaban saya terfokus pada apa yang Anda sebut input "konyol". Pengujian bukan tentang memeriksa jalur bahagia; ini juga tentang memeriksa bahwa aplikasi Anda tidak rusak ketika pengguna jahat dengan sengaja memasukkan hal-hal aneh, mencoba untuk memecahkannya. Ini berarti bahwa ketika Anda meminta persentase, Anda juga harus menguji apa yang terjadi ketika pengguna merespons dengan string yang berisi 1.000.000 karakter, atau angka negatif, atau tabel bobby .


9
Ah, U + 1D7E8: MATEMATIKA SANS-SERIF DIGIT ENAM.
Andreas Rejbrand

23
Kembali karakter unicode lainnya: Pada keyboard Jepang sangat umum untuk beralih dari digit normal ke digit lebar penuh di mana digit selebar kanji. Jadi pengguna Jepang mungkin memiliki input Jepang pada (bukan bahasa Inggris) dan secara tidak sengaja memasukkan digit lebar penuh.
Jan

3
Sebelum melihat bagian 5𝟨 Anda tentang masalah homoglyph yang sama, saya sebenarnya mengharapkan 1 234,56string (menggunakan U + 00A0 NO-BREAK SPACE alih-alih U + 0020 SPACE), yang merupakan cara yang tepat untuk mengkodifikasi penanda angka tersebut (atau dengan U + 202F NARROW NO-BREAK SPACE, peroahps). Menyalin nilai dari aplikasi apa pun yang memformat angka sesuai dengan lokal sebelum disajikan kepada pengguna akan dengan mudah menghasilkan itu.
Ángel

4
copy-paste adalah masalah yang jauh lebih besar. Yang umum adalah menyalin ruang tempel, jeda baris, karakter yang tidak terlihat ...
Sulthan

7
@Arseni Mourzenko Anda pasti beruntung. Menyalin dari mis. PDF dan menempel harus menempel semua jenis karakter yang mungkin tidak diinginkan tergantung pada circ, misalnya ligatur (untuk fi dll), kutipan cerdas, en atau em dash di mana ASCII minus diinginkan, dll.
Rosie F

12

Ada banyak jawaban bagus di sini yang menjelaskan mengapa ini penting, tetapi tidak banyak saran tentang cara melindungi aplikasi Anda secara masuk akal. "Praktik standar" adalah menggunakan validasi input yang kuat, pada klien dan server. Masukan yang tidak masuk akal mudah dipertahankan; Anda hanya menolak apa pun yang tidak masuk akal dalam konteks spesifik itu. Misalnya, nomor jaminan sosial hanya terdiri dari tanda hubung dan digit; Anda dapat dengan aman menolak apa pun yang diketik pengguna dalam bidang nomor jaminan sosial.

Ada dua jenis pengujian yang harus dilakukan pada setiap aplikasi yang Anda tulis, dan masing-masing memiliki tujuan yang berbeda. Pengujian yang Anda lakukan pada aplikasi Anda sendiri adalah pengujian positif; tujuannya adalah untuk membuktikan bahwa program itu bekerja. Pengujian yang dilakukan penguji tambahan pada aplikasi Anda adalah pengujian negatif; tujuannya adalah untuk membuktikan bahwa program Anda tidak berfungsi. Mengapa Anda membutuhkan ini? Karena Anda bukan orang terbaik untuk menguji perangkat lunak Anda sendiri. Lagi pula, Anda yang menulisnya, jadi sudah jelas itu berhasil, kan?

Saat Anda menulis validasi input, Anda akan menggunakan tes positif untuk membuktikan bahwa validasi Anda berfungsi. Penguji akan menggunakan input acak untuk mencoba membuktikan bahwa itu tidak berfungsi. Perhatikan bahwa ruang masalah untuk input acak pada dasarnya tidak terikat; tujuan Anda bukan untuk menguji setiap permutasi yang mungkin, tetapi untuk membatasi ruang masalah dengan menolak input yang tidak valid.

Perhatikan juga bahwa pengguna akhir bukan satu-satunya yang memberikan input ke program Anda. Setiap kelas yang Anda tulis memiliki API sendiri dan batasannya sendiri pada apa yang dianggap sebagai input yang valid, sehingga validasi yang kuat (yaitu "kontrak kode") juga penting untuk kelas Anda. Idenya adalah untuk mengeraskan perangkat lunak Anda sehingga perilaku tak terduga jarang atau tidak ada sejauh mungkin.

Akhirnya, alur kerja itu penting. Saya telah melihat aplikasi jatuh, bukan karena pengguna memasukkan sesuatu yang tidak masuk akal, tetapi karena mereka melakukan sesuatu dalam aplikasi dengan urutan yang tidak terduga. Aplikasi Anda harus mengetahui kemungkinan ini dan menangani alur kerja yang tidak terduga dengan anggun atau meminta pengguna untuk melakukan operasi dalam urutan yang Anda tentukan.


Contoh umum dari aplikasi yang mengharapkan pesanan tertentu adalah fungsi "teardown" yang melepaskan pegangan yang tidak pernah dicadangkan.
wizzwizz4

2
Sayangnya, praktik standar adalah menolak apa pun yang tidak masuk akal dan membuat pengguna bingung dan frustrasi. Praktik yang benar adalah menjelaskan secara akurat (misalnya menggunakan pesan kesalahan / umpan balik) mengapa input ditolak, sehingga pengguna tahu cara memperbaiki input mereka dan menerimanya. "Dapatkan integer dari 1 hingga 100" yang sederhana membutuhkan minimal 4 pesan kesalahan yang berbeda (string kosong, karakter yang tidak didukung, terlalu besar, terlalu kecil); ditambah pengujian untuk memastikan umpan balik yang tepat diberikan dalam setiap kasus.
Brendan

2
@ Brendan: Hanya satu pesan yang diperlukan: "Ini harus berupa angka antara 1 dan 100." Pengguna tidak tahu (dan tidak perlu tahu) apa string , atau apa arti "karakter yang tidak didukung". Itu adalah pengaruh programmer, bukan bantuan pengguna.
Robert Harvey

@ RobertTarvey Saya mungkin akan menambahkan sesuatu pernyataan di sepanjang baris "terdiri dari angka". Karena input "Tujuh Puluh Sembilan" adalah angka antara 1 dan 100, tetapi bukan input yang dapat digunakan sebagian besar program.
Delioth

1
@Delioth: Kamu tidak bisa memperbaiki kebodohan.
Robert Harvey

11

Biasanya nilai 'acak' tidak acak. Anda mencoba menangkap kasus tepi, "tidak dikenal".

Katakan misalnya karakter # akan merusak aplikasi Anda. Anda tidak mengetahui hal ini sebelumnya dan tidak mungkin menulis test case untuk setiap input yang memungkinkan. Tetapi kita dapat menulis tes untuk "¬!"£$%^&*()_+-=[]{};'#:@~,./<>?|\"dan melihat apakah itu rusak


2
+1 Secara mengejutkan sekilas pertama kali seberapa sering karakter acak itu menemukan bug. Data dari input pengguna dapat melakukan banyak perjalanan melalui banyak komponen / layanan. Hanya diperlukan satu komponen dalam rantai yang tidak memprosesnya dengan benar agar sistem memiliki bug.
Lan

4
esp. sekarang semua keyboard ponsel memiliki emotikon
Ewan

untuk pengembang .Net alat IntelliTest (sebelumnya disebut Pex) adalah cara yang sangat baik untuk menjalankan jalur kode untuk menemukan kasus tepi, ini sangat berguna dalam validasi input dan untuk mendapatkan cakupan kode yang baik.
James Snell

7

Saya pernah menulis sebuah program, yang saya uji langsung di lab dengan 60 siswa. Saya berdiri di belakang 60 layar komputer dan melihat mereka menggunakannya. Jumlah hal konyol yang mereka lakukan adalah membesarkan rambut. Saya basah kuyup menonton "kreativitas" mereka. Mereka melakukan jauh lebih banyak daripada yang bisa diimpikan oleh individu mana pun dalam seumur hidup. Tentu saja salah satu dari mereka memecahkannya.

Setelah itu saya mengikuti pendekatan: if "a very specific use case" do, else show error

Jika saya memiliki beberapa kasus penggunaan, saya benar-benar mendefinisikannya dan rantai di atas.


1
Namun, kasus penggunaan spesifik tersebut mungkin terlalu spesifik. Kami selalu meremehkan ruang input yang valid . (O'Hara, desimal berformat lokal, dll). Berapa banyak rutinitas keuangan yang disiapkan untuk menangani suku bunga negatif?
Guran

6

Apa yang Anda gambarkan adalah Pengujian Fuzzing atau Fuzz : melempar input acak dan tidak valid pada suatu sistem dan lihat apa yang terjadi. Anda tidak melakukan ini karena Anda mengharapkan pengguna melakukannya. Anda melakukannya untuk mengekspos asumsi dan bias Anda sendiri untuk menekankan tepi sistem Anda untuk melihat apa yang terjadi.

Masukan tes normal yang ditulis oleh manusia dengan akan datang dengan asumsi dan bias. Bias ini dapat berupa kelas bug tertentu yang tidak pernah ditemukan melalui pengujian.

Misalnya, jika sebagian besar input Anda berada dalam rentang Unicode aman ASCII, asumsi tentang pengkodean karakter dalam kode tidak dilakukan. Atau mungkin selalu di bawah ukuran tertentu, jadi bidang berukuran tetap atau buffer tidak mengenai. Atau mungkin ada karakter khusus yang ditafsirkan dengan cara mengejutkan yang memperlihatkan bahwa input pengguna dimasukkan ke shell atau digunakan untuk membuat kueri dengan cara yang tidak aman. Atau mungkin ada terlalu banyak pengujian "happy path" dan tidak cukup upaya untuk melakukan penanganan kesalahan.

Fuzzing tidak memiliki prasangka seperti itu tentang input. Ini akan secara brutal menjalankan sistem Anda dengan kemungkinan kombinasi input "valid". Unicode, ASCII, besar, kecil, dan banyak dan banyak kesalahan. Sistem Anda harus merespons semuanya dengan anggun. Seharusnya tidak pernah crash. Pengguna harus selalu mendapatkan semacam pesan masuk akal tentang apa yang salah dan bagaimana cara memperbaikinya. Bukan Sampah Masuk / Sampah Keluar, ini Sampah Masuk / Galat Keluar .

Sementara orang mungkin menolak ledakan yang dihasilkan karena "tidak ada pengguna nyata yang akan melakukan itu", itu melewatkan inti latihan. Fuzzing adalah cara murah untuk menghilangkan bias Anda tentang kemungkinan input. Ini adalah cara murah untuk membuang semua hal aneh yang akan coba dilakukan pengguna di sistem Anda. Sebagai insinyur, pekerjaan Anda adalah memastikan sistem Anda gagal dengan anggun.


Lebih lanjut, mengelabui "input" bukan hanya tentang pengguna. Itu bisa merupakan hasil dari permintaan API ke layanan pihak ke-3, bagaimana jika itu mulai mengirim hasil yang kacau? Bagaimana sistem Anda menangani itu? Sistem yang tepat harus memberi tahu admin bahwa ada komponen yang rusak. Sistem yang tidak benar akan secara diam-diam menolak permintaan yang buruk, atau lebih buruk lagi, menerimanya sebagai data yang baik.

Akhirnya, beberapa pengguna jahat. Jika Anda tidak menguji sistem Anda, orang lain akan melakukannya. Mereka akan menyelidiki tepi sistem Anda untuk kesalahan umum dan mencoba menggunakannya sebagai celah keamanan. Pengujian fuzz dapat mensimulasikan ini, sampai batas tertentu, dan Anda dapat menangani setiap lubang keamanan yang mungkin ditemukan sebelum menjadi masalah.


Dan ada alat pengujian Quick Check yang melakukan hal serupa
icc97

4

Jika tujuan Anda adalah untuk menciptakan produk yang berkualitas, maka ujilah setiap jenis input yang mungkin dapat dikirimkan oleh pengguna. Kalau tidak, Anda hanya menunggu hari ketika seseorang mengirimkan satu jenis input yang Anda rasa tidak perlu diuji.

Selama demonstrasi besar dari perangkat lunak e-auction baru di otoritas lokal tempat saya bekerja, manajer saya memutuskan (diakui dengan beberapa kerusakan) bahwa dia merasa perlu untuk melihat apa yang terjadi jika dia mengajukan penawaran lelang dengan nilai negatif. Betapa terkejutnya saya, perangkat lunak lelang membuat penawaran yang tidak masuk akal ini dan seluruh proses lelang terhenti. Jenis lelang yang diperlihatkan seharusnya tidak pernah membiarkan jumlah negatif diajukan.

Beberapa dari kelompok besar pejabat pengadaan dan keuangan merasa terganggu dengan manajer saya karena mengirimkan nilai yang tidak masuk akal. Tetapi yang lain, termasuk saya, merasa jengkel dengan pengembang perangkat lunak karena gagal menguji dan menolak jenis input yang jelas tidak valid. Saya hanya bisa membayangkan betapa lemahnya peranti lunak tersebut dalam membelokkan jenis input yang tidak valid lainnya (upaya injeksi kode, karakter eksotis yang tidak dapat diwakili dalam tabel database, dll.).

Jika terserah saya, saya akan mengembalikan perangkat lunak dan menganggapnya tidak sesuai untuk tujuan. Perbedaan antara produk perangkat lunak yang lemah dan kuat adalah tingkat pengujian yang telah dikenakan.


2
test every possible type of input that a user will be physically able to submit.- Ruang masalah itu pada dasarnya tidak terbatas, dan Anda membuang-buang waktu dengan mencoba menguji semuanya. Memeriksa input negatif adalah satu bifurkasi; itu tidak hanya masuk akal tetapi juga diharapkan dari pengembang yang kompeten. Anda tidak perlu memeriksa setiap angka negatif untuk membuktikan bahwa validasi tersebut berfungsi.
Robert Harvey

13
Itu sebabnya saya mengatakan setiap jenis input, dan tidak setiap input mungkin. Dan saya akan mengulangi poin saya: jika Anda tidak menguji setiap jenis input, pengguna akhirnya akan.
Arkanon

1

Misalnya: Saat melakukan pengujian fungsional formulir dalam aplikasi web, kami akan menguji bidang dengan memasukkan berbagai jenis nilai input acak.

Iya. Ini adalah semacam tes tetapi ini bukan tes fungsional . Inilah yang disebut pengujian stres . Ini adalah tindakan memberikan tekanan pada suatu sistem untuk melihat apakah ia dapat menanganinya.

Jadi apa gunanya menggabungkan semua testcases yang mungkin / mungkin tidak menyebabkan bug, ketika kemungkinan muncul masalah seperti ini dalam produksi jauh lebih sedikit?

Ketika Anda menguji perangkat lunak stres, Anda mencoba menemukan batasan-batasan apa batas perangkat lunak itu.

Tes-tes tersebut pada dasarnya bersifat menyeluruh. Di mana Anda perlu menemukan batas penggunaan, titik putus, periksa semua cabang logis atau lihat bagaimana kegagalan parsial mempengaruhi keseluruhan sistem.

Anda dapat lulus semua tes fungsional Anda, tetapi masih gagal dalam pengujian stres .

Saya mengajukan pertanyaan ini hanya untuk mengetahui apakah ada praktik standar yang harus diikuti atau sepenuhnya bergantung pada produk, domain, dan semua faktor lainnya.

Ya, ini adalah praktik standar.

Perangkat lunak pengujian adalah tentang mengajukan pertanyaan tentang yang diharapkan perilaku yang , dan ketika semua tes lulus, ini menunjukkan bahwa perangkat lunak beroperasi sebagaimana dimaksud. Inilah sebabnya mengapa tes membuat pra-kondisi yang baik untuk menyebarkan pembaruan.

Pengujian tekanan tidak memberikan indikator kelulusan atau kegagalan spesifik yang jelas. Hasilnya lebih informatif. Ini memberi tahu Anda apa yang dapat ditangani sistem Anda dan Anda membuat keputusan dari informasi itu.

Anda dapat menentukan tujuan spesifik untuk pengujian stres yang harus dilewati untuk melanjutkan ke tahap selanjutnya dalam pengembangan. Itu dapat dimasukkan sebagai bagian dari proses penjaminan kualitas Anda, tetapi perubahan dalam lingkungan dapat mengubah hasil dari tes stres. Jadi orang menjalankan tes stres pada waktu yang berbeda untuk melihat bagaimana sistem menangani kondisi yang berubah.

Maksud saya adalah Anda tidak bisa hanya menjalankan pengujian stres setiap kali Anda menggunakan versi baru perangkat lunak Anda, dan menganggap ini berarti semuanya akan lulus pengujian stres nanti.

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.