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

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.

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.

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.

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 .

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.

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

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.

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.

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.

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.