Testaussuunnitelma on yksityiskohtainen dokumentti, joka kuvaa ohjelmistojen testausalueet ja -toiminnot. Siinä esitetään testistrategia, tavoitteet, testiaikataulu, tarvittavat resurssit (henkilöresurssit, ohjelmistot ja laitteistot), testiarvio ja testitulokset.
milloin win 7 ilmestyi
Testisuunnitelma on jokaisen ohjelmiston testauksen perusta. Se on tärkein toiminta, joka varmistaa kaikkien suunniteltujen toimien luetteloiden saatavuuden sopivassa järjestyksessä.
Testaussuunnitelma on malli ohjelmistotestaustoimintojen suorittamiseen määriteltynä prosessina, jota testauspäällikkö valvoo ja hallitsee täysin. Testisuunnitelman laativat testijohto (60 %), testauspäällikkö (20 %) ja testausinsinööri (20 %).
Testisuunnitelman tyypit
Testisuunnitelmaa on kolmenlaisia
- Master Test Plan
- Vaihetestaussuunnitelma
- Testaustyyppikohtaiset testisuunnitelmat
Master Test Plan
Master Test Plan on eräänlainen testisuunnitelma, jossa on useita testaustasoja. Se sisältää täydellisen testistrategian.
Vaihetestaussuunnitelma
Vaihetestaussuunnitelma on eräänlainen testisuunnitelma, joka koskee mitä tahansa testausstrategian vaihetta. Esimerkiksi luettelo työkaluista, luettelo testitapauksista jne.
Erityiset testisuunnitelmat
Erityinen testisuunnitelma, joka on suunniteltu tärkeimmille testauksille, kuten tietoturvatestaus, kuormitustestaus, suorituskykytestaus jne. Toisin sanoen erityinen testisuunnitelma, joka on suunniteltu ei-toiminnalliseen testaukseen.
Kuinka kirjoittaa testisuunnitelma
Testisuunnitelman tekeminen on testinhallintaprosessin tärkein tehtävä. IEEE 829:n mukaan laadi testisuunnitelma seuraavien seitsemän vaiheen mukaisesti.
- Analysoi ensin tuotteen rakenne ja arkkitehtuuri.
- Suunnittele nyt testistrategia.
- Määrittele kaikki testin tavoitteet.
- Määritä testausalue.
- Määrittele kaikki käytettävät resurssit.
- Suunnittele kaikki toiminnot sopivalla tavalla.
- Määritä kaikki testitulokset.
Testaussuunnitelman komponentit tai attribuutit
Testisuunnitelma koostuu erilaisista osista, jotka auttavat meitä johtamaan koko testaustoiminnan.
Tavoitteet: Se koostuu tiedoista moduuleista, ominaisuuksista, testitiedoista jne., jotka osoittavat, että sovelluksen tarkoitus tarkoittaa sovelluksen käyttäytymistä, tavoitetta jne.
Laajuus: Se sisältää tietoja, jotka on testattava kunkin sovelluksen kanssa. Soveltamisala voidaan jakaa edelleen kahteen osaan:
- Laajuudessa
- Ulos ulottuvuudesta
Laajuudessa: Nämä ovat moduulit, jotka on testattava tarkasti (yksityiskohtaisesti).
Alueen ulkopuolella: Nämä ovat moduuleita, joita ei tarvitse testata tiukasti.
Esimerkiksi , Oletetaan, että meillä on Gmail-sovellus testattavaksi, missä testattavia ominaisuuksia kuten Kirjoita sähköpostit, lähetetyt kohteet, postilaatikko, luonnokset ja ominaisuuksia, joita ei testata kuten auta , ja niin edelleen, mikä tarkoittaa, että suunnitteluvaiheessa päätämme tuotteessa annetun aikarajan perusteella, mikä toimivuus on tarkistettava vai ei.
Nyt miten päätämme, mitä ominaisuuksia ei testata?
Meillä on seuraavat seikat, joiden perusteella voimme päättää, mitä ominaisuutta ei testata:
- Kuten yllä näemme auta ominaisuuksia ei testata, koska sen on kirjoittanut ja kehittänyt tekninen kirjoittaja ja tarkistanut toinen ammattimainen kirjoittaja.
- Oletetaan, että meillä on yksi sovellus, jolla on P, Q, R ja S ominaisuuksia, joita on kehitettävä vaatimusten perusteella. Mutta täällä S-ominaisuuden on jo suunnitellut ja käyttänyt joku muu yritys. Joten kehitystiimi ostaa S:n kyseiseltä yritykseltä ja integroi sen lisäominaisuuksiin, kuten P, Q ja R.
Nyt emme tee S-ominaisuuden toiminnallista testausta, koska sitä on jo käytetty reaaliajassa. Mutta teemme integraatiotestauksen ja järjestelmätestauksen P-, Q-, R- ja S-ominaisuuksien välillä, koska uudet ominaisuudet eivät ehkä toimi oikein S-ominaisuuden kanssa, kuten alla olevasta kuvasta näkyy:
- Oletetaan, että tuotteen ensimmäisessä julkaisussa on kehitetty elementtejä, kuten P, Q, R, S, T, U, V, W…..X, Y, Z . Nyt asiakas toimittaa vaatimukset uusille ominaisuuksille, jotka parantavat tuotetta toisessa julkaisussa ja uudet ominaisuudet ovat A1, B2, C3, D4 ja E5.
Sen jälkeen kirjoitamme laajuuden testisuunnitelman aikana nimellä
Laajuus
Testattavat ominaisuudet
A1, B2, C3, D4, E5 (uudet ominaisuudet)
P, Q, R, S, T
Ominaisuudet, joita ei testata
W…..X, Y, Z
Siksi tarkistamme ensin uudet ominaisuudet ja jatkamme sitten vanhoilla ominaisuuksilla, koska se saattaa vaikuttaa uusien ominaisuuksien lisäämisen jälkeen, mikä tarkoittaa, että se vaikuttaa myös vaikutusalueisiin, joten teemme yhden kierroksen regressiotestausta P, Q , R…, T ominaisuudet.
Testausmenetelmä:
Se sisältää tietoja erilaisten testausten, kuten toiminnallisen testauksen, integraatiotestauksen ja järjestelmätestauksen, suorittamisesta sovelluksessa. Tässä päätämme minkä tyyppistä testausta; suoritamme eri ominaisuudet sovellusvaatimuksen perusteella. Ja tässä pitäisi myös määritellä, millaista testausta käytämme testausmetodologioissa, jotta kaikki, kuten johto, kehitystiimi ja testaustiimi, ymmärtävät helposti, koska testausehdot eivät ole vakioita.
Esimerkiksi, itsenäiseen sovellukseen, kuten Adobe Photoshop , suoritamme seuraavan tyyppisiä testejä:
Savutestaus → Toimintatestaus → Integrointitestaus → Järjestelmätestaus → Adhoc-testaus → Yhteensopivuustestaus → Regressiotestaus → Globalisaatiotestaus → Esteettömyystestaus → Käytettävyystestaus → Luotettavuustestaus → Palautustestaus → Asennus- tai asennuksen poistotestaus
Ja oletetaan, että meidän on testattava https://www.jeevansathi.com/ sovellus, joten suoritamme seuraavan tyyppisiä testejä:
| Savun testaus | Toiminnallinen testaus | Integraatiotestaus |
| Järjestelmän testaus | Adhoc-testaus | Yhteensopivuustestaus |
| Regressiotestaus | Globalisaation testaus | Esteettömyystestaus |
| Käytettävyyden testaus | Suorituskyvyn testaus |
Lähestyä
Tätä attribuuttia käytetään kuvaamaan sovelluksen kulkua testauksen aikana ja myöhempää käyttöä varten.
Voimme ymmärtää sovelluksen kulun seuraavien näkökohtien avulla:
Kirjoittamalla korkean tason skenaarioita
Esimerkiksi , oletetaan, että testaamme Gmail sovellus:
- Kirjaudu Gmailiin - lähettää sähköpostin ja tarkistaa, onko se Lähetetyt-sivulla
- Kirjaudu sisään …….
- ……
- .........
Kirjoitamme tämän kuvaamaan lähestymistapoja, jotka on otettava tuotteen testaamiseen ja vain kriittisiin ominaisuuksiin, joissa kirjoitamme korkean tason skenaarioita. Tässä emme keskity kattamaan kaikkia skenaarioita, koska kyseinen testausinsinööri voi päättää, mitä ominaisuuksia on testattava vai ei.
Kirjoittamalla vuokaavion
Vuokaavio on kirjoitettu, koska korkean tason skenaarioiden kirjoittaminen vie vähän aikaa, kuten alla olevasta kuvasta näkyy:
Luomme vuokaavioita saadaksemme seuraavat edut, kuten:
- Peitto on helppoa
- Yhdistäminen on helppoa
Lähestymistapa voidaan jakaa kahteen osaan, jotka ovat seuraavat:
- Ylhäältä alas -lähestymistapa
- Alhaalta ylös -lähestymistapa
Oletus
Se sisältää tietoa ongelmasta tai ongelmasta, joka saattaa ilmetä testausprosessin aikana, ja kun kirjoitamme testaussuunnitelmia, varmistetut oletukset tehdään, kuten resurssit ja tekniikat jne.
Riski
Nämä ovat haasteita, jotka meidän on kohdattava testataksemme sovellusta nykyisessä julkaisussa, ja jos oletukset epäonnistuvat, siihen liittyy riskejä.
Esimerkiksi, hakemuksen vaikutus, julkaisupäivä siirtyy.
Lievennyssuunnitelma tai varautumissuunnitelma
Se on varasuunnitelma, joka on valmis voittamaan riskit tai ongelmat.
Katsotaanpa yksi esimerkki oletukselle, riskille ja varautumissuunnitelmalle yhdessä, koska ne liittyvät toisiinsa.
Missä tahansa tuotteessa oletus Teemme niin, että kaikki kolme testiinsinööriä ovat paikalla tuotteen valmistumiseen asti ja jokaiselle heistä on määritetty eri moduulit, kuten P, Q ja R. Tässä skenaariossa riski voisi olla niin, jos testiinsinööri jättäisi projektin kesken sen.
java-skanneri seuraavaksi
Siksi valmiussuunnitelma jokaiselle ominaisuudelle määritetään ensisijainen ja alisteinen omistaja. Joten jos yksi testiinsinööri lähtee, alainen omistaja ottaa tämän ominaisuuden haltuunsa ja auttaa myös uutta testausinsinööriä, jotta hän ymmärtää heille osoitetut moduulit.
Oletukset, riskit ja lievennys- tai varasuunnitelmat ovat aina tarkkoja itse tuotteessa. Erityyppiset riskit ovat seuraavat:
- Asiakkaan näkökulma
- Resurssien lähestymistapa
- Tekninen lausunto
Rooli ja vastuu
Se määrittelee täydellisen tehtävän, joka koko testausryhmän on suoritettava. Kun suuri projekti tulee, niin Testipäällikkö on henkilö, joka kirjoittaa testisuunnitelman. Jos pieniä projekteja on 3-4, testipäällikkö osoittaa jokaisen projektin jokaiselle testijohdolle. Ja sitten testijohto kirjoittaa projektin testisuunnitelman, joka hänelle määrätään.
Katsotaanpa yksi esimerkki, jossa ymmärrämme testipäällikön, testijohdon ja testiinsinöörien roolit ja vastuut.
Rooli: Testipäällikkö
Nimi: Ryan
Vastuu:
- Valmistele (kirjoita ja tarkista) testisuunnitelma
- Järjestä tapaaminen kehitystiimin kanssa
- Järjestä tapaaminen testausryhmän kanssa
- Järjestä tapaaminen asiakkaan kanssa
- Järjestä yksi kuukausittainen stand up -kokous
- Allekirjoita julkaisutiedote
- Eskalaatioiden ja ongelmien käsittely
Rooli: Testijohto
Nimi: Harvey
Vastuu:
- Valmistele (kirjoita ja tarkista) testisuunnitelma
- Järjestä päivittäin stand up -kokous
- Tarkista ja hyväksy testitapaus
- Valmistele RTM ja raportit
- Määritä moduulit
- Käsittelyaikataulu
Rooli: Testausinsinööri 1, testausinsinööri 2 ja testausinsinööri 3
java luokkakaavio
Nimi: Louis, Jessica, Donna
Määritä moduulit: M1, M2 ja M3
Vastuu:
- Kirjoita, tarkista ja suorita testiasiakirjat, jotka koostuvat testitapauksista ja testiskenaarioista
- Lue, tarkista, ymmärrä ja analysoi vaatimus
- Kirjoita sovelluksen kulku
- Suorita testitapaus
- RTM vastaaville moduuleille
- Vian seuranta
- Valmistele testin suoritusraportti ja välitä se testijohdolle.
Ajoittaa
Sitä käytetään selittämään työskentelyn ajoitusta, mikä on tehtävä, vai tämä attribuutti kattaa milloin jokaisen testaustoiminnon tulisi tarkalleen alkaa ja päättyy? Ja tarkat tiedot mainitaan myös jokaisesta testaustoiminnasta tiettynä päivänä.
Siksi, kuten alla olevasta kuvasta näemme, tietylle toiminnalle on aloitus- ja lopetuspäivämäärä; jokaiselle tietyn koontiversion testaamiselle on määritetty päivämäärä.
Esimerkiksi
- Testitapausten kirjoittaminen
- Toteutusprosessi
Vian seuranta
Se tehdään yleensä työkalujen avulla, koska emme voi seurata jokaisen vian tilaa manuaalisesti. Kommentoimme myös, kuinka kommunikoimme testausprosessin aikana tunnistetuista virheistä ja lähetämme ne takaisin kehitystiimille ja miten kehitystiimi vastaa. Mainitsemme tässä myös virheiden, kuten korkean, keskitason ja alhaisen, prioriteetin.
Seuraavat ovat eri näkökohtia vian seurannasta:
…..
……
……
……
Voimme kommentoida työkalun nimeä, jota käytämme virheiden jäljittämiseen. Jotkut yleisimmin käytetyistä virheenseurantatyökaluista ovat Jira, Bugzilla, Mantis ja Trac jne.<
Vakavuus voi olla seuraava:
Blocker tai showtopper
…..
….. (Selittää se esimerkillä testisuunnitelmassa)
Esimerkiksi , moduulissa on vika; emme voi mennä pidemmälle testaamaan muita moduuleja, koska jos vika on estetty, voimme jatkaa muiden moduulien tarkistamista.
Kriittinen
……
….. (Selitä se esimerkillä testisuunnitelmassa)
Tässä tilanteessa viat vaikuttavat liiketoimintaan.
Suuri
….
…. (Selitä se esimerkillä testisuunnitelmassa)
Pieni
…..
….. (Selittää se esimerkillä testisuunnitelmassa)
Nämä viat ovat niitä, jotka vaikuttavat sovelluksen ulkonäköön ja tuntumaan.
Korkea P1
…..
Keski-P2
…..
Matala-P3
…..
…..
P4
Siksi luokittelemme sen luokkiin P1, P2, P3 ja P4 bugien prioriteetin perusteella liike high, medium ja low.
Testiympäristöt
Nämä ovat ympäristöt, joissa testaamme sovellusta, ja tässä meillä on kahden tyyppisiä ympäristöjä, jotka ovat ohjelmisto ja laitteisto kokoonpano.
The ohjelmiston konfigurointi tarkoittaa eri yksityiskohtia Käyttöjärjestelmät kuten Windows, Linux, UNIX ja Mac ja erilaisia Selaimet Kuten Google Chrome, Firefox, Opera, Internet Explorer , ja niin edelleen.
Ja laitteiston kokoonpano tarkoittaa tietoa eri kokoisista RAM, ROM ja prosessorit .
Esimerkiksi
- The Ohjelmisto sisältää seuraavat:
Palvelin
| Käyttöjärjestelmä | Linux |
| Verkkopalvelin | Apache Tomcat |
| Sovelluspalvelin | Websphere |
| Tietokantapalvelin | Oracle tai MS-SQL Server |
Huomautus: Yllä olevat palvelimet ovat palveluita, joita testausryhmä käyttää sovelluksen testaamiseen.
Asiakas
| Käyttöjärjestelmä | Windows XP, Vista 7 |
| Selaimet | Mozilla Firefox, Google Chrome, Internet Explorer, Internet Explorer 7 ja Internet Explorer 8 |
Huomautus: Yllä olevat tiedot sisältävät eri käyttöjärjestelmät ja selaimet, joissa testausryhmä testaa sovellusta.
- The Laitteisto sisältää seuraavat:
Palvelin : Sun StarCat 1500
Testausryhmä voi käyttää tätä palvelinta sovelluksensa testaamiseen.
Asiakas:
Siinä on seuraava kokoonpano, joka on seuraava:
| Prosessori | Kokonaisuudessaan 2 GHz |
| RAM | 2GB |
| …. | …. |
Huomautus: Se tarjoaa testausryhmän muodostavien testausinsinöörien järjestelmien kokoonpanon.
……
…..
…..
Kehitystiimi antaa asetukset ohjelmiston asentamiseen. Jos kehitystiimi ei vielä tarjoa prosessia, kirjoitamme sen testisuunnitelmaan Task-Based Development (TBD) -muodossa.
Sisään- ja poistumiskriteerit
Se on välttämätön ehto, joka on täytettävä ennen testausprosessin aloittamista ja lopettamista.
Osallistumiskriteerit
Osallistumisehdot sisältävät seuraavat ehdot:
- Valkoisen laatikon testaus on saatava päätökseen.
- Ymmärrä ja analysoi vaatimus ja valmistele testiasiakirjat tai kun testiasiakirjat ovat valmiit.
- Testitietojen pitäisi olla valmiita.
- Rakenna tai hakemus on valmisteltava
- Moduulit tai ominaisuudet on osoitettava eri testausinsinööreille.
- Tarvittavien resurssien on oltava valmiina.
Poistumiskriteerit
Poistumiskriteerit sisältävät seuraavat ehdot:
- Kun kaikki testitapaukset on suoritettu.
- Suurin osa testitapauksista on oltava läpäissyt .
- Riippuu virheiden vakavuudesta, mikä tarkoittaa, että esto- tai suuria bugeja ei saa olla, kun taas joitain pieniä bugeja on.
Ennen kuin aloitamme toiminnallisen testauksen, kaikki edellä mainitut Osallistumiskriteerit tulee noudattaa. Kun olemme suorittaneet toiminnalliset testaukset ja ennen kuin teemme integraatiotestauksen, sitten Poistumiskriteerit Toiminnallista testausta kannattaa seurata, koska poistumiskriteerien prosentit päätetään tapaamisessa sekä kehitys- että testipäällikön kanssa, koska heidän yhteistyöllään prosenttiosuus voidaan saavuttaa. Mutta jos toiminnallisen testauksen poistumiskriteereitä ei noudateta, emme voi jatkaa integraatiotestaukseen.
Tässä vakavuuden perusteella virheen aiheuttama tarkoittaa, että testaustiimi olisi päättänyt jatkaa eteenpäin seuraavissa vaiheissa.
Testaa automaatiota
Tässä päätämme seuraavasta:
- Mikä ominaisuus on automatisoitava eikä automatisoitava?
- Mitä testiautomaatiotyökalua aiomme käyttää missä automaatiokehyksessä?
Automatisoimme testitapauksen vasta ensimmäisen julkaisun jälkeen.
Tässä herää kysymys, että millä perusteella me tahtoa päättää mitä ominaisuuksia on testattava?
Yllä olevassa kuvassa, kuten näemme, yleisimmin käytettyjä ominaisuuksia on testattava uudestaan ja uudestaan. Oletetaan, että meidän on tarkistettava Gmail-sovellus, jossa tärkeimmät ominaisuudet ovat Kirjoita viestit, lähetetyt viestit ja postilaatikko . Testaamme siis näitä ominaisuuksia, koska manuaalisen testauksen suorittaminen vie enemmän aikaa ja siitä tulee myös yksitoikkoista työtä.
Nyt, miten päätämme, mitä ominaisuuksia ei testata?
Olettaa apu Gmail-sovelluksen ominaisuutta ei testata uudestaan ja uudestaan, koska näitä ominaisuuksia ei käytetä säännöllisesti, joten meidän ei tarvitse tarkistaa sitä usein.
Mutta jos jotkin ominaisuudet ovat epävakaita ja niissä on paljon virheitä , mikä tarkoittaa, että emme testaa näitä ominaisuuksia, koska niitä on testattava uudelleen ja uudelleen manuaalisen testauksen aikana.
Jos on ominaisuus, jota on testattava usein , mutta odotamme kyseisen ominaisuuden vaatimuksen muutosta, joten emme tarkista sitä, koska manuaalisten testitapausten vaihtaminen on mukavampaa kuin automaatiotestikoodin muutos.
Tehon arvio
Tässä suunnittelemme jokaisen tiimin jäsenen ponnistuksen.
Testi Toimitettava
Nämä ovat testaustiimin tuotoksia, jotka luovutimme asiakkaalle tuotteen mukana. Se sisältää seuraavat:
Kaaviot ja mittarit
Kaavio
Tässä keskustelemme tyypeistä kaavioita lähetämme ja toimitamme myös näytteen jokaisesta kaaviosta.
Kuten näemme, meillä on viisi erilaista kaaviota, jotka osoittavat testausprosessin eri näkökohdat.
Kaavio1: Tässä näytämme kuinka monta vikaa on tunnistettu ja kuinka monta vikaa on korjattu kussakin moduulissa.
python-ohjelmat
Kaavio 2: Kuvassa 1 näkyy, kuinka monta kriittistä, suurta ja pientä vikaa on tunnistettu jokaiselle moduulille ja kuinka monta on korjattu vastaaville moduuleille.
Kaavio3: Tässä kaaviossa edustamme rakentaa viisas kaavio , mikä tarkoittaa, että jokaisessa versiossa kuinka monta vikaa jokaiselle moduulille on tunnistettu ja korjattu. Moduulin perusteella olemme määrittäneet virheet. Me lisäämme R näyttääksesi vikojen määrän P:ssä ja Q:ssa, ja lisäämme myös S näyttääksesi P:n, Q:n ja R:n viat.
Kaavio4: Testijohto suunnittelee Virhetrendianalyysi kaavio, joka luodaan joka kuukausi ja lähetä se myös johdolle. Ja se on aivan kuin ennustus, joka tehdään tuotteen lopussa. Ja täällä voimme myös arvioi virheenkorjaukset kuten voimme havaita sen kaari on suuntaus ylöspäin alla olevassa kuvassa.
Kaavio 5: The Testipäällikkö on suunnitellut tämän tyyppisen graafin. Tämän kaavion tarkoituksena on ymmärtää virheiden arvioinnissa oleva aukko ja todelliset esiintyneet viat, ja tämä kaavio auttaa myös parantamaan virheiden arviointia tulevaisuudessa.
Mittarit
Kuten yllä, luomme virheenjakaumakaavion, joka on kuvassa 1, ja yllämainittujen tietojen avulla suunnitellaan myös mittarit.
Esimerkiksi
Yllä olevassa kuvassa säilytämme kaikki tietyn projektin testausinsinöörit ja kuinka monta vikaa on tunnistettu ja korjattu. Voimme käyttää näitä tietoja myös tuleviin analyyseihin. Kun uusi vaatimus tulee, voimme päättää, kenelle tarjotaan haastava ominaisuus testaukseen aiemmin löydettyjen vikojen määrän perusteella yllä olevien mittareiden mukaan. Ja meillä on parempi tilanne tietää, kuka osaa käsitellä ongelmallisia ominaisuuksia erittäin hyvin ja löytää maksimimäärän vikoja.
Julkaisuilmoitus: Se on asiakirja, joka laaditaan tuotteen julkaisun yhteydessä ja jonka testauspäällikkö allekirjoittaa.
Alla olevassa kuvassa näemme, että lopullinen tuote on kehitetty ja otettu käyttöön asiakkaalle, ja viimeisin julkaisunimi on Beeta .
The Julkaisuilmoitus koostuu seuraavista:
- Ohjekirja.
- Luettelo vireillä olevista ja avoimista vioista.
- Luettelo lisätyistä, muokatuista ja poistetuista ominaisuuksista.
- Luettelo alustasta (käyttöjärjestelmä, laitteisto, selaimet), jolla tuotetta testataan.
- Alusta, jolla tuotetta ei ole testattu.
- Luettelo nykyisen julkaisun korjatuista virheistä ja luettelo edellisen julkaisun korjatuista virheistä.
- Asennusprosessi
- Ohjelmiston versiot
Esimerkiksi
Olettaa, että Beeta on sovelluksen toinen julkaisu ensimmäisen julkaisun jälkeen Alpha on ilmestynyt. Osa viasta, joka tunnistettiin ensimmäisessä julkaisussa ja joka on korjattu myöhemmin julkaistussa. Ja tässä osoitamme myös luettelon äskettäin lisätyistä, muokatuista ja poistetuista ominaisuuksista alfajulkaisusta betaversioon.
Sapluuna
Tämä osa sisältää kaikki mallit tuotteessa käytettäville asiakirjoille, ja kaikki testiinsinöörit käyttävät vain näitä malleja projektissa säilyttääkseen tuotteen yhtenäisyyden. Täällä meillä on erilaisia malleja, joita käytetään koko testausprosessin aikana, kuten:
- Testitapausmalli
- Testitapauksen tarkistusmalli
- RTM-malli
- Virheraporttimalli
- Testin suoritusraportti
Katsotaanpa yksi esimerkki testisuunnitelmaasiakirjasta
Sivu 1
Sivu3-sivu18
Sivu-20
Sivulla 1 täytämme ensisijaisesti vain Versiot, kirjoittaja, kommentit ja arvioima kenttiin, ja kun johtaja on hyväksynyt sen, mainitsemme yksityiskohdat Hyväksytty ja hyväksymispäivämäärä kentät.
Useimmiten testisuunnitelman hyväksyy testauspäällikkö, ja testiinsinöörit vain tarkistavat sen. Ja kun uudet ominaisuudet tulevat, muokkaamme testisuunnitelmaa ja teemme tarvittavat muutokset Versio kenttään, ja se lähetetään sitten uudelleen tarkastettavaksi, päivitettäväksi ja johtajan hyväksyttäväksi. Testisuunnitelma on päivitettävä aina, kun muutoksia on tapahtunut. Sivulla 20 Viitteet määritä tiedot kaikista asiakirjoista, joita aiomme käyttää testisuunnitelman laatimiseen.
Huomautus:
Kuka kirjoittaa testisuunnitelman?
- Testijohto → 60 %
- Test Manager → 20%
- Testausinsinööri → 20 %
Siksi, kuten ylhäältä voimme nähdä, että 60 %:ssa tuotteesta testisuunnitelman on kirjoittanut testijohto.
Kuka arvioi testisuunnitelman?
- Testijohto
- Testipäällikkö
- Testin insinööri
- Asiakas
- Kehitystiimi
Testausinsinööri tarkastelee testisuunnitelmaa moduulin näkökulmasta ja testipäällikkö tarkastelee testisuunnitelmaa asiakkaan mielipiteen perusteella.
Kuka hyväksyy testisuunnitelman?
- Asiakas
- Testipäällikkö
Kuka kirjoittaa testitapauksen?
- Testijohto
- Testi-insinööri
Kuka arvioi testitapauksen?
java-merkkijonon muunnos int:ksi
- Testi-insinööri
- Testijohto
- Asiakas
- Kehitystiimi
Kuka hyväksyy testitapaukset?
- Testipäällikkö
- Testijohto
- Asiakas
Testisuunnitelman ohjeet
- Kutista testisuunnitelmasi.
- Vältä päällekkäisyyksiä ja redundanssia.
- Jos uskot, että et tarvitse jo mainittua osiota, poista se ja jatka eteenpäin.
- Ole tarkka. Kun esimerkiksi määrität ohjelmistojärjestelmän testiympäristön osaksi, mainitse ohjelmistoversio pelkän nimen sijaan.
- Vältä pitkiä kappaleita.
- Käytä luetteloita ja taulukoita aina kun mahdollista.
- Päivitä suunnitelma tarvittaessa.
- Älä käytä vanhentunutta ja käyttämätöntä asiakirjaa.
Testisuunnitelman merkitys
- Testisuunnitelma antaa suuntaa ajattelullemme. Tämä on kuin sääntökirja, jota tulee noudattaa.
- Testisuunnitelma auttaa määrittämään tarvittavat toimet testattavan ohjelmistosovelluksen laadun validoimiseksi.
- Testisuunnitelma auttaa ihmisiä ymmärtämään testin yksityiskohtia, jotka liittyvät ulkopuoliseen, kuten kehittäjiin, yritysjohtajiin, asiakkaisiin jne.
- Tärkeät näkökohdat, kuten testiaikataulu, testausstrategia, testin laajuus jne. dokumentoidaan testisuunnitelmaan, jotta johtoryhmä voi tarkistaa ne ja käyttää niitä uudelleen muissa vastaavissa projekteissa.