Manuel test er en softwaretestproces, hvor testcases udføres manuelt uden brug af noget automatiseret værktøj. Alle testcases udføres af testeren manuelt i henhold til slutbrugerens perspektiv. Det sikrer, om applikationen virker, som nævnt i kravdokumentet eller ej. Testcases er planlagt og implementeret til at fuldføre næsten 100 procent af softwareapplikationen. Testcaserapporter genereres også manuelt.

Manuel test er en af ​​de mest fundamentale testprocesser, da den kan finde både synlige og skjulte fejl i softwaren. Forskellen mellem forventet output og output, givet af softwaren, er defineret som en defekt. Udvikleren rettede fejlene og afleverede den til testeren til gentestning.

Manuel test er obligatorisk for hver nyudviklet software før automatiseret test. Denne test kræver stor indsats og tid, men den giver sikkerhed for fejlfri software. Manuel test kræver kendskab til manuelle testteknikker, men ikke til noget automatiseret testværktøj.

Manuel test er afgørende, fordi en af ​​de software test grundlæggende er '100 % automatisering er ikke mulig.'

Hvorfor har vi brug for manuel test

Når en applikation kommer på markedet, og den er ustabil eller har en fejl eller problemer eller skaber et problem, mens slutbrugere bruger den.

Hvis vi ikke ønsker at stå over for den slags problemer, skal vi udføre en testrunde for at gøre applikationen fejlfri og stabil og levere et kvalitetsprodukt til klienten, for hvis applikationen er fejlfri, er slutbrugeren vil bruge applikationen mere bekvemt.

Hvis testingeniøren laver manuel test, kan han/hun teste applikationen som et slutbrugerperspektiv og blive mere fortrolig med produktet, hvilket hjælper dem med at skrive de korrekte testcases af applikationen og give hurtig feedback på applikationen.

Typer af manuel test

Der er forskellige metoder, der bruges til manuel test. Hver teknik bruges i henhold til dens testkriterier. Typer af manuel test er angivet nedenfor:

• White Box Test
• Black Box test
• Test af grå boks

White-box test

Den hvide boks-test udføres af udvikleren, hvor de tjekker hver linje i en kode, før de giver den til testingeniøren. Da koden er synlig for udvikleren under testen, er den derfor også kendt som White box-test.

For mere information om white box-test, henvises til nedenstående link:

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

Black box test

Black box-testen udføres af testingeniøren, hvor de kan tjekke funktionaliteten af ​​en applikation eller softwaren i henhold til kundens/klientens behov. I denne er koden ikke synlig, mens testen udføres; det er derfor, det er kendt som black-box test.

For mere information om black-box-test henvises til nedenstående link:

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

Gray Box test

Grå boks test er en kombination af hvid boks og sort boks test. Det kan udføres af en person, der kunne både kodning og test. Og hvis den enlige person udfører white box, samt black-box test for applikationen, er kendt som Gray box test.

For at få flere detaljer om test af grå boks, referer til nedenstående link:

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

Sådan udføres manuel test

• Først observerer testeren alle dokumenter relateret til software for at vælge testområder.
• Tester analyserer kravdokumenter for at dække alle krav angivet af kunden.
• Tester udvikler testcaserne i henhold til kravdokumentet.
• Alle testcases udføres manuelt ved at bruge Black box test og white box test.
• Hvis der opstod fejl, informerer testteamet udviklingsteamet.
• Udviklingsteamet retter fejl og afleverede software til testteamet for en gentest.

Software byggeproces

• Når kravet er indsamlet, vil det levere til de to forskellige teamudviklings- og testhold.
• Efter at have modtaget kravet, vil den pågældende udvikler begynde at skrive koden.
• Og i mellemtiden forstår testingeniøren kravet og forbereder de nødvendige dokumenter, indtil nu kan udvikleren færdiggøre koden og gemme i Værktøj til kontrolversion .
• Derefter ændres koden i brugergrænsefladen, og disse ændringer håndteres af et separat team, som er kendt som bygge team .
• Dette byggeteam tager koden og begynder at kompilere og komprimere koden ved hjælp af et byggeværktøj. Når vi har fået noget output, går outputtet i zip-filen, som er kendt som Byg (applikation eller software). Hver Build vil have et unikt nummer som (B001, B002).
• Derefter vil denne særlige Build blive installeret på testserveren. Derefter vil testingeniøren få adgang til denne testserver ved hjælp af test-URL'en og begynde at teste applikationen.
• Hvis testingeniøren fandt en fejl, vil han/hun blive rapporteret til den pågældende udvikler.
• Så vil udvikleren reproducere fejlen på testserveren og rette fejlen og igen gemme koden i kontrolversionsværktøjet, og den vil installere den nye opdaterede fil og fjerne den gamle fil; denne proces fortsættes, indtil vi får den stabile Build.
• Når vi har fået stalden Build, vil den blive overdraget til kunden.

Bemærk 1

• Når vi har indsamlet filen fra kontrolversionsværktøjet, vil vi bruge byggeværktøjet til at kompilere koden fra sprog på højt niveau til sprog på maskinniveau. Efter kompilering, hvis filstørrelsen vil stige, så vil vi komprimere den pågældende fil og dumpe ind i testserveren.
• Denne proces udføres af Byg team , Udvikler (hvis byggeteamet ikke er der, kan en udvikler gøre det) eller prøveledning (hvis build-teamet direkte håndterer zip'en og installerer applikationen på testserveren og informerer testingeniøren).
• Generelt kan vi ikke få en ny Build for hver fejl; ellers vil det meste af tiden kun blive spildt på at skabe builds.

Bemærk 2

Byg team

Byggeteamets hovedopgave er at oprette applikationen eller Byg og konvertere sproget på højt niveau til sprog på lavt niveau.

Byg

Det er software, som bruges til at konvertere koden til applikationsformat. Og den består af nogle sæt funktioner og fejlrettelser, der overdrages til testingeniøren til testformål, indtil den bliver stabil.

Kontrolversionsværktøj

Det er en software eller applikation, som bruges til følgende formål:

• I dette værktøj kan vi gemme forskellige typer filer.
• Det er altid sikret, fordi vi får adgang til filen fra værktøjerne med de samme loginoplysninger.
• Det primære formål med værktøjerne er at spore ændringerne for de eksisterende filer.

Eksempel på byggeproces

Lad os se et eksempel for at forstå, hvordan man bygger procesarbejde på de virkelige scenarier:

Så snart testingeniøren får fejlen, sender de den til udviklerne, og de har brug for lidt tid til at analysere; derefter retter han/hun kun fejlen (Testingeniør kan ikke give indsamlingen af ​​fejl).

Udvikleren bestemmer, hvor mange fejl han kan rette i henhold til deres tid. Og testingeniøren bestemmer, hvilken fejl der skal rettes først efter deres behov, fordi testingeniørerne ikke har råd til at stoppe med at teste.

Og testingeniøren får mailen, de kan kun vide, hvilken fejl der er rettet af liste over fejlrettelser .

Tiden vil stige, fordi ved den første Build, og udviklere bør skrive koden i de forskellige funktioner. Og i sidste ende kan han/hun kun lave fejlrettelserne, og antallet af dage vil blive reduceret.

Bemærk 3

Test cyklus

Testcyklussen er den tid, som testingeniøren får til at teste hver bygning.

Forskelle mellem de to opbygning

De fejl, der findes i én build og kan rettes i enhver fremtidig Build, hvilket afhænger af testingeniørens krav. Hver ny Build er den modificerede version af den gamle, og disse ændringer kan være fejlrettelser eller tilføjelse af nogle nye funktioner.

Hvor ofte fik vi den nye bygning

I begyndelsen plejede vi at få ugentlige builds, men i den seneste testfase, da applikationen var ved at blive stabil, plejede vi at få den nye Build en gang om 3 dage, to dage eller også på daglig basis.

Hvor mange builds får vi

Hvis vi overvejer et år af enhver projektvarighed, fik vi 22-26 builds.

Når vi får fejlrettelserne

Generelt forstår vi først fejlrettelserne efter testcyklussen er afsluttet, eller indsamlingen af ​​fejl er rettet i én build og overdragelse i de næste builds.

Fordele ved manuel test

• Det kræver ikke programmeringsviden, mens du bruger Black box-metoden.
• Det bruges til at teste dynamisk skiftende GUI-design.
• Tester interagerer med software som en rigtig bruger, så de er i stand til at opdage problemer med brugervenlighed og brugergrænseflade.
• Det sikrer, at softwaren er hundrede procent fejlfri.
• Det er omkostningseffektivt.
• Let at lære for nye testere.

Ulemper ved manuel test

• Det kræver et stort antal menneskelige ressourcer.
• Det er meget tidskrævende.
• Tester udvikler testcases baseret på deres færdigheder og erfaring. Der er ingen beviser for, at de har dækket alle funktioner eller ej.
• Testcases kan ikke bruges igen. Behov for at udvikle separate testcases for hver ny software.
• Det giver ikke test af alle aspekter af test.
• Da to teams arbejder sammen, er det nogle gange svært at forstå hinandens motiver, det kan vildlede processen.

Manuelle testværktøjer

I manuel test, forskellige typer af test som enhed, integration, sikkerhed, ydeevne og fejlsporing, har vi forskellige værktøjer såsom Jira , Bugzilla , Mantis, Zap, NUnit, Tessy, LoadRunner, Citrus, SonarQube osv. tilgængelige i marked. Nogle af værktøjerne er open source, og nogle er kommercielle.

For mere information om testværktøjer henvises til nedenstående link:

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

Lad os forstå dem én efter én:

LoadRunner

Det er mest almindeligt anvendte præstationstestværktøjer. LoadRunner bruges hovedsageligt til at understøtte ydeevnetestning for en bred vifte af procedurer, antal tilgange og applikationsmiljøer.

Hovedformålet med at udføre LoadRunner-værktøjet er at klassificere de mest almindelige kilder til ydeevneproblemer hurtigt.

Funktioner i LoadRunner

• LoadRunner-værktøjet indeholder n-tal af applikationer, hvilket reducerer tiden til at forstå og beskrive rapporterne.
• Vi kan få grundige præstationstestrapporter ved at bruge LoadRunner-værktøjet.
• Det vil reducere omkostningerne ved distribueret belastningstest og også tilbyde det operationelle værktøj til implementeringssporing.

Citrus

Citrus er et integrationstestværktøj, som er den mest brugte testramme. Det er skrevet i Java programmering Sprog. Det bruges mest til at anmode om og svare på server- og klientsiden og validere XML JSON-filerne.

For at udføre end-to-end use case-testen understøtter citrus adskillige HTTP-, JMS- og SOAP-protokoller.

Karakteristika for Citrus

Følgende er nogle af de vigtige funktioner i Citrus-værktøjet:

• Det bruges til at sende og modtage beskeder.
• Citrus er tilgængelig som både en open source og en licenseret på markedet.
• Det giver en billig løsning.
• Vi kan autentificere databasen ved at bruge citrusværktøjet.
• Den vil beskrive rækkefølgen af ​​meddelelser, tilbyde testplanen og dokumentere testdækningen.
• Det opretter beskeden og verificerer svarene.

ZAP

ZAP er en open source webapplikationssikkerhedsscanner. Det står for Zed Attack Proxy . Ligesom nogle andre værktøjer er det også skrevet i JAVA programmeringssprog . Det er det mest effektive Åbn Web Application Security Projects [OWASP].

Funktioner i ZAP

• Det understøtter mange operativsystemer såsom Windows, Linux, OS X.
• Det har en plugin-baseret arkitektur.
• Den indeholder en online markedsplads, der giver os mulighed for at tilføje nye eller opdaterede funktioner.
• ZAP's GUI kontrolpanel er let at bruge.

Nonne

NUnit er et af de mest brugte enhedstestværktøjer. Det er et open source-værktøj og primært afledt af JUnit .

Det var fuldstændig skrevet i C# programmeringssprog og velegnet til alle .Net sprog .

Med andre ord kan vi sige, at NUnit-værktøjet er fuldstændigt redesignet til at blive fordelen ved mange .Net-sprogkvaliteter. For eksempel:

Refleksionsrelaterede evner. Andre tilpassede attributter.

Karakteristika for NUnit

• Det tillader påstandene som en statisk metode for fordelsklassen.
• Det opretholder de datadrevne tests.
• Det understøtter flere platforme, såsom .NET kerne Xamarin mobil, Silverlight og effektive rammer.
• NUnits evne hjælper os med at udføre testene samtidigt.
• Den bruger en konsolløber til at indlæse og udføre testene.

JIRA

Det mest almindeligt brugte fejlsporingsværktøj er JIRA , som er et open source-værktøj. Det bruges til fejlsporing, projektstyring og problemsporing.

I dette værktøj kan vi nemt spore alle slags fejl eller defekter relateret til softwaren og produceret af testingeniørerne.

Funktioner af JIRA

• Det er et tidsbesparende værktøj.
• Jira bruges til at spore defekter og problemer.
• Det bruges til at etablere dokumentationsopgaverne.
• Jira er et meget nyttigt værktøj til at spore forbedringen af ​​vores dokumentation.

For at få den komplette information om Jira-værktøjet, se nedenstående link: https://www.javatpoint.com/jira-tutorial.

SonarQube

Et andet testværktøj til manuel test er SonarQube, som forbedrer vores arbejdsgang med kontinuerlig kodekvalitet og kodesikkerhed. Det er fleksibelt med brug af plug-ins.

Det er fuldstændig skrevet i programmeringssproget JAVA. Det tilbyder fuldautomatisk evaluering og integration med Ant, Maven, Gradle, MSBuild og konstant integrationsværktøjer. SonarQube har evnen til at registrere en metrisk historie og giver udviklingsgrafen.

Funktioner af Sonarqube

Nedenfor er nogle af de væsentlige funktioner i SonarQube-værktøjet:

• Det understøtter flere programmeringssprog som C, C++, Python, JAVA, HTML, CSS, VB.NET, PHP, COBOL, PL/SQL osv.
• Under GNU Lesser General Public License er Sonarqube frit tilgængelig.
• SonarQube er tilknyttet nogle vigtige eksterne værktøjer som GitHub, Active Directory, LDAP og andre.
• SonarQube fusionerede med Visual Studio, Eclipse og IntelliJ IDEA udviklingsmiljøer på grund af SonarLint plug-ins.

JMeter

JMeter er et open source-værktøj, der bruges til at teste ydeevnen af ​​både statiske og dynamiske ressourcer og dynamiske webapplikationer.

Den er fuldstændig designet på JAVA-applikationen til at indlæse den funktionelle testadfærd og måle applikationens ydeevne.

Det letter brugere eller udviklere at bruge kildekoden til udvikling af andre applikationer.

Funktioner af JMeter

Nedenfor er nogle af de væsentlige egenskaber ved JMeter:

• Det er platformsuafhængigt, hvilket accepterer en JVM-lignende Windows, Mac og Linux osv.
• Den understøtter en brugervenlig GUI, som er interaktiv og ligetil.
• Det er utroligt udvideligt at indlæse ydeevnetesten i flere typer servere.

For mere information om JMeter, henvises til nedenstående link:

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

Med Bugz

Et andet fejlsporingsværktøj, der bruges til manuel test, er Med Bugz .

Det er mest udbredt af mange organisationer til at spore de forskellige fejl i applikationen.

Bugzilla er et open source-værktøj, der hjælper kunden og klienten med at holde styr på fejlene. Bugzilla betragtes også som et teststyringsværktøj, fordi vi i dette nemt kan sammenkæde andre testcasestyringsværktøjer såsom ALM, Kvalitetscenter osv.

Funktioner af Bugzilla

Bugzilla har nogle ekstra funktioner, som hjælper os med at rapportere fejlen nemt:

• Det understøtter forskellige operativsystemer såsom Windows, Linux og Mac.
• Ved hjælp af Bugzilla kan vi liste en fejl i flere formater.
• Brugerpræferencer kan måle e-mailmeddelelser.
• Bugzilla har avancerede søgefunktioner.

Mantis

Mantis er et webbaseret fejlsporingssystem. ManitsBT står for Mantis Bug Tracker . Det bruges til at følge softwarefejlene og udføres i PHP programmeringssproget. Det er også et open source-værktøj.

apurva padgaonkar

Funktioner af Mantis

Nogle af standardfunktionerne i det pågældende værktøj er som følger:

• Ved hjælp af dette værktøj har vi fuld-tekstsøgning tilgængelighed.
• Revisionsspor for ændringer foretaget i problemer.
• Det giver integration af revisionskontrolsystemet.
• Revisionskontrol af tekstfelter og noter

For at få flere detaljer om fejlsporingsværktøjer, se følgende link: https://www.javatpoint.com/defect-or-bug-tracking-tool .

Tessy

Et andet integrationstestværktøj er Tessy , som bruges til at udføre integrationen og enhedstesten for den indlejrede software. Det hjælper os også med at opdage kodedækningen af ​​softwaren eller en applikation.

Det kan nemt styre hele testorganisationen, inklusive forretningsbehov, teststyring, dækningsmængde og sporbarhed.

Tessy indeholder tre primære funktioner, som er som følger:

• Test Interface Editor (TIE)
• Test Data Editor (TDE)
• Arbejdsplads.

Funktioner af TESSY

Standardfunktionerne i TESSY er som følger:

• Den producerer testrapporten for testudførelsesresultaterne.
• Det understøtter forskellige programmeringssprog såsom C og C++.
• Tessy bruges til at evaluere grænsefladen af ​​funktionen og beskriver den variabel, der bruges af denne funktion.

For mere information om integrationstestværktøjer henvises til følgende link: https://www.javatpoint.com/integration-testing-tools .

Oversigt

I denne artikel har vi set detaljerede oplysninger om Manuel test, som inkluderer definitionen af ​​manuel test, behovet for manuel test, type manuel test, manuelle testværktøjer, processen med manuel test og nogle vigtige fordele og ulemper ved det.

Endelig kan vi sige, at det er en proces, hvor testingeniøren skal være meget vedholdende, innovativ og lydhør.

Ved manuel test skal testingeniøren tænke og udføre som slutbrugerfortolkning.

For at implementere manuel testning har en testingeniør brug for produktiv færdighed og fantasi. Og de skal tænke på flere situationer eller scenarier for at teste en specifik applikation.

Selvom vi på nuværende tidspunkt kan teste næsten alle applikationer ved hjælp af automatiseringstest, er manuel test stadig nødvendig, da det er grundlaget for softwaretest.