Sa mga pamamaraan ng pag-verify ng software. Ang lugar ng pag-verify sa mga proseso ng pagbuo ng software. Pagpaplano para sa Pagpapatunay at Kwalipikasyon
20. Pagpapatunay at sertipikasyon software
Ang pag-verify at pagpapatunay ay ang mga proseso ng pagsubok at pagsusuri na nagpapatunay na ang software ay nakakatugon sa mga pagtutukoy nito at mga kinakailangan ng customer. Sinasaklaw ng pag-verify at sertipikasyon ang buong ikot ng buhay ng software - nagsisimula sila sa yugto ng pagsusuri ng mga kinakailangan at nagtatapos sa pag-verify ng code ng programa sa yugto ng pagsubok sa natapos na sistema ng software.
Ang pag-verify at sertipikasyon ay hindi pareho, bagama't madaling malito ang mga ito. Sa madaling sabi, ang pagkakaiba sa pagitan ng mga ito ay maaaring tukuyin tulad ng sumusunod:
Sinasagot ng pag-verify ang tanong kung ang sistema ay ginawa nang tama;
Sinasagot ng sertipikasyon ang tanong kung gumagana nang tama ang system.
Ayon sa mga kahulugang ito, bini-verify ng pag-verify ang pagsunod ng software sa detalye ng system, lalo na ang mga kinakailangan sa functional at non-functional. Ang sertipikasyon ay isang mas pangkalahatang proseso. Sa panahon ng sertipikasyon, kinakailangan upang matiyak na ang produkto ng software ay nakakatugon sa mga inaasahan ng customer. Ang sertipikasyon ay sumusunod sa pag-verify upang matukoy kung gaano kahusay natutugunan ng system hindi lamang ang mga pagtutukoy, kundi pati na rin ang mga inaasahan ng customer.
Tulad ng nabanggit kanina, sa mga unang yugto ng pagbuo ng software, ang sertipikasyon ng mga kinakailangan ng system ay napakahalaga. Ang mga pagkakamali at pagkukulang ay karaniwan sa mga kinakailangan; sa ganitong mga kaso, malamang na hindi matugunan ng huling produkto ang mga inaasahan ng customer. Ngunit siyempre, hindi matukoy ng pagpapatunay ng mga kinakailangan ang lahat ng mga problema sa detalye ng mga kinakailangan. Minsan ang mga pagkukulang at pagkakamali sa mga kinakailangan ay natuklasan lamang pagkatapos makumpleto ang pagpapatupad ng system.
Ang mga proseso ng pag-verify at sertipikasyon ay gumagamit ng dalawang pangunahing pamamaraan para sa pag-verify at pagsusuri ng mga system.
1. Inspeksyon ng software. Suriin at i-verify ang iba't ibang representasyon ng system, tulad ng dokumentasyon ng detalye ng mga kinakailangan, mga diagram ng arkitektura, o source code ng program. Isinasagawa ang inspeksyon sa lahat ng yugto ng proseso ng pagbuo ng software system. Kaayon ng inspeksyon, maaari itong isagawa awtomatikong pagsusuri source code ng mga programa at mga kaugnay na dokumento. Ang inspeksyon at awtomatikong pagsusuri ay static na pag-verify at mga pamamaraan ng pagpapatunay dahil hindi sila nangangailangan ng isang executable system.
2. Pagsubok ng software. Patakbuhin ang executable code na may data ng pagsubok at suriin ang mga katangian ng output at performance ng produkto ng software upang ma-verify na gumagana nang tama ang system. Ang pagsubok ay isang dynamic na paraan ng pag-verify at sertipikasyon habang inilalapat ito sa isang tumatakbong sistema.
Sa Fig. Ipinapakita ng Figure 20.1 ang lugar ng inspeksyon at pagsubok sa proseso ng pagbuo ng software. Ang mga arrow ay nagpapahiwatig ng mga yugto ng proseso ng pag-unlad kung saan maaaring ilapat ang mga pamamaraang ito. Ayon sa scheme na ito, maaaring isagawa ang inspeksyon sa lahat ng yugto ng proseso ng pag-develop ng system, at maaaring isagawa ang pagsubok sa mga kaso kung saan ang isang prototype o executable na programa ay nilikha.
Kasama sa mga paraan ng inspeksyon ang: inspeksyon ng programa, awtomatikong pagsusuri ng source code, at pormal na pag-verify. Ngunit ang mga static na pamamaraan ay maaari lamang suriin ang pagsunod ng mga programa na may mga pagtutukoy ay hindi magagamit upang suriin ang tamang paggana ng system. Bilang karagdagan, ang mga hindi gumaganang katangian tulad ng pagganap at pagiging maaasahan ay hindi mabe-verify gamit ang mga static na pamamaraan. Samakatuwid, upang suriin ang mga di-functional na katangian, isinasagawa ang pagsubok ng system.
kanin. 20.1. Static at dynamic na pag-verify at sertipikasyon
Sa kabila ng malawakang paggamit ng software inspeksyon, pagsubok pa rin ang nangingibabaw na paraan ng pagpapatunay at sertipikasyon. Ang pagsubok ay isang pagsubok sa pagpapatakbo ng mga programa na may data na katulad ng totoong data na ipoproseso sa panahon ng pagpapatakbo ng system. Ang pagkakaroon ng mga depekto at hindi pagsang-ayon sa programa ay natutukoy sa pamamagitan ng pagsusuri sa output data at pagtukoy ng mga maanomalyang kasama ng mga ito. Isinasagawa ang pagsubok sa yugto ng pagpapatupad ng system (upang suriin kung natutugunan ng system ang mga inaasahan ng mga developer) at pagkatapos makumpleto ang pagpapatupad nito.
Ang iba't ibang uri ng pagsubok ay ginagamit sa iba't ibang yugto ng proseso ng pagbuo ng software.
1. Pagsusuri ng depekto isinagawa upang makita ang mga hindi pagkakapare-pareho sa pagitan ng isang programa at ang detalye nito na sanhi ng mga error o depekto sa mga programa. Ang ganitong mga pagsubok ay idinisenyo upang matukoy ang mga error sa system, at hindi upang gayahin ang operasyon nito.
2. Pagsusulit sa istatistika sinusuri ang pagganap at pagiging maaasahan ng mga programa, pati na rin ang pagpapatakbo ng system sa iba't ibang mga mode ng pagpapatakbo. Ang mga pagsubok ay idinisenyo upang gayahin ang tunay na operasyon ng system gamit ang totoong data ng pag-input. Ang pagiging maaasahan ng system ay tinasa ng bilang ng mga pagkabigo na nabanggit sa pagpapatakbo ng mga programa. Ang pagganap ay tinatasa sa pamamagitan ng pagsukat sa kabuuang oras ng pagpapatupad ng mga operasyon at ang oras ng pagtugon ng system kapag nagpoproseso ng data ng pagsubok.
Ang pangunahing layunin ng pag-verify at kwalipikasyon ay upang matiyak na ang sistema ay "akma para sa layunin". Ang pagsunod ng isang software system sa layunin nito ay hindi nagpapahiwatig na dapat itong ganap na walang error. Sa halip, ang sistema ay dapat na makatwirang magsilbi sa mga layunin kung saan ito nilayon. Antas ng kinakailangan pagiging maaasahan ng pagsunod depende sa layunin ng system, mga inaasahan ng user at kundisyon sa merkado ng software.
1. Layunin ng software. Ang antas ng kumpiyansa sa pagsunod ay depende sa kung gaano kahalaga ang software na binuo ay ayon sa ilang pamantayan. Halimbawa, ang antas ng kumpiyansa para sa mga sistemang kritikal sa kaligtasan ay dapat na mas mataas kaysa sa antas ng kumpiyansa para sa mga prototype na software system na binuo upang magpakita ng ilang bagong ideya.
2. Mga inaasahan ng user. Nakalulungkot na tandaan na sa kasalukuyan ang karamihan sa mga gumagamit ay may mababang mga kinakailangan sa software. Ang mga gumagamit ay sanay na sanay sa mga pagkabigo na nangyayari habang tumatakbo ang mga programa na hindi sila nagulat dito. Handa silang tiisin ang mga pagkabigo ng system kung ang mga benepisyo ng paggamit nito ay mas malaki kaysa sa mga disadvantages. Gayunpaman, mula noong unang bahagi ng 1990s, ang pagpapaubaya ng gumagamit para sa mga pagkabigo sa mga sistema ng software ay unti-unting bumababa. Kamakailan lamang, ang paglikha ng mga hindi mapagkakatiwalaang mga sistema ay naging halos hindi katanggap-tanggap, kaya ang mga kumpanya na bumubuo ng mga produkto ng software ay kailangang magbayad ng higit at higit na pansin sa pag-verify ng software at sertipikasyon.
3. Kondisyon sa merkado ng software. Kapag sinusuri ang isang software system, dapat malaman ng nagbebenta ang mga nakikipagkumpitensyang system, ang presyong gustong bayaran ng mamimili para sa system, at ang target na petsa para sa paglabas ng system sa merkado. Kung ang kumpanya ng pag-unlad ay may ilang mga kakumpitensya, kinakailangan upang matukoy ang petsa para sa sistema upang makapasok sa merkado bago matapos ang buong pagsubok at pag-debug, kung hindi, ang mga kakumpitensya ay maaaring ang unang pumasok sa merkado. Kung ayaw ng mga customer na bumili ng software sa mataas na presyo, maaaring handa silang tiisin ang higit pang mga pagkabigo sa system. Ang lahat ng mga salik na ito ay dapat isaalang-alang kapag tinutukoy ang mga gastos sa proseso ng pag-verify at sertipikasyon.
Bilang isang patakaran, sa panahon ng pag-verify at sertipikasyon, ang mga error ay natuklasan sa system. Ginagawa ang mga pagbabago sa system upang itama ang mga error. Ito proseso ng pag-debug Karaniwang isinama sa iba pang mga proseso ng pag-verify at kwalipikasyon. Gayunpaman, ang pagsubok (o mas pangkalahatan, pag-verify at sertipikasyon) at pag-debug ay magkaibang proseso na may iba't ibang layunin.
1. Ang pagpapatunay at sertipikasyon ay ang proseso ng pagtukoy ng mga depekto sa isang software system.
2. Ang pag-debug ay ang proseso ng pag-localize ng mga depekto (mga error) at pagwawasto sa mga ito (Larawan 20.2).
kanin. 20.2. Proseso ng pag-debug
Walang mga simpleng paraan para sa pag-debug ng mga programa. Nakikita ng mga may karanasang debugger ang mga error sa pamamagitan ng paghahambing ng mga pattern ng output ng pagsubok sa output ng mga system na sinusubok. Ang paghahanap ng isang error ay nangangailangan ng kaalaman sa mga uri ng error, mga pattern ng output, programming language, at ang proseso ng programming. Ang kaalaman tungkol sa proseso ng pagbuo ng software ay napakahalaga. Alam ng mga debugger ang pinakakaraniwang error sa programmer (halimbawa, ang mga nauugnay sa pagtaas ng counter value). Ang mga error na tipikal ng ilang mga programming language ay isinasaalang-alang din, halimbawa ang mga nauugnay sa paggamit ng mga pointer sa wikang C.
Ang paghahanap ng mga error sa program code ay hindi palaging isang madaling proseso dahil ang error ay hindi kinakailangang matatagpuan malapit sa lugar sa program code kung saan nangyari ang problema. Upang ma-localize ang mga error, ang debugger programmer ay bubuo ng mga karagdagang pagsubok sa software na makakatulong na matukoy ang pinagmulan ng error sa program. Maaaring kailanganin na manu-manong subaybayan ang pagpapatupad ng programa.
Ang mga interactive na tool sa pag-debug ay bahagi ng isang hanay ng mga tool sa suporta sa wika na isinama sa system ng compilation ng code. Nagbibigay sila ng isang espesyal na kapaligiran sa pagpapatupad ng programa kung saan maaaring ma-access ang isang talahanayan ng mga identifier at, mula doon, ang mga variable na halaga. Kadalasang kinokontrol ng mga user ang pagpapatupad ng isang programa sa sunud-sunod na paraan, na sunud-sunod na gumagalaw mula sa pahayag patungo sa pahayag. Matapos maisakatuparan ang bawat pahayag, ang mga halaga ng mga variable ay nasuri at ang mga posibleng pagkakamali ay natukoy.
Ang isang error na nakita sa programa ay naitama, pagkatapos nito ay kinakailangan upang suriin muli ang programa. Upang gawin ito, maaari mong suriin muli ang programa o ulitin ang nakaraang pagsubok. Ginagamit ang muling pagsusuri upang matiyak na ang mga pagbabagong ginawa sa isang programa ay hindi nagpasok ng mga bagong bug sa system, dahil sa pagsasagawa, isang mataas na porsyento ng "pag-aayos ng bug" ay maaaring ganap na mabigo o magpasok ng mga bagong bug sa programa.
Sa prinsipyo, sa panahon ng retesting pagkatapos ng bawat pag-aayos, ang lahat ng mga pagsubok ay dapat na tumakbo muli, ngunit sa pagsasanay ang diskarte na ito ay masyadong mahal. Samakatuwid, kapag nagpaplano ng proseso ng pagsubok, ang mga dependency sa pagitan ng mga bahagi ng system ay tinutukoy at ang mga pagsubok ay itinalaga sa bawat bahagi. Posibleng masubaybayan ang mga elemento ng software gamit ang mga espesyal na kaso ng pagsubok (data ng pagsubok) na iniayon sa mga elementong iyon. Kung nakadokumento ang mga resulta ng bakas, isang subset lamang ng buong set ng data ng pagsubok ang maaaring gamitin upang subukan ang binagong elemento ng software at ang mga nakadependeng bahagi nito.
Pagpapatunay (pagkumpirma ng kawastuhan) - binubuo ng pagsuri at pagpapatunay sa kawastuhan ng binuo na programa na may kaugnayan sa hanay ng mga pormal na pahayag na ipinakita sa detalye at ganap na pagtukoy sa kaugnayan sa pagitan ng input at output data ng programang ito. Sa kasong ito, ang ugnayan sa pagitan ng mga variable sa input at output ng programa ay nasuri hindi sa anyo ng mga halaga, tulad ng sa pagsubok, ngunit sa anyo ng mga paglalarawan ng kanilang mga katangian, na nagpapakita ng kanilang mga sarili sa panahon ng anumang pagproseso ng mga variable na ito na kinokontrol. sa programa.
Ang pagpapatunay ng isang programa, sa prinsipyo, ay nag-aalis ng pangangailangan para sa pagsubok at pag-debug, dahil sa parehong oras, sa isang mas mataas na antas ng mga konsepto at paglalarawan ng lahat ng mga variable, ang kawastuhan ng mga proseso, ang kanilang pagproseso at pagbabago ay itinatag.
Ang kakanyahan ng bawat programa ay maaaring kinakatawan ng mga paglalarawan ng mga relasyon sa pagitan ng input at output data. Ang mga ugnayang ito ay ginawang pormal sa pamamagitan ng 1 detalye ng software. Sa totoong mga pag-unlad, ang pormalisasyon ng mga relasyong ito ay hindi masama, at ang ilan sa mga relasyon ay nilinaw sa proseso ng pagbuo ng programa. Ang mga hindi kumpletong tinukoy ay hindi sapat upang patunayan ang kawastuhan ng mga programa. Sa pamamagitan lamang ng kumpleto at tumpak na pormalisasyon ng lahat ng kundisyon at koneksyon sa pagitan ng input at output data nagiging posible na gamitin ang mga ito para sa awtomatikong pag-verify.
Paraan ng mga pahayag na pasaklaw.
Upang pag-aralan ang pamamaraang ito, ang programa ay binibigyan ng mga pahayag tungkol sa mga katangian ng mga variable nito sa ilang mga punto:
a) Ang mga variable ng input ay hindi nagbabago sa panahon ng pagpapatupad ng programa;
b) Ang mga estado ng mga variable sa mga intermediate na punto ay inilarawan;
c) Inilalarawan ang mga variable ng output gamit ang mga relasyon sa pagitan ng mga variable pagkatapos makumpleto ang programa.
Binubuo ang pag-verify ng sunud-sunod na pagpapakita na mula sa mga variable ng input at pagbabagong ginawa sa unang hakbang, ang katotohanan ng pahayag na nabuo sa susunod na intermediate point ay sumusunod.
Upang i-verify ang mga programa, tatlong wika ang kinakailangan:
· Wika para sa pagsulat ng mga teksto ng programa;
· Wika para sa pagbabalangkas ng mga kundisyon sa pag-verify;
· Wika ng pagbuo at patunay ng kawastuhan.
Dahil ang mga wikang ito ay naiiba sa isang makabuluhang lawak, ang sitwasyong ito ay isa sa mga aplikasyon ng pag-verify.
Ang patunay ng kawastuhan ay may mga sumusunod na pakinabang:
1. Kumakatawan sa isang malinaw na pormal na proseso.
2. Nangangailangan ng pagsusuri. Ginagawang posible ng proseso ng proof-of-correctness na suriin ang mga bahagi ng mga programa na susuriin lamang nang random.
3. nililinaw ang mga intermediate na resulta ng mga kalkulasyon. Ang pagsusulat ng mga expression ay pinipilit ang programmer na malinaw na bumalangkas ng kanyang mga pagpapalagay tungkol sa mga resulta ng mga kalkulasyon sa mga napiling punto sa programa.
4. Tinutukoy ang mga dependencies. Sa proseso ng pagpapatunay ng mga programa, nagsisimulang maunawaan kung anong mga pagpapalagay tungkol sa data ng pag-input ang hindi tahasang nasubok sa iba't ibang bahagi ng programa.
Mga disadvantages ng pamamaraan:
1. Kahirapan; kahit sa maliliit mga simpleng programa Ang mga kalkulasyon ay napaka-kumplikado, na maaaring humantong sa mga pagkakamali.
2. Mga pagkakamali Dahil sa pagiging kumplikado ng pamamaraan, madaling magkamali kapwa sa pagbuo ng mga pahayag na pinatutunayan at sa patunay.
3. Mga kahirapan sa pagtatrabaho sa mga array.
4. Kakulangan ng makapangyarihang mathematical apparatus.
5. Mataas na lakas ng paggawa ang pagsubok sa isang programa ay nangangailangan ng mas maraming paggawa kaysa sa pagsulat nito (2 hanggang 6 na beses).
6. Kakulangan ng pagpapahayag. Kadalasan ay hindi madaling bumalangkas ng isang kumikitang pahayag para sa kung ano ang intuitively ay lumilitaw na isang napakasimpleng pagkalkula:
7. Kahirapan sa pag-unawa.
8. Ang pangangailangan para sa pagsasanay. Ang pamamaraang ito ay nangangailangan ng malawak na pagsasanay at pagsasanay.
Ang layunin ng kursong ito ay ipakita ang isang komprehensibong pagtingin sa proseso ng pag-verify ng software. Ang paksa ng talakayan ay iba't ibang mga diskarte at pamamaraan na ginagamit sa larangan ng pagpapatunay at, sa partikular, pagsubok ng software. Ipinapalagay na ang software na binuo ay bahagi ng higit pa karaniwang sistema. Kasama sa naturang sistema ang mga bahagi ng hardware, impormasyon at organisasyon (taong gumagamit, operator ng tao, atbp.), na posibleng binuo ng iba't ibang mga koponan. Samakatuwid, kinakailangan ang mga dokumento sa pag-unlad na tumutukoy sa mga kinakailangan para sa iba't ibang bahagi ng system at ang mga patakaran para sa kanilang pakikipag-ugnayan. Bilang karagdagan, ipinapalagay na ang mga pagkabigo ng system ay maaaring humantong sa mga kahihinatnan ng isang kalubhaan o iba pa, samakatuwid, kapag bumubuo ng software, ang mga pagsisikap na ginugol sa pagtukoy ng mga nakatagong depekto ay kinakailangan at makatwiran. Una sa lahat, may kinalaman ito sa mga tool at pamamaraan sa pag-verify ng software. Kasama sa kurso ang ilang mga praktikal na klase, naglalarawan, gamit ang isang simpleng sistema bilang halimbawa, ang mga diskarte at pamamaraan ng pag-verify ng software sa Microsoft Visual Studio 2005 Team Edition para sa Software Testers na kapaligiran. Ang publikasyong ito ay bahagi ng Course Library, na binuo bilang bahagi ng programa ng pakikipagtulungang akademiko ng MSDN Academic Alliance (MSDN AA).
Ang teksto sa ibaba ay nakuha sa pamamagitan ng awtomatikong pagkuha mula sa orihinal na PDF na dokumento at nilayon bilang isang preview.
Walang mga larawan (mga larawan, formula, graph).
kanin. 7 Pagsubok, pagpapatunay at pagpapatunay Pagpapatunay ng software – higit pa pangkalahatang konsepto kaysa sa pagsubok. Ang layunin ng pag-verify ay upang matiyak na ang item na nabe-verify (mga kinakailangan o program code) ay nakakatugon sa mga kinakailangan, ipinatupad nang walang hindi sinasadyang mga function, at nakakatugon sa mga detalye at pamantayan ng disenyo. Kasama sa proseso ng pag-verify ang mga inspeksyon, pagsubok ng code, pagsusuri ng mga resulta ng pagsubok, pagbuo at pagsusuri ng mga ulat ng problema. Kaya, karaniwang tinatanggap na ang proseso ng pagsubok ay mahalaga bahagi proseso ng pagpapatunay, ang parehong palagay ay ginawa sa kursong ito ng pagsasanay. Ang pagpapatunay ng isang software system ay isang proseso na ang layunin ay patunayan na, bilang resulta ng pagbuo ng system, nakamit namin ang mga layunin na binalak naming makamit sa pamamagitan ng paggamit nito. Sa madaling salita, sinusuri ng pagpapatunay na natutugunan ng system ang mga inaasahan ng customer. Ang mga isyung nauugnay sa pagpapatunay ay lampas sa saklaw nito kursong pagsasanay at kumakatawan sa isang hiwalay na kawili-wiling paksa para sa pag-aaral. Kung titingnan mo ang tatlong prosesong ito sa mga tuntunin ng tanong na kanilang sinasagot, sinasagot ng pagsubok ang tanong na "Paano ito ginagawa?" o “Natutugunan ba ng pag-uugali ng binuong programa ang mga kinakailangan?”, pag-verify – “Ano ang nagawa na?” o “Natutugunan ba ng binuong system ang mga kinakailangan?”, at ang pagpapatunay ay “Nagawa ba ang kailangan nitong gawin?” o "Natutugunan ba ng binuong system ang mga inaasahan ng customer?" 1.7. Ang dokumentasyon na nilikha sa iba't ibang yugto ng siklo ng buhay Ang pag-synchronize ng lahat ng mga yugto ng pag-unlad ay nangyayari sa tulong ng mga dokumento na nilikha sa bawat yugto. Ginagawa rin ang dokumentasyon sa isang tuwid na linya ikot ng buhay– sa panahon ng pagbuo ng isang software system, at vice versa – sa panahon ng pag-verify nito. Subukan natin, gamit ang halimbawa ng isang hugis-V na siklo ng buhay, upang masubaybayan kung anong mga uri ng mga dokumento ang nilikha sa bawat isa sa mga segment, at kung anong mga ugnayan ang umiiral sa pagitan ng mga ito (Larawan 8). Ang resulta ng yugto ng pag-unlad ng mga kinakailangan ng system ay ang nabuong mga kinakailangan ng system - isang dokumentong naglalarawan pangkalahatang mga prinsipyo pagpapatakbo ng system, ang pakikipag-ugnayan nito sa " kapaligiran» - mga gumagamit ng system, pati na rin ang software at hardware na nagsisiguro sa operasyon nito. Karaniwan, kasabay ng mga kinakailangan ng system, isang plano sa pag-verify ay nilikha at isang diskarte sa pag-verify ay tinukoy. Tinutukoy ng mga dokumentong ito pangkalahatang diskarte sa kung paano isasagawa ang pagsubok, anong mga pamamaraan ang gagamitin, anong mga aspeto ng hinaharap na sistema ang dapat isailalim sa maingat na pagsubok. Ang isa pang gawain na nalutas sa pamamagitan ng pagtukoy ng isang diskarte sa pag-verify ay ang pagtukoy sa lokasyon ng iba't ibang mga proseso ng pag-verify at ang kanilang mga koneksyon sa mga proseso ng pag-unlad. 20 Ang proseso ng pag-verify na gumagana sa mga kinakailangan ng system ay ang proseso ng pagpapatunay ng mga kinakailangan at paghahambing ng mga ito sa mga tunay na inaasahan ng customer. Sa hinaharap, sabihin natin na ang proseso ng pagpapatunay ay naiiba sa mga pagsubok sa pagtanggap na isinagawa kapag inilipat ang tapos na system sa customer, bagama't maaari itong ituring na bahagi ng naturang mga pagsubok. Ang pagpapatunay ay isang paraan ng pagpapatunay hindi lamang sa kawastuhan ng pagpapatupad ng system mula sa pananaw ng customer, kundi pati na rin sa kawastuhan ng mga prinsipyong pinagbabatayan ng pag-unlad nito. kanin. 8 Mga proseso at dokumento sa pagbuo ng mga sistema ng software Ang mga kinakailangan ng system ay ang batayan para sa proseso ng pagbuo ng mga kinakailangan sa pagganap at arkitektura ng proyekto. Sa prosesong ito, ang mga pangkalahatang kinakailangan para sa software ng system at ang mga function na dapat nitong gawin ay binuo. Kadalasang kinabibilangan ng mga functional na kinakailangan ang pagtukoy ng mga pattern ng gawi ng system sa normal at abnormal na mga sitwasyon, mga panuntunan para sa pagproseso ng data, at mga kahulugan ng user interface. Ang teksto ng kinakailangan, bilang panuntunan, ay kinabibilangan ng mga salitang "dapat, dapat" at may istraktura ng form na "Kung ang halaga ng temperatura sa ABC sensor ay umabot sa 30 degrees Celsius o mas mataas, ang system ay dapat huminto sa pag-isyu ng audio signal. ” Ang mga kinakailangan sa pag-andar ay ang batayan para sa pagbuo ng arkitektura ng system - inilalarawan ang istraktura nito sa mga tuntunin ng mga subsystem at istrukturang yunit ng wika kung saan isinasagawa ang pagpapatupad - mga lugar, klase, module, function, atbp. Batay sa mga kinakailangan sa pagganap, ang mga kinakailangan sa pagsubok ay nakasulat - mga dokumento na naglalaman ng kahulugan ng mga pangunahing punto na dapat suriin upang matiyak ang tamang pagpapatupad ng mga kinakailangan sa pagganap. Kadalasan ang mga kinakailangan sa pagsusulit ay nagsisimula sa mga salitang "Subukan Iyan" at naglalaman ng mga sanggunian sa kanilang kaukulang mga kinakailangan sa pagganap. Ang isang halimbawa ng mga kinakailangan sa pagsubok para sa functional na kinakailangan sa itaas ay "I-verify na kapag ang temperatura sa ABC sensor ay bumaba sa ibaba 30 degrees Celsius, ang system ay naglalabas ng isang babala na tono" at "I-verify na kapag ang halaga ng temperatura sa ABC sensor ay higit sa 30 degrees Celsius” , hindi gumagawa ng sound signal ang system." 21 Ang isa sa mga problemang bumangon kapag nagsusulat ng mga kinakailangan sa pagsusulit ay ang pangunahing di-mapatunayan ng ilang mga kinakailangan, halimbawa, ang kinakailangan na "Ang user interface ay dapat na intuitive" ay hindi mabe-verify nang walang malinaw na kahulugan ng kung ano ang bumubuo ng isang madaling gamitin na interface. Ang ganitong mga hindi tiyak na mga kinakailangan sa paggana ay kadalasang kasunod na binago. Ang mga tampok na arkitektura ng system ay maaari ding magsilbi bilang isang mapagkukunan para sa paglikha ng mga kinakailangan sa pagsubok na isinasaalang-alang ang mga tampok ng pagpapatupad ng software ng system. Ang isang halimbawa ng naturang pangangailangan ay, halimbawa, "Tingnan na ang halaga ng temperatura sa ABC sensor ay hindi lalampas sa 255." Batay sa mga kinakailangan sa pagganap at arkitektura, isinulat ang code ng system, at upang mapatunayan ito, isang plano ng pagsubok ay inihanda batay sa mga kinakailangan sa pagsubok - isang paglalarawan ng pagkakasunud-sunod ng mga kaso ng pagsubok na sinusuri ang pagsunod ng pagpapatupad ng system sa mga kinakailangan. Ang bawat kaso ng pagsubok ay naglalaman ng isang tiyak na paglalarawan ng mga halaga na ibinibigay sa input ng system, ang mga halaga na inaasahan sa output, at isang paglalarawan ng senaryo ng pagpapatupad ng pagsubok. Depende sa test object, ang test plan ay maaaring ihanda alinman sa anyo ng isang program sa ilang programming language, o sa anyo ng input data file para sa toolkit na nagpapatupad ng system sa ilalim ng pagsubok at naglilipat dito ng mga halaga. tinukoy sa plano ng pagsubok, o sa anyo ng mga tagubilin para sa system ng gumagamit na naglalarawan ng mga kinakailangang aksyon na isasagawa upang subukan ang iba't ibang mga function ng system. Bilang resulta ng pagpapatupad ng lahat ng mga kaso ng pagsubok, ang mga istatistika ay nakolekta sa tagumpay ng pagsubok - ang porsyento ng mga kaso ng pagsubok kung saan ang aktwal na mga halaga ng output ay kasabay ng mga inaasahan, ang tinatawag na mga naipasa na mga pagsubok. Ang mga nabigong pagsusulit ay ang paunang data para sa pagsusuri ng mga sanhi ng mga error at ang kanilang kasunod na pagwawasto. Sa yugto ng pagsasama, ang mga indibidwal na module ng system ay pinagsama-sama sa isang buo at ang mga kaso ng pagsubok ay isinasagawa na nagsusuri sa buong pag-andar ng system. Naka-on huling yugto Ang tapos na sistema ay inihatid sa customer. Bago ang pagpapatupad, ang mga espesyalista sa customer, kasama ang mga developer, ay nagsasagawa ng mga pagsubok sa pagtanggap - sinusuri nila ang mga function na kritikal para sa user alinsunod sa isang paunang naaprubahang programa ng pagsubok. Kung matagumpay na nakumpleto ang mga pagsubok, ililipat ang system sa customer, kung hindi, ipapadala ito para sa rebisyon. 1.8. Mga uri ng mga proseso ng pagsubok at pag-verify at ang kanilang lugar sa iba't ibang mga modelo ng siklo ng buhay 1.8.1. Pagsubok sa unit Ang mga maliliit na module (procedure, klase, atbp.) ay napapailalim sa unit testing. Kapag sinusubukan ang isang medyo maliit na module na may sukat na 100-1000 linya, posible na suriin, kung hindi lahat, pagkatapos ay hindi bababa sa maraming mga lohikal na sangay sa pagpapatupad, iba't ibang mga landas sa data dependency graph, at mga halaga ng hangganan ng mga parameter. Alinsunod dito, ang pamantayan sa saklaw ng pagsubok ay binuo (lahat ng mga operator, lahat ng lohikal na sangay, lahat ng mga boundary point, atbp. ay sakop). . Ang pagsubok sa unit ay karaniwang ginagawa sa bawat independiyenteng software module at ito marahil ang pinakakaraniwang uri ng pagsubok, lalo na para sa maliliit hanggang katamtamang laki ng mga system. 1.8.2. Pagsusuri ng integrasyon Ang pagsuri sa kawastuhan ng lahat ng mga module, sa kasamaang-palad, ay hindi ginagarantiyahan ang tamang paggana ng sistema ng mga module. Ang panitikan kung minsan ay tinatalakay 22 ang "klasikal" na modelo ng hindi wastong organisasyon ng pagsubok ng isang sistema ng mga module, na kadalasang tinatawag na "malaking lukso" na pamamaraan. Ang kakanyahan ng pamamaraan ay subukan muna ang bawat module nang hiwalay, pagkatapos ay pagsamahin ang mga ito sa isang system at subukan ang buong system. Para sa malalaking sistema ito ay hindi makatotohanan. Sa diskarteng ito, maraming oras ang gugugulin sa paglo-localize ng mga error, at mananatiling mababa ang kalidad ng pagsubok. Ang isang alternatibo sa "malaking paglukso" ay ang pagsubok sa pagsasama, kapag ang sistema ay binuo sa mga yugto, ang mga pangkat ng mga module ay unti-unting idinagdag. 1.8.3. Pagsusuri ng system Ang isang ganap na ipinatupad na produkto ng software ay napapailalim sa pagsubok ng system. Sa yugtong ito, ang tester ay hindi interesado sa tamang pagpapatupad ng mga indibidwal na pamamaraan at pamamaraan, ngunit sa buong programa sa kabuuan, tulad ng nakikita ng end user. Ang mga pagsubok ay batay sa Pangkalahatang mga kinakailangan sa programa, kabilang ang hindi lamang ang tamang pagpapatupad ng mga pag-andar, kundi pati na rin ang pagganap, oras ng pagtugon, paglaban sa mga pagkabigo, pag-atake, mga error ng gumagamit, atbp. Para sa pagsubok sa system at bahagi, ginagamit ang mga partikular na uri ng pamantayan sa saklaw ng pagsubok (halimbawa, lahat ng tipikal na senaryo sa trabaho ay sakop, lahat ng senaryo na may abnormal na sitwasyon, magkapares na komposisyon ng mga sitwasyon, atbp.). 1.8.4. Pagsubok sa Pag-load Hindi lamang nagbibigay ang pagsusuri sa pag-load ng predictive na data sa performance ng system sa ilalim ng pag-load na gumagabay sa mga desisyon sa arkitektura, ngunit nagbibigay din ng impormasyon sa pagpapatakbo sa mga technical support team, pati na rin sa mga project at configuration manager na may pananagutan sa paggawa ng pinaka produktibong mga configuration ng hardware at software. Ang pagsubok sa pag-load ay nagbibigay-daan sa development team na gumawa ng mas matalinong mga desisyon na naglalayong bumuo ng pinakamainam na komposisyon ng arkitektura. Ang customer, sa kanyang bahagi, ay nakakakuha ng pagkakataon na magsagawa ng mga pagsubok sa pagtanggap sa ilalim ng mga kondisyong malapit sa mga tunay. 1.8.5. Mga pormal na inspeksyon Ang pormal na inspeksyon ay isa sa mga paraan upang maberipika ang mga dokumento at program code na nilikha sa panahon ng proseso ng pagbuo ng software. Sa panahon ng isang pormal na inspeksyon, isang pangkat ng mga espesyalista ang independiyenteng nagbe-verify ng pagkakatugma ng mga inspeksyon na dokumento sa orihinal na mga dokumento. Ang kalayaan ng inspeksyon ay sinisiguro ng katotohanan na ito ay isinasagawa ng mga inspektor na hindi lumahok sa pagbuo ng dokumentong siniyasat. 1.9. Pagpapatunay ng sertipikadong software Magbigay tayo ng ilang kahulugan na tumutukoy pangkalahatang istraktura proseso ng sertipikasyon ng software: Ang sertipikasyon ng software ay ang proseso ng pagtatatag at opisyal na pagkilala na ang pagbuo ng software ay isinagawa alinsunod sa mga tinukoy na kinakailangan. Sa panahon ng proseso ng sertipikasyon, mayroong pakikipag-ugnayan sa pagitan ng Aplikante, ang Nagpapatunay na Katawan at ang Katawan ng Tagapangasiwa Ang Aplikante ay isang organisasyong nagsusumite ng aplikasyon sa kaugnay na Nagpapatunay na Katawan upang makatanggap ng isang sertipiko (ng pagkakaayon, kalidad, pagiging angkop, atbp.) ng isang. produkto. Ang katawan na nagpapatunay ay isang organisasyon na isinasaalang-alang ang aplikasyon ng Aplikante para sa Sertipikasyon ng Software at alinman sa independyente o sa pamamagitan ng pagbuo ng isang espesyal na komisyon ay nagsasagawa ng isang hanay ng mga pamamaraan na naglalayong isagawa ang proseso ng Software Certification ng Aplikante. 23 Supervisory body - isang komisyon ng mga espesyalista na sumusubaybay sa mga proseso ng pag-unlad ng Aplikante para sa sertipikasyon sistema ng impormasyon at pagbibigay ng opinyon sa pagsunod sa prosesong ito sa ilang mga kinakailangan, na isinumite para sa pagsasaalang-alang sa Awtoridad ng Pagpapatibay. Ang sertipikasyon ay maaaring naglalayong makakuha ng isang sertipiko ng pagsang-ayon o isang sertipiko ng kalidad. Sa unang kaso, ang resulta ng sertipikasyon ay pagkilala sa pagsunod sa mga proseso ng pag-unlad na may ilang mga pamantayan, at ang pag-andar ng system na may ilang mga kinakailangan. Ang isang halimbawa ng naturang mga kinakailangan ay maaaring mga dokumento ng gabay Serbisyong pederal sa teknikal at kontrol sa pag-export sa larangan ng seguridad ng software system. Sa pangalawang kaso, ang resulta ay pagkilala sa pagsunod sa mga proseso ng pag-unlad na may ilang mga pamantayan na ginagarantiyahan ang isang naaangkop na antas ng kalidad ng ginawang produkto at ang pagiging angkop nito para sa paggamit sa ilang mga kundisyon. Ang isang halimbawa ng naturang mga pamantayan ay ang serye ng mga internasyonal na pamantayan ng kalidad na ISO 9000:2000 (GOST R ISO 9000-2001) o mga pamantayan ng aviation DO-178B, AS9100, AS9006. Ang pagsubok sa certifiable na software ay may dalawang pantulong na layunin: Ang unang layunin ay ipakita na ang software ay nakakatugon sa mga kinakailangan para dito. Ang pangalawang layunin ay ipakita nang may mataas na antas ng kumpiyansa na ang mga error na maaaring humantong sa mga hindi katanggap-tanggap na sitwasyon ng pagkabigo, gaya ng tinukoy ng proseso ng pagtatasa ng kaligtasan ng fault ng system, ay natukoy sa panahon ng proseso ng pagsubok. Halimbawa, ang DO-178B ay nangangailangan ng mga sumusunod upang matugunan ang mga layunin sa pagsubok ng software: Ang mga pagsubok ay dapat na pangunahing nakabatay sa mga kinakailangan ng software; Ang mga pagsubok ay dapat na idinisenyo upang i-verify ang tamang paggana at upang ilantad ang mga potensyal na error. Ang pagsusuri sa pagkakumpleto ng mga pagsubok batay sa mga kinakailangan ng software ay dapat matukoy kung aling mga kinakailangan ang hindi nasubok. Ang pagsusuri sa pagkakumpleto ng mga pagsubok batay sa istraktura ng code ng programa ay dapat matukoy kung aling mga istruktura ang hindi naisakatuparan sa panahon ng pagsubok. Pinag-uusapan din ng pamantayang ito ang tungkol sa pagsubok na nakabatay sa mga kinakailangan. Napag-alaman na ang diskarteng ito ay pinakamabisa sa pagtukoy ng mga error. Ang mga alituntunin para sa pagpili ng mga test case batay sa mga kinakailangan ay kinabibilangan ng mga sumusunod: Upang makamit ang mga layunin ng software testing, dalawang kategorya ng mga pagsubok ang dapat isagawa: mga pagsubok para sa mga normal na sitwasyon at mga pagsubok para sa abnormal (hindi kinakailangan, matatag) na mga sitwasyon. Ang mga partikular na kaso ng pagsubok ay dapat na binuo para sa mga kinakailangan ng software at mga mapagkukunan ng error na likas sa proseso ng pagbuo ng software. Ang layunin ng mga pagsubok para sa mga normal na sitwasyon ay upang ipakita ang kakayahan ng software na tumugon sa mga normal na input at kundisyon kung kinakailangan. 24 Ang layunin ng mga pagsubok para sa mga abnormal na sitwasyon ay upang ipakita ang kakayahan ng software na tumugon nang sapat sa mga abnormal na input at kundisyon, sa madaling salita, hindi ito dapat maging sanhi ng pagkabigo ng system. Ang mga kategorya ng pagkabigo para sa isang sistema ay itinatag sa pamamagitan ng pagtukoy sa kalubhaan ng sitwasyon ng pagkabigo sa sasakyang panghimpapawid at mga sakay nito. Ang anumang error sa software ay maaaring maging sanhi ng pagkabigo na nag-aambag sa isang sitwasyon ng pagkabigo. Kaya, ang antas ng integridad ng software na kinakailangan para sa ligtas na operasyon ay nauugnay sa mga sitwasyon ng pagkabigo para sa system. Mayroong 5 antas ng mga sitwasyon ng pagkabigo mula sa hindi gaanong mahalaga hanggang sa kritikal na mapanganib. Ayon sa mga antas na ito, ipinakilala ang konsepto ng antas ng pagiging kritikal ng software. Tinutukoy ng antas ng pagiging kritikal ang komposisyon ng dokumentasyong ibinigay sa katawan ng sertipikasyon, at samakatuwid ay ang lalim ng mga proseso ng pagbuo at pag-verify ng system. Halimbawa, ang bilang ng mga uri ng dokumento at ang dami ng gawaing pagpapaunlad ng system na kinakailangan para sa sertipikasyon hanggang sa pinakamababang antas ng kritikal na DO-178B ay maaaring mag-iba ng isa o dalawang order ng magnitude mula sa bilang at dami na kinakailangan para sa sertipikasyon hanggang sa pinakamaraming mataas na lebel. Ang mga partikular na kinakailangan ay tinutukoy ng pamantayan kung saan pinlano ang sertipikasyon. 25 PAKSA 2. Testing program code (mga lektura 2-5) 2.1. Mga gawain at layunin ng pagsubok sa code ng programa Ang pagsubok sa code ng programa ay ang proseso ng pagpapatupad ng code ng programa, na naglalayong tukuyin ang mga depektong umiiral dito. Ang isang depekto dito ay nauunawaan bilang isang seksyon ng program code, ang pagpapatupad nito, sa ilalim ng ilang mga kundisyon, ay humahantong sa hindi inaasahang pag-uugali ng system (ibig sabihin, pag-uugali na hindi nakakatugon sa mga kinakailangan). Ang hindi inaasahang pag-uugali ng system ay maaaring humantong sa mga malfunction at pagkabigo sa kasong ito, nagsasalita sila ng mga makabuluhang depekto sa code ng programa. Ang ilang mga depekto ay nagdudulot ng mga maliliit na problema na hindi nakakaabala sa paggana ng system, ngunit ginagawa itong medyo mahirap na magtrabaho dito. Sa kasong ito, nagsasalita sila ng katamtaman o menor de edad na mga depekto. Ang gawain ng pagsubok sa diskarteng ito ay upang matukoy ang mga kondisyon kung saan lumilitaw ang mga depekto ng system at itala ang mga kundisyong ito. Karaniwang hindi kasama sa mga gawain sa pagsubok ang pagtukoy sa mga partikular na may sira na seksyon ng program code at hindi kailanman kasama ang pagwawasto ng mga depekto - ito ay isang gawain sa pag-debug na ginagawa batay sa mga resulta ng pagsubok sa system. Ang layunin ng paggamit ng isang pamamaraan sa pagsubok ng code ng programa ay upang mabawasan ang bilang ng mga depekto, lalo na ang mga makabuluhang, sa huling produkto. Ang pagsubok lamang ay hindi magagarantiya kumpletong kawalan mga depekto sa system code. Gayunpaman, kasama ng mga proseso ng pag-verify at pagpapatunay na naglalayong alisin ang hindi pagkakapare-pareho at hindi kumpleto dokumentasyon ng proyekto(sa partikular, mga kinakailangan para sa system), tinitiyak ng maayos na pagsubok na natutugunan ng system ang mga kinakailangan at kumikilos alinsunod sa mga ito sa lahat ng nilalayong sitwasyon. Kapag bumubuo ng mga sistema ng mas mataas na pagiging maaasahan, halimbawa, mga aviation, ang mga garantiya ng pagiging maaasahan ay nakakamit sa pamamagitan ng isang malinaw na organisasyon ng proseso ng pagsubok, pagtukoy ng koneksyon nito sa iba pang mga proseso ng ikot ng buhay, at pagpapakilala ng mga quantitative na katangian na nagpapahintulot sa pagtatasa ng tagumpay ng pagsubok. Bukod dito, mas mataas ang mga kinakailangan para sa pagiging maaasahan ng system (ang antas ng pagiging kritikal nito), mas mahigpit ang mga kinakailangan na ipinapataw. Kaya, una sa lahat, hindi namin isinasaalang-alang ang mga tiyak na resulta ng pagsubok sa isang tiyak na sistema, ngunit pangkalahatang organisasyon proseso ng pagsubok, gamit ang diskarte na "isang maayos na proseso ay gumagawa ng isang kalidad na resulta." Ang pamamaraang ito ay karaniwan sa maraming internasyonal at pamantayan ng kalidad ng industriya, na tatalakayin nang mas detalyado sa pagtatapos ng kursong ito. Ang kalidad ng binuong sistema na may ganitong paraan ay bunga ng organisadong proseso ng pag-unlad at pagsubok, at hindi isang independiyenteng hindi makontrol na resulta. Dahil ang mga modernong software system ay medyo malaki, ang functional decomposition method ay ginagamit kapag sinusubukan ang kanilang program code. Ang system ay nahahati sa magkakahiwalay na mga module (mga klase, namespace, atbp.) na may functionality at mga interface na tinukoy ng mga kinakailangan. Pagkatapos nito, ang bawat module ay sinubok nang hiwalay - isinasagawa ang pagsubok sa yunit. Pagkatapos ay tipunin ang mga indibidwal na module sa mas malalaking pagsasaayos - isinagawa ang integration testing, at sa wakas ang system sa kabuuan ay nasubok - isinagawa ang system testing. Mula sa punto ng view ng code, ang unit, integration at system testing ay may maraming pagkakatulad, kaya ang paksang ito ay tututuon sa unit testing, na may mga tampok ng integration at system testing na tatalakayin sa ibang pagkakataon. 26 Sa panahon ng pagsubok sa unit, ang bawat module ay sinusuri kapwa para sa pagsunod sa mga kinakailangan at para sa kawalan ng mga problemang bahagi ng program code na maaaring magdulot ng mga pagkabigo at malfunctions sa system. Bilang isang patakaran, ang mga module ay hindi gumagana sa labas ng system - tumatanggap sila ng data mula sa iba pang mga module, pinoproseso ito at ipinadala pa ito. Upang, sa isang banda, upang ihiwalay ang module mula sa system at alisin ang impluwensya ng mga potensyal na error sa system, at sa kabilang banda, upang maibigay ang module sa lahat ng kinakailangang data, isang pagsubok na kapaligiran ang ginagamit. Ang gawain ng kapaligiran ng pagsubok ay lumikha ng isang runtime na kapaligiran para sa module at tularan ang lahat ng mga panlabas na interface na ina-access ng module. Tatalakayin sa paksang ito ang mga tampok ng pag-aayos ng isang kapaligiran sa pagsubok. Ang isang tipikal na pamamaraan ng pagsubok ay binubuo ng paghahanda at pagpapatupad ng mga kaso ng pagsubok (tinatawag din na simpleng mga pagsubok). Sinusuri ng bawat halimbawa ng pagsubok ang isang "sitwasyon" sa pag-uugali ng module at binubuo ng isang listahan ng mga halaga na ipinasa sa input ng module, isang paglalarawan ng paglulunsad at pagpapatupad ng pagproseso ng data - isang test script, at isang listahan ng mga halaga na inaasahan sa output ng module kung ito ay kumikilos nang tama. Ang mga script ng pagsubok ay pinagsama-sama sa paraang hindi kasama ang pag-access sa panloob na data ng module ang lahat ng pakikipag-ugnayan ay dapat mangyari lamang sa pamamagitan ng mga panlabas na interface nito. Ang pagpapatupad ng isang test case ay sinusuportahan ng isang pagsubok na kapaligiran, na kinabibilangan ng isang software na pagpapatupad ng pagsubok na script. Nagsisimula ang pagpapatupad sa pamamagitan ng pagpasa ng data ng input sa module at pagpapatakbo ng script. Ang aktwal na data ng output na natanggap mula sa module bilang resulta ng pagpapatupad ng script ay nai-save at inihambing sa inaasahan. Kung magkatugma ang mga ito, ang pagsusulit ay maituturing na pumasa kung hindi, ito ay itinuturing na nabigo. Ang bawat nabigong pagsusulit ay nagpapahiwatig ng alinman sa isang depekto sa module na sinusuri, o sa kapaligiran ng pagsubok, o sa paglalarawan ng pagsubok. Ang hanay ng mga paglalarawan ng mga kaso ng pagsubok ay bumubuo ng isang plano sa pagsubok - ang pangunahing dokumento na tumutukoy sa pamamaraan ng pagsubok para sa isang module ng software. Tinukoy ng plano ng pagsubok hindi lamang ang mga test case mismo, kundi pati na rin ang pagkakasunud-sunod ng paglitaw ng mga ito, na maaari ding maging mahalaga. Ang istraktura at mga tampok ng mga plano sa pagsubok ay tatalakayin sa paksang ito ang mga problema na nauugnay sa pagkakasunud-sunod ng mga kaso ng pagsubok ay tatalakayin sa paksang "Pag-uulit ng pagsubok". Kapag sumusubok, madalas na kinakailangang isaalang-alang hindi lamang ang mga kinakailangan ng system, kundi pati na rin ang istraktura ng code ng programa ng module na sinusuri. Sa kasong ito, ang mga pagsubok ay idinisenyo sa paraang matukoy karaniwang mga pagkakamali programmer sanhi ng maling interpretasyon ng mga kinakailangan. Ginagamit ang mga pagsusuri sa kundisyon sa hangganan at mga pagsusuri sa equivalence ng klase. Ang kawalan ng mga kakayahan sa system na hindi tinukoy ng mga kinakailangan ay ginagarantiyahan ng iba't ibang mga pagtatantya ng saklaw ng code ng programa sa pamamagitan ng mga pagsubok, i.e. pagtatantya kung ilang porsyento ng ilang mga pagbuo ng wika ang nakumpleto bilang resulta ng pagsasagawa ng lahat ng mga halimbawa ng pagsubok. Ang lahat ng ito ay tatalakayin sa pagtatapos ng paksang ito. 2.2. Mga paraan ng pagsubok 2.2.1. Itim na kahon Ang pangunahing ideya sa pagsubok ng isang sistema bilang isang itim na kahon ay ang lahat ng mga materyales na magagamit ng tester ay mga kinakailangan para sa system, na naglalarawan sa pag-uugali nito at sa mismong sistema, na maaari niyang gamitin lamang sa pamamagitan ng paglalapat ng ilang panlabas na impluwensya sa mga input nito at pagmamasid sa mga output ilang resulta. Ang lahat ng mga panloob na tampok ng pagpapatupad ng system ay nakatago mula sa tester, kaya ang system ay isang "itim na kahon", ang tamang pag-uugali na may kaugnayan sa mga kinakailangan ay dapat ma-verify. 27 Mula sa punto ng view ng software code, ang isang itim na kahon ay maaaring isang hanay ng mga klase (o mga module) na may mga kilalang panlabas na interface, ngunit hindi naa-access ang mga source code. Ang pangunahing gawain ng isang tester ay upang ang pamamaraang ito ang pagsubok ay binubuo ng patuloy na pagsuri kung ang pag-uugali ng system ay nakakatugon sa mga kinakailangan. Bilang karagdagan, dapat suriin ng tester ang pagpapatakbo ng system sa mga kritikal na sitwasyon - kung ano ang mangyayari kung ang mga maling halaga ng input ay ibinigay. Sa isang perpektong sitwasyon, ang lahat ng mga variant ng mga kritikal na sitwasyon ay dapat na inilarawan sa mga kinakailangan ng system at ang tester ay maaari lamang makabuo ng mga partikular na pagsubok ng mga kinakailangang ito. Gayunpaman, sa katotohanan, bilang resulta ng pagsubok, dalawang uri ng mga problema sa system ang karaniwang natutukoy: 1. Hindi pagkakapare-pareho ng pag-uugali ng system sa mga kinakailangan 2. Hindi naaangkop na pag-uugali ng system sa mga sitwasyong hindi ibinigay ng mga kinakailangan. Ang parehong uri ng mga problema ay iniulat at iniulat sa mga developer. Kasabay nito, ang mga problema ng unang uri ay kadalasang nagiging sanhi ng mga pagbabago sa code ng programa, mas madalas - mga pagbabago sa mga kinakailangan. Pagbabago ng mga kinakailangan sa sa kasong ito maaaring kailanganin dahil sa kanilang hindi pagkakapare-pareho (ilang iba't ibang mga kinakailangan ay naglalarawan ng iba't ibang mga modelo ng pag-uugali ng system sa parehong sitwasyon) o hindi tama (ang mga kinakailangan ay hindi tumutugma sa katotohanan). Ang mga problema ng pangalawang uri ay malinaw na nangangailangan ng pagbabago ng mga kinakailangan dahil sa kanilang hindi kumpleto - ang mga kinakailangan ay malinaw na nag-aalis ng isang sitwasyon na humahantong sa hindi naaangkop na pag-uugali ng system. Sa kasong ito, ang hindi naaangkop na pag-uugali ay maaaring maunawaan bilang isang kumpletong pagbagsak ng system, o sa pangkalahatan anumang pag-uugali na hindi inilarawan sa mga kinakailangan. Ang pagsusuri sa black box ay tinatawag ding pagsubok sa mga kinakailangan dahil... ito ang tanging pinagmumulan ng impormasyon para sa pagbuo ng plano sa pagsubok. 2.2.2. Glass (white) box Kapag sinusubukan ang isang system bilang isang glass box, ang tester ay may access hindi lamang sa mga kinakailangan para sa system, sa mga input at output nito, kundi pati na rin sa panloob na istraktura nito - nakikita niya ang code ng programa nito. Ang pagkakaroon ng program code ay nagpapalawak sa mga kakayahan ng tester dahil makikita niya ang pagsunod sa mga kinakailangan sa mga seksyon ng program code at sa gayon ay makita kung ang mga kinakailangan para sa buong code ng programa. Ang code ng programa kung saan walang mga kinakailangan ay tinatawag na code na hindi sakop ng mga kinakailangan. Ang nasabing code ay isang potensyal na mapagkukunan ng hindi naaangkop na pag-uugali ng system. Bilang karagdagan, ang transparency ng system ay nagpapahintulot sa iyo na palalimin ang pagsusuri ng mga lugar nito na nagdudulot ng mga problema - kadalasan ang isang problema ay neutralisahin ang isa pa at hindi sila nangyayari nang sabay-sabay. 2.2.3. Pagsubok ng modelo Ang pagsubok ng modelo ay medyo naiiba sa mga klasikal na pamamaraan ng pag-verify ng software. Una sa lahat, ito ay dahil sa ang katunayan na ang object ng pagsubok ay hindi ang system mismo, ngunit ang modelo nito, na dinisenyo sa pamamagitan ng pormal na paraan. Kung isasantabi natin ang mga isyu sa pagsuri sa kawastuhan at applicability ng modelo mismo (pinaniniwalaan na ang kawastuhan at pagsunod nito sa orihinal na sistema ay mapapatunayan sa pamamagitan ng pormal na paraan), kung gayon ang tester ay may isang medyo makapangyarihang tool para sa pagsusuri. ang pangkalahatang integridad ng system. Paggawa gamit ang modelo, maaari kang lumikha ng mga sitwasyon na hindi maaaring gawin sa isang pagsubok na laboratoryo para sa isang tunay na sistema. Paggawa gamit ang isang modelo ng code ng programa ng system, maaari mong suriin ang mga katangian nito at ang mga parameter ng system bilang ang pinakamainam ng mga algorithm o ang katatagan nito. 28 Gayunpaman, ang pagsubok ng modelo ay hindi naging tumpak nang tumpak dahil sa mga paghihirap na nakatagpo sa pagbuo ng isang pormal na paglalarawan ng pag-uugali ng system. Ang isa sa ilang mga pagbubukod ay ang mga sistema ng komunikasyon, ang algorithmic at mathematical apparatus na kung saan ay lubos na binuo. 2.2.4. Pagsusuri ng code ng programa (mga inspeksyon) Sa maraming sitwasyon, imposibleng subukan ang pag-uugali ng system sa kabuuan - ang mga indibidwal na seksyon ng code ng programa ay maaaring hindi kailanman maisakatuparan, ngunit sasakupin sila ng mga kinakailangan. Ang isang halimbawa ng naturang mga seksyon ng code ay mga exception handler. Kung, halimbawa, ang dalawang module ay nagpasa ng mga numeric na halaga sa isa't isa, at ang mga function ng pagsusuri ng halaga ay gumagana sa parehong mga module, kung gayon ang check function ng pagtanggap ng module ay hindi kailanman maa-activate, dahil lahat ng maling halaga ay mapuputol sa transmitter. Sa kasong ito, isinasagawa ang manu-manong pagsusuri ng code ng programa para sa kawastuhan, na tinatawag ding mga pagsusuri o inspeksyon ng code. Kung, bilang resulta ng inspeksyon, ang mga lugar ng problema ay natukoy, ang impormasyon tungkol dito ay ipinadala sa mga developer para sa pagwawasto, kasama ang mga resulta ng mga regular na pagsusuri. 2.3. Kapaligiran ng pagsubok Ang karamihan sa pagsubok ng halos anumang kumplikadong sistema ay karaniwang ginagawa sa awtomatikong mode. Bilang karagdagan, ang sistema sa ilalim ng pagsubok ay karaniwang nahahati sa magkakahiwalay na mga module, ang bawat isa ay sinubok muna nang hiwalay mula sa iba, pagkatapos ay sa kabuuan. Nangangahulugan ito na upang maisagawa ang pagsubok, kinakailangan na lumikha ng ilang kapaligiran na magsisiguro sa paglulunsad at pagpapatupad ng module sa ilalim ng pagsubok, magpadala ng data ng input dito, at mangolekta ng tunay na data ng output na nakuha bilang resulta ng system na tumatakbo sa ibinigay na data ng input. Pagkatapos nito, dapat ihambing ng kapaligiran ang aktwal na data ng output sa mga inaasahan at, batay sa paghahambing na ito, gumawa ng konklusyon tungkol sa pagsunod ng pag-uugali ng module sa tinukoy na isa (Fig. 9). Test driver Inaasahang output Nasubok Pagproseso Input data resulta module Real output data Stubs Fig. 9 Pangkalahatang diagram ng kapaligiran sa pagsubok Ang kapaligiran ng pagsubok ay maaari ding gamitin upang ihiwalay ang mga indibidwal na module ng system mula sa buong sistema. Ang paghihiwalay ng mga module ng system sa mga unang yugto ng pagsubok ay nagbibigay-daan sa iyo na mas tumpak na ma-localize ang mga problema na lumitaw sa kanilang program code. Upang suportahan ang pagpapatakbo ng isang module na nakahiwalay mula sa system, ang kapaligiran ng pagsubok ay dapat gayahin ang pag-uugali ng lahat ng mga module na ang mga function o data ay ina-access ng module na sinusuri. 29
Ang mga tuntunin sa pagpapatunay at pagpapatunay ay nauugnay sa pagsuri sa kalidad ng software. Ginagamit namin ang mga terminong ito sa aming mga artikulo at ulat. Paulit-ulit naming narinig ang iba't ibang komento at argumento tungkol sa kung ang static na pagsusuri ng source code ng program ay dapat na uriin bilang pagpapatunay at pagpapatunay at kung ano ang pagkakaiba sa pagitan ng mga konseptong ito. Sa pangkalahatan, ang isa ay nakakakuha ng impresyon na ang bawat isa ay naglalagay ng kanilang sariling mga konsepto sa mga terminong ito, at ito ay humahantong sa kapwa hindi pagkakaunawaan.
Nagpasya kaming unawain ang terminolohiya upang makasunod sa pinakatamang interpretasyon ng mga konseptong ito. Sa panahon ng pananaliksik, natagpuan namin ang gawain ng V.V. Kulyamin "Mga paraan ng pag-verify ng software". Nagbibigay ito ng detalyadong paglalarawan ng mga terminong ito, at nagpasya kaming higit pang umasa sa mga kahulugang ibinigay sa gawaing ito. Narito ang ilang mga sipi mula sa gawaing ito na may kaugnayan sa pagpapatunay at pagpapatunay.
Pagpapatunay at Pagpapatunay ay mga aktibidad na naglalayong subaybayan ang kalidad ng software at makita ang mga error dito. Ang pagkakaroon ng isang karaniwang layunin, naiiba sila sa mga mapagkukunan ng mga pag-aari, mga patakaran at mga paghihigpit na nasubok sa panahon ng kanilang kurso, na ang paglabag ay itinuturing na isang pagkakamali.
Para sa karagdagang paglalahad, kailangan nating ipakilala ang terminong “software life cycle artifact”. Ang mga artifact ng life cycle ng software ay iba't ibang entity ng impormasyon, dokumento at modelo na ginawa o ginamit sa panahon ng pagbuo at pagpapanatili ng software. Kaya, ang mga artifact ay mga teknikal na pagtutukoy, paglalarawan ng arkitektura, modelo lugar ng paksa sa anumang graphic na wika, source code, dokumentasyon ng user, atbp. Ang iba't ibang modelong ginagamit ng mga indibidwal na developer kapag lumilikha at nagsusuri ng software, ngunit hindi naitala sa anyo ng mga dokumentong naa-access ng ibang tao, ay hindi maituturing na mga artifact.
Sinusuri ng pag-verify ang pagsunod ng ilang artifact na ginawa sa panahon ng pag-develop at pagpapanatili ng software sa iba na dati nang ginawa o ginamit bilang input data, pati na rin ang pagsunod sa mga artifact na ito at ang mga proseso ng pagbuo ng mga ito sa mga panuntunan at pamantayan. Sa partikular, sinusuri ng pag-verify ang pagsunod sa pagitan ng mga pamantayan, paglalarawan ng mga kinakailangan ( mga tuntunin ng sanggunian) sa software, mga solusyon sa disenyo, source code, dokumentasyon ng user at ang paggana ng software mismo. Bilang karagdagan, napatunayan na ang mga kinakailangan, mga solusyon sa disenyo, dokumentasyon at code ay iginuhit alinsunod sa mga pamantayan at pamantayan na pinagtibay sa isang partikular na bansa, industriya at organisasyon kapag bumubuo ng software, at gayundin na sa panahon ng kanilang paglikha ng lahat ng mga operasyon na tinukoy sa ang mga pamantayan ay isinagawa sa kinakailangang mga pagkakasunud-sunod na paraan. Ang mga error at depekto na nakita sa panahon ng pag-verify ay mga pagkakaiba o kontradiksyon sa pagitan ng ilan sa mga nakalistang dokumento, sa pagitan ng mga dokumento at tunay na trabaho programa, sa pagitan ng mga pamantayan at ang aktwal na proseso ng pagbuo at pagpapanatili ng software. Kasabay nito, ang pagpapasya kung aling dokumento ang sasailalim sa pagwawasto (marahil pareho) ay isang hiwalay na gawain.
Sinusuri ng pagpapatunay ang pagsunod ng anumang mga artifact na nilikha o ginamit sa panahon ng pagbuo at pagpapanatili ng software sa mga pangangailangan at kinakailangan ng mga gumagamit at customer ng software na ito, na isinasaalang-alang ang mga batas ng paksa at ang mga paghihigpit sa konteksto ng paggamit ng software . Ang mga pangangailangan at pangangailangang ito ay kadalasang hindi nakadokumento - kapag naitala, nagiging paglalarawan sila ng mga kinakailangan, isa sa mga artifact ng proseso ng pagbuo ng software. Samakatuwid, ang pagpapatunay ay isang hindi gaanong pormal na aktibidad kaysa sa pagpapatunay. Ito ay palaging isinasagawa kasama ang paglahok ng mga kinatawan ng mga customer, user, business analyst o mga eksperto sa paksa - ang mga kung saan ang mga opinyon ay maituturing na sapat na pagpapahayag ng mga tunay na pangangailangan at pangangailangan ng mga user, customer at iba pang interesadong partido. Ang mga pamamaraan para sa pagpapatupad nito ay kadalasang gumagamit ng mga tiyak na pamamaraan upang matukoy ang kaalaman at aktwal na pangangailangan ng mga kalahok.
Ang pagkakaiba sa pagitan ng pagpapatunay at pagpapatunay ay inilalarawan sa Figure 1.
Ang mga ibinigay na kahulugan ay nakuha sa pamamagitan ng ilang extension ng mga kahulugan mula sa pamantayan ng IEEE 1012 para sa mga proseso ng pag-verify at pagpapatunay. Sa 1990 IEEE 610.12 standard dictionary ng software engineering terms, ang kahulugan ng verification ay humigit-kumulang pareho, ngunit ang kahulugan ng validation ay medyo naiiba - sinasabi nito na dapat suriin ng validation ang pagsunod ng software na nakuha bilang resulta ng pag-unlad sa orihinal. mga kinakailangan para dito. Sa kasong ito, ang pagpapatunay ay magiging isang espesyal na kaso ng pag-verify, na hindi nabanggit saanman sa software engineering literature, samakatuwid, at dahil din ito ay naitama sa IEEE 1012 ng 2004, ang kahulugan na ito ay dapat ituring na hindi tumpak. Madalas na paggamit ng parirala ni B. Boehm:
Sinasagot ng pag-verify ang tanong na "Ginagawa ba natin nang tama ang produkto?", at sinasagot ng validation ang tanong na "Ginagawa ba natin ang tamang produkto?"
ay nagdaragdag din sa pagkalito, dahil ang aphorism ng pahayag na ito, sa kasamaang-palad, ay pinagsama sa kalabuan. Gayunpaman, maraming mga gawa ng may-akda nito ang nagmumungkahi na sa pamamagitan ng pagpapatunay at pagpapatunay ang ibig niyang sabihin ay humigit-kumulang sa parehong mga konsepto tulad ng tinukoy sa itaas. Ang mga pagkakaibang ito ay maaari ding masubaybayan sa nilalaman ng mga pamantayan ng software engineering. Kaya, ang pamantayan ng ISO 12207 ay isinasaalang-alang ang pagsubok bilang isang uri ng pagpapatunay, ngunit hindi ang pagpapatunay, na, tila, ay isang resulta ng paggamit ng isang hindi tumpak na kahulugan mula sa karaniwang diksyunaryo.
Sa konklusyon, nais kong tandaan na ayon sa mga kahulugan sa itaas, ang static na pagsusuri ng source code ng program ay tumutugma sa pag-verify ng software, tulad ng pagsuri sa pagsunod ng program code sa iba't ibang mga pamantayan ng coding. Sinusuri ng static na pagsusuri ang pagsunod ng mga resulta ng yugto ng disenyo ng software system sa mga kinakailangan at paghihigpit na nabalangkas nang mas maaga.
Bibliograpiya
- V.V. Kulyamin "Mga paraan ng pag-verify ng software". Institute of System Programming RAS 109004, Moscow, st. B. Kommunisticeskaya, blg.
http://www.ict.edu.ru/ft/005645/62322e1-st09.pdf - IEEE 1012-2004 Standard para sa Software Verification at Validation. IEEE, 2005.
- IEEE 610.12-1990 Standard Glossary of Software Engineering Terminology, Corrected Edition. IEEE, Pebrero 1991.
- B. W. Boehm. Software engineering; Mga Trend ng R&D at Pangangailangan sa Depensa. Sa R. Wegner, ed. Pananaliksik. Mga Direksyon sa Software Technology. Cambridge, MA:MIT Press, 1979.
- ISO/IEC 12207 Mga sistema at software engineering - Mga proseso sa ikot ng buhay ng software. Geneva, Switzerland: ISO, 2008.
Pagsubok sa puting kahon
Pagsubok sa kakayahang magamit
A) Pagsubok sa pag-load
Subukan ang performance
Functional na pagsubok
Pagsubok ng software
Ang pagsubok ay ang proseso ng pagsasagawa ng isang programa (o bahagi ng isang programa) na may layunin (o layunin) na makahanap ng mga error.
Mayroong ilang mga pamantayan kung saan kaugalian na pag-uri-uriin ang mga uri ng pagsubok. Karaniwan ang mga sumusunod na sintomas ay nakikilala:
I) Sa pamamagitan ng pagsubok na bagay:
(pagtukoy o pagkolekta ng mga tagapagpahiwatig ng pagganap at oras ng pagtugon ng isang software at hardware system o device bilang tugon sa isang panlabas na kahilingan upang maitaguyod ang pagsunod sa mga kinakailangan para sa isang partikular na system)
b) Pagsusuri ng stress
(tinatasa ang pagiging maaasahan at katatagan ng system kapag nalampasan ang mga limitasyon ng normal na operasyon.)
c) Pagsubok sa katatagan
4) Pagsubok sa interface ng gumagamit
5) Pagsubok sa seguridad
6) Pagsubok sa lokalisasyon
7) Pagsubok sa pagiging tugma
II) Sa pamamagitan ng kaalaman sa sistema:
1) Pagsubok sa itim na kahon
(isang bagay ay nasubok na ang panloob na istraktura ay hindi kilala)
(ang panloob na istraktura ng programa ay nasuri, ang data ng pagsubok ay nakuha sa pamamagitan ng pagsusuri sa lohika ng programa)
III) Sa antas ng automation:
1) Manu-manong pagsubok
2) Awtomatikong pagsubok
3) Semi-automated na pagsubok
IV) Ayon sa antas ng paghihiwalay ng mga bahagi:
1) Pagsubok sa bahagi (unit).
2) Pagsubok sa pagsasama
3) Pagsusuri ng system
V) Sa oras ng pagsubok:
1) Pagsubok sa Alpha– isang saradong proseso ng pagsubok sa isang programa ng mga full-time na developer o tester. Ang isang alpha na produkto ay kadalasang 50% lang ang kumpleto; ang program code ay naroroon, ngunit isang makabuluhang bahagi ng disenyo ang nawawala.
2) Beta testing– masinsinang paggamit ng halos tapos na bersyon ng programa upang matukoy ang pinakamataas na bilang ng mga error sa pagpapatakbo nito para sa kanilang kasunod na pag-aalis bago ang huling paglabas sa merkado, sa mass consumer. Ang mga boluntaryo mula sa mga ordinaryong gumagamit sa hinaharap ay hinihikayat para sa pagsubok.
Ang pag-verify ng software ay isang mas pangkalahatang konsepto kaysa sa pagsubok. Ang layunin ng pag-verify ay upang matiyak na ang item na nabe-verify (mga kinakailangan o program code) ay nakakatugon sa mga kinakailangan, ay ipinatupad nang walang hindi sinasadyang mga function, at nakakatugon sa mga detalye ng disenyo at mga pamantayan ( ISO 9000-2000). Kasama sa proseso ng pag-verify ang mga inspeksyon, pagsubok ng code, pagsusuri ng mga resulta ng pagsubok, pagbuo at pagsusuri ng mga ulat ng problema. Kaya, karaniwang tinatanggap na ang proseso ng pagsubok ay isang mahalagang bahagi ng proseso ng pag-verify.