Handmatig testen is een softwaretestproces waarbij testgevallen handmatig worden uitgevoerd zonder gebruik te maken van een geautomatiseerd hulpmiddel. Alle testgevallen worden door de tester handmatig uitgevoerd vanuit het perspectief van de eindgebruiker. Het zorgt ervoor dat de applicatie werkt, zoals vermeld in het vereistendocument of niet. Er worden testgevallen gepland en geïmplementeerd om bijna 100 procent van de softwareapplicatie te voltooien. Testcaserapporten worden ook handmatig gegenereerd.

Handmatig testen is een van de meest fundamentele testprocessen, omdat hiermee zowel zichtbare als verborgen gebreken van de software kunnen worden opgespoord. Het verschil tussen de verwachte output en de output, gegeven door de software, wordt gedefinieerd als een defect. De ontwikkelaar heeft de gebreken verholpen en het aan de tester overhandigd om het opnieuw te testen.

Handmatig testen is verplicht voor elke nieuw ontwikkelde software vóór geautomatiseerd testen. Dit testen vergt grote inspanningen en tijd, maar het geeft de zekerheid van bugvrije software. Handmatig testen vereist kennis van handmatige testtechnieken, maar niet van geautomatiseerde testtools.

Handmatig testen is essentieel omdat een van de software testen grondbeginselen zijn '100% automatisering is niet mogelijk.'

Waarom we handmatig testen nodig hebben

Wanneer een applicatie op de markt komt en deze onstabiel is, een bug of problemen vertoont of een probleem veroorzaakt terwijl eindgebruikers deze gebruiken.

Als we dit soort problemen niet willen tegenkomen, moeten we één testronde uitvoeren om de applicatie bugvrij en stabiel te maken en een kwaliteitsproduct aan de klant te leveren, want als de applicatie bugvrij is, zal de eindgebruiker zal de applicatie gemakkelijker gebruiken.

Java-teller

Als de testingenieur handmatige tests uitvoert, kan hij/zij de applicatie testen vanuit het perspectief van de eindgebruiker en meer vertrouwd raken met het product, wat hen helpt de juiste testcases van de applicatie te schrijven en snelle feedback over de applicatie te geven.

Soorten handmatig testen

Er zijn verschillende methoden die worden gebruikt voor handmatig testen. Elke techniek wordt gebruikt volgens de testcriteria. Hieronder vindt u de soorten handmatige tests:

• White Box-testen
• Black Box-testen
• Grijze doos testen

Whitebox-testen

Het testen van de white box wordt gedaan door de ontwikkelaar, waarbij ze elke regel van een code controleren voordat deze aan de testingenieur wordt doorgegeven. Omdat de code tijdens het testen zichtbaar is voor de ontwikkelaar, wordt dit ook wel White box-testen genoemd.

Raadpleeg de onderstaande link voor meer informatie over white box-testen:

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

Blackbox-testen

Het black box-testen wordt gedaan door de Test Engineer, waar zij de functionaliteit van een applicatie of de software kunnen controleren volgens de behoeften van de klant/klant. Hierbij is de code tijdens het testen niet zichtbaar; daarom staat het bekend als black-box-testen.

Raadpleeg de onderstaande link voor meer informatie over black-box-testen:

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

Gray Box-testen

Gray box-testen is een combinatie van white box- en black box-testen. Het kan worden uitgevoerd door iemand die zowel coderen als testen kent. En als de enkele persoon zowel white box- als black-box-testen voor de toepassing uitvoert, staat dit bekend als Gray box-testen.

Raadpleeg de onderstaande link voor meer informatie over het testen van grijze dozen:

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

Handmatig testen uitvoeren

• Eerst observeert de tester alle documenten die verband houden met software, om testgebieden te selecteren.
• Tester analyseert vereiste documenten om aan alle door de klant gestelde eisen te voldoen.
• Tester ontwikkelt de testgevallen volgens het vereistendocument.
• Alle testgevallen worden handmatig uitgevoerd door middel van Black box testen en white box testen.
• Als er bugs zijn opgetreden, informeert het testteam het ontwikkelteam.
• Het ontwikkelingsteam repareert bugs en overhandigt de software aan het testteam voor een nieuwe test.

Software-bouwproces

• Zodra de vereiste is verzameld, wordt deze verstrekt aan de twee verschillende teamontwikkelings- en testteams.
• Nadat de vereiste is verkregen, begint de betreffende ontwikkelaar met het schrijven van de code.
• En in de tussentijd begrijpt de testingenieur de vereiste en bereidt hij de vereiste documenten voor, tot nu toe kan de ontwikkelaar de code voltooien en opslaan in de Tool Versiebeheer .
• Daarna verandert de code in de gebruikersinterface en worden deze wijzigingen afgehandeld door één afzonderlijk team, dat bekend staat als de team opbouwen .
• Dit bouwteam neemt de code en begint met het compileren en comprimeren van de code met behulp van een bouwtool. Zodra we wat uitvoer hebben, gaat de uitvoer naar het zip-bestand, dat bekend staat als Bouwen (applicatie of software). Elke build heeft een uniek nummer, zoals (B001, B002).
• Vervolgens wordt deze specifieke Build op de testserver geïnstalleerd. Daarna zal de testingenieur met behulp van de Test-URL toegang krijgen tot deze testserver en beginnen met het testen van de applicatie.
• Als de testingenieur een bug heeft gevonden, wordt hij/zij gerapporteerd aan de betreffende ontwikkelaar.
• Vervolgens zal de ontwikkelaar de bug op de testserver reproduceren en de bug repareren en de code opnieuw opslaan in de Control-versietool, en het nieuwe bijgewerkte bestand installeren en het oude bestand verwijderen; dit proces wordt voortgezet totdat we de stabiele build krijgen.
• Zodra wij de stabiele Build binnen hebben, wordt deze overgedragen aan de klant.

Notitie 1

• Zodra we het bestand uit de Control-versietool hebben verzameld, zullen we de build-tool gebruiken om de code te compileren van taal op hoog niveau naar taal op machineniveau. Als de bestandsgrootte na de compilatie toeneemt, zullen we dat specifieke bestand comprimeren en naar de testserver dumpen.
• Dit proces wordt uitgevoerd door Bouw een team , ontwikkelaar (als het buildteam er niet is, kan een ontwikkelaar het doen) of de test leiding (als het bouwteam de zip rechtstreeks afhandelt en de applicatie op de testserver installeert en de testingenieur informeert).
• Over het algemeen kunnen we niet voor elke bug een nieuwe build krijgen; anders wordt het grootste deel van de tijd alleen verspild aan het maken van de builds.

Opmerking2

Bouw een team

De belangrijkste taak van het bouwteam is het maken van de applicatie of de Build en het converteren van de taal op hoog niveau naar taal op laag niveau.

Bouwen

Het is software die wordt gebruikt om de code naar een applicatieformaat te converteren. En het bestaat uit een aantal functies en bugfixes die voor testdoeleinden aan de testingenieur worden overgedragen totdat het stabiel wordt.

Versiebeheertool

Het is een software of applicatie die wordt gebruikt voor de volgende doeleinden:

• In deze tool kunnen we verschillende soorten bestanden opslaan.
• Het is altijd beveiligd omdat we vanuit de tools toegang krijgen tot het bestand met dezelfde inloggegevens.
• Het primaire doel van de tools is het bijhouden van de wijzigingen die voor de bestaande bestanden zijn aangebracht.

Voorbeeld van een bouwproces

Laten we een voorbeeld bekijken om te begrijpen hoe u proceswerk kunt bouwen op basis van de echte scenario's:

Zodra de testingenieur de bug ontdekt, sturen ze deze naar de ontwikkelaars, en die hebben wat tijd nodig om te analyseren; daarna repareert hij/zij alleen de bug (de testingenieur kan de verzameling bugs niet geven).

De ontwikkelaar bepaalt hoeveel bugs hij kan repareren, afhankelijk van de tijd. En de testingenieur beslist welke bug het eerst moet worden opgelost op basis van zijn behoeften, omdat de testingenieurs het zich niet kunnen veroorloven om te stoppen met testen.

En de testingenieur die de mail ontvangt, kan alleen weten welke bug door de lijst met bugfixes .

De tijd zal toenemen omdat ontwikkelaars bij de eerste build de code in de verschillende functies moeten schrijven. En uiteindelijk kan hij/zij alleen de bugfixes uitvoeren en wordt het aantal dagen verlaagd.

Notitie 3

Testcyclus

De testcyclus is de tijdsduur die de testingenieur krijgt om elke build te testen.

Verschillen tussen de twee builds

De bugs zijn in één build gevonden en kunnen in elke toekomstige build worden opgelost, afhankelijk van de vereisten van de testingenieur. Elke nieuwe build is de gewijzigde versie van de oude, en deze wijzigingen kunnen bugfixes zijn of nieuwe functies toevoegen.

Hoe vaak we de nieuwe Build kregen

ex van gebruikersnaam

In het begin kregen we wekelijkse builds, maar in de laatste testfase, toen de applicatie stabiel werd, kregen we de nieuwe build eens in de drie dagen, twee dagen of ook dagelijks.

Hoeveel builds we krijgen

Als we een jaar van een projectduur in ogenschouw nemen, hebben we 22-26 builds gekregen.

Wanneer we de bugfixes krijgen

Over het algemeen begrijpen we de bugfixes pas nadat de testcyclus is voltooid, of de verzameling bugs is opgelost in één build en overgedragen in de volgende builds.

Voordelen van handmatig testen

• Er is geen programmeerkennis vereist bij het gebruik van de Black Box-methode.
• Het wordt gebruikt om dynamisch veranderende GUI-ontwerpen te testen.
• Tester communiceert met software als een echte gebruiker, zodat ze problemen met de bruikbaarheid en de gebruikersinterface kunnen ontdekken.
• Het zorgt ervoor dat de software honderd procent bugvrij is.
• Het is kosteneffectief.
• Gemakkelijk te leren voor nieuwe testers.

Nadelen van handmatig testen

• Het vergt een groot aantal menselijke hulpbronnen.
• Het is erg tijdrovend.
• Tester ontwikkelt testgevallen op basis van hun vaardigheden en ervaring. Er is geen bewijs dat ze alle functies hebben bestreken of niet.
• Testgevallen kunnen niet opnieuw worden gebruikt. Voor elke nieuwe software moeten afzonderlijke testgevallen worden ontwikkeld.
• Het biedt niet de mogelijkheid om alle aspecten van het testen te testen.
• Omdat twee teams samenwerken, is het soms moeilijk om elkaars motieven te begrijpen, wat het proces kan misleiden.

Handmatige testhulpmiddelen

Bij handmatig testen en verschillende soorten testen, zoals unit-, integratie-, beveiliging-, prestatie- en bug-tracking, hebben we verschillende tools zoals Jira, Bugzilla, Mantis, Zap, NUnit, Tessy, LoadRunner, Citrus, SonarQube, etc. beschikbaar in de markt. Sommige tools zijn open-source, andere zijn commercieel.

Raadpleeg de onderstaande link voor meer informatie over testtools:

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

Laten we ze een voor een begrijpen:

LoadRunner

Het zijn de meest gebruikte tools voor prestatietests. LoadRunner wordt voornamelijk gebruikt ter ondersteuning van prestatietests voor een breed scala aan procedures, aantal benaderingen en applicatieomgevingen.

Hoe iPhone-emoji's op Android te krijgen

Het belangrijkste doel van het uitvoeren van de LoadRunner-tool is om de meest voorkomende oorzaken van prestatieproblemen snel te classificeren.

Kenmerken van LoadRunner

• De LoadRunner-tool bevat n-aantallen applicaties, waardoor de tijd voor het begrijpen en beschrijven van de rapporten wordt verkort.
• We kunnen grondige prestatietestrapporten verkrijgen door de LoadRunner-tool te gebruiken.
• Het zal de kosten van gedistribueerde belastingtests verlagen en ook het operationele hulpmiddel bieden voor het volgen van implementaties.

Citrus

Citrus is een integratietesttool, het meest gebruikte testframework. Het is erin geschreven Java-programmering taal. Het wordt meestal gebruikt voor het aanvragen en beantwoorden van server- en clientzijde en het valideren van de XML JSON-bestanden.

Om de end-to-end use case-tests uit te voeren, ondersteunt Citrus verschillende HTTP-, JMS- en SOAP-protocollen.

Kenmerken van Citrus

Hieronder volgen enkele belangrijke kenmerken van de Citrus-tool:

• Het wordt gebruikt om berichten te verzenden en te ontvangen.
• Citrus is zowel als open source als met licentie op de markt verkrijgbaar.
• Het levert een goedkope oplossing.
• We kunnen de database authenticeren met behulp van de citrustool.
• Het beschrijft de volgorde van de berichten, biedt het testplan aan en documenteert de testdekking.
• Het creëert het bericht en verifieert de antwoorden.

ZAP

ZAP is een open-source beveiligingsscanner voor webapplicaties. Het staat voor Zed-aanvalsproxy . Net als sommige andere tools staat het ook geschreven in de JAVA-programmeertaal . Het is het meest effectief Open beveiligingsprojecten voor webapplicaties [OWASP].

Kenmerken van ZAP

• Het ondersteunt veel besturingssystemen zoals Windows, Linux, OS X.
• Het heeft een op plug-ins gebaseerde architectuur.
• Het bevat een online marktplaats waarmee we nieuwe of bijgewerkte functies kunnen toevoegen.
• Het GUI-configuratiescherm van ZAP is eenvoudig te gebruiken.

Non

NUnit is een van de meest gebruikte unit-testtools. Het is een open-sourcetool en is voornamelijk afgeleid van de JUnit .

Het was volledig geschreven in de C#-programmeertaal en geschikt voor iedereen .Net-talen .

Met andere woorden, we kunnen zeggen dat de NUnit-tool volledig opnieuw is ontworpen om het voordeel te halen uit veel .Net-taalkwaliteiten. Bijvoorbeeld:

Reflectiegerelateerde capaciteiten. Andere aangepaste kenmerken.

Kenmerken van NUnit

• Het maakt de beweringen mogelijk als een statische methode van de voordeelklasse.
• Het ondersteunt de datagestuurde tests.
• Het ondersteunt verschillende platforms, zoals .NET core Xamarin mobile, Silverlight en efficiënt framework.
• De mogelijkheid van NUnit helpt ons om de tests gelijktijdig uit te voeren.
• Het maakt gebruik van een consolerunner om de tests te laden en uit te voeren.

JIRA

De meest gebruikte tool voor het volgen van bugs is JIRA , een open source-tool. Het wordt gebruikt voor het volgen van bugs, projectbeheer en het volgen van problemen.

In deze tool kunnen we eenvoudig allerlei soorten bugs of defecten opsporen die verband houden met de software en die door de testingenieurs zijn geproduceerd.

Kenmerken van JIRA

• Het is een tijdbesparend hulpmiddel.
• Jira wordt gebruikt om de defecten en problemen op te sporen.
• Het wordt gebruikt om de documentatietaken vast te stellen.
• Jira is een zeer nuttig hulpmiddel bij het volgen van de verbetering van onze documentatie.

Voor de volledige informatie over de Jira-tool raadpleegt u de onderstaande link: https://www.javatpoint.com/jira-tutorial.

SonarQube

Een ander testinstrument voor handmatig testen is SonarQube, dat onze workflow verbetert met continue codekwaliteit en codebeveiliging. Het is flexibel door het gebruik van plug-ins.

c++ tekenreeks gesplitst

Het is volledig geschreven in de programmeertaal JAVA. Het biedt volledig geautomatiseerde evaluatie en integratie met Ant, Maven, Gradle, MSBuild en constante integratietools. SonarQube heeft de mogelijkheid om een ​​metrische geschiedenis vast te leggen en de evolutiegrafiek weer te geven.

Kenmerken van Sonarqube

Hieronder staan ​​enkele van de belangrijkste kenmerken van de SonarQube-tool:

• Het ondersteunt verschillende programmeertalen zoals C, C++, Python, JAVA, HTML, CSS, VB.NET, PHP, COBOL, PL/SQL, enz.
• Onder de GNU Lesser General Public License is Sonarqube gratis beschikbaar.
• SonarQube is aangesloten bij een aantal belangrijke externe tools zoals GitHub, Active Directory, LDAP en andere.
• SonarQube is samengevoegd met de ontwikkelomgevingen Visual Studio, Eclipse en IntelliJ IDEA vanwege de SonarLint plug-ins.

JMeter

JMeter is een open-sourcetool die wordt gebruikt om de prestaties van zowel statische als dynamische bronnen en dynamische webapplicaties te testen.

Het is volledig ontworpen op de JAVA-applicatie om het functionele testgedrag te laden en de prestaties van de applicatie te meten.

Het maakt het voor gebruikers of ontwikkelaars mogelijk om de broncode te gebruiken voor de ontwikkeling van andere applicaties.

Kenmerken van JMeter

Hieronder staan ​​enkele van de essentiële kenmerken van JMeter:

• Het is platformonafhankelijk en accepteert een JVM-achtige Windows, Mac en Linux, enz.
• Het ondersteunt een gebruiksvriendelijke GUI, die interactief en eenvoudig is.
• Het is ongelooflijk uitbreidbaar om de prestatietest op meerdere soorten servers te laden.

Raadpleeg de onderstaande link voor meer informatie over JMeter:

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

Met Bugz

Een ander hulpmiddel voor het volgen van bugs dat wordt gebruikt bij handmatig testen is Met Bugz .

Het wordt door veel organisaties het meest gebruikt om de verschillende bugs van de applicatie op te sporen.

Bugzilla is een open-source tool die de klant en de opdrachtgever helpt bij het bijhouden van de gebreken. Bugzilla wordt ook beschouwd als een testmanagementtool omdat we hierin eenvoudig andere testcasemanagementtools kunnen koppelen, zoals ALM, Quality Centre, etc.

Kenmerken van Bugzilla

Bugzilla heeft een aantal extra functies waarmee we de bug gemakkelijk kunnen melden:

• Het ondersteunt verschillende besturingssystemen zoals Windows, Linux en Mac.
• Met behulp van Bugzilla kunnen we een bug in verschillende formaten weergeven.
• Gebruikersvoorkeuren kunnen e-mailmeldingen meten.
• Bugzilla heeft geavanceerde zoekmogelijkheden.

bidsprinkhaan

Mantis is een webgebaseerd bugvolgsysteem. ManitsBT staat voor Mantis-bugtracker . Het wordt gebruikt om de softwarefouten te volgen en wordt uitgevoerd in de programmeertaal PHP. Het is ook een open source-tool.

Kenmerken van bidsprinkhaan

Enkele standaardfuncties van de specifieke tool zijn als volgt:

• Met behulp van deze tool hebben we volledige zoekmogelijkheden in de tekst.
• Audittrails van wijzigingen die in problemen zijn aangebracht.
• Het biedt de revisiecontrolesysteemintegratie.
• Revisiecontrole van tekstvelden en notities

Raadpleeg de volgende link voor meer informatie over tools voor het volgen van bugs: https://www.javatpoint.com/defect-or-bug-tracking-tool .

Tessy

Een ander hulpmiddel voor het testen van integraties is Tessy , dat wordt gebruikt om de integratie en unit-tests voor de embedded software uit te voeren. Het helpt ons ook om de codedekking van de software of een applicatie te ontdekken.

objectgelijkheid in Java

Het kan eenvoudig de gehele testorganisatie beheren, inclusief bedrijfsbehoeften, testbeheer, dekkingshoeveelheid en traceerbaarheid.

Tessy bevat drie primaire functies, namelijk:

• Testinterface-editor (TIE)
• Testgegevenseditor (TDE)
• Werkruimte.

Kenmerken van TESSY

De standaardeigenschappen van de TESSY zijn als volgt:

• Het produceert het testrapport voor de resultaten van de testuitvoering.
• Het ondersteunt verschillende programmeertalen zoals C en C++.
• Tessy wordt gebruikt om de interface van de functie te evalueren en beschrijft de variabele die door die functie wordt gebruikt.

Voor meer informatie over integratietesttools verwijzen we naar de volgende link: https://www.javatpoint.com/integration-testing-tools.

Overzicht

In dit artikel hebben we gedetailleerde informatie over gezien Handmatig testen, waaronder de definitie van handmatig testen, de noodzaak van handmatig testen, het type handmatig testen, handmatige testtools, het proces van handmatig testen en enkele belangrijke voor- en nadelen ervan.

Ten slotte kunnen we zeggen dat het een proces is waarbij de testingenieur zeer volhardend, innovatief en responsief moet zijn.

Bij handmatig testen moet de testingenieur denken en presteren zoals de eindgebruiker interpreteert.

Om handmatig testen te kunnen implementeren, heeft een testingenieur productieve vaardigheden en verbeeldingskracht nodig. En ze moeten meerdere situaties of scenario’s bedenken om een ​​specifieke applicatie te testen.

Ook al kunnen we momenteel bijna alle applicaties testen met behulp van geautomatiseerd testen, toch is handmatig testen noodzakelijk omdat dit de basis vormt voor het testen van software.