Napa programer mbutuhake tes?
Saperangan tingkat sabanjure bakal dikhususake kanggo nguji kanthi cara sing dibutuhake para programer . Nanging pisanan, ayo ngerteni apa tes kasebut lan kenapa dibutuhake.
Babagan piranti lunak, kita bisa ujar manawa tugas tes yaiku mriksa program kasebut:
- nindakake apa sing kudu ditindakake
- ora nindakake apa sing ora kudu ditindakake
Titik kapindho, kanthi cara, ora kurang penting tinimbang sing pisanan, nanging luwih akeh babagan mengko.
Ayo dadi miwiti karo titik pisanan. Apa tegese "program nindakake apa sing kudu ditindakake"?
Pisanan, wong kudu nggawe dhaptar kabeh kasus panggunaan kanggo program kasebut. Kapindho, padha kudu njlèntrèhaké carane program kudu bisa, carane pangguna kudu nindakake, lan apa asil samesthine. Sampeyan ora bisa nerusake luwih.
Sanalika kita nulis "carane pangguna kudu nindakake", kabeh gagasan nulis dokumentasi sing apik ambruk. Wong dudu mesin, luwih-luwih, wong asring nindakake piranti lunak kaya sing dikarepake . Ora ana sing miwiti kenalan karo teknologi kanthi sinau instruksi kasebut. Iku kasunyatan.
Mula, kita entuk kasunyatan anyar: keanehan piranti lunak kasebut yaiku duwe macem-macem skenario kerja. Sawetara iku ketok, liyane bisa didokumentasikake, liyane bisa dianggep, liyane bisa guessed, lan liyane 50% malah ora bakal kelakon kanggo sampeyan.
Saka sudut pandang programmer, umume bug dudu bug. Kesalahan yaiku nalika program ora bisa digunakake kaya sing dikarepake. Lan ana akeh kahanan nalika ora jelas kepiye program kasebut, utawa skenario sing mbantah ...
Ana sawetara skenario tanpa wates, lan bakal tansah ana kasus ing produk nalika program ora nindakake kaya samesthine (programmer wrote kode mung sawetara rolas skenario). Mula, bisa diarani manawa ana bug ing program apa wae lan produk apa wae bisa ditambah tanpa wates .
Sawisé iku, iku kabeh teka menyang expedency. Kaping pisanan, programmer ndandani bug sing paling gedhe, banjur bug sing luwih cilik, lan liya-liyane. Lan pungkasane, ana tahap nalika pemilik produk percaya yen ora bisa ditindakake kanthi ekonomi kanggo terus nggarap.
Nanging bali menyang kasalahan sing everyone ngenali minangka kasalahan: program temenan nindakake soko salah, tiba, nyuwil soko, etc. Kesalahan kuwi bisa conditionally dipérang dadi 3 kategori: gedhe, medium lan cilik.
Lan asring banget kedaden programmer digunakake kanggo ndandani kewan omo medium utawa malah cilik, senajan isih akeh masalah serius ing project. Dheweke mung ora nemokake , mula dheweke nggarap sing paling gedhe sing dheweke ngerti.
Mulane, ing proyek apa wae kudu ana penguji. Wong-wong iki khusus sinau kanggo ndeleng produk saka macem-macem sudut. Supaya sampeyan bisa ndeleng luwih akeh skenario program. Tugase yaiku nemokake kesalahan lan nulis (supaya ora nemokake kesalahan sing padha kaping pirang-pirang).
Pengujian minangka proses kanggo nemokake kesalahan. Kewan omo iki kudu ditemokake, diterangake lan diprioritasake. Mung sawise prioritas kesalahan, kita bisa ngomong babagan proses perbaikan piranti lunak sing efektif.
Elinga, langkah pisanan kanggo ngrampungake masalah yaiku ngakoni yen ana masalah . Sampeyan ora bisa ndandani kesalahan sing sampeyan ora ngerti.
Tes Otomatisasi
Aku kabeh setuju yen tes iku penting, mula ayo ndeleng tes kaya programer. Kepiye programer ndeleng tes? Programer ngotomatisasi karya wong liya. Profesi pungkasan sing ilang bakal dadi profesi pemrograman.
Kita ngotomatisasi proses apa wae sing ditemoni. Dadi tes kudu otomatis. Lan carane ngotomatisasi panelusuran kanggo kesalahan? Wangsulan singkat: ora. Nanging ing kene maneh kasunyatan manawa kita dadi programer mbantu kita.
Proses pangembangan piranti lunak kalebu owah-owahan konstan. mung ing proses terus-terusan nggawe owah-owahan, programer kerep banget break soko sing makarya nggoleki nganti bubar.
Lan panguji, tinimbang nggoleki kesalahan anyar, kepeksa terus-terusan mriksa manawa kita wis ngilangi barang sing wis digunakake kanthi apik kanggo wektu sing suwe. Sing diarani tes regresi. Iki jenis tes sing bisa lan kudu otomatis.
Ing kene kabeh piranti lunak bisa dipérang dadi rong bagéan:
- program sesambungan karo wong
- program interaksi karo program liyane
Opsi pisanan luwih angel kanggo ngotomatisasi, mbutuhake panguji otomatis khusus, uga disebut QA Automation utawa Software Test Engineer.
Nanging opsi kapindho bisa lan kudu otomatis kanthi mandiri. Yen sampeyan duwe piranti lunak sing:
- dianggo uga
- wis dites
- dipun ginakaken minangka modul kapisah utawa pamblokiran logis
- ora planning kanggo ngganti
- modul utawa program liyane gumantung ing
- Gagal fungsional larang regane
Aku nyaranake njupuk wektu kanggo nulis tes kanggo njupuk aspèk kunci saka fungsi saiki. Iku bakal cukup kanggo nyedhiakke 5% saka wektu kerja kanggo iki , utawa 1 dina saben sasi.
Ora perlu nulis tes kanggo tes.
Ora ana sing bakal ndhukung tes sampeyan. Ora programer liyane, ora dhewe. Ora ana sing nglakoni. 99% kabeh tes tulis ditinggal lan/utawa dipateni. Yen sampeyan ora bisa nulis tes - aja nulis. Tulis mung yen sampeyan pancen ora bisa nindakake tanpa dheweke.
Jinis tes
Saben programmer, yen durung ngalami latihan khusus, bakal bisa ngomong nganggo tembung dhewe apa testing: mriksa apa program nindakake apa kudu. Nanging, profesional ing lapangan iki mbedakake kabeh wilayah (jinis) tes.
Kabeh pangujian pancen gumantung ing linuwih lan kasedhiyan piranti lunak, nanging supaya luwih ngerti arah tes, ayo goleki sawetara conto.
Contone, sampeyan lagi nyoba toko online sing khas. Banjur area tes bisa dipérang dadi jinis ing ngisor iki: tes kinerja, tes fungsional, tes integrasi lan tes unit.
Yen pemilik situs mutusake kanggo miwiti kampanye iklan sing serius, mula akeh pangguna bakal teka ing situs kasebut bebarengan. Bisa uga situs kasebut ora bakal tiba, nanging sawetara bagean bisa uga alon utawa malah mandheg.
Kanggo nyegah kedadeyan kasebut, sampeyan kudu ngenali masalah kasebut sadurunge lan njupuk langkah kanggo ngilangi. Iki ditindakake kanthi nggunakake tes beban , utawa uga diarani tes kinerja.
Sampeyan bisa uga pengin nyoba carane API backend bisa lan nyoba saben fungsi: registrasi, login, nambah cart, Processing pembayaran, nulis database, etc. Kabeh kudu bisa miturut TOR. Ing kasus iki, sampeyan kudu nindakake tes fungsional .
Toko online sampeyan kemungkinan terintegrasi karo layanan pihak katelu: ngirim layang lan SMS, sistem pembayaran, obrolan dhukungan online, ngumpulake umpan balik saka pangguna, sistem pariwara, lsp. Kanggo mesthekake yen kabeh iki bisa digunakake kaya sing dikarepake, sampeyan kudu nguji integrasi .
Pungkasan, produk kompleks asring dipérang dadi modul mandiri. Saka modul kasebut, sampeyan bisa ngumpulake produk pungkasan, kayata saka konstruktor. Yen sampeyan ngembangake modul kasebut utawa sesambungan karo modul kasebut, sampeyan kudu nindakake tes unit .
Summing up, kita bisa ngomong sing testing fungsi dibutuhake kanggo nyoba saben fungsi individu saka situs. Integrasi - kanggo nguji interaksi modul gedhe lan sistem produk sampeyan. Modular - kanggo nguji modul sing kapisah, uga, tes kinerja - kanggo mriksa operasi situs sampeyan ing beban.
Bisa uga ana luwih akeh jinis tes: luwih rumit produk kasebut, luwih akeh aspek pangembangane kudu dikontrol.