kaikkien projektien onnistumisen kannalta testauksen estimointi ja asianmukainen toteutus ovat yhtä tärkeitä kuin kehityssykli. Arviossa pysyminen on erittäin tärkeää hyvän maineen rakentamiseksi asiakkaan kanssa.
kokemuksella on suuri merkitys arvioitaessa ”ohjelmistojen Testausponnisteluja”. Erilaisten projektien parissa työskentely auttaa meitä laatimaan tarkan arvion testisyklistä.
on selvää, ettei mihinkään testaustehtävään voi sokeasti laittaa joitakin päiviä. Testin arvioinnin on oltava realistinen ja tarkka.
tämä opetusohjelma sisältää joitakin tärkeitä osoittimia, jotka ovat erittäin hyödyllisiä tarkan testiarvioinnin laatimisessa hyvin yksinkertaisella tavalla.
Test Estimation Process
”estimointi on prosessi, jossa etsitään estimaatti tai approksimaatio, joka on arvo, jota voidaan käyttää johonkin tarkoitukseen, vaikka syöttötiedot saattaisivat olla epätäydellisiä, epävarmoja tai epävakaita.”
me kaikki kohtaamme erilaisia tehtäviä, velvollisuuksia ja määräaikoja läpi elämämme ammattilaisina, nyt on olemassa kaksi tapaa löytää ratkaisu ongelmaan.
ensimmäinen lähestymistapa on reaktiivinen lähestymistapa, jossa yritämme löytää ratkaisun käsillä olevaan ongelmaan vasta sen saavuttua.
toisessa lähestymistavassa, jota voidaan kutsua ennakoivaksi lähestymistavaksi, valmistaudumme ensin hyvissä ajoin ennen ongelman saapumista aikaisempien kokemustemme avulla ja pyrimme sitten löytämään ratkaisun haasteeseen, kun se saapuu.
estimointia voidaan siis pitää tekniikkana, jota sovelletaan, kun ongelmaan suhtaudutaan ennakoivasti.
näin ollen estimoinnin avulla voidaan ennustaa, kuinka paljon aikaa ja kustannuksia tietyn tehtävän suorittaminen vaatisi. Kun testiryhmä pystyy tekemään arvion käsillä olevasta ongelmasta, heidän on helpompi keksiä ratkaisu, joka olisi optimaalinen käsillä olevaan ongelmaan.
estimointikäytäntö voidaan sitten määritellä muodollisemmin likimääräisenä laskutoimituksena teoksen todennäköisistä kustannuksista.
myös read = > 7 Seleeniautomaatioprojektin testiin vaikuttavat tekijät
perusedellytykset
alla on esitetty testin Estimointiprosessin perusedellytykset.
#1) aiemmista kokemuksista saadut oivallukset: on aina hyvä käytäntö viettää aikaa muistellen menneitä projekteja, jotka aiheuttivat samanlaisia haasteita kuin nykyinen pyrkimys.
#2) saatavilla olevat asiakirjat tai artefaktit: Testinhallintatietokannan työkalut ovat käteviä tämäntyyppisissä skenaarioissa, koska ne tallentavat vaatimukset ja selvennysasiakirjat. Testiryhmä voi viitata näihin asiakirjoihin määritelläkseen selkeästi hankkeen laajuuden.
#3) oletukset työn tyypistä: aiempi työkokemus auttaa tekemään oletuksia projektista. Tässä kohtaa kokeneiden ammattilaisten palkkaaminen on tärkeintä. Testaus johtajat voivat poimia aivot näiden ihmisten tuottaa toivottuja tuloksia.
#4) mahdollisten riskien ja uhkien laskeminen: Testiryhmän on myös visualisoitava mahdolliset riskit ja uhat ja sudenkuopat, jotka valehtelevat voivat olla tiimille tulevaisuudessa.
#5) sen määrittäminen, onko asiakirjat hyväksytty Baselin standardiin: testiryhmän on myös määritettävä, onko vaatimukset hyväksytty Baselin standardissa vai ei. Jos asiakirjoja ei ole luetteloitu, on tärkeää määrittää muutosten tiheys.
#6) kaikkien vastuiden ja riippuvuuksien tulisi olla selkeitä: organisaation tulisi määritellä selkeästi roolit ja vastuut kaikille niille, jotka suorittaisivat estimointiprosessia.
#7) estimointitietojen dokumentointi ja seuranta: kaikki estimointiprosessin kannalta olennaiset tiedot on dokumentoitava.
#8) testin estimointiprosessin aikana suoritettavat toimet:
- Järjestä ryhmä, joka suorittaa arviointeja.
- hajota hanke hankevaiheisiin ja niitä seuraaviin toimintoihin.
- lasketaan arvio aiempien projektien ja työkokemuksen perusteella.
- priorisoi mahdolliset uhat ja keksi lähestymistapoja riskien vähentämiseksi.
- käy läpi ja dokumentoi teoksen olennaiset osat.
- toimita työ asianomaisille sidosryhmille.
merkittävimmät testin Estimointimenetelmät
joitakin tärkeimpiä testin estimointimenetelmiä ovat:
- testipisteen estimointi
- työvaiheeseen perustuva estimointi
- käyttötapauspisteen estimointi
miten ja missä näitä tekniikoita käytetään:
#1) testipisteen estimointi on yksinkertainen ja helposti ymmärrettävä estimointitekniikka, jota käytetään laajalti ohjelmistojen testispektrissä. Iteratiiviset vaiheet ja yksinkertaisuus ovat tämän erityisen tekniikan tärkeimmät ominaisuudet.
#2) työvaihe-estimointi on estimointimenetelmä, jossa tehdään arvausarvio tietystä vaiheesta (yleensä lyhyin ja yksinkertaisin vaiheista), minkä jälkeen testiryhmä lisää asteittain muita vaiheita alku-estimointiin ja lopulta tekee asianmukaisen estimoinnin.
#3) Use-Case Point estimation technique on estimointi käyttötapauksista, joissa ohjelmiston testauksen estimoinnin määrittämiseen käytetään oikaisemattomia toimijan painoja ja oikaisemattomia käyttötapauspainoja.
testipisteen Estimointimenetelmän yksityiskohdat
testipisteen estimointimenetelmä tehdään seuraavasti::
(tässä paradigmassa voidaan tarkastella seuraavia painoja, jotka voivat vaihdella projektikohtaisesti-jotkin näistä painoista ovat ohjelmointikielen painoja, jotka perustuvat koodin monimutkaisuuteen, sovelluspainoja, jotka perustuvat sovellustyyppiin, ja testipainoja, jotka on määritetty ohjelmiston testauksen eri vaiheiden perusteella.)
käsittelemättömät testipisteet kerrotaan CWF: llä, jotta saadaan testikoko testipisteen kokoon.
Tuottavuuskerroin ilmaisee, kuinka kauan testainsinöörillä on aikaa suorittaa yhden testipisteen testaus.
Testiponnistus Henkilötunteina lasketaan kertomalla testipisteen koko Tuottavuuskertoimella.
testipisteen estimointitekniikan laskennassa tarkastellaan seuraavia muuttujia.
- testivaatimuksen monimutkaisuus
- liitäntä muihin vaatimuksiin
- tarkastuspisteiden kokonaismäärä
- Lähtötestitiedot
tämän jälkeen on tarkasteltava painovektoreita kullekin datamuuttujalle ja järjestettävä ne seuraavalla tavalla.
Säätötekijä = keskiarvo (kompleksisuuspainon ja tekijäpainon tulo) / 30
Säätötestipiste testitapauksen suunnittelua varten = Testipiste X (1 + Säätötekijä Testitapauksen suunnittelua varten)
mukautettu Testipiste testitapauksen toteutusta varten = Testipiste X (1 + Säätötekijä Testitapauksen toteutusta varten))
kokonaistestipiste (normalisoitu) x (1 + säätökerroin testitapauksen suunnittelua/toteutusta varten) = mukautettu testipiste testitapauksen suunnittelua/toteutusta varten
kokonaisponnistus Henkilötunnit (PH) = normalisoitujen testipisteiden määrä / Tuottavuus (Normalisoiduissa testipisteissä Henkilötuntia kohti)
testin Estimointiesimerkit
yritetään soveltaa edellä mainittua formulaatiota muuhun käytännön käyttöön.
Oletetaan, että päädymme testivaatimukseen, jossa meillä on testattavana 5 testiskenaariota.
nyt sanotaan, että testiskenaariossa 1 on 5 testin odotettuja tuloksia, testiskenaariossa 2 on 6 testin odotettuja tuloksia, testiskenaariossa 3 vain 2 testin odotettuja tuloksia, testiskenaariossa 4 9 testin odotettuja tuloksia, testiskenaariossa 5 myös 9 testin odotettuja tuloksia.
luokittelemme testiskenaariot kolmeen luokkaan, eli monimutkaisiin, yksinkertaisiin ja kohtalaisiin, perustuen näiden kolmen luokan odotettujen tulosten kokonaismäärään.
Kompleksiluokissa on yli 7 odotettua tulosta, kun taas yksinkertaisissa luokissa on alle 5 odotettua tulosta ja maltillisissa skenaarioissa 4-7 odotettua tulosta.
näin ollen luokittelemme testiskenaarion 1 ja testiskenaarion 2 kohtalaisiksi skenaarioiksi, skenaarion 5 ja skenaarion 6 monimutkaisiksi skenaarioiksi ja testiskenaarion 3 yksinkertaiseksi.
sovellamme nyt testipisteitä kaikkiin näihin skenaarioihin. Sovellimme 5 testipistettä monimutkaisiin luokkiin, 3 kohtalaisiin ja 2 yksinkertaisiin skenaarioihin.
kerrotaan oletetut testipisteet kaikkien näiden testiskenaarioiden odotettujen tulosten kokonaismäärällä. Niinpä päädymme seuraaviin likiarvoihin:
Skenaario 1: 3 testipistettä * 5 testitulosta = mukautetut testipisteet = 25
skenaario 2: 3 testipistettä * 6 testitulosta = mukautetut testipisteet = 30
skenaario 3: 2 testipistettä * 2 testitulosta = Adjusted test points = 4
Scenario 4: 5 testipistettä * 9 testitulosta = Adjusted test points = 45
Scenario 5: 5 testipistettä * 9 testitulosta = Adjusted test points = 45
joten ottaen huomioon, että meidän on haettava vaikkapa 5 Henkilötuntia jokaista adjustoitua testipistettä kohti, saamme seuraavan likimääräisen tuloksen.
Testiskenaario 1: 25 mukautettua testipistettä * 5 Henkilötuntia = 125 Henkilötuntia
Testiskenaario 2: 30 mukautettua testipistettä * 5 Henkilötuntia = 150 Henkilötuntia
Testiskenaario 3: 4 mukautettua testipistettä * 5 Henkilötuntia= 20 Henkilötuntia
Testiskenaario 4: 45 mukautettua testipistettä * 5 Henkilötuntia = 225 Henkilötuntia
Testiskenaario 5: 45 mukautettua testipistettä * 5 Henkilötuntia = 225 Henkilötuntia
joten arvioitu henkilötuntien kokonaismäärä on: 745 Henkilötuntia
Käyttötapauspisteen arviointimenetelmä
Käyttötapauspistemenetelmä perustuu käyttötapaukset, joissa laskemme Kokonaistestin Estimointiponnistuksen käyttötapausten tai vaatimusten perusteella.
alla on yksityiskohtainen prosessi käyttötapauspisteen estimointimenetelmästä:
esimerkki samasta on, että tietyssä vaatimuksessa meillä on 5 käyttötapausta, käyttötapaus 1, käyttötapaus 2,…, käyttötapaus 5. Nyt tarkastellaan, että use case 1 koostuu 6 toimijoiden, use case 2 koostuu 15 toimijoiden, use case 3, 4 ja 5, 3, 4 ja 5 toimijoiden vastaavasti.
pidämme jokaista käyttötapausta, jossa näyttelijöiden kokonaismäärä on alle 5 negatiivisena, jokaista käyttötapausta, jossa näyttelijöiden kokonaismäärä on vähintään 5 ja enintään 10 positiivisena ja jokaista käyttötapausta, jossa toimijoita on enemmän kuin 10, poikkeuksellisena.
päätimme antaa poikkeuskäyttötapauksista 2 pistettä, positiivisista 1 ja negatiivisista -1.
näin ollen luokittelemme käyttötapaukset 1 ja 5 positiivisiksi, käyttötapaukset 2 poikkeuksellisiksi ja käyttötapaukset 3, 4 negatiivisiksi edellä esitettyjen oletustemme perusteella.
eli käsittelemätön toimija punnitsee = käyttötapaus 1 = (näyttelijöiden kokonaismäärä) 5 * 1 (annettu piste) = 5. Samoin
käyttötapaus 2 = 15 * 2 = 30 .
toistamalla prosessin muiden käyttötapausten osalta saamme käsittelemättömän toimijan painot = 33
käsittelemättömän käyttötapauksen paino = yhteensä no. käyttötapaukset = 5
käsittelemätön käyttötapauspiste = muokkaamaton näyttelijän painot + Muokkaamaton käyttötapauksen paino = 33 + 5 = 38
jalostetun käytön case point = 38 * = 26.7 tai 28 Henkilötuntia noin
työvaiheen Erittelytekniikka
työvaiheen erittelytekniikka voidaan kuvata seuraavissa vaiheissa.
- Jaa kokonaistyö vaiheisiin.
- Aloita yksinkertaisimmasta vaiheesta ja anna sille likimääräinen estimointiarvo.
- sen jälkeen on määriteltävä seuraava mahdollinen vaihe, joka voidaan aloittaa tämän vaiheen päätyttyä.
- johdetaan mahdollinen likiarvojoukko, jota voitaisiin soveltaa tähän vaiheeseen, ja valitaan suurin arvo kaikkien johdettujen likiarvojen joukosta.
- summaa arvioitu estimointiarvo lisäämällä nykyisen vaiheen ponnistuksen estimointiarvo jo olemassa olevaan arvoon.
- jatketaan vaiheilla 3-5, kunnes kaikki ensimmäisessä vaiheessa yksilöidyt vaiheet on käytetty loppuun.
- hyväksy lopullinen likimääräinen estimaattiarvo lopulliseksi.
Oletetaan, että vaatimuksessa on 5 vaadittua vaihetta. Ensimmäisessä vaiheessa 1 oletamme, että tarvittava kokonaisponnistus on 35 henkilötuntia ja sitten aloitamme seuraavan vaiheen 2, jolle meillä on 4 vertailevaa oletusta 35, 45, 55 ja 65 vastaavasti.
pidämme 65 henkilötuntia, joka on tässä suurin arvo. Vaiheessa 3, 4, 5 keksimme arvioita (12 , 33, 43 , 54) , (15 , 10 , 7 , 8) ja (2 , 16 , 5 , 13) vastaavasti. Soveltamalla mainitun periaatteen päädymme 185 Henkilötuntia vastaavasti.
laitan tietoa-miten arvioida testauspanostuksia mihin tahansa testaustehtävään, jonka opin kokemuksestani.
9 yleistä vinkkiä siitä, miten testiaika arvioidaan tarkasti
tekijät, jotka vaikuttavat ohjelmiston testauksen estimointiin, ja yleiset vinkit, joilla arvioidaan tarkasti:
#1) ajatelkaa Puskuriaikaa: arvioon pitäisi sisältyä puskuria. Mutta älä lisää puskuria, joka ei ole realistinen. Kun estimoinnissa on puskuri, voimme selviytyä mahdollisista viivästyksistä. Puskuri auttaa myös varmistamaan mahdollisimman kattavan testauksen.
#2) tarkastellaan Vikasykliä: testin estimointiin sisältyy myös vikasykli. Varsinainen testisykli voi kestää arvioitua enemmän päiviä.
tämän välttämiseksi on otettava huomioon, että testisykli riippuu rakenteen vakaudesta. Jos rakenne ei ole vakaa, kehittäjät voivat tarvita enemmän aikaa korjata sen ja tietenkin, testausjakso saa laajennettu automaattisesti.
#3) kaikkien resurssien saatavuus arvioituna ajanjaksona: Testiarviossa on otettava huomioon kaikki tiimin jäsenten suunnittelemat lehdet (tyypillisesti pitkät lehdet) lähiviikkoina tai lähikuukausina. Näin varmistetaan, että arviot ovat realistisia.
estimoinnissa olisi otettava huomioon jokin kiinteä resurssien määrä testisykliä varten. Jos resurssien määrä vähenee, arvio on tarkistettava ja päivitettävä vastaavasti.
#4) Voimmeko Tehdä Rinnakkaiskokeita? Onko sinulla aikaisempia versioita samasta tuotteesta, jotta voit vertailla tuotosta? Jos kyllä, niin tämä voi tehdä testaus tehtävä hieman helpompaa. Arvio kannattaa miettiä oman tuoteversion perusteella.
#5)Estimoinnit voivat mennä pieleen – joten käy arvioinnit usein uudelleen alkuvaiheessa ennen kuin toimitat ne: alkuvaiheessa meidän pitäisi usein käydä uudelleen testeissä ja tehdä tarvittaessa muutoksia. Meidän ei pitäisi laajentaa arviota jäädytettyämme sen, ellei vaatimuksissa tapahdu suuria muutoksia.
#6) ajattele aikaisempaa kokemustasi tehdä tuomioita! Aiemmista hankkeista saadut kokemukset ovat tärkeässä roolissa aika-arvioita laadittaessa. Voimme yrittää välttää kaikki vaikeudet tai ongelmat, joita aiemmissa hankkeissa oli. Voimme analysoida, miten aiemmat arviot olivat ja kuinka paljon ne auttoivat toimittamaan tuotteen ajoissa.
#7) Pohdi projektin laajuutta: tiedä mikä on projektin lopullinen tavoite ja Luettele kaikki lopulliset tuotokset. Pienissä ja suurissa hankkeissa huomioon otettavat tekijät eroavat paljon toisistaan. Suuret projektit sisältävät tyypillisesti testipohjan perustamisen, testitietojen tuottamisen, testiskriptit jne.
näin ollen arvioiden olisi perustuttava kaikkiin näihin tekijöihin. Kun taas pienissä projekteissa tyypillisesti testisykli sisältää testitapauksen kirjoittamisen, suorittamisen ja regression.
#8) Aiotko suorittaa kuormitustestauksen? Jos haluat laittaa paljon aikaa suorituskyvyn testaus sitten arvioida vastaavasti. Hankkeiden, joihin liittyy kuormitustestausta, arviointeja olisi tarkasteltava eri tavalla.
#9)Tunnetko Joukkueesi? Jos tiedät tiimissäsi työskentelevien henkilöiden vahvuudet ja heikkoudet, voit arvioida testaustehtäviä tarkemmin. Arvioitaessa on otettava huomioon se, että kaikki resurssit eivät välttämättä tuota samaa tuottavuustasoa.
jotkut pystyvät suorittamaan nopeammin kuin toiset. Vaikka tämä ei ole merkittävä tekijä, se lisää jopa koko viive suoritteet.
Conclusion
Software test estimation on käytäntö, joka edellyttää kokeneiden ammattilaisten osallistumista sekä alan parhaiden käytäntöjen, kuten test case point-ja use case point-menetelmien käyttöönottoa.
on myös tärkeää omaksua avoin mieli tarvittavien prosessien muokkaamiseen. Näiden prosessien onnistunut toteuttaminen parantaa yleisesti testausprosessia.
tämä on kirjailija ”N. Sandhya Ranin” vieraileva artikkeli.
Viimeksi Päivitetty: 29. Marraskuuta 2021
