Mengapa pengaturcara memerlukan ujian?
Beberapa peringkat seterusnya akan ditumpukan kepada ujian mengikut cara yang diperlukan oleh pengaturcara . Tetapi pertama-tama, mari kita ketahui apakah ujian itu dan mengapa ia diperlukan.
Berkenaan dengan perisian, kita boleh mengatakan bahawa tugas ujian adalah untuk memeriksa bahawa program:
- melakukan apa yang dia perlu lakukan
- tidak melakukan apa yang tidak sepatutnya dia lakukan
Perkara kedua, dengan cara itu, tidak kurang pentingnya daripada yang pertama, tetapi lebih lanjut mengenainya kemudian.
Mari kita mulakan dengan titik pertama. Apakah maksud "program melakukan apa yang sepatutnya dilakukan"?
Pertama, seseorang perlu membuat senarai semua kes penggunaan untuk program tersebut. Kedua, mereka perlu menerangkan cara program harus berfungsi, cara pengguna harus berkelakuan, dan hasil yang diharapkan. Anda tidak boleh meneruskan lagi.
Sebaik sahaja kami menulis "bagaimana pengguna harus berkelakuan", keseluruhan idea untuk menulis dokumentasi yang baik runtuh. Orang bukan mesin, lebih-lebih lagi, orang sering berkelakuan dengan perisian sesuka hati mereka . Tiada siapa yang memulakan perkenalan mereka dengan teknologi dengan mempelajari arahan. Ianya adalah fakta.
Oleh itu, kami mendapat fakta baharu: keistimewaan perisian ini ialah ia mempunyai banyak senario kerja yang berbeza. Sebahagian daripada mereka adalah jelas, yang lain boleh didokumenkan, yang lain boleh diandaikan, yang lain boleh meneka, dan 50% yang lain tidak akan berlaku kepada anda.
Dari sudut pandangan pengaturcara, kebanyakan pepijat bukanlah pepijat sama sekali. Ralat adalah apabila program tidak berfungsi seperti yang sepatutnya atau seperti yang diharapkan. Dan terdapat banyak situasi apabila tidak jelas bagaimana program itu harus berfungsi, atau senario yang bercanggah antara satu sama lain ...
Terdapat bilangan senario yang tidak terhingga, dan akan sentiasa ada kes dalam produk apabila program tidak berkelakuan seperti yang diharapkan (pengaturcara menulis kod untuk hanya beberapa dozen senario). Oleh itu, boleh dikatakan bahawa sentiasa ada pepijat dalam mana-mana program dan mana-mana produk boleh diperbaiki tanpa henti .
Selepas itu, semuanya bergantung kepada kesesuaian. Mula-mula, pengaturcara membetulkan pepijat terbesar, kemudian pepijat yang lebih kecil, dan seterusnya. Dan akhirnya, tiba satu peringkat apabila pemilik produk percaya bahawa ia tidak dapat dilaksanakan secara ekonomi untuk terus mengusahakannya.
Tetapi kembali kepada ralat yang semua orang iktiraf sebagai ralat: program ini jelas melakukan sesuatu yang salah, jatuh, memecahkan sesuatu, dan lain-lain. Ralat sedemikian boleh dibahagikan secara bersyarat kepada 3 kategori: besar, sederhana dan kecil.
Dan selalunya ia berlaku bahawa seorang pengaturcara sedang berusaha untuk membetulkan pepijat sederhana atau kecil, walaupun masih terdapat banyak masalah yang lebih serius dalam projek itu. Dia hanya tidak menjumpai mereka , jadi dia sedang mengusahakan yang terbesar yang dia tahu.
Oleh itu, dalam mana-mana projek perlu ada penguji. Mereka ini secara khusus belajar melihat produk dari sudut yang berbeza. Jadi anda boleh melihat lebih banyak senario program. Tugas mereka adalah untuk mencari ralat dan menulisnya (supaya tidak menemui ralat yang sama beberapa kali).
Pengujian adalah satu proses yang bertujuan untuk mencari kesilapan. Pepijat ini harus ditemui, diterangkan dan diutamakan. Hanya selepas mengutamakan ralat kita boleh bercakap tentang proses penambahbaikan perisian yang berkesan.
Ingat, langkah pertama untuk menyelesaikan masalah adalah dengan mengakui bahawa terdapat masalah . Anda tidak boleh membetulkan kesilapan yang anda tidak tahu.
Ujian Automasi
Saya rasa kita semua bersetuju bahawa ujian adalah penting, jadi mari kita lihat ujian seperti pengaturcara. Bagaimanakah pengaturcara melihat ujian? Pengaturcara mengautomasikan kerja orang lain. Profesion terakhir yang hilang ialah profesion pengaturcaraan.
Kami mengautomasikan sebarang proses yang kami hadapi. Jadi ujian perlu diautomatikkan. Dan bagaimana untuk mengautomasikan carian untuk ralat? Jawapan ringkas: tidak. Tetapi di sini sekali lagi fakta bahawa kami adalah pengaturcara datang untuk membantu kami.
Proses pembangunan perisian terdiri daripada perubahan berterusan padanya. hanya dalam proses sentiasa membuat perubahan, pengaturcara sering memecahkan sesuatu yang berfungsi dengan baik sehingga baru-baru ini.
Dan penguji, daripada mencari ralat baharu, terpaksa sentiasa menyemak sama ada kami telah memecahkan sesuatu yang telah berfungsi dengan baik untuk masa yang lama. Ujian regresi yang dipanggil. Jenis ujian inilah yang boleh dan harus diautomasikan.
Di sini semua perisian boleh dibahagikan kepada dua bahagian:
- program berinteraksi dengan orang itu
- program berinteraksi dengan program lain
Pilihan pertama adalah lebih sukar untuk mengautomasikan, ia memerlukan penguji automator khas, mereka juga dipanggil Automasi QA atau Jurutera Ujian Perisian.
Tetapi pilihan kedua boleh dan harus diautomasikan secara bebas. Jika anda mempunyai perisian yang:
- berfungsi dengan baik
- sudah diuji
- dilaksanakan sebagai modul atau blok logik yang berasingan
- tidak merancang untuk berubah
- modul atau program lain bergantung padanya
- kegagalan fungsi adalah mahal
Saya mengesyorkan meluangkan masa untuk menulis ujian untuknya yang menangkap aspek utama kefungsian semasanya. Adalah munasabah untuk memperuntukkan 5% daripada masa bekerja anda untuk ini , atau 1 hari sebulan.
Tidak perlu menulis ujian demi ujian.
Tiada siapa yang akan menyokong ujian anda. Bukan pengaturcara lain, bukan diri sendiri. Tiada siapa yang berbuat demikian. 99% daripada semua ujian bertulis terbengkalai dan/atau dilumpuhkan. Jika anda tidak boleh menulis ujian - jangan tulis. Tulis hanya jika anda benar-benar tidak boleh melakukannya tanpa mereka.
Jenis-jenis ujian
Setiap pengaturcara, jika dia tidak menjalani latihan khas, akan dapat memberitahu dengan perkataannya sendiri apa itu ujian: menyemak sama ada program melakukan apa yang sepatutnya. Walau bagaimanapun, profesional dalam bidang ini membezakan keseluruhan kawasan (jenis) ujian.
Semua ujian benar-benar berkisar pada kebolehpercayaan dan ketersediaan perisian, tetapi untuk lebih memahami arah ujian, mari lihat beberapa contoh.
Katakan anda sedang menguji kedai dalam talian biasa. Kemudian bidang ujian boleh dibahagikan kepada jenis berikut: ujian prestasi, ujian fungsian, ujian integrasi dan ujian unit.
Jika pemilik tapak memutuskan untuk melancarkan kempen pengiklanan yang serius, maka ramai pengguna akan datang ke tapak pada masa yang sama. Mungkin tapak itu tidak akan jatuh, tetapi beberapa bahagiannya mungkin perlahan atau berhenti berfungsi.
Untuk mengelakkan perkara ini berlaku, anda perlu mengenal pasti masalah tersebut lebih awal dan mengambil langkah untuk menghapuskannya. Ini dilakukan menggunakan ujian beban , atau ia juga dipanggil ujian prestasi.
Anda juga mungkin ingin menguji cara API bahagian belakang anda berfungsi dan menguji setiap fungsinya: pendaftaran, log masuk, tambah pada troli, pemprosesan pembayaran, penulisan pangkalan data, dll. Semuanya harus berfungsi mengikut TOR. Dalam kes ini, anda perlu melakukan ujian berfungsi .
Kedai dalam talian anda berkemungkinan besar disepadukan dengan perkhidmatan pihak ketiga: menghantar surat dan SMS, sistem pembayaran, sembang sokongan dalam talian, mengumpul maklum balas daripada pengguna, sistem pengiklanan, dsb. Untuk memastikan semua ini berfungsi seperti yang dimaksudkan, anda perlu menguji penyepaduan .
Akhirnya, produk kompleks sering dipecahkan kepada modul bebas. Daripada modul sedemikian, anda boleh memasang produk akhir, seperti dari pembina. Jika anda sedang membangunkan modul sedemikian atau berinteraksi dengan modul sedemikian, maka anda perlu melakukan ujian unit .
Kesimpulannya, kita boleh mengatakan bahawa ujian berfungsi diperlukan untuk menguji setiap fungsi individu tapak. Integrasi - untuk menguji interaksi modul dan sistem besar produk anda. Modular - untuk menguji modul yang berasingan, baik, ujian prestasi - untuk menyemak operasi tapak anda di bawah beban.
Terdapat lebih banyak jenis ujian: lebih kompleks produk, lebih banyak aspek pembangunannya perlu dikawal.
GO TO FULL VERSION