Menu

Top 20 praktische tips voor het testen van software die u moet lezen voordat u een toepassing test

top 20 practical software testing tips you should read before testing any application

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Ik wens dat alle testers de softwaretestmethoden lezen die in dit artikel zijn bijgewerkt ​ Lees elk punt zorgvuldig door en probeer ze toe te passen in uw dagelijkse testactiviteiten. Dit is wat ik verwacht van de lezers via dit artikel. Als u geen enkele testmethode begrijpt, vraag om meer uitleg in de commentaren hieronder.

U leert al deze testmethoden echter door ervaring. Maar waarom leer je al deze dingen niet voordat je een fout maakt?

Kom, laten we eens kijken hen!

Praktische tips voor het testen van software

Hier zijn enkele van de beste testmethoden die ik door ervaring heb geleerd:

hoe regex te gebruiken in c ++

# 1) Leer uw testresultaten grondig te analyseren. Negeer geen enkele testresultaten. Het uiteindelijke testresultaat kan ‘geslaagd’ of ‘mislukt’ zijn, maar het oplossen van de hoofdoorzaak van ‘mislukt’ geeft u de oplossing voor het probleem. Testers worden gerespecteerd als ze niet alleen het Bugs maar bieden ook oplossingen.

#twee) Leer om het Testdekking elke keer dat u een toepassing test. 100% testdekking is misschien niet mogelijk, maar toch kunt u altijd proberen om er dichtbij te komen.

# 3) Om een ​​maximale testdekking te garanderen, breek uw Application Under Test (AUT) op in kleinere functionele modules. Schrijf testcases op dergelijke individuele unit-modules. Breek deze modules ook indien mogelijk in kleinere delen.
Bijvoorbeeld, Laten we aannemen dat u uw websiteapplicatie in modules heeft opgedeeld en dat ‘gebruikersinformatie accepteren’ een van de modules is. U kunt dit scherm ‘Gebruikersinformatie’ in kleinere delen opsplitsen om testcases te schrijven: onderdelen zoals UI-testen, Beveiligingstests ​ Functioneel testen van het formulier ‘Gebruikersinformatie’ enz.

Pas alle formulierveldtype- en groottetests, negatieve en validatietests toe op de invoervelden en schrijf al dergelijke testcases voor maximale dekking.

# 4) Terwijl Testcases schrijven , schrijf eerst testcases voor de beoogde functionaliteit, d.w.z. voor geldige condities volgens de vereisten. Schrijf vervolgens testcases voor ongeldige voorwaarden. Dit omvat zowel verwacht als onverwacht gedrag van de te testen applicatie.

# 5) Denk positief. Begin met het testen van de applicatie met de bedoeling bugs / fouten te vinden. Denk van tevoren niet dat er geen bugs in de applicatie zullen zitten. Als je de applicatie test met de bedoeling bugs te vinden, zul je die zeker kunnen vinden Subtiele bugs ook.

# 6) Schrijf uw testcases in de behoefteanalyse en ontwerpfase zelf. Op deze manier kunt u ervoor zorgen dat alle vereisten toetsbaar zijn.

# 7) Maak jouw testcases beschikbaar voor de ontwikkelaars voorafgaand aan het coderen. Bewaar uw testcases niet bij u in afwachting van de definitieve applicatierelease om te testen, omdat u denkt dat u meer bugs kunt loggen. Laat de ontwikkelaars uw testcases grondig analyseren om een ​​kwaliteitsapplicatie te ontwikkelen. Dit bespaart ook tijd voor opnieuw werken.

# 8) Identificeer indien mogelijk en groepeer je testcases voor Regressietesten ​ Dit zorgt voor een snelle en effectieve handmatige regressietest.

# 9) Toepassingen die een kritische reactietijd vereisen, moeten grondig worden getest op prestaties. Prestatietesten is een cruciaal onderdeel van veel toepassingen. In Handboek Testen, dit wordt het meest genegeerd door testers vanwege een gebrek aan het vereiste grote datavolume bij prestatietests.

Ontdek hoe u de prestaties van uw applicatie kunt testen. Als het niet mogelijk is om handmatig testgegevens te maken, schrijf dan enkele basisscripts om testgegevens voor prestatietests te maken of vraag de ontwikkelaars om er een voor u te schrijven.

# 10) Programmeurs zouden hun eigen code niet moeten testen. Zoals besproken in ons vorige post , zou basis Unit Testing van ontwikkelde applicaties voldoende moeten zijn voor ontwikkelaars om de applicatie voor testers vrij te geven. Maar jij (tester) moet de ontwikkelaars niet dwingen het product vrij te geven om te testen.

Laat ze hun eigen tijd nemen. Iedereen, van lead tot manager, weet wanneer de module / update wordt vrijgegeven om te testen en ze kunnen de testtijd dienovereenkomstig inschatten. Dit is een typische situatie in een Behendig projectomgeving.

verschil tussen kwaliteitscontrole en borging

# 11) Ga verder dan het testen van vereisten. Test de applicatie voor wat deze niet mag doen.

# 12) Tijdens het uitvoeren van regressietesten gebruik de vorige buggrafiek (Buggrafiek - aantal gevonden bugs in de tijd voor verschillende modules). Deze module-gewijze buggrafiek kan handig zijn om het meest waarschijnlijke buggedeelte van de applicatie te voorspellen.

# 13) Noteer de nieuwe termen, concepten die u leert tijdens het testen. Houd een tekstbestand open tijdens het testen van een applicatie. Noteer de voortgang van het testen en observaties in het. Gebruik deze opmerkingen in het notitieblok bij het voorbereiden van het definitieve testrapport. Deze goede gewoonte zal u helpen om een ​​volledig ondubbelzinnig testrapport en vrijgavedetails te verstrekken.

# 14) Vaak brengen testers of ontwikkelaars wijzigingen aan in de codebasis voor de te testen applicatie. Dit is een vereiste stap in de ontwikkel- of testomgeving om uitvoering van de live transactieverwerking te vermijden, zoals bij bankprojecten.

Noteer al dergelijke codewijzigingen die zijn gedaan voor testdoeleinden en zorg er op het moment van de definitieve release voor dat u al deze wijzigingen hebt verwijderd uit de uiteindelijke client-side implementatiebestandsbronnen.

# 15) Houd ontwikkelaars uit de buurt van de testomgeving. Dit is een stap die nodig is om eventuele configuratiewijzigingen te detecteren die ontbreken in het release- of implementatiedocument. Soms brengen ontwikkelaars enkele wijzigingen in de systeem- of applicatieconfiguratie aan, maar vergeten ze deze te vermelden in de implementatiestappen.

Als de ontwikkelaars geen toegang hebben tot de testomgeving, zullen ze dergelijke wijzigingen niet per ongeluk in de testomgeving aanbrengen en kunnen deze ontbrekende dingen op de juiste plaats worden vastgelegd.

# 16) Het is een goede gewoonte om betrek testers vanaf de softwarevereiste en ontwerpfase zelf. Op deze manier kunnen testers kennis opdoen over de betrouwbaarheid van applicaties, wat resulteert in een gedetailleerde testdekking. Als u niet wordt gevraagd om deel uit te maken van deze ontwikkelingscyclus, kunt u een verzoek indienen bij uw leidinggevende of manager om uw testteam te betrekken bij alle besluitvormingsprocessen of vergaderingen.

# 17) Testteams zouden dat moeten doen deel de beste testmethoden , ervaring met de andere teams in hun organisatie.

# 18) Verhoog uw gesprek met de ontwikkelaars om meer te weten over het product. Maak waar mogelijk face-to-face communicatie om geschillen snel op te lossen en misverstanden te voorkomen.

Maar ook als u de vereiste begrijpt of een geschil oplost, zorg er dan voor dat u dezelfde overschreven communicatiemethoden communiceert als e-mails. Bewaar niets verbaal.

# 19) Ren niet Geen tijd meer om testtaken met hoge prioriteit uit te voeren. Geef prioriteit aan uw testwerk van hoge naar lage prioriteit en plan uw werk dienovereenkomstig. Analyseer alle bijbehorende risico's om prioriteit te geven aan uw werk.

# 20) Schrijf een duidelijke, beschrijvende, ondubbelzinnige Bug report ​ Geef niet alleen de bugsymptomen maar ook het effect van de bug en alle mogelijke oplossingen.

Vergeet niet dat testen een creatieve en uitdagende taak is. Ten slotte hangt het allemaal af van uw vaardigheid en ervaring met betrekking tot hoe u deze uitdaging aanpakt.

Terug naar jou:

Het delen van uw eigen testervaring, tips of testgeheimen in de onderstaande opmerkingen zal dit artikel zeker interessanter en nuttiger maken !!

Laat ons uw mening weten / suggesties over dit artikel.

Aanbevolen literatuur

^