MANUELL TESTNING - MJUKVARUTESTNING

Manuell testning är en mjukvarutestprocess där testfall utförs manuellt utan att använda något automatiserat verktyg. Alla testfall utförs av testaren manuellt enligt slutanvändarens perspektiv. Den säkerställer om applikationen fungerar, som nämnts i kravdokumentet eller inte. Testfall planeras och implementeras för att slutföra nästan 100 procent av programvaran. Testfallsrapporter genereras också manuellt.

Manuell testning är en av de mest grundläggande testprocesserna eftersom den kan hitta både synliga och dolda defekter i programvaran. Skillnaden mellan förväntad uteffekt och utdata, som ges av programvaran, definieras som en defekt. Utvecklaren fixade defekterna och lämnade den till testaren för omtestning.

Manuell testning är obligatorisk för varje nyutvecklad programvara innan automatiserad testning. Denna testning kräver stora ansträngningar och tid, men det ger garanti för buggfri programvara. Manuell testning kräver kunskap om manuella testtekniker men inte om något automatiserat testverktyg.

Manuell testning är viktig eftersom en av de mjukvarutestning Grunderna är '100 % automatisering är inte möjlig.'

Varför vi behöver manuell testning

Närhelst en applikation kommer ut på marknaden och den är instabil eller har en bugg eller problem eller skapar ett problem medan slutanvändare använder den.

Om vi inte vill möta den här typen av problem måste vi utföra en testrunda för att göra applikationen buggfri och stabil och leverera en kvalitetsprodukt till klienten, för om applikationen är buggfri kan slutanvändaren kommer att använda applikationen mer bekvämt.

Om testingenjören gör manuella tester kan han/hon testa applikationen som ett slutanvändarperspektiv och bli mer bekant med produkten, vilket hjälper dem att skriva de korrekta testfallen för applikationen och ge snabb feedback på applikationen.

Typer av manuell testning

Det finns olika metoder som används för manuell testning. Varje teknik används enligt dess testkriterier. Typer av manuell testning anges nedan:

White Box Testning
Black Box-testning
Testning av grå box

White-box-testning

Testningen av den vita lådan görs av utvecklaren, där de kontrollerar varje rad i en kod innan de ger den till testingenjören. Eftersom koden är synlig för utvecklaren under testningen, är det därför den också kallas White box-testning.

För mer information om white box-testning, se länken nedan:

skillnad på tiger och lejon

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

Black box testning

Black box-testningen görs av Testingenjören, där de kan kontrollera funktionaliteten hos en applikation eller mjukvaran enligt kundens/klientens behov. I detta är koden inte synlig när testet utförs; det är därför det är känt som black-box-testning.

För mer information om black-box-testning, se länken nedan:

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

Grey Box-testning

Grey box testning är en kombination av white box och Black box testning. Det kan utföras av en person som kunde både kodning och testning. Och om den enskilde personen utför white box, såväl som black-box-testning för applikationen, kallas Gray box-testning.

För att få mer information om testning av grå låda, se länken nedan:

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

Hur man utför manuell testning

Först observerar testaren alla dokument relaterade till programvaran för att välja testområden.
Testare analyserar kravdokument för att täcka alla krav som kunden ställer.
Testare utvecklar testfallen enligt kravdokumentet.
Alla testfall utförs manuellt genom att använda Black box-testning och white box-testning.
Om buggar inträffade informerar testteamet utvecklingsteamet.
Utvecklingsteamet fixar buggar och överlämnade programvara till testteamet för ett omtest.

Programvarubyggeprocess

När kravet har samlats in, kommer det att tillhandahålla de två olika teamutvecklings- och testteamen.
Efter att ha fått kravet kommer den berörda utvecklaren att börja skriva koden.
Och under tiden förstår testingenjören kravet och förbereder de nödvändiga dokumenten, fram till nu kan utvecklaren slutföra koden och lagra i Verktyg för kontrollversion .
Därefter ändras koden i användargränssnittet, och dessa ändringar hanteras av ett separat team, som är känt som bygga team .
Detta byggteam kommer att ta koden och börja kompilera och komprimera koden med hjälp av ett byggverktyg. När vi väl har fått lite utdata går utdata i zip-filen, som kallas Bygga (applikation eller mjukvara). Varje byggnad kommer att ha ett unikt nummer som (B001, B002).
Då kommer just denna Build att installeras i testservern. Efter det kommer testingenjören att komma åt denna testserver med hjälp av Test URL och börja testa applikationen.
Om testingenjören hittade någon bugg kommer han/hon att rapporteras till den berörda utvecklaren.
Sedan kommer utvecklaren att reproducera buggen i testservern och fixa buggen och återigen lagra koden i kontrollversionsverktyget, och den kommer att installera den nya uppdaterade filen och ta bort den gamla filen; denna process fortsätter tills vi får den stabila Build.
När vi väl fått stallbygget kommer det att lämnas över till kunden.

Anteckning 1

När vi har samlat in filen från kontrollversionsverktyget kommer vi att använda byggverktyget för att kompilera koden från högnivåspråk till språk på maskinnivå. Efter kompilering, om filstorleken kommer att öka, så kommer vi att komprimera den specifika filen och dumpas i testservern.
Denna process görs av Bygg team , utvecklare (om byggteamet inte finns där kan en utvecklare göra det) eller testledning (om byggteamet direkt hanterar zip-filen och installerar applikationen på testservern och informerar testingenjören).
I allmänhet kan vi inte få en ny version för varje bugg; annars kommer det mesta av tiden att gå till spillo bara på att skapa byggen.

Anteckning 2

Bygg team

Byggteamets huvudsakliga uppgift är att skapa applikationen eller Build och konvertera högnivåspråket till lågnivåspråk.

Bygga

Det är programvara som används för att konvertera koden till applikationsformat. Och den består av en uppsättning funktioner och buggfixar som överlämnas till testingenjören för teständamål tills den blir stabil.

Verktyg för kontrollversion

Det är en programvara eller applikation som används för följande ändamål:

I det här verktyget kan vi spara olika typer av filer.
Den är alltid säker eftersom vi kommer åt filen från verktygen med samma inloggningsuppgifter.
Det primära syftet med verktygen är att spåra de ändringar som gjorts för de befintliga filerna.

Exempel på byggprocess

Låt oss se ett exempel för att förstå hur man bygger processarbete på de verkliga scenarierna:

Så snart testingenjören får felet kommer de att skicka det till utvecklarna, och de behöver lite tid att analysera; efter det fixar han/hon bara felet (Testingenjören kan inte ge insamlingen av buggen).

Utvecklaren bestämmer hur många buggar han kan fixa enligt deras tid. Och testingenjören bestäms, vilken bugg som ska fixas först efter deras behov eftersom testingenjörerna inte har råd att sluta testa.

Och testingenjören som får mailet, de kan bara veta vilken bugg som fixas av lista över buggfixar .

Tiden kommer att öka eftersom vid den första Build, och utvecklare bör skriva koden i de olika funktionerna. Och i slutet kan han/hon bara göra buggfixarna och antalet dagar kommer att minska.

Not 3

Testcykel

Testcykeln är den tid som testingenjören får för att testa varje byggnad.

Skillnader mellan de två konstruktionerna

De buggar som finns i en version och kan fixas till vilken som helst framtida version, vilket beror på testingenjörens krav. Varje ny Build är den modifierade versionen av den gamla, och dessa ändringar kan vara buggfixar eller lägga till några nya funktioner.

Hur ofta vi fick den nya byggnaden

I början brukade vi få veckobyggnader, men i det senaste testskedet, när applikationen blev stabil, brukade vi få den nya byggnaden en gång på 3 dagar, två dagar eller också dagligen.

Hur många byggen får vi

gratis ipconfig

Om vi tänker på ett år av vilken projekttid som helst, fick vi 22-26 byggen.

När vi får buggfixar

I allmänhet förstår vi buggfixarna först efter att testcykeln är klar, eller efter att insamlingen av buggar har fixats i en version och överlämnande i nästa versioner.

Fördelar med manuell testning

Det kräver inga programmeringskunskaper när du använder Black box-metoden.
Den används för att testa dynamiskt föränderliga GUI-designer.
Tester interagerar med programvara som en riktig användare så att de kan upptäcka användarvänlighets- och användargränssnittsproblem.
Det säkerställer att programvaran är hundra procent buggfri.
Det är kostnadseffektivt.
Lätt att lära sig för nya testare.

Nackdelar med manuell testning

Det kräver ett stort antal mänskliga resurser.
Det är väldigt tidskrävande.
Tester utvecklar testfall baserat på deras kompetens och erfarenhet. Det finns inga bevis för att de har täckt alla funktioner eller inte.
Testfall kan inte användas igen. Behöver utveckla separata testfall för varje ny programvara.
Det ger inte testning på alla aspekter av testning.
Eftersom två team arbetar tillsammans är det ibland svårt att förstå varandras motiv, det kan vilseleda processen.

Manuella testverktyg

Vid manuell testning, olika typer av testning som enhet, integration, säkerhet, prestanda och buggspårning, har vi olika verktyg som Jira , Bugzilla , Mantis, Zap, NUnit, Tessy, LoadRunner, Citrus, SonarQube, etc. tillgängliga i marknadsföra. Vissa av verktygen är öppen källkod, och andra är kommersiella.

För mer information om testverktyg, se länken nedan:

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

Låt oss förstå dem en efter en:

LoadRunner

Det är de vanligaste verktygen för prestandatestning. LoadRunner används huvudsakligen för att stödja prestandatester för det breda utbudet av procedurer, antal tillvägagångssätt och applikationsmiljöer.

Huvudsyftet med att köra LoadRunner-verktyget är att snabbt klassificera de vanligaste källorna till prestandaproblem.

Funktioner i LoadRunner

inte

LoadRunner-verktyget innehåller n-antal applikationer, vilket minskar tiden för att förstå och beskriva rapporterna.
Vi kan få noggranna resultattestrapporter genom att använda LoadRunner-verktyget.
Det kommer att minska kostnaderna för distribuerad belastningstestning och även erbjuda det operativa verktyget för distributionsspårning.

Citrus

Citrus är ett integrationstestverktyg, vilket är det mest använda testramverket. Det är skrivet i Java programmering språk. Det används mest för att begära och svara på serversidan och klientsidan och validera XML JSON-filerna.

För att utföra end-to-end användningsfallstestning stöder citrus flera HTTP-, JMS- och SOAP-protokoll.

Egenskaper hos Citrus

Följande är några av de viktiga funktionerna i Citrus-verktyget:

Den används för att skicka och ta emot meddelanden.
Citrus är tillgänglig som både öppen källkod och licensierad på marknaden.
Det ger en lågkostnadslösning.
Vi kan autentisera databasen genom att använda citrusverktyget.
Den kommer att beskriva sekvensen av meddelanden, erbjuda testplanen och dokumentera testtäckningen.
Det skapar meddelandet och verifierar svaren.

ZAP

ZAP är en säkerhetsskanner för webbapplikationer med öppen källkod. Det står för Zed Attack Proxy . Precis som vissa andra verktyg är det också skrivet i JAVA programmeringsspråk . Det är det mest effektiva Öppna Web Application Security Projects [OWASP].

Funktioner hos ZAP

Det stöder många operativsystem som Windows, Linux, OS X.
Den har en plugin-baserad arkitektur.
Den innehåller en onlinemarknadsplats som tillåter oss att lägga till nya eller uppdaterade funktioner.
ZAP:s GUI-kontrollpanel är lätt att använda.

Nunna

NUnit är ett av de mest använda enhetstestverktygen. Det är ett verktyg med öppen källkod och huvudsakligen härlett från JUnit .

Det var helt skrivet i C# programmeringsspråk och passar alla .Net-språk .

Med andra ord kan vi säga att NUnit-verktyget är helt omdesignat för att bli fördelen med många .Net-språkkvaliteter. Till exempel:

Reflektionsrelaterade förmågor. Andra anpassade attribut. Manuell testning

Kännetecken för NUnit

Det tillåter påståenden som en statisk metod för fördelsklassen.
Det upprätthåller de datadrivna testerna.
Den stöder flera plattformar, som .NET core Xamarin mobile, Silverlight och effektiva ramverk.
NUnits förmåga hjälper oss att utföra testerna samtidigt.
Den använder en konsollöpare för att ladda och utföra testerna.

JIRA

Det vanligaste felspårningsverktyget är JIRA , som är ett verktyg med öppen källkod. Den används för buggspårning, projekthantering och problemspårning.

I det här verktyget kan vi enkelt spåra alla typer av buggar eller defekter relaterade till programvaran och producerade av testingenjörerna.

Funktioner hos JIRA

Det är ett tidsbesparande verktyg.
Jira används för att spåra defekter och problem.
Den används för att upprätta dokumentationsuppgifterna.
Jira är ett mycket användbart verktyg för att spåra förbättringen av vår dokumentation.

För att få fullständig information om Jira-verktyget, se länken nedan: https://www.javatpoint.com/jira-tutorial.

SonarQube

Ett annat testverktyg för manuell testning är SonarQube, som förbättrar vårt arbetsflöde med kontinuerlig kodkvalitet och kodsäkerhet. Det är flexibelt med hjälp av plug-ins.

Det är helt skrivet i programmeringsspråket JAVA. Den erbjuder helautomatisk utvärdering och integration med Ant, Maven, Gradle, MSBuild och konstanta integrationsverktyg. SonarQube har förmågan att registrera en statistikhistorik och ger utvecklingsgrafen.

Funktioner i Sonarqube

Nedan är några av de viktiga funktionerna i SonarQube-verktyget:

Det stöder flera programmeringsspråk som C, C++, Python, JAVA, HTML, CSS, VB.NET, PHP, COBOL, PL/SQL, etc.
Under GNU Lesser General Public License är Sonarqube fritt tillgänglig.
SonarQube är anslutet till några viktiga externa verktyg som GitHub, Active Directory, LDAP och andra.
SonarQube slogs samman med utvecklingsmiljöerna Visual Studio, Eclipse och IntelliJ IDEA på grund av SonarLint plugin-program.

JMeter

JMeter är ett verktyg med öppen källkod som används för att testa prestandan för både statiska och dynamiska resurser och dynamiska webbapplikationer.

normala former

Den är helt designad på JAVA-applikationen för att ladda det funktionella testbeteendet och mäta applikationens prestanda.

Det underlättar för användare eller utvecklare att använda källkoden för utveckling av andra applikationer.

Funktioner i JMeter

Nedan är några av de väsentliga egenskaperna hos JMeter:

Det är plattformsoberoende, vilket accepterar en JVM-liknande Windows, Mac och Linux, etc.
Den stöder ett användarvänligt GUI, som är interaktivt och enkelt.
Det är otroligt utbyggbart att ladda prestandatestet i flera typer av servrar.

För mer information om JMeter, se länken nedan:

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

Med Bugz

Ett annat felspårningsverktyg som används vid manuell testning är Med Bugz .

Det används mest av många organisationer för att spåra de olika buggarna i applikationen.

Bugzilla är ett verktyg med öppen källkod som hjälper kunden och kunden att hålla reda på defekterna. Bugzilla anses också vara ett testhanteringsverktyg eftersom vi i detta enkelt kan länka andra testfallshanteringsverktyg som ALM, Quality Center, etc.

Funktioner hos Bugzilla

Bugzilla har några ytterligare funktioner som hjälper oss att rapportera felet enkelt:

Den stöder olika operativsystem som Windows, Linux och Mac.
Med hjälp av Bugzilla kan vi lista en bugg i flera format.
Användarinställningar kan mäta e-postmeddelanden.
Bugzilla har avancerade sökfunktioner.

Bönsyrsa

Mantis är ett webbaserat felspårningssystem. ManitsBT står för Mantis Bug Tracker . Det används för att följa mjukvarufel och utförs i PHP-programmeringsspråket. Det är också ett verktyg med öppen källkod.

Funktioner av Mantis

Några av standardfunktionerna för det specifika verktyget är följande:

Med hjälp av detta verktyg har vi tillgång till fulltextsökning.
Granska spår av ändringar som gjorts i frågor.
Det tillhandahåller integration av revisionskontrollsystemet.
Revisionskontroll av textfält och anteckningar

För att få mer information om felspårningsverktyg, se följande länk: https://www.javatpoint.com/defect-or-bug-tracking-tool .

Tessy

Ett annat integrationstestverktyg är Tessy , som används för att utföra integrationen och enhetstesten för den inbäddade programvaran. Det hjälper oss också att upptäcka kodtäckningen för programvaran eller en applikation.

period nyckel

Den kan enkelt hantera hela testorganisationen, inklusive affärsbehov, testhantering, täckningsmängd och spårbarhet.

Tessy innehåller tre primära funktioner, som är följande:

Test Interface Editor (TIE)
Testdataredigerare (TDE)
Arbetsyta.

Funktioner hos TESSY

Standardfunktionerna hos TESSY är följande:

Den producerar testrapporten för testkörningsresultaten.
Den stöder olika programmeringsspråk som C och C++.
Tessy används för att utvärdera gränssnittet för funktionen och beskriver variabeln som används av den funktionen.

För mer information om integrationstestverktyg, hänvisar du till följande länk: https://www.javatpoint.com/integration-testing-tools .

Översikt

I den här artikeln har vi sett detaljerad information om Manuell testning, som inkluderar definitionen av manuell testning, behovet av manuell testning, typ av manuell testning, manuella testverktyg, processen för manuell testning och några viktiga fördelar och nackdelar med det.

Slutligen kan vi säga att det är en process där testingenjören måste vara mycket uthållig, innovativ och lyhörd.

Vid manuell testning måste testingenjören tänka och utföra som slutanvändartolkning.

För att kunna implementera manuell testning behöver en testingenjör produktiv skicklighet och fantasi. Och de måste tänka på flera situationer eller scenarier för att testa en specifik applikation.

Även om vi för närvarande kan testa nästan alla applikationer med hjälp av automationstestning är det fortfarande nödvändigt med manuell testning eftersom det är basen för mjukvarutestning.