Manuaalinen testaus on ohjelmistojen testausprosessi, jossa testitapaukset suoritetaan manuaalisesti ilman automaattista työkalua. Kaikki testitapaukset, jotka testaaja suorittaa manuaalisesti loppukäyttäjän näkökulman mukaan. Se varmistaa, toimiiko sovellus, kuten vaatimusasiakirjassa mainitaan vai ei. Testitapaukset suunnitellaan ja toteutetaan lähes 100 prosenttia ohjelmistosovelluksesta. Testitapausraportit luodaan myös manuaalisesti.

Manuaalinen testaus on yksi tärkeimmistä testausprosesseista, koska se voi löytää sekä näkyviä että piilotettuja ohjelmiston vikoja. Ohjelmiston antama ero odotetun lähdön ja lähdön välillä määritellään viaksi. Kehittäjä korjasi viat ja antoi sen testaajalle uudelleen testattavaksi.

Manuaalinen testaus on pakollinen jokaiselle uusille ohjelmistolle ennen automaattista testausta. Tämä testaus vaatii suuria ponnisteluja ja aikaa, mutta se takaa virheettömän ohjelmiston. Manuaalinen testaus edellyttää manuaalisten testaustekniikoiden tuntemusta, mutta ei mitään automaattista testaustyökalua.

Manuaalinen testaus on välttämätöntä, koska yksi niistä ohjelmistojen testaus perusasia on '100 % automaatio ei ole mahdollista.'

Miksi tarvitsemme manuaalista testausta

Aina kun sovellus tulee markkinoille ja se on epävakaa tai siinä on virhe tai ongelmia tai se aiheuttaa ongelmia loppukäyttäjien käyttäessä sitä.

Jos emme halua kohdata tällaisia ​​ongelmia, meidän on suoritettava yksi testauskierros tehdäksemme sovelluksesta virheettömän ja vakaan sekä toimittaaksemme laadukkaan tuotteen asiakkaalle, koska jos sovellus on bugiton, loppukäyttäjä käyttää sovellusta kätevämmin.

Jos testiinsinööri tekee manuaalista testausta, hän voi testata sovellusta loppukäyttäjän näkökulmasta ja tutustua tuotteeseen paremmin, mikä auttaa kirjoittamaan sovelluksen oikeat testitapaukset ja antamaan nopean palautteen sovelluksesta.

Manuaalisen testauksen tyypit

Manuaalisessa testauksessa käytetään erilaisia ​​menetelmiä. Jokaista tekniikkaa käytetään sen testauskriteerien mukaisesti. Manuaalisen testauksen tyypit on esitetty alla:

• Valkoisen laatikon testaus
• Mustan laatikon testaus
• Harmaan laatikon testaus

Valkoisen laatikon testaus

Kehittäjä tekee valkoisen laatikon testauksen, jossa he tarkistavat koodin jokaisen rivin ennen sen antamista testausinsinöörille. Koska koodi näkyy Kehittäjälle testauksen aikana, se tunnetaan myös nimellä White box -testaus.

Lisätietoja valkoisen laatikon testaamisesta on alla olevasta linkistä:

https://www.javatpoint.com/white-box-testing

Mustan laatikon testaus

Mustan laatikon testauksen tekee Testausinsinööri, jossa hän voi tarkistaa sovelluksen tai ohjelmiston toimivuuden asiakkaan/asiakkaan tarpeiden mukaan. Tässä koodi ei näy testauksen aikana; siksi se tunnetaan mustan laatikon testauksena.

Lisätietoja black-box-testauksesta saat alla olevasta linkistä:

https://www.javatpoint.com/black-box-testing

Grey Box -testaus

Harmaan laatikon testaus on valkoisen ja mustan laatikon testauksen yhdistelmä. Sen voi suorittaa henkilö, joka osasi sekä koodauksen että testauksen. Ja jos yksittäinen henkilö suorittaa valkoisen laatikon ja mustan laatikon testauksen sovellukselle, sitä kutsutaan harmaalaatikon testaukseksi.

Saat lisätietoja harmaan laatikon testauksesta alla olevasta linkistä:

https://www.javatpoint.com/grey-box-testing

sql-määrä erillinen

Manuaalisen testauksen suorittaminen

• Ensin testaaja tarkkailee kaikkia ohjelmistoon liittyviä asiakirjoja valitakseen testausalueet.
• Testaaja analysoi vaatimusasiakirjat kattaakseen kaikki asiakkaan ilmoittamat vaatimukset.
• Testaaja kehittää testitapaukset vaatimusasiakirjan mukaisesti.
• Kaikki testitapaukset suoritetaan manuaalisesti käyttämällä Black Box -testausta ja white box -testausta.
• Jos virheitä ilmenee, testaustiimi ilmoittaa siitä kehitystiimille.
• Kehitystiimi korjaa virheet ja luovuttaa ohjelmistot testaustiimille uudelleentestausta varten.

Ohjelmiston rakennusprosessi

• Kun vaatimus on kerätty, se toimitetaan kahdelle eri tiimille kehitys- ja testaustiimille.
• Vaatimuksen saatuaan asianomainen kehittäjä alkaa kirjoittaa koodia.
• Ja sillä välin testiinsinööri ymmärtää vaatimuksen ja valmistelee vaaditut asiakirjat. Tähän asti kehittäjä voi täydentää koodin ja tallentaa sen Versiohallintatyökalu .
• Sen jälkeen koodi muuttuu käyttöliittymässä, ja nämä muutokset käsittelee yksi erillinen tiimi, joka tunnetaan nimellä rakentaa joukkuetta .
• Tämä rakennustiimi ottaa koodin ja aloittaa koodin kääntämisen ja pakkaamisen rakennustyökalun avulla. Kun olemme saaneet tulosteen, tuloste menee zip-tiedostoon, joka tunnetaan nimellä Rakentaa (sovellus tai ohjelmisto). Jokaisella versiolla on jokin yksilöllinen numero, kuten (B001, B002).
• Sitten tämä koontiversio asennetaan testipalvelimelle. Tämän jälkeen testiinsinööri käyttää tätä testipalvelinta Test-URL-osoitteen avulla ja aloittaa sovelluksen testauksen.
• Jos testaaja havaitsee virheen, hänestä ilmoitetaan asianomaiselle kehittäjälle.
• Sitten kehittäjä toistaa virheen testipalvelimessa ja korjaa virheen ja tallentaa koodin uudelleen Control version -työkaluun, ja se asentaa uuden päivitetyn tiedoston ja poistaa vanhan tiedoston. tätä prosessia jatketaan, kunnes saamme vakaan koontiversion.
• Kun olemme saaneet tallin rakentamisen, se luovutetaan asiakkaalle.

Huomautus1

• Kun olemme keränneet tiedoston hallintaversiotyökalusta, käytämme koontityökalua koodin kääntämiseen korkean tason kielestä konetason kieleen. Kääntämisen jälkeen, jos tiedoston koko kasvaa, niin pakkaamme kyseisen tiedoston ja upotetaan testipalvelimeen.
• Tämän prosessin suorittaa Rakenna joukkue , kehittäjä (jos rakennustiimiä ei ole, kehittäjä voi tehdä sen) tai testijohto (jos rakennustiimi käsittelee zip-tiedoston suoraan ja asentaa sovelluksen testipalvelimelle ja ilmoita siitä testiinsinöörille).
• Yleensä emme voi saada uutta versiota jokaiselle bugille; Muuten suurin osa ajasta menee hukkaan vain rakennelmien luomiseen.

Muistio 2

Rakenna joukkue

Rakennustiimin päätehtävänä on luoda sovellus tai Build ja muuntaa korkean tason kieli matalan tason kieleksi.

Rakentaa

Se on ohjelmisto, jota käytetään koodin muuntamiseen sovellusmuotoon. Ja se koostuu joukosta ominaisuuksia ja virheenkorjauksia, jotka luovutetaan testausinsinöörille testausta varten, kunnes se muuttuu vakaaksi.

Versiohallintatyökalu

Se on ohjelmisto tai sovellus, jota käytetään seuraaviin tarkoituksiin:

• Tällä työkalulla voimme tallentaa erityyppisiä tiedostoja.
• Se on aina suojattu, koska käytämme tiedostoa työkaluista samoilla kirjautumistiedoilla.
• Työkalujen ensisijainen tavoite on seurata olemassa oleviin tiedostoihin tehtyjä muutoksia.

Esimerkki rakennusprosessista

Katsotaanpa yksi esimerkki ymmärtääksesi kuinka rakentaa prosessityötä todellisissa skenaarioissa:

Heti kun testiinsinööri saa virheen, he lähettävät sen kehittäjille, ja he tarvitsevat jonkin aikaa analysoidakseen; sen jälkeen hän vain korjaa vian (Testiinsinööri ei voi antaa bugikokoelmaa).

Kehittäjä päättää, kuinka monta virhettä hän voi korjata aikansa mukaan. Ja testausinsinööri päättää, mikä bugi tulee korjata ensin heidän tarpeidensa mukaan, koska testiinsinööreillä ei ole varaa lopettaa testausta.

Ja testausinsinööri, joka saa postia, voi tietää vain sen, mikä virhe on korjattu luettelo virheenkorjauksista .

Aika pitenee, koska ensimmäisessä Buildissa ja kehittäjien tulisi kirjoittaa koodi eri ominaisuuksiin. Ja lopulta hän voi tehdä vain virheenkorjauksia ja päivien lukumäärää vähennetään.

Huomautus3

Testisykli

Testisykli on aika, joka testiinsinöörille annetaan testata jokaista rakennelmaa.

Erot näiden kahden rakenteen välillä

Virheet löytyvät yhdestä versiosta ja ne voidaan korjata missä tahansa tulevassa versiossa, mikä riippuu testiinsinöörin vaatimuksista. Jokainen uusi Build on muokattu versio vanhasta, ja nämä muutokset voivat olla virheenkorjauksia tai joidenkin uusien ominaisuuksien lisäämistä.

Kuinka usein saimme uuden Buildin

Aluksi saimme viikoittaisia ​​koontiversioita, mutta viimeisimmässä testausvaiheessa, kun sovellus oli vakiintumassa, saimme uuden Buildin kerran 3 päivässä, kahdessa päivässä tai myös päivittäin.

Kuinka monta rakennusta saamme

Jos otamme huomioon yhden vuoden projektin keston, saimme 22-26 rakennusta.

Kun saamme virheenkorjauksia

Yleensä ymmärrämme virheenkorjaukset vasta, kun testisykli on suoritettu tai virheiden kokoelma on korjattu yhdessä koontiversiossa ja luovutus seuraavissa versioissa.

Manuaalisen testauksen edut

• Se ei vaadi ohjelmointiosaamista käytettäessä Black box -menetelmää.
• Sitä käytetään dynaamisesti muuttuvien GUI-mallien testaamiseen.
• Testaaja on vuorovaikutuksessa ohjelmistojen kanssa todellisena käyttäjänä, jotta he voivat löytää käytettävyys- ja käyttöliittymäongelmia.
• Se varmistaa, että ohjelmisto on sataprosenttisesti virheetön.
• Se on kustannustehokasta.
• Helppo oppia uusille testaajille.

Manuaalisen testauksen haitat

• Se vaatii suuren määrän henkilöresursseja.
• Se on erittäin aikaa vievää.
• Testaaja kehittää testitapauksia taitojensa ja kokemuksensa perusteella. Ei ole näyttöä siitä, että ne olisivat kattaneet kaikki toiminnot vai eivät.
• Testitapauksia ei voi käyttää uudelleen. Jokaiselle uudelle ohjelmistolle on kehitettävä erilliset testitapaukset.
• Se ei tarjoa testausta kaikista testauksen näkökohdista.
• Koska kaksi tiimiä työskentelee yhdessä, on joskus vaikea ymmärtää toistensa motiiveja, mikä voi johtaa prosessia harhaan.

Manuaaliset testaustyökalut

Manuaalisessa testauksessa, erityyppisissä testauksissa, kuten yksikkö-, integraatio-, tietoturva-, suorituskyky- ja virheseuranta, meillä on saatavilla erilaisia ​​työkaluja, kuten Jira , Bugzilla , Mantis, Zap, NUnit, Tessy, LoadRunner, Citrus, SonarQube jne. markkinoida. Osa työkaluista on avoimen lähdekoodin, osa kaupallisia.

Lisätietoja testaustyökaluista on alla olevasta linkistä:

https://www.javatpoint.com/software-testing-tools

Ymmärrämme ne yksitellen:

LoadRunner

Se on yleisimmin käytetty suorituskyvyn testaustyökalu. LoadRunneria käytetään pääasiassa tukemaan suorituskyvyn testausta useissa eri menetelmissä, useissa lähestymistavoissa ja sovellusympäristöissä.

LoadRunner-työkalun suorittamisen päätarkoitus on luokitella yleisimmät suorituskykyongelmien lähteet nopeasti.

LoadRunnerin ominaisuudet

• LoadRunner-työkalu sisältää n-määrä sovelluksia, mikä vähentää raporttien ymmärtämiseen ja kuvaamiseen kuluvaa aikaa.
• LoadRunner-työkalun avulla voimme saada kattavat suoritustestiraportit.
• Se vähentää hajautetun kuormitustestauksen kustannuksia ja tarjoaa myös toiminnallisen työkalun käyttöönoton seurantaan.

Sitrus

Citrus on integraatiotestaustyökalu, joka on yleisimmin käytetty testikehys. Se on kirjoitettu sisään Java ohjelmointi Kieli. Sitä käytetään enimmäkseen palvelin- ja asiakaspuolen pyytämiseen ja niihin vastaamiseen sekä XML JSON -tiedostojen vahvistamiseen.

Päästä päähän -käyttötapausten testauksen suorittamiseksi citrus tukee useita HTTP-, JMS- ja SOAP-protokollia.

Sitruunan ominaisuudet

Seuraavassa on joitain Citrus-työkalun tärkeitä ominaisuuksia:

• Sitä käytetään viestien lähettämiseen ja vastaanottamiseen.
• Citrus on saatavana sekä avoimena lähdekoodina että lisensoituna markkinoilla.
• Se tarjoaa edullisen ratkaisun.
• Voimme todentaa tietokannan käyttämällä sitrustyökalua.
• Se kuvaa viestien järjestyksen, tarjoaa testisuunnitelman ja dokumentoi testin kattavuuden.
• Se luo viestin ja tarkistaa vastaukset.

ZAP

ZAP on avoimen lähdekoodin verkkosovellusten suojausskanneri. Se edustaa Zed Attack Proxy . Kuten jotkut muut työkalut, se on myös kirjoitettu Java-ohjelmointikieli . Se on tehokkain Avaa Web Application Security Projects [OWASP].

ZAP:n ominaisuudet

• Se tukee monia käyttöjärjestelmiä, kuten Windows, Linux, OS X.
• Siinä on laajennuspohjainen arkkitehtuuri.
• Se sisältää online-markkinapaikan, jonka avulla voimme lisätä uusia tai päivitettyjä ominaisuuksia.
• ZAP:n GUI-ohjauspaneeli on helppokäyttöinen.

Nunna

NUnit on yksi yleisimmin käytetyistä yksikkötestaustyökaluista. Se on avoimen lähdekoodin työkalu, ja se on peräisin ensisijaisesti JUnit .

Se oli kokonaan kirjoitettu C# ohjelmointikieli ja sopii kaikille .Net kielet .

Toisin sanoen voimme sanoa, että NUnit-työkalu on suunniteltu kokonaan uudelleen, jotta siitä tulee eduksi monista .Net-kielen ominaisuuksista. Esimerkiksi:

Heijastukseen liittyvät ominaisuudet. Muut mukautetut attribuutit.

NUnitin ominaisuudet

• Se sallii väitteet etuluokan staattisena menetelmänä.
• Se ylläpitää tietopohjaisia ​​testejä.
• Se tukee useita alustoja, kuten .NET core Xamarin mobile, Silverlight ja tehokas kehys.
• NUnitin kyky auttaa meitä suorittamaan testit samanaikaisesti.
• Se käyttää konsolin juoksijaa testien lataamiseen ja suorittamiseen.

JIRA

Usein käytetty vianseurantatyökalu on JIRA , joka on avoimen lähdekoodin työkalu. Sitä käytetään vikojen seurantaan, projektinhallintaan ja ongelmien seurantaan.

Tällä työkalulla voimme helposti seurata kaikenlaisia ​​ohjelmistoon liittyviä ja testiinsinöörien tuottamia vikoja.

JIRAn ominaisuudet

• Se on aikaa säästävä työkalu.
• Jiraa käytetään vikojen ja ongelmien jäljittämiseen.
• Sitä käytetään dokumentointitehtävien määrittämiseen.
• Jira on erittäin hyödyllinen työkalu dokumentaatiomme kehittymisen seuraamiseen.

Saat täydelliset tiedot Jira-työkalusta alla olevasta linkistä: https://www.javatpoint.com/jira-tutorial.

SonarQube

Toinen manuaalisen testauksen testaustyökalu on SonarQube, joka parantaa työnkulkuamme jatkuvalla koodin laadulla ja suojauksella. Se on joustava lisäosien käytön ansiosta.

Se on kirjoitettu kokonaan JAVA-ohjelmointikielellä. Se tarjoaa täysin automatisoidun arvioinnin ja integroinnin Ant, Mavenin, Gradlen, MSBuildin ja jatkuvan integroinnin työkalujen kanssa. SonarQube pystyy tallentamaan mittaushistorian ja antamaan kehityskaavion.

aakkoset numeroissa

Sonarquben ominaisuudet

Alla on joitain SonarQube-työkalun merkittäviä ominaisuuksia:

• Se tukee useita ohjelmointikieliä, kuten C, C++, Python, JAVA, HTML, CSS, VB.NET, PHP, COBOL, PL/SQL jne.
• GNU Lesser General Public License -lisenssin alaisena Sonarqube on vapaasti saatavilla.
• SonarQube on sidoksissa joihinkin tärkeisiin ulkoisiin työkaluihin, kuten GitHub, Active Directory, LDAP ja muut.
• SonarQube yhdistettiin Visual Studio-, Eclipse- ja IntelliJ IDEA -kehitysympäristöihin, koska SonarLint laajennuksia.

JMeter

JMeter on avoimen lähdekoodin työkalu, jota käytetään sekä staattisten että dynaamisten resurssien ja dynaamisten verkkosovellusten suorituskyvyn testaamiseen.

Se on täysin suunniteltu JAVA-sovellukselle lataamaan toiminnallinen testikäyttäytyminen ja mittaamaan sovelluksen suorituskykyä.

Se auttaa käyttäjiä tai kehittäjiä käyttämään lähdekoodia muiden sovellusten kehittämiseen.

JMeterin ominaisuudet

Alla on joitain JMeterin olennaisia ​​ominaisuuksia:

• Se on alustasta riippumaton, mikä hyväksyy JVM:n kaltaisen Windows, Mac ja Linux jne.
• Se tukee käyttäjäystävällistä käyttöliittymää, joka on interaktiivinen ja suoraviivainen.
• Suorituskykytestin lataaminen useisiin palvelimiin on uskomattoman laajennettava.

Lisätietoja JMeteristä saat alla olevasta linkistä:

https://www.javatpoint.com/jmeter-tutorial.

Bugzilla

Toinen manuaalisessa testauksessa käytetty virheenseurantatyökalu on Bugzilla .

Monet organisaatiot käyttävät sitä laajimmin seuratakseen sovelluksen eri vikoja.

Bugzilla on avoimen lähdekoodin työkalu, joka auttaa asiakasta ja asiakasta seuraamaan vikoja. Bugzillaa pidetään myös testinhallintatyökaluna, koska siihen voimme helposti linkittää muita testitapausten hallintatyökaluja, kuten ALM, laatukeskus jne.

Bugzillan ominaisuudet

Bugzillassa on joitain lisäominaisuuksia, joiden avulla voimme ilmoittaa virheestä helposti:

• Se tukee erilaisia ​​käyttöjärjestelmiä, kuten Windowsia, Linuxia ja Macia.
• Bugzillan avulla voimme listata vian useissa muodoissa.
• Käyttäjäasetukset voivat mitata sähköposti-ilmoituksia.
• Bugzillassa on edistyneet hakuominaisuudet.

Mantis

Mantis on web-pohjainen vianseurantajärjestelmä. ManitsBT tarkoittaa Mantis Bug Tracker . Sitä käytetään ohjelmistovirheiden seuraamiseen ja suoritetaan PHP-ohjelmointikielellä. Se on myös avoimen lähdekoodin työkalu.

Mantiksen ominaisuudet

Jotkut tietyn työkalun vakioominaisuuksista ovat seuraavat:

• Tämän työkalun avulla meillä on koko tekstihaun esteettömyys.
• Ongelmiin tehtyjen muutosten seurantapolkuja.
• Se tarjoaa versioiden ohjausjärjestelmän integroinnin.
• Tekstikenttien ja muistiinpanojen tarkistushallinta

Saat lisätietoja virheenseurantatyökaluista seuraavasta linkistä: https://www.javatpoint.com/defect-or-bug-tracking-tool .

Tessy

Toinen integraation testaustyökalu on Tessy , jota käytetään sulautetun ohjelmiston integrointi- ja yksikkötestaukseen. Se auttaa meitä myös löytämään ohjelmiston tai sovelluksen koodikattavuuden.

Se voi helposti hallita koko testiorganisaatiota, mukaan lukien liiketoiminnan tarpeet, testien hallinta, peittomäärä ja jäljitettävyys.

Tessy sisältää kolme ensisijaista toimintoa, jotka ovat seuraavat:

• Test Interface Editor (TIE)
• Test Data Editor (TDE)
• Työtila.

TESSYn ominaisuudet

TESSYn vakioominaisuudet ovat seuraavat:

• Se tuottaa testiraportin testin suoritustuloksista.
• Se tukee useita ohjelmointikieliä, kuten C ja C++.
• Tessyä käytetään arvioimaan funktion käyttöliittymä ja se kuvaa funktion käyttämää muuttujaa.

Lisätietoja integroinnin testaustyökaluista on seuraavassa linkissä: https://www.javatpoint.com/integration-testing-tools.

Yleiskatsaus

Tässä artikkelissa olemme nähneet yksityiskohtaisia ​​tietoja Manuaalinen testaus, joka sisältää manuaalisen testauksen määrittelyn, manuaalisen testauksen tarpeen, manuaalisen testauksen tyypin, manuaalisen testauksen työkalut, manuaalisen testauksen prosessin sekä joitakin sen tärkeitä etuja ja haittoja.

Lopuksi voimme sanoa, että se on prosessi, jossa testiinsinöörin on oltava erittäin sinnikäs, innovatiivinen ja reagoiva.

Manuaalisessa testauksessa testiinsinöörin täytyy ajatella ja toimia kuten loppukäyttäjän tulkinta.

Manuaalisen testauksen toteuttamiseksi testiinsinööri tarvitsee tuottavaa taitoa ja mielikuvitusta. Ja heidän on mietittävä useita tilanteita tai skenaarioita tietyn sovelluksen testaamiseksi.

Vaikka voimme tällä hetkellä testata lähes kaikkia sovelluksia automaatiotestauksen avulla, manuaalinen testaus on kuitenkin tarpeen, koska se on ohjelmistotestauksen perusta.