Scopul tău este ca administrator de sistem
este de a implementa strategii eficiente pentru
maximizarea resurselor computerului dvs.

D. Gunter, S. Barnett, L. Gunter.
Integrarea Windows NT și Unix

Specialiștii IT nu trebuie doar să se familiarizeze cu numeroasele teste publicate în presa informatică, ci și să dezvolte ei înșiși procedurile de testare, care sunt necesare atât la alegerea unui furnizor, cât și la crearea propriei soluții. Prin urmare, vom încerca să răspundem la întrebările care apar în procesul dificil de testare, mai ales când este vorba de sisteme atât de complexe precum serverele..

Ce se testează și de ce?

Adesea, în periodicele informatice există diferite tipuri de recenzii ale programelor, hardware-ului și soluțiilor. Un interes deosebit, de regulă, sunt recenziile comparative ale produselor omogene din punct de vedere funcțional, care prezintă rezultatele testelor. Se crede că aceste tabele detaliate ajută utilizatorul, administratorul și profesionistul IT să fie cel puțin la curent cu ceea ce se întâmplă în acest domeniu și chiar să decidă asupra alegerii produsului.

Deci, ce factori sunt luați în considerare în astfel de cazuri, care este obiectul cercetării și ce tipuri de teste sunt cele mai populare?

Criteriile de testare sunt de obicei:

• funcționalitatea produsului;
• ușurința de învățare;
• ușurință de instalare;
• calitatea documentației și a suportului;
• performanţă;
• Pentru echipamente, designul este uneori luat în considerare.

Există, de asemenea, criterii foarte ambigue. Nu cu mult timp în urmă, una dintre recenziile serverelor web considera „gradul ridicat de integrare cu sistemul de operare” ca un factor pozitiv atunci când se acorda o evaluare generală. Dar dacă o defecțiune a unei aplicații cauzează o defecțiune a sistemului de operare (a cărei probabilitate este proporțională cu gradul de integrare) - este acesta cu adevărat un avantaj?

Sunt o sută de iepuri egal cu un tigru?

Separat, aș dori să mă opresc asupra raportului preț/performanță, care este tipic atunci când evaluăm hardware-ul. La prima vedere, acesta este într-adevăr singurul criteriu obiectiv de legătură specificații sistemul studiat cu portofelul consumatorului. Cu toate acestea, nu totul este atât de simplu pe cât pare. Cert este că abordarea menționată mai sus funcționează numai în momentul achiziției și nu ia în considerare costul de proprietate, siguranța investițiilor în echipamente sau software sau posibilitatea modernizării ulterioare.

Un exemplu tipic este o comparație a modelelor mai vechi de sisteme pe procesoare Intel cu cei mai tineri în linia platformelor RISC. Da, într-adevăr, în intervalul dat gama de prețuri Mașinile cu arhitectură Intel sunt comparabile cu sistemele RISC sau, în unele cazuri, chiar superioare. Cu toate acestea, care este plafonul pentru unele platforme este doar Primul nivel pentru altii etc.

Concluzii: fiți critic cu privire la criteriile după care este evaluat un produs – dvs. și testerii puteți avea gusturi diferite. Încercați să le spuneți fanilor Unix asta de dragul confortului GUI Când configurați sistemul, ar trebui să acceptați necesitatea de a reporni după modificarea parametrilor IP. În ceea ce privește compactitatea unității de sistem, acest lucru este bun până când trebuie să introduceți un hard disk suplimentar în carcasa subțire.

Pe scurt, regândește rezultatele testelor pentru a se potrivi nevoilor tale.

Specificul testării serverului

Dacă computerul nu pornește, este defect.
Dacă nu se oprește, este un server.
Semn popular

În opinia noastră, una dintre cerințele fundamentale pentru servere este fiabilitatea. Performanța, desigur, este de asemenea importantă, deoarece afectează timpul de răspuns al sistemului - cea mai importantă caracteristică din punctul de vedere al utilizatorului, dar disponibilitatea serviciului este determinată de fiabilitate. Actualitatea furnizării sale, relevanța și integritatea informațiilor depind, de asemenea, de fiabilitate.

În plus, ar trebui să se țină cont de faptul că serverele specializate, adică oferind un singur serviciu, sunt în continuare excepția și nu regula. De obicei, un astfel de computer combină o serie de funcții - de exemplu, un server de aplicații poate servi și ca server de fișiere, server de imprimare, controler de servicii de rezervă etc. Serverele de comunicații funcționează de obicei cu mai multe protocoale la nivel de aplicație, fiecare dintre ele servit. prin propriul „daemon””.

Și, în sfârșit, o trăsătură caracteristică a funcționării serverului este prezența sarcinilor de vârf. Motivele apariției lor pot fi foarte diferite - de la începutul zilei de lucru într-o organizație mare (mai ales dacă toți utilizatorii sosesc la timp la serviciu) până la restabilirea unei conexiuni „scăzute” la un furnizor de servicii de internet, când rămâne în așteptare. de e-mail și grupuri de știri atinge serverele de comunicații.

Acești factori, adică cerința pentru o fiabilitate sporită în condițiile furnizării de servicii multiple și a sarcinilor de vârf, ar trebui să fie cheie atunci când se determină ideologia testării serverului.

Din păcate, majoritatea recenziilor publicate în periodice informatice sunt dedicate fie comparării performanței diferitelor soluții hardware pe un set de sarcini de testare efectuate secvenţial, fie testare comparativă a unui anumit serviciu (de exemplu, testarea serverelor Web de la diferiți producători). Una dintre cele mai proaste variante ale acestei abordări este atunci când o analiză comparativă a capabilităților soluțiilor similare se numește testare doar pentru că autorul publicației a efectuat instalarea și a „condus” puțin produsul.

Condiții de test

În primul rând, o mică teorie. Glenford Myers în lucrarea sa „Reliability” software„ dă mai multe „axiome de testare”. Să încercăm, urmându-le, să luăm în considerare ce și cum să testăm.

Din când în când, în presa informatică apar reportaje de natură aproape sportivă: un produs de la firma N a dat rezultate record la testul M Cât de informative sunt testele efectuate de companiile producătoare?

Imposibil de testat propriul program

Adesea testele sunt scrise de angajații companiei pentru un anumit produs. Testele de performanță ale procesorului, scrise în așa fel încât să realizeze avantajele unui anumit procesor, au devenit de vorbă în oraș. De exemplu, dimensiunea programului de testare este selectată ținând cont de plasarea acestuia în memoria cache etc. Prezentarea grafică a unor astfel de rezultate este adesea destul de părtinitoare.

Cunoașterea arhitecturii aplicațiilor și utilizarea acestora a resurselor sistemului de operare permite dezvoltatorilor de software să configureze sistemul în așa fel încât să obțină rezultate maxime pentru programul lor. Nu contează deloc dacă alte programe sau servicii se vor simți confortabil cu astfel de instalări ale sistemului de operare și dacă aplicația supusă testării va „exploata resursele”.

Autorul a întâlnit acest fenomen în timp ce încerca să configureze Netscape Enterprise Server Web sub Solaris (SPARC). Performanța serverului folosind protocolul http a fost crescută de aproape 6 (!) ori (conform testării cu MS InetLoad), dar într-un test complex creșterea s-a dovedit a fi de trei ori, în timp ce performanța serverului POP3 s-a dublat, News serverul a rămas neschimbat, iar SMTP a arătat rezultate de două ori mai proaste decât înainte de modificări.

În plus, producătorii, cunoscând caracteristicile unui anumit set de testare, pot optimiza parametrii sistemului special pentru acesta. Un exemplu în acest sens este pagina Web Netscape, care oferă recomandări despre cum să configurați Netscape Enterprise Server pentru testare folosind SPECweb96.

Testarea este efectuată pentru a detecta erorile

În cazul serverelor și al software-ului server, aceasta înseamnă că dispozitivul ar trebui să fie forțat să funcționeze în modul cel mai nefavorabil - efectuați un test de „supraviețuire”. Acest lucru poate fi realizat prin testarea serverului în următoarea configurație de operare:

• toate serviciile trebuie să funcționeze;
• toate serviciile trebuie testate simultan (test cuprinzător);
• un flux de cereri este trimis către fiecare dintre servicii, simulând activitatea tipică a utilizatorului;
• această activitate ar trebui să crească periodic în timpul testului până când cel puțin un serviciu nu mai poate face față cererilor de procesare.

Două note sunt relevante aici:

1. Modelul comportamentului utilizatorului.

În raport cu utilizatorii, administratorul trebuie să fie pesimist. Testele de supraviețuire ar trebui să fie construite în consecință.

Furnizați suma maxima acțiuni pe care pur și simplu nu ți-ar veni niciodată prin cap să le faci într-o stare normală. Estimați (sau verificați) dacă sistemul va funcționa normal în această situație. Și la fel de important, utilizatorul va primi un mesaj clar de la ea că nu mai merită să facă asta și de ce.

2. Serviciul a încetat să mai gestioneze cereri: opțiuni posibile.

În funcție de gradul de severitate, astfel de eșecuri pot fi împărțite în 4 grupuri:

• performanță scăzută - serviciul nu are timp să proceseze, dar răspunde corect (returnează codul de eroare corespunzător - „Prea multe conexiuni”, etc.);
• terminarea anormală a unui serviciu care nu implică consecințe negative pentru sistem: programul corespunzător și-a încheiat activitatea, s-a descărcat din memorie și resursele sistemului sunt eliberate;
• întreruperea anormală a unui serviciu, care afectează negativ performanța sistemului. Programul fie „se blochează” în lista de procese fără a elibera resurse, fie în timpul procesului de terminare confiscă resurse suplimentare;
• blocarea sistemului - în cel mai bun caz, urmată de o repornire, în cel mai rău caz - cu înghețare.

Pregătiți teste atât pentru intrări corecte, cât și incorecte

Această axiomă o detaliază pe cea anterioară în ceea ce privește fluxurile de informații de intrare.

Cum va reacționa sistemul la trimiterea unei scrisori de câteva zeci de megaocteți? Va rămâne blocat într-o coadă, blocându-vă astfel sistem postal(mai ales dacă conexiunea cu gazda care primește este întreruptă în mod regulat), sau va fi distrusă, iar utilizatorul a anunțat că astfel de acțiuni sunt inacceptabile?

Sfat preluat din aceeași carte de G. Myers: „Încercați să nu lăsați sistemul să enerveze utilizatorul, deoarece acest lucru poate duce la unele situații neașteptate la intrare - Regula #5 de minimizare a erorilor utilizatorului în sistemele de dialog. A fi pesimist nu nu înseamnă să fii mizantrop!”.

Dar serverul de știri - este instalat acolo? dimensiune maximă articole?

Ar putea cineva care intenționează să încarce jumătate din site-ul tău FTP să deschidă trei duzini de sesiuni FTP paralele și, dacă da, cum ar afecta acest lucru canalul tău și munca altora care doresc să viziteze FTP?

Ca exemplu care confirmă corectitudinea acestei abordări, putem aminti incidentul cu crucișătorul de rachete Yorktown, unde o eroare de intrare a operatorului a dus la defecțiune a sistemului de control al motorului. Sau altul, citat de însuși Myers: „Operatorii sistemului de expediere a vehiculelor de poliție SPRINT din New York în timp liber s-au amuzat încercând să o dezactiveze introducând mesaje în mod deliberat incorecte.” Acest lucru s-a întâmplat la începutul anilor 70. Poate că morala s-a înmuiat de atunci, dar acest lucru este puțin probabil.

Evitați testele ireproductibile

În cazul testării serverelor și a software-ului server, această axiomă este deosebit de relevantă. În primul rând, testarea lor necesită prezența unor generatoare de încărcare separate de hardware (Client-Side Load Generators, CSLG) - de obicei, acestea sunt grupuri de stații de lucru care execută partea client a testului și oferă un flux de solicitări către server. În al doilea rând, rezultatele pot fi afectate de starea rețelei care conectează serverul și CSLG. În plus, în multe cazuri, performanța depinde de istoricul apelurilor către server. Majoritatea aplicațiilor server folosesc memorarea în cache. Viteza de accesare a memoriei cache este semnificativ mai mare decât viteza de accesare subsistem de disc. Cache-ul aplicației se poate umple din cauza rulărilor preliminare sau de depanare a programelor de testare - iar rezultatele se pot schimba în consecință. Mai mult, cu testarea complexă, este posibilă influența încrucișată a aplicațiilor - de exemplu, numărul de solicitări complexe procesate pe unitatea de timp către serverele POP3 sau IMAP depinde de dimensiunea spool-ului de e-mail, care poate fi mărită prin testul SMTP anterior . În cele din urmă, setările sistemului de operare afectează performanța.

Toate recenziile decente au o secțiune despre „Cum au fost efectuate testele”. În unele publicații este mai detaliat, în altele mai puțin - se pare că încă nu există un standard pentru descrierea și înregistrarea testării. Un exemplu excelent în acest sens este testul SPECweb96. Acest document ține cont de specificul testării și anume aplicație server. Spre deosebire de descrierile tradiționale, există cerințe de înregistrare setari aditionale sistemul de operare și aplicația aflată în studiu - ceva care de obicei este menționat doar în treacăt chiar și în cele mai bune exemple descrierile de testare.

Poate că voi înșivă vă veți da seama că trebuie să vă efectuați propriul test. Această nevoie poate apărea în următoarele cazuri:

• intenționați să vă extindeți rețeaua, ceea ce va duce la o încărcare crescută a serverelor aflate în ea;
• intenționați să actualizați (sau să schimbați) software-ul;
• decideți să vă schimbați serverul (sau serverele) cu altele mai productive;
• În cele din urmă, poate tocmai v-ați decis să vă dați seama de „limitele creșterii” sistemului dumneavoastră.

Primul pas va fi probabil să te uiți la recenziile publicate. Prin urmare, pentru a utiliza datele obținute de altcineva, tratați-le critic și încercați să înțelegeți, printre altele, motivația persoanelor care au efectuat această testare. Și apoi totul depinde de tine - înțelegerea scopului, alegerea sau redactarea unui set adecvat de teste și efectuarea corectă a testării în sine. Sper că considerentele prezentate în acest articol vă vor ajuta în acest sens.

Capitolul introduce conceptul de calitate și descrie proces tehnologic testarea și discută despre modul în care calitatea și testarea se referă la diferite procese de fabricație. Este prezentată viziunea tradițională a testării ca mecanism de evaluare a calității unui produs și, de asemenea, descrie modul în care testarea ajută la consolidarea și consolidarea arhitecturii la începutul ciclului de dezvoltare.

Ţintă

Scopul testării este de a evalua calitatea produsului. Aceasta înseamnă nu doar o evaluare a produsului final, ci și o evaluare a arhitecturii cu primele etape proces și până la livrarea finală a produsului către clienți. include următoarele.

Verificarea interacțiunilor componentelor

Verificarea integrării corecte a componentelor

Verificarea acurateței implementării tuturor cerințelor

Identificarea defectelor si luarea masurilor necesare pentru eliminarea lor inainte
implementarea software-ului

Calitate

Utilizarea standard a termenului calitate include multe lucruri: de regulă, acest cuvânt denotă absența defectelor și (ceea ce este mult mai important!) conformitatea cu scopul propus; Cu conceptul de calitate asociem ceea ce avem nevoie de la un produs. Un produs (sau o componentă a acestuia) poate să nu fie defect, dar dacă nu face ceea ce trebuie să facă, este la fel de inutil ca un produs cu defecte. Scopul principal al testării este de a evalua calitatea produs final, precum și evaluarea calității componentelor care o compun și a arhitecturii care determină forma acelor componente. Acest lucru este pentru a vă asigura că produsul este

Capitolul 12. G67

îndeplinește sau depășește anumite cerințe (evaluate în funcție de măsuri și criterii de acceptare).

Calitatea unui produs nu poate fi evaluată pe deplin de la sine; software-ul este dezvoltat de o organizație care utilizează un proces, astfel încât calitatea slabă poate fi cauzată de un proces slab sau de un proces la care este dificil de respectat. În consecință, evaluarea calității ia în considerare adesea nu numai calitatea produsului în sine, ci și factorii organizatorici și calitatea procesului.

Cine este responsabil pentru calitatea produsului

Toți membrii echipei de proiect sunt responsabili pentru producerea unui produs de calitate. Dacă calitatea nu a fost inclusă inițial în produs, atunci aceasta nu mai poate fi „adăugată ulterior” prin efectuarea unor acțiuni active pentru a garanta calitatea.

Sarcina de a testa nu este garanție calitate și estima oferind în același timp feedback pentru a rezolva problemele de calitate la un cost și un timp rezonabil. Sarcina testatorului este să evalueze calitatea și să ofere feedback, iar misiunea echipei de proiect este să creeze artefacte care să îndeplinească cerințele și parametrii de calitate.

Testarea într-un ciclu de viață iterativ

Testarea nu este o activitate separată sau o fază a unui proiect în care se realizează evaluarea calității. Dacă dezvoltatorii au nevoie de feedback în timp util cu privire la problemele legate de calitatea produselor, atunci testarea ar trebui să fie efectuată pe tot parcursul ciclului de viață: funcționalitatea prototipurilor timpurii poate fi testată; stabilitatea, acoperirea și performanța arhitecturii (puteți corecta oricând deciziile proaste); În plus, puteți testa produsul final și puteți evalua gradul de pregătire al acestuia pentru transferul în mâinile clienților. Există o părere comună că testarea este verificarea finală a performanței globale; totuși, în această situație, principalul avantaj al testării este ratat: capacitatea de organizare părere când mai este timp (și resurse) pentru a lua măsurile necesare.

Clasificarea testelor

Pentru a evalua calitatea unui produs sunt necesare diferite tipuri de teste. Următoarele caracteristici pot fi folosite pentru a clasifica testele.

Parametru de calitate testat - ce parametru de calitate este testat?

faza de testare- punct din ciclul de viață în care este efectuat
testarea

Tipul testului- o sarcină specifică a unui test individual, de obicei asociată cu unul
parametru de calitate

Parametrii de calitate

Există tipare care vă permit să identificați probleme legate de calitate (de regulă, aproape toate sistemele au același tip de probleme). Ca rezultat, următoarele ar trebui evaluate pentru fiecare produs.

Fiabilitate

Software-ul „rezistă” la apariția erorilor în timpul execuției: nu există blocări, blocări, scurgeri de memorie etc.

Funcționalitate

Software-ul implementează cazurile de utilizare necesare sau are comportamentul așteptat.

I Productivitate

Software-ul și sistemul funcționează, răspund prompt la evenimente predeterminate și continuă să funcționeze acceptabil în condițiile lumii reale. caracteristici operaționale(de exemplu, sub sarcină mare, perioade lungi de lucru etc.). Testarea performanței se concentrează pe atingerea cerințelor funcţionalitate satisfacând în același timp cerințele nefuncționale ale sistemului.

Pentru fiecare dintre parametri specificati calitatea necesită ca unul sau mai multe teste să fie efectuate la una sau mai multe etape de testare. În plus, există și alți parametri de calitate, a căror evaluare poate fi mai subiectivă: ușurință în utilizare, extindere, flexibilitate etc. O evaluare calitativă a acestor parametri de calitate ar trebui făcută cu fiecare ocazie.

Etape de testare

Testarea nu trebuie considerată o activitate separată efectuată în întregime simultan. Testarea se desfășoară în diferite etape de dezvoltare a software-ului și are ca scop verificarea diferitelor obiecte (ținte de testare). Etapele testării progresează de la testarea elementelor mici ale sistemului, cum ar fi componentele (testarea unitară) până la testare. testarea sistemelor finalizate (testarea sistemului). Să enumerăm etapele de testare existente și sarcinile acestora.

Testarea unitară

Elementele minime ale sistemului sunt testate. Timpul de testare, de regulă, coincide cu timpul de implementare a elementelor.

Testare integrală

Unitățile integrate (sau componentele sau subsistemele) sunt testate.

Testarea sistemului

Aplicațiile și sistemele finalizate (formate din una sau mai multe aplicații) sunt testate.

Testarea de acceptare

Aplicația (sau sistemul) finalizată este testată de utilizatorii finali (sau reprezentanții utilizatorilor finali). Scopul testării: pentru a determina gradul de pregătire pentru implementare a produsului.

Trebuie amintit că, în momente diferite ale ciclului de viață, etapele de testare au loc cu diferite accente. Prototipul conceptului timpuriu, utilizat în faza de cercetare pentru a evalua viabilitatea viziunii produsului, va fi supus diferitelor teste de acceptare. Prototipul arhitectural dezvoltat în faza de rafinare a planului va fi supus testării integrale și a sistemului, menite să verifice integritatea arhitecturală și performanța elementelor arhitecturale cheie, deși în acest moment o mare parte din codul sistemului este sub formă de programe surogat. Etapele de testare nu sunt „faze” predefinite care sunt executate secvenţial mai aproape de Sfârşit proiect; dimpotrivă, într-un ciclu de viață iterativ, testarea începe devreme și are loc frecvent.

Tipuri de teste

Există multe tipuri de teste, fiecare dintre ele se concentrează pe un obiectiv de testare specific și testează doar un aspect al calității software-ului. Deoarece testarea are loc pe parcursul întregului ciclu de viață, software-ul testat poate fi o singură bucată de cod, o unitate integrală sau o aplicație (sau sistem) completă. Să numim cele mai comune tipuri de teste.

Test de atestare

Compară performanța unei ținte de testare și a unui obiect standard, cum ar fi software-ul existent, sau evaluează performanța conform unui sistem de măsuri.

Test de configurare

Verifică funcționarea acceptabilă a țintei de testare în diferite configurații (software sau hardware).

Teste funcționale

Se verifică în general funcționarea obiectului de testare țintă, adică. implementarea corectă a precedentelor cerute.

Teste de instalare

Verifică instalarea corectă a țintei de testare, posibilitatea instalării cu succes în diferite configurații sau în conditii diferite(de exemplu, dacă spațiul pe disc este insuficient).

Testare de integritate

Se verifică fiabilitatea obiectului de testare țintă, stabilitatea acestuia și rezistența la erori în timpul execuției.

Test de sarcină

Verifică dacă performanța țintei de testare este acceptabilă într-o varietate de condiții de operare (inclusiv număr diferit utilizatori, tranzacții etc.) cu o configurație neschimbabilă.

Teste de performanță

Verifică dacă performanța țintei de testare este acceptabilă în diferite configurații, menținând în același timp caracteristicile de funcționare constante.

Testarea modului greu

Verifică performanța acceptabilă a țintei de testare în condiții de urgență sau critice, cum ar fi resurse limitate sau extreme număr mare utilizatorii.

Testare de regresie

Testarea de regresie este o tehnică de testare în care testele efectuate anterior sunt re-executate versiune noua obiect țintă. Scopul acestui tip de testare este de a se asigura că calitatea obiectului țintă nu se deteriorează (regresează) atunci când se adaugă noi caracteristici la acel obiect. Testarea de regresie este necesară pentru

Detectarea precoce maximă a defectelor;

Verificarea ca modificările de cod să nu introducă noi defecte sau
restaurarea celor vechi.

Testarea de regresie poate implica rularea oricărui tip de test din nou și din nou. De obicei, o astfel de testare este efectuată în fiecare iterație și constă în reluarea testelor efectuate în iterațiile anterioare.

Model de testare

Testarea modelului- este o reprezentare a ceea ce va fi testat și a modului în care se va face testarea. Acest model este o reprezentare a modelelor de proiectare și implementare, ilustrând testele reale și parametrii țintă legați de testare. Modelul de testare include un set de sarcini de control, proceduri de testare, scenarii de testare și rezultatele așteptate ale testelor, precum și o descriere a relației dintre acestea.

Să aruncăm o privire mai atentă asupra componentelor modelului de testare.

Sarcini de control

Un set de date de testare, condiții de execuție a testului și rezultate așteptate dezvoltate pentru o anumită sarcină de testare. Sarcinile de control pot fi determinate din precedente, documentație de proiectare sau cod de program. Sarcina de control poate fi implementată folosind una sau mai multe metode de testare.

Metode de testare

Un set de instrucțiuni detaliate pentru stabilirea și efectuarea sarcinilor de control și evaluarea rezultatelor obținute. Folosind o singură metodă de testare, pot fi implementate una sau mai multe sarcini de control. O metodologie de testare poate fi, de asemenea, utilizată pentru a implementa doar o parte a unei sarcini de testare, cum ar fi un flux de caz de utilizare alternativ.

Scenarii de testare

Instrucțiuni care automatizează implementarea unei părți sau a întregii proceduri de testare (sau proceduri de testare).

Clase de testare și componente

Clase și componente care implementează proiecte de testare, inclusiv drivere și programe surogat.

Testarea interacțiunilor

Interacțiunile sunt reprezentate sub forma unei diagrame de interacțiune sau a unei diagrame secvențe și reflectă fluxul de mesaje ordonat în timp între componentele testului și ținta testului care are loc în timpul procesului de testare.

Note

Informații text care descriu restricțiile sau Informații suplimentare, utilizat în modelul de testare. Notele pot fi atașate la orice element al modelului de testare.

Elementele principale ale modelului de testare și relațiile lor sunt prezentate în Fig. 12.1.

Orez. 12.1. Sarcini de testare, metode de testare și scenarii de testare pentru un bancomat

Interpreți și artefacte

În procesul de testare sunt implicați doi actori principali.

Dezvoltator de testare responsabil de planificarea, dezvoltarea, implementarea testelor și
evaluarea testării. Responsabilitățile sale includ crearea unui plan și model de testare
dezvoltarea, implementarea metodelor de testare și evaluarea acoperirii testelor, a rezultatelor
tats și eficacitatea testului.

Tester responsabil de executare testarea sistemului. În obligația sa
include configurarea și desfășurarea testelor, evaluarea performanței testelor,
recuperarea din erori, evaluarea rezultatelor testelor și înregistrarea
defecte identificate.

Dacă este necesar un cod specific pentru a susține testarea (de exemplu, drivere sau surogate trebuie să fie dezvoltate), atunci procesul trebuie să implice și un dezvoltator și un designer în roluri similare cu cele definite în capitolele 10 și 11.

Performanții și artefactele procesului de testare sunt prezentate în Fig. 12.2. Să ne uităm la artefactele cheie ale acestui proces.

Planul de testare, care conțin informații despre scopurile și obiectivele testării.
Planul de testare determină ce strategii vor fi utilizate și care
sunt necesare resurse pentru a efectua testarea.

Model de testare descris mai devreme.

Rezultatele testuluiși datele colectate în timpul executării testului.

Modelul volumului de muncă pentru teste de performanta; defineste
variabilele și valorile acestora utilizate în diverse operaționale
teste pentru modelarea sau simularea caracteristicilor externe
performeri, funcții efectuate de utilizatorii finali, volum
aceste funcții și încărcarea creată de aceste funcții.

defecte, obținute ca urmare a „testelor nereușite” sunt una dintre
tipuri de cereri de modificare (vezi capitolul 13).

Pe lângă artefactele enumerate, următoarele artefacte trebuie create atunci când se dezvoltă suport software pentru un test.

Pachete de testare și clase

Subsisteme și componente de testare

Evaluarea finală a testului este utilizată ca parte a evaluării iterației proiectului și a evaluării periodice a stării (vezi Capitolul 7, „Fluxul de lucru pentru managementul proiectului”).

Proces tehnologic

Un proces tipic de testare, elementele sale principale și dependențele dintre ele sunt prezentate în Fig. 12.3.

Pregătirea pentru testare

Scopul acestui element de flux de lucru este de a defini și descrie testarea care va fi efectuată. Pentru a face acest lucru, este creat un plan de testare care conține cerințele de testare și strategiile de testare. Se poate dezvolta un singur plan de testare care descrie toate tipurile de teste care trebuie efectuate sau poate fi creat un plan separat pentru fiecare tip de test. Pregătirea testului se realizează în așa fel încât activitățile de testare să fie măsurabile și gestionabile.

Dezvoltarea testelor

Scopul acestui element de flux de lucru este de a defini, descrie și crea modelul de testare și artefactele asociate acestuia. Un proiect de testare este creat pentru a se asigura că software-ul utilizat pentru testare este organizat corespunzător și îndeplinește cerințele specificate. În timpul acestui element al fluxului de lucru, designerul de testare analizează ținta testului, dezvoltă un model de testare și (în cazul testării performanței) un model de volum de lucru. Proiectarea testelor transformă cazurile de utilizare în sarcini de acceptare și control al sistemului, care apoi ghidează proiectarea elemente de program efectuarea testării.

Implementarea testului

Scopul acestui element de proces este de a implementa procedurile de testare definite în secțiune Pregătirea pentru testare. Metodele de testare sunt create, de regulă, într-un mediu de automatizare a testelor sau într-un mediu de programare. Artefactul rezultat este versiune electronica procedură de testare, numită scenariu de testare.

Dacă este necesar un anumit cod pentru a susține sau a efectua testarea (de exemplu, instrumentele de testare, driverele sau programele surogat trebuie dezvoltate), atunci dezvoltatorul, designerul și dezvoltatorul de testare sunt implicați în munca de creare a acestuia.

Executarea testelor in faza de testare integrala

Scopul acestui element de proces este de a asigura integrarea corectă componentele sistemului, și de asemenea verificând dacă această uniune are comportamentul corect. Integratorul de sistem este responsabil pentru compilarea și combinarea sistemului în blocuri funcționale crescânde. Pentru fiecare astfel de bloc, funcțiile adăugate sunt testate, sunt efectuate teste de regresie și sunt preluate rezultatele testelor.

În timpul unei iterații, testarea integrală este efectuată de mai multe ori până când întregul sistem este integrat cu succes (determinat de scopul iterației).

Executarea testelor în timpul fazei de testare a sistemului

Scopul acestui element al procesului tehnologic este de a asigura buna functionare a intregului sistem. Integratorul de sistem compilează și integrează sisteme în unități funcționale în creștere. Fiecare element adăugat

trebuie să treacă teste de funcționalitate; in plus, sunt executate toate testele efectuate anterior pe fiecare proiect (teste de regresie).

În timpul unei singure iterații, testarea sistemului este efectuată de mai multe ori până când întregul sistem este integrat cu succes (determinat de scopul iterației) și sunt îndeplinite criteriile de succes a testului sau de finalizare a sistemului.

Test de evaluare

Scopul acestui element al procesului tehnologic este de a dezvolta și evalua măsuri cantitative de testare care să permită determinarea calității obiectului de testare țintă și a procesului de testare. Acest lucru se realizează prin revizuirea și evaluarea rezultatelor testelor, identificarea și înregistrarea cererilor de modificare și calcularea măsurilor cheie ale testelor.

Suport instrumental

Deoarece testarea este un efort iterativ efectuat pe tot parcursul ciclului de dezvoltare, este nevoie de suport pentru instrumente pentru a se asigura că testarea începe devreme și are loc des; Testarea manuală nu este suficient de eficientă și nu vă permite să evaluați în detaliu software-ul dezvoltat. Acest ultim punct este valabil mai ales pentru testele de performanță și sarcină, în care sarcina de lucru iar o cantitate semnificativă de date trebuie acumulată.

Rational Software Corporation oferă următoarele instrumente pentru a sprijini automatizarea testelor și procesul de testare în general.

TestStudio este o suită unelte, sprijinind implementarea
efectuarea de teste și evaluarea rezultatelor testelor. Instrumentele TestStudio permit
tester pentru a crea scripturi de testare cu interfață grafică
chipul utilizatorului. Aceste scenarii se concentrează pe astfel de parametri
calități precum fiabilitatea, funcționarea și performanța. Inclus în set
TestStudio include următoarele instrumente.

Robotul acceptă execuția testelor, permițând testerilor să creeze și să reproducă scripturi de testare cu o interfață grafică cu utilizatorul și să compare rezultatele obținute și rezultatele așteptate.

LogViewer captează rezultatele testelor și oferă un raport pentru a evalua performanța testului.

TestManager acceptă planificarea, proiectarea și evaluarea testelor, vă permite să determinați acoperirea testului și generează rapoarte de starea testului.

TestFactory acceptă testarea fiabilității prin generarea și executarea automată a scripturilor de testare. În plus, acest instrument raportează în mod programatic acoperirea testelor.

PerformanceStudio rulează scripturi de testare a utilizatorului virtual
corp, folosind teste de performanță și unele funcții
teste onale.

DevelopmentStudio acceptă fluxul de lucru de testare și
include următoarele instrumente.

Rational Purify pentru a izola erorile de rulare greu de găsit.

Rational PureCoverage* pentru a identifica zonele de cod care nu testează și pentru a efectua analize de acoperire a codului.

Rational Quantify* pentru a identifica fragmentele de cod care limitează performanța.

În plus, Rational Unified Process oferă mentori de instrumente pentru majoritatea acestor instrumente.

rezumat

Testarea vă permite să evaluați calitatea produsului fabricat.

Testarea este un proces iterativ efectuat în toate fazele vieții.
ciclu lung; vă permite să vă organizați din timp verso comunicare pe probleme de calitate
va, folosit pentru a îmbunătăți produsul în timpul dezvoltării și construcției acestuia
nia. Testarea nu trebuie efectuată numai la sfârșitul ciclului de viață
(să accepte sau să respingă produsul final); trebuie să fie de nedespărțit
o parte integrantă a mecanismului de feedback constant.

Toată lumea este responsabilă pentru calitate. Calitatea nu poate fi introdusă de organismul de testare
ție. Testarea are ca scop doar evaluarea calității și organizarea
feedback în timp util pentru a îmbunătăți calitatea sistemului.

Oferă un mecanism de feedback,
permițând măsurarea calității și identificarea defectelor. Testarea efectuată
apare în primele etape ale proiectului – începe cu teste de planificare și unele
a doua evaluare (uneori efectuată chiar și în faza de cercetare) și a continuat
crește pe măsură ce proiectul avansează.

18.09.2003 Alexander Petrenko, Elena Britvina, Sergey Groshev, Alexander Monakhov, Olga Petrenko

Mulți oameni știu să dezvolte un program; De macar, toată lumea a făcut asta de multe ori, dar explicarea modului de a crea un program de înaltă calitate se dovedește a fi mult mai dificil.

Industria software-ului încearcă în mod constant să rezolve problema calității, dar cât de semnificativ este succesul acesteia? acest moment Este destul de greu de spus. In articol despre care vorbim despre o nouă generație de instrumente de testare care sunt concepute pentru a îmbunătăți calitatea programelor. Cu toate acestea, instrumentele, chiar și cele automate, nu pot ajuta dacă sunt utilizate incorect. Prin urmare, o discuție despre instrumente este precedată de o declarație a prevederilor generale pentru testarea „corectă”.

Abordări pentru îmbunătățirea calității programului

„Lupta pentru calitate” a programelor poate fi dusă în două moduri. Primul mod este „simplu”: adunați o echipă de programatori buni cu experiență în proiecte similare, oferiți-le o sarcină bine definită, instrumente bune, creați condiții bune de muncă. Este foarte probabil că va fi posibil să se dezvolte un sistem software de bună calitate.

A doua modalitate nu este atât de simplă, dar vă permite să obțineți produse software de înaltă calitate chiar și atunci când condițiile enumerate nu pot fi îndeplinite - nu există destui programatori buni, claritate în livrarea sarcinii etc. Această cale necesită standardizarea proceselor de dezvoltare: introducerea de cerințe uniforme pentru etapele de lucru, documentare, organizarea de întâlniri regulate, efectuarea de inspecții de cod etc. Unul dintre primele progrese pe acest front a fost introducerea conceptului de ciclu de viață al unui sistem software, care a definit clar necesitatea de a lua în considerare multe sarcini, fără a le rezolva pe care nu se poate conta pe succesul unui proiect software.

În cea mai simplă versiune, setul de etape ale ciclului de viață este următorul:

• analiza cerințelor;
• proiectare (preliminar și detaliat);
• codificare și depanare („programare”);
• testare;
• operare si intretinere.

O diagramă standardizată a ciclului de viață cu o reglementare clară a lucrărilor necesare și o listă de documentație relevantă a stat la baza așa-numitului model „cascada” sau cascadă. Model cascadă implică o împărțire rigidă a procesului de dezvoltare a software-ului în etape, iar trecerea de la o etapă la alta se realizează numai după ce lucrările din etapa anterioară sunt complet finalizate. Fiecare etapă se încheie cu lansarea unui set complet de documentație, suficient pentru ca dezvoltarea să poată fi continuată de o altă echipă. Modelul cascadă a devenit dominant în standardele proceselor de dezvoltare ale DoD. Mulți, vrând-nevrând, chiar deviând de la acest model, au fost în general de acord cu caracterul rezonabil și utilitatea acestuia.

Modelul cascadă a necesitat ca toate cerințele să fie formulate cu acuratețe și complet; modificarea cerințelor a fost posibilă numai după finalizarea tuturor lucrărilor. Modelul cascadă nu a răspuns la întrebarea ce trebuie făcut atunci când cerințele se schimbă sau înțelegerea acestor cerințe se modifică direct în timpul dezvoltării.

La sfârșitul anilor 80 a fost propus așa-numitul model în spirală, iar metoda dezvoltării iterative și incrementale (IID) a fost dezvoltată și testată în practică. Modelul în spirală a ținut cont de problemele modelului de cascadă. Accentul principal al modelului în spirală este pe natura iterativă a procesului. Sunt descrise experiențe de utilizare a IID cu o durată de iterație de numai jumătate de zi. Fiecare iterație se încheie cu o nouă versiune a software-ului. La fiecare versiune, cerințele pentru sistemul țintă sunt clarificate (și eventual modificate) și se iau măsuri pentru a satisface noile cerințe. În general, Rational Unified Process (RUP) urmează și acest model.

A rezolvat problema de calitate? Doar într-o oarecare măsură.

Problema îmbunătățirii calității software-ului în general și a îmbunătățirii calității testării atrage o atenție din ce în ce mai mare; Universitățile introduc discipline speciale în testare și asigurare a calității, formează specialiști specializați în testare și ingineri de asigurare a calității. Cu toate acestea, erorile costă în continuare între 20 și 60 de miliarde de dolari anual doar în Statele Unite. În același timp, aproximativ 60% din pierderi cad pe umerii utilizatorilor finali. Apare o situație în care consumatorii sunt nevoiți să cumpere bunuri vădit defecte.

Cu toate acestea, situația nu este fără speranță. Un studiu realizat de Institutul Național de Standarde și Tehnologie din SUA a constatat că pierderile asociate cu defecțiunile software ar putea fi reduse cu aproximativ o treime dacă s-ar investi mai mult efort în infrastructura de testare, în special în dezvoltarea instrumentelor de testare.

Care este direcția atacului principal? Ce sugerează „cele mai bune practici”?

În anii 80 și 90, răspunsul la această întrebare suna cam așa. Cele mai scumpe greșeli sunt făcute în primele faze ale ciclului de viață - acestea sunt erori în definirea cerințelor, alegerea unei arhitecturi și designul la nivel înalt. Prin urmare, trebuie să ne concentrăm pe găsirea erorilor în toate fazele, inclusiv în cele mai timpurii, fără a aștepta până când acestea sunt descoperite în timpul testării unei implementări gata făcute. În general, teza suna așa: „Reduceți timpul dintre moment? erori și momentul detectării acesteia.” Teza în ansamblu este bună, dar nu foarte constructivă, deoarece nu oferă recomandări directe despre cum să reduceți acest timp.

ÎN anul trecutÎn legătură cu apariția metodelor care sunt de obicei notate cu epitetul agil („agil”, „agil”), sunt propuse și implementate noi metode constructive pentru detectarea timpurie a erorilor. Sa spunem modele moderne, cum ar fi Microsoft Solutions Framework (MSF) și eXtreme Programming (XP), oferă următoarele recomandări pentru dezvoltarea testelor:

• toate testele necesare trebuie să fie gata până la implementarea unei anumite părți a programului; în acest caz, de obicei un test corespunde unei cerințe;
• un set de teste create anterior trebuie executat (sub rezerva cerințelor neschimbate) pe orice versiune a programului;
• dacă se fac modificări la cerințe, atunci testele ar trebui schimbate cât mai repede posibil.

Cu alte cuvinte, un bug - fie că este vorba de cerințe, în proiectare sau în implementare - nu trăiește mai mult decât în ​​momentul în care testul este rulat pentru a verifica implementarea această cerință. Aceasta înseamnă că, deși timpul astronomic dintre „introducerea” unei erori și detectarea acesteia se poate dovedi a fi mare, nu s-a irosit prea mult efort, iar implementarea nu a avut timp să meargă departe.

Nu ne vom opri asupra corectitudinii acestor prevederi și asupra eficienței lor. După cum se întâmplă adesea, prin efect inovația s-a dovedit a fi mai semnificativă decât implementarea efectivă a acestei idei. În acest caz, discuțiile despre metodele agile au dus la o nouă înțelegere a locului testării în procesul de dezvoltare a software-ului. S-a dovedit că testarea în sensul larg al cuvântului, adică. dezvoltarea, sărirea peste teste și analiza rezultatelor rezolvă nu numai problema găsirii celor deja admiși codul programului erori. O atitudine serioasă față de testare vă permite să preveniți erorile: înainte de a scrie codul, ar trebui să vă gândiți la ce erori ar putea fi făcute în el și să scrieți un test care vizează aceste erori, pe măsură ce calitatea codului se îmbunătățește.

În noile modele de ciclu de viață, testarea pare să se dizolve în alte faze de dezvoltare. Astfel, MSF nu conține o fază de testare - testele sunt întotdeauna scrise și folosite!

Asa de, diverse lucrăriÎn timpul procesului de producție, programele trebuie să fie bine integrate cu activitățile de testare. În consecință, instrumentele de testare trebuie să fie bine integrate cu multe alte instrumente de dezvoltare. Din marii producatori instrumentele de dezvoltare software, primii care au înțeles acest lucru au fost Telelogic (un set de instrumente pentru proiectarea, modelarea, implementarea și testarea software-ului de telecomunicații, bazat pe notații SDL/MSC/TTCN) și Rational Software (un set similar, bazat în principal pe notația UML) . IBM a făcut următorul pas, începând să integreze capabilitățile instrumentelor Rational în mediul de dezvoltare software Eclipse.

Teza XP - „Scrieți un test înainte de a-l implementa” - este bună ca slogan, dar în realitate este la fel de neconstructivă. Pentru sistemele software mari este necesar să se dezvolte teste pentru diverse scopuri: teste de module, teste de integrare sau componente, teste de sistem.

Trei componente ale testării - o excursie în teorie

Testarea unitară sunt expuse module mici (proceduri, clase etc.). Când se testează un modul relativ mic de 100-1000 de linii în dimensiune, este posibil să se verifice, dacă nu toate, atunci cel puțin multe ramuri logice în implementare, căi diferite în graficul dependenței de date și valorile limită ale parametrilor. În conformitate cu aceasta, sunt construite criteriile de acoperire a testelor (toți operatorii, toate ramurile logice, toate punctele de limită etc. sunt acoperite).

Verificarea corectitudinii tuturor modulelor, din păcate, nu garantează funcționarea corectă a sistemului de module. Literatura de specialitate discută uneori modelul „clasic” de organizare necorespunzătoare a testării unui sistem de module, adesea numit metoda „salt mare”. Esența metodei este să testați mai întâi fiecare modul separat, apoi să le combinați într-un sistem și să testați întregul sistem. Pentru sistemele mari, acest lucru este nerealist. Cu această abordare, se va cheltui mult timp pentru localizarea erorilor, iar calitatea testării va rămâne scăzută. O alternativă la „Marele Salt înainte” - testarea integrării Când un sistem este construit în etape, grupuri de module sunt adăugate treptat.

Proliferarea tehnologiilor componente a dat naștere termenului "testarea componentelor" Cum caz special testarea de integrare.

Un produs software complet implementat este supus testarea sistemului. Pe în această etapă Testerul nu este interesat de implementarea corectă a procedurilor și metodelor individuale, ci de întregul program în ansamblu, așa cum îl vede el Utilizator final. Testele se bazează pe Cerințe generale la program, incluzând nu numai implementarea corectă a funcțiilor, ci și performanța, timpul de răspuns, rezistența la eșecuri, atacuri, erori ale utilizatorului etc. Pentru testarea sistemului și a componentelor, sunt utilizate tipuri specifice de criterii de acoperire a testelor (de exemplu, sunt acoperite toate scenariile de lucru tipice, toate scenariile cu situații anormale, compozițiile perechi ale scenariilor etc.).

Instrumente de testare - Practică reală

După ce am finalizat excursia în metodologie, să revenim la întrebarea ce instrumente de testare sunt utilizate în prezent și cât de mult corespund noilor idei despre locul testării în procesul de dezvoltare a programului.

În acest moment, următoarele etape de lucru sunt cel mai automatizate: execuția testului, colectarea datelor primite, analiza acoperirii testelor (pentru testarea unitară, se colectează de obicei informații despre operatorii acoperiți și ramurile logice acoperite), urmărirea stării de procesare a cererilor pentru corectarea erorii.

Vom revizui instrumentele de testare în ordine inversă - de la testarea sistemului la testarea unitară.

Instrumente larg răspândite de testare a aplicațiilor cu grafică interfața cu utilizatorul. Ele sunt adesea numite instrumente de testare funcțională. Dacă nivelul de responsabilitate al aplicației nu este ridicat, atunci o astfel de testare poate fi limitată; Acest tip de testare este cel mai ieftin.

În acest tip de testare, instrumentele de înregistrare și redare sunt utilizate pe scară largă; Cele mai cunoscute produse includ Rational Robot (IBM/Rational), WinRunner (Mercury Interactive), QARun (Compuware). Alături de acestea, există instrumente pentru interfețele terminalelor text, de exemplu, QAHiperstation de la Compuware.

Pentru testarea încărcării sistemului a aplicațiilor Web și altele sisteme distribuite Setul de instrumente LoadRunner de la Mercury Interactive este utilizat pe scară largă; nu are ca scop generarea de scenarii de testare sofisticate, dar oferă material bogat pentru analiza performanței, căutare blocajele, afectând performanța unui sistem distribuit.

O schemă generală aproximativă pentru utilizarea instrumentelor de înregistrare și redare este următoarea:

• veniți cu un scenariu (de preferință bazat pe o analiză sistematică a cerințelor);
• desfășurați o sesiune de lucru în conformitate cu acest scenariu; instrumentul va înregistra toate informațiile de intrare provenite de la utilizator (apăsări de taste pe tastatură, mișcări ale mouse-ului etc.) și va genera scriptul corespunzător.

Scriptul rezultat poate fi rulat de mai multe ori, făcându-i mici modificări dacă este necesar.

Când scrieți un script, puteți face opriri pentru a indica ce răspunsuri ale sistemului într-o anumită situație ar trebui considerate corecte, ce variații ale datelor introduse de utilizator sunt posibile etc. Dacă există astfel de variații, data viitoare când testul este jucat, instrumentul va selecta independent una dintre alternativele definite. Dacă răspunsul sistemului nu se potrivește cu răspunsul așteptat, va fi înregistrată o eroare.

Cu toate acestea, capacitățile acestui tip de testare sunt limitate:

• înregistrarea scripturilor este posibilă numai dacă aveți un prototip al viitoarei interfețe grafice;
• Suportul pentru script necesită foarte multă muncă; este adesea mai ușor să scrii din nou un script decât să-l editezi;
• Ca urmare, nu este eficient să se lucreze la crearea de teste în paralel cu dezvoltarea sistemului în sine și, în general, este imposibil înainte de a crea un prototip.

Următoarea clasă de instrumente este instrumente de testare a componentelor. Un exemplu este Test Architect (IBM/Rational). Astfel de instrumente ajută la organizarea testării aplicațiilor create folosind una dintre tehnologiile componente (de exemplu, EJB). Este furnizat un set de șabloane pentru crearea diferitelor componente ale unui program de testare, în special teste pentru module, scripturi și stub-uri.

Îndeplinește acest instrument cerințele pentru dezvoltarea de teste avansate? În general, da: pentru a crea un test este suficientă o descriere a interfețelor componentelor. Dar există și puncte slabe, care, totuși, sunt inerente majorității celorlalte instrumente. Astfel, scriptul de testare trebuie scris manual. În plus, nu există un sistem unificat pentru specificarea criteriilor de acoperire a testelor și conectarea acestor criterii cu cerințele funcționale ale sistemului.

Ultima dintre clasele de instrumente discutate aici este instrumente de testare unitară. Un exemplu este Test RealTime (IBM/Rational), conceput pentru testarea modulelor în C++. O componentă importantă a acestui instrument este mecanismul „declarațiilor” de verificare (afirmație). Folosind instrucțiuni, puteți formula cerințe pentru datele de intrare și de ieșire ale funcțiilor/metodelor claselor sub formă de condiții logice, în formă similară puteți seta cerințe invariante pentru datele obiectului. Aceasta este o îmbunătățire semnificativă față de Test Architect. Aparatul de afirmare vă permite să reprezentați în mod sistematic cerințele funcționale și, pe baza acestor cerințe, să construiți criterii de acoperire a testelor (cu toate acestea, Test RealTime nu oferă suport automat pentru analiza acoperirii).

În principiu, acest instrument poate fi folosit pentru dezvoltarea de teste avansate, dar aceeași funcție de generare a acțiunilor de testare în sine rămâne nerealizată - această muncă trebuie făcută manual. Nu există suport tehnic sau metodologic pentru reutilizarea testelor și afirmărilor.

O nouă generație de instrumente care urmează o testare bazată pe model sau o abordare de testare bazată pe specificații oferă o soluție la aceste probleme.

Cum pot ajuta modelele

În mintea unui dezvoltator și tester există întotdeauna unul sau altul „model” al structurii programului, precum și un „model” al comportamentului său dorit, pe baza căruia, în special, sunt compilate liste de proprietăți care trebuie testate și sunt create exemple de test corespunzătoare. (Rețineți că aceasta diferite modele; primele sunt adesea numite arhitecturale, iar cele din urmă funcționale sau comportamentale.) Sunt adesea compilate din documente sau discuții informale.

Dezvoltarea modelelor și specificațiilor este asociată cu „matematizarea” programării. Încercările de a folosi diverse abordări matematice pentru a proiecta și chiar a genera programe au fost făcute încă din primii ani ai computerelor. Succesul relativ a fost obținut în teoria compilatorului, baze de date relaționale date și în mai multe domenii înalt specializate; Nu a fost posibil să se obțină rezultate semnificative în majoritatea domeniilor practice. Mulți oameni au devenit sceptici cu privire la metodele formale în programare.

O nouă creștere a interesului pentru metodele formale a avut loc în prima jumătate a anilor '90. A fost cauzată de primele rezultate obținute folosind modele formale și specificații formale în testare.

Beneficiile testării bazate pe model au fost văzute ca:

• testele bazate pe specificarea cerințelor funcționale sunt mai eficiente deoarece sunt mai concentrate pe verificarea funcționalității decât testele bazate doar pe cunoașterea implementării;
• Testele de autoverificare pot fi create pe baza specificațiilor formale, deoarece criteriile de verificare a rezultatelor sistemului țintă pot fi adesea extrase din specificațiile formale.

Cu toate acestea, nu a existat nicio claritate cu privire la calitatea acestor teste. Modelele sunt de obicei mai simplu de implementat, așa că s-ar putea presupune că testele care „acoperă” bine modelul sunt prea slabe pentru a acoperi sistemele reale. A fost necesară experimentarea amplă în proiecte reale.

Un model este o anumită reflectare a structurii și comportamentului sistemului. Modelul poate fi descris în termeni de stare a sistemului, acțiuni de intrare asupra acestuia, stări finale, fluxuri de date și fluxuri de control, rezultate returnate de sistem etc. Sunt folosite seturi diferite de termeni pentru a reflecta diferite aspecte ale sistemului. O specificație formală este o descriere completă a unui model de sistem și a cerințelor pentru comportamentul acestuia în termenii unei anumite metode formale. Pentru a descrie caracteristicile unui sistem, puteți utiliza mai multe modele în cadrul mai multor formalisme. De obicei, cu cât o notație de modelare este mai generală, cu atât este mai mare dificultate în automatizarea testării programelor pe baza modelului/specificației descrise în notația respectivă. Unele notații și limbi se concentrează mai mult pe accesibilitatea și transparența descrierii, altele - pe analiza și traducerea ulterioară, în special pe traducerea specificației într-un test. S-au încercat să se dezvolte un limbaj formal de specificare care să îndeplinească cerințele utilizării industriale (de exemplu, metodologia RAISE), dar nu au găsit o utilizare pe scară largă.

Există mai multe notații formale de specificații care au devenit deja clasice: VDM, Z, B, CCS, LOTOS etc. Unele dintre ele, de exemplu, VDM, sunt folosite în primul rând pentru prototipare rapidă. Limbajul B este convenabil pentru analiză, în special pentru verificarea analitică a modelelor. Toate aceste limbi sunt utilizate activ în cadrul programelor universitare. În practică, UML este folosit pentru a descrie modele arhitecturale, iar limbaje SDL/MSC, diagrame executabile UML și notații similare sunt folosite pentru a construi modele comportamentale.

Limbile și notațiile enumerate pentru modelele comportamentale, din păcate, nu au suficientă generalitate. S-au dovedit bine în aplicațiile de telecomunicații și sunt practic inutile pentru a descrie funcționalitatea sistemelor software „generice”: sisteme de operare, compilatoare, DBMS etc.

O nouă generație de instrumente pentru descrierea modelelor/specificațiilor și instrumente pentru generarea de teste pentru a verifica consistența comportamentului implementării unui model dat pretinde a fi instrumente pentru dezvoltarea de teste pentru astfel de sisteme.

Instrumente de testare bazate pe modele

Test Real Time este unul dintre primii reprezentanți ai acestui grup. Mai mult oportunități ample Jtest este furnizat de Parasoft. Instrumentele de la Comformiq sunt interesante. O familie de instrumente de dezvoltare a testelor bazate pe modele este oferită de Institutul de Programare a Sistemelor al Academiei Ruse de Științe, în cooperare cu compania ATS. Deoarece autorii sunt mult mai familiarizați cu familia UniTesK, vom prezenta schema generala abordare de testare bazată pe model folosind exemple de la UniTesK.

Orez. 1. Fazele procesului de dezvoltare a specificațiilor și testelor

Schița generală a procesului de dezvoltare a specificațiilor și testelor constă din patru faze (Figura 1).

Prima fază este relativ scurtă, dar în proiectele reale este importantă. Aici este stabilit nivelul de abstractizare al modelului. Modelul ar trebui să fie cât mai simplu posibil: acest lucru vă va permite să solicitați un set exhaustiv de teste. În același timp, modelul trebuie să fie semnificativ și să dezvăluie specificul implementării testate. Astfel, sarcina primei faze este de a găsi un compromis între abstractizare și detaliu.

Sarcina celei de-a doua faze este de a descrie cerințele pentru comportamentul sistemului. Multe abordări (de exemplu, SDL) propun să descrie modele executabile care pot fi considerate prototipuri pentru implementări viitoare. Stabilirea cerințelor în acest caz este determinată de formula „implementarea trebuie să se comporte în același mod ca modelul”. Abordarea este clară, dar, din păcate, în multe situații din viața reală nu funcționează. Să presupunem că antetul unui anumit mesaj construit de model indică o singură dată, iar un antet similar din implementare indică un timp ușor diferit. Este aceasta o greșeală sau nu? Încă un exemplu. Modelul sistemului de management al memoriei a generat un pointer către o locație de memorie liberă, dar sistemul real a produs un indicator diferit: modelul și sistemul funcționează în spații de adrese diferite. Este aceasta o greșeală?

UniTesK - soluție unificată

UniTesK sugerează utilizarea așa-numitelor specificații implicite sau specificații de constrângere. Ele sunt specificate sub formă de pre- și postcondiții ale procedurilor și restricții invariante asupra tipurilor de date. Acest mecanism nu permite modelului să descrie algoritmi pentru calcularea valorilor așteptate ale funcțiilor, ci doar proprietățile acestora. Să presupunem că, în cazul unui sistem de gestionare a memoriei, modelul va fi specificat printr-o expresie booleană într-o postcondiție precum „valoarea pointerului aparține zonei de memorie liberă”. Un exemplu simplu de postcondiție pentru funcția rădăcină pătrată este dat la ; aceeași specificație este prezentată în trei notații diferite: în stilul limbajelor C, Java și C#. Utilizarea extensiilor de specificații ale limbajelor de programare convenționale în locul limbajelor de specificații formale clasice este un pas pe care îl fac aproape toți dezvoltatorii de astfel de instrumente. Ele se disting doar prin puterea expresivă a notațiilor și capacitatea de a analiza și traduce specificațiile.

A treia fază este dezvoltarea unui script de testare. În cel mai simplu caz, scriptul poate fi scris manual, dar în acest grup de instrumente aceasta este o formă proastă. Test, adică o secvență de apeluri la operațiuni ale sistemului țintă cu parametrii corespunzători poate fi generată pornind de la o descriere a programului sau a structurii de date. Vom numi o astfel de descriere scenariu. Conformiq se oferă să descrie o mașină cu stări finite. Le corespund diferitelor stări ale mașinii sensuri diferite variabile ale sistemului țintă, tranziții - apeluri la operațiunile acestui sistem. A defini un automat înseamnă pentru fiecare stare să descrie în ce stare vom trece din aceasta dacă ne întoarcem la orice operație predeterminată cu orice stare predeterminată. parametrii dați. Dacă o astfel de descriere este ușor de obținut, nu este nevoie să faceți altceva: instrumentul va genera automat testul și va prezenta rezultatele testului, de exemplu, sub formă de diagrame MSC. Dar este acest lucru ușor pentru, să zicem, un program cu o variabilă întreagă și două sau trei operații? Probabil da. Cu toate acestea, în cazul general, este pur și simplu imposibil de făcut.

În UniTesK, pentru a genera secvențe de testare, o mașină cu stări finite nu este descrisă, ci este generată pe măsură ce testul este executat. Tot ceea ce este necesar de la dezvoltatorul testului este să specifice o metodă de calcul a stării modelului pe baza stării sistemului țintă și o metodă de enumerare a acțiunilor de testare aplicate în starea curentă. Aceste calcule sunt înregistrate în cazuri de testare. Următorul impact de testare este selectat pe baza specificației scenariului, în funcție de rezultatele impacturilor anterioare. Această abordare are două avantaje importante. În primul rând, vă permite să construiți secvențe de testare complexe într-o formă extrem de compactă și ușor de scris și de înțeles. În al doilea rând, testele devin extrem de flexibile: pot fi parametrizate cu ușurință în funcție de nevoile actuale de testare și chiar se pot adapta automat la modificări minore ale modelului. În fig. 3 prezintă un exemplu de metoda scenariului.

În general, scriptul de testare descrie iteratorii pentru toate metodele din această clasă, cu toate acestea, de fiecare dată, dezvoltatorul testului decide numai problema locala- cum să iterați prin parametrii de intrare ai unei singure metode. Sarcina generală este modul de organizare a secvenței de apeluri; cum să reveniți la aceeași stare de numărul necesar de ori pentru a testa încă o metodă, încă o valoare a parametrului; când să se oprească pentru a nu face lucrări inutile - de toate acestea se ocupă unealta.

UniTesK folosește o arhitectură de testare unificată, potrivită pentru testarea sistemelor de complexitate diferită, legate de diferite domenii și care asigură scalabilitatea testului. Componentele de testare care necesită scriere umană sunt separate de bibliotecă și componentele generate automat (Figura 4).

În sistemele reale, numărul de stări distinse și numărul de acțiuni de testare permise în fiecare dintre ele este foarte mare, ceea ce duce la o „explozie de stări” combinatorie. Pentru a combate acest efect, a fost dezvoltat un mecanism de factorizare a modelului: acele stări ale sistemului țintă, a căror diferență este nesemnificativă din punctul de vedere al sarcinilor acestui test, sunt combinate într-o stare generalizată a modelului; influențele testelor sunt combinate în mod similar în grupuri. Procesul de factorizare oferă dezvoltatorului libertate de creație, dar, în același timp, este susținut de cercetări riguroase care determină condiții suficiente care garantează corectitudinea rezultatelor și o reducere semnificativă a timpului de testare, menținând în același timp acoperirea testului atins.

Orez. 4. Arhitectura programelor de testare

Creatorii UniTesK, crezând că nu ar trebui să existe un mediu separat pentru dezvoltarea testelor, nu numai că l-au înzestrat cu capacitatea de a imita diverse limbaje de programare, dar au asigurat integrarea instrumentelor sale constitutive în instrumentele populare de dezvoltare a programelor. În fig. 5 prezintă o sesiune de utilizare a UniTesK în mediul de dezvoltare Forte 4.0 de la Sun Microsystems.

Noua calitate pe care noile instrumente o promit

După cum sa menționat mai sus, creatorii de instrumente de testare se confruntă de obicei cu următoarele provocări:

• absența sau definirea neclară a criteriilor de acoperire a testelor, lipsa unei legături directe cu cerințele funcționale;
• lipsa suportului pentru reutilizarea testelor;
• lipsa generării automate a testului în sine (aceasta se aplică atât influențelor de intrare, cât și rezultatelor de referință sau analizoarelor automate de corectitudine a implementării).

Instrumentele de testare care utilizează un model sau o specificație formală a sistemului țintă pentru a genera un test au avantaje fundamentale față de instrumentele tradiționale? Pentru a răspunde la această întrebare, vom indica modul în care problemele notate sunt rezolvate pentru instrumentele care utilizează modele.

Criterii de acoperire a testului. Criteriul principal este verificarea tuturor afirmațiilor, în special a afirmațiilor care definesc postcondițiile procedurilor sau metodelor. Este ușor de verificat și ușor de asociat cu cerințele funcționale ale sistemului țintă. Deci, instrumente UniTesK, instrumente pentru Platforme Javași C# oferă patru niveluri de criterii imbricate.

Reutilizarea testelor. Nivelul de reutilizare este semnificativ mai mare decât cel al instrumentelor tradiționale. Dezvoltatorul testului nu scrie scriptul de testare, ci criteriile de verificare a afirmațiilor și scriptul de testare. Ambelor le lipsesc multe detalii de implementare și, prin urmare, sunt mai ușor de reutilizat pentru o nouă versiune a sistemului țintă sau pentru a adapta specificațiile și testele pentru un proiect similar. De exemplu, statisticile UniTesK arată că nivelul de reutilizare pentru testarea nucleelor ​​diferitelor sisteme de operare depășește 50%.

Generare automată a testelor. Acesta este principalul avantaj al noilor instrumente; aici sunt mult înaintea instrumentelor tradiționale, deoarece nu folosesc tipuri arbitrare de notații și metode de modelare și specificare, ci tocmai cele care oferă avantaje în generarea automată a testelor. Astfel, declarațiile fac posibilă generarea de „oracole” de testare - programe pentru analizarea automată a corectitudinii rezultatului; diverse tipuri de mașini cu stări finite sau analogii acestora vă permit să generați secvențe de testare. În plus, deoarece modelele sunt de obicei mai simple decât implementările, ele pot fi analizate mai amănunțit, astfel încât suita de teste devine mai sistematică.

Instrumentele luate în considerare au fost testate pe proiecte reale, la scară largă. Desigur, fiecare proiect are anumite particularități care pot împiedica testarea exhaustivă. Cu toate acestea, experiența în utilizarea acestor instrumente arată că de obicei este posibil să se obțină rezultate bune, mai bune decât rezultatele obținute în proiecte similare folosind testarea manuală. Utilizatorii UniTesK consideră de obicei o acoperire de cod de 70-80% a sistemului țintă ca fiind un nivel acceptabil de calitate; în acest caz trebuie îndeplinit cel puțin criteriul de acoperire a tuturor ramurilor logice în postcondiții. Pentru unele programe complexe (inclusiv blocul de optimizare al compilatorului GCC), a fost atins un nivel de acoperire de 90-95%.

Există limitări fundamentale ale aplicabilității acestei abordări? Este aproape imposibil de utilizat în cazul în care, dintr-un motiv sau altul, nimeni din lanțul client-dezvoltator-tester nu a fost capabil sau dispus să formuleze clar cerințele pentru sistemul țintă. Totuși, aceasta nu este doar o limitare, ci și un stimulent suplimentar pentru îmbunătățirea proceselor de dezvoltare, un alt motiv pentru a explica clientului că investițiile în faza de proiectare sunt mai mult decât recuperate prin reducerea timpului general de dezvoltare și a costului proiectului.

Denumirile elementelor structurii generale a specificației unei metode:

S- Semnătura operațiunii

A- Specificații de acces

- Condiție prealabilă

B- Definirea ramurilor de funcționalitate

> - Postcondiție

Java:

Clasa SqrtSpecification ( Specificația S static double sqrt(double x) A citește x, epsilon ( = 0; ) post ( > if(x == 0) ( B ramura „Argument zero”; > return sqrt == 0; > ) else ( Ramura B „Argument pozitiv”; > return sqrt >= 0 && > Math.abs((sqrt*sqrt-x)/x) ) ) )

Si:

Specificația S dublu SQRT(dublu x) A citește (dublu)x, epsilon ( = 0.; ) acoperire ZP ( if(x == 0) ( B return(ZERO, „Argument zero”); ) else ( B return( POS, „Argument pozitiv” ) ) post ( > if(acoperire(ZP, ZERO)) ( > return SQRT == 0.; > ) else ( > return SQRT >= 0. && > abs((SQRT*SQRT) - x)/x) ) ) )

C#:

Exemple de spațiu de nume ( clasa de specificații SqrtSpecification ( specificația S static double Sqrt(double x) A citește x, epsilon ( = 0; ) post ( > if(x == 0) ( B ramura ZERO (“Argument zero”); > return $ this.Result == 0; > ) else ( B branch POS ("Argument pozitiv"); > return $this.Result >= 0 && > Math.Abs(($this.Result * $this.Result - x)/ x) ) > ) > ) ) )

Planul cursului:

1.
Testați modelul și Cum să lucrați cu structura
2.
Cum să vină cu cecuri
1.
2.
Tehnici de proiectare de testare (cutie neagră)
Prezentare generală a tehnicilor White Box
3.
Lucrul cu consecvență
4.
Formularea controalelor
5.
Prioritizare
6.
În urma procesului de documentare a testului

Audit - Ce a fost verificat

1.
Completitudinea acoperirii (după cum este necesar)
2.
Consecvență (duplicate, cerințe contradictorii)
3.
Structura (cum au fost împărțite în părți și seturi de testare, cum au fost testate)
4.
Conținutul verificărilor (formularea, înțelegerea tuturor participanților la proiect)
5.
Design (erori de scris, aspect îngrijit)
6.
Acoperire (fum/MAT/AT)
7.
Respectarea procesului (procesul de lucru cu documentația de testare)

Erori pentru toate tipurile de documentație
Alfabetizare
60
10,4
Acoperă toate funcțiile
verificări
42
9,4
Defalcarea funcției
6,4
Aspect
6,2
Stil unic
2,1
Metode de documentare
2,1
Metode de rezultat
2
55
38
14
20
17
% din toate proiectele
% din toate erorile

Erori pentru sondaj de testare, cazuri de testare
Sari peste controale
12,6
Așteptat
rezultat
Duplicate
Stil unic
Controverse
O prioritate
70
47
6
38
3,5
25
2,4
25
1,6
1,4
19
% din toate proiectele
% din toate erorile

Model de testare

este o structură logică care descrie funcționalitatea
sistem și/sau comportamentul utilizatorului, conform căruia
sunt generate cazuri de testare. Construirea unui model de testare
începe cu construcția structurii, iar apoi aprobat
structura este umplută cu cazuri de testare/verificări.
(c) Dmitri Tișcenko. Blogul A1QA, 2014

Acoperirea inspecției

1) Dorințele clientului actual în specificații\cerințe\aspecte
2) Acorduri asupra proiectului
3) Disponibilitatea verificărilor necesare pentru fiecare funcție:
Tehnici de proiectare de testare:
◦
◦
◦
◦
Testarea partiționării echivalente
Testarea valorilor limită
Testare în perechi
Testarea tranziției de stat

Partiționare echivalentă

TEHNOLOGIA CLASELE ECHIVALENTE

*pentru a simplifica exemplul, să luăm un preț constant

1) Împărțiți parametrii de intrare în clase

Parametru
Clasa 1
Clasa 2
Versiunea produsului
Standard
Premium
<0
0 <= количество < 100
Cantitate
Clasa 3
>= 100
*Voice of Reason - pentru „Versiune de produs” trebuie să testați TOATE valorile din clasa de valori validă.
De exemplu, pentru câmpul Plată (valori: card, numerar, transfer), este logic să testați TOATE opțiunile separat

2) 1 clasă == 1 cec

Versiunea produsului
Cazul 1
Standard
Cazul 2
Premium
Cant

2) 1 clasă == 1 cec

Versiunea produsului
Cazul 1
Standard
Cazul 2
Premium
Cant
Cazul 3
-1
Cazul 4
16
Cazul 5
125

3) Cec negativ doar pentru clasa I în caz

Versiunea produsului
Cant
Rezultat
Cazul 1
Standard
50
Pozitiv
Cazul 2
Premium
50
Pozitiv
Cazul 3
Standard
-1
Negativ
Cazul 4
Standard
16
Pozitiv
Cazul 5
Standard
125
Negativ

4) Reconsiderați verificările pozitive

Versiunea produsului
Cant
Rezultat
Cazul 1
Standard
50
Pozitiv
Cazul 2
Premium
50
Pozitiv
Cazul 3
Standard
-1
Negativ
Cazul 4
Standard
16
Pozitiv
Cazul 5
Standard
125
Negativ

5) Total

Versiunea produsului
Cant
Rezultat
Cazul 1
Premium
50
Pozitiv
Cazul 2
Standard
-1
Negativ
Cazul 3
Standard
16
Pozitiv
Cazul 4
Premium
125
Negativ

Mai multe cursuri...

Parametru
Clasa 1
Clasa 2
Versiunea produsului
Standard
Premium
<0
0 <= Кол-во < 100
Fracționat
Întreg
Numerele
Nu numere
Cant
Clasa 3
> 100
Gol

Versiunea produsului
Cant
Rezultat
Cazul 1
Standard
50
Pozitiv
Cazul 2
Premium
10
Pozitiv
Cazul 3
Premium
-1
Negativ
Cazul 4
Standard
16
Pozitiv
Cazul 5
Premium
150
Negativ
Cazul 6
Premium
19,45
Negativ
Cazul 7
Premium
%Număr!
Negativ
Cazul 8
Standard
-
Negativ

Versiunea produsului
Cant
Rezultat
Cazul 1
Standard
50
Pozitiv
Cazul 2
Premium
10
Pozitiv
Cazul 3
Premium
-1
Negativ
Cazul 4
Standard
16
Pozitiv
Cazul 5
Premium
150
Negativ
Cazul 6
Premium
19.45
Negativ
Cazul 7
Premium
%Număr!
Negativ
Cazul 8
Standard
-
Negativ

~30% cazuri pozitive

Versiunea produsului
Cant
Rezultat
Cazul 1
Standard
50
Pozitiv
Cazul 2
Premium
10
Pozitiv
Cazul 3
Premium
-1
Negativ
Cazul 4
Premium
150
Negativ
Cazul 5
Premium
19.45
Negativ
Cazul 6
Premium
%Număr!
Negativ
Cazul 7
Standard
-
Negativ

Funcţie
Parametru de intrare
Destinatar
Trimite
Subiect
Corp
Fișiere
Atașați
Fișiere
Formatarea textului
Șterge
Vidul
Clasa 1
Clasa 2
Adresă existentă Adresă inexistentă
Marimea 0
0 < Размер <= Limit
Conține simboluri @
._-+
Alte simboluri decât @ . _ - +
Format
Nu format
Marimea 0
0 < Размер <= Limit
Conține caractere
cu excepția simbolurilor „∞₽₾₾©¥£µ®” ∞₽₾₾©¥£µ®
Marimea 0
0 < Размер <= Limit
Formatare
Fără formatare
Nu
unu
Marimea 0
0 < Размер <= Limit
Sprijinit
Neacceptat
Niciun text selectat
alege
Text
formatare
Clic
Clasa 3
Dimensiune > Limită
Dimensiune > Limită
Dimensiune > Limită
Mult
Dimensiune > Limită
Formatat
al-lea text

№
1
2
Destinatar
Există
0 < Размер <= Limit
Subiect
0 < Размер <= Limit
Conține caractere
cu excepția „∞₽₾₾©¥£µ®”
3 Conține simboluri @. _ 0< Размер <= Limit
-+
4 Format
0 < Размер <= Limit
5 Adresă inexistentă 0< Размер <= Limit
6 Marimea 0
Conține caractere
cu excepția „∞₽₾₾©¥£µ®”
7 Dimensiune > Limită
Conține caractere
cu excepția „∞₽₾₾©¥£µ®”
8 Nu format
0 < Размер <= Limit
9 0 < Размер <= Limit
Marimea 0
10 0 < Размер <= Limit
Dimensiune > Limită
11 0 < Размер <= Limit
Conține caractere
“∞₽₾₾©¥£µ®”
12 Există
0 < Размер <= Limit
0 < Размер <= Limit
Formatare
Nu
unu
Așteptat
rezultat
Trimis
Trimis
0 < Размер <= Limit
Trei
Trimis
0 < Размер <= Limit
0 < Размер <= Limit
Formatare
Trei
Nu
unu
Trimis
Nelivrat
Netrimis
Formatare
unu
Netrimis
0 < Размер <= Limit
Formatare
0 < Размер <= Limit
0 < Размер <= Limit
Nu
unu
Trei
Trei
Netrimis
Netrimis
Netrimis
Netrimis
Dimensiune > Limită
Nu
Netrimis
Corp
Fișiere

#
Intrare
Rezultat
Vidul
Anulați ștergerea
Text neselectat\nu selectați
formatare
Scrisoarea a fost ștearsă
Scrisoarea nu a fost ștearsă
Text
Formatarea aplicată
4
Text bogat
S-a aplicat o nouă formatare
5
Dimensiune si format disponibile
valorile
Fisier atasat
Nu specificați fișierul
Fișierul nu este atașat
Specificați un fișier de dimensiune nevalidă
(min< или >max)
Fișierul nu este atașat
Specificați fișierul neacceptat
Fișierul nu este atașat
1
Funcţie
Îndepărtarea
2
3
6
7
8
Formatare
Atașament
fişier
Sistemul nu aplică formatare

Valori limită

TEHNICA VALORII LIMITĂ

Sarcină: Creați cazuri de testare pentru Planul de Evacuare

Sarcină: Creați cazuri de testare pentru Planul de Evacuare

0
Test de bază
Pentru a calma nervii
Test negativ
99

99
0
0
99

Găsirea tuturor perechilor (vezi graficul)
În matematică, acesta este produsul cartezian:
Plan_Evacuare x Evaluare_Risc = ((a,b) | a ∈ Plan_Evacuare, b ∈ Evaluare_Risc)
Plan_Evacuare x Evaluare_Risc =
{ (-1,-1),
(-1,0), (-1,1),
(-1,50),
(-1,98), (-1,99), (-1,100),
(0,-1),
(0,0),
(0,1),
(0,50),
(0,98),
(0,99),
(0,100),
(1,-1),
(1,0),
(1,1),
(1,50),
(1,98),
(1,99),
(1,100),
(50,-1), (50,0), (50,1), (50,50),
(50,98), (50,99), (50,100),
(98,-1), (98,0), (98,1), (98,50),
(98,98), (98,99), (98,100),
(99,-1), (99,0), (99,1),
(99,50), (99,98), (99,99),
(99,100),
(100,-1), (100,0), (100,1), (100,50), (100,98), (100,99), (100,100),
}
7x7 = 49 de verificări

Plan_evacuare = (-1, 0, 1, 50, 98, 99, 100)
Evaluarea_riscului = (-1, 0, 1, 50, 98, 99, 100)
EP_Type = (Standard, Premium)
RA_Type = (Standard, Premium)
Număr de cazuri = 7 * 7 * 2 * 2 = 196

Testare în perechi

TEHNICA DE TESTARE A TOATE PERECHII

Sarcină

Stocarea datelor (5): PostgreSQL, Oracle, MySQL, JSON, XML
Sistem de operare (4): Windows 7, 8, 10, OS X 10
RAM (3): 1.024 MB, 4.096 MB, 8.192 MB
HDD (2): SCSI, IDE
Căutare completă = 5 * 4 * 3 * 2 = 120 de opțiuni

Idei

1. Testați perechi de valori, nu căutări exhaustive
2. Dovada empirică a eficacității
3. Toate perechile/opțiunile de tehnică masivă ortogonală

Lucrul cu ortogonal
matrice

1
2
3
4
5
Date
PostgreSQL
Oracol
MySQL
JSON
XML
OS
Windows 7
Windows 8
Windows 10
OS X 10
RAM
1 024 MB
4 096 MB
8 192 MB
HDD
SCSI
IDE

Lucrul cu ortogonal
matrice
1. Înțelegeți ce și câți parametri de intrare:
1
2
3
4
5
Date
PostgreSQL
Oracol
MySQL
JSON
XML
OS
Windows 7
Windows 8
Windows 10
OS X 10
RAM
1 024 MB
4 096 MB
8 192 MB
HDD
SCSI
IDE

Lucrul cu ortogonal
matrice
1. Înțelegeți ce și câți parametri de intrare:
Stocare a datelor
OS
RAM
HDD
Coloana 5
Coloana 6
1
1
1
1
1
1
1
2
2
2
2
2
1
3
3
3
3
3
1
4
4
4
4
4
1
5
5
5
5
5
2
1
2
3
4
5
2
2
3
4
5
1
1
2
3
4
5
2
3
4
5
1
2
Date
PostgreSQL
Oracol
MySQL
JSON
XML
2
4
5
1
2
3
OS
Windows 7
Windows 8
Windows 10
OS X 10
2
5
1
2
3
4
3
1
3
5
2
4
RAM
1 024 MB
4 096 MB
8 192 MB
3
2
4
1
3
5
HDD
SCSI
IDE
3
3
5
2
4
1
3
4
1
3
5
2
3
5
2
4
1
3
4
1
4
2
5
3
4
2
5
3
1
4
4
3
1
4
2
5
4
4
2
5
3
1
4
5
3
1
4
2
5
1
5
4
3
2
5
2
1
5
4
3
5
3
2
1
5
4
5
4
3
2
1
5
5
5
4
3
2
1
2. Selectați o matrice ortogonală potrivită – L25(56 ^6)

Lucrul cu ortogonal
matrice
1. Înțelegeți ce și câți parametri de intrare:
1
2
3
4
5
Date
PostgreSQL
Oracol
MySQL
JSON
XML
OS
Windows 7
Windows 8
Windows 10
OS X 10
RAM
1 024 MB
4 096 MB
8 192 MB
HDD
SCSI
IDE
2. Selectați o matrice ortogonală adecvată -
3. Construirea unui tablou ortogonal
4. Îndepărtați COLOANELE inutile
L25(56^6)
Stocare a datelor
OS
RAM
HDD
1
1
1
1
1
2
2
2
1
3
3
3
1
4
4
4
1
5
5
5
2
1
2
3
2
2
3
4
2
3
4
5
2
4
5
1
2
5
1
2
3
1
3
5
3
2
4
1
3
3
5
2
3
4
1
3
3
5
2
4
4
1
4
2
4
2
5
3
4
3
1
4
4
4
2
5
4
5
3
1
5
1
5
4
5
2
1
5
5
3
2
1
5
4
3
2
5
5
4
3

Lucrul cu ortogonal
matrice
1. Înțelegeți ce și câți parametri de intrare:
Stocare a datelor
OS
RAM
HDD
1
PostgreSQL
Windows 7
1 024 MB
SCSI
2
PostgreSQL
Windows 8
4 096 MB
IDE
3
PostgreSQL
Windows 10
8 192 MB
SCSI
4
PostgreSQL
OS X 10
1 024 MB
SCSI
5
PostgreSQL
Windows 10
1 024 MB
SCSI
6
Oracol
Windows 7
4 096 MB
SCSI
7
Oracol
Windows 8
8 192 MB
SCSI
1
2
3
4
5
8
Oracol
Windows 10
1 024 MB
SCSI
Date
PostgreSQL
Oracol
MySQL
JSON
XML
9
Oracol
OS X 10
1 024 MB
SCSI
OS
Windows 7
Windows 8
Windows 10
OS X 10
10
Oracol
Windows 10
1 024 MB
IDE
11
MySQL
Windows 7
8 192 MB
SCSI
RAM
1 024 MB
4 096 MB
8 192 MB
12
MySQL
Windows 8
1 024 MB
SCSI
HDD
SCSI
IDE
13
MySQL
Windows 10
4 096 MB
IDE
14
MySQL
OS X 10
1 024 MB
SCSI
15
MySQL
OS X 10
4 096 MB
SCSI
16
JSON
Windows 7
4 096 MB
IDE
17
JSON
Windows 8
4 096 MB
SCSI
18
JSON
Windows 10
1 024 MB
SCSI
19
JSON
OS X 10
4 096 MB
SCSI
20
JSON
OS X 10
8 192 MB
SCSI
21
XML
Windows 7
4 096 MB
SCSI
22
XML
Windows 8
1 024 MB
SCSI
23
XML
Windows 10
4 096 MB
SCSI
24
XML
OS X 10
8 192 MB
IDE
25
XML
Windows 10
4 096 MB
SCSI
2. Selectați o matrice ortogonală potrivită – L25(56 ^6)
3. Construirea unui tablou ortogonal
4. Îndepărtați COLOANELE inutile
5. Introduceți valorile parametrilor de intrare
6. Completați spațiile libere + verificați perechile pentru relevanță

PICT
Stocare a datelor
OS
RAM
HDD
1
JSON
OSX_10
4096 MB
SCSI
2
Oracol
Windows 7
1024 MB
IDE
3
MySQL
Windows10
8192 MB
IDE
4
Oracol
Windows 8
8192 MB
SCSI
5
JSON
Windows 8
1024 MB
IDE
6
JSON
Windows 7
8192 MB
SCSI
7
Oracol
Windows10
1024 MB
SCSI
8
XML
Windows 7
4096 MB
IDE
9
MySQL
OSX_10
1024 MB
SCSI
10
JSON
Windows10
4096 MB
SCSI
11
XML
Windows10
8192 MB
SCSI
12
PostgreSQL
Windows 8
4096 MB
SCSI
13
MySQL
Windows 7
4096 MB
SCSI
14
XML
Windows 8
1024 MB
IDE
15
PostgreSQL
Windows 7
1024 MB
IDE
16
XML
OSX_10
8192 MB
IDE
17
PostgreSQL
Windows10
8192 MB
SCSI
18
MySQL
Windows 8
4096 MB
IDE
19
PostgreSQL
OSX_10
8192 MB
IDE
20
Oracol
OSX_10
4096 MB
SCSI

105*16*2*4*5*2 = 134 400

1
2
3
4
5
…
105
Subiect
arabic
Istoria artei
Biologie
Afaceri
Studii
Chimie
…
EAL
Nivel școlar (16)
Elementar
Mijloc
Înalt
La nivel de școală
Înalt/Mijloc
…
Probabilitate
Hotărât
Tentativă
Angajare
Tip
Deplin
Parte
Substitui
Temporar
Durata contractului
1
2
3
4
Scrisoare de intenție

De ce este necesară testarea?

În această secțiune, ne vom uita la cele mai de bază concepte și principii care sunt utilizate în procesul de testare. Vom afla ce este de fapt testarea, de ce este nevoie și cine o face. Să luăm în considerare obiectivele, principiile și etapele principale ale testării. Să simțim care ar trebui să fie atitudinea psihologică a unui tester adevărat și, în sfârșit, să dezmințim câteva mituri despre testare. Suntem siguri că veți fi interesați.
Să începem cu ce este „testarea”. Pentru început, să facem abstracție de la definițiile academice seci și să privim acest concept din punctul de vedere al utilizării de zi cu zi.
Când testăm ceva, ne punem o întrebare simplă: „funcționează așa cum ne așteptăm?” sau, cu alte cuvinte: comportamentul real al obiectului de testare se potrivește așteptărilor noastre? Dacă răspunsul este pozitiv, grozav dacă nu, am fost înșelați în așteptările noastre, ceea ce înseamnă că ceva trebuie corectat.
Testarea este necesară pentru că toți facem greșeli. Unele dintre ele pot fi minore, în timp ce altele pot avea cele mai devastatoare consecințe. Tot ceea ce este produs de om poate conține erori (așa suntem proiectați noi, oamenii). Acesta este motivul pentru care orice produs trebuie verificat - testat înainte de a putea fi utilizat eficient și în siguranță.
Același lucru este valabil și pentru software.
Software – programe de calculator, funcții, precum și documentația și datele însoțitoare legate de funcționarea unui sistem informatic.
Tehnologiile informatice pătrund din ce în ce mai adânc în viața noastră de zi cu zi. Software-ul controlează funcționarea multor lucruri din jurul nostru - de la telefoane mobile și computere la mașini de spălat și carduri de credit. În orice caz, cu toții am întâlnit una sau alta eroare în program: un editor de text care se blochează în timp ce lucrează la un proiect de teză, un bancomat care „mâncă” un card sau pur și simplu un site web care nu se va încărca - toate acestea nu ne ușurează viața.
Cu toate acestea, nu toate erorile sunt la fel de periculoase - nivelurile de risc pot varia pentru diferite sisteme software.
Risc:
– un factor care poate duce la consecințe negative în viitor; de regulă, se exprimă în termeni de probabilitate de apariție a unor astfel de consecințe și impactul acestora asupra sistemului.
– ceva ce nu s-a întâmplat încă și s-ar putea să nu se întâmple deloc; potenţială problemă.
În plus, nivelul de risc va depinde de probabilitatea apariției unor consecințe negative.
De exemplu, aceeași eroare minoră, să zicem o greșeală de scriere, poate avea niveluri de risc complet diferite pentru diferite programe:
– o greșeală de tipar în descrierea intereselor pe o pagină personală de pe o rețea de socializare este puțin probabil să aibă consecințe semnificative, cu excepția faptului că îți va face prietenii să zâmbească;
– aceeași greșeală simplă făcută în descrierea activităților unei mari companii postată pe site-ul său este deja periculoasă, deoarece indică indirect neprofesionalismul angajaților săi;
- o greșeală de tipar în codul programului care calculează nivelurile de radiații atunci când se utilizează un aparat cu raze X (de exemplu, 100 în loc de 10) poate avea cele mai grave consecințe - prejudiciul cauzat sănătății și siguranței oamenilor va duce la o pierdere de încredere în companie și procese cu multe zerouri.