Cum se scriu cazuri de testare: ultimul ghid cu exemple

how write test cases

În acest tutorial practic aprofundat despre Cum să scriu cazuri de testare, am acoperit detaliile despre ceea ce este un caz de testare, definiția sa standard și tehnicile de proiectare a cazurilor de testare.

Ce este un caz de testare?

Un caz de testare are componente care descriu intrarea, acțiunea și un răspuns așteptat, pentru a determina dacă o caracteristică a unei aplicații funcționează corect.

Un caz de testare este un set de instrucțiuni despre „CUM” pentru a valida un anumit obiectiv / țintă de testare, care atunci când este urmat ne va spune dacă comportamentul așteptat al sistemului este satisfăcut sau nu.

Lista tutorialelor acoperite în această serie de teste de scriere a cazurilor:

Cum se scrie:

Tutorial nr. 1: Ce este un caz de testare și cum se scriu cazuri de testare (acest tutorial)
Tutorial nr. 2: Exemplu de șablon de caz de testare cu exemple (Descărcare) (trebuie citit)
Tutorial # 3: Scrierea cazurilor de testare din documentul SRS
Tutorial # 4: Cum se scriu cazuri de testare pentru un scenariu dat
Tutorial # 5: Cum să te pregătești pentru scrierea cazurilor de testare
Tutorial nr. 6: Cum se scriu cazuri de testare negative

Exemple:

Tutorial nr. 7: 180+ exemple de cazuri de testare pentru aplicații web și desktop
Tutorial # 8: Peste 100 de scenarii de testare gata de executare (listă de verificare)

Tehnici de scriere:

Tutorial # 9: Graficul cauzei și efectului - Tehnica de scriere dinamică a cazurilor de testare
Tutorial # 10: Tehnica de testare a tranziției de stat
Tutorial # 11: Tehnica de testare a matricei ortogonale
Tutorial # 12: Tehnica de ghicit a erorilor
Tutorial # 13: Tabelul de validare a câmpului (FVT) Tehnica de proiectare a testului

Test de caz vs. scenarii de testare:

Tutorial # 14: Cazuri de testare vs. scenarii de testare
Tutorial # 15: Diferența dintre planul de testare, strategia de testare și cazul de testare

Automatizare:

Tutorial # 16: Cum se selectează cazuri de testare corecte pentru testarea automată
Tutorial # 17: Cum se traduce cazuri de testare manuale în scripturi de automatizare

Instrumente de gestionare a testelor:

Tutorial # 18: Cele mai bune instrumente de gestionare a testelor
Tutorial # 19: TestLink pentru gestionarea cazurilor de testare
Tutorial # 20: Crearea și gestionarea cazurilor de testare utilizând HP Quality Center
Tutorial # 21: Executarea cazurilor de testare folosind ALM / QC

Cazuri specifice domeniului:

Tutorial nr. 22: Cazuri de testare pentru aplicații ERP
Tutorial # 23: JAVA Aplicarea cazurilor de testare
Tutorial # 24: Analiza valorii limită și partiționarea echivalenței

Să continuăm cu primul tutorial din această serie.

Instrumente recomandate:

Înainte de a continua procesul de scriere a cazurilor de testare, vă recomandăm să descărcați acest instrument de gestionare a cazurilor de testare. Acest lucru vă va ușura procesul de scriere a cazurilor de test menționat în acest tutorial:

# 1) TestRail

=> Descărcați instrumentul de gestionare a cazurilor de testare TestRail

# 2) TestMonitor

Management de test online de nivel superior. Revoluționar ușor.

TestMonitor este un instrument complet de gestionare a testelor pentru fiecare organizație. O abordare simplă, intuitivă a testării. Indiferent dacă implementați software de întreprindere, aveți nevoie de QA, construiți o aplicație de calitate sau aveți nevoie doar de o mână de ajutor în proiectul dvs. de testare, TestMonitor vă oferă acoperire.

=> Vizitați site-ul web TestMonitor

Ce veți învăța:

• Ce este un caz de testare și cum se scriu cazuri de testare?
  • De ce scriem teste?
  • Cum se scriu cazuri de testare?
  • Formatul de bază al declarației cazului de testare
• Sfaturi pentru testele de scriere
  • • # 1) Păstrați-l simplu, dar nu prea simplu; face complex, dar nu prea complex:
    • # 2) După documentarea cazurilor de testare, revizuiți o dată ca Tester:
    • # 3) Legați și ușurați testerii:
    • # 4) Fii colaborator:
    • # 5) Nu uitați niciodată utilizatorul final:
• Cum să obțineți excelența în documentarea cazurilor de testare
  • Sfaturi și trucuri utile
    • # 1) Documentul dvs. de testare este în formă bună?
    • # 2) Nu uitați să acoperiți cazurile negative
    • # 3) Faceți pași de testare atomică
    • # 4) Prioritizează testele
    • # 5) Secvența contează
    • # 6) Adăugați Timestamp și numele testerului la comentarii
    • # 7) Includeți detalii despre browser
    • # 8) Păstrați două foi separate - „Bugs” și „Summary” în document
• Cum NU să scrieți teste
  • 3 Cele mai frecvente probleme în cazurile de testare
    • # 1) Etape compozite
    • # 2) Comportamentul aplicației este luat ca comportament așteptat
    • # 3) Condiții multiple într-un singur caz
• Cum să îmbunătățim eficiența cazului de testare
  • Colecție de documente pentru scrierea testelor
  • Exemplu real
  • Document de caz de testare
  • Colectarea datelor de testare
• Importanța standardizării cazurilor de testare
  • Motive pentru reutilizarea cazurilor de testare
  • Ce este un test standard în testarea web?
  • Concluzie
  • Lectură recomandată

Ce este un caz de testare și cum se scriu cazuri de testare?

A scrie cazuri eficiente este o abilitate. Și îl puteți învăța din experiența și cunoștințele aplicației testate.

Pentru instrucțiuni de bază despre cum să scrieți testele, vă rugăm să verificați următorul videoclip:

Resursele de mai sus ar trebui să ne ofere elementele de bază ale procesului de scriere a testului.

Nivelurile procesului de scriere a testului:

• Nivelul 1: În acest nivel, veți scrie fișierul cazuri de bază din specificația disponibilă și documentația utilizatorului.
• Nivelul 2: Acesta este etapa practică în care cazurile de scriere depind de fluxul funcțional și de sistem al aplicației.
• Nivelul 3: Aceasta este etapa în care veți grupa unele cazuri și scrieți o procedură de testare . Procedura de testare nu este altceva decât un grup de cazuri mici, poate maximum 10.
• Nivelul 4: Automatizarea proiectului. Acest lucru va reduce la minimum interacțiunea umană cu sistemul și, astfel, QA se poate concentra pe funcționalitățile actualizate în prezent pentru a testa, mai degrabă decât să rămână ocupat cu testarea de regresie.

De ce scriem teste?

Obiectivul de bază al scrierii cazurilor este pentru a valida acoperirea testului unei cereri.

Dacă lucrați în orice organizație CMMi, atunci standardele de testare sunt urmate mai îndeaproape. Scrierea cazurilor aduce un fel de standardizare și minimizează abordarea ad-hoc în testare.

Cum se scriu cazuri de testare?

Câmpuri:

• ID-ul cazului de test
• Unitate de testat: Ce trebuie verificat?
• Ipoteze
• Date de testare: Variabile și valorile lor
• Pașii de executat
• rezultat asteptat
• Rezultat actual
• Trecut picat
• Comentarii

Formatul de bază al declarației cazului de testare

Verifica
Folosind (numele instrumentului, numele etichetei, dialogul etc)
Cu (condiții)
La (ceea ce este returnat, arătat, demonstrat)

Verifica: Folosit ca primul cuvânt al enunțului de testare.
Folosind: Pentru a identifica ceea ce este testat. Puteți utiliza „introducerea” sau „selectarea” aici în loc să utilizați în funcție de situație.

Pentru orice aplicație, trebuie să acoperiți toate tipurile de teste ca:

• Cazuri funcționale
• Cazuri negative
• Valori limită

În timp ce scrii toate acestea TC-urile ar trebui să fie simple și ușor de înțeles .

************************************************

Sfaturi pentru testele de scriere

Una dintre cele mai frecvente și majore activități ale unui software Tester (persoană SQA / SQC) este de a scrie scenarii și cazuri de testare.

Există câțiva factori importanți și critici care sunt legați de această activitate majoră. Să vedem mai întâi o privire de ansamblu asupra acestor factori.

Factori importanți implicați în procesul de scriere:

a) TC-urile sunt predispuse la revizuire și actualizare periodică:

Trăim într-o lume în continuă schimbare și același lucru este valabil și pentru software. Schimbările cerințelor software au un impact direct asupra cazurilor. Ori de câte ori cerințele sunt modificate, TC-urile trebuie actualizate.

Cu toate acestea, nu numai schimbarea cerinței poate provoca revizuirea și actualizarea TC. În timpul executării TC, multe idei apar în minte și pot fi identificate multe condiții ale unui singur TC. Toate acestea determină o actualizare a TC-urilor și uneori duce chiar la adăugarea de TC noi.

Mai mult, în timpul testării de regresie, mai multe corecții și / sau valuri necesită revizuire sau noi TC.

b) TC-urile sunt predispuse la distribuție între testeri care vor executa aceste:

Desigur, există cu greu o astfel de situație în care un singur tester execută toate TC-urile. În mod normal, există mai mulți testeri care testează diferite module ale unei singure aplicații. Deci, TC-urile sunt împărțite între testeri în funcție de domeniile lor deținute ale aplicației supuse testului.

Unele TC care sunt legate de integrarea aplicației pot fi executate de mai multe testere, în timp ce celelalte TC-uri pot fi executate numai de un singur tester.

c) TC-urile sunt predispuse la grupare și lot:

Este normal și obișnuit ca TC-urile care aparțin unui singur scenariu de test să solicite de obicei executarea lor într-o anumită secvență specifică sau sub forma unui grup. Pot exista anumite condiții prealabile ale unui TC care solicită executarea altor TC înainte de a rula singur.

În mod similar, conform logicii de afaceri a AUT, un singur TC poate contribui la mai multe condiții de testare și o singură condiție de testare poate consta din mai multe TC.

d) TC au tendința de interdependență:

Acesta este, de asemenea, un comportament interesant și important al TC care indică faptul că pot fi interdependenți unul de celălalt. De la aplicații medii la mari, cu logică de afaceri complexă, această tendință este mai vizibilă.

Cea mai clară zonă a oricărei aplicații în care acest comportament poate fi cu siguranță observat este interoperabilitatea între diferite module ale aceleiași aplicații sau chiar diferite. Pur și simplu vorbind, oriunde diferitele module, o singură aplicație sau mai multe aplicații sunt interdependente, același comportament se reflectă și în TC.

e) TC-urile sunt predispuse la distribuție între dezvoltatori (în special în mediul de dezvoltare bazat pe teste):

Un fapt important despre TC este că acestea nu trebuie utilizate numai de testeri. În cazul normal, când un bug este în curs de remediere de către dezvoltatori, aceștia folosesc indirect TC pentru a remedia problema. În mod similar, dacă se urmărește dezvoltarea bazată pe test, atunci TC-urile sunt utilizate direct de dezvoltatori pentru a-și construi logica și a acoperi toate scenariile din codul lor care sunt abordate de TC-uri.

Sfaturi pentru a scrie teste eficiente:

Ținând cont de cei 5 factori de mai sus, Iată câteva sfaturi pentru a scrie TC eficiente.

Să începem!!!

# 1) Păstrați-l simplu, dar nu prea simplu; face complex, dar nu prea complex:

Această afirmație pare un paradox. Dar, promit că nu este așa. Păstrați toți pașii TC-urilor atomici și preciși. Menționați pașii cu secvența corectă și maparea corectă la rezultatele așteptate. Cazul de testare trebuie să fie auto-explicativ și ușor de înțeles. Aceasta este ceea ce vreau să fac simplu.

Acum, a face din acesta un mijloc complex de integrare a acestuia cu Planul de testare și alte TC. Consultați celelalte TC, artefacte relevante, GUI etc., acolo unde și când este necesar. Dar, faceți acest lucru într-un mod echilibrat. Nu faceți un tester să se deplaseze înainte și înapoi în teancul de documente pentru a finaliza un singur scenariu de testare.

Pe de altă parte, nici măcar nu lăsați testerul să documenteze aceste TC într-un mod foarte compact. În timp ce scrieți TC, amintiți-vă întotdeauna că dvs. sau altcineva va trebui să le revizuiți și să le actualizați.

# 2) După documentarea cazurilor de testare, revizuiți o dată ca Tester:

Nu vă gândiți niciodată că treaba s-a încheiat după ce ați scris ultimul TC al scenariului de testare. Mergeți la început și examinați toate TC-urile o dată, dar nu cu mentalitatea unui scriitor TC sau a Planificatorului de testare. Examinați toate TC-urile cu mintea unui tester. Gândiți rațional și încercați să vă rulați TC-urile.

Evaluează toate etapele și vezi dacă le-ai menționat clar într-un mod ușor de înțeles și rezultatele așteptate sunt în armonie cu acei pași.

Asigurați-vă că date de testare specificat în TC este fezabil nu numai pentru testerii reali, ci este și în funcție de mediul în timp real. Asigurați-vă că nu există niciun conflict de dependență între TC și verificați dacă toate referințele la alte TC / artefacte / GUI sunt corecte. În caz contrar, testerii ar putea avea mari probleme.

# 3) Legați și ușurați testerii:

Nu lăsați datele testelor pe testere. Oferiți-le o gamă de intrări, în special în cazul în care trebuie efectuate calcule sau comportamentul aplicației este dependent de intrări. Le puteți permite să decidă valorile articolelor de date de testare, dar nu le dați niciodată libertatea de a alege ele însele datele de testare.

Deoarece, în mod intenționat sau neintenționat, ei pot utiliza aceleași date de testare din nou și din nou, iar unele date importante de testare pot fi ignorate în timpul executării TC-urilor.

Păstrați testerii în largul lor, organizând TC-urile în funcție de categoriile de testare și zonele conexe ale unei aplicații. În mod clar, instruiți și menționați care TC sunt interdependente și / sau în loturi. De asemenea, indicați în mod explicit care TC sunt independente și izolate, astfel încât testerul să își poată gestiona activitatea generală în consecință.

În acest moment, s-ar putea să fiți interesat să citiți despre analiza valorii la graniță, care este o strategie de proiectare a cazurilor de test care este utilizată în testarea cutiei negre. Clic Aici pentru a afla mai multe despre asta.

# 4) Fii colaborator:

Nu acceptați niciodată FS sau Documentul de proiectare așa cum este. Sarcina ta nu este doar să treci prin FS și să identifici scenariile de testare. Fiind o resursă QA, nu ezitați niciodată să contribuiți la afaceri și să dați sugestii dacă credeți că ceva poate fi îmbunătățit în aplicație.

Sugerați și dezvoltatorilor, în special în mediul de dezvoltare bazat pe TC. Sugerează listele drop-down, controalele calendarului, lista de selecție, butoanele radio de grup, mesaje mai semnificative, atenționări, solicitări, îmbunătățiri legate de utilizare etc.

Fiind un QA, nu doar testați, ci faceți diferența!

# 5) Nu uitați niciodată utilizatorul final:

Cel mai important factor de interes este „Utilizatorul final”, care va folosi în cele din urmă aplicația. Deci, nu-l uitați niciodată în orice etapă a scrierii TC. De fapt, utilizatorul final nu trebuie ignorat în nicio etapă a SDLC. Cu toate acestea, accentul meu de până acum este legat doar de subiectul meu.

Deci, în timpul identificării scenariilor de testare, nu treceți cu vederea niciodată acele cazuri care vor fi utilizate în cea mai mare parte de către utilizator sau cazurile care sunt critice pentru afaceri, chiar dacă sunt mai puțin utilizate. Păstrați-vă în locul utilizatorului final și apoi parcurgeți toate TC și judecați valoarea practică a executării tuturor TC-urilor documentate.

************************************************

Cum să obțineți excelența în documentarea cazurilor de testare

Fiind un tester de software, cu siguranță veți fi de acord cu mine că a veni cu un document de testare perfect este o sarcină dificilă.

Lăsăm întotdeauna unele posibilități de îmbunătățire în domeniul nostru Documentația cazului de testare . Uneori, nu suntem în măsură să oferim o acoperire de 100% a testului prin TC și, uneori, șablonul de testare nu este la înălțime sau ne lipsește asigurarea unei bune lizibilități și claritate testelor noastre.

În calitate de tester, ori de câte ori vi se cere să scrieți documentația de testare, nu începeți doar într-un mod ad-hoc. Este foarte important să înțelegeți scopul scrierii cazurilor de testare cu mult înainte de a lucra la procesul de documentare.

Testele ar trebui să fie întotdeauna clare și lucide. Acestea trebuie scrise într-un mod care să ofere testerului ușurința de a efectua testarea completă, urmând pașii definiți în fiecare dintre teste.

În plus, documentul cazului de testare ar trebui să conțină câte cazuri este necesar pentru a furniza complet acoperirea testului . De exemplu , ar trebui să încercați să acoperiți testarea pentru toate scenariile posibile care pot apărea în cadrul aplicației software.

Ținând cont de punctele de mai sus, permiteți-mi să vă duc acum printr-un tur despre Cum să atingeți excelența în documentarea testelor.

Sfaturi și trucuri utile

Aici, vă voi oferi câteva îndrumări utile care vă pot ajuta în documentația de testare a celorlalți.

# 1) Documentul dvs. de testare este în formă bună?

Cel mai bun și mai simplu mod de a vă organiza documentul de testare este împărțindu-l în mai multe secțiuni utile. Împărțiți întregul test în mai multe scenarii de testare. Apoi împărțiți fiecare scenariu în mai multe teste. În cele din urmă, împărțiți fiecare caz în mai mulți pași de testare.

Dacă utilizați Excel, documentați fiecare caz de testare pe o foaie separată a registrului de lucru în care fiecare caz de testare descrie un flux complet de testare.

# 2) Nu uitați să acoperiți cazurile negative

În calitate de tester de software, trebuie să vă gândiți în afara casetei și să profitați de toate posibilitățile pe care le are aplicația dvs. Noi, ca testeri, trebuie să verificăm dacă orice încercare neautentică de a intra în software sau orice date nevalide care să circule în aplicație ar trebui să fie oprite și raportate.

cum se folosește un fișier torrent după descărcare

Astfel, un caz negativ este la fel de important ca un caz pozitiv. Asigurați-vă că pentru fiecare scenariu pe care îl aveți două cazuri de testare - unul pozitiv și unul negativ . Cel pozitiv ar trebui să acopere debitul intenționat sau normal, iar cel negativ ar trebui să acopere debitul neintenționat sau excepțional.

# 3) Faceți pași de testare atomică

Fiecare etapă de testare ar trebui să fie una atomică. Nu ar trebui să existe alte sub-pași. Cu cât este mai simplu și mai clar un pas de testare, cu atât ar fi mai ușor să continuați testarea.

# 4) Prioritizează testele

De multe ori avem termene stricte pentru a termina testarea unei aplicații. În acest caz, este posibil să ratăm testarea unora dintre funcționalitățile și aspectele importante ale software-ului. Pentru a evita acest lucru, ar trebui să etichetați o prioritate cu fiecare test în timp ce îl documentați.

Puteți utiliza orice codificare pentru definirea priorității unui test. În general, este mai bine să utilizați oricare dintre cele 3 niveluri, înalt, mediu și scăzut , sau 1, 50 și 100. Deci, atunci când aveți un calendar strict, ar trebui să finalizați mai întâi toate testele cu prioritate ridicată și apoi să treceți la testele cu prioritate medie și mică.

De exemplu - pentru un site de cumpărături, verificarea refuzului de acces pentru o încercare nevalidă de conectare la aplicație poate fi un caz cu prioritate ridicată, verificarea afișării produselor relevante pe ecranul utilizatorului poate fi un caz cu prioritate medie și verificarea culorii textului afișat pe butoanele ecranului pot fi un test cu prioritate redusă.

# 5) Secvența contează

Confirmați dacă secvența de pași din test este absolut corectă. O secvență greșită de pași poate duce la confuzie. De preferință, pașii ar trebui să definească, de asemenea, întreaga secvență de la intrarea în aplicație până la ieșirea din aplicație pentru un anumit scenariu care este testat.

# 6) Adăugați Timestamp și numele testerului la comentarii

Poate exista un caz în care testați o aplicație, cineva face modificări în paralel cu aceeași aplicație sau cineva poate actualiza aplicația după terminarea testării. Acest lucru duce la o situație în care rezultatele testului dvs. pot varia în funcție de timp.

Deci, este întotdeauna mai bine să adăugați un timestamp cu numele testerului în comentariile de testare, astfel încât un rezultat al testului (promovat sau eșuat) să poată fi atribuit stării unei aplicații în acel moment. Alternativ, puteți avea un „ Data executării ’Coloană adăugată separat la cazul testului, care va identifica în mod explicit marca de timp a testului.

# 7) Includeți detalii despre browser

După cum știți, dacă este o aplicație web, rezultatele testelor pot diferi în funcție de browserul pe care este executat testul. Pentru ușurința altor testeri, dezvoltatori sau oricine examinează documentul de testare, ar trebui să adăugați numele și versiunea browserului în carcasă, astfel încât defectul să poată fi reprodus cu ușurință.

# 8) Păstrați două foi separate - „Bugs” și „Summary” în document

Dacă vă documentați într-un Excel, atunci primele două foi ale registrului de lucru ar trebui să fie Rezumat și Bug-uri. Foaia de rezumat ar trebui să rezume scenariul de testare, iar foaia de erori ar trebui să enumere toate problemele întâmpinate în timpul testării. Semnificația adăugării acestor două foi este că va oferi o înțelegere clară a testării cititorului / utilizatorului documentului.

Deci, atunci când timpul este restricționat, aceste două foi se pot dovedi foarte utile pentru a oferi o imagine de ansamblu asupra testării.

Documentul de testare ar trebui să ofere cea mai bună acoperire posibilă a testului, lizibilitate excelentă și ar trebui să urmeze un singur format standard.

Putem obține excelența în documentația de testare, ținând cont doar de câteva sfaturi esențiale, cum ar fi organizarea documentului de caz de testare, prioritizarea TC, având totul în ordine corespunzătoare, inclusiv toate detaliile obligatorii pentru a executa un TC și oferind pași de test clar și lucizi etc. așa cum s-a discutat mai sus.

************************************************

Cum NU să scrieți teste

Ne petrecem cea mai mare parte a timpului scriind, examinând, executând sau întreținând acestea. Este destul de regretabil faptul că testele sunt și cele mai predispuse la erori. Diferențele de înțelegere, practicile de testare a organizației, lipsa de timp etc. sunt câteva dintre motivele pentru care adesea vedem teste care lasă mult de dorit.

Există o mulțime de articole pe site-ul nostru despre acest subiect, dar aici vom vedea Cum NU se scriu cazuri de testare - câteva sfaturi care vor fi esențiale în crearea unor teste distinctive, de calitate și eficiente.

Să citim mai departe și vă rugăm să rețineți că aceste sfaturi sunt destinate atât testerilor noi, cât și celor experimentați.

3 Cele mai frecvente probleme în cazurile de testare

1. Pași compuși
2. Comportamentul aplicației este luat ca comportament așteptat
3. Condiții multiple într-un singur caz

Aceste trei trebuie să fie pe lista mea de top 3 cu probleme frecvente în procesul de scriere a testului.

Ceea ce este interesant este că acestea se întâmplă atât cu testeri noi, cât și cu experți și continuăm să urmăm aceleași procese eronate, fără să ne dăm seama că câteva măsuri simple pot remedia lucrurile cu ușurință.

Să ajungem la el și să discutăm fiecare în detaliu:

# 1) Etape compozite

În primul rând, ce este un pas compozit?

De exemplu, dați indicații de la punctul A la punctul B: dacă spuneți că „Mergeți la locul XYZ și apoi la ABC”, acest lucru nu va avea mult sens, deoarece aici ne găsim gândindu-ne - „Cum ajungeți la XYZ în primul rând ”- începând cu„ Virați la stânga de aici și mergeți 1 milă, apoi virați la dreapta pe Rd. 11 pentru a ajunge la XYZ ”ar putea obține rezultate mai bune.

Aceleași reguli se aplică și testelor și pașilor săi.

De exemplu Scriu un test pentru Amazon.com - plasați o comandă pentru orice produs.

Următorii sunt pașii mei de testare (Notă: scriu doar pașii și nu toate celelalte părți ale testului, cum ar fi rezultatul scontat etc.)

la . Lansați Amazon.com
b . Căutați un produs introducând cuvântul cheie / numele produsului în câmpul „Căutare” din partea de sus a ecranului.
c . Din rezultatele căutării afișate, alegeți primul.
d . Faceți clic pe Adăugați în coș pe pagina cu detalii despre produs.
este . Verificați și plătiți.
f . Verificați pagina de confirmare a comenzii.

Acum, puteți identifica care dintre acestea este un pas compozit? Pasul drept (e)

Amintiți-vă, testele sunt întotdeauna despre „Cum” să testați, deci este important să scrieți exact pașii „Cum să faceți check-out și să plătiți” în test.

Prin urmare, cazul de mai sus este mai eficient atunci când este scris ca mai jos:

la . Lansați Amazon.com
b . Căutați un produs introducând cuvântul cheie / numele produsului în câmpul „Căutare” din partea de sus a ecranului.
c . Din rezultatele căutării afișate, alegeți primul.
d . Faceți clic pe Adăugați în coș pe pagina cu detalii despre produs.
este . Faceți clic pe Checkout în pagina coșului de cumpărături.
f . Introduceți informațiile CC, expediere și informații de facturare.
g . Faceți clic pe Verificare.
h . Verificați pagina de confirmare a comenzii.

Prin urmare, un pas compozit este cel care poate fi descompus în mai multe etape individuale. Data viitoare când scriem teste, să fim cu toții atenți la această parte și sunt sigur că veți fi de acord cu mine că facem acest lucru mai des decât ne dăm seama.

# 2) Comportamentul aplicației este luat ca comportament așteptat

Tot mai multe proiecte trebuie să facă față acestei situații în aceste zile.

Lipsa documentației, programarea extremă, ciclurile de dezvoltare rapidă sunt câteva motive care ne obligă să ne bazăm pe aplicație (o versiune mai veche sau cam așa) pentru a scrie testele sau pentru a ne baza testarea. Ca întotdeauna, aceasta este o practică proastă dovedită - nu întotdeauna cu adevărat.

Este inofensiv atâta timp cât păstrați o minte deschisă și păstrați așteptarea că - „AUT ar putea fi defect”. Numai când nu credeți că este, lucrurile funcționează prost. Ca întotdeauna, vom lăsa exemplele să vorbească.

Dacă următoarea este pagina pentru care scrieți / proiectați pașii de testare:

Cazul 1:

Dacă pașii mei de testare sunt după cum urmează:

1. Lansați site-ul de cumpărături.
2. Faceți clic pe Expediere și returnare- Rezultatul așteptat: Pagina de expediere și returnare este afișată cu „Puneți informațiile aici” și un buton „Continuați”.

Apoi, acest lucru este incorect.

Cazul 2:

1. Lansați site-ul de cumpărături.
2. Faceți clic pe Expediere și returnare.
3. În caseta de text „Introduceți numărul comenzii” prezentă în acest ecran, introduceți nr.
4. Faceți clic pe Continuare - Rezultatul așteptat: sunt afișate detaliile comenzii legate de expediere și returnări.

Cazul 2 este un caz de testare mai bun, deoarece, deși aplicația de referință se comportă incorect, o luăm doar ca orientare, facem cercetări suplimentare și scriem comportamentul așteptat conform funcționalității corecte anticipate.

Linia de fund: Aplicarea ca referință este o comandă rapidă rapidă, dar vine cu propriile pericole. Atâta timp cât suntem atenți și critici, produce rezultate uimitoare.

# 3) Condiții multiple într-un singur caz

Încă o dată, să învățăm de la Exemplu .

Aruncați o privire la pașii de test de mai jos: Următorii pași de test în cadrul unui test pentru o funcție de conectare.

A. Introduceți detalii valide și faceți clic pe Trimiteți.
b. Lăsați câmpul Nume utilizator gol. Faceți clic pe Trimiteți.
c. Lăsați câmpul de parolă gol și faceți clic pe Trimiteți.
d. Alegeți un nume de utilizator / parola deja conectat și faceți clic pe Trimiteți.

Ceea ce trebuia să fie 4 cazuri diferite se combină într-unul singur. S-ar putea să vă gândiți - Ce este în neregulă cu asta? Economisesc o mulțime de documentație și ce pot face în 4, o fac în 1 - nu este grozav? Ei bine, nu chiar. Motive?

Citiți mai departe:

• Ce se întâmplă dacă una dintre condiții eșuează - trebuie să marcăm întregul test ca „eșuat”. Dacă marcăm întregul caz ca „eșuat”, înseamnă că toate cele 4 condiții nu funcționează, ceea ce nu este cu adevărat adevărat.
• Testele trebuie să aibă un flux. De la condiția prealabilă la pasul 1 și prin toate etapele. Dacă urmez acest caz, la pasul (a), dacă are succes, voi fi conectat la pagina, unde opțiunea „autentificare” nu mai este disponibilă. Deci, când ajung la pasul (b) - unde urmează să testeze numele de utilizator? Vedeți, fluxul este rupt.

Prin urmare, scrie teste modulare . Sună ca o mulțime de muncă, dar tot ce trebuie pentru tine este să separi lucrurile și să folosești cei mai buni prieteni Ctrl + C și Ctrl + V pentru a lucra pentru noi. :)

************************************************

Cum să îmbunătățim eficiența cazului de testare

Testerii de software ar trebui să își scrie testele din etapa anterioară a ciclului de viață al dezvoltării software-ului, cel mai bine în faza de cerințe software.

Managerul de testare sau un manager de control al calității trebuie să colecteze și să pregătească documentele maxime posibile, conform listei de mai jos.

Colecție de documente pentru scrierea testelor

# 1) Documentul privind cerințele utilizatorului

Este un document care enumeră procesul de afaceri, profilurile utilizatorilor, mediul utilizatorului, interacțiunea cu alte sisteme, înlocuirea sistemelor existente, cerințe funcționale, cerințe nefuncționale, cerințe de licențiere și instalare, cerințe de performanță, cerințe de securitate, utilizare și cerințe concurente etc. .,

# 2) Document de caz de utilizare a afacerii

Acest document detaliază utilizare caz scenariul cerințelor funcționale din perspectiva afacerii. Acest document acoperă actorii de afaceri (sau sistemul), obiectivele, condițiile prealabile, condițiile ulterioare, fluxul de bază, fluxul alternativ, opțiunile, excepțiile de la fiecare flux de afaceri al sistemului conform cerințelor.

# 3) Document de cerințe funcționale

Acest document detaliază cerințele funcționale ale fiecărei caracteristici pentru sistemul conform cerințelor.

În mod normal, documentul de cerințe funcționale servește ca un depozit comun atât pentru echipa de dezvoltare și testare, cât și pentru părțile interesate din proiect, inclusiv pentru clienți pentru cerințele angajate (uneori înghețate), care ar trebui tratate ca fiind cel mai important document pentru orice dezvoltare de software.

# 4) Plan de proiect software (opțional)

Un document care descrie detaliile proiectului, obiectivele, prioritățile, etapele, activitățile, structura organizației, strategia, monitorizarea progresului, analiza riscurilor, ipotezele, dependențele, constrângerile, cerințele de instruire, responsabilitățile clientului, programul proiectului etc.,

# 5) QA / Plan de testare

Acest document detaliază sistemul de management al calității, standardele de documentare, mecanismul de control al modificărilor, modulele și funcționalitățile critice, sistemul de gestionare a configurației, planurile de testare, urmărirea defectelor, criteriile de acceptare etc.

planul de testare documentul este utilizat pentru a identifica caracteristicile care urmează să fie testate, caracteristicile care nu trebuie testate, testarea alocărilor echipei și interfața acestora, cerințele resurselor, programul de testare, scrierea testelor, acoperirea testelor, livrabilele testelor, condiții prealabile pentru executarea testului, raportarea și urmărirea erorilor mecanism, valori de testare etc.,

Exemplu real

Să vedem cum să scriem în mod eficient cazuri de testare pentru un ecran „Login” familiar și simplu, conform figurii de mai jos. abordarea testării va fi aproape la fel chiar și pentru ecranele complexe cu mai multe informații și caracteristici critice.

# 1) Prima abordare pentru orice proces de testare a cazului va fi obținerea unui prototip de ecran (sau cadre de sârmă) ca mai sus, dacă este disponibil. Este posibil să nu fie disponibil pentru unele dintre funcționalități și depinde de criticitatea proiectării unui prototip în etapele anterioare de dezvoltare.

Dar, dacă un SRS Document (Specificația cerințelor software) document este disponibil pentru proiect, majoritatea prototipurilor de ecran sunt dezvoltate de echipa de proiect. Acest tip de ecran simplifică activitatea testerului și crește eficiența testelor.

#Două) Apoi, specificații cerințe funcționale . Depinde de procesul de organizare, va fi disponibil într-o suită de documente multiple.

Deci, decideți cel mai bun document pentru scrierea cazurilor, fie că poate fi un document de cerințe ale utilizatorului, fie specificații de cerințe funcționale (sau chiar un document SRS dacă echipa de testare poate înțelege confortabil), care va oferi un flux funcțional complet caracteristică de testat.

# 3) Odată ce prototipul ecranului și specificațiile funcționale sunt la locul lor, testerul ar trebui să înceapă să scrie cazurile cu următoarea abordare și criterii.

• Teste UI :Comenzile / câmpurile care sunt vizibile pentru utilizator. Există controale statice și controale dinamice disponibile pentru caracteristica care urmează să fie testată. De exemplu, în ecranul de conectare de mai sus, textele „Nume utilizator și parolă” sunt câmpuri statice care nu necesită interacțiune cu utilizatorul, doar pentru afișarea numai a textului.

• Cazuri funcționale :Pe de altă parte, butonul de conectare și hyperlinkurile (ați uitat parola? & Înregistrare) sunt câmpuri dinamice care necesită interacțiunea utilizatorului făcând clic pe controale, care vor face o acțiune ulterior.

• Cazuri de baze de date :Odată ce utilizatorul introduce numele de utilizator și parola, testele pot fi scrise pentru a verifica baza de date aferentă, dacă numele de utilizator și parola sunt verificate în baza de date și tabelul potrivit și, de asemenea, utilizatorul are permisiunea de a se conecta la aplicația testată.
  

• Teste de proces :Acest lucru este legat de procesul (nu de acțiunile asociate cu comenzile vizibile disponibile pe ecran) asociat cu caracteristica și funcționalitatea. De exemplu, făcând clic pe linkul Uitat parola din ecranul de mai sus, este posibil să trimiteți un e-mail utilizatorului. Deci, poate că un e-mail trebuie testat pentru procesul și confirmarea corespunzătoare.

4) În cele din urmă, păstrați „ Mantra BAOE ', mijloace i) Debitul de bază ii) Flux alternativ iii) Opțiuni și iv) Excepții pentru acoperirea completă a fluxului funcțional și a caracteristicii de testat. Fiecare concept trebuie aplicat testelor pozitive și negative.

De exemplu, să vedem abordarea simplă BAOE pentru exemplul de ecran de conectare de mai sus.

• Debit de bază: Introduceți calea URL a autentificării în orice browser și introduceți informațiile necesare și conectați-vă la aplicație.
• Flux alternativ: Instalați aplicația pe un dispozitiv mobil și introduceți informațiile necesare și conectați-vă la aplicație.
• Opțiuni: Care sunt opțiunile disponibile pentru a accesa același ecran de conectare? De exemplu, după conectarea la aplicație, făcând clic pe „Deconectare” poate apărea același ecran sau, dacă expirarea sesiunii sau sesiunea a expirat, utilizatorul poate ajunge la ecranul de conectare.
• Excepții: Care sunt excepțiile dacă testele mele sunt negative? De exemplu, dacă sunt introduse acreditări greșite în ecranul de autentificare, dacă utilizatorul va primi un mesaj de eroare sau nu va fi asociată nicio acțiune.

Cu toate aceste informații în mână, să începem să scriem TC-urile pentru ecranul de conectare, într-un format cu acoperire și trasabilitate completă și cu informații detaliate. Secvența logică și numerotarea identificării „ ID caz de testare ” va fi foarte util pentru un istoric de execuție rapidă a identificării cazurilor de testare.

Citește și=> 180 de eșantioane de testare gata de utilizare pentru aplicații web și desktop.

Document de caz de testare

Notă : Coloanele de testare nu se limitează la eșantionul de test de mai jos, care poate fi păstrat într-o foaie Excel pentru a avea câte coloane este necesar pentru o matrice de trasabilitate completă, și anume, prioritatea, scopul testării, tipul de testare, locația de captură de ecran a erorilor etc.,

Citește și=> Eșantion de șablon de caz de testare cu exemple.

Pentru ușurința simplității și lizibilității acestui document, permiteți-ne să scriem detaliile de mai jos pașii de reproducere, comportamentul așteptat și efectiv al testelor pentru ecranul de conectare.

Notă : Adăugați coloana Comportament actual la sfârșitul acestui șablon.

Colectarea datelor de testare

Când se scrie cazul de testare, cea mai importantă sarcină pentru orice tester este colectarea datelor de testare. Această activitate este omisă și trecută cu vederea de mulți testeri, presupunând că cazurile de testare pot fi executate cu niște date eșantion sau date fictive și pot fi alimentate atunci când datele sunt într-adevăr necesare. Aceasta este o concepție greșită critică conform căreia se introduc date de eșantion sau date de intrare din memoria minții în momentul executării cazurilor de testare.

Dacă datele nu sunt colectate și actualizate în documentul de testare în momentul scrierii testelor, testerul ar petrece anormal mai mult timp pentru a colecta datele în momentul executării testului. Datele testelor trebuie colectate atât pentru cazurile pozitive, cât și pentru cele negative din toată perspectiva fluxului funcțional al caracteristicii. Documentul de caz de utilizare a afacerii este foarte util în această situație.

Găsiți un eșantion de date de testare pentru testele scrise mai sus, care, la rândul lor, vor fi utile cu privire la cât de eficient putem colecta datele care ne vor ușura munca în momentul executării testului.

************************************************

Importanța standardizării cazurilor de testare

În această lume aglomerată, nimeni nu poate face lucruri repetitive zi de zi cu același nivel de interes și energie. Mai ales, nu sunt pasionat să fac aceeași sarcină din nou și din nou la locul de muncă. Îmi place să gestionez lucrurile și să economisesc timp. Oricine din IT ar trebui să fie așa.

Toate companiile IT execută diferite tipuri de proiecte. Aceste proiecte pot fi fie bazate pe produse, fie pe servicii. Dintre aceste proiecte, majoritatea lucrează în jurul site-urilor web și testarea site-ului web . Vestea bună despre asta este că toate site-urile web au multe asemănări. Și, dacă site-urile web sunt pentru același domeniu, au și câteva caracteristici comune.

Întrebarea care mă deranjează întotdeauna este că: „Dacă majoritatea aplicațiilor sunt similare, de exemplu: cum ar fi site-urile de vânzare cu amănuntul, care au fost testate de o mie de ori înainte,„ De ce trebuie să scriem de la zero cazuri de testare pentru încă un alt site de vânzare cu amănuntul? ” Nu va economisi o grămadă de timp extragând scripturile de testare existente care au fost folosite pentru a testa un site de vânzare cu amănuntul anterior?

Sigur, ar putea exista câteva mici modificări pe care ar trebui să le facem, dar, în general, este mai ușor, eficient, economisește timp și bani și, prin urmare, ajută întotdeauna la menținerea nivelurilor de interes ale testerilor ridicate. Cui îi place să scrie, să revizuiască și să mențină în mod repetat aceleași cazuri de testare, nu? Reutilizarea testelor existente poate rezolva acest lucru într-o mare măsură, iar clienții dvs. vor găsi și acest lucru inteligent și logic.

În mod logic, am început să extrag scripturile existente din proiecte similare bazate pe web, am făcut modificări și le-am analizat rapid. De asemenea, am folosit codarea culorilor pentru a arăta modificările care au fost făcute, astfel încât recenzorul să se poată concentra doar asupra părții care a fost modificată.

Motive pentru reutilizarea cazurilor de testare

# 1) Cele mai multe zone funcționale ale unui site web sunt aproape - autentificare, înregistrare, adăugare în coș, listă de dorințe, plată, opțiuni de expediere, opțiuni de plată, conținutul paginii produsului, vizualizate recent, produse relevante, facilități de cod promoțional etc.

#Două) Majoritatea proiectelor sunt doar îmbunătățiri sau modificări ale funcționalității existente.

# 3) Sistemele de gestionare a conținutului care definesc sloturile pentru încărcarea imaginilor cu moduri statice și dinamice sunt, de asemenea, comune pentru toate site-urile web.

# 4) Site-urile de vânzare cu amănuntul au CSR Sistemul (Serviciul Clienți).

# 5) Sistemul backend și aplicația de depozit care utilizează JDA sunt, de asemenea, utilizate de toate site-urile web.

# 6) Conceptul de cookie-uri, expirarea timpului și securitatea sunt comune.

# 7) Proiectele bazate pe web sunt frecvent predispuse la modificări ale cerințelor.

# 8) tipuri de testare necesare sunt comune ca browserul testarea compatibilității , test de performanta , testarea securității

Vedeți, există o mulțime de lucruri comune și similare.

Acestea fiind spuse că reutilizarea este calea de urmat, uneori modificările în sine pot sau nu să dureze mai mult sau mai puțin timp. Uneori se poate simți că este mai bine să începi de la zero decât să modifici atât de mult.

Acest lucru poate fi ușor gestionat prin crearea unui set de cazuri de testare standard pentru fiecare dintre funcționalitățile comune.

Ce este un test standard în testarea web?

• Creați cazuri de test care sunt complete - pași, date, variabile etc. Acest lucru vă va asigura că datele / variabila care nu sunt similare pot fi înlocuite pur și simplu atunci când este necesar un caz de test similar.
• Criteriile de intrare și ieșire ar trebui definite în mod corespunzător.
• Pașii modificabili sau declarația din pași ar trebui să fie evidențiați într-o altă culoare pentru a găsi și înlocui rapid.
• Limbajul utilizat pentru crearea cazului de test standard ar trebui să fie generic.
• Toate caracteristicile fiecărui site web ar trebui acoperite în cazurile de testare.
• Numele cazurilor de testare ar trebui să fie numele funcționalității sau caracteristicii pe care o acoperă cazul de testare. Acest lucru va facilita găsirea cazului de testare din set.
• Dacă există un eșantion de bază sau standard sau un fișier GUI sau o captură de ecran a caracteristicii, atunci acesta trebuie atașat cu pașii relevanți.

Utilizând sfaturile de mai sus, puteți crea un set de scripturi standard și le puteți utiliza cu modificări mici sau necesare pentru diferite site-uri web.

Aceste cazuri de testare standard pot fi, de asemenea, automatizate, dar din nou concentrarea pe reutilizare este întotdeauna un plus. De asemenea, dacă automatizare se bazează pe o interfață grafică, reutilizarea scripturilor pe mai multe adrese URL sau site-uri este ceva ce personal nu am găsit niciodată eficient.

Utilizarea unui set standard de cazuri de testare manuală pentru diferite site-uri web cu modificări minore este cel mai bun mod de a efectua testarea site-ului web. Tot ce avem nevoie este să creăm și să menținem cazurile de testare cu standarde și utilizare adecvate.

Concluzie

Îmbunătățirea eficienței cazului de testare nu este un termen pur și simplu definit, dar este un exercițiu și poate fi realizat printr-un proces maturizat și o practică regulată.

Echipa de testare nu ar trebui să se plictisească să se implice în îmbunătățirea unor astfel de sarcini, deoarece este cel mai bun instrument pentru realizări mai mari în lumea calității, acest lucru este dovedit în multe dintre organizațiile de testare din întreaga lume cu privire la proiecte critice de misiune și aplicații complexe.

Sper că ați fi dobândit cunoștințe imense cu privire la conceptul de cazuri de testare. Urmăriți seria noastră de tutoriale pentru a afla mai multe despre cazurile de testare și nu ezitați să vă exprimați gândurile în secțiunea de comentarii de mai jos!

Următorul tutorial

Lectură recomandată

• Testarea funcțională Vs testarea non-funcțională
• Ghid de testare a portabilității cu exemple practice
• Tipuri de testare software: diferite tipuri de testare cu detalii
• Cele mai bune instrumente de testare software 2021 (Instrumente de automatizare a testelor de calitate)
• Testarea alfa și testarea beta (un ghid complet)
• Ce este testarea sistemului - Un ghid pentru începători
• Certificare de testare ISTQB Exemplu de lucrări de întrebare cu răspunsuri
• Cum se scrie un raport săptămânal de testare a software-ului