Ennemmin tai myöhemmin monet organisaatiot, jotka käyttävät tätä tai toista ohjelmistoa, tulevat tarpeeseen järjestää testausprosessi. Syitä on yleensä useita, joko kyseessä on käynnistys, joka vaatii välittömästi ohjelmistonsa testaamista, tai johto alkaa ymmärtää, että yritystestauksen, ylläpidon, kehityksen ja kaikkien muiden yritykseen osallistuvien lisäksi ammattitaitoiset testausasiantuntijat ovat edelleen vaaditaan, joka vapauttaa kaikki muut ihmiset, joilla ei ole normaalia ymmärrystä testaamisesta. Ja tästä hetkestä alkaa usein perinteinen yhden nykyisen työntekijän nimittäminen testausosaston johtajaksi, meidän työllemme. Kuten, tässä on sinulle pelto, kylvä se... Sillä ei ole väliä mitä teet, mutta osaston on oltava olemassa ja sen on tuotava tuloksia. Kaikki ei tietenkään aina ole niin huonosti, että joku vielä etsii tähän tehtävään osaavia testausasiantuntijoita, mutta silti tässä vaiheessa ei ole vielä testausprosessia ja se on luotava.

Ja hyvin usein monet johtajat alkavat luoda testausprosessia ei järjestelmällisesti, vaan valikoivasti. Mutta samaan aikaan, jos järjestät testausprosessin yksinkertaisesti repäisemällä parhaita käytäntöjä, ilman järjestelmällinen lähestymistapa, niin tällainen prosessi ei tuota positiivisia tuloksia ei kuukaudessa, ei vuodessa.

Luulen, että monet tietävät, että jos testausprosessia ei ole järjestetty oikein alusta alkaen, sen muuttaminen myöhemmin on erittäin vaikeaa. Siksi sinun on määritettävä, kuinka testausprosessi järjestetään oikein?

Mistä testausprosessin organisointi kannattaa aloittaa?

Tunnistan 11 pääkriteeriä testausprosessin järjestämisessä:

1. Testauksen tavoitteet ja laajuus
2. Joukkue
3. Ohjaus
4. Viestintä ja vuorovaikutus
5. Testausmenetelmä
6. Prosessin dokumentaatio
7. Riskienhallinta
8. Prosessin mittaus
9. Työkalut
10. Testiympäristöt
11. Prosessin parantaminen

Kaikkien näiden kriteerien täyttyminen mahdollistaa testausprosessin tasaisen kehittymisen, mikä lyhyet ehdot voit saavuttaa tason, jolla testausprosessi tuo positiivisia tuloksia.

Siksi jokaisen johtajan, jonka tehtävänä on järjestää testausprosessi, tulee esittää seuraavat kysymykset:

• Miksi tarvitsemme testejä?
• Mitä meidän pitää testata?
• Mitä prosesseja pitää virallistaa tai luoda?
• Miten ja mitä meidän pitäisi testata?

Vasta saatuamme vastaukset näihin kysymyksiin voimme alkaa siirtyä standardeihin.

korostan standardien mukaisesti, jotka sinun on todella opittava ennen kuin aloitat prosessin rakentamisen:

• ISO 29119
• IEEE 829\1008
• TPI Next&TMap
• ISTQB

Luonnollisesti standardien mukaisia ​​käytäntöjä ei voida täysin hyödyntää. Kaikki standardit tulee räätälöidä vastaamaan oman testausprosessisi tarpeita, koska standardikäytäntöjen harkitsematon käyttöönotto voi johtaa haitallisiin seurauksiin, koska testausprosessisi ei täytä liiketoiminnan vaatimuksia.

Kaikkien IT-prosessien tulee aina vastata liiketoiminnan tarpeita!

Analysoimme tärkeimmät kriteerit testausprosessin rakentamiselle.

Testauksen tavoitteet ja laajuus

Testauksen tarkoituksena on havaita viat, varmistaa, että ohjelmisto täyttää esitetyt vaatimukset ja antaa palautetta puutteista kaikille kiinnostuneille.

Tämä on testausprosessin vakiotavoite, mutta voi olla myös tavoitteita, jotka määräytyvät organisaation liiketoimintatarpeiden mukaan. Esimerkiksi pankeille on tyypillistä, että keskuspankin erilaiset vaatimukset toteutetaan ajallaan, joten yleisen testaustavoitteen lisäksi lisätään myös kriittisten tehtävien edellyttämän laadun oikea-aikainen suorittaminen.

Testausalueesta puhuttaessa meidän on ymmärrettävä täydellisesti, mitä meidän on testattava. Nämä voivat olla järjestelmiä, komponentteja tai liiketoimintaprosesseja. Ymmärtääksesi tämän, sinun tarvitsee vain vastata kahteen kysymykseen:

• Mitä pitäisi testata?
• Mitä testaamme?

Usein se, mitä on testattava ja mitä testaamme, voi vaihdella suuresti. Se riippuu testausprosessisi kyvyistä. "Mitä tarvitaan" on usein liiketoiminnan ja johdon sanelema, joten hyvän johtajan tulee aina ymmärtää "mitä tarvitaan" testattavaksi. Kuten sanonta kuuluu: "Jos jahtaat kahta jänistä, et saa kumpaakaan kiinni", niin se on tässä. On aina parempi testata laadullisesti sitä, mitä voit todella testata tiimisi kanssa, kuin tarttua kaikkeen, mitä yritys pyytää, ja olla tekemättä mitään ajoissa ja jopa jättää huomiotta kriittiset viat.

Tiimi ja johto

Tiimi on testausprosessin tärkein osa. Ilman joukkuetta et johtajana tee mitään. Ryhmän muodostamiseen on usein useita tapoja:

Työkalut ja infrastruktuuri

Mitä on testausprosessi ilman työkaluja? Tämä osoittautuu käsityöksi käsityön vuoksi :) Luulen, että monet teistä ovat usein kuulleet testitapausten kirjoittamisesta Word-dokumentteihin, kaavioiden ja kaavioiden rakentamisesta Excelissä. Mutta miksi tuhlata vaivaa, jos markkinat tarjoavat meille valmiita testinhallintatuotteita, kuten HP ALM, MS TFS, TestRail, TestLink, JIRA Zephyr ja monet muut.
Siksi, jos olet aloittanut testausprosessin organisoinnin, tee tästä prosessista kätevä ja tehokas. Kirjoita testitapaukset sopivissa muodoissa valmiita tuotteita, integroida työkalut tehtävänhallintajärjestelmään, muokata jne.

Kun valitset työkalua, sinun tulee aina ymmärtää:

• Mitä tehtäviä aiot suorittaa?
• Mikä on työkalubudjettisi?

Kun olet saanut vastaukset näihin kysymyksiin, voit määrittää sinulle sopivimmat testaustyökalut ja ehkä kehittää omasi.

Testauksenhallintatyökalujen lisäksi testaustyökaluihin kuuluvat myös:

• Vikojen ja tehtävien hallintajärjestelmä (voidaan sisällyttää testinhallintajärjestelmään)
• Aputyökalut (kuvakaappauksia, lokien ottamista, tietokantojen käyttöä varten, SOUP-käyttöliittymä XML:lle jne.)
• Automaatiotyökalut ( , seleeni jne.)
• Tiedonhallintajärjestelmät (wiki-moottorissa)

Puhutaanpa nyt infrastruktuurista. Tarinani nykyisessä kontekstissa tarkoitan testiympäristöjä.

Lähes missä tahansa organisaatiossa, varsinkin jos organisaatio on suuri eikä kehity mobiilisovelluksia Playmarketia varten tarvitset testiympäristöjä testausta varten. Järjestelmäintegraation kapasiteetti ja määrä testiympäristöissä voivat vaihdella testauksen määrän mukaan.

Standardina korostan seuraavat tyypit testiympäristöt:

• Kehitysympäristö (voidaanko se luokitella testiympäristöksi?, mutta silti)
• Järjestelmän testausympäristö (yksi tai useampi järjestelmä voidaan ottaa käyttöön, komponentti, ei vaadi vakavaa tehoa)
• Integrointiympäristö (täydellinen integraatioympäristö päästä päähän -yritysprosessien toimivuuden testaamiseen)
• Ympäristö (päävaatimus on, että teho vastaa taistelupiiriä)
• ProdLike/PreProd-ympäristö (ympäristö valmiin testatun koontiversion virheenkorjaukseen, asennustestien suorittamiseen)

Mahdollisuus järjestää tällainen suuria määriä testiympäristöt mahdollistavat testaustyön suorittamisen päällekkäin, mikä lisää muutosten (julkaisujen, sprinttien) määrää, joita voi tapahtua rinnakkain, mutta testauksen eri vaiheissa.

Prosessin parantaminen

Sanon hyvin usein lauseen, että "kaikkia prosessia, olipa mikä tahansa, tulee aina parantaa", johon kuulen usein "Miksi, prosessimme toimii jo hyvin."

Mutta se ei ole totta. Miksi meidän on jatkuvasti parannettava testausprosessia:

1. Testaustavoitteet eivät voi olla samoja, ne muuttuvat jatkuvasti liiketoiminnan tarpeiden mukaan, mikä on markkinoiden sanelemaa.

2. IT-ala kehittyy jatkuvasti. Uusia teknologioita ja lähestymistapoja on tulossa, joiden avulla voimme aina parantaa testausprosessia.

Kuten he sanovat, täydellisyydellä ei ole rajaa!

No, kuinka parantaa, on tavallinen Demming-sykli.

Suunniteltu - Valmistettu - Analysoitu - Muokattu

Lopuksi sanon, että oikean avulla voit luoda todellisen tehokas prosessi testaus, sille asetettujen tavoitteiden ja päämäärien ratkaiseminen.

Testaus ohjelmisto(ohjelmisto) tunnistaa koodissa olevat puutteet, puutteet ja virheet, jotka on poistettava. Se voidaan myös määritellä arviointiprosessiksi toiminnallisuutta ja ohjelmiston oikeellisuus analyysin avulla. Perusintegraatio- ja testausmenetelmät ohjelmistotuotteita varmistavat sovellusten laadun ja koostuvat spesifikaation, suunnittelun ja koodin tarkistamisesta, luotettavuuden arvioinnista, validoinnista ja todentamisesta.

menetelmät

Ohjelmistojen testauksen päätavoite on varmistaa laatu ohjelmistopaketti tekemällä järjestelmällisesti virheenkorjaus sovelluksista tarkasti valvotuissa olosuhteissa, määrittämällä niiden täydellisyys ja oikeellisuus sekä havaitsemalla piilotetut virheet.

Menetelmät voidaan jakaa staattisiin ja dynaamisiin.

Ensimmäiset sisältävät epävirallisen, valvonta- ja teknisen tarkastuksen, tarkastuksen, askel askeleelta analyysi, tarkastus ja staattinen analyysi tiedonkulku ja ohjaus.

Dynaamiset tekniikat ovat seuraavat:

1. Testausmenetelmä valkoinen laatikko. Tämä on yksityiskohtainen tutkimus ohjelman sisäisestä logiikasta ja rakenteesta. Tämä edellyttää lähdekoodin tuntemista.
2. Mustan laatikon testaus. Tämä tekniikka ei vaadi tietoa sovelluksen sisäisestä toiminnasta. Vain sellaiset järjestelmän pääkohdat, jotka eivät liity toisiinsa tai joilla on vain vähän yhteyttä sen sisäiseen loogiseen rakenteeseen, otetaan huomioon.
3. Harmaan laatikon menetelmä. Yhdistää kaksi edellistä lähestymistapaa. Virheenkorjaus sovelluksen sisäisen toiminnan rajallisella tiedolla yhdistetään järjestelmän perusominaisuuksien tuntemukseen.

Läpinäkyvä testaus

White box -menetelmä käyttää testiskriptejä ohjausrakenne menettelyprojekti. Tämän tekniikan avulla voit tunnistaa toteutusvirheet, kuten huonon koodinhallinnan, analysoimalla ohjelmiston sisäistä toimintaa. Data testausmenetelmiä sovellettavissa integraatioon, modulaariseen ja järjestelmän tasot. Testaajan tulee päästä käsiksi lähdekoodiin ja sen avulla selvittää, mikä lohko toimii sopimattomasti.

Ohjelmien White box -testauksella on seuraavat edut:

• avulla voit tunnistaa virheet piilotettu koodi kun poistat ylimääräisiä viivoja;
• sivuvaikutusten mahdollisuus;
• Suurin kattavuus saavutetaan kirjoittamalla testikäsikirjoitus.

Virheet:

• erittäin kallis prosessi, joka vaatii pätevän virheenkorjaajan;
• monet polut jäävät tutkimatta, koska kaikkien mahdollisten piilovirheiden perusteellinen tarkistaminen on erittäin vaikeaa;
• osa puuttuvasta koodista jää huomaamatta.

Valkoisen laatikon testausta kutsutaan joskus myös läpinäkyväksi tai läpinäkyväksi testaukseksi. avoin laatikko, rakenteellinen, looginen testaus, testaus perustuu lähdetekstejä, arkkitehtuuri ja logiikka.

Päälajikkeet:

1) virtauksen ohjauksen testaus - jäsennelty strategia, joka käyttää mallina ohjelman ohjausvirtaa ja antaa etusijalle lisää yksinkertaisia ​​tapoja ennen vähemmän monimutkaisempi;

2) haaran virheenkorjaus pyrkii tutkimaan jokaisen vaihtoehdon (tosi tai epätosi) jokaisesta ohjauslauseesta, joka sisältää myös yhdistetyn päätöksen;

3) peruspolun testaus, jonka avulla testaaja voi määrittää toimenpiteen loogisen monimutkaisuuden mittarin suorituspolkujen perusjoukon tunnistamiseksi;

4) tietovirran tarkistus - strategia ohjausvirran tutkimiseksi merkitsemällä graafiin tiedot ohjelmamuuttujien ilmoittamisesta ja käytöstä;

5) syklin testaus - täysin keskittynyt syklisten toimenpiteiden oikeaan suorittamiseen.

Käyttäytymisen virheenkorjaus

Black Box -testaus käsittelee ohjelmistoa "mustana laatikkona" - se ei ota huomioon tietoja ohjelman sisäisestä toiminnasta, ja vain järjestelmän pääasiat testataan. Tässä tapauksessa testaajan on tunnettava järjestelmän arkkitehtuuri ilman pääsyä lähdekoodiin.

Tämän lähestymistavan edut:

• tehokkuus suurelle koodisegmentille;
• testaajan havaitsemisen helppous;
• Käyttäjän näkökulma on selvästi erotettu kehittäjän näkökulmasta (ohjelmoija ja testaaja ovat toisistaan ​​riippumattomia);
• lisää nopea luominen testata.

Ohjelmien testaamisessa black box -menetelmillä on seuraavat haitat:

• todellisuudessa suoritetaan tietty määrä testitapauksia, mikä johtaa rajoitettuun kattavuuteen;
• selkeiden eritelmien puute vaikeuttaa testitapausten kehittämistä;
• alhainen tehokkuus.

Muita tämän tekniikan nimiä ovat käyttäytymistesti, läpinäkymätön testaus, toiminnallinen testaus ja suljetun laatikon virheenkorjaus.

1) vastaava osio, joka voi vähentää testidata, koska syöttötiedot ohjelmistomoduuli jaetaan erillisiin osiin;

2) reuna-analyysi keskittyy rajojen tai ääriraja-arvojen testaamiseen - minimit, maksimit, virheet ja tyypilliset arvot;

3) fuzzing - käytetään etsimään toteutusvirheitä syöttämällä vääristyneitä tai puolivääristyneitä tietoja automaattisessa tai puoliautomaattisessa tilassa;

4) syy-seuraussuhteiden graafit - tekniikka, joka perustuu graafien luomiseen ja yhteyden luomiseen toiminnan ja sen syiden välille: identiteetti, negaatio, looginen TAI ja looginen JA - neljä perussymbolia, jotka ilmaisevat syyn ja seurauksen keskinäistä riippuvuutta;

5) ortogonaalisten taulukoiden testaus, joita sovelletaan ongelmiin, joissa on suhteellisen pieni syöttöalue, joka ylittää kattavan tutkimuksen mahdollisuudet;

6) kaikkien parien testaus - tekniikka, jonka testiarvojen joukko sisältää kaikki mahdolliset erilliset yhdistelmät jokaisesta syöttöparametriparista;

Black Box -testaus: esimerkkejä

Tekniikka perustuu spesifikaatioihin, dokumentaatioon ja ohjelmiston tai järjestelmän käyttöliittymän kuvauksiin. Lisäksi on mahdollista käyttää malleja (virallisia tai epävirallisia), jotka edustavat ohjelmiston odotettua käyttäytymistä.

Tätä virheenkorjausmenetelmää käytetään tyypillisesti käyttöliittymissä ja se vaatii vuorovaikutusta sovelluksen kanssa syöttämällä tietoja ja keräämällä tuloksia - näytöltä, raporteista tai tulosteista.

Testaaja on siis vuorovaikutuksessa ohjelmiston kanssa tulon, käyttökytkimien, painikkeiden tai muiden liitäntöjen kautta. Syöttötietojen valinta, järjestys, jossa ne syötetään, tai toimintojen järjestys voi johtaa jättimäiseen kokonaismäärään yhdistelmiä, kuten seuraavasta esimerkistä voidaan nähdä.

Kuinka monta testiä on suoritettava kaikkien mahdollisten arvojen tarkistamiseksi neljälle valintaruudulle ja yhdelle kaksipaikkaiselle kentälle, joka määrittää ajan sekunteina? Ensi silmäyksellä laskenta on yksinkertainen: 4 kenttää kahdella mahdolliset olosuhteet- 24 = 16, joka on kerrottava mahdollisten paikkojen lukumäärällä 00 - 99, eli 1600 mahdollisella testillä.

Tämä laskelma on kuitenkin virheellinen: voimme määrittää, että kaksipaikkainen kenttä voi sisältää myös välilyönnin, eli se koostuu kahdesta aakkosnumeerisesta paikasta ja voi sisältää aakkosmerkkejä, erikoismerkkejä, välilyönnit jne. Jos järjestelmä on siis 16-bittinen tietokone, jokaisessa paikassa on 216 = 65 536 vaihtoehtoa, jolloin tuloksena on 4 294 967 296 testitapausta, jotka on kerrottava 16 lippujen yhdistelmällä, mikä antaa yhteensä 68 719 476 736, jos ne suoritetaan nopeudella 1 testi sekunnissa, testien kokonaiskesto on 2 177,5 vuotta. 32- tai 64-bittisissä järjestelmissä kesto on vielä pidempi.

Siksi tämä ajanjakso on lyhennettävä hyväksyttävään arvoon. Siksi on käytettävä tekniikoita testitapausten määrän vähentämiseksi ilman, että testauksen kattavuus pienenee.

Vastaava osio

Vastaava osiointi on yksinkertainen tekniikka, jota voidaan soveltaa mihin tahansa ohjelmistossa olevaan muuttujaan, olivatpa ne tulo- tai lähtöarvot, symboliset, numeeriset jne. Se perustuu periaatteeseen, että kaikki tiedot samasta vastaavasta osiosta käsitellään samalla tavalla ja samoilla ohjeilla.

Testauksen aikana jokaisesta määritellystä vastaavasta osiosta valitaan yksi edustaja. Tämän avulla voit järjestelmällisesti vähentää mahdollisten testitapausten määrää menettämättä komentojen ja ominaisuuksien kattavuutta.

Toinen tämän osioinnin seuraus on kombinatorisen räjähdyksen väheneminen eri muuttujien välillä ja siihen liittyvä testitapausten väheneminen.

Esimerkiksi (1/x)1/2:ssa käytetään kolmea datasekvenssiä, kolme vastaavaa osiota:

1. Kaikki positiiviset luvut käsitellään samalla tavalla ja niiden pitäisi tuottaa oikeat tulokset.

2. Kaikki negatiiviset luvut käsitellään samalla tavalla ja samalla tuloksella. Tämä on väärin, koska negatiivisen luvun juuri on imaginaari.

3. Nolla käsitellään erikseen ja antaa nollalla jakovirheen. Tämä on yhden merkityksen osa.

Joten näemme kolme erilaista osaa, joista yksi tiivistyy yhteen merkitykseen. On yksi "oikea" osio, joka antaa luotettavia tuloksia, ja kaksi "väärää" osiota, joissa on virheelliset tulokset.

Alueellinen analyysi

Tietojen käsittely vastaavilla osiorajoilla voidaan suorittaa odotettua eri tavalla. Raja-arvotutkimus - hyvä tunnettu menetelmä ohjelmistojen käyttäytymisen analysointi tällaisilla alueilla. Tämän tekniikan avulla voit tunnistaa seuraavat virheet:

• relaatiooperaattoreiden virheellinen käyttö (<,>, =, ≠, ≥, ≤);
• yksittäisiä virheitä;
• ongelmia silmukoiden ja iteraatioiden kanssa,
• tietojen tallentamiseen käytettyjen muuttujien virheelliset tyypit tai koot;
• tietoihin ja muuttujatyyppeihin liittyvät keinotekoiset rajoitukset.

Läpinäkyvä testaus

Harmaa laatikko -menetelmä lisää tarkastuksen kattavuutta, jolloin voit keskittyä kaikille tasoille monimutkainen järjestelmä yhdistämällä valkoista ja mustaa menetelmää.

Tätä tekniikkaa käytettäessä testaajan on tiedettävä sisäiset rakenteet dataa ja algoritmeja. Esimerkkejä harmaan laatikon testaustekniikoista ovat:

• arkkitehtoninen malli;
• Unified Modeling Language (UML);
• tilamalli (äärellisen tilan kone).

Gray box -menetelmässä moduulien koodeja tutkitaan white-tekniikalla testitapausten kehittämiseksi ja varsinainen testaus suoritetaan ohjelmaliittymillä mustalla tekniikalla.

Tällaisilla testausmenetelmillä on seuraavat edut:

• yhdistämällä valkoisen ja mustan laatikon tekniikoiden edut;
• testaaja luottaa käyttöliittymään ja toiminnallinen erittely, ei päällä lähdekoodi;
• debuggeri voi luoda erinomaisia ​​testiskriptejä;
• varmennus suoritetaan käyttäjän, ei ohjelman suunnittelijan näkökulmasta;
• mukautetun testikehityksen luominen;
• objektiivisuus.

Virheet:

• testin kattavuus on rajoitettu, koska lähdekoodiin ei ole pääsyä;
• vaikeus havaita vikoja hajautetuissa sovelluksissa;
• monet polut jäävät tutkimatta;
• Jos ohjelmistokehittäjä on jo suorittanut testin, lisätutkimukset voivat olla tarpeettomia.

Harmaan laatikkotekniikan toinen nimi on läpikuultava virheenkorjaus.

1) ortogonaalinen matriisi - käyttämällä kaikkien mahdollisten yhdistelmien osajoukkoa;

2) matriisivirheenkorjaus ohjelman tiladatan avulla;

3) suoritetaan, kun ohjelmistoon tehdään uusia muutoksia;

4) mallitesti, joka analysoi hyvän sovelluksen suunnittelua ja arkkitehtuuria.

ohjelmistojen testaus

Käyttäen kaikkia dynaamiset menetelmät johtaa kombinatoriseen räjähdysmäiseen räjähdysmäiseen kokeeseen, joka on suunniteltava, toteutettava ja suoritettava. Jokaista tekniikkaa tulee käyttää pragmaattisesti ottaen huomioon sen rajoitukset.

Ei ole olemassa yhtä oikeaa menetelmää, vain ne, jotka sopivat paremmin tiettyyn kontekstiin. Rakenteellisten tekniikoiden avulla voit löytää hyödyttömiä tai haitallinen koodi, mutta ne ovat monimutkaisia ​​eivätkä sovellu niihin tärkeimmät ohjelmat. Määrittelypohjaiset menetelmät ovat ainoita, jotka pystyvät tunnistamaan puuttuvan koodin, mutta ne eivät voi tunnistaa poikkeavia arvoja. Jotkut tekniikat sopivat paremmin tietylle testitasolle, virhetyypille tai kontekstiin kuin toiset.

Alla on tärkeimmät erot kolmen dynaamisen testaustekniikan välillä - vertailutaulukko kolmen ohjelmiston virheenkorjaustavan välillä on annettu.

Aspekti	Mustan laatikon menetelmä	Harmaan laatikon menetelmä	Valkoisen laatikon menetelmä
Tietojen saatavuus ohjelman koostumuksesta	Vain perusnäkökohdat analysoidaan	Osittainen tieto aiheesta sisäinen rakenne ohjelmia	Täysi pääsy lähdekoodiin
Ohjelman pirstoutumisen aste
Kuka tekee virheenkorjauksen?	Loppukäyttäjät, testaajat ja kehittäjät	Loppukäyttäjät, virheenkorjaajat ja kehittäjät	Kehittäjät ja testaajat
	Testaus perustuu ulkoisiin hätätilanteisiin.	Tietokantakaaviot, tietovuokaaviot, sisäiset tilat, algoritmin ja arkkitehtuurin tuntemus	Sisäinen rakenne on täysin tiedossa
Kattavuus	Vähiten kattava ja vaatii vähän aikaa		Mahdollisesti kattavin. Vie paljon aikaa
Data ja sisäiset rajat	Vianetsintä vain yrityksen ja erehdyksen avulla	Tietoalueet ja sisäiset rajat voidaan tarkistaa, jos ne ovat tiedossa	Tietoalueiden ja sisäisten rajojen parempi testaus
Soveltuu algoritmin testaamiseen

Automaatio

Automaattiset ohjelmistotestausmenetelmät yksinkertaistavat todentamisprosessia huomattavasti teknisestä ympäristöstä tai ohjelmistokontekstista riippumatta. Niitä käytetään kahdessa tapauksessa:

1) automatisoida tylsiä, toistuvia tai huolellisia tehtäviä, kuten useiden tuhansien rivien tiedostojen vertailua, jotta testaajan aikaa vapautuu keskittymiseen tärkeämpiin kohtiin;

2) suorittaa tai seurata tehtäviä, joita ihminen ei voi helposti suorittaa, kuten suorituskyvyn testaus tai vasteaika-analyysi, joka voidaan mitata sekunnin sadasosissa.

Testilaitteet voidaan luokitella eri tavoin. Seuraava jako perustuu heidän tukemiinsa tehtäviin:

• testien hallinta, joka sisältää tuen projektinhallinnassa, versionhallinnassa, konfiguraatioiden hallinnassa, riskianalyysissä, testiseurannassa, vioissa, vioissa ja raportointityökaluissa;
• vaatimusten hallinta, joka sisältää vaatimusten ja eritelmien tallentamisen, niiden täydellisyyden ja moniselitteisyyden tarkistamisen, niiden tärkeysjärjestyksen ja kunkin testin jäljitettävyyden;
• kriittinen tarkistus ja staattinen analyysi, mukaan lukien kulun ja tehtävien seuranta, kommenttien tallentaminen ja tallentaminen, vikojen ja suunniteltujen korjausten havaitseminen, tarkistuslistoihin ja sääntöihin liittyvien viittausten hallinta, lähdedokumenttien ja koodin suhteen seuranta, staattinen analyysi vikojen havaitsemiseen, koodausstandardien noudattamisen varmistaminen , rakenteiden ja niiden riippuvuuksien analysointi, koodin ja arkkitehtuurin metristen parametrien laskenta. Lisäksi käytetään kääntäjiä, linkkianalysaattoreita ja ristiviittausgeneraattoreita;
• mallinnus, joka sisältää työkalut liiketoimintakäyttäytymisen mallintamiseen ja luotujen mallien testaamiseen;
• testikehitys varmistaa olosuhteisiin ja käyttöliittymään, malleihin ja koodiin perustuvan odotettavissa olevan datan generoinnin, niiden hallinnan tiedostojen ja tietokantojen luomiseksi tai muuttamiseksi, viestit, hallintasääntöihin perustuvan tietojen todentamisen, olosuhteiden ja riskien tilastojen analysoinnin;
• kriittinen tarkistus syöttämällä tiedot kautta GUI käyttäjä, API, komentorivit vertailijoiden käyttäminen onnistuneiden ja epäonnistuneiden testien määrittämisessä;
• tuki virheenkorjausympäristöille, joiden avulla voit korvata puuttuvan laitteiston tai ohjelmiston, mukaan lukien laitteistosimulaattorit, jotka perustuvat deterministisen lähdön osajoukkoon, pääteemulaattorit, matkapuhelimia tai verkkolaitteet, ympäristöt kielten, käyttöjärjestelmien ja laitteisto korvaamalla puuttuvat komponentit ohjaimilla, valemoduuleilla jne. sekä työkaluilla käyttöjärjestelmän pyyntöjen sieppaamiseen ja muokkaamiseen, CPU-, RAM-, ROM- tai verkkorajoitusten simulointi;
• tiedostojen, tietokantojen vertailu, odotettujen tulosten tarkistaminen testauksen aikana ja sen jälkeen, mukaan lukien dynaaminen ja erävertailu, automaattiset "oraakkelit";
• Peittomittaus muistivuotojen paikallistamiseksi ja väärä ohjaus se arvioi järjestelmän käyttäytymistä simuloiduissa kuormitusolosuhteissa, luo sovellus-, tietokanta-, verkko- tai palvelinkuormituksia sen kasvun realistisissa skenaarioissa, mittaa, analysoi, tarkistaa ja raportoi järjestelmäresursseista;
• turvallisuuden varmistaminen;
• suorituskyvyn testaus, kuormitustestaus ja dynaaminen analyysi;
• muut työkalut, mukaan lukien oikeinkirjoituksen ja syntaksin tarkistukset, verkon turvallisuus, kaikkien verkkosivustojen sivujen saatavuus jne.

Perspektiivi

Ohjelmistoalan trendien muuttuessa myös virheenkorjausprosessi voi muuttua. Nykyiset uudet menetelmät ohjelmistotuotteiden testaamiseen, kuten palvelukeskeinen arkkitehtuuri (SOA), langattomat tekniikat, mobiilipalvelut jne., ovat löytäneet uusia tapoja testata ohjelmistoja. Muutaman seuraavan vuoden aikana tällä alalla odotettavissa olevia muutoksia on lueteltu alla:

• testaajat tarjoavat kevyitä malleja, joilla kehittäjät voivat tarkistaa koodinsa;
• testausmenetelmien kehittäminen, joihin sisältyy ohjelmien katselu ja simulointi varhaisessa vaiheessa, poistaa monia epäjohdonmukaisuuksia;
• monien testipysäytysten esiintyminen vähentää virheiden havaitsemiseen kuluvaa aikaa;
• staattisia analysaattoreita ja tunnistustyökaluja käytetään laajemmin;
• hyödyllisten matriisien, kuten spesifikaatioiden kattavuuden, mallin kattavuuden ja koodin kattavuuden, soveltaminen ohjaa projektin kehitystä;
• kombinatoristen työkalujen avulla testaajat voivat määrittää painopistealueet virheenkorjaus;
• testaajat tarjoavat näkyvämpiä ja arvokkaampia palveluita koko ohjelmistokehitysprosessin ajan;
• Debuggerit pystyvät luomaan ohjelmistojen testaustyökaluja ja menetelmiä, jotka on kirjoitettu eri ohjelmointikielillä ja jotka ovat yhteensopivia niiden kanssa;
• Vianetsintäasiantuntijoista tulee ammattitaitoisempaa koulutusta.

Uudet liiketoimintalähtöiset testausmenetelmät tulevat korvaamaan ne, muuttaen tapaamme olla vuorovaikutuksessa järjestelmien ja niiden tarjoaman tiedon kanssa, samalla vähentäen riskejä ja lisäämällä liiketoiminnan muutosten hyötyjä.

Johdanto

Nykyisillä ohjelmistotestausmenetelmillä ei voida yksiselitteisesti ja täydellisesti tunnistaa kaikkia vikoja ja varmistaa analysoitavan ohjelman oikea toiminta, joten kaikki olemassa olevat testausmenetelmät toimivat tutkittavan tai kehitettävän ohjelmiston muodollisen varmennusprosessin puitteissa.

Tämä muodollinen varmennusprosessi voi osoittaa, että käytetyssä menetelmässä ei ole puutteita. (Toisin sanoen ohjelmistotuotteen vikojen puuttumista ei voida tarkasti todeta tai taata, kun otetaan huomioon ohjelmiston elinkaaren kaikissa vaiheissa esiintyvä inhimillinen tekijä).

Ohjelmistotestauksen ja -todentamisen ongelman ratkaisemiseen on monia tapoja, mutta monimutkaisten ohjelmistotuotteiden tehokas testaus on erittäin luova prosessi, joka ei rajoitu tiukkojen ja tarkkojen menettelyjen noudattamiseen tai luomiseen.

Staattinen testaus sisältää myös vaatimusten, spesifikaatioiden ja dokumentaation testaamisen.

Regressiotestaus

Pääartikkeli: Regressiotestaus

Kun olet tehnyt muutoksia ohjelman seuraavaan versioon, regressiotestit vahvistavat, että tehdyt muutokset eivät vaikuttaneet sovelluksen muiden toimintojen suorituskykyyn. Regressiotestaus voidaan suorittaa joko manuaalisesti tai käyttämällä testiautomaatiotyökaluja.

Testaa skriptejä

Testaajat käyttävät testiskriptejä eri tasoilla: sekä modulaarisia, integraatio- että järjestelmän testaus. Testausskriptit kirjoitetaan yleensä testaamaan komponentteja, jotka todennäköisimmin epäonnistuvat tai joissa virhe, jota ei löydy ajoissa, voi olla kallista.

Valkoisen ja mustan laatikon testaus

Testauksen ammattilaisten terminologiassa ilmaisut "valkoisen laatikon testaus" ja "mustan laatikon testaus" viittaavat siihen, onko testin kehittäjällä pääsy testattavan ohjelmiston lähdekoodiin vai suoritetaanko testaus käyttöliittymä tai sovellettu ohjelmiston käyttöliittymä, jonka tarjoaa testattava moduuli.

Mustaa laatikkoa testattaessa testaajalla on pääsy ohjelmistoon vain samojen käyttöliittymien kautta kuin asiakas tai käyttäjä tai ulkoiset rajapinnat, jolloin toinen tietokone tai toinen prosessi voi muodostaa yhteyden järjestelmään testausta varten. Esimerkiksi testimoduuli voi virtuaalisesti painaa testattavan ohjelman näppäimiä tai hiiren painikkeita prosessiviestintämekanismin avulla luottaen siihen, että kaikki menee oikein ja että nämä tapahtumat tuottavat saman vastauksen kuin oikeat näppäinpainallukset ja hiiren painikkeet. Pääsääntöisesti black box -testaus suoritetaan spesifikaatioiden tai muiden järjestelmän vaatimuksia kuvaavien asiakirjojen avulla. Tyypillisesti tämäntyyppisessä testauksessa kattavuuskriteeri koostuu syötetietorakenteen kattavuudesta, vaatimusten kattavuudesta ja mallin kattavuudesta (mallipohjaisessa testauksessa).

Harmaan laatikon testauksessa testin kehittäjällä on pääsy lähdekoodiin, mutta suoritettaessa testejä suoraan koodiin pääsyä ei yleensä vaadita.

Vaikka "alfa"- ja "beta"-testaus viittaavat vaiheisiin ennen tuotteen julkaisua (ja myös implisiittisesti testausyhteisön kokoon ja testausmenetelmien rajoituksiin), valkoinen laatikko ja musta laatikko -testaus viittaavat tapoihin. jossa testaaja saavuttaa tavoitteen.

Betatestaus rajoittuu yleensä black-box-testaukseen (vaikkakin pysyvä osa testaajista yleensä jatkaa white-box-testausta samanaikaisesti betatestauksen kanssa). Siten termi "beta-testaus" voi osoittaa ohjelman tilan (lähempänä julkaisua kuin "alfa"), tai se voi viitata johonkin testaajien ryhmään ja kyseisen ryhmän suorittamaan prosessiin. Joten testaaja voi jatkaa valkoisen laatikon testaamista, vaikka ohjelmisto on jo "beta" (vaiheessa), mutta tässä tapauksessa hän ei ole osa "beta-testausta" (ryhmä/prosessi).

Koodin kattavuus

Pääartikkeli: Koodin kattavuus

Koodipeitto on pohjimmiltaan valkoisen laatikon testaus. Testattava ohjelmisto on koottu erikoisasetukset tai kirjastoja ja/tai ajetaan erityisessä ympäristössä, minkä seurauksena kullekin käytetylle (suoritettavalle) ohjelmafunktiolle määritetään tämän funktion sijainti lähdekoodissa. Tämän prosessin avulla kehittäjät ja laadunvarmistusasiantuntijat voivat tunnistaa järjestelmän osat, jotka milloin tahansa normaali toiminta, käytetään hyvin harvoin tai ei koskaan (kuten virheenkäsittelykoodi jne.). Näin testaajat voivat keskittyä tärkeimpien tilojen testaamiseen.

Testaajat voivat käyttää koodin kattavuuden testituloksia kehittääkseen testejä tai testitietoja, jotka laajentavat koodin kattavuutta tärkeisiin ominaisuuksiin.

Tyypillisesti koodin peiton saamiseksi käytetyt työkalut ja kirjastot vaativat merkittäviä suorituskyky- ja/tai muistikustannuksia, joita ei voida hyväksyä normaalissa ohjelmiston toiminnassa. Siksi niitä voidaan käyttää vain laboratorio-olosuhteissa.

Lainausmerkit

• "Ohjelmatestausta voidaan käyttää osoittamaan virheiden olemassaolo, mutta se ei koskaan osoita niiden puuttumista."- Dijkstra, 1970

Katso myös

• Taaksepäin semanttinen jäljitys - universaali menetelmä minkä tahansa suunnitteluartefaktin testaaminen

Huomautuksia

Kirjallisuus

• Glenford Myers, Tom Badgett, Corey Sandler Ohjelmistojen testauksen taide, 3. painos. - M.: "Dialektiikka", 2012. - 272 s. - ISBN 978-5-8459-1796-6
• Lisa Crispin, Janet Gregory Ketterä testaus: käytännön opas ohjelmistotestaajille ja ketterille ryhmille = Ketterä testaus: Käytännön opas testaajille ja ketterille tiimeille. - M.: "Williams", 2010. - 464 s. - (Addison-Wesley Signature Series). - 1000 kappaletta.
• - ISBN 978-5-8459-1625-9 Kaner Khem, Folk Jack, Nguyen Yong Kek
• Ohjelmistojen testaus. Yrityssovellusten hallinnan peruskäsitteet. - Kiova: DiaSoft, 2001. - 544 s. - ISBN 9667393879 Culbertson Robert, Brown Chris, Cobb Gary
• Nopea testaus. - M.: "Williams", 2002. - 374 s. - ISBN 5-8459-0336-X Sinitsyn S. V., Nalyutin N. Yu.
• Ohjelmiston vahvistus. - M.: BINOM, 2008. - 368 s. - ISBN 978-5-94774-825-3 Beiser B.

Mustan laatikon testaus. Tekniikat ohjelmistojen ja järjestelmien toiminnalliseen testaukseen. - Pietari. : Peter, 2004. - 320 s. - ISBN 5-94723-698-2

• Linkit
• Ohjelmistojen testaus- ja laadunvarmistusasiantuntijoiden portaali (venäjä)
• Portaali automaattisesta ohjelmistotestauksesta (venäjäksi)

Johdanto

Nykyisillä ohjelmistotestausmenetelmillä ei voida yksiselitteisesti ja täydellisesti tunnistaa kaikkia vikoja ja varmistaa analysoitavan ohjelman oikea toiminta, joten kaikki olemassa olevat testausmenetelmät toimivat tutkittavan tai kehitettävän ohjelmiston muodollisen varmennusprosessin puitteissa.

Tämä muodollinen varmennusprosessi voi osoittaa, että käytetyssä menetelmässä ei ole puutteita. (Toisin sanoen ohjelmistotuotteen vikojen puuttumista ei voida tarkasti todeta tai taata, kun otetaan huomioon ohjelmiston elinkaaren kaikissa vaiheissa esiintyvä inhimillinen tekijä).

Ohjelmistotestauksen ja -todentamisen ongelman ratkaisemiseen on monia tapoja, mutta monimutkaisten ohjelmistotuotteiden tehokas testaus on erittäin luova prosessi, joka ei rajoitu tiukkojen ja tarkkojen menettelyjen noudattamiseen tai luomiseen.

Staattinen testaus sisältää myös vaatimusten, spesifikaatioiden ja dokumentaation testaamisen.

Regressiotestaus

Pääartikkeli: Regressiotestaus

Kun olet tehnyt muutoksia ohjelman seuraavaan versioon, regressiotestit vahvistavat, että tehdyt muutokset eivät vaikuttaneet sovelluksen muiden toimintojen suorituskykyyn. Regressiotestaus voidaan suorittaa joko manuaalisesti tai käyttämällä testiautomaatiotyökaluja.

Testaa skriptejä

Ohjelmiston laatu (Venäjä)

Valkoisen ja mustan laatikon testaus

Testaajat käyttävät testiskriptejä eri tasoilla: sekä yksikkötestauksessa että integraatio- ja järjestelmätestauksessa. Testausskriptit kirjoitetaan yleensä testaamaan komponentteja, jotka todennäköisimmin epäonnistuvat tai joissa virhe, jota ei löydy ajoissa, voi olla kallista.

Testauksen ammattilaisten terminologiassa ilmaisut "valkoisen laatikon testaus" ja "mustan laatikon testaus" viittaavat siihen, onko testin kehittäjällä pääsy testattavan ohjelmiston lähdekoodiin vai suoritetaanko testaus käyttöliittymän tai sovellusohjelmoinnin kautta. testattavan laitteen tarjoama liitäntä.

Harmaan laatikon testauksessa testin kehittäjällä on pääsy lähdekoodiin, mutta suoritettaessa testejä suoraan koodiin pääsyä ei yleensä vaadita.

Vaikka "alfa"- ja "beta"-testaus viittaavat vaiheisiin ennen tuotteen julkaisua (ja myös implisiittisesti testausyhteisön kokoon ja testausmenetelmien rajoituksiin), valkoinen laatikko ja musta laatikko -testaus viittaavat tapoihin. jossa testaaja saavuttaa tavoitteen.

Betatestaus rajoittuu yleensä black-box-testaukseen (vaikkakin pysyvä osa testaajista yleensä jatkaa white-box-testausta samanaikaisesti betatestauksen kanssa). Siten termi "beta-testaus" voi osoittaa ohjelman tilan (lähempänä julkaisua kuin "alfa"), tai se voi viitata johonkin testaajien ryhmään ja kyseisen ryhmän suorittamaan prosessiin. Joten testaaja voi jatkaa valkoisen laatikon testaamista, vaikka ohjelmisto on jo "beta" (vaiheessa), mutta tässä tapauksessa hän ei ole osa "beta-testausta" (ryhmä/prosessi).

Koodin kattavuus

Pääartikkeli: Koodin kattavuus

Koodipeitto on pohjimmiltaan valkoisen laatikon testaus. Testattava ohjelmisto on rakennettu erityisillä asetuksilla tai kirjastoilla ja/tai ajettava erityisessä ympäristössä, minkä seurauksena jokaiselle käytetylle (suoritettavalle) ohjelmatoiminnolle määritetään tämän toiminnon sijainti lähdekoodissa. Tämän prosessin avulla kehittäjät ja laadunvarmistusasiantuntijat voivat tunnistaa järjestelmän osat, joita normaalin toiminnan aikana käytetään harvoin tai ei koskaan (kuten virheenkäsittelykoodi jne.). Näin testaajat voivat keskittyä tärkeimpien tilojen testaamiseen.

Testaajat voivat käyttää koodin kattavuuden testituloksia kehittääkseen testejä tai testitietoja, jotka laajentavat koodin kattavuutta tärkeisiin ominaisuuksiin.

Tyypillisesti koodin peiton saamiseksi käytetyt työkalut ja kirjastot vaativat merkittäviä suorituskyky- ja/tai muistikustannuksia, joita ei voida hyväksyä normaalissa ohjelmiston toiminnassa. Siksi niitä voidaan käyttää vain laboratorio-olosuhteissa.

Lainausmerkit

• "Ohjelmatestausta voidaan käyttää osoittamaan virheiden olemassaolo, mutta se ei koskaan osoita niiden puuttumista."- Dijkstra, 1970

Katso myös

• Taaksepäin semanttinen jäljitys on yleinen menetelmä minkä tahansa suunnitteluartefaktin testaamiseen

Huomautuksia

Kirjallisuus

• Glenford Myers, Tom Badgett, Corey Sandler Ohjelmistojen testauksen taide, 3. painos. - M.: "Dialektiikka", 2012. - 272 s. - ISBN 978-5-8459-1796-6
• Lisa Crispin, Janet Gregory Ketterä testaus: Käytännön opas testaajille ja ketterille ryhmille. - M.: "Williams", 2010. - 464 s. - (Addison-Wesley Signature Series). - 1000 kappaletta.
• - ISBN 978-5-8459-1625-9 Kaner Khem, Folk Jack, Nguyen Yong Kek
• Ohjelmistojen testaus. Yrityssovellusten hallinnan peruskäsitteet. - Kiova: DiaSoft, 2001. - 544 s. - ISBN 9667393879 Culbertson Robert, Brown Chris, Cobb Gary
• Nopea testaus. - M.: "Williams", 2002. - 374 s. - ISBN 5-8459-0336-X Sinitsyn S. V., Nalyutin N. Yu.
• Ohjelmiston vahvistus. - M.: BINOM, 2008. - 368 s. - ISBN 978-5-94774-825-3 Beiser B.

Mustan laatikon testaus. Tekniikat ohjelmistojen ja järjestelmien toiminnalliseen testaukseen. - Pietari. : Peter, 2004. - 320 s. - ISBN 5-94723-698-2

• Linkit
• Ohjelmistojen testaus- ja laadunvarmistusasiantuntijoiden portaali (venäjä)
• Portaali automaattisesta ohjelmistotestauksesta (venäjäksi)

- ISBN 978-5-8459-1625-9

— ohjelmistojen (ohjelmistojen) tutkimusprosessi, jotta saadaan tietoa tuotteen laadusta.

Johdanto

Nykyisillä ohjelmistotestausmenetelmillä ei voida yksiselitteisesti ja täydellisesti tunnistaa kaikkia vikoja ja varmistaa analysoitavan ohjelman oikea toiminta, joten kaikki olemassa olevat testausmenetelmät toimivat tutkittavan tai kehitettävän ohjelmiston muodollisen varmennusprosessin puitteissa. Tämä muodollinen tarkastus- tai varmennusprosessi voi osoittaa, että käytetyssä menetelmässä ei ole puutteita. (Toisin sanoen ei ole mitään keinoa tarkasti todeta tai taata, että ohjelmistotuotteessa ei ole vikoja, kun otetaan huomioon kaikissa vaiheissa esiintyvä inhimillinen tekijä elinkaaren aikana

BY).

Ohjelmistotestauksen ja -todentamisen ongelman ratkaisemiseen on monia tapoja, mutta monimutkaisten ohjelmistotuotteiden tehokas testaus on erittäin luova prosessi, joka ei rajoitu tiukkojen ja tarkkojen menettelyjen noudattamiseen tai luomiseen. ISO 9126:n kannalta Laatu ( ohjelmisto

· ) voidaan määritellä tutkittavan ohjelmiston kumulatiiviseksi ominaispiirteeksi ottaen huomioon seuraavat komponentit:

· Luotettavuus

· Ylläpidettävyys

· Käytännöllisyys

· Tehokkuus

· Liikkuvuus

Toiminnallisuus Lisää täydellinen lista attribuutit ja kriteerit löytyvät kohdasta ISO-standardi 9126 Kansainvälinen standardointijärjestö. Testausprosessiin liittyvän dokumentaation koostumus ja sisältö määritellään 829-1998 IEEE standardi Standardi varten

Ohjelmistojen testaus

On olemassa useita kriteerejä, joiden mukaan on tapana luokitella testaustyypit. Tyypillisesti erotetaan seuraavat:

Testaamalla objektia:

· Toiminnallinen testaus

· Kuormitustestaus

· Suorituskyky/stressitestaus

· Vakaus-/kuormitustestaus

· Käytettävyyden testaus

· Käyttöliittymän testaus (käyttöliittymän testaus)

· Turvallisuustestaus

· Lokalisointitestaus

· Yhteensopivuustestaus

Järjestelmän tuntemuksen perusteella:

· Mustan laatikon testaus

· Valkoisen laatikon testaus

· Harmaan laatikon testaus

Automaatioasteen mukaan:

· Manuaalinen testaus

· Automaattinen testaus

· Semi automaattinen testaus(puoliautomaattinen testaus)

Komponenttien eristysasteen mukaan:

· Komponenttien/yksiköiden testaus

· Integraatiotestaus

· Järjestelmän testaus (järjestelmä/päästä päähän -testaus)

Testausajan mukaan:

· Alfa-testaus

· Savun testaus

· Uusien ominaisuuksien testaus

· Regressiotestaus

· Hyväksymistesti

· Beta-testaus

Positiivisten skenaarioiden perusteella:

· Positiivinen testi

· Negatiivinen testi

Testausvalmiusasteen mukaan:

· Testaus dokumentaation mukaan (muodollinen testaus)

· Ed Hoc (intuitiivinen) testaus (ad hoc -testaus)

Testitasot

Yksikkötestaus (yksikkötestaus) — testataan pienin mahdollinen testauskomponentti, esimerkiksi erillinen luokka tai toiminto. Yksikkötestauksen tekevät usein ohjelmistokehittäjät.

Integraatiotestaus — Komponenttien ja osajärjestelmien väliset liitännät testataan. Jos tässä vaiheessa on aikavaraa, testaus suoritetaan iteratiivisesti ja sisällytetään asteittain seuraavat osajärjestelmät.

Järjestelmän testaus — integroidun järjestelmän vaatimustenmukaisuus testataan.

Alfa-testaus — täysipäiväisten kehittäjien jäljitelmä todellista työtä järjestelmän parissa, tai oikeaa työtä potentiaalisten käyttäjien/asiakkaiden toimesta.

Useimmiten alfatestaus tehdään tuotteen kehityksen alkuvaiheessa, mutta joissain tapauksissa sitä voidaan käyttää valmiille tuotteelle sisäisenä hyväksymistestauksena. Joskus alfatestaus suoritetaan debuggerin alla tai käyttämällä ympäristöä, joka auttaa havaitsemaan nopeasti löydetyt virheet. Löydetyt virheet voidaan välittää testaajille lisätutkimuksia varten ympäristössä, joka on samanlainen kuin se, jossa ohjelmistoa käytetään. Beta-testaus

- joissain tapauksissa versio, jossa on rajoituksia (toiminnallisuudessa tai käyttöajassa), jaetaan tietylle ihmisryhmälle, jotta varmistetaan, että tuotteessa on riittävän vähän virheitä. Joskus betatestauksia tehdään saadakseen palautetta tuotteesta tulevilta käyttäjiltä. Usein ilmaisissa/avoimen lähdekoodin ohjelmistoissa Alpha-testausvaihe luonnehtii koodin toiminnallista sisältöä ja Beta-testaus virheenkorjausvaihetta. Lisäksi pääsääntöisesti jokaisessa kehitysvaiheessa välitulokset

Valkoisen ja mustan laatikon testaus

teokset ovat loppukäyttäjien saatavilla.

Testausalan ammattilaisten (ohjelmistot ja jotkin laitteet) terminologiassa ilmaisut "valkoisen laatikon testaus" ja "mustan laatikon testaus" viittaavat siihen, onko testin kehittäjällä pääsy testattavan ohjelmiston lähdekoodiin vai suoritetaanko testaus käyttöliittymä tai sovellusohjelmointirajapinta, jonka testattava moduuli tarjoaa.

Mustaa laatikkoa testattaessa testaajalla on pääsy ohjelmistoon vain samojen liitäntöjen kautta kuin asiakas tai käyttäjä tai ulkoisten rajapintojen kautta, jotka mahdollistavat toisen tietokoneen tai muun prosessin yhteyden järjestelmään testausta varten. Esimerkiksi testimoduuli voi virtuaalisesti painaa testattavan ohjelman näppäimiä tai hiiren painikkeita prosessiviestintämekanismin avulla luottaen siihen, että kaikki menee oikein ja että nämä tapahtumat tuottavat saman vastauksen kuin oikeat näppäinpainallukset ja hiiren painikkeet. Pääsääntöisesti black box -testaus suoritetaan spesifikaatioiden tai muiden järjestelmän vaatimuksia kuvaavien asiakirjojen avulla. Tyypillisesti tämäntyyppisessä testauksessa kattavuuskriteeri koostuu syötetietorakenteen kattavuudesta, vaatimusten kattavuudesta ja mallin kattavuudesta (mallipohjaisessa testauksessa).

Vaikka "alfa"- ja "beta"-testaus viittaavat vaiheisiin ennen tuotteen julkaisua (ja myös implisiittisesti testausyhteisön kokoon ja testausmenetelmien rajoituksiin), valkoinen laatikko ja musta laatikko -testaus viittaavat tapoihin. jossa testaaja saavuttaa tavoitteen.

Betatestaus rajoittuu yleensä black-box-testaukseen (vaikkakin pysyvä osa testaajista yleensä jatkaa white-box-testausta samanaikaisesti betatestauksen kanssa). Siten termi "beta-testaus" voi osoittaa ohjelman tilan (lähempänä julkaisua kuin "alfa"), tai se voi viitata johonkin testaajien ryhmään ja kyseisen ryhmän suorittamaan prosessiin. Joten testaaja voi jatkaa valkoisen laatikon testaamista, vaikka ohjelmisto on jo "beta" (vaiheessa), mutta tässä tapauksessa hän ei ole osa "beta-testausta" (ryhmä/prosessi).

Staattinen ja dynaaminen testaus

Yllä kuvatut tekniikat - valkoisen laatikon testaus ja musta laatikko -testaus - olettavat, että koodi suoritetaan, ja ero on vain testaajan tiedoissa. Molemmissa tapauksissa tämä on dynaaminen testaus.

Staattisen testauksen aikana ohjelmakoodi ei suoriteta - ohjelma analysoidaan lähdekoodin perusteella, joka luetaan manuaalisesti tai analysoidaan erikoistyökaluilla. Joissakin tapauksissa lähdekoodia ei analysoida, vaan välikoodia (kuten tavukoodi tai MSIL-koodi).

Staattinen testaus sisältää myös vaatimusten, spesifikaatioiden ja dokumentaation testaamisen.

Regressiotestaus

Regressiotestaus (englanniksi regressiotestaus, latinasta regressio - liikkuminen taaksepäin) on yhteisnimitys kaikenlaisille ohjelmistotestauksille, joiden tarkoituksena on havaita virheet jo testatuilla lähdekoodin alueilla. Tällaisia ​​virheitä - kun ohjelmaan tehtyjen muutosten jälkeen jokin, jonka pitäisi toimia, lakkaa toimimasta - kutsutaan regressiovirheiksi.

Yleisesti käytettyjä regressiotestausmenetelmiä ovat aikaisempien testien uudelleen suorittaminen sekä sen tarkistaminen, onko koodin yhdistämisen seurauksena lisätty regressiovirheitä seuraavaan versioon.

Ohjelmistokehityskokemuksesta tiedämme, että samojen virheiden toistuminen on melko yleistä. Joskus tämä johtuu huonoista versionhallintatekniikoista tai inhimillisestä virheestä työskennellessään versionhallintajärjestelmän kanssa. Mutta yhtä usein ratkaisu ongelmaan on "lyhytaikainen": seuraavan ohjelman muutoksen jälkeen ratkaisu lakkaa toimimasta. Ja lopuksi, kun kirjoitat uudelleen minkä tahansa osan koodista, samat virheet kuin edellisessä toteutuksessa esiintyvät usein.

Siksi virheen korjaamisen hyvänä käytäntönä on luoda sille testi ja suorittaa se säännöllisesti myöhempien ohjelmamuutosten yhteydessä. Vaikka regressiotestaus voidaan tehdä manuaalisesti, se tehdään useimmiten käyttämällä erikoistuneet ohjelmat, jolloin voit suorittaa kaikki regressiotestit automaattisesti. Jotkut projektit käyttävät jopa työkaluja automaattinen käynti regressiotestit kautta määrätty aikaväli aika. Tyypillisesti tämä tehdään jokaisen onnistuneen kokoamisen jälkeen (pienissä projekteissa) tai joka ilta tai joka viikko.

Regressiotestaus on olennainen osa äärimmäinen ohjelmointi. Tässä menetelmässä projektin dokumentaatio korvataan laajennettavalla, toistetulla ja automatisoidulla kaiken testauksella ohjelmistopaketti ohjelmistokehityssyklin jokaisessa vaiheessa.

Regressiotestausta voidaan käyttää paitsi ohjelman oikeellisuuden tarkistamiseen, sitä käytetään usein myös saadun tuloksen laadun arvioimiseen. Joten kääntäjää kehitettäessä regressiotestejä suoritettaessa otetaan huomioon tuloksena olevan koodin koko, sen suoritusnopeus ja kunkin testiesimerkin käännösaika.

Lainata

”Ohjelmiston ylläpidon perusongelma on, että yhden virheen korjaaminen aiheuttaa suurella todennäköisyydellä (20-50 %) uuden. Siksi koko prosessi noudattaa periaatetta "kaksi askelta eteenpäin, yksi askel taaksepäin".

Miksi emme voi korjata virheitä tarkemmin? Ensinnäkin, jopa piilotettu vika ilmenee epäonnistumisena yhdessä paikassa. Todellisuudessa sillä on usein seurauksia koko järjestelmään, jotka eivät yleensä ole ilmeisiä. Mikä tahansa yritys korjata se pienellä vaivalla korjaa paikallisen ja ilmeisen, mutta ellei rakenne ole erittäin selkeä tai dokumentaatio on erittäin hyvä, tämän korjauksen pitkän aikavälin seuraukset jäävät huomaamatta. Toiseksi, virheitä ei yleensä korjaa ohjelman tekijä, vaan usein nuorempi ohjelmoija tai harjoittelija.

Uusien virheiden vuoksi ohjelman ylläpito vaatii huomattavasti enemmän järjestelmän virheenkorjausta lauseketta kohden kuin minkään muun ohjelmoinnin yhteydessä. Teoriassa jokaisen korjauksen jälkeen sinun on suoritettava koko sarja testitapauksia, jonka mukaan järjestelmä tarkastettiin aiemmin, ettei se ole vaurioitunut jollain tuntemattomalla tavalla. Käytännössä tällaisen backtracking (regressio)testauksen täytyy itse asiassa lähestyä tätä teoreettista ihannetta, ja se on erittäin kallista.

Kun olet tehnyt muutoksia ohjelman seuraavaan versioon, regressiotestit vahvistavat, että tehdyt muutokset eivät vaikuttaneet sovelluksen muiden toimintojen suorituskykyyn.

Testaa skriptejä

Regressiotestaus voidaan suorittaa joko manuaalisesti tai käyttämällä testiautomaatiotyökaluja.

Testaajat käyttävät testiskriptejä eri tasoilla: sekä yksikkötestauksessa että integraatio- ja järjestelmätestauksessa. Testausskriptit kirjoitetaan yleensä testaamaan komponentteja, jotka todennäköisimmin epäonnistuvat tai joissa virhe, jota ei löydy ajoissa, voi olla kallista.

Koodin kattavuus

Koodipeitto on ohjelmistotestauksessa käytetty mitta. Se näyttää prosenttiosuuden, jolla ohjelman lähdekoodia on testattu. Koodipeittotekniikka oli yksi ensimmäisistä tekniikoista, jotka keksittiin järjestelmälliseen ohjelmistotestaukseen. Ensimmäinen maininta koodin kattavuudesta julkaisuissa ilmestyi vuonna 1963.

Kriteerit

· Kattavuuden mittaamiseen on useita eri tapoja, joista tärkeimmät ovat:

· Ehtojen kattavuus – onko jokainen päätöspiste (joka arvioi, onko lauseke tosi vai epätosi) suoritettu ja testattu?

· Polun kattavuus - onko siinä kaikki? mahdollisia tapoja tietyn koodin läpi on suoritettu ja testattu?

· Toiminnon kattavuus – suoritettiinko ohjelman jokainen toiminto

· Tulo-/lähtöpeitto – onko kaikki funktiokutsut ja palautukset suoritettu

Ohjelmille, joissa erityisiä vaatimuksia Turvallisuus edellyttää usein sen osoittamista, että testit kattavat 100 % jonkin kriteerin. Jotkut annetuista kattavuuskriteereistä liittyvät toisiinsa; esimerkiksi polun kattavuus sisältää sekä ehtojen kattavuuden että lausunnon kattavuuden. Lausunnon kattavuus ei sisällä kunnon kattavuutta, kuten tämä C-koodi osoittaa:

printf("tämä on");

jos (bar< 1)

printf("ei");

printf("positiivinen kokonaisluku");

Jos tässä palkki = −1, niin operaattoreiden kattavuus on täydellinen, mutta ehtojen kattavuus ei, koska if-lauseen ehdon noudattamatta jättämistä ei kata. Täydellinen polun peitto ei yleensä ole mahdollista. Koodifragmentti, jolla on n ehtoa, sisältää 2n polkua; silmukkasuunnittelu luo äärettömän määrän polkuja. Joitakin ohjelman polkuja ei ehkä saavuteta, koska testitiedoissa ei ollut polkuja, jotka voisivat johtaa näiden polkujen suorittamiseen. Ei ole olemassa universaalia algoritmia, joka ratkaisee tavoittamattoman polun ongelman (tätä algoritmia voitaisiin käyttää pysähtymisongelman ratkaisemiseen). Käytännössä polun peiton saavuttamiseksi käytetään seuraavaa lähestymistapaa: polkujen luokat tunnistetaan (esimerkiksi polut, jotka eroavat vain saman silmukan iteraatioiden lukumäärällä, voidaan luokitella yhdeksi luokkaksi), 100 % kattavuus saavutetaan, jos kaikki polkujen luokat ovat katettuja (luokka katsotaan katetuksi, jos vähintään yksi polku siitä on katettu).

Koodipeitto on pohjimmiltaan valkoisen laatikon testaus. Testattava ohjelmisto on rakennettu erityisillä asetuksilla tai kirjastoilla ja/tai ajettava erityisessä ympäristössä, minkä seurauksena jokaiselle käytetylle (suoritettavalle) ohjelmatoiminnolle määritetään tämän toiminnon sijainti lähdekoodissa. Tämän prosessin avulla kehittäjät ja laadunvarmistusasiantuntijat voivat tunnistaa järjestelmän osat, joita normaalin toiminnan aikana käytetään harvoin tai ei koskaan (kuten virheenkäsittelykoodi jne.). Näin testaajat voivat keskittyä tärkeimpien tilojen testaamiseen.

Käytännön sovellus

Tyypillisesti lähdekoodissa on testejä, jotka suoritetaan säännöllisesti. Tuloksena oleva raportti analysoidaan tunnistamaan koodialueet, joita ei suoritettu, testipaketti päivitetään ja testit kirjoitetaan peittämättömille alueille. Tavoitteena on saada joukko regressiotestejä, jotka tarkistavat koko lähdekoodin perusteellisesti.

Koodin kattavuus ilmaistaan ​​yleensä prosentteina. Esimerkiksi "testasimme 67 % koodista." Tämän lauseen merkitys riippuu käytetystä kriteeristä. Esimerkiksi 67 % polun kattavuudesta on paras tulos yli 67 % operaattorin kattavuus. Kysymys koodin kattavuuden ja laadun välisestä suhteesta testisarja ei ole vielä täysin ratkaistu.

Testaajat voivat käyttää koodin kattavuuden testituloksia kehittääkseen testejä tai testitietoja, jotka laajentavat koodin kattavuutta tärkeisiin ominaisuuksiin.

Tyypillisesti koodin peiton saamiseksi käytetyt työkalut ja kirjastot vaativat merkittäviä suorituskyky- ja/tai muistikustannuksia, joita ei voida hyväksyä normaalissa ohjelmiston toiminnassa. Siksi niitä voidaan käyttää vain laboratorio-olosuhteissa. Sähköposti: [sähköposti suojattu]