Ohjelmistotuotteiden testaus. Kuinka testata funktion toimivuutta, joka käyttää muita toimintojaan? Muutokseen liittyvä testaus

Vaikka olisit niin suvaitsevainen, että voit käynnistää ohjelman uudelleen 18 kertaa kaatumisen jälkeen puolen tunnin sisällä ja vasta sitten heittää näytön suoraan ikkunaan, olet samaa mieltä siitä, että tämän ohjelman kanssa työskentely olisi mukavampaa, jos se ei "kaajuisi" ".

Kuinka voit varmistaa, että kehittämäsi ohjelman kaatumis-, jäätymis- tai epäonnistumistapaukset ovat erittäin harvinaisia?

Tarkka vastaus kysymykseen Tämä kysymys Ei. Mutta vuosisatojen ajan viisaimmat tiedemiehet ovat pohtineet tätä aihetta vuosia ja ovat löytäneet lääkkeen, joka, jos se ei poista kaikkia ohjelmavirheitä, luo ainakin illuusion toimista niiden poistamiseksi.

Ja tätä lääkettä kutsutaan TESTAUS ohjelmistotuote .

Viisaiden ihmisten mukaan testaus on yksi vakiintuneimmista tavoista varmistaa kehityksen laatu ohjelmisto ja kuuluu sarjaan tehokkaita keinoja moderni järjestelmä varmistaa ohjelmistotuotteen laadun.

Ohjelmistotuotteen laadulle on tunnusomaista joukko ominaisuuksia, jotka määräävät, kuinka "hyvä" tuote on sidosryhmien, kuten tuotteen asiakkaan, sponsorin, loppukäyttäjän, tuotekehittäjien ja testaajien, tukiinsinöörien, markkinoinnin, näkökulmasta. , koulutus- ja myyntihenkilöstö. Jokaisella osallistujalla voi olla erilainen käsitys tuotteesta ja kuinka hyvä tai huono se on, eli kuinka laadukas tuote on. Näin ollen tuotteen laadun varmistamisen ongelman asettaminen johtaa tehtävään tunnistaa sidosryhmät, niiden laatukriteerit ja löytää sitten optimaalinen ratkaisu, joka täyttää nämä kriteerit.

Milloin ja kuka?

Kokeneiden kehittäjien mukaan ohjelmistotuotteen testaus tulisi suorittaa heti sen luomisen alusta alkaen. Mutta samaan aikaan kokeneiden kehittäjien ei pitäisi itse osallistua testaukseen, koska tämä ei ole kuninkaallinen asia. Ohjelmistotuotteen tulee testata erityisesti koulutettujen työntekijöiden, joita kutsutaan testaajiksi, toimesta, sillä kokeneinkaan kehittäjä ei huomaa virhettään edes uusimmilla optisilla instrumenteilla.

Kaikki kehittäjät ovat kuitenkin yhtä mieltä siitä, että ohjelmistotuotteen testaus tarkoituksenmukaisen luokituksen kannalta tulisi jakaa kahteen luokkaan:

• Toiminnallinen testaus
• Ei-toiminnallinen testaus

Toiminnallinen testaus

Toiminnallinen testaus tarkoittaa sen tarkistamista, että ohjelmistotuote täyttää toiminnalliset vaatimukset, jotka on määritelty tämän tuotteen luomista varten. Yksinkertaisesti sanottuna toiminnallinen testaus tarkistaa, suorittaako ohjelmistotuote kaikki sen toiminnot.

Joten päätit lopulta suorittaa toiminnallisen testauksen. Tutustut tekniseen eritelmään, luet toiminnalliset vaatimukset ja huomaat, että ne eivät ainakaan ole siinä järjestyksessä, jossa testaus voidaan tehdä. Tulet yllättymään siitä, että jo kauan sitten muut huomasivat tämän ristiriidan ja keksivät, kuinka se voidaan voittaa.

Toiminnallista testausta varten teknisen valvonnan henkilöstö kehittää dokumenttiohjelmaa ja menetelmää sovelluksen (API) toimivuuden testaamiseen. PMI-asiakirja sisältää luettelon ohjelmistotuotteiden testausskenaarioista (testitapauksista). Yksityiskohtainen kuvaus askeleet. Testausskenaarion jokaiselle vaiheelle on ominaista käyttäjän (testausasiantuntija) toimet ja odotetut tulokset - ohjelman vastaus näihin toimiin. Testiohjelman ja metodologian tulee simuloida ohjelmistotuotteen toimintaa reaalitilassa. Tämä tarkoittaa, että testausskenaario tulee rakentaa järjestelmän tulevien käyttäjien suorittamien toimintojen analyysin perusteella, eikä se saa olla keinotekoisesti koottu manipulaatiosarja, joka on ymmärrettävä vain kehittäjälle.

Tyypillisesti toiminnallinen testaus suoritetaan kahdella tasolla:

• Komponenttien (yksikkö) testaus. Ohjelmistotuotteen yksittäisten komponenttien testaus keskittyen niiden erityispiirteisiin, tarkoitukseen ja toiminnallisiin ominaisuuksiin.
• Integraatiotestaus. Tämä tyyppi testaus suoritetaan komponenttien testauksen jälkeen ja sen tarkoituksena on tunnistaa vikoja eri osajärjestelmien vuorovaikutuksessa ohjausvirtojen ja tiedonvaihdon tasolla.

Ei-toiminnallinen testaus

Ei-toiminnallinen testaus arvioi ohjelmistotuotteen ominaisuuksia, kuten ergonomiaa tai suorituskykyä.

Mielestäni tämäntyyppisen testauksen merkitys on selvä, eikä se vaadi perusteluja. Loppujen lopuksi kaikki ymmärtävät, että jos esimerkiksi järjestelmän suorituskyky ei ole riittävä, käyttäjien on odotettava puoli päivää vastausta toimintoihinsa, mikä voi johtaa heidän massalepotilaan.

Kuten nimestä voi päätellä, ei-toiminnallinen testaus varmistaa, että ohjelmistotuote täyttää ei-toiminnalliset vaatimukset. toimeksianto sen luomiseen. Ja kuten toiminnallisen testauksen tapauksessa, ei-toiminnallista testausta varten kehitetään testiohjelma ja menetelmät.

Sulautetun ohjelmiston testaus ja vaatimustenmukaisuus ketterällä aikakaudella

Alan standardien noudattamista ei voi laiminlyödä tai tehdä myöhemmin. se on olennainen osa sulautettujen ohjelmistojen (ohjelmistojen) kehitysprosessia. Joillakin teollisuudenaloilla - kuten ilmailutekniikassa, autoteollisuudessa ja terveydenhuollossa - laatustandardien tiukka noudattaminen monimutkaisten ja ongelmattomien sulautettujen järjestelmien kehittämisessä on elintärkeää tuotteen markkinoille saattamisen kannalta. Perinteisesti testauksella on ollut tärkeä rooli sulautettujen järjestelmien kehittämisessä standardeilla säännellyille aloille. Viime vuosina vakiintuneet testauskäytännöt ja -prosessit, niiden paikka ja rooli tällaisissa projekteissa ovat kuitenkin muuttuneet merkittävästi. Se oli pelin muuttaja, ja kun pelin säännöt muuttuvat, sinun on vaihdettava niiden kanssa voittaaksesi.

Uusien, huipputeknologioiden jatkuvan kehityksen myötä yritysten on nopeasti tarjottava markkinoille tuotteita, jotka ovat luotettavia, turvallisia, helppokäyttöisiä ja yhteensopivia muiden järjestelmien kanssa – vain välttääkseen eksymisen nopeasti muuttuvaan teknologiamaailmaan. Tällaisessa tilanteessa perinteinen vesiputousmalli, jossa ohjelmistokehitysprosessi on tiukasti peräkkäinen ja testaus suoritetaan aivan lopussa, jää menneisyyteen. DevOps- ja Agile-menetelmistä on tulossa yhä suositumpia, koska niiden avulla insinöörit voivat suorittaa tehtäviä, jotka aiemmin seurasivat toisiaan samanaikaisesti.

Suorituskyvyn testaus

Suorituskykytestausvaiheessa ensimmäinen vaihe on kuormitustestaus, jonka tarkoituksena on tarkistaa, reagoiko järjestelmä riittävästi ulkoisiin vaikutuksiin todellista toimintaa lähellä olevassa tilassa.

Kuormitustestauksen lisäksi testit suoritetaan minimaalisen laitteiston ja maksimikuormituksen olosuhteissa - stressitestaus, sekä testit käsitellyn tiedon enimmäismäärien olosuhteissa - volyymitestaus.

On olemassa toisenlainen testaus: stabiilisuus- ja luotettavuustestaus, joka sisältää ohjelmistotuotteen pitkän aikavälin testaamisen normaaleissa olosuhteissa myös sen kyvyn palata normaaliin toimintaan lyhyiden kuormitusjaksojen jälkeen.

Dokumentaatio testausta varten

Kuten edellä mainittiin, testaus suoritetaan GOST 34.603-92:n mukaisesti kehitetyn ohjelman ja testausmenetelmien mukaisesti.

Testauksen suorittamista varten kehitetään testitapaus, jonka tulee sisältää riittävästi tietoa ohjelmistotuotteen kaikkien toimintatapojen testaamiseksi. Tyypillisesti testitapaus luodaan asiakkaan ja urakoitsijan yhteisesti todellisten tietojen perusteella.

Kaikentyyppisten suorituskykytestien suorittamiseksi luodaan useimmiten ns. datageneraattori, joka mahdollistaa automaattinen tila luoda riittävä määrä tietoa objektiivisen tuloksen saavuttamiseksi suorituksen arvioinnissa.

Testauksen aikana laaditaan testausprotokolla, joka sisältää tiedot testauksen kaikkien vaiheiden ja vaiheiden valmistumisesta sekä testauksen aikana saadut kommentit.

Jos testitulos on negatiivinen, puutteet korjataan ja testataan uudelleen.

Tutkiva testaus

Tutkiva testaus (ad hoc -testaus on toiminnallisen testauksen alatyyppi. Sitä käytetään nopeasti kasvavissa projekteissa joustavilla kehitysmenetelmillä, joissa ei ole selkeää dokumentaatiota ja vaatimuksia. Tutkiva testaus on ohjelmistotestauksen korkein taitolento. Kvalitatiivista testausta on saatavilla mm. erittäin päteviä asiantuntijoita ja riippuu melkein täysin esiintyjästä, hänen kokemuksestaan, tiedoistaan ​​(sekä aihealueella että testausmenetelmissä) ja kyvystä päästä nopeasti olemukseen.

Stressitestaus

Kuormitustestaus on prosessi, jossa analysoidaan testattavan järjestelmän suorituskykyä kuormitettuna. Kuormitustestauksen tarkoituksena on määrittää sovelluksen kyky kestää ulkoista kuormitusta. Tyypillisesti testit suoritetaan useissa vaiheissa.

1. Luodaan testiskriptejä

Jotta analyysi olisi tehokasta, skenaarioiden on oltava mahdollisimman lähellä todellisia käyttötapauksia. On tärkeää ymmärtää, että poikkeukset ovat aina mahdollisia, ja tarkinkaan testisuunnitelma ei välttämättä kata yhtä tapausta.

2. Testikonfiguraation kehittäminen

Kun testiskenaariot ovat olemassa, on tärkeää jakaa kasvavan kuorman järjestys. Onnistuneen analyysin kannalta on tarpeen tunnistaa suorituskyvyn arviointikriteerit (vastausnopeus, pyynnön käsittelyaika jne.).

3. Testitestin suorittaminen

Testejä suoritettaessa on tärkeää seurata skenaarioiden toteutumista ja testattavan järjestelmän reagointia ajoissa. Suurten kuormien emulointi vaatii vakavaa laitteisto- ja ohjelmistoinfrastruktuuria. Joissakin tapauksissa käytetään matemaattisia mallinnusmenetelmiä työn kustannusten alentamiseksi. Alhaisilla kuormituksilla saadut tiedot otetaan lähtökohtana ja likimääräisinä. Mitä korkeampi simuloidun kuormituksen taso on, sitä pienempi on arvion tarkkuus. Tämä menetelmä kuitenkin vähentää merkittävästi kustannuksia.

Testaa automaatiota

Automaattisen testauksen pääominaisuus on kyky suorittaa nopeasti regressiotestejä. Automaation tärkeimmät edut (Worksoftin raportin mukaan) ovat lisääntynyt henkilöstön tehokkuus, aikaisempi vikojen havaitseminen ja paljon muuta. korkealaatuinen liiketoimintaprosesseja. Näitä etuja kompensoi merkittävä haittapuoli: korkeat kustannukset – testiautomaation toteuttamisen ja tukemisen korkeiden kustannusten vuoksi noin 50 % yrityksistä käyttää edelleen pääasiassa manuaalista testausta.

Käytettävyyden testaus

Mikä tahansa sovellus luodaan käytettäväksi. Helppokäyttöisyys on tärkeä ohjelman laatuindikaattori. IT-ala tietää monia esimerkkejä projekteista, jotka lähtevät liikkeelle onnistuneen käytettävyyskorjauksen jälkeen. Mitä laajempi yleisö, sitä tärkeämpi käytettävyystekijä. Käytettävyystestaus sisältää yksityiskohtaisen analyysin käyttäjien käyttäytymisestä. Ergonomian arvioimiseksi on tärkeää saada tietoa paitsi liiketehtävän suorittamisen nopeudesta, myös käyttäjän tunteista, ilmeistä ja äänen sointista.

Kokoonpanon testaus

Konfiguraatiotestaus antaa varmuuden siitä, että sovellus toimii eri alustoilla ja siten mahdollisimman suurella määrällä käyttäjiä. WEB-sovelluksissa valitaan yleensä selaintestaus. Windows-sovelluksille - testaus erilaisilla käyttöjärjestelmät ja bittikoot (x86, x64). Tärkeä osa konfiguraatiotestausta on testiinfrastruktuuri: testien suorittamiseksi sinun on jatkuvasti ylläpidettävä testikonekantaa. Niiden määrä vaihtelee viidestä useisiin kymmeniin.

Integraatiotestaus

Jos projektissasi on useampi kuin yksi komponentti, se tarvitsee integraatiotestauksen. Monimutkaisessa sovellusarkkitehtuurissa välttämätön edellytys laadunvarmistukselle on ohjelman osien vuorovaikutuksen tarkistaminen. Testaus saavutetaan kehittämällä ja suorittamalla "päästä päähän" -tapauksia. Integrointitestaus suoritetaan komponenttien testauksen jälkeen. Siksi on erittäin tärkeää ottaa huomioon komponenttien testaamisesta saatu kokemus, samalla kun otetaan huomioon testitapausten liiketoimintasuuntautuneisuus.

Stressitestaus

Jokaisella järjestelmällä on rajansa normaalia toimintaa. Kun raja ylittyy, järjestelmä menee stressitilaan ja muuttaa käyttäytymistään merkittävästi. Stressitestaus testaa sovelluksen toimintaa normaalit toimintarajat ylittävissä olosuhteissa. Tämä on erityisen tärkeää "kriittisille" ohjelmille: pankkiohjelmistoille, ilmailualan ohjelmille, lääketieteelle. Stressitestausta ei tehdä vain ohjelmistokehitysvaiheessa, vaan myös koko käyttösyklin ajan, jotta saadaan ja käsitellään järjestelmän käyttäytymistietoja pitkällä aikavälillä.

Oletetaan, että on olemassa get-data-funktio, joka palauttaa kartan läpäisyn käyttäjätunnuksen tiedoista. Nyt tämä funktio käyttää kolmea funktiota lähde-a, lähde-b ja lähde-c kolmen erilaisen kartan tuottamiseen. Nyt yhdistämme kaikki nämä kartat yhdeksi kartaksi ja palaamme tiedonhankinnasta.

Kun testaan ​​get-dataapitäisikö minun tarkistaa avainten tietojen saatavuus? Onko järkevää, että tämä funktio epäonnistuu yksikkötesteissä, jos jokin lähteistä-a, lähde-b ja lähde-c epäonnistuu? Jos sen toiminnon tehtävänä on yhdistää tiedot, ja se tekee, sen pitäisi riittää, eikö?

1

2 vastausta

Oletetaan, että on olemassa get-data-funktio, joka palauttaa kartan tiedoista käyttäjätunnuksesta, jolle välitettiin.

Loistava. Sitten sinun pitäisi tarkistaa se. Palautatko oikeat tiedot tietylle tunnukselle?

nyt tämä funktio käyttää 3 funktiota lähde-a, lähde-b ja lähde-c kolmen erilaisen kartan tuottamiseen.

Mitkä toteutustiedot sinun tulee jättää testissä huomiotta. Testaat vain, että työyksikkösi (tämä menetelmä) tekee sen, mitä sen pitäisi tehdä (ota tunnus ja palauttaa XYZ-tiedot tälle tunnukselle). Miten tällä menetelmällä ei ole oikeastaan ​​väliä - loppujen lopuksi tämän yksikkötestin tärkein etu on, että voit muuttaa menetelmän toteutuksen ja testi tarkistaa, että teit sen oikein.

Sinun on kuitenkin luultavasti pilkattava tietolähteitä, joten jossain vaiheessa testin on todennäköisesti tiedettävä, kuinka tämä koodi toimii. Tässä on tasapainotettava kolme kilpailevaa tavoitetta: tehdä testistä eristetty (pilkkaamalla dataa) ja saada testi keskittymään vaatimuksiin ja pragmaattisuuteen.

Loppujen lopuksi tämä on tärkeä koodi. On olemassa testejä, jotka tukevat varsinaista koodia, viettävät paljon aikaa ja vaivatta kiillotuksen tarkistaminen ei ole yhtä hyödyllistä kuin testit tehdä .

Yksikkötestauksessa kannattaa testata vain yhden luokan toimivuutta, jos lähde-a-, lähde-b- ja lähde-c-metodit kutsuvat muita luokkia, kannattaa niitä pilkata (ne pitäisi olla yksikkötestattuja luokissaan).

Integraatiotestauksessa testaat useiden luokkien käyttäytymistä, jotka ovat vuorovaikutuksessa niiden välillä, mikä tarkoittaa, että get-data-funktion on tarkistettava, että haettava data on oikein (lähde-a, lähde-b ja lähde-c ovat oikein ja tiedot on kytketty oikein).

Yksikkötestit ovat yksinkertaisempia ja keskittyneempiä, ja kehittäjien tulisi kirjoittaa ne. Integraatiotestit vanhenevat yleensä suhteellisen nopeasti (jos sellaisia ​​on sisäinen komponentti on muutettu), mikä vaikeuttaa niiden suorittamista. On luotava laadunvarmistusprofiililla.

Vaikka olisit niin suvaitsevainen, että voit käynnistää ohjelman uudelleen 18 kertaa kaatumisen jälkeen puolen tunnin sisällä ja vasta sitten heittää näytön suoraan ikkunaan, olet samaa mieltä siitä, että tämän ohjelman kanssa työskentely olisi mukavampaa, jos se ei "kaajuisi" ".

Kuinka voit varmistaa, että kehittämäsi ohjelman kaatumis-, jäätymis- tai epäonnistumistapaukset ovat erittäin harvinaisia?

Tähän kysymykseen ei ole tarkkaa vastausta. Mutta vuosisatojen ajan viisaimmat tiedemiehet ovat pohtineet tätä aihetta vuosia ja ovat löytäneet lääkkeen, joka, jos se ei poista kaikkia ohjelmavirheitä, luo ainakin illuusion toimista niiden poistamiseksi.

Ja tätä lääkettä kutsutaan Ohjelmistotuotteen TESTAUS.

Viisaiden ihmisten mukaan testaus on yksi vakiintuneimmista tavoista varmistaa ohjelmistokehityksen laatu ja se sisältyy nykyaikaisen ohjelmistotuotteiden laadunvarmistusjärjestelmän tehokkaiden työkalujen joukkoon.

Ohjelmistotuotteen laadulle on tunnusomaista joukko ominaisuuksia, jotka määräävät, kuinka "hyvä" tuote on sidosryhmien, kuten tuotteen asiakkaan, sponsorin, loppukäyttäjän, tuotekehittäjien ja testaajien, tukiinsinöörien, markkinoinnin, näkökulmasta. , koulutus- ja myyntihenkilöstö. Jokaisella osallistujalla voi olla erilainen käsitys tuotteesta ja kuinka hyvä tai huono se on, eli kuinka laadukas tuote on. Näin ollen tuotteen laadun varmistamisen ongelman asettaminen johtaa tehtävään tunnistaa sidosryhmät, niiden laatukriteerit ja löytää sitten optimaalinen ratkaisu, joka täyttää nämä kriteerit.

Milloin ja kuka?

Kokeneiden kehittäjien mukaan ohjelmistotuotteen testaus tulisi suorittaa heti sen luomisen alusta alkaen. Mutta samaan aikaan kokeneiden kehittäjien ei pitäisi itse osallistua testaukseen, koska tämä ei ole kuninkaallinen asia. Ohjelmistotuotteen tulee testata erityisesti koulutettujen työntekijöiden, joita kutsutaan testaajiksi, toimesta, sillä kokeneinkaan kehittäjä ei huomaa virhettään edes uusimmilla optisilla instrumenteilla.

Kaikki kehittäjät ovat kuitenkin yhtä mieltä siitä, että ohjelmistotuotteen testaus tarkoituksenmukaisen luokituksen kannalta tulisi jakaa kahteen luokkaan:

• Toiminnallinen testaus
• Ei-toiminnallinen testaus

Toiminnallinen testaus

Toiminnallinen testaus tarkoittaa sen tarkistamista, että ohjelmistotuote täyttää toiminnalliset vaatimukset, jotka on määritelty tämän tuotteen luomista varten. Yksinkertaisesti sanottuna toiminnallinen testaus tarkistaa, suorittaako ohjelmistotuote kaikki sen toiminnot.

Joten päätit lopulta suorittaa toiminnallisen testauksen. Tutustut tekniseen eritelmään, luet toiminnalliset vaatimukset ja huomaat, että ne eivät ainakaan ole siinä järjestyksessä, jossa testaus voidaan tehdä. Tulet yllättymään siitä, että jo kauan sitten muut huomasivat tämän ristiriidan ja keksivät, kuinka se voidaan voittaa.

Toiminnallista testausta varten teknisen valvonnan henkilöstö kehittää dokumenttiohjelmaa ja menetelmää sovelluksen (API) toimivuuden testaamiseen. PMI-asiakirja sisältää luettelon ohjelmistotuotteiden testausskenaarioista (testitapauksista) ja yksityiskohtaisen kuvauksen vaiheista. Testausskenaarion jokaiselle vaiheelle on ominaista käyttäjän (testausasiantuntija) toimet ja odotetut tulokset - ohjelman vastaus näihin toimiin. Testiohjelman ja metodologian tulee simuloida ohjelmistotuotteen toimintaa reaalitilassa. Tämä tarkoittaa, että testausskenaario tulee rakentaa järjestelmän tulevien käyttäjien suorittamien toimintojen analyysin perusteella, eikä se saa olla keinotekoisesti koottu manipulaatiosarja, joka on ymmärrettävä vain kehittäjälle.

Tyypillisesti toiminnallinen testaus suoritetaan kahdella tasolla:

• Komponenttien (yksikkö) testaus. Ohjelmistotuotteen yksittäisten komponenttien testaus keskittyen niiden erityispiirteisiin, tarkoitukseen ja toiminnallisiin ominaisuuksiin.
• Integraatiotestaus. Tämän tyyppinen testaus suoritetaan komponenttien testauksen jälkeen ja sen tarkoituksena on tunnistaa vikoja eri osajärjestelmien vuorovaikutuksessa ohjausvirtojen ja tiedonvaihdon tasolla.

Ei-toiminnallinen testaus

Ei-toiminnallinen testaus arvioi ohjelmistotuotteen ominaisuuksia, kuten ergonomiaa tai suorituskykyä.

Mielestäni tämäntyyppisen testauksen merkitys on selvä, eikä se vaadi perusteluja. Loppujen lopuksi kaikki ymmärtävät, että jos esimerkiksi järjestelmän suorituskyky ei ole riittävä, käyttäjien on odotettava puoli päivää vastausta toimintoihinsa, mikä voi johtaa heidän massalepotilaan.

Kuten nimestä voi päätellä, ei-toiminnallinen testaus tarkistaa ohjelmistotuotteen ei-toiminnallisten vaatimusten mukaisuuden sen luomisen teknisistä eritelmistä. Ja kuten toiminnallisen testauksen tapauksessa, ei-toiminnallista testausta varten kehitetään testiohjelma ja menetelmät.

Sulautetun ohjelmiston testaus ja vaatimustenmukaisuus ketterällä aikakaudella

Alan standardien noudattamista ei voi laiminlyödä tai tehdä myöhemmin. se on olennainen osa sulautettujen ohjelmistojen (ohjelmistojen) kehitysprosessia. Joillakin teollisuudenaloilla - kuten ilmailutekniikassa, autoteollisuudessa ja terveydenhuollossa - laatustandardien tiukka noudattaminen monimutkaisten ja ongelmattomien sulautettujen järjestelmien kehittämisessä on elintärkeää tuotteen markkinoille saattamisen kannalta. Perinteisesti testauksella on ollut tärkeä rooli sulautettujen järjestelmien kehittämisessä standardeilla säännellyille aloille. Viime vuosina vakiintuneet testauskäytännöt ja -prosessit, niiden paikka ja rooli tällaisissa projekteissa ovat kuitenkin muuttuneet merkittävästi. Se oli pelin muuttaja, ja kun pelin säännöt muuttuvat, sinun on vaihdettava niiden kanssa voittaaksesi.

Uusien, huipputeknologioiden jatkuvan kehityksen myötä yritysten on nopeasti tarjottava markkinoille tuotteita, jotka ovat luotettavia, turvallisia, helppokäyttöisiä ja yhteensopivia muiden järjestelmien kanssa – vain välttääkseen eksymisen nopeasti muuttuvaan teknologiamaailmaan. Tällaisessa tilanteessa perinteinen vesiputousmalli, jossa ohjelmistokehitysprosessi on tiukasti peräkkäinen ja testaus suoritetaan aivan lopussa, jää menneisyyteen. DevOps- ja Agile-menetelmistä on tulossa yhä suositumpia, koska niiden avulla insinöörit voivat suorittaa tehtäviä, jotka aiemmin seurasivat toisiaan samanaikaisesti.

Suorituskyvyn testaus

Suorituskykytestausvaiheessa ensimmäinen vaihe on kuormitustestaus, jonka tarkoituksena on tarkistaa, reagoiko järjestelmä riittävästi ulkoisiin vaikutuksiin todellista toimintaa lähellä olevassa tilassa.

Kuormitustestauksen lisäksi testit suoritetaan minimaalisen laitteiston ja maksimikuormituksen olosuhteissa - stressitestaus, sekä testit käsitellyn tiedon enimmäismäärien olosuhteissa - volyymitestaus.

On olemassa toisenlainen testaus: stabiilisuus- ja luotettavuustestaus, joka sisältää ohjelmistotuotteen pitkän aikavälin testaamisen normaaleissa olosuhteissa myös sen kyvyn palata normaaliin toimintaan lyhyiden kuormitusjaksojen jälkeen.

Dokumentaatio testausta varten

Kuten edellä mainittiin, testaus suoritetaan GOST 34.603-92:n mukaisesti kehitetyn ohjelman ja testausmenetelmien mukaisesti.

Testauksen suorittamista varten kehitetään testitapaus, jonka tulee sisältää riittävästi tietoa ohjelmistotuotteen kaikkien toimintatapojen testaamiseksi. Tyypillisesti testitapaus luodaan asiakkaan ja urakoitsijan yhteisesti todellisten tietojen perusteella.

Kaikentyyppisten suorituskykytestien suorittamiseksi luodaan useimmiten ns. datageneraattori, jonka avulla voit automaattisesti luoda riittävän määrän dataa objektiivisen tuloksen saavuttamiseksi suorituksen arvioinnissa.

Testauksen aikana laaditaan testausprotokolla, joka sisältää tiedot testauksen kaikkien vaiheiden ja vaiheiden valmistumisesta sekä testauksen aikana saadut kommentit.

Jos testitulos on negatiivinen, puutteet korjataan ja testataan uudelleen.

Tutkiva testaus

Tutkiva testaus (ad hoc -testaus on toiminnallisen testauksen alatyyppi. Sitä käytetään nopeasti kasvavissa projekteissa joustavilla kehitysmenetelmillä, joissa ei ole selkeää dokumentaatiota ja vaatimuksia. Tutkiva testaus on ohjelmistotestauksen korkein taitolento. Kvalitatiivista testausta on saatavilla mm. erittäin päteviä asiantuntijoita ja riippuu melkein täysin esiintyjästä, hänen kokemuksestaan, tiedoistaan ​​(sekä aihealueella että testausmenetelmissä) ja kyvystä päästä nopeasti olemukseen.

Stressitestaus

Kuormitustestaus on prosessi, jossa analysoidaan testattavan järjestelmän suorituskykyä kuormitettuna. Kuormitustestauksen tarkoituksena on määrittää sovelluksen kyky kestää ulkoista kuormitusta. Tyypillisesti testit suoritetaan useissa vaiheissa.

1. Luodaan testiskriptejä

Jotta analyysi olisi tehokasta, skenaarioiden on oltava mahdollisimman lähellä todellisia käyttötapauksia. On tärkeää ymmärtää, että poikkeukset ovat aina mahdollisia, ja tarkinkaan testisuunnitelma ei välttämättä kata yhtä tapausta.

2. Testikonfiguraation kehittäminen

Kun testiskenaariot ovat olemassa, on tärkeää jakaa kasvavan kuorman järjestys. Onnistuneen analyysin kannalta on tarpeen tunnistaa suorituskyvyn arviointikriteerit (vastausnopeus, pyynnön käsittelyaika jne.).

3. Testitestin suorittaminen

Testejä suoritettaessa on tärkeää seurata skenaarioiden toteutumista ja testattavan järjestelmän reagointia ajoissa. Suurten kuormien emulointi vaatii vakavaa laitteisto- ja ohjelmistoinfrastruktuuria. Joissakin tapauksissa käytetään matemaattisia mallinnusmenetelmiä työn kustannusten alentamiseksi. Alhaisilla kuormituksilla saadut tiedot otetaan lähtökohtana ja likimääräisinä. Mitä korkeampi simuloidun kuormituksen taso on, sitä pienempi on arvion tarkkuus. Tämä menetelmä kuitenkin vähentää merkittävästi kustannuksia.

Testaa automaatiota

Automaattisen testauksen pääominaisuus on kyky suorittaa nopeasti regressiotestejä. Automaation tärkeimmät edut (Worksoftin raportin mukaan) ovat henkilöstön tehostaminen, vikojen aikaisempi havaitseminen ja liiketoimintaprosessien korkeampi laatu. Näitä etuja kompensoi merkittävä haittapuoli: korkeat kustannukset – testiautomaation toteuttamisen ja tukemisen korkeiden kustannusten vuoksi noin 50 % yrityksistä käyttää edelleen pääasiassa manuaalista testausta.

Käytettävyyden testaus

Mikä tahansa sovellus luodaan käytettäväksi. Helppokäyttöisyys on tärkeä ohjelman laatuindikaattori. IT-ala tietää monia esimerkkejä projekteista, jotka lähtevät liikkeelle onnistuneen käytettävyyskorjauksen jälkeen. Mitä laajempi yleisö, sitä tärkeämpi käytettävyystekijä. Käytettävyystestaus sisältää yksityiskohtaisen analyysin käyttäjien käyttäytymisestä. Ergonomian arvioimiseksi on tärkeää saada tietoa paitsi liiketehtävän suorittamisen nopeudesta, myös käyttäjän tunteista, ilmeistä ja äänen sointista.

Kokoonpanon testaus

Konfiguraatiotestaus antaa varmuuden siitä, että sovellus toimii eri alustoilla ja siten mahdollisimman suurella määrällä käyttäjiä. WEB-sovelluksissa valitaan yleensä selaintestaus. Windows-sovelluksille - testaus eri käyttöjärjestelmillä ja bittinopeuksilla (x86, x64). Tärkeä osa konfiguraatiotestausta on testiinfrastruktuuri: testien suorittamiseksi sinun on jatkuvasti ylläpidettävä testikonekantaa. Niiden määrä vaihtelee viidestä useisiin kymmeniin.

Integraatiotestaus

Jos projektissasi on useampi kuin yksi komponentti, se tarvitsee integraatiotestauksen. Monimutkaisessa sovellusarkkitehtuurissa välttämätön edellytys laadunvarmistukselle on ohjelman osien vuorovaikutuksen tarkistaminen. Testaus saavutetaan kehittämällä ja suorittamalla "päästä päähän" -tapauksia. Integrointitestaus suoritetaan komponenttien testauksen jälkeen. Siksi on erittäin tärkeää ottaa huomioon komponenttien testaamisesta saatu kokemus, samalla kun otetaan huomioon testitapausten liiketoimintasuuntautuneisuus.

Stressitestaus

Jokaisella järjestelmällä on raja sen normaalille toiminnalle. Kun raja ylittyy, järjestelmä menee stressitilaan ja muuttaa käyttäytymistään merkittävästi. Stressitestaus testaa sovelluksen toimintaa normaalit toimintarajat ylittävissä olosuhteissa. Tämä on erityisen tärkeää "kriittisille" ohjelmille: pankkiohjelmistoille, ilmailualan ohjelmille, lääketieteelle. Stressitestausta ei tehdä vain ohjelmistokehitysvaiheessa, vaan myös koko käyttösyklin ajan, jotta saadaan ja käsitellään järjestelmän käyttäytymistietoja pitkällä aikavälillä.

Kaikista tyypeistä toiminnallinen testaus on oikeutetusti johtavassa asemassa, koska ohjelman on ensinnäkin toimittava oikein, muuten helppokäyttöisyydestä, turvallisuudesta ja riittävästä nopeudesta ei ole mitään hyötyä. Erilaisten testaustekniikoiden hallitsemisen lisäksi jokaisen asiantuntijan on ymmärrettävä, kuinka testi suoritetaan oikein tehokkaimman tuloksen saamiseksi.

Toiminnallinen testaus: mihin suunnata pääponnistelut?

Yksikkö- ja järjestelmätestaukseen;

Valitse "valkoinen" tai "musta" ruutu;

Manuaaliseen testaukseen ja automatisointiin;

testata uusia toimintoja tai;

"Negatiivisille" tai "positiivisille" testeille.

Kaikkien näiden toiminta-alueiden välillä on tärkeää löytää oikea polku, josta tulee "keskiosa", jotta ponnistelut tasapainoistuvat käyttämällä kunkin alueen etuja maksimaalisesti.

Ohjelmiston tarkistus suoritetaan eri tavoilla, joista yksi on musta laatikko tai datapohjainen testaus.

Ohjelma on tässä tapauksessa esitetty "mustan laatikon" näkökulmasta, ja testillä selvitetään olosuhteet, joissa ohjelman käyttäytyminen ei vastaa spesifikaatiota. Kaikki virheet tunnistetaan tiedonhallinnan avulla, joka toteutetaan perusteellisella testauksella eli kaikin mahdollisin keinoin

Jos ohjelman komennon suoritus riippuu sitä edeltävistä tapahtumista, se vaatii kaikkien mahdollisten sekvenssien tarkistamista. On aivan selvää, että useimmissa tapauksissa on yksinkertaisesti mahdotonta suorittaa kattavaa testausta, joten useammin he valitsevat hyväksyttävän tai järkevän vaihtoehdon, joka rajoittuu ohjelman suorittamiseen pienellä osajoukolla kaikkia syötetietoja. Tämä vaihtoehto takaa täysin, ettei spesifikaatioista poikkea.

Toiminnalliseen testaukseen kuuluu oikean testin valinta. Samanaikaisesti on tapana erottaa seuraavat menetelmät joukkojen luomiseksi niille:

Raja-arvoanalyysi;

Vastaava osio;

Virhe-oletus;

Syiden ja seurausten välisten yhteyksien analyysi.

Voit tarkastella jokaista niistä erikseen.

Raja-arvoanalyysi. Raja-arvoilla tarkoitetaan yleensä niitä, jotka sijaitsevat ekvivalenssiluokkien rajoilla. Tällaisissa paikoissa virhe löytyy todennäköisimmin. Tällaisen menetelmän käyttö vaatii asiantuntijalta tiettyä luovuutta sekä erikoistumista tähän tarkasteltavana olevaan ongelmaan.

Vastaava osio. Kaikki mahdolliset syöttöparametrijoukot on jaettu useisiin ekvivalenssiluokkiin. Tiedot yhdistetään samanlaisten virheiden havaitsemisen periaatteella. On yleisesti hyväksyttyä, että jos yhden luokan joukko näyttää virheen, myös vastaavat osoittavat sen. Toiminnallinen testaus tätä menetelmää suoritetaan kahdessa vaiheessa: ensimmäisessä tunnistetaan ekvivalenssiluokat ja toisessa muodostetaan jo erityisiä testejä.

Syy-seuraussuhteiden analyysi. Järjestelmä voi valita tehokkaita testejä suorittamalla tällaisia ​​tarkastuksia. Tässä tapauksessa syyksi otetaan erillinen sisääntuloehto ja seuraukseksi lähtöehto. Menetelmä perustuu ajatukseen kaikentyyppisten syiden liittämisestä tiettyihin seurauksiin eli samojen syy-seuraus-suhteiden selvittämiseen. Ohjelmistotuotteen testaus suoritetaan useissa vaiheissa, jolloin saadaan luettelo syistä ja niistä aiheutuvista seurauksista.

• kehittäjien tahattomat poikkeamat työstandardeista tai toteutussuunnitelmista;
• toiminnallisten ja liitäntävaatimusten määrittelyt tehdään noudattamatta kehitysstandardeja, mikä johtaa ohjelmien toiminnan häiriintymiseen;
• kehitysprosessin organisointi - projektipäällikön resurssien (henkilöstö, tekniset, ohjelmistot jne.) epätäydellinen tai riittämätön hallinta ja projektielementtien testaus- ja integrointiongelmat.

Katsotaanpa testausprosessia ISO/IEC 12207 -standardin suositusten perusteella ja kerrotaan, millaisia ​​virheitä kussakin elinkaariprosessissa havaitaan.

Vaatimusten kehittämisprosessi. Määrittäessään järjestelmän alkukonseptia ja järjestelmän alkuvaatimuksia analyytikot tekevät määrittelyvirheitä huipputaso järjestelmät ja aihealueen käsitteellisen mallin rakentaminen.

Tyypillisiä virheitä tässä prosessissa ovat:

• vaatimusmäärittelyn riittämättömyys loppukäyttäjille - ohjelmiston vuorovaikutuksen virheellinen määrittely käyttöympäristön tai käyttäjien kanssa;
• yksittäisten ja yleisten ohjelmistoominaisuuksien asiakkaiden vaatimusten noudattamatta jättäminen;
• toiminnallisten ominaisuuksien virheellinen kuvaus;
• työkalujen puute kaikkien asiakkaiden vaatimusten toteuttamiseen jne.

Suunnitteluprosessi.Virheitä komponenttien suunnittelussa voi tapahtua kuvattaessa algoritmeja, ohjauslogiikkaa, tietorakenteita, rajapintoja, tietovirran mallinnuslogiikkaa, syöttö-lähtömuotoja jne. Nämä virheet perustuvat analyytikkospesifikaatioiden virheisiin ja suunnitteluvirheisiin. Näitä ovat virheet, jotka liittyvät:

• ympäristön käyttöliittymän määrittelyllä;
• toimintojen kuvauksella (komponenttijoukkoa tarkistettaessa havaittujen komponenttien tavoitteiden ja päämäärien riittämättömyys);
• tietojenkäsittelyprosessin ja prosessien välisen vuorovaikutuksen määrittelyllä (komponenttien ja prosessien välisten suhteiden virheellisen määrittämisen tulos);
• tietojen ja niiden rakenteiden virheellinen määrittely kuvattaessa yksittäisiä komponentteja ja ohjelmistoa kokonaisuutena;
• moduulialgoritmien virheellinen kuvaus;
• esiintymisolosuhteiden määrittämisen kanssa mahdollisia virheitä ohjelmassa;
• hankkeeseen hyväksyttyjen standardien ja tekniikoiden vastaisesti.

Koodausvaihe.Tässä vaiheessa syntyy virheitä, jotka ovat seurausta suunnitteluvirheistä, ohjelmoijien ja johtajien virheistä järjestelmän kehittämisen ja virheenkorjauksen aikana. Virheiden syyt ovat:

• syöteparametrien, taulukkoindeksien, silmukkaparametrien, tulostetulosten, jakamisen nollalla jne. arvojen hallinnan puute;
• epäsäännöllisten tilanteiden virheellinen käsittely analysoitaessa paluukoodeja kutsutuista alirutiineista, funktioista jne.;
• koodausstandardien rikkominen (huonot kommentit, irrationaaliset moduulien allokointi ja komponentit jne.);
• yhden nimen käyttö eri objektien tai objektin eri nimien osoittamiseen, huono nimimuistomerkki; - eri kehittäjien tekemät epäjohdonmukaiset muutokset ohjelmaan jne.

Testausprosessi.Tässä prosessissa ohjelmoijat ja testaajat tekevät virheitä suorittaessaan kokoonpano- ja testaustekniikkaa, valitessaan testisarjoja ja testiskenaarioita jne. Tällaisten virheiden aiheuttamat ohjelmistovirheet on tunnistettava, eliminoitava eivätkä ne saa vaikuttaa komponenttien ja komponenttien tilastoihin. ohjelmistovirheitä yleensä.

Huoltoprosessi.Ylläpitoprosessin aikana havaitaan virheitä, jotka johtuvat käyttödokumentaation puutteista ja puutteista, riittämättömistä muunnettavuuden ja luettavuuden indikaattoreista sekä ohjelmiston ylläpidosta ja/tai parantamisesta vastaavien henkilöiden epäpätevyydestä. Tehtävien muutosten luonteesta riippuen tässä vaiheessa saattaa ilmetä melkein mitä tahansa virheitä, jotka ovat samankaltaisia ​​kuin aiemmin luetellut virheet edellisissä vaiheissa.

Kaikki ohjelmissa esiintyvät virheet jaetaan yleensä seuraaviin luokkiin [7.12]:

• loogiset ja toiminnalliset virheet;
• laskenta- ja ajonaikaiset virheet;
• syöttö/tulostus ja tietojen käsittelyvirheet;
• käyttöliittymävirheet;
• datamäärän virheet jne.

Loogisia virheitä ovat syynä algoritmin logiikan rikkomiseen, muuttujien ja operaattorien sisäiseen epäjohdonmukaisuuteen sekä ohjelmointisääntöihin. Toiminnalliset virheet ovat seurausta väärin määritellyistä toiminnoista, niiden käyttöjärjestyksen rikkomisesta tai niiden toteuttamisen puutteellisuudesta jne.

Laskentavirheet syntyvät lähdetietojen ja toteutettujen kaavojen epätarkkuudesta, menetelmävirheistä, laskentatoimintojen tai operandien virheellisestä soveltamisesta. Ajonaikaiset virheet liittyvät epäonnistumiseen vaaditun pyynnön käsittelynopeuden tai ohjelman palautusajan toimittamisessa.

I/O-virheet ja tietojen manipulointi ovat seurausta tietojen huonosta valmistelusta ohjelman suorittamista varten, epäonnistumisista niiden syöttämisessä tietokantoihin tai haettaessa niistä.

Käyttöliittymävirheet viittaavat virheisiin yksittäisten elementtien keskinäisessä suhteessa, joka ilmenee niiden välisen tiedonsiirron aikana sekä vuorovaikutuksessa toimintaympäristön kanssa.

Äänenvoimakkuuden virheet liittyvät tietoihin ja ovat seurausta siitä, että toteutetut pääsytavat ja tietokantojen koot eivät täytä järjestelmäinformaation todellisia määriä tai niiden käsittelyn intensiteettiä.

Annetut pääasialliset virheluokat ovat ominaisia ​​eri tyyppisille ohjelmistokomponenteille ja ne ilmenevät ohjelmissa eri tavoin. Näin ollen tietokannan kanssa työskennellessä tapahtuu virheitä tietojen esittämisessä ja käsittelyssä, loogisia virheitä sovellettavien tietojenkäsittelymenetelmien määrittelyssä jne. Laskennallisissa ohjelmissa laskentavirheet hallitsevat ja ohjaus- ja käsittelyohjelmissa loogiset ja toiminnalliset virheet. Ohjelmisto, joka koostuu useista erilaisista ohjelmista, jotka toteuttavat eri toimintoja, voivat sisältää virheitä eri tyyppejä. Käyttöliittymävirheet ja äänenvoimakkuuden rikkomukset ovat tyypillisiä kaikentyyppisille järjestelmille.

Ohjelmien virhetyyppien analysointi on edellytys testisuunnitelmien ja testausmenetelmien laatimiselle ohjelmiston oikeellisuuden varmistamiseksi.

Ohjelmistokehityksen tukityökalujen (CASE-teknologiat, oliopohjaiset menetelmät ja työkalut mallien ja ohjelmien suunnitteluun) nykyisessä kehitysvaiheessa toteutetaan suunnittelu, jossa ohjelmisto on suojattu yleisimmiltä virheiltä ja siten estetty ohjelmistovikoja.

Virheen ja epäonnistumisen välinen suhde Virheen esiintyminen ohjelmassa johtaa pääsääntöisesti ohjelmiston epäonnistumiseen sen toiminnan aikana. "Virhe-epäonnistuminen" syy-seuraus-suhteiden analysoimiseksi suoritetaan seuraavat toimet:

• suunnittelu- ja ohjelmointitekniikoiden puutteiden tunnistaminen;
• suunnitteluprosessin puutteiden ja inhimillisten virheiden välinen suhde;
• epäonnistumisten, puutteiden ja mahdollisten virheiden sekä puutteiden luokittelu kussakin kehitysvaiheessa - tietyssä kehitysprosessissa tehtyjen inhimillisten virheiden ja objektin virheiden vertailu projektispesifikaatioiden, ohjelmamallien virheiden seurauksena;
• todentaminen ja virhesuojaus kaikissa elinkaaren vaiheissa sekä vikojen havaitseminen kussakin kehitysvaiheessa;
• Ohjelmistojen vikojen ja vikojen vertailu kytkentäjärjestelmän ja menetelmien kehittämiseksi vikoja ja vikoja koskevien tietojen lokalisoimiseksi, keräämiseksi ja analysoimiseksi;
• ohjelmistojen dokumentointi- ja testausprosessien lähestymistapojen kehittäminen.

Virhe-epäonnistumisen syy-yhteyden perimmäisenä tavoitteena on määritellä menetelmät ja keinot tiettyjen luokkien virheiden testaamiseksi ja havaitsemiseksi sekä kriteerit useiden tietojoukkojen testauksen suorittamiseksi loppuun; tunnistaa tapoja parantaa ohjelmistokehityksen, testauksen ja ylläpidon prosessin organisointia.

Tässä on seuraava vikatyyppien luokittelu:

• laitteisto, jossa järjestelmän laajuinen ohjelmisto ei toimi;
• informaatio, joka johtuu virheistä syöttötiedoissa ja tiedonsiirrossa viestintäkanavien kautta sekä syöttölaitteiden viasta (laitteistovikojen seuraus);
• ergonominen, aiheutuu käyttäjän virheistä hänen vuorovaikutuksessaan koneen kanssa (tämä vika on toissijainen vika ja voi johtaa tieto- tai toimintahäiriöihin);
• ohjelmisto, jos komponenteissa on virheitä jne.

Jotkut virheet voivat johtua puutteista vaatimusten määrittelyssä, suunnittelussa, lähtökoodin luomisessa tai dokumentaatiossa. Toisaalta ne syntyvät ohjelmaa kehitettäessä tai yksittäisten ohjelmaelementtien rajapintoja kehitettäessä (parametrien järjestyksen rikkominen, vähemmän tai useampi parametri jne.).

Virheiden lähteet.Virheitä voi syntyä projektin, komponenttien, koodin ja dokumentaation kehittämisen aikana. Yleensä ne havaitaan ohjelmiston suorittamisen tai ylläpidon aikana kaikkein odottamattomimmissa ja erilaisissa kohdissa.

Jotkut ohjelman virheet voivat johtua puutteista vaatimusten määrittelyssä, suunnittelussa, koodin luomisessa tai dokumentaatiossa. Toisaalta virheitä syntyy ohjelman tai sen elementtien rajapintojen kehittämisen aikana (esimerkiksi kun viestintäparametrien asetusjärjestystä rikotaan - vähemmän tai enemmän kuin vaaditaan jne.).

Virheiden syynä on asiakkaiden vaatimusten ymmärtämisen puute; epätarkka vaatimusten määrittely projektiasiakirjoissa jne. Tämä johtaa siihen, että osa järjestelmän toiminnoista on toteutettu, jotka eivät toimi asiakkaan ehdotuksen mukaisesti. Tältä osin käydään asiakkaan ja kehittäjän välillä yhteinen keskustelu joidenkin vaatimusten yksityiskohdista niiden selventämiseksi.

Järjestelmän kehitystiimi voi myös muuttaa järjestelmän kuvauksen syntaksia ja semantiikkaa. Joitakin virheitä ei kuitenkaan välttämättä havaita (esimerkiksi näiden lauseiden indeksit tai muuttujien arvot on asetettu väärin).