model de testare este o structură logică care descrie funcționalitatea sistemului și/sau comportamentul utilizatorului, în funcție de care sunt generate cazurile de testare. Construirea unui model de testare începe cu construirea unei structuri, iar apoi structura aprobată este completată cu cazuri de testare.

Modelele sunt de obicei construite pe baza cerințelor și/sau a comportamentului așteptat al sistemului. Construirea unui model de testare și gestionarea acestuia este potrivită pentru sisteme mari cu o logică complexă de afaceri și este dificil de aplicat proiectelor care utilizează metodologii agile, deoarece costul menținerii procesului de management al modelului de testare și de asigurare a calității va fi prea mare.

Managementul modelului de testare este un proces care controlează acoperirea modelului de testare, calitatea scenariilor care descriu modelul de testare și actualizarea acestuia.

Managementul modelului de testare este un proces continuu ciclu de viață produs.

Testați acoperirea modelului

Pentru a controla acoperirea tuturor cerințelor, puteți utiliza matrice de urmărire care determină acoperirea cerințelor prin scenarii de testare (vezi exemplul).
Înainte de a fi descrise cazurile de testare, structura modelului de testare trebuie aprobată cu clientul.

Calitatea scenariului

Pentru a gestiona calitatea scenariilor, este necesar să se controleze nu numai nivelul de descriere a cazurilor de testare, ci și calitatea acestora.

Înainte de a începe descrierea cazurilor de testare, este necesar să se definească cerințele pentru fiecare nivel de descriere și criteriile pentru calitatea descrierii cazurilor de testare.

Niveluri posibile de descriere a cazurilor de testare:

La al 4-lea nivel, acordul cu clientul poate fi înlocuit prin acord.

Criteriile de calitate pentru descrierea cazurilor de testare pot fi următoarele:

• Cazurile de testare trebuie scrise conform cerințelor

Testarea este procesul prin care se verifică dacă un produs îndeplinește cerințele sale. Prin urmare, în partea descrierii generale a cazului de testare (în sistemele de urmărire a testelor, termenul „Rezumat” este de obicei folosit), este necesar să se facă referire la o cerință specifică împreună cu fragmente din textul cerințelor. Astfel, pentru toți participanții la proiect va fi clar pe baza a ceea ce este scris acest caz de testare.

• Utilizați condiții preliminare detaliate

Cum să economisești timp pe cazurile de testare?

Setați reguli de formatare pentru toate cazurile de testare. Deci, cazul de testare va fi ușor de înțeles și de citit pentru orice participant la proiect. De exemplu, pe un proiect, puteți introduce următoarele reguli:

• Toți parametrii de intrare trebuie marcați cu roșu.
• Toate scripturile trebuie evidențiate cu albastru,
• Toate numele butoanelor, câmpurilor, blocurilor sunt scrise cu caractere cursive și aldine.
• Sunt subliniate pasaje importante.
• Fiecare pas efectuat trebuie să aibă un rezultat așteptat.
• Fiecare pas din cazurile de testare ar trebui să descrie o singură acțiune și rezultatul așteptat. Acestea. atunci când se primește un caz de testare eșuat într-un anumit pas, ar trebui să fie clar clar asupra acțiunii care a apărut eroarea.
• Rezultatul așteptat trebuie să fie clar.

Cazurile de testare trebuie să fie clare, de ex. ar trebui să fie redactate și formulate astfel încât să nu permită o interpretare ambiguă, dar să fie înțelese clar de toți participanții.

Dacă scrierea cazurilor de testare durează mult, atunci poate apărea o situație când un specialist încetează să-și vadă greșelile. Pentru a face acest lucru, aveți nevoie de o privire laterală - aici vă va ajuta revizuire încrucișată. Această etapă este recomandată a fi efectuată în cazurile în care dezvoltarea unui model de testare este prelungită în timp și este lungă în timp. De exemplu, când dezvoltarea scenariilor de testare durează mai mult de 1 lună.

Procesul de control al calității scenariului poate fi efectuat cu controlul modelului de testare- șablon special pregătit.

Testează actualizarea modelului

Este necesar să se actualizeze în mod regulat modelul de testare și cazurile de testare în sine pentru conformitatea cu cerințele, precum și revizuirea priorităților cazurilor de testare.

Pentru actualizare puteți menține o „Matrice de cerințe”(Matricea de urmărire a cerințelor): după fiecare modificare a unei anumite cerințe, o selecție a tuturor scenariilor de testare legate de această cerință este realizată din sistemul de urmărire a testelor și actualizată.

Testarea controalelor modelului:

• șină de testare
• link de testare
• Jira+Zephyr
• Microsoft Test Manager (MTM)
• excela

Testarea este un proces care vă permite să evaluați calitatea produsului produs. Un produs software de înaltă calitate trebuie să îndeplinească cerințele pentru acesta, atât funcționale, cât și nefuncționale. PS trebuie să implementeze toate VI-urile necesare și să nu aibă defecte - diferențe între proprietățile din viața reală sau comportamentul față de cele necesare. În plus, PS-ul trebuie să aibă proprietăți de fiabilitate (nu trebuie să existe blocări, blocări etc.), securitate, să ofere performanța dorită, să fie ușor de utilizat, extensibil etc. Astfel, testarea este un proces de analiză a PS-ului , care vizează identificarea defectelor și evaluarea proprietăților PS.

Obiectivele procesului de testare

Scopul testării este de a evalua calitatea produs software prin

• Verificări ale interacțiunii componentelor;
• Verificarea integrării corecte a componentelor;
• Verificarea acurateței implementării tuturor cerințelor și identificarea defectelor.

Caracteristicile procesului de testare în RUP

Testarea este un proces iterativ efectuat în toate fazele ciclului de viață. Testarea începe de la început stadiul inițial identificarea cerințelor pentru un produs viitor și integrarea strânsă cu sarcinile curente. Pentru fiecare iterație, se determină scopul testării și metodele de realizare a acestuia. La sfârșitul fiecărei iterații, se stabilește în ce măsură a fost atins acest obiectiv, dacă sunt necesare teste suplimentare, dacă principiile și instrumentele de testare ar trebui schimbate.

Fiecare defect constatat este inregistrat in baza de date a proiectului cu o descriere a situatiei in care a fost constatat. Analistul stabilește dacă acesta este un defect real și dacă este o repetare a unui defect descoperit anterior. Defectul găsit este atribuit o prioritate A indicând importanța remedierii. Proiectantul responsabil pentru dezvoltarea subsistemului, componentei sau clasei sau o altă persoană desemnată de manager, procedează la remedierea defectului. Ordinea în care sunt remediate defectele este guvernată de prioritățile acestora. Testerul repetă testele și este convins (sau nu) că defectul a fost remediat.

Dezvoltator de testare responsabil pentru planificarea, dezvoltarea și implementarea testelor. El creează un plan și un model de testare, proceduri de testare (vezi mai jos) și evaluează rezultatele testului.

tester (tester) responsabil pentru efectuarea testării sistemului. Responsabilitățile sale includ configurarea și executarea testelor, evaluarea performanței testelor, recuperarea din erori și înregistrarea defectelor detectate.

Artefacte

În timpul testării, sunt create următoarele documente:

Planul de testare– un document care definește strategia de testare în fiecare iterație. Conține o descriere a scopurilor și obiectivelor testării în iterația curentă, precum și a strategiilor care vor fi utilizate. Planul indică ce resurse vor fi necesare și oferă o listă de teste.

Model de testare este o reprezentare a ceea ce și cum va fi testat. Modelul include un set de sarcini de control, metode de testare, scenarii de testare și rezultate așteptate (cazuri de testare), scripturi de testare și descrieri ale interacțiunilor de testare.

• Sarcina de control– un set de date de testare, condiții de execuție a testului și rezultatele așteptate.
• Metoda de test– un document care să cuprindă instrucțiuni pentru înființarea și efectuarea sarcinilor de control, precum și pentru evaluarea rezultatelor obținute.
• Scriptul de testare- aceasta este o descriere simplificată a testului, inclusiv datele inițiale, condițiile și secvențele de acțiuni și rezultatele așteptate.
• Scriptul de testare este un program care este executat în timpul testării automate folosind instrumente de testare.
• Descrierea interacțiunii testului este o diagramă de secvențe sau cooperări care reflectă fluxul de mesaje ordonate în timp între componentele de testare și obiectul de testare.

Rezultatele testuluişi datele obţinute în timpul executării testelor.

Modelul volumului de muncă este utilizat pentru a modela funcțiile externe efectuate de utilizatorii finali, domeniul de aplicare al acelor funcții și volumul de muncă generat de acele funcții. Modelul este destinat efectuării testelor de sarcină și/sau de stres care simulează funcționarea sistemului în condiții reale.

Defecte- sunt descrieri ale faptelor de neconformitate a sistemului cu cerințele constatate în timpul testării. Sunt un tip de cereri de schimbare.

Lucrările de testare sunt efectuate în fiecare iterație în toate fazele, dar scopurile și obiectivele în diferite faze ale proiectului sunt semnificativ diferite.

Faza de intrare in proiect. În această fază, se efectuează pregătirea pentru testare. Include:

• Creați un plan de testare care să conțină cerințele și strategiile de testare. Se poate crea un singur plan pentru toate tipurile de testare (funcționale, de încărcare etc.) sau planuri separate pentru fiecare tip.
• Analiza domeniului de testare.
• Formularea criteriilor de calitate și finalizarea testării.
• Instalarea și pregătirea pentru funcționarea instrumentelor de testare.
• Formularea cerințelor pentru proiectul de dezvoltare PS, determinate de nevoile de testare.

Faza de dezvoltare.În iterațiile acestei faze, începe construcția modelului de testare și a artefactelor aferente. Deoarece modelul VI este deja prezent în această fază, puteți începe să proiectați scenarii de testare. În același timp, nu este recomandabil să se efectueze teste, deoarece, de obicei, nu există încă fragmente PS finalizate în această fază. Se desfășoară următoarele activități:

• Dezvoltarea scenariilor de testare.
• Crearea de scripturi de testare.
• Dezvoltarea sarcinilor de control.
• Dezvoltarea metodelor de testare.
• Dezvoltarea unui model de volum de muncă.

Faza de construcție.În această fază apar fragmente de sistem finalizate și prototipuri, care trebuie testate. În același timp, în aproape fiecare iterație, toate modulele sunt verificate (atât dezvoltate și testate anterior, cât și altele noi adăugate în iterația curentă). Testele aplicate în iterațiile anterioare sunt folosite și în iterațiile ulterioare pentru testarea regresiei, adică pentru a verifica dacă funcționalitatea sistemului implementată anterior este păstrată în noua iterație. Se desfășoară următoarele activități:

• Creați un plan de testare pentru fiecare iterație.
• Perfecţionarea şi adăugarea modelului de testare.
• Executarea testelor.
• Descrierea defectelor constatate.
• Descrierea rezultatelor testelor.
• Evaluarea rezultatelor testelor.

Pe baza rezultatelor testării, se fac modificări la codul programului pentru a elimina defectele identificate, după care testarea se repetă.

Faza de implementare.În iterațiile acestei faze, se efectuează testarea întregului PS ca produs software. Activitățile desfășurate sunt similare cu activitățile din faza anterioară. Detectarea defectelor determină necesitatea modificărilor și retestării. Procesul iterativ se repetă până când sunt îndeplinite criteriile de terminare a testului.

Rezultatele testelor sunt evaluate pe baza unor metrici de testare care permit determinarea calității PS testat și a procesului de testare în sine.

Suport instrumental

Deoarece procesul de testare iterativă implică mai multe repetări ale testelor, testarea manuală devine ineficientă și nu permite o evaluare amănunțită a calității produsului software. Acest lucru este valabil mai ales pentru testele de încărcare și de stres, unde trebuie să simulați volumul de muncă și să acumulați o cantitate semnificativă de date. Soluția este utilizarea instrumentelor care sprijină automatizarea compilării și executării testelor.

La fel ca procesul de dezvoltare, procesul de post-testare a software-ului urmează și o metodologie specifică. Prin metodologie, în acest caz, înțelegem diferitele combinații de principii, idei, metode și concepte la care apelezi în timp ce lucrezi la un proiect.

În prezent, există un număr destul de mare de abordări diferite ale testării, fiecare având propriile puncte de plecare, durata de execuție și metodele utilizate în fiecare etapă. Iar alegerea unuia sau altuia poate fi o provocare. În acest articol, vom analiza diferite abordări ale testării software-ului și vom vorbi despre caracteristicile lor principale pentru a vă ajuta să navigați în varietatea existentă.

Model cascadă (model liniar secvenţial al ciclului de viaţă al software-ului)

Modelul Waterfall este unul dintre cele mai vechi modele care poate fi folosit nu numai pentru dezvoltarea sau testarea software-ului, ci și pentru aproape orice alt proiect. A lui principiu de bază este ordinea succesivă în care sunt îndeplinite sarcinile. Aceasta înseamnă că putem trece la următorul pas de dezvoltare sau testare numai după ce cel anterior a fost finalizat cu succes. Acest model este potrivit pentru proiecte mici și este aplicabil numai dacă toate cerințele sunt clar definite. Principalele avantaje ale acestei metodologii sunt eficiență economică, ușurință în utilizare și gestionarea documentației.

Procesul de testare a software-ului începe după finalizarea procesului de dezvoltare. În această etapă, toate testele necesare sunt transferate de la unități la testarea sistemului pentru a controla funcționarea componentelor atât individual, cât și în ansamblu.

Pe lângă avantajele menționate mai sus, această abordare a testării are și dezavantajele sale. Există întotdeauna posibilitatea de a găsi erori critice în procesul de testare. Acest lucru poate duce la necesitatea de a schimba complet una dintre componentele sistemului sau chiar întreaga logică a proiectului. Dar o astfel de sarcină este imposibilă în cazul modelului cascadă, deoarece revenirea la pasul anterior din această metodologie este interzisă.

Aflați mai multe despre modelul cascadei din articolul anterior..

V-Model (model de verificare și validare)

La fel ca modelul cu cascadă, modelul V se bazează pe o secvență directă de pași. Principala diferență dintre aceste două metodologii este că testarea în acest caz este planificată în paralel cu etapa de dezvoltare corespunzătoare. Conform acestei metodologii de testare software, procesul începe imediat ce cerințele sunt definite și devine posibilă începerea testării statice, adică. verificare și revizuire, ceea ce evită eventualele defecte ale software-ului în etapele ulterioare. Este creat un plan de testare adecvat pentru fiecare nivel de dezvoltare software care definește rezultatele așteptate și criteriile de intrare și ieșire pentru acel produs.

Schema acestui model arată principiul împărțirii sarcinilor în două părți. Cele legate de proiectare și dezvoltare sunt plasate în stânga. Sarcinile legate de testarea software-ului sunt situate în partea dreaptă:

Principalii pași ai acestei metodologii pot varia, dar de obicei includ următoarele:

• Etapă definițiile cerințelor. Testarea de acceptare aparține acestei etape. Sarcina sa principală este de a evalua gradul de pregătire a sistemului pentru utilizarea finală.
• Etapa în care design la nivel înalt sau design la nivel înalt (HDL). Această fază se referă la testarea sistemului și include o evaluare a conformității cu cerințele pentru sistemele integrate.
• Faza de proiectare detaliată(Detailed Design) este paralel cu faza de testare a integrării, în timpul căreia sunt testate interacțiunile dintre diferitele componente ale sistemului
• După etapa de codificareÎncepe un alt pas important - testarea unitară. Este foarte important să vă asigurați că comportamentul părților și componentelor individuale ale software-ului este corect și îndeplinește cerințele.

Singurul dezavantaj al metodologiei de testare luate în considerare este lipsa soluțiilor gata făcute care ar putea fi aplicate pentru a scăpa de defectele software-ului găsite în faza de testare.

model incremental

Această metodologie poate fi descrisă ca un model de testare software cu mai multe cascade. Fluxul de lucru este împărțit într-un număr de cicluri, fiecare dintre acestea fiind, de asemenea, împărțit în module. Fiecare iterație adaugă anumite funcționalități software-ului. Creșterea constă din trei cicluri:

1. design și dezvoltare
2. testarea
3. implementare.

În acest model, este posibilă dezvoltarea simultană a diferitelor versiuni ale produsului. De exemplu, prima versiune poate fi în faza de testare, în timp ce a doua versiune este în dezvoltare. A treia versiune poate trece prin faza de proiectare în același timp. Acest proces poate continua până la sfârșitul proiectului.

Evident, această metodologie necesită detectarea cât mai rapidă a numărului maxim posibil de erori în software-ul testat. La fel și faza de implementare, care necesită confirmarea gradului de pregătire a produsului pentru a fi livrat utilizatorului final. Toți acești factori cresc semnificativ greutatea cerințelor de testare.

Comparativ cu metodologiile anterioare, modelul incremental are mai multe avantaje importante. Este mai flexibil, modificările cerințelor duc la costuri mai mici, iar procesul de testare a software-ului este mai eficient, deoarece testarea și depanarea sunt mult mai ușoare prin utilizarea unor iterații mici. Cu toate acestea, merită remarcat faptul că cost total tot mai mare decât în ​​cazul modelului în cascadă.

model în spirală

Modelul Spiral este o metodologie de testare software care se bazează pe o abordare incrementală și prototipare. Este format din patru etape:

1. Planificare
2. Analiza de risc
3. Dezvoltare
4. Nota

Imediat după încheierea primului ciclu, începe al doilea. Testarea software-ului începe în etapa de planificare și continuă până în etapa de evaluare. Principalul avantaj al modelului în spirală este că primele rezultate ale testelor apar imediat după rezultatele testelor din a treia etapă a fiecărui ciclu, ceea ce ajută la asigurarea evaluării corecte a calității. Cu toate acestea, este important să rețineți că acest model poate fi destul de scump și nu este potrivit pentru proiecte mici.

Deși acest model este destul de vechi, rămâne util atât pentru testare, cât și pentru dezvoltare. În plus, obiectivul principal multe metodologii de testare a software-ului, inclusiv modelul spiralat, s-au schimbat recent. Le folosim nu doar pentru a găsi defecte în aplicații, ci și pentru a afla motivele care le-au cauzat. Această abordare ajută dezvoltatorii să lucreze mai eficient și să remedieze rapid erorile.

Citiți mai multe despre modelul spirală în postarea anterioară de blog..

Agil

Metodologia agilă de dezvoltare a software-ului și testarea software-ului pot fi descrise ca un set de abordări axate pe utilizarea dezvoltării interactive, formarea dinamică a cerințelor și asigurarea implementării acestora ca urmare a interacțiunii constante în cadrul unei organizații auto-organizate. grup de lucru. Cele mai multe metodologii agile de dezvoltare a software-ului urmăresc să minimizeze riscul prin dezvoltare în iterații scurte. Unul dintre principiile principale ale acestei strategii flexibile este capacitatea de a răspunde rapid la eventualele schimbări, mai degrabă decât să se bazeze pe o planificare pe termen lung.

Aflați mai multe despre Agile(notă – articol în engleză).

Programare extremă (XP, Programare extremă)

Extreme Programming este un exemplu de dezvoltare agilă a software-ului. O caracteristică distinctivă a acestei metodologii este „programarea în pereche”, o situație în care un dezvoltator lucrează la cod, în timp ce colegul său revizuiește constant codul scris. Procesul de testare a software-ului este destul de important deoarece începe chiar înainte ca prima linie de cod să fie scrisă. Fiecare modul de aplicație ar trebui să aibă un test unitar, astfel încât majoritatea erorilor să poată fi remediate în etapa de codare. O altă proprietate distinctivă este că testul determină codul și nu invers. Aceasta înseamnă că o anumită bucată de cod poate fi considerată completă numai dacă toate testele trec. În caz contrar, codul este respins.

Principalele avantaje ale acestei metodologii sunt testarea constantă și lansările scurte, care ajută la asigurare calitate superioară cod.

Scrum

Scrum - Parte a metodologiei Agile, un cadru incremental iterativ creat pentru a gestiona procesul de dezvoltare software. Conform principiilor Scrum, echipa de testare ar trebui să fie implicată în următorii pași:

• Participarea la planificarea Scrum
• Suport pentru testarea unitară
• Testarea poveștii utilizatorului
• Colaborați cu clientul și proprietarul produsului pentru a determina criteriile de acceptare
• Furnizarea de testare automată

Mai mult, membrii QA ar trebui să fie prezenți la toate întâlnirile zilnice, ca și alți membri ai echipei, pentru a discuta despre ceea ce a fost testat și făcut ieri, ce va fi testat astăzi, precum și despre progresul general al testării.

În același timp, principiile metodologiei Agile în Scrum duc la apariția unor caracteristici specifice:

• Estimarea efortului necesar pentru fiecare poveste de utilizator este o necesitate
• Testerul trebuie să fie atent la cerințe, deoarece acestea se pot schimba tot timpul.
• Riscul de regresie crește odată cu modificările frecvente ale codului.
• Planificarea si executarea simultana a testelor
• Neînțelegere între membrii echipei în cazul în care cerințele clientului nu sunt complet clare

Aflați mai multe despre metodologia Scrum dintr-un articol anterior..

Concluzie

În concluzie, este important de menționat că astăzi practica utilizării uneia sau alteia metodologii de testare software implică o abordare multiversală. Cu alte cuvinte, nu trebuie să vă așteptați ca o singură metodologie să fie potrivită pentru toate tipurile de proiecte. Alegerea unuia dintre ele depinde de un număr mare de aspecte, precum tipul de proiect, cerințele clienților, termenele limită și multe altele. Din perspectiva testării software-ului, este obișnuit ca unele metodologii să înceapă testarea la începutul dezvoltării, în timp ce pentru altele este obișnuit să aștepte până când sistemul este complet.

Indiferent dacă aveți nevoie de ajutor pentru dezvoltarea sau testarea software-ului, o echipă dedicată de dezvoltatori și ingineri QA este gata de plecare.

Testarea serviciului web

Cel mai Cel mai bun mod evaluați dacă am testat bine produsul – analizați defectele ratate. Cele cu care se confruntă utilizatorii noștri, implementatorii, companiile. Puteți evalua multe din ele: ce nu am verificat suficient de amănunțit, ce zone ale produsului ar trebui să li se acorde mai multă atenție, care este procentul de omisiuni în general și care este dinamica modificărilor acestuia. Cu această metrică (poate cea mai comună în testare), totul este în regulă, dar... Când am lansat produsul și am aflat despre erorile ratate, s-ar putea să fie prea târziu: pe Habré a apărut un articol supărat despre noi, concurenții sunt răspândirea rapidă a criticilor, clienții și-au pierdut încrederea în noi, conducerea este nemulțumită.

Pentru a preveni acest lucru, de obicei încercăm să evaluăm calitatea testării în avans, înainte de lansare: cât de bine și cât de bine verificăm produsul? Ce domenii lipsesc atenția, unde sunt principalele riscuri, ce progrese? Și pentru a răspunde la toate aceste întrebări, evaluăm acoperirea testului.

De ce sa evaluezi?

Orice măsurători de evaluare sunt o pierdere de timp. În acest moment, puteți testa, începe erori, puteți pregăti autotestări. Ce beneficii magice obținem de la valorile de acoperire a testelor pentru a sacrifica timpul de testare?

1. Găsește-ți zonele slabe. Desigur, avem nevoie de asta? nu doar pentru a întrista, ci pentru a ști unde sunt necesare îmbunătățiri. Ce domenii funcționale nu sunt acoperite de teste? Ce nu am verificat? Unde sunt cele mai mari riscuri de lipsă de erori?
2. Rareori obținem o acoperire de 100% din rezultatele evaluării. Ce să îmbunătățim? Unde să mergem? Care este procentul acum? Cum îl putem crește cu orice sarcină? Cât de repede putem ajunge la 100? Toate aceste întrebări aduc transparență și claritate procesului nostru., iar răspunsurile la acestea sunt date de estimarea acoperirii.
3. Focalizarea atenției. Să presupunem că produsul nostru are aproximativ 50 de zone funcționale diferite. ieşind o nouă versiune, și începem să testăm pe primul dintre ele și găsim greșeli de scriere acolo și butoane care au mutat câțiva pixeli și alte fleacuri ... Și acum timpul pentru testare a trecut, iar această funcționalitate a fost testată în detaliu .. Și restul de 50? Evaluarea acoperirii ne permite să prioritizăm sarcinile pe baza realităților actuale și a termenelor limită.

Cum se evaluează?

Înainte de a implementa orice măsură, este important să decideți cum o veți folosi. Începeți prin a răspunde exact la această întrebare - cel mai probabil, veți înțelege imediat cum este cel mai bine să o calculați. Și voi împărtăși în acest articol doar câteva exemple și experiența mea despre cum se poate face acest lucru. Nu pentru a copia orbește soluții - ci pentru ca imaginația ta să se bazeze pe această experiență, gândindu-te la o soluție ideală pentru tine.

Evaluarea acoperirii cerințelor prin teste

Să presupunem că ai analiști în echipa ta și nu își petrec timpul în zadar. timpul de lucru. Pe baza rezultatelor muncii lor, au fost create cerințe în RMS (Requirements Management System) - HP QC, MS TFS, IBM Doors, Jira (cu pluginuri suplimentare), etc. În acest sistem, ei fac cerințe care corespund cerințelor pentru cerințe (scuze pentru tautologie). Aceste cerințe sunt atomice, trasabile, specifice... În general, condiții ideale pentru testare. Ce putem face într-un astfel de caz? Când utilizați o abordare scriptată, legați cerințele și testele. Facem teste în același sistem, facem o conexiune cerințe-test și în orice moment putem vedea un raport despre ce cerințe au teste, care nu, când au fost trecute aceste teste și cu ce rezultat.
Obținem o hartă de acoperire, acoperim toate cerințele neacoperite, toată lumea este fericită și mulțumită, nu ratăm greșelile...

Bine, hai să revenim la pământ. Cel mai probabil, nu aveți cerințe detaliate, nu sunt atomice, unele dintre cerințe sunt în general pierdute și nu există timp să documentați fiecare test, sau cel puțin fiecare a doua. Puteți să disperați și să plângeți, sau puteți admite că testarea este un proces compensator și, cu cât suntem mai rău cu analiza și dezvoltarea proiectului, cu atât mai mult ar trebui să încercăm noi înșine să compensăm problemele celorlalți participanți la proces. Să analizăm problemele separat.

Problemă: cerințele nu sunt atomice.

De asemenea, analiștii păcătuiesc uneori cu o salată în cap și, de obicei, acest lucru este plin de probleme cu întregul proiect. De exemplu, dezvoltați un editor de text și este posibil să aveți două cerințe în sistemul dvs. (printre altele): „formatarea html trebuie să fie acceptată” și „când deschideți un fișier cu un format neacceptat, o fereastră pop-up cu o întrebare trebuie să apară.” Câte teste sunt necesare pentru verificarea de bază a primei cerințe? Și pentru al 2-lea? Diferența de răspunsuri, cel mai probabil, este de aproximativ o sută de ori!!! Nu putem spune că, dacă există cel puțin 1 test la prima cerință, acesta este suficient - dar despre al 2-lea, cel mai probabil, complet.

Astfel, a avea un test de cerință nu ne garantează absolut nimic! Ce înseamnă statisticile noastre de acoperire în acest caz? Aproape nimic! Va trebui să decidem!

1. În acest caz, calculul automat al acoperirii cerințelor prin teste poate fi eliminat - încă nu are încărcare semantică.
2. Pentru fiecare cerință, începând cu cea mai mare prioritate, pregătim teste. La pregătire, analizăm ce teste vor fi necesare pentru această cerință, câte vor fi suficiente? Efectuăm o analiză completă a testului și nu lăsăm deoparte „există un singur test, dar bine”.
3. În funcție de sistemul folosit, exportăm/încărcăm teste la cerere și... testăm aceste teste! Sunt suficiente? În mod ideal, desigur, astfel de testare ar trebui efectuate cu un analist și un dezvoltator al acestei funcționalități. Imprimă testele, închide-ți colegii în sala de ședințe și nu-ți da drumul până nu spun „da, aceste teste sunt suficiente” (asta se întâmplă doar cu acordul scris, când aceste cuvinte sunt rostite pentru dezabonare, chiar și fără a analiza testele. În timpul unei discuții orale, colegii tăi vor revărsa o critică în cuvă, teste ratate, cerințe neînțelese etc. - acest lucru nu este întotdeauna plăcut, dar este foarte util pentru testare!)
4. După finalizarea testelor la cerere și convenirea asupra completității acestora, în sistem această cerință poate fi marcată cu statutul „acoperit de teste”. Această informație va însemna mult mai mult decât „există cel puțin 1 test aici”.

Desigur, un astfel de proces de acord necesită o mulțime de resurse și timp, mai ales la început, până când se dezvoltă practica. Prin urmare, efectuați numai cerințe cu prioritate înaltă și noi îmbunătățiri asupra acestuia. În timp, înăspriți restul cerințelor și toată lumea va fi fericită! Dar... și dacă nu există cerințe deloc?

Problemă: Nu există cerințe deloc.

Ei lipsesc din proiect, se discută oral, fiecare face ce vrea/poate și cum înțelege. Testăm la fel. Drept urmare, avem un număr mare de probleme nu numai la testare și dezvoltare, ci și implementarea inițială incorectă a caracteristicilor - ne doream ceva complet diferit! Aici pot sfătui opțiunea „definiți și documentați singur cerințele” și chiar am folosit această strategie de câteva ori în practica mea, dar în 99% din cazuri nu există astfel de resurse în echipa de testare - așa că să mergem mai puțin. mod intensiv în resurse:

1. Creați o listă de caracteristici. Sami! Sub formă de google-tablet, în format PBI în TFS - alegeți oricare, atâta timp cât nu este un format text. Mai trebuie să colectăm statusuri! Includem toate zonele funcționale ale produsului în această listă și încercăm să alegem un nivel general de descompunere (puteți scrie obiecte software, sau scripturi utilizator, sau module, sau pagini web, sau metode API, sau formulare de ecran .. .) - dar nu toate acestea deodată! UN SINGUR format de descompunere care vă va face mai ușor și mai clar să nu pierdeți lucruri importante.
2. Coordonam COMPLETEZA acestei liste cu analisti, dezvoltatori, business, in cadrul echipei noastre... Incearca sa faci totul pentru a nu pierde parti importante din produs! Cât de profund să analizezi depinde de tine. În practica mea, au existat doar câteva produse pentru care am creat peste 100 de pagini în tabel, iar acestea erau produse gigantice. Cel mai adesea, 30-50 de linii este un rezultat realizabil pentru o prelucrare atentă ulterioară. Într-o echipă mică fără analiști de testare dedicați Mai mult elementele fichelista ar fi prea greu de întreținut.
3. După aceea, trecem prin priorități și procesăm fiecare linie a listei de fișe ca în secțiunea de cerințe descrisă mai sus. Scriem teste, discutăm, cădem de acord asupra suficienței. Marcăm stările, pentru care caracteristică există suficiente teste. Obținem starea, progresul și extinderea testelor prin comunicarea cu echipa. Toată lumea este fericită!

Dar... Ce se întâmplă dacă cerințele sunt menținute, dar nu într-un format urmăribil?

Problemă: cerințele nu sunt urmăribile.

Există o cantitate imensă de documentație pe proiect, analiștii scriu cu o viteză de 400 de caractere pe minut, aveți specificații, specificații tehnice, instrucțiuni, referințe (cel mai adesea acest lucru se întâmplă la cererea clientului), iar toate acestea acționează ca cerințele și totul a fost pe proiect de mult timp. Confuz unde să căutați ce informații?
Repetând secțiunea anterioară, ajutând întreaga echipă să facă curățenie!

1. Creăm o listă de caracteristici (vezi mai sus), dar fără o descriere detaliată a cerințelor.
2. Pentru fiecare caracteristică, colectăm împreună link-uri către specificații tehnice, specificații, instrucțiuni și alte documente.
3. Mergem pe priorități, pregătim teste și cădem de acord asupra caracterului lor complet. Totul este la fel, doar că datorită combinării tuturor documentelor într-o singură placă creștem ușurința de acces la ele, stările transparente și consistența testelor. Până la urmă, totul este super și toată lumea este fericită!

Dar... Nu pentru mult timp... Se pare că în ultima săptămână, analiștii au actualizat 4 specificații diferite în funcție de solicitările clienților!!!

Problemă: cerințele se schimbă tot timpul.

Desigur, ar fi bine să testăm un sistem fix, dar produsele noastre sunt de obicei live. Clientul a cerut ceva, ceva s-a schimbat în legislația externă produsului nostru, iar pe undeva analiștii au găsit o eroare de analiză a anului trecut... Cerințele își trăiesc propria viață! Ce să fac?

1. Să presupunem că ați colectat deja link-uri către TK și specificații sub forma unei liste de caracteristici, PBI, cerințe, note Wiki etc. Să presupunem că aveți deja teste pentru aceste cerințe. Și acum, cerințele se schimbă! Aceasta ar putea însemna o schimbare în RMS sau o sarcină în TMS (Task Management System) sau o scrisoare prin poștă. Oricum, duce la același rezultat: testele tale sunt depășite! Sau pot fi irelevante. Aceasta înseamnă că necesită actualizare (acoperire prin teste versiune veche produsul nu este cumva considerat foarte mult, nu?)
2. În lista de caracteristici, în RMS, în TMS (Test Management System - testrails, sitechco, etc) testele trebuie marcate ca irelevante imediat și fără greșeală! În HP QC sau MS TFS, acest lucru se poate face automat la actualizarea cerințelor, iar într-o tabletă google sau wiki, va trebui să lăsați pixuri. Dar ar trebui să vedeți imediat: testele sunt irelevante! Aceasta înseamnă că așteptăm o re-cală completă: actualizați, reluați analiza testului, rescrieți testele, cădem de acord asupra modificărilor și numai după aceea marcați din nou caracteristica/cerința ca „acoperită de teste”.

În acest caz, obținem toate beneficiile evaluării acoperirii testului și chiar și în dinamică! Toată lumea este fericită!!! Dar…
Dar te-ai concentrat atât de mult pe lucrul cu cerințele, încât acum nu mai ai timp suficient nici pentru a testa sau a documenta testele. După părerea mea (și există loc pentru o dispută religioasă!) cerințele sunt mai importante decât testele și e mai bine așa! Cel puțin sunt în regulă, iar întreaga echipă este la curent, iar dezvoltatorii fac exact ceea ce este necesar. DAR NU ESTE TIMP DE DOCUMENTAREA TESTELOR!

Problemă: Nu este suficient timp pentru a documenta testele.

De fapt, sursa acestei probleme poate fi nu numai lipsa de timp, ci și alegerea ta destul de conștientă de a nu le documenta (nu ne place, evităm efectul pesticidului, produsul se schimbă prea des etc.). Dar cum se evaluează acoperirea testului în acest caz?

1. Mai aveți nevoie de cerințe ca cerințe complete sau ca o listă de caracteristici, așa că una dintre secțiunile de mai sus, în funcție de munca analiștilor la proiect, va fi în continuare necesară. Aveți o listă de cerințe/funcții?
2. Descriem și punem de acord verbal asupra unei scurte strategii de testare, fără a documenta teste specifice! Această strategie poate fi specificată într-o coloană de tabel, pe o pagină wiki sau într-o cerință din RMS și, din nou, trebuie convenită. Ca parte a acestei strategii, recenziile vor fi efectuate în moduri diferite, dar veți ști: când este ultima data testat si cu ce strategie? Și asta, vezi tu, nici nu este rău! Și toată lumea va fi fericită.

Dar… Ce altceva "dar"? Care???

Spuneți, vom ocoli orice și fie ca produsele de înaltă calitate să fie cu noi!

| Planificarea lecțiilor pentru anul școlar | Principalele etape ale modelării

Lectia 2
Principalele etape ale modelării

Studiind acest subiect, veți învăța:

Ce este modelarea;
- ce poate servi drept prototip pentru modelare;
- care este locul modelării în activitatea umană;
- care sunt principalele etape ale modelării;
- ce este un model de calculator;
Ce este un experiment pe calculator.

experiment pe calculator

Pentru a da viață noilor dezvoltări de design, pentru a introduce noi soluții tehnice în producție sau pentru a testa idei noi, este nevoie de un experiment. Un experiment este un experiment care este efectuat cu un obiect sau model. Constă în efectuarea unor acțiuni și determinarea modului în care eșantionul experimental reacționează la aceste acțiuni.

La școală, faci experimente la lecțiile de biologie, chimie, fizică, geografie.

Experimentele sunt efectuate atunci când se testează mostre de produse noi la întreprinderi. De obicei, în acest scop se folosește o configurație special creată, care face posibilă efectuarea unui experiment în condiții de laborator sau produsul real în sine este supus la tot felul de teste (un experiment la scară completă). Pentru a studia, de exemplu, proprietățile de performanță ale unei unități sau ansamblu, acesta este plasat într-un termostat, înghețat în camere speciale, testat pe suporturi de vibrații, scăpat etc. Este bine dacă este un ceas nou sau un aspirator - pierderea în timpul distrugerii nu este mare. Dacă este un avion sau o rachetă?

Experimentele de laborator și la scară reală necesită costuri mari de materiale și timp, dar semnificația lor, cu toate acestea, este foarte mare.

Cu dezvoltarea tehnologia calculatoarelor a apărut o nouă metodă unică de cercetare - un experiment pe calculator. În multe cazuri, studiile de simulare pe computer au venit să ajute, și uneori chiar să înlocuiască, probele experimentale și bancurile de testare. Etapa de realizare a unui experiment pe calculator include două etape: elaborarea unui plan de experiment și realizarea unui studiu.

Planul de experiment

Planul de experiment ar trebui să reflecte în mod clar succesiunea de lucru cu modelul. Primul pas într-un astfel de plan este întotdeauna testarea modelului.

Testarea este procesul de verificare a corectitudinii modelului construit.

Test - un set de date inițiale care vă permite să determinați corectitudinea construcției modelului.

Pentru a fi siguri de corectitudinea rezultatelor modelării obținute, este necesar: ​​♦ să verificați algoritmul dezvoltat pentru construirea modelului; ♦ asigurați-vă că modelul construit reflectă corect proprietățile originalului, care au fost luate în considerare în simulare.

Pentru a verifica corectitudinea algoritmului de construcție a modelului, se folosește un set de test de date inițiale, pentru care rezultatul final este cunoscut în prealabil sau predeterminat în alte moduri.

De exemplu, dacă utilizați formule de calcul în modelare, atunci trebuie să selectați mai multe opțiuni pentru datele inițiale și să le calculați „manual”. Acestea sunt elemente de testare. Când modelul este construit, testați cu aceleași intrări și comparați rezultatele simulării cu concluziile obținute prin calcul. Dacă rezultatele se potrivesc, atunci algoritmul este dezvoltat corect, dacă nu, este necesar să se caute și să se elimine cauza discrepanței lor. Este posibil ca datele de testare să nu reflecte deloc situația reală și să nu aibă conținut semantic. Cu toate acestea, rezultatele obținute în timpul procesului de testare vă pot determina să vă gândiți la schimbarea modelului informațional sau de semne original, în primul rând în acea parte a acestuia în care este stabilit conținutul semantic.

Pentru a vă asigura că modelul construit reflectă proprietățile originalului, care au fost luate în considerare în simulare, este necesar să selectați un exemplu de testare cu date sursă reale.

Efectuarea de cercetări

După testare, când aveți încredere în corectitudinea modelului construit, puteți trece direct la studiu.

Planul ar trebui să includă un experiment sau o serie de experimente care să îndeplinească obiectivele simulării. Fiecare experiment trebuie să fie însoțit de o înțelegere a rezultatelor, care servește drept bază pentru analizarea rezultatelor modelării și luarea deciziilor.

Schema de pregătire și desfășurare a unui experiment pe calculator este prezentată în Figura 11.7.

Orez. 11.7. Schema unui experiment pe calculator

Analiza rezultatelor simulării

Scopul final al modelării este de a lua o decizie, care ar trebui dezvoltată pe baza unei analize cuprinzătoare a rezultatelor simulării. Această etapă este decisivă - fie continui studiul, fie termini. Figura 11.2 arată că faza de analiză a rezultatelor nu poate exista autonom. Concluziile obținute contribuie adesea la o serie suplimentară de experimente și uneori la o schimbare a problemei.

Rezultatele testelor și experimentelor servesc drept bază pentru dezvoltarea unei soluții. Dacă rezultatele nu corespund obiectivelor sarcinii, înseamnă că au fost făcute greșeli în etapele anterioare. Aceasta poate fi fie o declarație incorectă a problemei, fie o construcție prea simplificată a unui model de informații, fie o alegere nereușită a unei metode sau a unui mediu de modelare, fie o încălcare a metodelor tehnologice la construirea unui model. Dacă sunt identificate astfel de erori, atunci modelul trebuie corectat, adică revenirea la una dintre etapele anterioare. Procesul se repetă până când rezultatele experimentului îndeplinesc obiectivele simulării.

Principalul lucru de reținut este că eroarea detectată este și rezultatul. După cum spune proverbul, înveți din greșelile tale. Marele poet rus A. S. Pușkin a mai scris despre asta:

O, câte descoperiri minunate avem
Pregătiți spiritul de iluminare
Și experiența, fiul greșelilor grele,
Și geniu, paradoxuri prietene,
Și șansa, Dumnezeu este inventatorul...

Controlați întrebările și sarcinile

1. Care sunt cele două tipuri principale de formulare a problemei de modelare.

2. În binecunoscuta „Cartea problemelor” de G. Oster, există următoarea problemă:

Vrăjitoarea rea, lucrând neobosit, transformă 30 de prințese în omizi pe zi. Câte zile îi va lua pentru a transforma 810 de prințese în omizi? Câte prințese pe zi ar trebui să fie transformate în omizi pentru a-și îndeplini treaba în 15 zile?
Ce întrebare poate fi atribuită tipului de „ce se va întâmpla dacă...”, și care – tipului de „cum se face astfel încât...”?

3. Enumerați cele mai cunoscute obiective ale modelării.

4. Formalizați problema jucăușă din „Cartea problemelor” a lui G. Oster:

Din două cabine situate la o distanță de 27 km unul de celălalt, doi câini luptători au sărit unul spre celălalt în același timp. Primul rulează cu o viteză de 4 km/h, iar al doilea - 5 km/h.
Cât va începe lupta?

5. Numiți cât mai multe caracteristici ale obiectului „pereche de pantofi”. Compuneți un model informațional al unui obiect în diferite scopuri:
■ alegerea încălțămintei pentru drumeții;
■ alegerea unei cutii de pantofi potrivite;
■ achiziționarea cremei de îngrijire a pantofilor.

6. Ce caracteristici ale unui adolescent sunt esențiale pentru o recomandare privind alegerea unei profesii?

7. De ce computerul este utilizat pe scară largă în simulare?

8. Numiți instrumentele de modelare pe computer cunoscute de dvs.

9. Ce este un experiment pe calculator? Dă un exemplu.

10. Ce este testarea modelului?

11. Ce erori se întâlnesc în procesul de modelare? Ce trebuie făcut când se găsește o eroare?

12. Ce este analiza rezultatelor simulării? Ce concluzii se trag de obicei?