Definiția testului de acceptare. Dezvoltarea documentației, producerea și testarea prototipurilor. Set de standarde pentru sisteme automate

De obicei, această testare este făcută de o altă echipă care repetă o mare parte din ceea ce este acoperit în testele automate de acceptare manual sau cu un alt instrument. Acest lucru se poate face deoarece testele de acceptare nu pot fi rulate cu ușurință în diferite medii sau echipa de dezvoltare nu poate înțelege cu ușurință ce fac testele, iar datele utilizate sunt ascunse în cod, ceea ce face dificilă găsirea sau modificarea. Ascunderea intenției unui test în cod face dificilă înțelegerea a ceea ce încearcă să facă testul.

De asemenea, înseamnă că membrii echipei non-tehnice nu pot contribui cu ușurință la testare, iar oamenii tehnici petrec mai mult timp pe codul de testare automatizat. Când testele trebuie refactorizate, ceea ce este inevitabil că separă intenția de mijloacele de implementare, vă puteți concentra pe refactorizarea implementării testului, mai degrabă decât pe ceea ce ar trebui să facă testul.

Separarea intenției, implementării și datelor

Mai jos este o diagramă care ilustrează ideea de a separa intenția, implementarea și datele. Mediul este, de asemenea, inclus, deoarece este important să înțelegeți în ce mediu se vor rula testele și, dacă este necesar, să schimbați datele și să rulați testul. Crearea unei intenții poate fi făcută de membrii echipei non-tehnice într-un limbaj care este independent de implementare. Acest lucru este important deoarece înseamnă că implementarea poate fi refactorizată fără a fi nevoie să se schimbe intenția testului. Este adevărat și invers; este posibil să se schimbe intenția unui test fără a afecta implementarea, cu condiția să existe o implementare care să satisfacă toate cuvintele din paragraful de intenție.

Dacă, în cel mai rău caz, decideți să aruncați întreaga implementare și să o luați de la capăt, puteți încă păstra intenția testului și, prin urmare, nu pierdeți cea mai importantă parte a testelor automate, ceea ce testele încearcă să facă. Datele trebuie, de asemenea, separate în intenții și implementări, făcând acest lucru datele pot fi specificate în test prin abstracție și apoi implementarea este eliminată. De exemplu, un test poate indica „Client de aur”, deoarece clientul este identificat, nu face parte din test, ci face parte din stratul de date.

Crearea stratului de date și abstracția datelor nu sunt tehnici noi; acestea sunt de obicei utilizate pentru codul aplicației și ar trebui aplicate testelor automate, deoarece beneficiile încă se aplică. În cazul de testare, stratul de date este apelat pentru a prelua date din sursa de date pentru tipul de client adecvat.

Cazul de testare repetă apoi peste toate intrările din listă și efectuează un test pentru fiecare intrare de client. Testele de sistem corespund unuia dintre nivelurile de testare a software-ului combinat cu diverse teste precum recuperare, securitate, rezistență, performanță, conectivitate, volum, tensiune, disponibilitatea datelor, ușurință în utilizare, operare, Mediu inconjurator, stocare, configurare, instalare și documentare. Fiecare are un scop diferit și are un scop comun care demonstrează viziunea sistematică a proiectului. Testarea de acceptare este un alt tip de nivel care este completat de niveluri de testare software, aceste teste sunt foarte fundamentale deoarece sunt cele care ne vor permite să obținem un produs care îndeplinește standardele cerute și care satisface simultan cerințele utilizatorilor în conformitate cu cerinte pe care le-au ridicat de la bun inceput . Acest lucru obligă sistemul să testeze procesul vital de testare, deoarece în ceea ce privește produsul, numărul de erori și severitatea acelor erori, este pasul de dezvoltare care este de obicei predispus la majoritatea erorilor. Figura 1: Verificarea sistemelor iterative Testele de sistem nu sunt procese pentru verificarea funcționalității sistemului sau program complet, deoarece ar fi redundant cu procesul de testare funcțională. Testele de sistem au un scop specific: de a compara un sistem sau un program cu obiectivele sale originale. În acest scop, sunt prezentate două valori. Testarea sistemului nu se limitează la sisteme. Dacă produsul este un program, testarea sistemului este o încercare de a demonstra modul în care programul nu își îndeplinește complet obiectivele sau cerințele. Testele de sistem, prin definiție, nu sunt posibile decât dacă există cerințe scrise care sunt măsurabile pentru produs. Testarea sistemului este faza de cercetare în care se asigură că fiecare componentă sau modul interacționează cu alte componente sau module conform intenției. Testele de sistem vizează implementarea în profunzime a sistemului, verificarea integrării unui sistem informațional în întreaga lume, verificarea funcționării corecte a interfețelor dintre diferitele subsisteme care îl compun și cu alte sisteme informaționale cu care acesta comunică. Problema clasică de testare a sistemului este „a arăta cu degetul”. Acest lucru se întâmplă atunci când se descoperă o eroare și dezvoltatorul fiecărui element de sistem dă vina pe alții. În loc să cadă în această absurditate, inginerul de software ar trebui să anticipeze posibile probleme cu o interfață:  o cale de gestionare a erorilor de proiectare care verifică toate informațiile provenite din alte elemente ale sistemului. Testarea și testarea sistemului 6  Aplicați o serie de teste care simulează date proaste sau altele posibile greșeliîn interfața software.  Înregistrați rezultatele testelor ca dovezi în caz de vinovăție.  Participa la planificarea și dezvoltarea testării sistemului pentru a se asigura că software-ul a fost testat corespunzător. De fapt, testul de sistem acoperă o serie de teste diferite, al căror scop principal este de a calcula în profunzime sistemul în timpul calculului. Deși fiecare test are un scop diferit, toate funcționează pentru a se asigura că toate elementele sistemului au fost integrate corespunzător și că îndeplinesc funcțiile corespunzătoare. 2 Revizuirea sistemului a testului. Când urmează să fie efectuată testarea, este necesar să se mențină un sistem, adică o abordare integrală a dezvoltării software. Aplicarea acestor concepte la un test de software generează un set de principii care vor servi drept bază pentru test: trebuie să vă asigurați că cunoașteți exact obiectivele software-ului testat, precum și ratele de succes. Aceste elemente se regăsesc în documentele obținute în faza de colectare a cerințelor, precum și în specificațiile software. Aceste informații vor fi necesare pentru pregătirea planului de testare și vor constitui baza pentru inițierea dezvoltării cazului de testare. Trebuie definite intrările și ieșirile sistemului aprobat. Acest aspect este necesar în pregătirea cazurilor de testare, precum și în crearea procedurilor de testare, în special a celor orientate pe cazuri de testare care arată îndeplinirea scopurilor. Luați în considerare sistemul principal pe care rulează software-ul testat. De obicei, este un mediu organizațional care constă din hardware, software și oameni. Toate aceste elemente au o mare influență asupra sistemului și mai ales ajută la pregătirea cazurilor de testare a situațiilor nedorite asociate cu date inadecvate, lipsa de elementele necesareși apariția excepțiilor. 3 Testarea sistemului Prezentare generală Procesul de testare a sistemului constă din două faze care pot fi foarte separate în timp: pregătirea testului și aplicarea testului. Primul este strâns legat de cerințe, așa că se întâmplă la începutul proiectului, iar cel de-al doilea necesită sistemul complet sau cel puțin o integrare, deoarece se spune că produsul parțial nu este lansat pentru a putea aplica teste, așa că se întâmplă în etapele avansate ale proiectului. proiect. Situația exactă cu aceste piese depinde de modelul ales. ciclu de viață. Pentru a efectua a doua și a treia activitate, este necesar un document de cerințe. Prima fază a testării oferă feedback pentru a analiza cerințele, a identifica lacunele, ambiguitățile și alte probleme. De asemenea, oferă sfaturi valoroase cu privire la proiectarea și implementarea sistemului, dacă tocmai dezvoltați unul. Faza de aplicare a testului necesită un plan de testare și o versiune de sistem executabilă. În acest caz, se vor aplica cazurile de testare care au fost pregătite, se vor analiza rezultatele și se vor identifica eventualele defecte. Acest al doilea pas oferă feedback la implementare și proiectare, arătând posibilele defecte care trebuie remediate. De asemenea, oferă informații care vor fi utile în lansarea unui sistem, adoptarea acestuia, evaluarea fiabilității și menținerea acestuia. Figura 1 prezintă procesul de testare a sistemului și relația acestuia cu alte procese. Al doilea punct este important deoarece uneori testul de sistem este confundat cu testul de interfață. Prima verifică interacțiunea tuturor părților, iar a doua analizează elementele de interfață și, eventual, procesarea evenimentelor aferente. Cu toate acestea, instrumentele care ajută la testarea interfeței pot fi utilizate pentru a rula teste de sistem. Apar mai multe întrebări: câte cazuri vor fi suficiente? Cum să generezi cât mai puțin posibil? Ce valori sunt potrivite? Testarea și testarea sistemului 9 1 Plan de testare Un plan de testare este foarte Document Importantîn timpul testării software-ului. Acesta explică obiectivele și abordările testării, planul de lucru, procedurile operaționale, instrumentele necesareși responsabilități. Testarea și testarea sistemului 10 Documentul de cerințe ar trebui să conțină o listă de funcții care trebuie îndeplinite de software, descriindu-le și stabilindu-le priorități; ar trebui să includă, de asemenea, cerințe nefuncționale, care pot include aspecte organizaționale, operaționale și alte aspecte. Un document de cerințe bine pregătit ar trebui să ofere o modalitate pentru fiecare cerință de a verifica dacă este îndeplinită. În cazul caracteristicilor, aceasta ar fi o descriere, iar în cazul cerințelor nefuncționale, ar putea fi specificații foarte precise, cum ar fi timpul de răspuns. Deocamdată ne vom concentra pe cerințele funcționale, lăsând restul pentru o secțiune ulterioară. Testele de sistem sunt importante din cauza următorilor factori:  Sistemul este testat ca întreg în cadrul ciclului de viață al dezvoltării sistemului.  Se verifică conformitatea sistemului cu funcţionale şi cerinte tehnice .  Sistemul este testat într-un mediu cât mai apropiat de mediul de producție.  Testele de sistem vă permit să testați, să validați și să validați atât cerințele de afaceri, cât și arhitectura aplicației. 6Tip de teste de sistem Teste funcționale  Test de integrare. - În care echipamentul de testare are acces la codul sursă al sistemului. Când se descoperă o problemă, echipa de integrare încearcă să găsească sursa problemei și să determine componentele care trebuie depanate. Testarea integrării se ocupă în principal de găsirea defectelor în sistem.  Dovada livrării. Iată versiunea sistemului care poate fi livrată utilizatorului. Aici, echipa de testare este preocupată să verifice dacă sistemul îndeplinește cerințele sale și garantează fiabilitatea sistemului. Testele de livrare sunt de obicei teste cutie neagră, în care echipamentul de testare este pur și simplu preocupat de dacă sistemul funcționează corect. Componentele care pot fi integrate pot fi componente comerciale, componente reutilizabile adaptate unui anumit sistem sau componente nou dezvoltate. Pentru multe sisteme mari, probabil că vor folosi toate cele trei tipuri de componente. Testul de integrare verifică dacă aceste componente funcționează împreună, sunt apelate corect și transmite datele corecte la momentul exact prin interfețele lor. Integrarea sistemului implică identificarea grupurilor de componente care oferă unele funcționalități ale sistemului și integrarea acestora prin adăugarea de coduri pentru a lucra împreună. Uneori, scheletul întregului sistem este dezvoltat mai întâi, iar componentele sunt adăugate. Aceasta se numește post-integrare. Aceasta este integrarea ascendentă. În practică, pentru multe sisteme, strategia de integrare este o combinație a ambelor, adăugând componente suplimentare de infrastructură și componente funcționale. Ambele abordări de integrare necesită cod suplimentar pentru a modela alte componente și pentru a permite pornirea sistemului. Principala dificultate întâlnită în timpul testelor de integrare este localizarea erorilor. Există interacțiuni complexe între componentele sistemului și, atunci când este detectată o ieșire anormală, poate fi dificil să se determine unde a apărut eroarea. Pentru a facilita izolarea erorilor, ar trebui să utilizați întotdeauna o abordare incrementală a integrării și testării sistemului. Scopul principal al acestui proces este de a crește încrederea furnizorului că sistemul îndeplinește cerințele acestuia. Dacă da, poate fi livrat ca produs sau livrat unui client. Pentru a demonstra că un sistem își îndeplinește cerințele, trebuie să se demonstreze că oferă funcționalitatea, performanța și fiabilitatea specificate și că nu eșuează în condiții normale de utilizare. Testele de livrare sunt de obicei un proces de testare cutie neagră în care testele sunt derivate din specificațiile sistemului. Sistemul este privit ca o cutie neagră al cărei comportament ar trebui determinat doar prin examinarea intrărilor și ieșirilor respective. Un alt nume pentru aceasta este testarea funcțională, deoarece testerul este interesat doar de funcționalitate și nu de implementarea software-ului. În figura următoare, vom vedea o ilustrare a modelului de sistem pe care îl permite în validarea cutiei negre. Testerul prezintă intrări către o componentă sau sistem și ia în considerare intrările. În unele cazuri, sistemul trebuie să fie tolerant la erori; adică eșecurile de procesare nu ar trebui să conducă la defecțiuni ale sistemului în ansamblu. Sisteme de testare și teste de acceptare 14 Defecțiunea sistemului trebuie remediată într-o anumită perioadă de timp sau va avea daune economice grave. Testul de recuperare este un test de sistem care face ca software-ul să eșueze în mai multe moduri și să verifice dacă recuperarea este efectuată corect. Dacă recuperarea are loc automat, trebuie să verificați dacă reinițializarea, mecanismele de backup a sistemului, recuperarea datelor și repornirea sunt corecte. Dacă recuperarea necesită intervenție umană, timpul mediu de recuperare trebuie determinat pentru a determina dacă se află în limite acceptabile. Scopul este de a stabili punctele finale în care sistemul începe să funcționeze sub cerințele specificate. Acest lucru nu trebuie confundat cu testul de volum; înaltă tensiune este cantitatea maximă de date sau activitate per un timp scurt. Analogia ar fi evaluarea dactilografului. Se va determina un test de volum dacă dactilograful se confruntă cu o schiță de raport mare; testul de stres va determina dacă dactilograful poate scrie la un index de 50 de cuvinte pe minut. Încălcarea include o gamă largă de activități:  Un hacker care încearcă să se autentifice în fiecare joc. Testul de securitate verifică dacă mecanismele de securitate încorporate în sistem îl protejează de fapt de intruziunile necorespunzătoare. „Sistemele trebuie testate pentru ca securitatea sistemului să fie imune la atacurile frontale, dar și la cei care fac flancuri sau spate”. În timpul testului de securitate, oricine îl aplică joacă rolul persoanei care dorește să se autentifice. Toate acestea merită! Ar trebui să încercați să obțineți orice parolă mijloace externe; poate ataca sistemul folosind software special conceput pentru a ocoli orice arhitectură protejată; el poate satura sistemul, refuzând astfel serviciul altora; poate duce la erori deliberate în sistem pentru a încerca să obțineți acces în timpul recuperării: puteți vizualiza datele fără protecție, cu ideea de a căuta parola pentru sistem. Dacă se acordă suficient timp și resurse, sistemul o va face în cele din urmă test bun pentru siguranță. Rolul proiectantului de sistem este ca costul întreruperii să fie mai mare decât costul informațiilor primite. Cu toate acestea, analiza factorilor umani rămâne o problemă extrem de subiectivă. Cazurile de testare au scopul de a demonstra că aceste ținte de stocare nu sunt găsite. Adesea, numărul de configurații posibile este prea mare pentru a testa fiecare, dar dacă este posibil, ar trebui să testați programul cu fiecare tip de dispozitiv hardware și cu configurația minimă și maximă. Dacă programul în sine poate fi configurat pentru a omite componente sau dacă poate rula pe mai multe computere, fiecare configurație trebuie testată. Testarea procedurilor de instalare este o parte importantă a procesului de testare a sistemului. Acest lucru este valabil mai ales pentru sistem instalare automată incluse în pachetul software. Un program de instalare executat necorespunzător poate împiedica utilizatorul să aibă o experiență de succes cu sistemul. Prima experiență a utilizatorului este atunci când instalează aplicația. O modalitate de a realiza acest lucru este să utilizați documentația pentru a defini o vedere a cazurilor anterioare de testare a sistemului. Adică, odată ce doriți să dezvoltați un caz de supraîncărcare, ar trebui să utilizați documentația ca ghid pentru scrierea cazului de testare real. În plus, documentația utilizatorului ar trebui să facă obiectul unei verificări pentru acuratețe și claritate. Oricare dintre exemplele prezentate în documentație ar trebui testat și adăugat la lista de activități și inclus în program. Testarea și testarea sistemului 17 din punct de vedere al funcționării, după adoptarea sistemului în mediul real și pe baza respectării cerințelor nefuncționale specificate. Testarea rezistenței este concepută pentru a contracara programele în situații anormale. În esență, persoana care face testul de rezistență va întreba. Cât de departe ajungi înainte să eșueze? Testul de rezistență conduce sistemul în așa fel încât necesită o cantitate, o frecvență sau o cantitate anormală de resurse. De exemplu:  au fost dezvoltate teste speciale care generează 10 întreruperi pe secundă când media cană este una sau două.  Frecvența de introducere a datelor este crescută cu o sumă care va permite răspunsuri la funcțiile de intrare.  Rulați cazuri de testare care necesită memorie maximă sau alte resurse.  Cazurile de testare sunt concepute pentru a depana problemele de gestionare a memoriei. Sunt create cazuri de testare care provoacă căutări excesive pe disc. Figura este un exemplu de test de rezistență. Testul de performanță se aplică în toate etapele procesului de testare. Chiar și la nivelul unității. Performanța unui modul individual ar trebui evaluată în timpul testării. Cu toate acestea, numai după ce toate elementele sistemului sunt pe deplin integrate poate fi atinsă performanța reală a sistemului. Testele de performanță implică adesea testarea rezistenței și adesea necesită instrucțiuni software și hardware. Adică, este adesea necesar să se măsoare cu precizie utilizarea resurselor. Folosind instrumente externe, puteți monitoriza în mod regulat intervalele de rulare, evenimentele înregistrate și starea mostrelor de hardware. Aceste teste sunt efectuate astfel încât clientul să confirme că sistemul este valabil pentru el. Planificarea detaliată a acestor teste ar trebui efectuată la începutul fazei de dezvoltare, cu scopul de a utiliza rezultatele ca o indicație a validității lor: dacă testele documentate sunt efectuate spre satisfacția clientului, produsul este considerat corect și, prin urmare, adecvat pentru a fi pus în aplicare. producție. 6 Testele de acceptare2 sunt practic teste funcționale pe întregul sistem și au ca scop să verifice dacă cerințele stabilite . Execuția acestuia este opțională pentru client, iar în cazul în care nu sunt specificate în mod explicit, acestea sunt incluse în testele de sistem. Adică, testele de acceptare sunt adesea responsabilitatea utilizatorului sau a clientului, deși oricine implicat în afacere le poate efectua. Testarea de acceptare necesită un mediu de testare care reprezintă mediul de producție. Această fază sau nivel ca punct de plecare definește linia de bază a acceptării produsului deja stabilită în mediul de certificare. Testarea și acceptarea sistemului 19 Figura - Controlul acceptării. 1 Examinarea situației actuale în testele de acceptare. Ca parte a testelor, trebuie să verificăm software-ul, unul dintre cele mai importante este testarea de acceptare. Acestea sunt testele care sunt dezvoltate chiar de echipa de dezvoltare pe baza cerințelor funcționale specificate în faza de analiză pentru a acoperi întregul spectru și a fi efectuate de utilizatorul final, dar nu toți, ci câțiva utilizatori au un rezultat semnificativ care oferă validitatea și conformitatea cu produsul care le este livrat pe baza a ceea ce sa convenit inițial. În funcție de complexitatea sistemului testat, indiferent dacă acesta este împărțit în module etc. executarea acestor teste se realizează diferit. Dacă aplicația ar fi împărțită în module, acestea ar fi considerate subsisteme și ar fi suficient de complexe pentru ca acestea să fie tratate diferit, ar trebui efectuate diferite sesiuni de testare de acceptare. 2 Scopul testării de acceptare Testarea de acceptare urmărește obținerea acceptării clientului final înainte de livrarea unui produs pentru ca acesta să intre în producție. Când o organizație a efectuat teste de sistem și a remediat majoritatea defectelor sale, sistemul va fi livrat utilizatorului sau clientului pentru aprobare. Scopul testării de acceptare este de a verifica dacă sistemul îndeplinește performanța așteptată și permite utilizatorului acelui sistem să determine acceptarea acestuia în ceea ce privește funcționalitatea și performanța sa. Testele de acceptare sunt determinate de utilizatorul sistemului și pregătite de echipa de dezvoltare, deși execuția și aprobarea finală sunt la latitudinea utilizatorului. Validarea sistemului se realizează prin rularea testelor cutie neagră care demonstrează conformitatea și sunt incluse într-un plan de testare care definește validările care trebuie efectuate și cazurile de testare asociate acestora. Acest plan este conceput pentru a se asigura că sunt îndeplinite toate cerințele funcționale specificate de utilizator, precum și cerințele nefuncționale legate de performanță, securitatea accesului la sistem, date și procese și diverse resurse ale sistemului, 3 Generarea testării de acceptare. Sistemul trebuie să fie acceptat de utilizator. Din acest motiv, pe baza specificațiilor structurate ale sistemului, analistul creează un set de cazuri de testare care trebuie să treacă satisfăcător. Deoarece testele de acceptare pot fi dezvoltate în paralel cu activitățile de proiectare și practică, este normal ca aceste activități să fie inițiate de analist imediat ce activitatea de Analiză Structurată este finalizată. 4 Strategii de testare a acceptării Dacă sistemul ar fi conceput pentru piața de masă, atunci nu ar fi practic să-l testați pentru utilizatori individuali sau clienți, în unele cazuri nu ar fi posibil. În aceste cazuri, feedback-ul este necesar înainte ca produsul să fie scos la vânzare. Adesea, astfel de sisteme au două etape de testare de acceptare. Testarea Alpha și Beta Când un software personalizat este construit pentru un client, sunt efectuate o serie de teste de acceptare pentru a permite clientului să testeze toate cerințele. Efectuat de client pe site-ul de dezvoltare. Software-ul este utilizat în mod natural cu dezvoltatorul ca supraveghetor al utilizatorului, împreună cu erorile de înregistrare și problemele de utilizare. Testele alfa sunt efectuate într-un mediu controlat. Lucrezi într-un mediu controlat și clientul are întotdeauna un expert care să te ajute să folosești sistemul. Dezvoltatorul ține evidența erorilor găsite și a problemelor de utilizare. Testele Β-beta sunt efectuate după testul α-alfa și sunt dezvoltate într-un mediu client. În acest caz, clientul rămâne singur cu produsul și încearcă să găsească bug-uri care informează dezvoltatorul. Acestea sunt efectuate de utilizatorii finali ai software-ului la stațiile de lucru ale clientului. Spre deosebire de un test alfa, dezvoltatorul nu este de obicei prezent. Astfel, un test beta este o aplicație live a software-ului într-un mediu care nu poate fi controlat de dezvoltator. Clientul înregistrează toate problemele care apar în timpul testării beta și raportează dezvoltatorilor la intervale regulate. 5 Intrări, ieșiri, sarcini și roluri ale testului de acceptare. Specificarea cerințelor de intrare. Sarcini Pregătiți mediul de testare. Vă recomandăm să aveți un mediu de testare specific pentru acest tip de testare. Instalare într-un mediu de testare. Testarea și testarea sistemului 22 Identificați testele care trebuie efectuate. Se vor stabili eventualele dependențe care există între teste și se va stabili ordinea sau secvența în care vor fi executate testele pe baza acestor dependențe. Primirea și înregistrarea rezultatelor. S-au remediat erori și erori. Repetați sarcina până când treceți toate testele. Întocmirea unui raport de testare de acceptare. O privire de ansamblu asupra executării corecte și a rezultatelor tuturor testelor depuse. Crearea unei baze de producție. Închiderea oficială a activităților. Rezultatele testului. Raport de acceptare a produsului acceptat. Manager de proiect. Accentul pe testarea de acceptare este legat de încercarea de a consolida opinia că utilizatorul integrat în această etapă, într-un stadiu incipient, ar ajuta la îmbunătățirea acestui proces în faza de planificare și proiectare a testelor, cu îmbunătățiri ulterioare în multe aspecte cantitative și dezirabile. , cum ar fi: Îmbunătățirea calității securității software integrate. Minimizarea costurilor. Fiabilitate crescută în rezultatele proiectului. Când utilizați software cu mai puține erori, există o creștere a satisfacției clienților. Acest lucru îmbunătățește eficiența procesului de dezvoltare. 7 Criterii pentru testarea de acceptare. Acceptarea software-ului se realizează printr-o serie de teste care demonstrează că acestea îndeplinesc cerințele. Planul de testare descrie tipul de test care trebuie aplicat, iar procedura de testare definește cazurile de testare specifice, atât planul, cât și procedura sunt concepute pentru a se asigura că îndeplinesc toate cerințele funcționale, că toate caracteristicile comportamentale sunt îndeplinite, toate cerințele de performanță sunt îndeplinite, documentația este corectă și a respectat toate cerințele pentru ușurință în utilizare și altele cerințe specificate. 8 Instrumente pentru testele de acceptare. Acest lucru permite clienților, testerilor și programatorilor să știe ce ar trebui să facă software-ul lor și să compare automat ceea ce face de fapt. Vă permite să scrieți teste ușor de citit și ușor de întreținut. Această activitate este cunoscută sub denumirea de test final sau test de acceptare. Acest lucru necesită introducerea datelor de test de acceptare și un sistem integrat creat în timpul acestei activități. Testul va fi efectuat de un membru sau departament al utilizatorului, sau chiar de un departament independent de control al calității. Este important de remarcat faptul că este important să se desfășoare activități de control al calității în fiecare dintre activitățile anterioare de analiză, proiectare și implementare pentru a se asigura că acestea au fost efectuate la nivelul adecvat de calitate. Acest lucru asigură că analistul produce specificații de calitate, că designerul produce design de calitate și că programatorul produce programe de codare de calitate. În informatică, o implementare este o specificație tehnică sau algoritmi, cum ar fi un program, componentă software sau alt sistem informatic. Multe implementări sunt furnizate conform unei specificații sau standard. Rezum lucrările anterioare ale autorilor pentru a obține obiectivele testelor, care reprezintă punctul de plecare pentru dezvoltarea testelor automate. În contextul testării sistemului din cazuri de utilizare, scopul testării poate fi exprimat ca un caz de utilizare. Acest scenariu va consta dintr-o secvență de pași fără alternativă posibilă și un set de valori de testare și preconditiiși post-conferințe legate de acest scenariu. Pentru a genera scenarii de testare, mai întâi, este construită o diagramă de activitate din secvența principală și secvențele de eroare și alternative ale cazului de utilizare. În diagrama de activitate, acțiunile efectuate de sistem și acțiunile efectuate de participanți sunt stereotipate. Se efectuează apoi analiza căii și fiecare cale a diagramei de activitate va fi un scenariu de caz de utilizare și, prin urmare, o potențială țintă de testare. 2 Implementarea testelor de sistem. Arhitectura de testare a sistemului. Arhitectura pentru executarea și validarea automată a testelor de sistem este prezentată în Figura 7. Această arhitectură este similară cu arhitectura necesară pentru automatizarea altor tipuri de teste, cum ar fi testele unitare. Principala diferență este că, într-un test unitar, testul în sine apelează codul executabil, în timp ce testarea funcțională a sistemului de testare și acceptarea testului 27 necesită un intermediar care știe cum să-și manipuleze interfața externă. Implementarea cazurilor de testare. Un test-test este realizarea scopului testării. Comportamentul general pentru un caz de testare este listat în tabelul Comportament general al cazului de testare. Fiecare caz de utilizare va fi asociat cu o suită de testare. Această suită va conține teste pentru toate scenariile cazului de utilizare menționat. După cum se poate observa din obiectivele testului, fiecare pas trebuie specificat dacă este realizat de un actor sau de sistemul testat. Aceste informații sunt foarte relevante atunci când se codifică metodele de testare a pachetului. Toate acțiunile efectuate de actor transformă codul codului de testare într-o interacțiune între cazul de testare și sistem. Testarea sistemului și testarea de acceptare 29 Metodologia operațională și variabilă de categorie va fi aplicată pentru a determina valorile de testare necesare. Trei au fost identificate tipuri variate variabile operaționale. Fiecare tip va fi implementat diferit în cazurile de testare. Primul tip este format din acele variabile operaționale care indică transferul de informații către sistem de către o entitate externă. Pentru fiecare variabilă de acest tip va fi definită o nouă clasă, ale cărei obiecte vor conține diferite valori de testare pentru această variabilă. Un exemplu de acest tip de variabilă de lucru este prezentat în studiul de caz. Al doilea tip constă din acele variabile operaționale care indică o alegere între multiple opțiuni disponibile actorului extern. În schimb, o astfel de alegere va fi implementată direct ca parte a codului care implementează interacțiunea dintre actor și sistem. Al treilea tip constă din acele variabile de operare care indică starea sistemului. Pentru a implementa metoda de configurare a cazului de testare, scrieți codul necesar pentru a seta corect valoarea variabilelor operaționale care descriu stările sistemului sau pentru a verifica dacă valorile se potrivesc. În mod similar, metoda break trebuie să restabilească aceste valori la stările lor originale. În plus, metoda de urmărire trebuie să excludă, dacă este necesar, informațiile introduse de cazul de testare în sistem în timpul execuției cazului de testare. În studiul de caz sunt prezentate mai multe exemple de variabile operaționale de acest tip. În acest caz, primul lucru de făcut este să aplicați ceea ce s-a văzut pentru a obține setul de obiective de testare din cazul de utilizare. Se determină apoi caracteristicile hamului de testare utilizat. În cele din urmă, aplicăm ceea ce am văzut în secțiunile anterioare pentru a implementa cazul de testare din ținta de testare. Sistemul testat artefactele au fost identificate pe Limba engleză, în măsura în care limba spaniolă nu este susținută de instrumentele utilizate. Cazul de utilizare din Tabelul 2 descrie introducerea unei noi legături în sistem. În plus, este afișată și o cerință de stocare a informațiilor care descriu informațiile gestionate de fiecare link. Din cazul de utilizare și automat generat un set de scenarii care vor fi ținta testării cazului de utilizare menționat. Având în vedere că cazul de utilizare are bucle nelimitate cu un număr infinit de repetări potențiale, criteriul de acoperire ales pentru obținerea drumurilor este criteriul 01, care verifică și testează testele sistemului 30, constă în obținerea tuturor căilor posibile pentru repetarea niciuna sau o singură dată a fiecare dintre bucle. Toate scripturile obținute folosind acest criteriu și traduse în spaniolă sunt enumerate în tabel. Pentru acest studiu de caz, am ales Scenariul 09, care este detaliat în Tabelul 5 pentru implementarea lui. Testare și testare în testare 31 Informații de tabel Cerință pentru referințe. De asemenea, puteți aplica metoda de împărțire a categoriilor. Secțiunile pentru fiecare dintre aceste variabile sunt listate în tabel. Testarea și testarea sistemului 32 Variabile de tabel definite pentru cazul de utilizare. Testare și testare în testare 33 Tabel de categorii pentru variabilele identificate. După cum este descris în Figura 7, testul cablajului este conceput pentru a simula comportamentul utilizatorului și pentru a oferi un set de declarații pentru a evalua rezultatul. Această traducere se face în prezent manual și este prezentată în tabel. Testarea și testarea transceiver-ului 35 Figura Implementarea cazului de testare. Traducerea în cod executabil a pașilor executați de utilizator în scenariul principal. Adică să ne asigurăm că categoriile există și că nu există circumstanțe care să provoace o eroare la restaurarea categoriilor sau la introducerea unui nou link. Implementarea metodei break a fost de a restaura setul original de legături stocate în sistem. 2 Implementarea testelor de acceptare. Testele de acceptare funcționează numai cu asistența pentru clienți sau cel puțin cu un proxy pentru client pentru a determina criteriile. Fără criterii de acceptare a driverului, devine dificil să verificați dacă construiți software-ul potrivit. Clientul, împreună cu toți membrii echipei de dezvoltare, trebuie să se asocieze pentru a defini sistemul în termenii unei serii de „scripturi” care descriu ce ar trebui să facă sistemul și cum ar trebui să o facă. Prin crearea de teste cu cerințe clare și criterii de aprobare, este mai probabil ca software-ul să îndeplinească așteptările clienților. Cu toate acestea, aceasta înseamnă că cineva verifică manual dacă cerințele sunt îndeplinite și dacă aplicația funcționează conform așteptărilor. Aici apar testele automate de acceptare în locul cerințelor dintr-un document moștenit, cerințele sunt definite ca exemple și scenarii, protejate în controlul sursei cu artefacte de implementare și pot fi rulate în orice moment pentru a verifica dacă îndeplinesc cerințele și funcționează corect. Puteți folosi aceeași abordare pentru a scrie teste, dar în loc să le introduceți într-un software de gestionare a cazurilor de testare sau într-o foaie de calcul, scrieți-le direct în cod. Testarea și testarea sistemului 37 1 Testarea automată de acceptare. Prin urmare, primul pas în implementarea oricărei noi funcționalități este să vă descrieți așteptările printr-un test. Alții nu sunt și se confruntă cu probleme cu controlul procesului în timp, mai ales pe măsură ce dovezile cresc și flexibilitatea testării începe să se deterioreze. Abordarea bazată pe teste se bazează pe care teste ar trebui să ghideze dezvoltarea unui produs software. În produsele software industriale, atunci când sunt utilizate metode de inginerie a cerințelor, acestea sunt susținute în mare parte de limbajul natural, ceea ce implică binecunoscutul inconvenient al ambiguității. Cu toate acestea, nevoia de validare poate depăși beneficiile pe care le poate oferi o specificație mai formală și mai riguroasă a cerințelor. Clientul trebuie să fie capabil să citească și să înțeleagă cerințele pentru a putea fi de acord cu acestea. Cele mai populare metode pentru definirea cerințelor sunt enumerate în secțiunea Cazuri de utilizare și Povești utilizator. Definirea cerințelor este cheia pentru atragerea clientului. Cerințe - scopul realizării, adică ceea ce așteaptă clientul de la produsul software. Testarea și testarea sistemului 38 de roluri legate de specificarea cerințelor și validarea și testarea de acceptare. Conceptul de cerințe devine Container of Acceptance Tests, iar acestea sunt cele care ocupă centrul atenției ca specificație a fiecărei cerințe. Luați în considerare cerința „Retrageți bani” în contextul unui bancomat. O specificație descriptivă tipică ar putea fi următoarea: clientul trebuie să poată retrage numerar de la casierie în sume selectate. Primiți întotdeauna o chitanță dacă casieria nu mai are hârtie. Când vine vorba de Client preferat, vă puteți retrage mai mulți bani decât ai în cont, dar ar trebui să fii avertizat că vei fi taxat cu un procent. Clientul ar trebui să poată anula în orice moment înainte de a confirma retragerea. Sumele trebuie să poată fi deservite de conturile pe care casieria le are la momentul respectiv, iar alte sume nu trebuie acceptate. Figura - Alternative de specificații Figura 10 prezintă câteva alternative de specificații pentru această cerință. Pictogramele reflectă confortul fiecărei specificații. Poate fi interesant să se dezvolte o diagramă de secvență pentru a defini fiecare scenariu pentru îndeplinirea unei cerințe, cu toate acestea, în general, acest lucru nu este potrivit din cauza un numar mare diagrame generate. Este mai interesant să identifici scenarii decât să le ilustrezi pe fiecare într-o diagramă. Descrierea narativă nu este o singură dată, cel puțin pentru scurtă definiție cerințe, care se concentrează pe definirea conceptelor implicate. Cu toate acestea, modelul de utilizare nu este potrivit pentru a ilustra structura detaliată a cerințelor unui produs software într-un mediu de întreținere pe termen lung, deoarece un produs software mediu poate avea mii de cerințe. Sunt necesare mecanisme mai adecvate pentru a vizualiza și gestiona multe cerințe. Șabloanele sunt una dintre cele mai frecvent utilizate alternative de utilizat pentru cazurile de utilizare. Șabloanele sunt elegante și oferă un sentiment de ordine conform specificațiilor. Cu toate acestea, acestea sunt în general contraproductive, deoarece tind să ofere un singur nivel de procesare a detaliilor pentru toate cerințele. În aceste cazuri foarte simple, ele includ lucruri care sunt evidente sau irelevante doar pentru a acoperi toate secțiunile șablonului. Când o cerință include mai multe scripturi, încercarea de a sintetiza toate scripturile dintr-un șablon are ca rezultat, de obicei, specificații confuze. În acest fel, cerințele acționează ca containere pentru țară. În funcție de cerință, pot fi utile și alte forme suplimentare de specificație. De exemplu, o diagramă de activitate dacă comportamentul asociat cu o cerință are un simbol algoritmic sau o diagramă de stare dacă comportamentul include acțiuni de activare sau dezactivare conform aserțiilor sistemului și testelor de acceptare a sistemului. O condiție prealabilă esențială este pragmatismul în ceea ce privește specificația, care nu exclude partajarea alternativelor la specificație, dar criteriul principal ar trebui să fie dorința de a fi profitabil și de a contribui la menținerea respectivei specificații. Pe de altă parte, în ceea ce privește eforturile de a întreținere, mai ales din punct de vedere al coerenței, este important să nu folosiți excesiv duplicarea sau duplicarea specificațiilor în mijloace diferite reprezentare. Un grafic direcționat este o reprezentare adecvată pentru rafinarea nivelului. Acest grafic vă permite să vizualizați relațiile de descompunere și dependențele dintre cerințe. Astfel, fiecare nod este o cerință funcțională sau nefuncțională. Arcurile dintre noduri stabilesc relații între părinți și copii sau relații de dependență „noduri care afectează nodurile”. Astfel, în exemplul de mai sus, cerința „Retragere de bani” poate fi un nod al structurii cerințelor. Retur cu cantitatea introdusa de client. Nu există bilete disponibile. Nu există hârtie de primit. Timpul de comunicare cu sistemul central a fost depășit. Notificarea operațiunilor interne ale casieriei. Timpul expirat pentru a iniția acțiunea. Aceasta poate fi legată de o cerință funcțională sau de o cerință nefuncțională. Este opțional și este folosit pentru a seta cerințe preliminare înainte de a aplica pașii de testare. Acestea sunt acțiunile de interacțiune ale actorului cu sistemul. Când efectuează mai multe acțiuni, pot fi plasate pe o listă numerotată. Acesta este efectul interacțiunilor actorilor. Fiecare acțiune poate provoca unul sau mai multe rezultate. Este important ca atunci când vine vorba de mesaje către utilizator, textul să fie inclus ca parte a rezultatului așteptat, astfel încât programatorul are deja aceste informații verificate cu clientul. Aceasta, după cum vom sublinia mai jos, va stabili dependența dintre cerințe. Condiție Trebuie să fie un client normal. Pași  Încercați să rambursați un client normal și să solicitați o sumă în plus față de sold.  Rezultatul scontat. Testarea sistemului și acceptarea 42  Se afișează mesajul „Cantitatea solicitată depășește soldul actual, reintroduceți cantitatea” și revine în fereastra pentru a introduce cantitatea. Testarea de acceptare va ajuta la confirmarea faptului că construiți aplicația dorită de client, în timp ce automatizarea acestor scripturi vă permite să testați în mod continuu aplicația pe tot parcursul procesului de dezvoltare și să le utilizați ca parte a suitei dvs. de testare a regresiei pentru a vă asigura că modificările viitoare nu se întrerup în prezent. cele.cerinţe. Cu toate acestea, a avea un client asociat cu compilarea dovezilor, în special testarea automată, prezintă o serie de probleme potențiale. Clienții, în general, sunt non-tehnici și tind să se distanțeze de dezvoltarea de software în sine. Clientul poate furniza date și exemple, în timp ce testerii sau dezvoltatorii pot codifica rapid scripturi și specificații executabile. Teste de acceptare a interfeței cu utilizatorul În exemple, testele de acceptare s-au concentrat pe logica de afaceri și pe obiectele de domeniu pentru a vedea dacă logica a funcționat cu succes. Dar cum interacționează utilizatorul cu aplicația? Aceste teste de acceptare ar trebui să fie acolo pentru a testa corectitudinea logicii din punctul de vedere al utilizatorului, iar punctul de vedere al utilizatorului este interfața cu utilizatorul. Dacă aplicația are o decuplare bună și o bună separare a logicii de codul UI, acest lucru ar trebui să faciliteze implementarea testelor. Dacă testați la acest nivel, testele nu se vor schimba în interfața cu utilizatorul. Deși testarea ar trebui să se concentreze exclusiv pe logică, aceasta nu înseamnă că nu trebuie să treceți testele de acceptare pe întreaga interfață cu utilizatorul. Îmi place să am un set de teste de fum care vizează o interfață de utilizator de bază" drum fericit". Aceștia se concentrează pe părțile aplicației pe care utilizatorii sunt cel mai probabil să le folosească pentru a profita la maximum de experiența lor. cea mai mica cantitate testarea. Dacă încerci să acoperi totul modalități posibileși utilizarea UI, iar dacă UI se schimbă, va trebui să schimbați toate testele. De exemplu, dacă testați interfața de utilizator pentru un site de comerț electronic, drumul va fi bucuros să selecteze un articol, să îl adauge în coș, să îl verifice și să vadă o confirmare de cumpărare. Dacă acest scenariu eșuează, chiar doriți să aflați cât mai curând posibil. Pentru anumite aplicații, în funcție de complexitate și durata de viață, poate doriți să aveți mai multe teste de acceptare în UI pentru a vă asigura că aveți mai multă încredere în stratul UI. Cu toate acestea, testarea UI de succes este întrebare dificilăși nu am loc să-l acopăr. Testarea și acceptarea sistemelor 43 3Teste inteligente. După ce ați spus povestea și scenariile într-un format clar și ușor de înțeles, următorul pas este să automatizați povestea și scenariile. Acest lucru le permite să ruleze în timpul dezvoltării pentru a urmări progresul și a detecta erori de regresie. Concluzii si recomandari. Pe de altă parte, avem teste de sisteme care sunt responsabile cu evaluarea funcționării pe tot parcursul procesului, pentru a detecta erorile care pot apărea pentru aceasta, este necesar să se elaboreze o strategie cu teste și să se separe dezvoltarea codului de dezvoltarea interfeței, astfel încât cel mai bine este să implementați teste de sistem. Implementarea acestor două teste software trebuie realizată cu teste riguroase care să îndeplinească anumite standarde și cu coordonarea părților interesate implicate în dezvoltarea sistemului. Testarea și acceptarea sistemului 44 Bibliografie 1. Isabelle Ramos Roman, José Javier Dolado Cosin. Metode de management cantitativ în dezvoltarea de software. Alonso Amo, Loic Martinez Normand. Introducere în dezvoltarea de software. Testarea sistemelor și testarea de acceptare 45 8. -Departamentul de Limbaje și Sisteme de Calculatoare. Structural analiza de sistem. Metode de identificare a bacteriilor în laboratorul de microbiologie.