Manuell testing er en programvaretestprosess der testtilfeller utføres manuelt uten å bruke noe automatisert verktøy. Alle testtilfeller utført av testeren manuelt i henhold til sluttbrukerens perspektiv. Den sikrer om applikasjonen fungerer, som nevnt i kravdokumentet eller ikke. Testtilfeller planlegges og implementeres for å fullføre nesten 100 prosent av programvareapplikasjonen. Testtilfellerapporter genereres også manuelt.

Manuell testing er en av de mest grunnleggende testprosessene siden den kan finne både synlige og skjulte defekter i programvaren. Forskjellen mellom forventet utgang og utgang, gitt av programvaren, er definert som en defekt. Utvikleren fikset feilene og leverte den til testeren for ny testing.

Manuell testing er obligatorisk for hver nyutviklet programvare før automatisert testing. Denne testingen krever stor innsats og tid, men den gir garanti for feilfri programvare. Manuell testing krever kunnskap om manuelle testteknikker, men ikke om noe automatisert testverktøy.

Manuell testing er viktig fordi en av de programvaretesting grunnleggende er '100 % automatisering er ikke mulig.'

Hvorfor trenger vi manuell testing

Når en applikasjon kommer på markedet, og den er ustabil eller har en feil eller problemer eller skaper et problem mens sluttbrukere bruker den.

Hvis vi ikke vil møte denne typen problemer, må vi utføre en runde med testing for å gjøre applikasjonen feilfri og stabil og levere et kvalitetsprodukt til klienten, for hvis applikasjonen er feilfri, vil sluttbrukeren vil bruke applikasjonen mer praktisk.

Hvis testingeniøren utfører manuell testing, kan han/hun teste applikasjonen som et sluttbrukerperspektiv og bli mer kjent med produktet, noe som hjelper dem til å skrive de riktige testsakene av applikasjonen og gi applikasjonen rask tilbakemelding.

Typer manuell testing

Det finnes ulike metoder for manuell testing. Hver teknikk brukes i henhold til testkriteriene. Typer manuell testing er gitt nedenfor:

• White Box Testing
• Black Box-testing
• Testing av grå boks

White-box testing

Testingen av den hvite boksen utføres av utvikleren, hvor de sjekker hver linje i en kode før de gir den til testingeniøren. Siden koden er synlig for utvikleren under testingen, er det derfor den også er kjent som White box-testing.

For mer informasjon om testing av hvite bokser, referer til lenken nedenfor:

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

Black box testing

Black box-testingen gjøres av testingeniøren, hvor de kan sjekke funksjonaliteten til en applikasjon eller programvaren i henhold til kundens/klientens behov. I denne er koden ikke synlig mens testingen utføres; det er derfor det er kjent som black-box-testing.

For mer informasjon om black-box-testing, se lenken nedenfor:

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

Gray Box testing

Testing av grå boks er en kombinasjon av testing av hvit boks og svart boks. Det kan utføres av en person som kunne både koding og testing. Og hvis den enslige personen utfører hvit boks, så vel som svart-boks-testing for applikasjonen, er kjent som grå boks-testing.

For å få mer informasjon om testing av grå boks, referer til lenken nedenfor:

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

Hvordan utføre manuell testing

• Først observerer testeren alle dokumenter relatert til programvare for å velge testområder.
• Tester analyserer kravdokumenter for å dekke alle krav oppgitt av kunden.
• Tester utvikler testcasene i henhold til kravdokumentet.
• Alle testtilfeller utføres manuelt ved å bruke Black box-testing og white box-testing.
• Hvis det oppstod feil, informerer testteamet utviklingsteamet.
• Utviklingsteamet fikser feil og leverte programvare til testteamet for en ny test.

Programvarebyggingsprosess

• Når kravet er samlet, vil det gis til de to forskjellige teamutviklings- og testteamene.
• Etter å ha fått kravet, vil den aktuelle utvikleren begynne å skrive koden.
• Og i mellomtiden forstår testingeniøren kravet og forbereder de nødvendige dokumentene, til nå kan utvikleren fullføre koden og lagre i Verktøy for kontrollversjon .
• Etter det endres koden i brukergrensesnittet, og disse endringene håndteres av ett separat team, som er kjent som bygge team .
• Dette byggeteamet vil ta koden og begynne å kompilere og komprimere koden ved hjelp av et byggeverktøy. Når vi har fått litt utdata, går utdataene i zip-filen, som er kjent som Bygge (applikasjon eller programvare). Hver bygning vil ha et unikt nummer som (B001, B002).
• Deretter vil denne bygningen bli installert i testserveren. Etter det vil testingeniøren få tilgang til denne testserveren ved hjelp av Test URL og begynne å teste applikasjonen.
• Hvis testingeniøren fant en feil, vil han/hun bli rapportert til den aktuelle utvikleren.
• Deretter vil utvikleren reprodusere feilen i testserveren og fikse feilen og igjen lagre koden i kontrollversjonsverktøyet, og den vil installere den nye oppdaterte filen og fjerne den gamle filen; denne prosessen fortsetter til vi får den stabile Build.
• Når vi har fått stallen Bygg, vil den bli overlevert til kunden.

Merknad 1

• Når vi har samlet inn filen fra kontrollversjonsverktøyet, vil vi bruke byggeverktøyet til å kompilere koden fra språk på høyt nivå til språk på maskinnivå. Etter kompilering, hvis filstørrelsen vil øke, så vil vi komprimere den aktuelle filen og dumpet inn i testserveren.
• Denne prosessen gjøres av Bygg team , utvikler (hvis byggeteamet ikke er der, kan en utvikler gjøre det) eller prøveledning (hvis byggeteamet håndterer zip-en direkte og installerer applikasjonen på testserveren og informer testingeniøren).
• Generelt kan vi ikke få et nytt bygg for hver feil; ellers vil mesteparten av tiden bare gå bort på å lage byggene.

Notat 2

Bygg team

Hovedoppgaven til byggeteamet er å lage applikasjonen eller Bygg og konvertere høynivåspråket til lavnivåspråk.

Bygge

Det er programvare som brukes til å konvertere koden til applikasjonsformat. Og den består av et sett med funksjoner og feilrettinger som overleveres til testingeniøren for testformål til den blir stabil.

Kontrollversjonsverktøy

Det er en programvare eller applikasjon som brukes til følgende formål:

• I dette verktøyet kan vi lagre forskjellige typer filer.
• Den er alltid sikret fordi vi får tilgang til filen fra verktøyene med samme påloggingsinformasjon.
• Hovedmålet med verktøyene er å spore endringene som er gjort for de eksisterende filene.

Eksempel på byggeprosess

La oss se ett eksempel for å forstå hvordan du bygger prosessarbeid på de virkelige scenariene:

Så snart testingeniøren får feilen, vil de sende den til utviklerne, og de trenger litt tid til å analysere; etter det fikser han/hun bare feilen (testingeniøren kan ikke gi samlingen av feilen).

Utvikleren bestemmer hvor mange feil han kan fikse i henhold til deres tid. Og testingeniøren bestemmer seg, hvilken feil som skal fikses først i henhold til deres behov fordi testingeniørene ikke har råd til å slutte å teste.

Og testingeniøren får e-posten, de kan bare vite hvilken feil som er fikset av liste over feilrettinger .

Tiden vil øke fordi ved den første Build, og utviklere bør skrive koden i de forskjellige funksjonene. Og på slutten kan han/hun bare gjøre feilrettingene, og antall dager vil bli redusert.

Merknad 3

Testsyklus

Testsyklusen er tiden som testingeniøren får for å teste hver bygning.

Forskjeller mellom de to byggene

Feilene som finnes i én konstruksjon og kan fikses på hvilken som helst fremtidig Build, som avhenger av testingeniørens krav. Hvert nye bygg er den modifiserte versjonen av den gamle, og disse endringene kan være feilrettinger eller å legge til noen nye funksjoner.

Hvor ofte vi fikk det nye bygget

I begynnelsen pleide vi å få ukentlige bygg, men i det siste teststadiet, da applikasjonen ble stabil, pleide vi å få den nye versjonen en gang i 3 dager, to dager eller daglig også.

Hvor mange bygg får vi

Hvis vi vurderer ett år av en hvilken som helst prosjektvarighet, fikk vi 22-26 bygg.

Når vi får feilrettingene

Vanligvis forstår vi feilrettingene først etter at testsyklusen er fullført, eller samlingen av feil er fikset i en build, og overlevering i de neste buildene.

Fordeler med manuell testing

• Det krever ikke programmeringskunnskap mens du bruker Black box-metoden.
• Den brukes til å teste dynamisk skiftende GUI-design.
• Tester samhandler med programvare som en reell bruker, slik at de er i stand til å oppdage problemer med brukervennlighet og brukergrensesnitt.
• Det sikrer at programvaren er hundre prosent feilfri.
• Det er kostnadseffektivt.
• Lett å lære for nye testere.

Ulemper med manuell testing

• Det krever et stort antall menneskelige ressurser.
• Det er veldig tidkrevende.
• Tester utvikler testcases basert på deres ferdigheter og erfaring. Det er ingen bevis for at de har dekket alle funksjoner eller ikke.
• Testtilfeller kan ikke brukes igjen. Trenger å utvikle separate testcases for hver ny programvare.
• Den gir ikke testing på alle aspekter ved testing.
• Siden to team jobber sammen, noen ganger er det vanskelig å forstå hverandres motiver, det kan villede prosessen.

Manuelle testverktøy

I manuell testing, ulike typer testing som enhet, integrasjon, sikkerhet, ytelse og feilsporing, har vi ulike verktøy som Jira , Bugzilla , Mantis, Zap, NUnit, Tessy, LoadRunner, Citrus, SonarQube, etc. tilgjengelig i marked. Noen av verktøyene er åpen kildekode, og noen er kommersielle.

For mer informasjon om testverktøy, se lenken nedenfor:

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

La oss forstå dem en etter en:

LoadRunner

Det er mest brukte verktøy for ytelsestesting. LoadRunner brukes hovedsakelig til å støtte ytelsestesting for det brede spekteret av prosedyrer, antall tilnærminger og applikasjonsmiljøer.

Hovedformålet med å kjøre LoadRunner-verktøyet er å klassifisere de vanligste kildene til ytelsesproblemer raskt.

Funksjoner i LoadRunner

• LoadRunner-verktøyet inneholder n-tall applikasjoner, noe som reduserer tiden til å forstå og beskrive rapportene.
• Vi kan få grundige ytelsestestrapporter ved å bruke LoadRunner-verktøyet.
• Det vil redusere kostnadene for distribuert lasttesting og også tilby det operasjonelle verktøyet for distribusjonssporing.

Sitrus

Citrus er et integrasjonstestverktøy, som er det mest brukte testrammeverket. Det er skrevet i Java programmering Språk. Det brukes mest til å be om og svare på server- og klientsiden og validere XML JSON-filene.

For å oppnå ende-til-ende brukstesting, støtter sitrus flere HTTP-, JMS- og SOAP-protokoller.

Egenskaper til sitrus

Følgende er noen av de viktige funksjonene til sitrusverktøyet:

• Den brukes til å sende og motta meldinger.
• Sitrus er tilgjengelig som både åpen kildekode og lisensiert i markedet.
• Det gir en rimelig løsning.
• Vi kan autentisere databasen ved å bruke sitrusverktøyet.
• Den vil beskrive sekvensen av meldinger, tilby testplanen og dokumentere testdekningen.
• Den lager meldingen og bekrefter svarene.

ZAP

ZAP er en åpen kildekode-sikkerhetsskanner for nettapplikasjoner. Det står for Zed Attack Proxy . Akkurat som noen andre verktøy, er det også skrevet i JAVA programmeringsspråk . Det er det mest effektive Åpne Web Application Security Projects [OWASP].

Funksjoner av ZAP

• Den støtter mange operativsystemer som Windows, Linux, OS X.
• Den har en plugin-basert arkitektur.
• Den inneholder en online markedsplass som lar oss legge til nye eller oppdaterte funksjoner.
• ZAPs GUI-kontrollpanel er enkelt å bruke.

Nonne

NUnit er et av de mest brukte enhetstestingsverktøyene. Det er et åpen kildekode-verktøy og primært avledet fra JUnit .

Det var fullstendig skrevet i C# programmeringsspråk og passer for alle .Net-språk .

Med andre ord kan vi si at NUnit-verktøyet er fullstendig redesignet for å bli fordelen med mange .Net-språkkvaliteter. For eksempel:

Refleksjonsrelaterte evner. Andre egendefinerte attributter.

Kjennetegn ved NUnit

• Det tillater påstandene som en statisk metode for fordelsklassen.
• Den opprettholder de datadrevne testene.
• Den støtter flere plattformer, som .NET core Xamarin mobil, Silverlight og effektivt rammeverk.
• Evnen til NUnit hjelper oss å utføre testene samtidig.
• Den bruker en konsollløper for å laste og utføre testene.

JIRA

Det mest brukte feilsporingsverktøyet er JIRA , som er et åpen kildekodeverktøy. Den brukes til feilsporing, prosjektstyring og problemsporing.

I dette verktøyet kan vi enkelt spore alle slags feil eller defekter relatert til programvaren og produsert av testingeniørene.

Funksjoner av JIRA

• Det er et tidsbesparende verktøy.
• Jira brukes til å spore defektene og problemene.
• Den brukes til å etablere dokumentasjonsoppgavene.
• Jira er et veldig nyttig verktøy for å spore forbedringen av dokumentasjonen vår.

For å få fullstendig informasjon om Jira-verktøyet, se lenken nedenfor: https://www.javatpoint.com/jira-tutorial.

SonarQube

Et annet testverktøy for manuell testing er SonarQube, som forbedrer arbeidsflyten vår med kontinuerlig kodekvalitet og kodesikkerhet. Det er fleksibelt med bruk av plug-ins.

Den er fullstendig skrevet i programmeringsspråket JAVA. Den tilbyr helautomatisert evaluering og integrasjon med Ant, Maven, Gradle, MSBuild og konstante integreringsverktøy. SonarQube har muligheten til å registrere en metrikkhistorie og gir evolusjonsgrafen.

Funksjoner av Sonarqube

Nedenfor er noen av de viktigste funksjonene til SonarQube-verktøyet:

• Den støtter flere programmeringsspråk som C, C++, Python, JAVA, HTML, CSS, VB.NET, PHP, COBOL, PL/SQL, etc.
• Under GNU Lesser General Public License er Sonarqube fritt tilgjengelig.
• SonarQube er tilknyttet noen viktige eksterne verktøy som GitHub, Active Directory, LDAP og andre.
• SonarQube fusjonerte med utviklingsmiljøene Visual Studio, Eclipse og IntelliJ IDEA på grunn av SonarLint plug-ins.

JMeter

JMeter er et åpen kildekodeverktøy som brukes til å teste ytelsen til både statiske og dynamiske ressurser og dynamiske webapplikasjoner.

Den er fullstendig designet på JAVA-applikasjonen for å laste den funksjonelle testatferden og måle applikasjonens ytelse.

Det gjør det lettere for brukere eller utviklere å bruke kildekoden for utvikling av andre applikasjoner.

Funksjoner av JMeter

Nedenfor er noen av de viktigste egenskapene til JMeter:

• Den er plattformuavhengig, som godtar en JVM-liknende Windows, Mac og Linux, etc.
• Den støtter et brukervennlig GUI, som er interaktivt og enkelt.
• Det er utrolig utvidbart å laste ytelsestesten i flere typer servere.

For mer informasjon om JMeter, referer til lenken nedenfor:

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

Med Bugz

Et annet feilsporingsverktøy som brukes i manuell testing er Med Bugz .

Det er mest brukt av mange organisasjoner for å spore de forskjellige feilene i applikasjonen.

Bugzilla er et åpen kildekodeverktøy som hjelper kunden og klienten med å holde styr på defektene. Bugzilla regnes også som et teststyringsverktøy fordi vi i dette enkelt kan koble sammen andre testcasestyringsverktøy som ALM, Quality Centre, etc.

Funksjoner av Bugzilla

Bugzilla har noen tilleggsfunksjoner som hjelper oss å rapportere feilen enkelt:

• Den støtter ulike operativsystemer som Windows, Linux og Mac.
• Ved hjelp av Bugzilla kan vi liste en feil i flere formater.
• Brukerpreferanser kan måle e-postvarsling.
• Bugzilla har avanserte søkefunksjoner.

Mantis

Mantis er et nettbasert feilsporingssystem. ManitsBT står for Mantis Bug Tracker . Den brukes til å følge programvarefeilene og utføres i PHP-programmeringsspråket. Det er også et åpen kildekodeverktøy.

åpne en fil med java

Funksjoner av Mantis

Noen av standardfunksjonene til det aktuelle verktøyet er som følger:

• Ved hjelp av dette verktøyet har vi fulltekstsøketilgjengelighet.
• Revisjonsspor for endringer som er gjort i problemer.
• Det gir integrasjon av revisjonskontrollsystemet.
• Revisjonskontroll av tekstfelt og notater

For å få mer informasjon om feilsporingsverktøy, se følgende lenke: https://www.javatpoint.com/defect-or-bug-tracking-tool .

Tessy

Et annet integrasjonstestverktøy er Tessy , som brukes til å utføre integrasjonen og enhetstesten for den innebygde programvaren. Det hjelper oss også å oppdage kodedekningen til programvaren eller en applikasjon.

Den kan enkelt administrere hele testorganisasjonen, inkludert forretningsbehov, testadministrasjon, dekningsmengde og sporbarhet.

Tessy inneholder tre primære funksjoner, som er som følger:

• Test Interface Editor (TIE)
• Test Data Editor (TDE)
• Arbeidsområde.

Egenskaper til TESSY

Standardfunksjonene til TESSY er som følger:

• Den produserer testrapporten for testutførelsesresultatene.
• Den støtter ulike programmeringsspråk som C og C++.
• Tessy brukes til å evaluere grensesnittet til funksjonen og beskriver variabelen som brukes av denne funksjonen.

For mer informasjon om integrasjonstestverktøy, referer til følgende lenke: https://www.javatpoint.com/integration-testing-tools .

Oversikt

I denne artikkelen har vi sett detaljert informasjon om Manuell testing, som inkluderer definisjonen av manuell testing, behovet for manuell testing, type manuell testing, manuelle testverktøy, prosessen med manuell testing, og noen viktige fordeler og ulemper med det.

Til slutt kan vi si at det er en prosess der testingeniøren må være veldig utholdende, innovativ og lydhør.

Ved manuell testing må testingeniøren tenke og utføre som sluttbrukertolkning.

For å implementere manuell testing trenger en testingeniør produktiv ferdighet og fantasi. Og de må tenke på flere situasjoner eller scenarier for å teste en spesifikk applikasjon.

Selv om vi for tiden kan teste nesten alle applikasjoner ved hjelp av automatiseringstesting, er det fortsatt nødvendig med manuell testing ettersom det er grunnlaget for programvaretesting.