Ang tradisyunal na diskarte sa mga automated na pagsubok ay ganito ang hitsura - pinag-aaralan ng isang test writer ang system na sinusubok at pagkatapos ay manu-manong isinulat ang bawat indibidwal na script upang subukan ang system na sinusuri. Maaaring may sumulat ng ipinagmamalaking salitang "handcrafted" dito, ngunit tinatawag ko itong "handjob". Ito ay dahil kadalasan ang pamamaraang ito sa paglikha at pagsulat ng mga pagsusulit ay dumaranas ng dalawang problema:

• Ang "pesticide paradox" na inilarawan ni Boris Beizer noong 1990. Binubuo ito sa katotohanan na ang mga pagsubok ay hindi gaanong epektibo sa paghuli ng mga bug, dahil ang mga bug na isinulat ng mga pagsubok na ito upang makita ay natagpuan at naayos na. Kung hindi ito mangyayari, pagkatapos ay lumitaw ang mga seryosong tanong tungkol sa nakasulat na code at mga proseso ng trabaho.
• Ang mga pagsubok ay static at mahirap baguhin, habang ang system na nasa ilalim ng pagsubok ay may posibilidad na patuloy na mag-evolve, makakuha ng bagong functionality at baguhin ang gawi ng mga luma. At kailangang baguhin ang mga pagsubok sa tuwing babaguhin ng isang functionality ang hitsura ng programa o ang pag-uugali nito. At habang lumalaki ang pagiging kumplikado ng pag-update ng mga pagsubok, lalong nagiging mahirap na bigyang-katwiran ang napakalaking gastos sa pagpapanatili ng mga pagsubok.

Ang Pagsusulit na Batay sa Modelo ay halos ganap na binabalewala ang mga problemang ito, dahil ang mga pagsubok ay awtomatikong nilikha mula sa eksaktong modelo mga aplikasyon. Lubos nitong pinapasimple ang suporta ng mga umiiral na at ang henerasyon ng mga bago, lubhang kapaki-pakinabang at nababaluktot na mga pagsubok.

Ano ang isang modelo?

Ang modelo ay isang paglalarawan ng system na sinusuri. Ang isang pormal na detalye ay magiging maayos. Ang modelo ay dapat na mas simple kaysa sa system na inilalarawan at kahit papaano ay makakatulong sa amin na maunawaan at mahulaan ang gawi ng produktong sinusuri.

Karaniwan, ang alinman sa isang state graph o ilang uri ng finite state machine ay ginagamit bilang isang modelo. Kasabay nito, ang state graph ay ginamit sa pagsubok para sa ikatlong dekada upang kumatawan sa software sa ilalim ng pagsubok at pagsubok na disenyo. Maaari kang magbasa nang higit pa tungkol sa diskarteng disenyo ng pagsubok na ito . O mas mabuti pa, sa isang buong grupo ng mga libro sa pagsubok na nai-publish sa nakalipas na 25 taon.

Sa madaling salita, maaari itong ilarawan bilang mga sumusunod: ang software sa ilalim ng pagsubok ay nagsisimulang gumana sa ilang estado ("bukas ang pangunahing pahina"), tumatanggap ng ilang input ng user ("tumingin sa mga larawan ng mga kuting") at, depende sa input na ito, gumagalaw sa isang bagong estado ("isang album na may mga larawan ng mga kuting ay lumitaw"). Gumagamit kami ng mga modelo sa lahat ng oras upang maunawaan ang pag-uugali ng piraso ng software na ginagamit namin ("Hmm... kung ako ay dito at ginagawa ko ito Ito tapos lalabas na ako doon"). Oo, sa pangkalahatan, ang lahat ng pagsubok ay maaaring ituring bilang ang tester na gumagalaw iba't ibang estado system at pagsuri kung ang mga paggalaw na ito ay nangyayari nang tama (ang ibig sabihin ng "tama" ay isang hiwalay na paksa, kaya laktawan natin ito sa ngayon).

Ano ang Model-Based Testing?

Medyo lumang ideya na gumamit ng pormal na inilarawang mga modelo upang gawing mas mura at mas madali ang pagsubok ng software. Ang Model-Based Testing mismo ay tulad ng isang "advanced" black-box testing technique. Mayroon itong ilang mga bonus sa mga tradisyonal na pamamaraan:

• Maaari mong simulan ang pag-assemble ng modelo bago pa man lumitaw ang mga unang linya ng code
• Ang pagmomodelo ay nagsasangkot ng masusing gawain sa detalye at arkitektura ng software na binuo, na, bilang panuntunan, ay nagbibigay-daan sa amin upang mapupuksa ang mga pangunahing problema at walang kuwentang pagkakaiba sa mga unang yugto.
• Maglalaman ang modelo ng impormasyon na maaaring magamit muli para sa mga pangangailangan sa pagsubok sa hinaharap, kahit na magbago ang detalye
• Ang modelo ay mas madaling mapanatili kaysa sa isang malaking grupo ng magkakaibang mga pagsubok

At higit sa lahat, ang pormal na inilarawang mga modelo kasama ang mga simulain ng teorya ng graph ay nakakatulong na makabuo ng daan-daang pagsubok nang madali at walang kahirap-hirap.

Ang isang agila-eyed Agile fan ay maaaring sumigaw "hoy! mayroon kaming BDD at ito ay sumasakop sa unang tatlong puntos at ito ay isang spec din!" Sasagot ako ng "walang ganoon - ang iyong mga halimbawa ay magiging isang normal na detalye lamang kapag si Haring Shaka Zulu ay maituturing na isang detalye para sa buong sangkatauhan."

Ngayon, isantabi natin ang debate at tingnan kung paano gamitin ang teorya ng graph upang kunin mula sa modelo ang kailangan mo para sa mga pagsubok.

Isang maikling programang pang-edukasyon sa teorya ng graph

Ang teorya ng graph ay nagmula noong 1736 sa lumang Prussian na lungsod ng Köningsberg. Ang lungsod ay nakatayo sa dalawang pampang ng ilog at sa parehong oras ay sinakop ang ilang mga isla sa gitna ng mismong ilog na ito. Ang mga residente ng lungsod na ito, dahil sa katamaran, ay sinubukang malaman kung paano bisitahin ang lahat ng pitong tulay nang hindi tumawid ng isa nang dalawang beses. Nagpasya kami sa pagsasanay, habang naglalakad, at sa teorya, sa mga pagtitipon sa kusina. Sa mahabang panahon walang sinuman ang maaaring patunayan o pabulaanan ang posibilidad ng pagkakaroon ng rutang ito hanggang sa dumating ang bore Euler at sinira ang holiday para sa mga taong-bayan.

Nakaisip si Euler ng ideya na ilarawan ang bawat piraso ng lupa bilang isang vertex ng isang graph, at mga tulay bilang mga gilid ng graph.

At pagkatapos ay biglang naging malinaw na ang kinakailangang ruta ay hindi umiiral. At lahat dahil mayroon ang lahat ng mga taluktok kakaibang numero tadyang Pagkatapos ng lahat, kung ang tuktok ay may pantay na bilang ng mga gilid, kung gayon sa tuwing ang isang naglalakad na mamamayan ay papasok sa bahaging ito ng lupa, maaari siyang lumabas mula roon kasama ang isang bagong tulay. Kaya, lumalabas na hindi ka makakalakad sa lahat ng tulay nang hindi tumawid sa isang tulay nang dalawang beses.

Simula noon, ang isang graph kung saan ang lahat ng vertices ay may pantay na bilang ng mga gilid ay tinatawag na "Eulerian Graph". At ang kumpletong pagtawid ng graph na ito ay nagtataglay ng ipinagmamalaking pangalan ng "Eulerian path".

At pagkatapos nito, ang mga residente ng Koeningsberg ay kailangang maghanap ng iba pang libangan. Isang Chinese mathematician na si Mei-Ku Kuan ang patuloy na niloloko ang sarili sa mga tulay na ito. At ang sumusunod na tanong ay bumagabag sa kanya:

Kung imposibleng gumawa ng ruta upang ang bawat tulay ay tumawid nang eksaktong isang beses, kung gayon kung ano ang pinakamababang bilang ng karagdagang mga tawiran sa tulay na dapat gawin upang makumpleto ang detour.

At ito ay halos kapareho sa problemang kinakaharap ng mga kartero. Sabihin nating ang bawat vertex ay Mailbox, kung saan kailangan mong ilagay ang mga titik. At, sabihin natin, ang aming mail carrier ay dapat magtapon ng mga titik sa bawat kahon nang hindi gumagawa ng mga hindi kinakailangang paggalaw.

Iminungkahi ni Kuan na isaalang-alang ang muling pagtawid sa isang tulay bilang pagdaragdag ng isa pang gilid sa graph. Ang pagdaragdag ng mga gilid ay dapat magresulta sa lahat ng vertice sa graph na may pantay na bilang ng mga gilid. Ang pamamaraang ito ay karaniwang tinatawag na "Eulerianization" ng graph. At pagkatapos na ang graph ay "Eulerianized," maaari tayong bumuo ng isang Euler path sa kahabaan nito.

At bilang parangal kay Kuan, ang problemang ito ay tinawag na "problema ng postman ng Tsino."

Pagkalipas ng ilang taon, mayroon pa ring mga bores na naging interesado sa kung ano ang mangyayari kung posible na maglakad sa mga gilid ng graph lamang sa isang direksyon. Ito ay lumalabas na isang problemang katulad ng sakit ng ulo taxi driver sa New York, nagpaplano ng ruta sa mga one-way na kalye.

Dito ipinakilala namin ang isa pang termino - digraph. O isang direktang graph. Ito ay isang graph na ang mga gilid ay maaari lamang i-intersect sa isang tinukoy na direksyon. Ang mga nakadirekta na gilid ay tinatawag ding "mga arko".

At kung sa kaso ng Euler Path o ang Chinese Postman Problem ay pinaandar namin ang mga arko na humipo sa mga vertices, pagkatapos dito kailangan din nating isaalang-alang ang direksyon ng paggalaw. At hinihiling namin ang bahagi ng "Eulerianization" ng naturang graph upang ang bilang ng mga arko na pumapasok sa isang vertex ay katumbas ng bilang ng mga papalabas. At binibilang ang bawat papasok na arko bilang "+1" at papalabas na arko bilang "-1" maaari nating kalkulahin ang "polarity" ng bawat vertex ng digraph. Halimbawa, ang isang vertex na may dalawang papasok at isang papalabas na arko ay may polarity na "2 - 1 = 1".

Upang ma-Eulerize ang isang digraph, kailangan nating gumuhit ng mga arko sa pagitan ng positibo at negatibong mga vertex. Kailangan namin ang "paglabas ng gabi" na ito ng bilang ng mga papasok at papalabas na arko para sa parehong dahilan kung bakit nakamit namin ang pantay na bilang ng mga gilid sa isang hindi nakadirekta na graph - ang sinumang bisita sa isang vertex ng graph ay dapat na makaalis dito.

Ano ang kinalaman ng pagsubok dito?

Ipagpalagay natin na ang tester ay may modelo ng gawi ng system na sinusuri. Ipagpalagay din natin na ang modelong ito ay mukhang isang digraph, kung saan ang mga vertices ay kumakatawan sa estado ng system, at ang mga arko ay mga aksyon na maaaring gawin ng tester upang baguhin ang estado ng system.

Ang unang bagay na gustong gawin ng isang tester ay isagawa ang lahat ng posibleng pagkilos sa system na sinusuri. Ngunit paano natin ito magagawa nang epektibo? Pagkatapos ay isang matalinong tester ang nag-isip ng isang palaisipan tungkol sa isang taxi driver mula sa New York, na bahagyang nakabalatkayo. At dahil mayroon na tayong modelo ng system na sinusuri sa anyo ng isang graph, kailangan lang nating ilapat dito ang isang angkop na traversal algorithm, na maaaring awtomatikong mabuo.

Sa kabilang banda, ang pagsasagawa ng lahat ng posibleng aksyon ay mabuti, ngunit kahit na ang pinakamakitid na pag-iisip na tagapamahala ng pagsubok ay nauunawaan na ito ay karaniwang "saklaw ng estado" sa mga tuntunin ng pagsusuri sa raw code. Ngunit ang mga multiplier ay may isang hindi kasiya-siyang pag-aari - sila, bilang panuntunan, ay may maraming "susunod" na estado para sa bawat tuktok. Ano ang dapat nating gawin kung gusto nating subukan ang lahat ng posibleng kumbinasyon ng mga aksyon? Ang mga solusyon sa mga problema tulad ng problema sa Chinese Postman ay hindi angkop dahil ginagarantiyahan lamang nila ang pagbisita sa bawat arko, ngunit hindi binibisita ang lahat ng posibleng kumbinasyon ng mga arko.

Ang pamamaraang ito ay aktibong ginamit para sa pagsubok ng mga may hangganang makina ng estado. Bukod dito, natural na sumusunod ang kinakailangang ito mula sa combinatorial test design technique na tinatawag na "all pairs".

Isang solusyon ang iminungkahi ng isang partikular na de Bruijn. Mukhang ganito ang algorithm:

• Gumuhit kami ng graph sa gilid, kung saan ang bawat gilid ng orihinal na graph ay isang vertex.
• Kung saan sa orihinal na graph na arc "1" ay pumapasok sa vertex kung saan lumabas ang arc "2", gumuhit kami ng arc sa bagong likhang graph mula sa vertex "1" hanggang sa vertex "2".
• I-Eulerize natin ang resultang graph.
• Gumuhit tayo ng Euler path sa graph na ito.

Sa prinsipyo, hindi ka maaaring mag-abala at gumawa lamang ng isang random na traversal ng graph. Ang kapansin-pansin ay ang diskarte na ito ay medyo lumalaban sa "pesticide paradox." Sa kabilang banda, ang anumang mas kumplikado o mas kumplikadong aplikasyon ay may medyo malawak na graph ng mga estado, kung saan maaari kang gumugol ng maraming oras bago makakuha ng hindi bababa sa ilang saklaw na may "random na paglalakad".

Magsusulat ako sa ibang pagkakataon tungkol sa kung bakit idinagdag ang Markov Chains dito, at kung paano karaniwang nalutas ang parallelization ng naturang mga pagsubok. Sa ngayon, ibubuod natin nang maikli.

Kabuuan

Ang mga modelo ay mahusay na paraan representasyon at pag-unawa sa application na nasa ilalim ng pagsubok, ngunit binibigyan din nila kami ng medyo simpleng paraan upang i-update ang mga pagsubok at makasabay sa patuloy na umuusbong na application.

Maaari naming isaalang-alang ang pagsubok ng aplikasyon bilang pagtawid sa isang graph na binuo batay sa modelo ng aplikasyon. Sa turn, ang Graph Theory ay nagbibigay ng sapat na mga tool upang magamit ang impormasyon tungkol sa pag-uugali ng system na inilarawan sa modelo upang makabuo ng mga bagong makikinang na pagsubok.

At, dahil pinapayagan kami ng Graph Theory na direktang magtrabaho kasama ang modelo:

• Ang mga bagong lakad ay maaaring awtomatikong mabuo kapag nagbago ang modelo
• Madali at natural na mababago ang aming mga pagsubok sa loob ng parehong modelo
• Ang iba't ibang mga algorithm ng traversal ay maaaring umangkop sa iba't ibang mga pangangailangan sa pagsubok
• Ang mga resultang bypass algorithm ay madaling magamit muli sa isang ganap na bagong kapaligiran

Pagsubok sa mga serbisyo sa web

Karamihan Ang pinakamahusay na paraan suriin kung nasubukan namin nang mabuti ang produkto - pag-aralan ang mga napalampas na depekto. Ang mga naranasan ng aming mga user, tagapagpatupad, at negosyo. Batay sa kanila, marami kang masusuri: kung ano ang hindi pa namin nasuri nang husto, anong mga bahagi ng produkto ang dapat bigyan ng higit na pansin, kung ano ang kabuuang porsyento ng mga pagtanggal at kung ano ang dinamika ng mga pagbabago nito. Sa panukat na ito (marahil ang pinakakaraniwan sa pagsubok), maayos ang lahat, ngunit... Nang inilabas namin ang produkto at nalaman ang tungkol sa mga hindi nakuhang error, maaaring huli na: isang galit na artikulo tungkol sa amin ang lumabas sa Habré, ang mga kakumpitensya ay mabilis na kumakalat ng kritisismo, nawalan kami ng tiwala sa amin ng mga customer, hindi nasisiyahan ang pamamahala.

Upang maiwasang mangyari ito, karaniwan naming sinusubukang suriin ang kalidad ng pagsubok nang maaga, bago ilabas: gaano kahusay at lubusan namin sinusubok ang produkto? Anong mga lugar ang kulang sa pansin, nasaan ang mga pangunahing panganib, ano ang pag-unlad? At para masagot ang lahat ng tanong na ito, sinusuri namin ang saklaw ng pagsubok.

Bakit magsusuri?

Ang anumang sukatan ng pagsusuri ay isang pag-aaksaya ng oras. Sa oras na ito, maaari kang sumubok, gumawa ng mga bug, at maghanda ng mga autotest. Anong uri ng mahiwagang benepisyo ang nakukuha natin mula sa mga sukatan ng saklaw ng pagsubok upang maisakripisyo ang oras ng pagsubok?

1. Paghahanap ng iyong mga mahihinang lugar. Natural, kailangan ba natin ito? hindi lamang upang magdalamhati, ngunit upang malaman kung saan kailangan ang mga pagpapabuti. Anong mga functional na lugar ang hindi sakop ng mga pagsubok? Ano ang hindi natin nasusuri? Nasaan ang pinakamalaking panganib ng mga nawawalang error?
2. Bihirang makakuha kami ng 100% batay sa aming mga resulta ng pagtatasa sa saklaw. Ano ang dapat pagbutihin? Saan pupunta? Ano ang porsyento ngayon? Paano natin ito madadagdagan sa anumang gawain? Gaano kabilis tayo makakarating sa 100? Ang lahat ng mga tanong na ito ay nagdadala ng transparency at kalinawan sa aming proseso., at ang mga sagot sa mga ito ay ibinibigay ng pagtatasa sa saklaw.
3. Pokus ng atensyon. Sabihin nating may 50 iba't ibang produkto ang aming produkto mga functional zone. May lumabas na bagong bersyon, at sinimulan naming subukan ang 1 sa mga ito, at nakita namin ang mga typo, at mga button na nakapaglipat ng ilang pixel, at iba pang maliliit na bagay... At ngayon, tapos na ang oras ng pagsubok, at nasubok ang functionality na ito sa detalye... At ang iba pang 50? Ang pagtatasa ng saklaw ay nagbibigay-daan sa amin na unahin ang mga gawain batay sa kasalukuyang mga katotohanan at mga deadline.

Paano magsusuri?

Bago ipatupad ang anumang sukatan, mahalagang magpasya kung paano mo ito gagamitin. Magsimula sa pamamagitan ng pagsagot nang eksakto sa tanong na ito - malamang, mauunawaan mo kaagad kung paano pinakamahusay na kalkulahin ito. At sa artikulong ito ay ibabahagi ko lamang ang ilang mga halimbawa at ang aking karanasan kung paano ito magagawa. Hindi para bulag na kopyahin ang mga solusyon - ngunit upang ang iyong imahinasyon ay batay sa karanasang ito, na nag-iisip sa pamamagitan ng isang solusyon na perpekto para sa iyo.

Sinusuri namin ang saklaw ng mga kinakailangan sa pamamagitan ng mga pagsubok

Sabihin nating mayroon kang mga analyst sa iyong koponan, at hindi sila nag-aaksaya ng kanilang oras. Batay sa mga resulta ng kanilang trabaho, ang mga kinakailangan ay nilikha sa RMS (Requirements Management System) - HP QC, MS TFS, IBM Doors, Jira (na may mga karagdagang plugin), atbp. Ipinasok nila ang mga kinakailangan sa sistemang ito na nakakatugon sa mga kinakailangan sa kinakailangan (pasensya na sa tautolohiya). Ang mga kinakailangang ito ay atomic, traceable, partikular... Sa pangkalahatan, mainam na mga kondisyon para sa pagsubok. Ano ang maaari nating gawin sa kasong ito? Kapag gumagamit ng naka-script na diskarte, i-link ang mga kinakailangan at pagsubok. Nagpapatakbo kami ng mga pagsubok sa parehong system, gumagawa ng koneksyon sa pagsubok ng kinakailangan, at anumang oras ay makakakita kami ng ulat kung aling mga kinakailangan ang may mga pagsubok, alin ang wala, kapag naipasa ang mga pagsusulit na ito, at kung ano ang resulta.
Nakakakuha kami ng mapa ng saklaw, sinasaklaw namin ang lahat ng hindi natatakpan na mga kinakailangan, lahat ay masaya at nasisiyahan, hindi namin pinalampas ang anumang mga pagkakamali...

Okay, bumalik tayo mula sa langit sa lupa. Malamang, wala kang mga detalyadong kinakailangan, hindi atomic ang mga ito, ang ilan sa mga kinakailangan ay ganap na nawala, at wala kang oras upang idokumento ang bawat pagsubok, o hindi bababa sa bawat segundo. Maaari kang mawalan ng pag-asa at umiyak, o maaari mong aminin na ang pagsubok ay isang compensatory na proseso, at ang mas masahol pa sa analytics at pag-unlad sa proyekto, mas kailangan nating subukan ang ating sarili at bayaran ang mga problema ng iba pang mga kalahok sa proseso. Tingnan natin ang mga problema nang hiwalay.

Problema: Ang mga kinakailangan ay hindi atomic.

Ang mga analyst ay minsan din nagkakamali sa kanilang mga ulo, at kadalasan ito ay puno ng mga problema sa buong proyekto. Halimbawa, gumagawa ka ng isang text editor, at maaaring mayroon kang dalawang kinakailangan sa iyong system (bukod sa iba pa): "dapat suportahan ang pag-format ng html" at "kapag nagbubukas ng isang file ng hindi sinusuportahang format, isang pop-up window na may tanong dapat lumitaw." Ilang pagsubok ang kinakailangan para sa pangunahing pag-verify ng unang kinakailangan? At para sa ika-2? Ang pagkakaiba sa mga sagot ay malamang na mga isang daang beses!!! Hindi namin masasabi na kung mayroong hindi bababa sa 1 pagsubok para sa unang kinakailangan, ito ay sapat na - ngunit para sa ika-2, malamang, ito ay.

Kaya, ang pagkakaroon ng pagsubok para sa isang kinakailangan ay hindi ginagarantiyahan sa amin ang anumang bagay! Ano ang ibig sabihin ng aming mga istatistika sa saklaw sa kasong ito? Halos wala! Kailangan nating magdesisyon!

1. Sa kasong ito, maaaring alisin ang awtomatikong pagkalkula ng saklaw ng mga kinakailangan sa pamamagitan ng mga pagsubok - hindi pa rin ito nagdadala ng anumang semantic load.
2. Para sa bawat pangangailangan, simula sa pinakamataas na priyoridad, naghahanda kami ng mga pagsubok. Kapag naghahanda, sinusuri namin kung anong mga pagsubok ang kakailanganin ng kinakailangang ito, ilan ang magiging sapat? Nagsasagawa kami ng isang ganap na pagsusuri sa pagsusulit, at huwag ipagwalang-bahala ito "may isang pagsubok, mabuti, okay."
3. Depende sa system na ginamit, nag-e-export/nag-upload kami ng mga pagsubok on demand at... sinusubok ang mga pagsubok na ito! Sapat na ba sila? Sa isip, siyempre, ang naturang pagsubok ay dapat isagawa kasama ng isang analyst at developer ng functionality na ito. I-print ang mga pagsusulit, ikulong ang iyong mga kasamahan sa isang silid ng pagpupulong, at huwag silang pabayaan hangga't hindi nila sinasabing “oo, sapat na ang mga pagsusulit na ito” (nangyayari lamang ito nang may nakasulat na kasunduan, kapag sinabing lumagda ang mga salitang ito, kahit na wala pagsusuri sa mga pagsusulit. Sa panahon ng oral na talakayan, ang iyong mga kasamahan ay magbubuhos ng kritisismo, hindi nasagot na mga pagsusulit, hindi nauunawaang mga kinakailangan, atbp. - hindi ito palaging kaaya-aya, ngunit ito ay lubhang kapaki-pakinabang para sa pagsubok!)
4. Matapos i-finalize ang mga pagsusulit ayon sa kinakailangan at sumang-ayon sa kanilang pagkakumpleto, ang kinakailangang ito ay maaaring italaga ang katayuan na "saklaw ng mga pagsubok" sa system. Ang impormasyong ito ay mangangahulugan ng higit pa kaysa sa "mayroong hindi bababa sa 1 pagsubok dito."

Siyempre, ang ganitong proseso ng pag-apruba ay nangangailangan ng maraming mapagkukunan at oras, lalo na sa una, bago makakuha ng pagsasanay. Samakatuwid, isakatuparan lamang ang mataas na priyoridad na mga kinakailangan at mga bagong pagpapahusay. Sa paglipas ng panahon, hihigpitan mo ang natitirang mga kinakailangan, at lahat ay magiging masaya! Pero... paano kung wala talagang requirements?

Problema: walang mga kinakailangan sa lahat.

Wala sila sa proyekto, napag-usapan nang pasalita, ginagawa ng lahat ang gusto/kaya niya at ayon sa pagkakaintindi niya. Sinusubukan namin ito sa parehong paraan. Bilang isang resulta, nakakakuha kami ng isang malaking bilang ng mga problema hindi lamang sa pagsubok at pag-unlad, kundi pati na rin sa una ay hindi tamang pagpapatupad ng mga tampok - gusto namin ng isang bagay na ganap na naiiba! Dito maaari kong irekomenda ang opsyon na "tukuyin at idokumento ang mga kinakailangan sa iyong sarili," at ginamit ko pa ang diskarteng ito ng ilang beses sa aking pagsasanay, ngunit sa 99% ng mga kaso walang ganoong mga mapagkukunan sa pangkat ng pagsubok - kaya't gumawa tayo ng maraming hindi gaanong mapagkukunan-intensive na landas:

1. Lumikha ng isang listahan ng tampok. Sami! Sa anyo ng isang sign ng Google, sa format na PBI sa TFS - pumili ng anumang format, hangga't hindi ito isang format ng teksto. Kailangan pa nating mangolekta ng mga status! Sa listahang ito isinasama namin ang lahat ng functional na bahagi ng produkto, at subukang pumili ng isang pangkalahatang antas ng agnas (maaari mong isulat ang mga bagay sa software, o script ng user, o module, o web page, o mga pamamaraan ng API, o mga form ng screen.. .) - hindi lang lahat ng ito nang sabay-sabay! ISANG format ng decomposition, na mas madali at mas nakikita para sa iyo, ay magbibigay-daan sa iyo na hindi makaligtaan ang mahahalagang bagay.
2. Sumasang-ayon kami sa KUMPLETO ng listahang ito kasama ng mga analyst, developer, negosyo, sa loob ng aming team... Subukang gawin ang lahat para hindi mawala ang mahahalagang bahagi ng produkto! Nasa iyo kung gaano kalalim ang pagsusuri. Sa aking pagsasanay, mayroon lamang ilang mga produkto kung saan lumikha kami ng higit sa 100 mga pahina sa talahanayan, at ito ay mga higanteng produkto. Kadalasan, ang 30-50 na linya ay isang matamo na resulta para sa kasunod na maingat na pagproseso. Sa isang maliit na team na walang dedikadong test analyst, mas maraming featurelist na elemento ang magiging napakahirap suportahan.
3. Pagkatapos nito, pumunta kami sa pamamagitan ng mga priyoridad at pinoproseso ang bawat linya ng listahan ng tampok tulad ng sa seksyon ng mga kinakailangan na inilarawan sa itaas. Nagsusulat kami ng mga pagsusulit, tinatalakay, nagkakasundo sa kasapatan. Minarkahan namin ang mga katayuan kung saan ang tampok ay may sapat na mga pagsubok. Nakukuha namin ang katayuan, pag-unlad, at pagpapalawak ng mga pagsubok sa pamamagitan ng pakikipag-ugnayan sa koponan. Masaya ang lahat!

Ngunit... Paano kung ang mga kinakailangan ay pinananatili, ngunit hindi sa isang nasusubaybayang format?

Problema: Hindi masusubaybayan ang mga kinakailangan.

Mayroong isang malaking halaga ng dokumentasyon sa proyekto, ang mga analyst ay nag-type sa bilis na 400 mga character bawat minuto, mayroon kang mga pagtutukoy, mga teknikal na pagtutukoy, mga tagubilin, mga sertipiko (madalas na nangyayari ito sa kahilingan ng customer), at lahat ng ito ay kumikilos bilang mga kinakailangan, at ang lahat ay nasa proyekto sa loob ng mahabang panahon Nalilito kung saan hahanapin kung anong impormasyon?
Inuulit namin ang nakaraang seksyon, tinutulungan ang buong koponan na maging maayos!

1. Lumilikha kami ng isang listahan ng tampok (tingnan sa itaas), ngunit walang detalyadong paglalarawan ng mga kinakailangan.
2. Para sa bawat feature, kinokolekta namin ang mga link sa mga teknikal na detalye, detalye, tagubilin, at iba pang mga dokumento.
3. Pumunta kami sa pamamagitan ng mga priyoridad, naghahanda ng mga pagsusulit, sumasang-ayon sa kanilang pagkakumpleto. Ang lahat ay pareho, sa pamamagitan lamang ng pagsasama-sama ng lahat ng mga dokumento sa isang talahanayan, pinapataas namin ang kadalian ng pag-access sa mga ito, mga transparent na katayuan at pagkakapare-pareho ng mga pagsubok. Sa huli, lahat ay mahusay sa amin at lahat ay masaya!

Ngunit... Hindi nagtagal... Mukhang noong nakaraang linggo, nag-update ang mga analyst ng 4 na magkakaibang mga detalye batay sa mga kahilingan ng customer!!!

Problema: nagbabago ang mga kinakailangan sa lahat ng oras.

Siyempre, mainam na subukan ang ilang uri ng nakapirming sistema, ngunit ang aming mga produkto ay karaniwang nabubuhay. Ang customer ay humiling ng isang bagay, may nagbago sa batas sa labas ng aming produkto, at sa isang lugar ang mga analyst ay nakakita ng isang error sa pagsusuri ng taon bago ang huling... Ang mga kinakailangan ay nabubuhay sa sarili nilang buhay! Anong gagawin?

1. Sabihin nating nakakolekta ka na ng mga link sa mga teknikal na pagtutukoy at pagtutukoy sa anyo ng talahanayan ng listahan ng tampok, PBI, mga kinakailangan, mga tala sa Wiki, atbp. Sabihin nating mayroon ka nang mga pagsubok para sa mga kinakailangang ito. At ngayon, nagbabago ang pangangailangan! Ito ay maaaring mangahulugan ng pagbabago sa RMS, o isang gawain sa TMS (Task Management System), o isang sulat sa koreo. Sa anumang kaso, ito ay humahantong sa parehong kahihinatnan: ang iyong mga pagsusulit ay walang kaugnayan! O maaaring hindi sila nauugnay. Nangangahulugan ito na nangangailangan sila ng pag-update (na sumasaklaw sa lumang bersyon ng produkto na may mga pagsubok kahit papaano ay hindi talaga mabibilang, tama?)
2. Sa featurelist, sa RMS, sa TMS (Test Management System – testrails, sitechco, atbp) na mga pagsusulit ay dapat na kailangan at agad na mamarkahan bilang walang kaugnayan! Sa HP QC o MS TFS, maaari itong awtomatikong gawin kapag nag-a-update ng mga kinakailangan, ngunit sa isang Google plate o wiki kakailanganin mong ipasok ito nang manu-mano. Ngunit dapat mong makita kaagad: ang mga pagsusulit ay hindi nauugnay! Nangangahulugan ito na nahaharap tayo sa isang kumpletong paulit-ulit na landas: i-update, muling patakbuhin ang pagsusuri sa pagsubok, muling isulat ang mga pagsubok, sumang-ayon sa mga pagbabago, at pagkatapos lamang na markahan muli ang tampok/kinakailangan bilang "saklaw ng mga pagsubok."

Sa kasong ito, nakukuha namin ang lahat ng benepisyo ng pagsusuri sa saklaw ng pagsubok, at sa dynamics! Masaya ang lahat!!! Pero…
Ngunit gumugol ka ng napakaraming oras sa pagtatrabaho sa mga kinakailangan na wala ka na ngayong sapat na oras para sa alinman sa pagsubok o dokumento ng mga pagsubok. Sa palagay ko (at may puwang para sa pagtatalo sa relihiyon dito!) Ang mga kinakailangan ay mas mahalaga kaysa sa mga pagsubok, at mas mabuti sa ganoong paraan! Hindi bababa sa sila ay ok, at ang buong koponan ay may kamalayan, at ginagawa ng mga developer kung ano mismo ang kinakailangan. PERO WALA NA LANG PANAHON PARA SA PAGDOKUMENTO NG MGA PAGSUSULIT!

Problema: Walang sapat na oras upang idokumento ang mga pagsusulit.

Sa katunayan, ang pinagmulan ng problemang ito ay maaaring hindi lamang kakulangan ng oras, kundi pati na rin ang iyong napakamalay na pagpili na huwag idokumento ang mga ito (hindi namin gusto ang mga ito, iniiwasan namin ang epekto ng isang pestisidyo, ang produkto ay madalas na nagbabago, atbp. .). Ngunit paano suriin ang saklaw ng pagsubok sa kasong ito?

1. Kailangan mo pa rin ang mga kinakailangan, alinman bilang buong mga kinakailangan o bilang isang listahan ng tampok, kaya ang ilan sa mga seksyong inilarawan sa itaas, depende sa gawain ng mga analyst sa proyekto, ay kakailanganin pa rin. Nakuha ba ang mga kinakailangan/featurelist?
2. Inilalarawan namin at pasalitang sumasang-ayon nang maikli sa diskarte sa pagsubok, nang hindi nagdodokumento ng mga partikular na pagsubok! Ang diskarte na ito ay maaaring tukuyin sa isang haligi ng talahanayan, sa isang pahina ng wiki, o sa isang kinakailangan sa RMS, at muli ay dapat na napagkasunduan. Iba ang pagsubok ng diskarteng ito, ngunit malalaman mo: Kailan ito huling sinubukan at sa anong diskarte? At ito, nakikita mo, ay hindi rin masama! At lahat ay magiging masaya.

Pero… Ano pang "ngunit"? alin???

Sabihin, malalagpasan natin ang lahat, at nawa'y makasama natin sila kalidad ng mga produkto!

Gennadii_M Marso 17, 2016 nang 2:52 pm

Pagsubok. Pangunahing teorya

• Pagsubok sa mga IT system

• Pagtuturo

Kamakailan ay nagkaroon ako ng panayam sa Middle QA para sa isang proyekto na malinaw na lumampas sa aking mga kakayahan. Gumugol ako ng maraming oras sa isang bagay na hindi ko alam at kaunting oras na inuulit ang isang simpleng teorya, ngunit walang kabuluhan.

Nasa ibaba ang mga pangunahing dapat suriin bago ang pakikipanayam para sa Trainee at Junior: Definition of Testing, kalidad, pagpapatunay/pagpatunay, mga layunin, yugto, plano sa pagsubok, mga punto ng plano sa pagsubok, disenyo ng pagsubok, mga diskarte sa disenyo ng pagsubok, traceability matrix, test case, checklist, depekto, error / depekto / pagkabigo, ulat ng bug, kalubhaan kumpara sa priyoridad, mga antas ng pagsubok, mga uri / uri, integration testing approach, mga prinsipyo ng pagsubok, static at dynamic na pagsubok, exploratory / ad-hoc na pagsubok, mga kinakailangan, ikot ng buhay ng bug, mga yugto ng pagbuo ng software, talahanayan ng desisyon, qa/qc/test engineer, diagram ng koneksyon.

Lahat ng mga komento, pagwawasto at mga karagdagan ay malugod na tinatanggap.

Pagsubok software - pagsuri sa mga sulat sa pagitan ng aktwal at inaasahang pag-uugali ng programa, na isinasagawa sa isang may hangganan na hanay ng mga pagsubok na pinili sa isang tiyak na paraan. Sa mas malawak na kahulugan, ang pagsubok ay isa sa mga diskarte sa pagkontrol sa kalidad na kinabibilangan ng mga aktibidad ng pagpaplano ng trabaho (Test Management), disenyo ng pagsubok (Test Design), pagpapatupad ng pagsubok (Test Execution) at pagsusuri ng mga resulta (Test Analysis).

Kalidad ng Software ay isang hanay ng mga katangian ng software na nauugnay sa kakayahan nitong matugunan ang mga nasabi at inaasahang pangangailangan.

Pagpapatunay ay ang proseso ng pagsusuri ng isang sistema o mga bahagi nito upang matukoy kung ang mga resulta ng kasalukuyang yugto ng pag-unlad ay nakakatugon sa mga kondisyong nabuo sa simula ng yugtong ito. Yung. kung ang aming mga layunin, deadline, at mga gawain sa pagbuo ng proyekto na tinukoy sa simula ng kasalukuyang yugto ay natutugunan.
Pagpapatunay- ito ay isang pagpapasiya kung ang software na binuo ay nakakatugon sa mga inaasahan at pangangailangan ng gumagamit, at mga kinakailangan ng system.
Makakahanap ka rin ng isa pang interpretasyon:
Ang proseso ng pagtatasa sa pagsunod ng isang produkto sa mga tahasang kinakailangan (mga detalye) ay pag-verify, habang ang pagtatasa sa pagsunod ng produkto sa mga inaasahan at kinakailangan ng user ay pagpapatunay. Madalas mo ring mahahanap ang sumusunod na kahulugan ng mga konseptong ito:
Pagpapatunay - ‘ito ba ang tamang detalye?’.
Pagpapatunay - ‘tama ba ang sistema sa espesipikasyon?’.

Mga Layunin sa Pagsubok
Dagdagan ang posibilidad na ang application na inilaan para sa pagsubok ay gagana nang tama sa lahat ng pagkakataon.
Palakihin ang posibilidad na matugunan ng sinusubok na aplikasyon ang lahat ng inilarawang kinakailangan.
Nagbibigay ng up-to-date na impormasyon tungkol sa kasalukuyang estado ng produkto.

Mga yugto ng pagsubok:
1. Pagsusuri ng produkto
2. Paggawa gamit ang mga kinakailangan
3. Pagbuo ng diskarte sa pagsubok
at pagpaplano ng mga pamamaraan sa pagkontrol sa kalidad
4. Paglikha ng dokumentasyon ng pagsusulit
5. Pagsubok sa prototype
6. Pangunahing pagsubok
7. Pagpapatatag
8. Operasyon

Plano ng Pagsubok- ito ay isang dokumento na naglalarawan sa buong saklaw ng gawain sa pagsubok, simula sa isang paglalarawan ng bagay, diskarte, iskedyul, pamantayan para sa pagsisimula at pagtatapos ng pagsubok, hanggang sa kagamitan na kinakailangan sa proseso, espesyal na kaalaman, pati na rin ang pagtatasa ng panganib na may mga opsyon para sa kanilang resolusyon.
Sagutin ang mga tanong:
Ano ang dapat masuri?
Ano ang susuriin mo?
Paano mo susuriin?
Kailan ka magsusulit?
Pamantayan para sa pagsisimula ng pagsubok.
Pamantayan sa pagkumpleto ng pagsusulit.

Mga pangunahing punto ng plano ng pagsubok
Inililista ng pamantayan ng IEEE 829 ang mga punto na dapat (maaaring) binubuo ng isang plano sa pagsubok:
a) Tagatukoy ng plano ng pagsubok;
b) Panimula;
c) Mga item sa pagsubok;
d) Mga tampok na susuriin;
e) Mga tampok na hindi susuriin;
f) Pagdulog;
g) Pamantayan sa pagpasa/pagkabigo ng item;
h) Pamantayan sa pagsususpinde at mga kinakailangan sa pagpapatuloy;
i) Mga maihahatid na pagsubok;
j) Mga gawain sa pagsubok;
k) Pangangailangan sa kapaligiran;
l) Mga Pananagutan;
m) Mga pangangailangan ng tauhan at pagsasanay;
n) Iskedyul;
o) Mga panganib at maaaring mangyari;
p) Mga Pag-apruba.

Pagsubok sa disenyo– ito ang yugto ng proseso ng pagsubok ng software kung saan ang mga senaryo ng pagsubok (mga kaso ng pagsubok) ay idinisenyo at nilikha alinsunod sa naunang tinukoy na pamantayan sa kalidad at mga layunin sa pagsubok.
Mga tungkulin na responsable para sa disenyo ng pagsubok:
Test analyst - tinutukoy ang "ANO ang susuriin?"
Taga-disenyo ng pagsubok - tinutukoy ang "PAANO magsusuri?"

Subukan ang mga diskarte sa disenyo

Equivalence Partitioning (EP). Bilang halimbawa, kung mayroon kang isang hanay ng mga wastong halaga mula 1 hanggang 10, dapat kang pumili ng isang tamang halaga sa loob ng pagitan, sabihin nating 5, at isang maling halaga sa labas ng pagitan, 0.

Pagsusuri sa Halaga ng Hangganan (Boundary Value Analysis (BVA). Kung gagawin natin ang halimbawa sa itaas, pipiliin natin ang pinakamababa at pinakamataas na limitasyon (1 at 10) bilang mga halaga para sa positibong pagsubok, at mga halagang mas malaki at mas mababa kaysa sa mga limitasyon (0 at 11). Maaaring ilapat ang pagsusuri sa halaga ng hangganan sa mga field, talaan, file, o anumang uri ng pinaghihigpitang entity.

Sanhi/Epekto - CE. Ito ay, bilang panuntunan, pagpasok ng mga kumbinasyon ng mga kundisyon (mga dahilan) upang makakuha ng tugon mula sa system (Epekto). Halimbawa, sinusubukan mo ang kakayahang magdagdag ng customer gamit ang isang partikular na display. Upang gawin ito, kakailanganin mong magpasok ng ilang mga patlang tulad ng "Pangalan", "Address", "Numero ng Telepono" at pagkatapos ay i-click ang pindutang "Magdagdag" - ito ay "Dahilan". Matapos i-click ang pindutang "Magdagdag", idinagdag ng system ang kliyente sa database at ipinapakita ang kanyang numero sa screen - ito ay "Pagsisiyasat".

Error Guessing (EG). Ito ay kapag ginagamit ng tester ang kanyang kaalaman sa system at kakayahang bigyang-kahulugan ang detalye upang "hulaan" sa ilalim ng kung anong mga kundisyon ng input ang maaaring magdulot ng error ang system. Halimbawa, ang detalye ay nagsasabing "dapat magpasok ang user ng code." Iisipin ng tester: "Paano kung hindi ko ilagay ang code?", "Paano kung maling code ang inilagay ko? ", at iba pa. Ito ang hula ng pagkakamali.

Exhaustive Testing (ET)- ito ay isang matinding kaso. Sa loob ng diskarteng ito, dapat mong subukan ang lahat ng posibleng kumbinasyon ng mga halaga ng pag-input, at sa prinsipyo, ito ay dapat mahanap ang lahat ng mga problema. Sa pagsasagawa, ang paggamit ng paraang ito ay hindi posible dahil sa marami mga halaga ng input.

Pairwise Testing ay isang pamamaraan para sa pagbuo ng mga set ng data ng pagsubok. Ang kakanyahan ay maaaring buuin, halimbawa, tulad nito: ang pagbuo ng mga set ng data kung saan ang bawat nasubok na halaga ng bawat isa sa nasubok na mga parameter ay pinagsama nang hindi bababa sa isang beses sa bawat nasubok na halaga ng lahat ng iba pang nasubok na mga parameter.

Sabihin nating ang ilang halaga (buwis) para sa isang tao ay kinakalkula batay sa kanyang kasarian, edad at pagkakaroon ng mga bata - nakakakuha kami ng tatlong mga parameter ng input, para sa bawat isa kung saan pipili kami ng mga halaga sa ilang paraan para sa pagsubok. Halimbawa: kasarian - lalaki o babae; edad - hanggang 25, mula 25 hanggang 60, higit sa 60; pagkakaroon ng mga anak - oo o hindi. Upang suriin ang kawastuhan ng mga kalkulasyon, maaari mong, siyempre, dumaan sa lahat ng mga kumbinasyon ng mga halaga ng lahat ng mga parameter:

№	sahig	edad	mga bata
1	lalaki	hanggang 25	walang anak
2	babae	hanggang 25	walang anak
3	lalaki	25-60	walang anak
4	babae	25-60	walang anak
5	lalaki	mahigit 60	walang anak
6	babae	mahigit 60	walang anak
7	lalaki	hanggang 25	Mayroon ka bang mga anak
8	babae	hanggang 25	Mayroon ka bang mga anak
9	lalaki	25-60	Mayroon ka bang mga anak
10	babae	25-60	Mayroon ka bang mga anak
11	lalaki	mahigit 60	Mayroon ka bang mga anak
12	babae	mahigit 60	Mayroon ka bang mga anak

O maaari kang magpasya na hindi namin gusto ang mga kumbinasyon ng lahat ng mga halaga ng parameter sa lahat, ngunit nais lamang na tiyaking suriin namin ang lahat ng mga natatanging pares ng mga halaga ng parameter. Iyon ay, halimbawa, sa mga tuntunin ng mga parameter ng kasarian at edad, gusto naming tiyakin na tumpak naming suriin ang isang lalaki sa ilalim ng 25, isang lalaki sa pagitan ng 25 at 60, isang lalaki pagkatapos ng 60, pati na rin ang isang babae sa ilalim ng 25, isang babae sa pagitan ng 25 at 60, at iba pa. babae pagkatapos ng 60. At eksaktong pareho para sa lahat ng iba pang mga pares ng mga parameter. At sa ganitong paraan makakakuha tayo ng mas maliliit na hanay ng mga halaga (mayroon silang lahat ng mga pares ng mga halaga, bagaman ang ilan ay dalawang beses):

№	sahig	edad	mga bata
1	lalaki	hanggang 25	walang anak
2	babae	hanggang 25	Mayroon ka bang mga anak
3	lalaki	25-60	Mayroon ka bang mga anak
4	babae	25-60	walang anak
5	lalaki	mahigit 60	walang anak
6	babae	mahigit 60	Mayroon ka bang mga anak

Ang diskarteng ito ay halos ang esensya ng pairwise testing technique - hindi namin sinusubok ang lahat ng kumbinasyon ng lahat ng value, ngunit sinusubok namin ang lahat ng pares ng value.

Traceability matrix - Matrix ng pagsunod sa mga kinakailangan ay isang dalawang-dimensional na talahanayan na naglalaman ng mga sulat mga kinakailangan sa pagganap(mga kinakailangan sa paggana) ng produkto at mga inihandang sitwasyon sa pagsubok (mga kaso ng pagsubok). Ang mga heading ng column ng talahanayan ay naglalaman ng mga kinakailangan, at ang mga heading ng row ay naglalaman ng mga sitwasyon ng pagsubok. Sa intersection ay may marka na nagpapahiwatig na ang pangangailangan ng kasalukuyang column ay sakop ng test case ng kasalukuyang row.
Ang matrix ng pagsunod sa mga kinakailangan ay ginagamit ng mga inhinyero ng QA upang patunayan ang saklaw ng pagsubok ng produkto. Ang MCT ay isang mahalagang bahagi ng plano ng pagsubok.

Test Case ay isang artifact na naglalarawan ng isang hanay ng mga hakbang, partikular na kundisyon at parameter na kinakailangan upang suriin ang pagpapatupad ng function na nasa ilalim ng pagsubok o bahagi nito.
Halimbawa:
Pagkilos Inaasahang Resulta Resulta ng Pagsubok
(pumasa/nabigo/na-block)
Buksan ang pahina “login” Login page ay binuksan Nakapasa

Ang bawat test case ay dapat may 3 bahagi:
PreConditions Isang listahan ng mga aksyon na nagdadala sa system sa isang kondisyon na angkop para sa pangunahing pagsubok. O isang listahan ng mga kondisyon, ang katuparan nito ay nagpapahiwatig na ang sistema ay nasa isang estado na angkop para sa pagsasagawa ng pangunahing pagsubok.
Paglalarawan ng Kaso ng Pagsubok Isang listahan ng mga aksyon na naglilipat ng system mula sa isang estado patungo sa isa pa upang makakuha ng resulta batay sa kung saan maaari itong tapusin na ang pagpapatupad ay nakakatugon sa mga kinakailangan
PostConditions Listahan ng mga aksyon na naglilipat ng system sa paunang estado (estado bago ang pagsubok - paunang estado)
Mga Uri ng Test Script:
Ang mga kaso ng pagsubok ay nahahati ayon sa inaasahang resulta sa positibo at negatibo:
Ang isang positibong kaso ng pagsubok ay gumagamit lamang ng tamang data at nagpapatunay na ang application ay wastong naisakatuparan ang tinatawag na function.
Gumagana ang isang negatibong kaso ng pagsubok sa parehong tama at maling data (kahit 1 maling parameter) at naglalayong suriin ang mga pambihirang sitwasyon (nati-trigger ang mga validator), at tingnan din kung ang function na tinatawag ng application ay hindi naisakatuparan kapag na-trigger ang validator.

Check list ay isang dokumento na naglalarawan kung ano ang dapat subukan. Kasabay nito, ang checklist ay maaaring may ganap na magkakaibang antas ng detalye. Gaano magiging detalyado ang checklist ay depende sa mga kinakailangan sa pag-uulat, ang antas ng kaalaman sa produkto ng mga empleyado at ang pagiging kumplikado ng produkto.
Bilang isang patakaran, ang isang checklist ay naglalaman lamang ng mga aksyon (mga hakbang), nang walang inaasahang resulta. Ang checklist ay hindi gaanong pormal kaysa sa test script. Angkop na gamitin ito kapag ang mga test script ay kalabisan. Ang mga checklist ay nauugnay din sa mga nababaluktot na diskarte sa pagsubok.

Depekto (aka bug) ay isang pagkakaiba sa pagitan ng aktwal na resulta ng pagpapatupad ng programa at ang inaasahang resulta. Natuklasan ang mga depekto sa yugto ng pagsubok ng software, kapag inihambing ng tester ang mga resulta ng programa (bahagi o disenyo) sa inaasahang resulta na inilarawan sa detalye ng mga kinakailangan.

Error- error ng gumagamit, iyon ay, sinusubukan niyang gamitin ang programa sa ibang paraan.
Halimbawa - naglalagay ng mga titik sa mga patlang kung saan kailangan mong maglagay ng mga numero (edad, dami ng mga kalakal, atbp.).
Ang isang de-kalidad na programa ay nagbibigay para sa mga ganitong sitwasyon at nagpapakita ng mensahe ng error na may pulang krus.
Bug (depekto)- isang error ng programmer (o taga-disenyo o sinumang nakikibahagi sa pag-unlad), iyon ay, kapag ang isang bagay sa programa ay hindi napupunta gaya ng binalak at ang programa ay nawalan ng kontrol. Halimbawa, kapag ang input ng user ay hindi kontrolado sa anumang paraan, bilang resulta, ang maling data ay nagdudulot ng mga pag-crash o iba pang "kagalakan" sa pagpapatakbo ng programa. O ang programa ay binuo sa loob sa paraang sa simula ay hindi ito tumutugma sa kung ano ang inaasahan dito.
Kabiguan- isang pagkabigo (at hindi kinakailangang isang hardware) sa pagpapatakbo ng isang bahagi, isang buong programa o sistema. Ibig sabihin, may mga depekto na humahantong sa mga pagkabigo (A defect caused the failure) at may mga hindi. Mga depekto sa UI halimbawa. Ngunit ang isang pagkabigo ng hardware na walang kinalaman sa software ay isang pagkabigo din.

Ulat ng Bug ay isang dokumento na naglalarawan sa sitwasyon o pagkakasunud-sunod ng mga aksyon na humantong sa hindi tamang operasyon ng pagsubok na bagay, na nagpapahiwatig ng mga dahilan at ang inaasahang resulta.
Isang sumbrero
Maikling paglalarawan (Buod) Isang maikling paglalarawan ng problema, malinaw na nagpapahiwatig ng sanhi at uri ng sitwasyon ng error.
Pangalan ng Proyekto ng proyektong sinusuri
Application Component (Component) Ang pangalan ng bahagi o function ng produktong sinusuri
Numero ng bersyon Ang bersyon kung saan natagpuan ang error
Kalubhaan Ang pinakakaraniwang limang antas na sistema para sa pag-grado sa kalubhaan ng isang depekto ay:
S1 Blocker
S2 Kritikal
S3 Major
S4 Minor
S5 walang kuwenta
Priyoridad Ang priyoridad ng depekto:
P1 Mataas
P2 Katamtaman
P3 Mababa
Status Ang status ng bug. Depende sa pamamaraang ginamit at sa ikot ng buhay ng bug (bug workflow at life cycle)

May-akda (May-akda) Tagalikha ng ulat ng bug
Itinalaga Sa Ang pangalan ng taong itinalaga sa problema.
Kapaligiran
OS / Service Pack, atbp. / Browser + bersyon /… Impormasyon tungkol sa kapaligiran kung saan natagpuan ang bug: operating system, service pack, para sa pagsubok sa WEB - pangalan at bersyon ng browser, atbp.
…
Paglalarawan
Mga Hakbang sa Pag-reproduce Mga Hakbang kung saan madali mong mai-reproduce ang sitwasyon na humantong sa error.
Aktwal na Resulta Ang resultang nakuha pagkatapos dumaan sa mga hakbang sa pagpaparami
Inaasahang Resulta Inaasahang tamang resulta
Mga add-on
Attachment Isang log file, screenshot o anumang iba pang dokumento na makakatulong na linawin ang sanhi ng error o magpahiwatig ng paraan upang malutas ang problema

Kalubhaan vs Priyoridad
Ang kalubhaan ay isang katangian na nagpapakita ng epekto ng isang depekto sa pagganap ng isang aplikasyon.
Ang priyoridad ay isang katangian na nagpapahiwatig ng priyoridad ng pagsasagawa ng isang gawain o pag-aalis ng isang depekto. Masasabi nating isa itong tool ng manager ng pagpaplano ng trabaho. Kung mas mataas ang priyoridad, mas mabilis na kailangang ayusin ang depekto.
Ang kalubhaan ay inilantad ng tester
Priyoridad – manager, team lead o customer

Gradation ng Defect Severity (Severity)

S1 Blocker
Isang error sa pag-block na nagpapawalang-bisa sa application, na ginagawang imposible ang karagdagang paggana sa system na sinusubok o ang mga pangunahing pag-andar nito. Ang paglutas ng problema ay kinakailangan para sa karagdagang paggana ng system.

S2 Kritikal
Isang kritikal na error, isang hindi gumaganang pangunahing lohika ng negosyo, isang butas sa sistema ng seguridad, isang problema na humantong sa isang pansamantalang pag-crash ng server o nag-render ng ilang bahagi ng system na hindi gumagana, nang walang posibilidad na malutas ang problema gamit ang iba pang mga entry point. Ang paglutas ng problema ay kinakailangan para sa karagdagang trabaho sa mga pangunahing pag-andar ng system na sinusuri.

S3 Major
Ang isang makabuluhang error, bahagi ng pangunahing lohika ng negosyo ay hindi gumagana nang tama. Ang error ay hindi kritikal o posible na gumana sa function sa ilalim ng pagsubok gamit ang iba pang mga input point.

S4 Minor
Isang maliit na error na hindi lumalabag sa lohika ng negosyo ng bahagi ng application na sinusuri, isang malinaw na problema sa user interface.

S5 walang kuwenta
Isang maliit na error na hindi nakakaapekto sa lohika ng negosyo ng application, isang hindi magandang kopyahin na problema na halos hindi napapansin sa pamamagitan ng user interface, isang problema sa mga third-party na aklatan o serbisyo, isang problema na walang epekto sa pangkalahatang kalidad ng ang produkto.

Gradasyon ng Depekto Priyoridad (Priyoridad)
P1 Mataas
Ang error ay dapat itama sa lalong madaling panahon, dahil... ang presensya nito ay kritikal para sa proyekto.
P2 Katamtaman
Dapat itama ang error; hindi kritikal ang presensya nito, ngunit nangangailangan ng mandatoryong solusyon.
P3 Mababa
Ang pagkakamali ay dapat itama; ang presensya nito ay hindi kritikal at hindi nangangailangan ng agarang solusyon.

Mga Antas ng Pagsubok

1. Unit Testing
Sinusuri ng pagsubok ng bahagi (unit) ang functionality at naghahanap ng mga depekto sa mga bahagi ng application na naa-access at maaaring masuri nang hiwalay (mga module ng programa, bagay, klase, function, atbp.).

2. Pagsusuri sa Pagsasama
Ang pakikipag-ugnayan sa pagitan ng mga bahagi ng system ay sinusuri pagkatapos ng pagsubok ng bahagi.

3. System Testing
Ang pangunahing layunin ng pagsubok ng system ay upang i-verify ang parehong mga kinakailangan sa pagganap at hindi gumagana sa system sa kabuuan. Tinutukoy nito ang mga depekto gaya ng maling paggamit ng mga mapagkukunan ng system, hindi sinasadyang mga kumbinasyon ng data sa antas ng user, hindi pagkakatugma sa kapaligiran, hindi sinasadyang mga kaso ng paggamit, nawawala o hindi tamang paggana, abala sa paggamit, atbp.

4. Pagsusuri sa pagpapatakbo (Pagsusuri sa Paglabas).
Kahit na natutugunan ng isang system ang lahat ng kinakailangan, mahalagang tiyakin na natutugunan nito ang mga pangangailangan ng user at natutupad ang papel nito sa operating environment nito gaya ng tinukoy sa modelo ng negosyo ng system. Dapat itong isaalang-alang na ang modelo ng negosyo ay maaaring maglaman ng mga error. Ito ang dahilan kung bakit napakahalagang magsagawa ng operational testing bilang panghuling hakbang sa pagpapatunay. Bilang karagdagan, ang pagsubok sa operating environment ay nagpapahintulot sa amin na matukoy ang mga hindi gumaganang problema, tulad ng: mga salungatan sa iba pang mga system na nauugnay sa lugar ng negosyo o sa software at electronic na kapaligiran; hindi sapat na pagganap ng system sa operating environment, atbp. Malinaw, ang paghahanap ng mga bagay sa yugto ng pagpapatupad ay isang kritikal at mahal na problema. Iyon ang dahilan kung bakit napakahalaga na isakatuparan hindi lamang ang pagpapatunay, kundi pati na rin ang pagpapatunay, mula sa pinakamaagang yugto ng pagbuo ng software.

5. Pagsubok sa Pagtanggap
Isang pormal na proseso ng pagsubok na nagpapatunay na ang isang system ay nakakatugon sa mga kinakailangan at isinasagawa upang:
pagtukoy kung ang sistema ay nakakatugon sa mga pamantayan sa pagtanggap;
paggawa ng desisyon ng customer o ng ibang awtorisadong tao kung tinanggap ang aplikasyon o hindi.

Mga uri/uri ng pagsubok

Mga functional na uri ng pagsubok

Functional na pagsubok
Pagsubok sa GUI
Pagsubok sa Seguridad at Access Control
Pagsusuri sa Interoperability

Mga uri ng pagsubok na hindi gumagana

Lahat ng uri ng pagsubok sa pagganap:
o pagsubok sa pagkarga (Pagsusuri sa Pagganap at Pag-load)
o Stress Testing
o Pagsubok sa Katatagan / Pagiging Maaasahan
o Pagsubok sa Dami
Pagsubok sa pag-install
Pagsubok sa Usability
Failover at Pagsusuri sa Pagbawi
Pagsubok sa Configuration

Mga Uri ng Pagsubok na Kaugnay ng Pagbabago

Pagsubok sa Usok
Pagsusuri ng Regression
Muling pagsubok
Build Verification Test
Pagsubok sa Katinuan

Functional na pagsubok Isinasaalang-alang ang paunang tinukoy na pag-uugali at batay sa isang pagsusuri ng mga detalye ng pag-andar ng bahagi o ng system sa kabuuan.

Pagsubok sa GUI- functional check ng interface para sa pagsunod sa mga kinakailangan - laki, font, kulay, pare-parehong pag-uugali.

Pagsubok sa seguridad ay isang diskarte sa pagsubok na ginagamit upang suriin ang seguridad ng system, gayundin upang pag-aralan ang mga panganib na nauugnay sa pagbibigay ng isang holistic na diskarte sa pagprotekta sa application, mga pag-atake ng mga hacker, mga virus, hindi awtorisadong pag-access sa kumpidensyal na data.

Pagsusuri sa Interoperability ay functional testing na sumusubok sa kakayahan ng isang application na makipag-ugnayan sa isa o higit pang mga bahagi o system at kasama ang compatibility testing at integration testing

Pagsusuri sa Stress- ito ay awtomatikong pagsubok na ginagaya ang gawain ng isang tiyak na bilang ng mga user ng negosyo sa ilang karaniwang (nakabahaging) mapagkukunan.

Pagsusuri sa Stress nagbibigay-daan sa iyong suriin kung gaano kahusay ang application at ang system sa kabuuan ay nasa ilalim ng stress at suriin din ang kakayahan ng system na muling buuin, i.e. upang bumalik sa normal pagkatapos ng pagtigil ng stress. Stress sa sa kontekstong ito maaaring magkaroon ng pagtaas sa intensity ng mga operasyon sa napakataas na halaga o isang emergency na pagbabago sa configuration ng server. Gayundin, ang isa sa mga gawain ng pagsubok sa stress ay maaaring masuri ang pagkasira ng pagganap, kaya ang mga layunin ng pagsubok sa stress ay maaaring mag-overlap sa mga layunin ng pagsubok sa pagganap.

Pagsubok sa Dami. Ang layunin ng pagsubok sa dami ay upang makakuha ng pagtatasa ng pagganap habang tumataas ang dami ng data sa database ng application

Pagsubok sa Katatagan / Pagiging Maaasahan. Ang gawain ng pagsubok sa katatagan (pagkakatiwalaan) ay suriin ang pag-andar ng application sa panahon ng pangmatagalang (maraming oras) na pagsubok na may average na antas ng pagkarga.

Pagsubok sa pag-install naglalayong i-verify ang matagumpay na pag-install at pagsasaayos, pati na rin ang pag-update o pag-uninstall ng software.

Pagsubok sa kakayahang magamit ay isang paraan ng pagsubok na naglalayong itatag ang antas ng kakayahang magamit, kakayahang matuto, maunawaan at kaakit-akit para sa mga gumagamit ng produktong binuo sa konteksto ng mga ibinigay na kundisyon. Kasama rin dito ang:
Ang User eXperience (UX) ay ang pakiramdam na nararanasan ng user habang gumagamit ng digital na produkto, habang ang User interface ay isang tool na nagbibigay-daan sa pakikipag-ugnayan ng user-web resource.

Failover at Pagsusuri sa Pagbawi sinusubok ang produkto sa ilalim ng pagsubok sa mga tuntunin ng kakayahan nitong makatiis at matagumpay na makabawi mula sa mga posibleng pagkabigo na nagreresulta mula sa mga error sa software, pagkabigo sa hardware, o mga problema sa komunikasyon (halimbawa, pagkabigo sa network). Ang layunin ng ganitong uri ng pagsubok ay upang subukan ang mga sistema ng pagbawi (o mga system na nagdodoble sa pangunahing pag-andar), na, sa kaganapan ng mga pagkabigo, ay titiyakin ang kaligtasan at integridad ng data ng produktong sinusuri.

Pagsubok sa Configuration- isang espesyal na uri ng pagsubok na naglalayong suriin ang pagpapatakbo ng software sa ilalim ng iba't ibang mga configuration ng system (ipinahayag na mga platform, suportadong driver, iba't ibang mga configuration ng computer, atbp.)

Usok ang pagsubok ay itinuturing bilang isang maikling cycle ng mga pagsubok na isinagawa upang kumpirmahin na pagkatapos buuin ang code (bago o naayos), ang naka-install na application ay magsisimula at gumaganap ng mga pangunahing function.

Pagsusuri ng regression ay isang uri ng pagsubok na naglalayong i-verify ang mga pagbabagong ginawa sa isang application o kapaligiran (pag-aayos ng isang depekto, pagsasama-sama ng code, paglipat sa ibang operating system, database, web server o application server), upang kumpirmahin ang katotohanan na gumagana ang dati nang functionality ayon sa nilalayon dati. Ang mga pagsusuri sa regression ay maaaring parehong functional at non-functional na mga pagsubok.

Muling pagsubok- pagsubok, kung saan ang mga script ng pagsubok na natukoy ang mga error sa huling pagtakbo ay isinasagawa upang kumpirmahin ang tagumpay ng pagwawasto sa mga error na ito.
Ano ang pagkakaiba sa pagitan ng regression testing at re-testing?
Muling pagsubok - ang mga pag-aayos ng bug ay sinusuri
Pagsusuri ng regression - sinusuri kung ang mga pag-aayos ng bug, pati na rin ang anumang mga pagbabago sa code ng aplikasyon, ay hindi nakakaapekto sa iba pang mga module ng software at hindi nagdudulot ng mga bagong bug.

Pagsusuri sa pagpupulong o Pagsubok sa Pag-verify ng Build- pagsubok na naglalayong tukuyin ang pagsunod sa inilabas na bersyon na may kalidad na pamantayan upang simulan ang pagsubok. Sa mga tuntunin ng mga layunin nito, ito ay kahalintulad sa Smoke Testing, na naglalayong tanggapin ang isang bagong bersyon para sa karagdagang pagsubok o operasyon. Maaari itong tumagos nang mas malalim, depende sa mga kinakailangan sa kalidad ng inilabas na bersyon.

Pagsusuri sa kalusugan- ito ay sapat na nakatutok sa pagsubok upang patunayan na gumagana ang isang partikular na function ayon sa mga kinakailangan na nakasaad sa detalye. Ito ay isang subset ng regression testing. Ginagamit upang matukoy ang pagganap ng isang partikular na bahagi ng application pagkatapos ng mga pagbabagong ginawa dito o sa kapaligiran. Karaniwang ginagawa nang manu-mano.

Mga diskarte sa pagsasama ng pagsubok:
Bottom Up Integration
Ang lahat ng mababang antas na mga module, pamamaraan o function ay kinokolekta nang magkasama at pagkatapos ay sinubukan. Pagkatapos kung saan ang susunod na antas ng mga module ay binuo para sa pagsubok ng pagsasama. Ang pamamaraang ito ay itinuturing na kapaki-pakinabang kung ang lahat o halos lahat ng mga module ng antas na binuo ay handa na. Tinutulungan din ng diskarteng ito na matukoy ang antas ng kahandaan ng aplikasyon batay sa mga resulta ng pagsubok.
Pagsasama ng Top Down
Una, ang lahat ng mga high-level na module ay nasubok, at unti-unting ang mga mababang antas ay idinaragdag nang paisa-isa. Ang lahat ng mga module sa mababang antas ay ginagaya bilang mga stub na may katulad na pag-andar, pagkatapos kapag handa na, papalitan ang mga ito ng mga tunay na aktibong sangkap. Sa ganitong paraan sinusubukan namin mula sa itaas hanggang sa ibaba.
Big Bang (“Big Bang” Integration)
Ang lahat o halos lahat ng binuo na mga module ay pinagsama-sama bilang isang kumpletong sistema o ang pangunahing bahagi nito, at pagkatapos ay isinasagawa ang pagsubok sa pagsasama. Ang diskarte na ito ay napakahusay para sa pag-save ng oras. Gayunpaman, kung ang mga kaso ng pagsubok at ang kanilang mga resulta ay hindi naitala nang tama, kung gayon ang proseso ng pagsasama mismo ay magiging lubhang kumplikado, na magiging isang balakid para sa pangkat ng pagsubok sa pagkamit ng pangunahing layunin ng pagsubok sa pagsasama.

Mga prinsipyo ng pagsubok

Prinsipyo 1– Ipinapakita ng pagsubok ang pagkakaroon ng mga depekto
Maaaring ipakita ng pagsubok na may mga depekto, ngunit hindi mapapatunayan na wala ang mga ito. Binabawasan ng pagsubok ang posibilidad ng mga depekto sa software, ngunit kahit na walang nakitang mga depekto, hindi nito pinatutunayan ang kawastuhan nito.

Prinsipyo 2– Imposible ang kumpletong pagsubok
Ang kumpletong pagsubok gamit ang lahat ng kumbinasyon ng mga input at precondition ay pisikal na hindi magagawa maliban sa mga maliliit na kaso. Sa halip na kumpletong pagsubok, ang pagsusuri sa panganib at pag-prioritize ay dapat gamitin upang mas mahusay na ituon ang mga pagsusumikap sa pagsubok.

Prinsipyo 3- Maagang pagsubok
Upang makahanap ng mga depekto sa lalong madaling panahon, ang mga aktibidad sa pagsubok ay dapat magsimula nang maaga hangga't maaari sa ikot ng buhay ng software o system development, at dapat ay nakatuon sa mga partikular na layunin.

Prinsipyo 4– Pagkumpol ng mga depekto
Ang mga pagsusumikap sa pagsubok ay dapat na puro sa proporsyon sa inaasahan, at sa ibang pagkakataon ang aktwal, density ng depekto ng module. Bilang isang patakaran, karamihan sa mga depekto na natuklasan sa panahon ng pagsubok o na sanhi ng karamihan ng mga pagkabigo ng system ay nakapaloob sa isang maliit na bilang ng mga module.

Prinsipyo 5– Kabalintunaan ng pestisidyo
Kung paulit-ulit na tatakbo ang parehong mga pagsubok, sa kalaunan ang hanay ng mga kaso ng pagsubok na ito ay hindi na makakahanap ng mga bagong depekto. Upang malampasan ang "pesticide paradox", ang mga kaso ng pagsubok ay dapat na regular na suriin at ayusin, ang mga bagong pagsubok ay dapat na komprehensibo upang masakop ang lahat ng mga bahagi ng software,
o system, at maghanap ng maraming depekto hangga't maaari.

Prinsipyo 6– Ang pagsubok ay depende sa konsepto
Ang pagsubok ay ginagawa nang iba depende sa konteksto. Halimbawa, ang software na kritikal sa seguridad ay sinubok nang iba kaysa sa isang e-commerce na site.
Prinsipyo 7– Pagkakamali sa absence-of-errors
Ang paghahanap at pag-aayos ng mga depekto ay hindi makakatulong kung ang nilikha na sistema ay hindi angkop sa gumagamit at hindi nakakatugon sa kanyang mga inaasahan at pangangailangan.

Static at dynamic na pagsubok
Ang static na pagsubok ay naiiba sa dynamic na pagsubok dahil ginagawa ito nang hindi pinapatakbo ang code ng produkto. Ang pagsubok ay isinasagawa sa pamamagitan ng pagsusuri sa program code (code review) o compiled code. Ang pagsusuri ay maaaring gawin nang manu-mano o gamit ang mga espesyal na tool. Ang layunin ng pagsusuri ay maagang pagtuklas mga pagkakamali at potensyal na mga problema sa produkto. Kasama rin sa static na pagsubok ang mga detalye ng pagsubok at iba pang dokumentasyon.

Exploratory/ad-hoc na pagsubok
Ang pinakasimpleng kahulugan ng exploratory testing ay ang pagdidisenyo at pagpapatakbo ng mga pagsubok sa parehong oras. Alin ang kabaligtaran ng diskarte sa senaryo (kasama ang mga paunang natukoy na pamamaraan ng pagsubok nito, manwal man o awtomatiko). Ang mga pagsubok sa paggalugad, hindi tulad ng mga pagsubok sa sitwasyon, ay hindi paunang natukoy at hindi isinasagawa nang eksakto tulad ng nakaplano.

Ang pagkakaiba sa pagitan ng ad hoc at exploratory testing ay ang teorya, ang ad hoc na pagsubok ay maaaring isagawa ng sinuman, habang ang exploratory testing ay nangangailangan ng kasanayan at kaalaman sa ilang mga diskarte. Pakitandaan na ang ilang mga diskarte ay hindi lamang mga diskarte sa pagsubok.

Mga kinakailangan ay isang espesipikasyon (paglalarawan) kung ano ang dapat ipatupad.
Inilalarawan ng mga kinakailangan kung ano ang kailangang ipatupad, nang hindi idinetalye ang teknikal na bahagi ng solusyon. Ano, hindi paano.

Mga Kinakailangan Mga Kinakailangan:
Katumpakan
Kalinawan
Pagkumpleto ng hanay ng mga kinakailangan
Pagkakatugma ng isang hanay ng mga kinakailangan
Pagpapatunay (testability)
Traceability
Kakayahang maunawaan

Ikot ng buhay ng bug

Mga yugto ng pagbuo ng software- ito ang mga yugto na pinagdadaanan ng mga software development team bago maging available ang program sa isang malawak na hanay ng mga user. Ang pag-develop ng software ay nagsisimula sa unang yugto ng pag-unlad (pre-alpha stage) at nagpapatuloy sa mga yugto kung saan ang produkto ay pino at ginawang moderno. Ang huling yugto ng prosesong ito ay ang pagpapalabas ng huling bersyon ng software sa merkado ("pangkalahatang magagamit na paglabas").

Ang produkto ng software ay dumaan sa mga sumusunod na yugto:
pagsusuri ng mga kinakailangan sa proyekto;
disenyo;
pagpapatupad;
pagsubok ng produkto;
pagpapatupad at suporta.

Ang bawat yugto ng pagbuo ng software ay itinalaga ng isang tiyak serial number. Gayundin, ang bawat yugto ay may sariling pangalan, na nagpapakilala sa pagiging handa ng produkto sa yugtong ito.

Siklo ng buhay ng pagbuo ng software:
Pre-alpha
Alpha
Beta
Palayain ang kandidato
Palayain
Post release

Talaan ng desisyon– isang mahusay na tool para sa pag-aayos ng mga kumplikadong kinakailangan sa negosyo na dapat ipatupad sa isang produkto. Ang mga talahanayan ng desisyon ay nagpapakita ng isang hanay ng mga kundisyon, ang sabay-sabay na katuparan nito ay dapat humantong sa isang tiyak na aksyon.

modelo ng pagsubok ay isang lohikal na istruktura na naglalarawan sa functionality ng system at/o gawi ng user, ayon sa kung aling mga test case ang nabuo. Ang pagtatayo ng isang modelo ng pagsubok ay nagsisimula sa pagtatayo ng isang istraktura, at pagkatapos ay ang naaprubahang istraktura ay puno ng mga kaso ng pagsubok.

Ang mga modelo ay karaniwang binuo batay sa mga kinakailangan at/o inaasahang pag-uugali ng system. Ang pagbuo at pamamahala ng modelo ng pagsubok ay angkop para sa malalaking sistema na may kumplikadong lohika ng negosyo at mahirap ilapat sa mga proyektong gumagana gamit ang mga nababaluktot na pamamaraan, dahil ang gastos sa pagpapanatili ng pamamahala ng modelo ng pagsubok at proseso ng pagtiyak ng kalidad ay magiging masyadong mataas.

Ang pamamahala ng modelo ng pagsubok ay tumutukoy sa prosesong kumokontrol sa saklaw ng modelo ng pagsubok, ang kalidad ng mga script na naglalarawan sa modelo ng pagsubok at ang pag-update nito.

Ang pamamahala sa modelo ng pagsubok ay isang patuloy na proseso sa buong ikot ng buhay ng produkto.

Saklaw ng modelo ng pagsubok

Upang kontrolin ang saklaw ng lahat ng kinakailangan, maaari mong gamitin ang mga trace matrice, na tumutukoy sa saklaw ng mga kinakailangan ayon sa mga kaso ng pagsubok (tingnan ang halimbawa).
Bago ilarawan ang mga kaso ng pagsubok, dapat na aprubahan ng customer ang istruktura ng modelo ng pagsubok.

Kalidad ng script

Upang pamahalaan ang kalidad ng mga script, kinakailangan na kontrolin hindi lamang ang antas ng paglalarawan ng mga kaso ng pagsubok, kundi pati na rin ang kanilang kalidad.

Bago simulan ang paglalarawan ng mga kaso ng pagsubok, kinakailangan upang matukoy ang mga kinakailangan para sa bawat antas ng paglalarawan at pamantayan ng kalidad para sa paglalarawan ng mga kaso ng pagsubok.

Mga posibleng antas ng paglalarawan ng test case:

Sa antas 4, ang koordinasyon sa customer ay maaaring mapalitan ng pag-apruba.

Ang mga pamantayan sa kalidad para sa mga paglalarawan ng kaso ng pagsubok ay maaaring ang mga sumusunod:

• Ang mga kaso ng pagsubok ay dapat isulat ayon sa mga kinakailangan

Ang pagsubok ay ang proseso ng pagpapatunay na ang isang produkto ay nakakatugon sa mga kinakailangan nito. Samakatuwid, sa bahagi Pangkalahatang paglalarawan kaso ng pagsubok (sa mga sistema ng pagsubaybay sa pagsubok ang terminong "Buod" ay karaniwang ginagamit) kinakailangan na sumangguni sa isang partikular na kinakailangan kasabay ng mga fragment ng teksto ng mga kinakailangan. Kaya, magiging malinaw sa lahat ng mga kalahok sa proyekto kung saan isinulat ang test case na ito.

• Gumamit ng mga detalyadong paunang kondisyon

Paano makatipid ng oras sa mga kaso ng pagsubok?

Magtakda ng mga panuntunan sa pag-format para sa lahat ng test case. Sa ganitong paraan magiging madaling maunawaan at mabasa ang test case para sa sinumang kalahok sa proyekto. Halimbawa, sa isang proyekto maaari mong ipasok ang mga sumusunod na panuntunan:

• Dapat markahan ng pula ang lahat ng input parameter.
• Ang lahat ng mga script ay dapat na naka-highlight sa asul,
• Ang lahat ng mga pangalan ng mga pindutan, mga patlang, mga bloke ay naka-highlight sa italics at bold.
• Ang mga mahahalagang lugar ay na-highlight na may salungguhit.
• Ang bawat hakbang na ginawa ay dapat may inaasahang resulta.
• Ang bawat hakbang sa mga test case ay dapat maglarawan lamang ng isang aksyon at ang inaasahang resulta para dito. Yung. Kapag tumatanggap ng nabigong test case sa isang partikular na hakbang, dapat itong malinaw na malinaw kung saan naganap ang error.
• Ang inaasahang resulta ay dapat na hindi malabo.

Ang mga kaso ng pagsubok ay dapat na hindi malabo, ibig sabihin. ay dapat na bumalangkas at bumalangkas sa paraang hindi nila pinapayagan ang malabong interpretasyon, ngunit malinaw na nauunawaan ng lahat ng kalahok.

Kung ang pagsusulat ng mga test case ay tumatagal ng mahabang panahon, isang sitwasyon ay maaaring lumitaw kapag ang isang espesyalista ay tumigil na makita ang kanyang mga pagkakamali. Nangangailangan ito ng panlabas na pananaw - dito makakatulong ito pagsasagawa ng cross-reviews. Ang yugtong ito ay inirerekomenda na isagawa sa mga kaso kung saan ang pagbuo ng isang modelo ng pagsubok ay pinalawig at tumatagal ng mahabang panahon. Halimbawa, kapag ang pagbuo ng mga senaryo ng pagsubok ay tumatagal ng higit sa 1 buwan.

Maaaring isagawa ang proseso ng kontrol sa kalidad ng script gamit ang Test Model Control– isang espesyal na inihandang template.

Pag-update ng modelo ng pagsubok

Kinakailangan na regular na i-update ang modelo ng pagsubok at ang mga kaso ng pagsubok mismo para sa pagsunod sa mga kinakailangan, pati na rin suriin ang mga priyoridad ng mga kaso ng pagsubok.

Upang mag-update maaari mong panatilihin ang isang "Requirements Matrix"(Requirement Traceability Matrix): pagkatapos ng bawat pagbabago sa isang partikular na pangangailangan, lahat ng test case na nauugnay sa kinakailangang ito ay pipiliin mula sa test tracking system at ina-update.

Mga kontrol sa modelo ng pagsubok:

• TestRail
• TestLink
• Jira+Zephyr
• Microsoft Test Manager (MTM)
• Excel

Ang iyong layunin bilang isang system administrator
ay ang pagpapatupad ng mga epektibong estratehiya para sa
pag-maximize ng iyong mga mapagkukunan ng computer.

D. Gunter, S. Barnett, L. Gunter.
Pagsasama ng Windows NT at Unix

Ang mga espesyalista sa IT ay hindi lamang kailangang maging pamilyar sa maraming mga pagsubok na inilathala sa computer press, ngunit bumuo din ng mga pamamaraan ng pagsubok sa kanilang sarili, na kinakailangan kapwa kapag pumipili ng isang tagapagtustos at kapag lumilikha ng kanilang sariling solusyon. Samakatuwid, susubukan naming sagutin ang mga tanong na lumitaw sa mahirap na proseso ng pagsubok, lalo na kapag ito ay may kinalaman sa mga kumplikadong sistema tulad ng mga server..

Ano ang sinusuri at bakit?

Kadalasan sa mga peryodiko ng computer ay may iba't ibang uri ng pagsusuri ng mga programa, hardware at solusyon. Ang partikular na interes, bilang panuntunan, ay mga comparative review ng functionally homogenous na mga produkto, na nagpapakita ng mga resulta ng pagsubok. Ito ay pinaniniwalaan na ang mga detalyadong talahanayan na ito ay nakakatulong sa user, administrator at IT professional na magkaroon ng kamalayan sa kung ano ang nangyayari sa lugar na ito at kahit na magpasya sa pagpili ng produkto.

Kaya, anong mga kadahilanan ang isinasaalang-alang sa mga ganitong kaso, ano ang layunin ng pananaliksik at anong mga uri ng mga pagsubok ang pinakasikat?

Ang mga pamantayan sa pagsubok ay karaniwang:

• pag-andar ng produkto;
• kadalian ng pag-aaral;
• kadalian ng pag-install;
• kalidad ng dokumentasyon at suporta;
• pagganap;
• Para sa kagamitan, minsan ay isinasaalang-alang ang disenyo.

Mayroon ding napaka-ambiguous na pamantayan. Hindi pa katagal sa isa sa mga pagsusuri ng mga Web server kapag nagse-set pangkalahatang pagtatasa bilang positibong salik ay isinasaalang-alang" mataas na antas pagsasama sa operating system." Ngunit kung ang pagkabigo ng aplikasyon ay nagdudulot ng pagkabigo sa operating system (ang posibilidad na proporsyonal sa antas ng pagsasama) - ito ba ay talagang isang kalamangan?

Ang isang daang kuneho ay katumbas ng isang tigre?

Hiwalay, gusto kong pag-isipan ang ratio ng presyo/pagganap, na karaniwan kapag sinusuri ang hardware. Sa unang tingin, ito lang talaga layunin na pamantayan, kumokonekta mga pagtutukoy ang sistemang pinag-aaralan sa wallet ng mamimili. Gayunpaman, hindi lahat ay kasing simple ng tila. Ang katotohanan ay ang nabanggit na diskarte ay gumagana lamang sa oras ng pagbili at hindi isinasaalang-alang ang halaga ng pagmamay-ari, ang kaligtasan ng mga pamumuhunan sa kagamitan o software, o ang posibilidad ng karagdagang modernisasyon.

Ang isang karaniwang halimbawa ay isang paghahambing ng mga mas lumang modelo ng mga system sa mga processor ng Intel sa mga mas bata sa linya ng mga platform ng RISC. Oo, sa katunayan, sa isang naibigay na hanay ng presyo, ang mga makina na may arkitektura ng Intel ay maihahambing o, sa ilang mga kaso, mas mataas pa sa mga sistema ng RISC. Gayunpaman, kung ano ang kisame para sa ilang mga platform ay ang panimulang antas lamang para sa iba, at iba pa.

Mga konklusyon: maging mapanuri sa pamantayan kung saan sinusuri ang isang produkto—maaaring magkaiba ka at ang mga tagasubok. Subukang sabihin sa mga tagahanga ng Unix na para sa kaginhawaan ng graphical na interface para sa pag-configure ng system, ito ay nagkakahalaga ng pagtanggap ng pangangailangan na mag-reboot pagkatapos baguhin ang mga parameter ng IP. Tulad ng para sa compact na disenyo ng system unit, ito ay mabuti hanggang sa kailangan mong magpasok ng karagdagang hard drive sa slim case.

Sa madaling salita, pag-isipang muli ang mga resulta ng pagsusulit upang umangkop sa iyong mga pangangailangan.

Mga detalye ng pagsubok ng server

Kung ang computer ay hindi naka-on, ito ay may sira.
Kung hindi ito naka-off, ito ay isang server.
Folk sign

Sa aming opinyon, ang isa sa mga pangunahing kinakailangan para sa mga server ay pagiging maaasahan. Ang pagganap, siyempre, ay mahalaga din, dahil nakakaapekto ito sa oras ng pagtugon ng system - ang pinakamahalagang katangian mula sa pananaw ng gumagamit, ngunit ang pagkakaroon ng serbisyo ay tinutukoy ng pagiging maaasahan. Ang pagiging maagap ng pagkakaloob nito, ang kaugnayan at integridad ng impormasyon ay nakasalalay din sa pagiging maaasahan.

Bilang karagdagan, dapat itong isaalang-alang na nagdadalubhasa, ibig sabihin, nagbibigay lamang ng isang serbisyo, ang mga server ay ang pagbubukod pa rin kaysa sa panuntunan. Karaniwan, ang isang ganoong computer ay pinagsasama ang ilang mga function - halimbawa, ang isang application server ay maaari ding magsilbi bilang isang file server, print server, backup service controller, atbp. Ang mga server ng komunikasyon ay karaniwang gumagana sa ilang mga application-level protocol, na ang bawat isa ay inihahatid sa pamamagitan ng sarili nitong "daemon" ".

At sa wakas, ang isang katangian ng pagpapatakbo ng server ay ang pagkakaroon ng mga peak load. Ang mga dahilan para sa kanilang hitsura ay maaaring ibang-iba - mula sa simula ng araw ng trabaho sa isang malaking organisasyon (lalo na kung ang lahat ng mga gumagamit ay dumating sa trabaho sa oras) hanggang sa pagpapanumbalik ng isang "nabagsak" na koneksyon sa isang Internet service provider, kapag ang backlog ng mail at mga newsgroup ay tumama sa mga server ng komunikasyon.

Ang mga salik na ito, ibig sabihin, ang pangangailangan para sa mas mataas na pagiging maaasahan sa mga kundisyon ng pagbibigay ng maramihang mga serbisyo at peak load, ay dapat maging susi kapag tinutukoy ang ideolohiya ng pagsubok sa server.

Sa kasamaang palad, karamihan sa mga review na nai-publish sa mga periodical ng computer ay nakatuon sa paghahambing ng pagganap ng iba't ibang mga solusyon sa hardware sa isang hanay ng mga gawain sa pagsubok na isinagawa nang sunud-sunod, o sa paghahambing na pagsubok ng isang partikular na serbisyo (halimbawa, pagsubok sa mga Web server iba't ibang mga tagagawa). Ang isa sa mga pinakamasamang variant ng diskarteng ito ay kapag ang isang paghahambing na pagsusuri ng mga kakayahan ng mga katulad na solusyon ay tinatawag na pagsubok lamang dahil ang may-akda ng publikasyon ay nagsagawa ng pag-install at "nagmaneho" ng produkto nang kaunti.

Mga kondisyon ng pagsubok

Una, isang maliit na teorya. Glenford Myers, sa kanyang papel na "Software Reliability", ay nagbibigay ng ilang "testing axioms". Subukan natin, sundin ang mga ito, upang isaalang-alang kung ano at kung paano subukan.

Paminsan-minsan, lumilitaw ang mga ulat na halos palakasan sa computer press: ang produkto ng kumpanyang N ay nagpakita ng rekord ng pagganap sa pagsubok sa M. Gaano kabatid ang mga pagsusulit na isinasagawa ng mga kumpanya ng pagmamanupaktura?

Hindi masubukan ang sarili mong programa

Kadalasan ang mga pagsusulit ay isinulat ng mga empleyado ng kumpanya para sa isang partikular na produkto. Ang mga pagsubok sa pagganap ng processor, na isinulat sa paraang mapagtanto ang mga pakinabang ng isang partikular na processor, ay naging usapan ng bayan. Halimbawa, ang laki ng programa ng pagsubok ay pinili na isinasaalang-alang ang pagkakalagay nito sa memorya ng cache, atbp. Ang graphical na presentasyon ng mga naturang resulta ay kadalasang medyo bias.

Ang pag-alam sa arkitektura ng mga application at ang kanilang paggamit ng mga mapagkukunan ng OS ay nagbibigay-daan sa mga developer ng software na i-configure ang system sa paraang makakuha ng pinakamataas na resulta para sa kanilang programa. Hindi mahalaga kung ang ibang software o serbisyo ay magiging komportable sa mga naturang pag-install ng operating system at kung ang application na nasa ilalim ng pagsubok ay "aagawin ang mga mapagkukunan".

Nakatagpo ng may-akda ang hindi pangkaraniwang bagay na ito habang sinusubukang i-configure ang Netscape Enterprise Web Server sa ilalim ng Solaris (SPARC). Ang pagganap ng server gamit ang http protocol ay nadagdagan ng halos 6 (!) na beses (ayon sa pagsubok sa MS InetLoad), ngunit sa isang kumplikadong pagsubok ang pagtaas ay naging tatlong beses, habang ang pagganap ng POP3 server ay nadoble, ang Balita nanatiling hindi nagbabago ang server, at dalawang beses na nagpakita ang SMTP pinakamasamang resulta kaysa bago ginawa ang mga pagbabago.

Bilang karagdagan, ang mga tagagawa, na alam ang mga katangian ng isang partikular na set ng pagsubok, ay maaaring mag-optimize ng mga parameter ng system na partikular para dito. Ang isang halimbawa nito ay ang Netscape Web page, na nagbibigay ng mga rekomendasyon kung paano i-configure ang Netscape Enterprise Server para sa pagsubok gamit ang SPECweb96.

Ang pagsubok ay isinasagawa upang makita ang mga error

Sa kaso ng mga server at software ng server, nangangahulugan ito na ang aparato ay dapat pilitin na gumana sa pinaka-hindi kanais-nais na mode - magsagawa ng isang pagsubok na "survivability". Magagawa ito sa pamamagitan ng pagsubok sa server sa sumusunod na configuration ng operating:

• lahat ng mga serbisyo ay dapat na tumatakbo;
• lahat ng mga serbisyo ay dapat na masuri nang sabay-sabay (komprehensibong pagsubok);
• isang stream ng mga kahilingan ang ipinapadala sa bawat isa sa mga serbisyo, na ginagaya ang karaniwang aktibidad ng user;
• ang aktibidad na ito ay dapat na pana-panahong tumaas sa panahon ng pagsubok hanggang sa hindi na makayanan ng kahit isang serbisyo ang mga kahilingan sa pagproseso.

Dalawang tala ang may kaugnayan dito:

1. Modelo ng pag-uugali ng user.

Kaugnay ng mga user, ang administrator ay dapat na isang pesimista. Ang pagsubok sa kaligtasan ay dapat gawin nang naaayon.

Ibigay ang maximum na bilang ng mga aksyon na maaari mong gawin nasa mabuting kalagayan Hindi lang sana sumagi sa isip ko. Tantyahin (o suriin) kung gagana nang normal ang system sa sitwasyong ito. At tulad ng mahalaga, makakatanggap ba ang gumagamit ng isang malinaw na mensahe mula sa kanya na hindi na ito karapat-dapat gawin at bakit.

2. Ang serbisyo ay huminto sa paghawak ng mga kahilingan: mga posibleng opsyon.

Ayon sa antas ng kalubhaan, ang mga naturang pagkabigo ay maaaring nahahati sa 4 na grupo:

• nabawasan ang pagganap - ang serbisyo ay walang oras upang maproseso, ngunit tumugon nang tama (ibinabalik ang kaukulang error code - "Masyadong maraming koneksyon", atbp.);
• abnormal na pagwawakas ng isang serbisyo na hindi nagsasangkot ng mga negatibong kahihinatnan para sa system: ang kaukulang programa ay nakumpleto ang trabaho nito, na-disload mula sa memorya, at ang mga mapagkukunan ng system ay napalaya;
• abnormal na pagwawakas ng isang serbisyo, na negatibong nakakaapekto sa pagganap ng system. Ang programa ay maaaring "nakabitin" sa listahan ng mga proseso nang hindi naglalabas ng mga mapagkukunan, o sa panahon ng proseso ng pagwawakas ito ay kumukuha ng mga karagdagang mapagkukunan;
• pag-crash ng system - sa pinakamaganda, na sinusundan ng pag-reboot, sa pinakamalala - na may pagyeyelo.

Maghanda ng mga pagsubok para sa parehong tama at maling mga input

Ang axiom na ito ay nagdedetalye ng nauna sa mga tuntunin ng mga daloy ng impormasyon ng input.

Ano ang magiging reaksyon ng system sa pagpapadala ng isang liham na ilang sampu-sampung megabytes ang laki? Maaalis ba ito sa isang pila, at sa gayon ay haharangin ang iyong mail system nang walang hanggan (lalo na kung ang komunikasyon sa host ng tatanggap ay regular na naaantala), o masisira ba ito at aabisuhan ang user na ang mga naturang aksyon ay hindi katanggap-tanggap?

Payo na kinuha mula sa parehong libro ni G. Myers: "Subukang huwag hayaan ang system na magalit ang user, dahil maaaring humantong ito sa ilang hindi inaasahang sitwasyon sa input - Rule #5 ng pagliit ng mga error ng user sa mga dialog system. Ang pagiging pesimista ay hindi ibig sabihin ng pagiging misanthrope!" .

Paano ang server ng balita - mayroon bang maximum na laki ng artikulo?

Maaari bang may isang taong nagnanais na i-load ang kalahati ng iyong FTP site na magbukas ng tatlong dosenang parallel na FTP session, at kung gayon, paano ito makakaapekto sa iyong channel at sa gawain ng iba na gustong bumisita sa FTP?

Bilang isang halimbawa na nagpapatunay sa kawastuhan ng diskarteng ito, maaari nating banggitin ang insidente sa missile cruiser Yorktown, kung saan nagresulta ang isang error sa input ng operator sa pagkabigo ng sistema ng kontrol ng engine. O isa pa, na binanggit mismo ni Myers: "Ang mga operator ng New York City police dispatch system na SPRINT ay nilibang ang kanilang sarili sa kanilang libreng oras sa pamamagitan ng pagsisikap na huwag paganahin ito sa pamamagitan ng paglalagay ng sadyang maling mga mensahe." Nangyari ito noong unang bahagi ng 70s. Marahil ay lumambot ang moral mula noon, ngunit ito ay malamang na hindi.

Iwasan ang mga hindi maibabalik na pagsubok

Sa kaso ng pagsubok sa mga server at server software, ang axiom na ito ay partikular na nauugnay. Una, ang pagsubok sa mga ito ay nangangailangan ng pagkakaroon ng hardware-separated load generators (Client-Side Load Generators, CSLG) - kadalasan ito ay mga grupo ng mga workstation na nagpapatupad ng client na bahagi ng pagsubok at nagbibigay ng daloy ng mga kahilingan sa server. Pangalawa, ang mga resulta ay maaaring maapektuhan ng estado ng network na kumukonekta sa server at sa CSLG. Bilang karagdagan, sa maraming mga kaso, ang pagganap ay nakasalalay sa kasaysayan ng mga tawag sa server. Karamihan sa mga application ng server ay gumagamit ng caching. Ang bilis ng pag-access sa memorya ng cache ay mas mataas kaysa sa bilis ng pag-access sa disk subsystem. Maaaring mapuno ang cache ng application dahil sa paunang o pag-debug ng mga pagtakbo ng mga programa sa pagsubok - at maaaring magbago ang mga resulta nang naaayon. Bukod dito, sa kumplikadong pagsubok, posible ang cross-influence ng mga application - halimbawa, ang bilang ng mga kumplikadong kahilingan na naproseso bawat yunit ng oras sa mga POP3 o IMAP server ay depende sa laki ng mail spool, na maaaring dagdagan ng nakaraang pagsubok sa SMTP . Sa wakas, ang mga setting ng operating system ay nakakaapekto sa pagganap.

Ang lahat ng disenteng pagsusuri ay may seksyon sa "Paano isinagawa ang mga pagsubok." Sa ilang mga publikasyon ito ay mas detalyado, sa iba ay mas mababa - tila wala pa ring pamantayan para sa paglalarawan at pagtatala ng pagsubok. Ang isang mahusay na halimbawa nito ay ang pagsubok ng SPECweb96. Isinasaalang-alang ng dokumentong ito ang mga detalye ng pagsubok ng isang server application. Hindi tulad ng mga tradisyonal na paglalarawan, mayroong mga kinakailangan sa pag-log karagdagang mga setting operating system at ang application na pinag-aaralan - isang bagay na karaniwang binabanggit lamang sa pagpasa kahit na sa pinakamahusay na mga halimbawa ng mga paglalarawan ng pagsubok.

Marahil ikaw mismo ay makakarating sa pagsasakatuparan na kailangan mong magsagawa ng iyong sariling pagsubok. Ang pangangailangang ito ay maaaring lumitaw sa mga sumusunod na kaso:

• pinaplano mong palawakin ang iyong network, na hahantong sa pagtaas ng pagkarga sa mga server na matatagpuan dito;
• balak mong i-update (o baguhin) ang software;
• nagpasya kang baguhin ang iyong server (o mga server) sa mga mas produktibo;
• Sa wakas, marahil ay nagpasya ka na lamang na malaman ang "mga limitasyon sa paglago" ng iyong system.

Ang iyong unang hakbang ay malamang na tingnan ang mga na-publish na review. Samakatuwid, upang magamit ang data na nakuha ng ibang tao, ituring ito nang kritikal at subukang maunawaan, bukod sa iba pang mga bagay, ang motibasyon ng mga taong nagsagawa ng pagsubok na ito. At pagkatapos ang lahat ay nakasalalay sa iyo - pag-unawa sa layunin, pagpili o pagsulat ng isang sapat na hanay ng mga pagsubok, at wastong pagsasagawa ng pagsubok mismo. Umaasa ako na ang mga pagsasaalang-alang na nakabalangkas sa artikulong ito ay makakatulong sa iyo dito.