Bakit kailangan ng mga programmer ang pagsubok?

Ang susunod na pares ng mga antas ay iuukol sa pagsubok sa paraang kailangan ito ng mga programmer . Ngunit una, alamin natin kung ano ang pagsubok at kung bakit ito kinakailangan.

Sa pagsasaalang-alang sa software, maaari naming sabihin na ang gawain ng pagsubok ay upang suriin na ang programa ay:

  • ginagawa niya ang dapat niyang gawin
  • hindi niya ginagawa ang hindi niya dapat gawin

Ang pangalawang punto, sa pamamagitan ng paraan, ay hindi mas mahalaga kaysa sa una, ngunit higit pa sa na mamaya.

Magsimula tayo sa unang punto. Ano ang ibig sabihin ng "ginagawa ng programa ang dapat nitong gawin"?

Una, kailangang gumawa ng isang listahan ng lahat ng mga kaso ng paggamit para sa programa. Pangalawa, kailangan nilang ilarawan kung paano dapat gumana ang program, kung paano dapat kumilos ang user, at kung anong mga resulta ang inaasahan. Hindi ka na makakapagpatuloy pa.

Sa sandaling isinulat namin ang "kung paano dapat kumilos ang gumagamit", ang buong ideya ng pagsusulat ng mahusay na dokumentasyon ay nahulog. Ang mga tao ay hindi mga makina, bukod pa rito, ang mga tao ay madalas na kumikilos gamit ang software ayon sa gusto nila . Walang sinuman ang nagsisimula sa kanilang kakilala sa teknolohiya sa pamamagitan ng pag-aaral ng mga tagubilin. Ito ay katotohanan.

Samakatuwid, nakakakuha kami ng isang bagong katotohanan: ang kakaiba ng software ay mayroon itong maraming iba't ibang mga sitwasyon sa trabaho. Ang ilan sa mga ito ay halata, ang iba ay maaaring idokumento, ang iba ay maaaring ipagpalagay, ang iba ay maaaring hulaan, at ang iba pang 50% ay hindi man lang mangyayari sa iyo.

Mula sa pananaw ng isang programmer, karamihan sa mga bug ay hindi mga bug. Ang isang error ay kapag ang isang programa ay hindi gumagana ayon sa nararapat o tulad ng inaasahan. At mayroong maraming mga sitwasyon kung saan hindi malinaw kung paano dapat gumana ang programa, o mga sitwasyon na sumasalungat sa bawat isa ...

Java webinar

Mayroong walang katapusang bilang ng mga senaryo, at palaging may mga kaso sa produkto kapag ang programa ay hindi kumikilos gaya ng inaasahan (isinulat ng programmer ang code para lamang sa ilang dosenang mga senaryo). Samakatuwid, maaari itong pagtalunan na palaging may mga bug sa anumang programa at anumang produkto ay maaaring mapabuti nang walang hanggan .

Pagkatapos nito, ang lahat ay bumaba sa kapakinabangan. Una, inaayos ng programmer ang pinakamalalaking bug, pagkatapos ay ang mas maliliit na bug, at iba pa. At sa wakas, darating ang isang yugto kapag ang may-ari ng produkto ay naniniwala na ito ay hindi magagawa sa ekonomiya upang ipagpatuloy ang paggawa dito.

Ngunit bumalik sa mga error na kinikilala ng lahat bilang mga error: ang programa ay malinaw na gumagawa ng isang bagay na mali, nahulog, sinira ang isang bagay, atbp. Ang ganitong mga error ay maaaring kondisyon na nahahati sa 3 kategorya: malaki, katamtaman at maliit.

At madalas na nangyayari na ang isang programmer ay nagtatrabaho sa pag-aayos ng daluyan o kahit na maliit na mga bug, bagaman mayroon pa ring maraming mas malubhang problema sa proyekto. Hindi lang niya nahanap ang mga ito , kaya ginagawa niya ang pinakamalalaking alam niya.

Samakatuwid, sa anumang proyekto dapat mayroong mga tester. Ang mga taong ito ay partikular na natututong tingnan ang produkto mula sa iba't ibang anggulo. Kaya maaari mong makita ang higit pang mga senaryo ng programa. Ang kanilang gawain ay upang mahanap ang mga error at isulat ang mga ito (upang hindi mahanap ang parehong error nang maraming beses).

Ang pagsubok ay isang proseso na naglalayong maghanap ng mga pagkakamali. Ang mga bug na ito ay dapat matagpuan, inilarawan at bigyang-priyoridad. Pagkatapos lamang ng pag-prioritize ng mga error maaari nating pag-usapan ang tungkol sa isang epektibong proseso ng pagpapabuti ng software.

Tandaan, ang unang hakbang sa paglutas ng problema ay ang pagkilala na mayroong problema . Hindi mo maaayos ang isang pagkakamali na hindi mo alam.

Pagsubok sa Automation

Sa tingin ko lahat tayo ay sumang-ayon na ang pagsubok ay mahalaga, kaya tingnan natin ang pagsubok tulad ng mga programmer. Paano tinitingnan ng mga programmer ang pagsubok? Ang mga programmer ay awtomatiko ang gawain ng ibang tao. Ang huling propesyon na mawawala ay ang propesyon sa programming.

Awtomatiko namin ang anumang mga proseso na aming nararanasan. Kaya kailangang awtomatiko ang pagsubok. At paano i-automate ang paghahanap para sa mga error? Maikling sagot: hindi. Ngunit narito muli ang katotohanan na kami ay mga programmer ay dumating sa aming tulong.

Ang proseso ng pagbuo ng software ay binubuo ng mga patuloy na pagbabago dito. sa proseso pa lamang ng patuloy na paggawa ng mga pagbabago, madalas na sinisira ng mga programmer ang isang bagay na gumana nang maayos hanggang kamakailan.

At ang mga tagasubok, sa halip na maghanap ng mga bagong error, ay napipilitang patuloy na suriin kung nasira namin ang isang bagay na gumagana nang maayos sa mahabang panahon. Ang tinatawag na regression testing. Ito ang ganitong uri ng pagsubok na maaari at dapat na awtomatiko.

Dito lahat ng software ay maaaring nahahati sa dalawang bahagi:

  • nakikipag-ugnayan ang programa sa tao
  • ang programa ay nakikipag-ugnayan sa isa pang programa

Ang unang opsyon ay mas mahirap i-automate, nangangailangan ito ng mga espesyal na automator tester, tinatawag din silang QA Automation o Software Test Engineer.

Ngunit ang pangalawang opsyon ay maaari at dapat na awtomatiko nang nakapag-iisa. Kung mayroon kang isang piraso ng software na:

  • gumagana nang maayos
  • nasubok na
  • ipinatupad bilang isang hiwalay na module o lohikal na bloke
  • walang balak magbago
  • iba pang mga module o programa ang nakasalalay dito
  • magastos ang functional failure

Inirerekumenda kong maglaan ng oras upang magsulat ng mga pagsubok para dito na kumukuha ng mga pangunahing aspeto ng kasalukuyang pagpapagana nito. Makatuwirang maglaan ng 5% ng iyong oras ng pagtatrabaho para dito , o 1 araw bawat buwan.

Hindi na kailangang magsulat ng mga pagsubok para sa kapakanan ng mga pagsubok.

Walang susuporta sa iyong mga pagsubok. Hindi ibang programmer, hindi ang iyong sarili. Walang gumagawa niyan. 99% ng lahat ng nakasulat na pagsusulit ay inabandona at/o hindi pinagana. Kung hindi ka magsulat ng mga pagsusulit - huwag magsulat. Sumulat lamang kung talagang hindi mo magagawa nang wala sila.

Mga uri ng pagsubok

Ang bawat programmer, kung hindi siya sumailalim sa espesyal na pagsasanay, ay masasabi sa sarili niyang mga salita kung ano ang pagsubok: pagsuri kung ginagawa ng programa ang nararapat. Gayunpaman, ang mga propesyonal sa larangang ito ay nakikilala ang buong lugar (mga uri) ng pagsubok.

Ang lahat ng pagsubok ay talagang umiikot sa pagiging maaasahan at pagkakaroon ng software, ngunit upang mas maunawaan ang direksyon ng pagsubok, tingnan natin ang ilang mga halimbawa.

Sabihin nating sinusubukan mo ang isang karaniwang online na tindahan. Pagkatapos ang mga lugar ng pagsubok ay maaaring nahahati sa mga sumusunod na uri: pagsubok sa pagganap, pagsubok sa pagganap, pagsubok sa pagsasama at pagsubok sa yunit.

Kung nagpasya ang may-ari ng site na maglunsad ng isang seryosong kampanya sa advertising, maraming mga gumagamit ang pupunta sa site nang sabay-sabay. Maaaring hindi mahuhulog ang site, ngunit ang ilan sa mga seksyon nito ay maaaring mabagal o huminto sa paggana.

Upang maiwasang mangyari ito, kailangan mong tukuyin ang mga naturang problema nang maaga at gumawa ng mga hakbang upang maalis ang mga ito. Ginagawa ito gamit ang load testing , o tinatawag din itong performance testing.

Maaari mo ring subukan kung paano gumagana ang iyong backend API at subukan ang bawat function nito: pagpaparehistro, pag-login, pagdaragdag sa cart, pagpoproseso ng pagbabayad, pagsusulat ng database, atbp. Lahat ay dapat gumana ayon sa TOR. Sa kasong ito, kailangan mong magsagawa ng functional testing .

Malamang na isinama ang iyong online na tindahan sa mga serbisyo ng third-party: pagpapadala ng mga liham at SMS, mga sistema ng pagbabayad, mga chat sa suporta sa online, pagkolekta ng feedback mula sa mga user, mga system sa advertising, atbp. Upang matiyak na gumagana ang lahat ng ito ayon sa nilalayon, kailangan mong magsama ng pagsubok .

Sa wakas, ang mga kumplikadong produkto ay madalas na pinaghiwa-hiwalay sa mga independiyenteng module. Mula sa naturang mga module, maaari mong tipunin ang pangwakas na produkto, tulad ng mula sa isang tagabuo. Kung bubuo ka ng naturang module o nakikipag-ugnayan sa mga naturang module, kakailanganin mong magsagawa ng unit testing .

Summing up, masasabi nating kailangan ng functional testing para subukan ang bawat indibidwal na function ng site. Pagsasama - para sa pagsubok sa pakikipag-ugnayan ng malalaking module at system ng iyong produkto. Modular - upang subukan ang isang hiwalay na module, mabuti, pagsubok sa pagganap - upang suriin ang pagpapatakbo ng iyong site sa ilalim ng pagkarga.

Maaaring magkaroon ng higit pang mga uri ng pagsubok: kung mas kumplikado ang produkto, mas maraming aspeto ng pag-unlad nito ang kailangang kontrolin.