Testarea Neconventionala a Interfetelor Sistemului Base24 Eps

Testarea neconvențională a interfețelor sistemului BASE24-eps

Cuprins

Introducere

Capitolul 1. Atributele testării

1.1 Principiile testării

1.2 Modele de dezvoltare software

Capitolul 2. Noțiuni de testare negativă

2.1. Obiectivele testării negative

2.2. Managementul testării negative

2.3. Strategii de selectare a testelor

2.4. Tehnici pentru crearea de teste

2.5. Testarea parțial scriptată

Capitolul 3. Testarea negativă a interfețelor sistemului BASE24-eps

3.1. Ce este o tranzacție financiară

3.2. Entități implicate într-o tranzacție financiară

3.3. Instrumente folosite în testarea tranzacțiilor financiare

3.4. Testarea pozitivă

3.5. Testarea negativă

3.6. Fault Injector

3.7. Execuția testelor negative pe un proiect pilot

Concluzii și perspective

Bibliografie

Anexa A

Introducere

În ziua de astăzi domeniul financiar-bancar a devenit parte integrantă din viața de zi cu zi a fiecăruia. Mai ales în ultimii ani, în România, instituțiile bancare și-au făcut tot mai simțită prezența atât la nivel de companii, persoane juridice, etc cât și la cel al persoanelor fizice.

Vorbind la nivel global, competitivitatea puternică dintre instituțiile bancare a dus la faptul că unele din acestea, de-a lungul timpului, au reusit și continuă să ofere clienților lor produse și servicii de bună și foarte bună calitate.

Ca marea majoritate a companiilor, instituțiile financiare folosesc exhaustiv, în toate activitățile care le desfășoară, tehnologia informației; cum ar fi: calculatoare PC (workstation-uri), servere, o gamă foarte largă de aplicații, diverse servicii oferite de alte companii etc.

Toată tehnologia la care se apelează, hardware și software, trebuie riguros testată. În acest domeniu erorile sunt foarte puțin tolerate, de aceea, sistemele folosite trebuie sa funcționeze cu cât mai puține erori.

Calitatea software

În literatura de specialitate există numeroase definiții ale calității, în general, și a calității produselor software în particular.

Conform standardului ISO 9000 calitatea reprezintă ”gradul în care un set de însușiri inerente îndeplinesc cerințele”.

Trebuie specificat că (notele explicative din reglementări): – termenul calitate poate fi folosit cu adjective precum slabă, bună sau excelentă, iar termenul inerentă înseamnă care există în ceva mai ales ca o însușire permanentă [4].

Societatea Americană pentru Controlul Calității ( ASQC = American Society for Quality Control) a definit conceptul de calitate ca “totalitatea caracteristicilor unui produs sau serviciu care se referă la capacitatea sa de a satisface necesități date”.

Calitatea software poate fi definită având în vedere trei direcții esențiale:

cerințele funcționale sau de performanță definite anterior

standardele din domeniu

cerințele implicite (de exemplu ușurința de a folosi produsul respectiv, mentenabilitatea).

Calitatea produselor software este determinată de către o multitudine de aspecte și parametri, care pot fi clasificați în criterii externe și criterii interne de calitate.

Criteriile externe de calitate se referă la experiența utilizatorului la momentul folosirii respectivului produs software, în timp ce criteriile interne se referă mai mult la aspecte legate de codul sursă, care nu sunt vizibile în mod normal utilizatorului final. Dintre aceste criterii care evaluează calitatea produselor software unele sunt obiective și măsurabile, iar altele sunt subiective și mult mai greu de caracterizat de anumite măsurători calitative și cantitative.

Calitatea produselor software poate fi testată folosind diferite nivele, tipuri si strategii de testare:

niveluri de testare: testarea unitara, testarea de intregrare, testarea de sistem, testarea de acceptare.

tipuri de testare: testare de instalare si dezinstalare, testare de compatibilitate, testarea smoke si sanity, testare de regresie, testarea de performanta, testare de uzabilitate, testarea in conditii de stres etc.

strategii de testare: testarea pozitiva si testarea negativa.

Niveluri de testare:

Testarea unitara:

Prima treapta a testării; se testeaza funcțiile sau modulele de cod . De obicei sunt făcute de programatori deoarece presupun cunoștințe avansate a design-ului intern al aplicației și codului [1].

Testarea de integrare:

Testarea combinată a diferitelor componente dintr-o aplicație pentru a vedea dacă funcționează corect. Aceste componente pot fi module de cod, aplicații individuale, aplicații client-server într-o retea etc.

Testarea de sistem:

Testare bazată pe specificații, care acoperă toate parțile sistemului (End-to-End testing).

Testarea de acceptare:

Determină dacă software-ul este satisfăcător din punctul de vedere al end-user/clientului, într-un mediu cât mai apropiat celui de producție.

Tipuri de testare:

Testare de instalare:

Testarea parțiala sau integrală a procesului de instalare sau upgrade

Testare de compatibilitate:

Testează softare-ului într-un mediu identic (dacă este posibil) sau cât mai aproape, de cel de producție: hardware/software/sistem de operare/rețea/etc

Testarea smoke și sanity:

Testarea smoke consistă într-un număr minim de încercări de folosire a software-ul; este conceput pentru a determina dacă sunt probleme primare care ar putea împiedica folosirea software-ului.

Testarea sanity determină dacă se poate/merită a continua procesul de testare a aplicației [2].

Testarea de regresie:

Retestarea după o schimbare majoră a software-ul (corecții/îmbunătățiri) sau dacă mediul a fost modificat. Utilitarele destinate testării automate pot fi foarte utile pentru acest tip de testare.

Testarea de performanță:

Testarea de performanță este, în general, folosită pentru a determina cum se comportă sistemul din punct de vedere al stabilității și reacției acestuia în anumite condiții de încarcare a sistemului.

Testarea în condiții de stress și load testing-ul sunt considerate testări de performanță.

Testarea de uzabilitate:

Testează daca un software este 'user-friendly'. Această testare este subiectivă și va depinde de utilizator/client. Interviuri cu utilizatorii, sondaje, monitorizarea sesiunilor utilizatorilor sunt metode care pot fi folosite pentru crearea acestui tip de testare. Programatorii și testerii nu sunt cei mai indicați pentru acest tip de testare.

Strategii de testare:

Testarea pozitivă:

Testarea pozitivă determină dacă aplicația testată funcționeaza corect. Daca apare o eroare pe parcursul testării pozitive, testul nu trece (fails) [3].

Testarea negativă:

Testarea negativă determină dacă aplicația testată poate procesa cu succes date de intrare invalide sau poate funcționa corect chiar și atunci când aceasta este folosită într-un mod neobișnuit/nefiresc.

În capitolele următoare va fi prezentată în detaliu testarea negativă, studiul de caz folosind această strategie de testare.

Sumarul capitolelor următoare:

Capitolul 1:

Prezintă atributele testării

Capitolul 2:

Prezintă principiile testării, modele de dezvoltare software, nivelurile de testare.

Capitolul 3:

Studiul de caz: Analiza comportamentului interfețelor sistemului BASE24-eps. Testarea negativă a interfețelor.

Concluzii și perspective

Bibliografie

Anexa A

Capitolul 1. Atributele testării

Pentru o mai bună înțelegere a contextului testării produselor software, voi prezenta succint, în continuare, câteva aspecte care definesc calitatea produselor software:

Viteza. Cât de repede poate aplicația noastră sa pună la dispoziția utilizatorului serviciul pe care acesta îl așteaptă ( timpul scurs din momentul în care am cerut acel serviciu și până când aplicația ni l-a furnizat).

Caracteristici de funcționalitate. Acestea reprezintă chiar motivul pentru care produsul software a fost creat, și anume furnizarea unor servicii. Practic aceste caracteristici se referă la ceea ce produsul respectiv știe sa facă.

Spațiul. Câtă memorie utilizează produsul nostru software. Este foarte strâns legată de modul în care a fost definită arhitectura produsului și de modul de implementare.

Utilizarea lungimii de bandă este de asemenea o caracteristică foarte importantă care poate influența evaluarea calitativă a soluției pe care o producem.

Stabilitate. Cât de des este necesar să livram “patch”-uri pentru rezolvarea unor probleme în software. Pentru utilizator acestea pot reprezenta un inconvenient major, însă pentru programator acest lucru semnifică fragilitatea codului scris. Testorul putea considera că ar fi fost necesar un timp crescut pentru faza de testare, iar pentru cei responsabili de design-ul aplicației se poate pune în discuție o rescriere parțială a codului sursă.

Robustețea. Cât de des se întâmplă ca aplicația noastră să aibă probleme grave care o aduc în imposibilitatea de a mai funcționa normal, sau cât de tolerantă este aceasta la condiții extreme de funcționare.

Ușurința de utilizare. Aceasta reprezintă un factor subiectiv, foarte greu de măsurat. Se referă la claritatea acțiunilor în timpul utilizării, la documentația livrată împreună cu produsul, claritatea mesajelor de eroare, modul de tratare al excepțiilor.

Determinismul ( sau repetabilitatea) se referă la măsura în care programul nostru produce de fiecare dată același rezultat, în condiții similare date. Există numeroase motive pentru care o aplicație poate să aibă un comportament nedeterminist ceea ce poate fi foarte frustrant pentru utilizator. De asemenea un astfel de program este greu de testat.

Compatibilitatea cu versiunile anterioare reprezintă gradul în care o aplicație poate fi folosită cu versiuni de date mai vechi. O incompatibilitate de acest fel ar însemna costuri foarte mari de portare a vechilor seturi de date, pe versiunea nouă de aplicație.

Caracteristici de securitate. Este posibilă compromiterea datelor? Pot fi aceste date accesate de persoane neautorizate?

Test Coverage ( acoperirea codului de către cazurile de test). Aceasta caracteristică reprezintă procentul din cod care este executat după rularea cazurilor de test și se poate măsura în linii de cod, număr de funcții, clase. Obținerea unui rezultat foarte bun al acestui parametru este foarte dificilă în practică, fiind legată de alte aspecte precum testabilitatea. Arhitectura aplicației și metodologia de dezvoltare au de asemenea implicații foarte mari.

Testabilitatea. Cât de ușor este de testat produsul nostru astfel încât să obținem o acoperire cât mai mare a codului de către cazurile noastre de test.

O portabilitate ușoară dă produsului nostru posibilitatea de a rula în diverse medii (sisteme de operare diferite, în browsere diferite, pe mașini hardware variate, etc).

Cât de compact este codul scris pentru aplicația noastră? Există cod care nu este executat niciodată? Avem cod duplicat? Un cod compact de obicei prezintă mai puține defecte, dar poate sa influențeze pozitiv și timpul de compilare sau dimensiunea codului binar.

Mentenabilitatea. Este foarte greu de măsurat. Se referă la ușurința de “debug”, sau de livrare de “fix”-uri.

Documentația (codului) se referă la documente speciale de descriere a codului, comentariile din codul sursă sau chiar denumiri de funcții, variabile, tipuri de date.

Lizibilitate. Este un aspect subiectiv și înseamnă ușurința cu care codul sursă poate fi citit iar logica sa urmarită. Pentru creșterea acesteia au fost definite standarde internaționale, ghiduri, directive pentru diverse limbaje de programare.

Scalabilitate. Cât de ușor este sa adăugăm în programul nostru funcționalități noi. Depinde foarte mult de arhitectura sistemului și de modul în care au fost anticipate aceste nevoi ulterioare pentru diverse alte funcționalități.

În concluzie putem afirma că, în cazul produselor software, calitatea nu se referă doar la experiența utilizatorului final cu produsul nostru. Calitatea este clădită pe tot parcursul procesului de dezvoltare, și implică multe alte aspecte de care utilizatorul nu este conștient.

1.1 Principiile testării

În ciuda numeroaselor tehnici de prevenire a defectelor software și drită. Pentru creșterea acesteia au fost definite standarde internaționale, ghiduri, directive pentru diverse limbaje de programare.

Scalabilitate. Cât de ușor este sa adăugăm în programul nostru funcționalități noi. Depinde foarte mult de arhitectura sistemului și de modul în care au fost anticipate aceste nevoi ulterioare pentru diverse alte funcționalități.

În concluzie putem afirma că, în cazul produselor software, calitatea nu se referă doar la experiența utilizatorului final cu produsul nostru. Calitatea este clădită pe tot parcursul procesului de dezvoltare, și implică multe alte aspecte de care utilizatorul nu este conștient.

1.1 Principiile testării

În ciuda numeroaselor tehnici de prevenire a defectelor software și de facilitare a detecției acestora, procesul de dezvoltare software este foarte predispus la erori. Testarea software este cea mai importantă metodă de a controla calitatea aplicațiilor. Prin testare se pot identifica problemele și riscurile posibile în produsele software. Așadar motivele care fac din testare o etapă foarte importantă în producția de software sunt foarte numeroase.

Testarea software este o activitate care evaluează capabilitățile și caracteristicile unui program sau sistem, și determină masura în care acesta funcționează conform specificațiilor.

Există de fapt mai multe motive pentru care produsele software trec prin faza de testare deoarece până la urmă testarea software reprezintă un compromis între buget, timp și calitate.

Dacă ne întrebăm de ce testăm produsele software, probabil cel mai comun răspuns este “pentru a găsi defecte”. Totuși trebuie luate în considerare multe alte aspecte. [5] Testarea este necesară și pentru:

– A reduce impactul defectelor la client și pentru a ne asigura că ele nu vor impacta costurile și profitabilitatea companiei;

– Pentru a asigura calitatea produsului;

– Pentru a mări fiabilitatea produsului;

– Pentru a ne asigura că cerințele sunt implementate corect și complet;

– Pentru a valida faptul că produsul funcționează conform scopului definit;

– Pentru a verifica dacă anumite standarde sau cerințe legale sunt îndeplinite;

– Pentru a menține reputația companiei.

În ultimii 40 de ani testarea software a fost analizată de către foarte mulți specialiști. A reieșit o listă de principii care este valabilă indiferent de mărimea companiei și domeniul în care activează, tipul de testare sau complexitatea produsului.

Principiul 1. Testarea ne arată prezența defectelor.

Testarea produselor software ne poate demonstra existența unor defecte în sistem, însă nu poate garanta că nu există defecte. Într-adevăr se reduce probabilitatea ca unele defecte nedescoperite să persiste în produs, dar chiar și așa, dacă nu se mai gasesc defecte nu avem nici o dovadă asupra corectitudinii totale.

Principiul 2. Testarea exhaustivă este imposibilă.

Testarea totală a unei aplicații ( toate combinațiile de date de intrare și precondiții) este practic imposibilă, excepție făcând doar cazurile triviale. În locul testării exhaustive se folosește analiza de risc și prioritizările, pentru concentrarea efortului de testare acolo unde sunt riscurile mai mari.

Principiul 3. Testarea timpurie.

Activitățile de testare trebuie să înceapă cât mai devreme în ciclul de dezvoltare software, iar fiecare fază sau tip de testare trebuie să se concentreze pe obiective bine definite.

Principiul 4. Efectul Pareto.

Conform principiului 20/80, un număr redus de module sunt responsabile pentru majoritatea defectelor într-o aplicație.

Principiul 5. Pesticide paradox.

Dacă aceleași teste sunt rulate repetitiv, setul respectiv de teste nu va mai găsi defecte noi. Așadar setul de teste trebuie revizuit în mod regulat, și noi cazuri de test trebuie scrise pentru a antrena alte module din aplicație.

Principiul 6. Testarea este dependentă de context.

Activitatea de testare se efectuează diferit, depinzând de context. De exemplu o pagină de cumpărături electronice se testează în alt mod decât software-ul pentu aparatura medicală sau semnalizarea feroviară.

Principiul 7. Absența erorilor

Dacă găsim defecte software și le reparăm, acest lucru nu ajută în cazul în care produsul nu este utilizabil sau nu indeplinește așteptările și nevoile utilizatorului.

1.2 Modele de dezvoltare software

Procesul de testare nu este o activitate independentă. Își are locul în cadrul ciclului de viață a dezvoltării software și astfel ciclul de viață aplicat va determina organizarea testării. Există diferite forme de testare. Datorită diverselor discipline, de obicei cu interese diferite, implicate în ciclul de dezvoltare, este foartă importantă înțelegerea și definirea variatelor niveluri și tipuri de testare.

Procesul de dezvoltare software adoptat pentru un proiect depinde de scopul și de obiectivele acestuia. Numeroase cicluri de dezvoltare au fost concepute cu scopul de a atinge diferite obiective necesare. Aceste cicluri de viață variază de la metodologiile rapide, în care timpul de expunere pe piață este de esență, până la metodologii complet controlate și documentate, în care calitatea și fiabilitatea sunt factori cheie.

Fiecare dintre aceste metodologii își are locul în dezvoltarea modernă de software și procesul de dezvoltare cel mai adecvat ar trebui să se aplice pentru fiecare proiect. Modelele precizează diferitele etape ale procesului și ordinea în care ele sunt efectuate.

Modelul ciclului de viață care este adoptat pentru un proiect va avea un impact mare asupra testării care se efectuează. Testarea nu există în izolare; activitățile de testare sunt foarte legate de activitățile de dezvoltare de software.

Acesta va defini răspunsul la întrebările ce, unde și când ale testării noastre planificate și va determina în mare măsură care tehnici de test să fie utilizate. Modul în care testarea este organizată trebuie să se potrivească ciclului de dezvoltare, altfel nu va reuși să livreze beneficiul său. În cazul în care timpul de expunere pe piață este factorul cheie, atunci testarea trebuie să fie rapidă și eficientă. Dacă se cere un ciclu de dezvoltare software complet documentat, cu o pistă de audit a probelor, testarea trebuie să fie complet documentată [6].

Waterfall model

“Waterfall model” sau “Modelul cascadă” a fost unul dintre primele modele proiectate. Are o cronologie naturală, sarcinile fiind executate în mod secvențial. Pornim de la partea de sus a cascadei, cu un studiu de fezabilitate și parcurgem diferitele sarcini de lucru ale proiectului terminând cu implementarea în mediul real.

Etapa de design este urmată de etapa de dezvoltare, care trece în etapa de build și în cele din urmă în testare. Testarea tinde să se întâmple spre sfârșitul ciclului de viață al proiectului, astfel defectele sunt detectate aproape de data punerii în aplicare reale. Cu acest model a fost dificil să se obțină feedback în etapele anterioare din cascasă și există dificultăți în cazul în care avem nevoie să transportăm iterații numeroase pentru o anumită fază.

Figura 1.1: Modelul cascadă

V-model

V-model a fost dezvoltat pentru a rezolva unele dintre problemele experimentate utilizând abordarea tradițională cascadă. Defecte au fost găsite prea târziu în ciclul de viață, deoarece testarea nu a fost implicată până la sfârșitul proiectului. Testarea a adaugat de asemenea întârziere în timp din cauza implicării sale tarzie.

V-model recomandă ca testarea să înceapă cât mai curând posibil în ciclul de viață, ceea ce reprezintă unul dintre principiile fundamentale de testare structurată. De asemenea, arată că testarea nu este doar o activitate bazată pe execuție.

Există o varietate de activități care trebuie să fie efectuate înainte de sfârșitul fazei de codare. Aceste activități trebuie să se desfășoare în paralel cu activitățile de dezvoltare, și testorii trebuie să lucreze cu developerii și analiștii de afaceri astfel încât să poată efectua aceste activități sau sarcini și pentru a produce un set de livrabile de testare.

Produsele fabricate de developeri și analiști de afaceri în timpul de dezvoltare sunt baza de testare în una sau mai multe niveluri. Prin demararea design-ului de test devreme, sunt adesea găsite defecte în documentele de bază de testare.

O bună practică este de a avea testori implicați chiar mai devreme, în timpul review-urilor de documente folosite de testare.

V-model este un model care ilustrează modul în care activitățile de testare (verificare și validare) pot fi integrate în fiecare fază a ciclului de viață.

În cadrul V-model, testarea de validare are loc în special în stadiile incipiente, de exemplu, revizuirea cerințelor utilizatorilor, iar mai târziu în ciclul de viață, de exemplu, în timpul testelor de acceptanță.

Deși variante ale V-model există, un tip comun de V-model folosește patru niveluri de testare.

Cele patru niveluri de testare utilizate, fiecare cu propriile obiective, sunt:

testarea pe componente (“component testing“) : caută defecte în componentele software care sunt separat testabile și verifică modul de funcționare al acestora (de exemplu, module, programe, obiecte, clase etc)

testarea de integrare (“integration testing“): testează interfețele dintre componente, interacțiuni între diferite părți ale unui sistem, cum ar fi un sistem de operare, sistemul de fișiere sau interfețele între sisteme

testarea de sistem (“system testing“): concentrată cu comportamentul întregului sistem / produs astfel cum se definește în scopul proiect de dezvoltare sau de produs. Principalul obiectiv al testării de sistem este verificarea în raport cu cerințele specificate

testarea de acceptanță (“acceptance testing“): testarea de validare cu privire la nevoile utilizatorilor, necesită procese de business pentru a determina dacă sau nu se acceptă sistemul.

Figura 1.2: Modelul V

În practică, un V-model poate avea mai multe niveluri, mai puține sau diferite niveluri de dezvoltare și testare, în funcție de proiect și produsul software.

Cicluri iterative

Nu toate ciclurile de viață sunt secvențiale. Există, de asemenea cicluri iterative sau incrementale în care, în loc de o dezvoltare în timp de la început până la sfârșit, realizăm cicluri pentru un număr mai mic de faze ale aceluiași proiect.

Ca și în cazul V-model, există multe variante de cicluri de viață iterative.

O trăsătură comună a abordării iterative este că livrarea este împărțită în trepte sau construiește cu fiecare increment noi funcționalități.

Incrementul inițial va conține infrastructura necesară pentru a susține funcționalitatea inițială a build-ului.

Incrementul produs printr-o iterație poate fi testat la mai multe niveluri, ca parte a dezvoltării sale. Creșterile ulterioare vor avea nevoie de testare pentru noua funcționalitate, testarea de regresie a funcționalității existente, testare de integrare pentru părțile noi și cele existente. Testarea de regresie este mai importantă începând cu a doua iterație.

Acest lucru înseamnă că mai multă testare va fi solicitată la fiecare etapă de livrare care trebuie să fie permisă în planurile de proiect. Acest ciclu de viață poate da prezență timpurie pe piață cu funcționalitate critică, poate fi mai simplu de gestionat deoarece volumul de muncă este împărțit în

bucăți mai mici, și poate reduce investiția inițială, deși aceasta poate costa mai mult pe termen lung. De asemenea, prezența timpurie pe piață va însemna că testarea de validare se realizează la fiecare increment, oferind astfel feedback devreme cu privire la valoarea de afaceri și fitness pentru utilizare a produsului.

Exemple de modele de dezvoltare iterative sau incrementale sunt prototipuri, Rapid Application Development (RAD), Rational Unified Process (RUP) și dezvoltare Agile.

Figura 1.3: Model iterativ de dezvoltare

Agile development

Extreme Programming (XP) este în prezent unul dintre modelele cele mai cunoscute agile. Metodologia pretinde a fi mai prietenoasă decât metodele tradiționale de dezvoltare. Unele caracteristici ale XP sunt:

Se promovează generația de povești de afaceri pentru a defini funcționalitatea

Se cere un client on-site pentru feedback continuu și să definească și să efectueze testele de acceptare funcțională

Se promovează programare de tip pair și cod de proprietate partajată între dezvoltatori

Acesta prevede că script-urile pentru testarea componentelor trebuie să fie scrise înainte de scrierea codului și că aceste teste ar trebui să fie automate

Se afirmă că integrarea și testarea de cod se va întâmpla de mai multe ori pe zi

Acesta prevede că punem în aplicare întotdeauna cea mai simplă soluție pentru a face față problemelor de astăzi

Cu XP există numeroase iterații, fiecare necesitând testare. Developerii XP scriu fiecare caz de test la care se pot gândi și îl automatizează.

De fiecare dată când se face o schimbare în cod și e testat pe componente, apoi integrat cu codul existent, care este apoi complet testat de integrare folosind un set complet de cazuri de testare. Acest lucru oferă integrare continuă, prin care înțelegem că schimbările sunt încorporate continuu în software build.

Capitolul 2. Noțiuni de testare negativă

Unele abordări în ceea ce privește testarea recomandă ca scopul echipei de testare să demonstreze, cu un anumit nivel de încredere, că sistemul testat funcționează corect.

Testarea negativă demostrează exact opusul; ea  caută sa demonstreze că software-ul nu funcționează corect, caută si găsește puncte slabe ale sistemului pănă când reușeste să găsească o cale de a exploata o parte vurnerabilă a sistemului, deteriorează sistemul si apoi urmărește dacă acesta se redresează sau devine compromis. Cele două abordări descrise mai sus sunt complementare, dar au scopuri total diferite [7].

2.1. Obiectivele testării negative

Definiția testării negative dată de British Standard in BS7925-1 [8], preluată de la Beizer [9] este:

Testarea negativă este testarea care are ca obiectiv să demonstreze că software-ul nu functionează corect. Aceasta poate conduce la o serie de obiective complementare și concurențiale:

Descoperirea de greșeli care determină erori funcționale semnificative, incapacitate de a mai funcționa, breșe in sistemul de securitate etc.

Monitorizarea si analiza raspunsurilor generate de sistem datorată anumitor probleme externe.

Descoperirea punctelor slabe ale softului și posibilitățile de exploatare ale acestora.

Cu toate că este o definiție acceptabilă, nu se poate spune că este general acceptată. Testarea negativă este un termen redefinit de la o companie la alta și uneori chiar de la o echipă la alta. Practica, deobicei, diferă față de definiția dată de British Standard în sensul că include teste care au ca scop să testeze funcționalități care au legătura cu erori:

Validări de input, rejectări și funcționalități de repetare a unor cereri: input uman sau sisteme externe.

Validări de date interne și rejectări.

Comportamentul în cazul absenței unor resurse externe sau întreruperii acestora.

Funcționalitățile de procesare a erorilor: mesagerie, logare, monitorizare.

Functionalități de recuperare: fail-over, rollback si restoration.

Direcții strategice:

De multe ori testarea negativă are si scopuri care nu definesc scopul de activitate, dar cu siguranță impune alegerile făcute pentru crearea si executarea testelor. Acestea pot include:

Expunerea promptă a valorilor negative semnificative.

Înțelegerea funcțiilor prin studiul disfuncțiilor

Verificarea și îmbunătățirea modelului risc folosit pentru prioritizarea testării.

Documentarea erorilor de funcționare comune, a simptomelor caracteristice și a testării corecțiilor.

2.2. Managementul testării negative

Testarea, per ansamblu, este reactivă, open-ended și greu de apreciat înainte de a fi încheiată. Chiar dacă testarea negativă este parte integrantă a multor abordări de testare, uneori este explicit exclusă din spectrul testării.

Secțiunile următoare descriu o modalitate de bugetare, planificare și suport pentru testarea negativă și prezintă diferențele dintre testarea scriptică si cea exploratorie.

2.2.1 Bugetarea si estimarea

Estimarea este o abilitate dobândită, bazată pe o varietate de evaluări, iar procesul de estimare poate fi mai benefic decât estimarea propiu-zisă.

Estimarea de timp și bani necesară testării negative are nevoie de o abordare formată din trei părți, fiecare parte având propria balanță pentru costurile planificate și potențialul de a investi în noi teste, daca e necesar.

2.2.1.1 Testele scriptate și investiția inițială

Unele teste negative pot fi derivate folosind tehnici formale. Acestea sunt deseori scritate și pot fi relativ simplu estimate într-o maniera uzuală, granulară.

Estimările trebuie să reflecte faptul că testarea negativă nu este simplă, nu este intr-o singură fază, ci se extinde pe mai multe activități.

Testarea negativă poate compromite alte teste și poate avea nevoie de un mediu separat și suport specializat. Poate fi foarte bine îmbunătațit cu ajutorul utilitarelor (tools) și poate avea nevoie de expertize care la momentul respectiv nu există în echipa de testare.

Testele scriptate vor ajuta pentru a ințelege unele dintre aceste nevoi și vor determina luarea in considerare investiții în: echipament hardware suplimentar, licențe, dezvoltare si training.

2.2.1.2 Testarea negativă primară

Această testare negativă se concentrează pe modurile de eșec (failure), observarea acesteia, evaluarea modelului de risc și găsirea de probleme noi, necunoscute.

Tehnicile formale și listele de verificare pot permite anumite estimări granulare, iar analiza modurilor de eșec pot indica resursele de laborator pentru testare necesare. În funcție de planificare si realizând bugetul in alta etapa a proiectului, e posibil să se producă o suprapunere cu analiza făcută pentru designul si testarea unitară [7].

O parte din estimări vor trebui să se bazeze pe resursele disponibile și rezultatele așteptate; dacă resursele sunt limitate, o alegere făcută in favoarea efectuării testării negative poate compromite o posibilă alegere în favoarea altei testări/activități.

2.2.1.3 Testarea negativă secundară

Aceasta testare este necesar a fi efectuată după startul ciclului de test și include teste care să găseasca defecțiuni odată ce o nouă breșă sau vulnerabilitate a fost găsită și să diagnostice testele negative.

Trebuie considerat de asemenea rezerve de timp pentru testarea negativă primară, teste în domenii noi și teste în domenii cu riscuri noi. Foarte puțin din acest tip de testare poate fi planificată. La fel ca și în cazul testării de regresie si retestării, riscul și resursele disponibile vor limita testele în care se poate investi.

Este posibil să se poată obține o estimare din proiecte anterioare sau planificarea pentru flexibilitate, bazată pe densitatea de defecte găsite pe parcursul derulării proiectului. În cazul unui proiect cu un buget fix sau termene limită, aceste teste vor înlocui alte teste.

Pentru a determina care teste trebuie să fie excluse, este nevoie de o evaluare, activitate pentru care trebuie alocat timp si resursele necesare.

2.2.2 Planificarea

Testarea negativă nu are o poziție bine definită intr-un proces waterfall sau iterativ si de aceea, în general, nu este considerată ca si o fază distinctă. Mai degrabă este o modalitate de a clasifica anumite teste și de a direcționa o parte din efortul de testare.

În mod obisnuit, testarea negativă este de cele mai multe ori folosită în cadrul testării de sistem si testării de integrare; ea este proiectată si executată de către testori din cadrul echipelor de testare. Testarea negativă este o activitate open-ended. Dupa cum s-a văzut mai sus în secțiunea de estimare, unele elemente ale testării negative nu pot fi planificate în nici un detaliu, dar trebuie abordate în mod proactiv.

2.2.2.1 Activitățiile

Testarea negativă include următoarele activități:

Design-ul formal și execuția testelor negative

Crearea și executarea testelor negative exploratorii

Evaluarea riscurilor și a posibilelor exploatări a unor vulnerabilități

Teste diagnostic și înregistrarea problemelor aferente

Comunicarea in cadrul echipei a exploit-urilor și vulnerabilităților

2.2.2.2 Planificarea testării si alegerea echipei

Abilitatea de a face software-ul sa nu mai funcționeze sau să o facă, dar cu erori, este o compentență importantă si greu de dobândit. De aceea, cei mai buni testori de teste negative sunt testorii care fac din meseria lor o carieră. Abilitățile lor nu pot fi pe deplin folosite decât atunci când sistemul de testat este integrat într-un mediu cât mai apropiat de condițiile reale de funcționare ale sistemului.

Oricum, testarea negativa se regăsește în toate fazele unui proiect.

Urmatorul tabel prezintă câteva considerații legate de planificarea testării si alegerea membrilor echipei, in mare parte împărțite pe faze:

2.2.2.3 Excluderea

Testarea negativă este uneori explicit exclusă din testarea unitară testarea UAT. Cu toate acestea, obiectivele testării sunt folositoare pe parcursul proiectului și orice excludere ar trebui bazată pe evaluările de risc și susținute de o realocare a task-urilor.

Este de asemenea foarte ușor pentru strategii să excludă testarea negativă pentru a schimba responsabilitățile și pentru cei care planifică să o ignore pentru că este dificil de planificat.

Dacă este explicit exclusă, e de preferat să existe un tip de definiție care să îi limiteze caracteristica open-ended, deoarece altfel ar deveni un tip de teste pentru care nimeni nu ar dori sa fie responsabili.

2.2.3 Suportul

Testarea negativă poate fi susținută de tool-uri de calitate, dar poate fi nesusținută într-un mediu ostil acestui tip de testare. Cel mai important lucru este să fie susținută această testare, susținere ce se poate realiza având competențele necesare în cadrul echipei și încurajând echipa și membrii ei să își îmbunătățească aceste competențe.

2.2.3.1 Competențele testorului și sprijinul pentru perfecționarea continuă

Cu toate că experiența este importantă pentru testarea negativă, orice echipă de test, în timp, poate deveni mai bună în testarea negativă, pentru că membrii ei acumulează experiență despre punctele slabe tipice si vulnerabilități. Înțeleg mai bine cum funcționează sistemul care trebuie testat și ce fel de teste se pot executa. Această perfecționare trebuie încurajată dacă se dovedește a fi sustenabilă.

Managerii trebuie să aibă un rol activ în realizarea următoarelor:

Transferul de compentențe în cadrul echipei, în mod particular al acelor competențe 'intuitive' dobândite de testorii experimentați.

Testarea în pereche permite ca modelele, competențele și strategiile testorilor intuitivi să poată fi urmărite de către alți membrii ai echipei, care pot  să își dobândească aceste competențe sau să le folosească ca bază pentru alte tehnici de testare.

Transferul de cunoștiințe în cadrul echipei, în particular, pentru punctele slabe și vulnerabilitățile sistemului de testat.

Transferul de cunoștiințe către echipa de design-eri și programatori în ceea ce privește implementarea și arhitectura sistemului.

Folosirea ideilor, perspectivelor și analogiilor din afara proiectului: cărți, analogii, training și conferințe.

2.2.3.2. Suportul tehnic

Testarea negativă, ca testare de performanță și stres, poate avea nevoie de propriul mediu, pentru a evita compromiterea muncii altora. Utilitarele pot face testarea negativă mai simplă și mai rapidă; pot oferi perspective de testare care nu ar fi posibile fără utilitarul respectiv.

Dar asemenea tool-uri tind să fie realizate la cerere, ceea ce poate duce la consumarea bugetului încă în fazele inițiale ale proiectului.

Suportul programatorilor și design-erilor poate avea ca rezultat găsirea punctelor slabe și vulnerabilităților sistemului, ceea ce nu ar fi evident pentru un black-box tester.

2.2.3.3 Suportul managerial

Testarea negativă are nevoie de suport managerial dacă se dorește să rămână efectiv si de valoare – mulți test manageri știu foarte bine cum să asigure un astfel de suport. Unii chiar evită să folosească termenul de testare negativă pentru că, in opinia lor, este un termen prea 'negativ' .

Indiferent de abordare, important este ca business-ul să înțeleagă valoarea informației produsă de testarea negativă. Nu doar că testorii, care sunt deseori primii apărători ai clienților, lucrează cu un

sistem integrat, in fază finală, funcțională, dar și competențele specializate ale testării negative pot expune imperfecțiuni/defecte care sunt fatale relației cu clienții.

Este foarte important ca testorii să înțeleagă valoarea pe care business-ul o atribuie informației generate de testarea negativă. Această ințelegere nu doar că va motiva echipa, dar o va ajuta să iși perfecționeze abordările în ceea ce privește crearea valorilor negative și testele care folosesc aceste valori.

Competența discutată mai sus este o competență importantă atunci când este nevoie să alegi cele mai utile teste într-o perioadă de timp limitată.

2.2.4 Scriptat sau exploratoriu

Tehnicile formale pentru derivarea testelor pot fi folosite pentru testarea negativă și sunt eficiente pe perioada design-ului si testării unitare. Dar, în ultimele etape, testarea negativă e reactivă, open-ended și poate fi dificil de executat.

Abordarea reducționistă a majorității tehnicilor formale poate avea ca efect obținerea unui mare număr de teste, care necesită multi timp pentru a fi executate și fără o idee concretă despre aria de acoperire. O proporție semnificativă a testării negative în aceste ultime etape vor fi parțial scriptate sau exploratorii.

2.3. Strategii de selectare a testelor

Strategiile de selectare a testelor ajută echipa să decidă care teste să fie planificate, executate și care sunt prioritare. Testarea negativă este open’ended, iar strategiile de selectare a testelor trebuie să aibă in vedere faptul că rezultatele unui test poate genera un nou set de alte teste importante.

O metodă de a realiza acestă strategie este alegerea testelor care permit testarea sistemului în ansamblul lui. Următoarea abordare se bazează pe următoarele idei:

– Testează eficacitatea și robustețea tratării excepțiilor de sistem în fazele inițiale ale testării. Rezultatele testelor efectuate mai tărziu vor depinde de acuratețea si calitatea tratării acestor excepții.

– Folosește o gamă largă de teste negative pentru a testa sistemul din mai multe perspective diferite. Aceasta te va ajuta să verifici și să îmbunătățești modelul risc al sistemului pe care îl vei folosi in vederea prioritizării altor teste.

– Explorează sistemul, căutând posibile puncte slabe ale acestuia. Prioritizează efortul pentru testare.

– Prioritizează testarea în funcție de vulnerabilitățile cunoscute. Această acțiune poate găsi defecte sau să ofere încredere crescută în ceea ce privește robustețea sistemului.Vulnerabilitățile care tind către un crash al sistemului sunt candidate cu sanse bune, pentru această abordare.

– Prioritizează testarea în funcție de modurile de eroare cunoscute, în mod special acelea unde analiza de impact indică serioase consecințe.

– Abate-te de modul în care testezi, mai ales dacă testarea merge bine, si vei avea șanse să găsești riscuri, care nu au fost luate înca în considerare, într-un timp mai scurt.

-Încearcă să găsești cât mai multe căi pentru a forța sistemul să fail-uie, căi care nu se incadrează în modul de testare obișnuit.

Un model risc descrie riscurile cunoscute și așteptate ale produsului. Unele modele sunt formal documentate, altele sunt doar cunoscute în cadrul testării.

Modelul risc este folosit pentru a ușura proiectarea sistemului din punct de vedere al tratării riscurilor și pentru a ușura prioritizarea testării. Unul din importantele riscuri ale testării bazate pe risc este acela ca modelul risc este greșit sau incompatibil.

2.3.1. Când să te oprești

Dacă termenele limită și bugetul au o oarecare flexibilitate, cea mai logică abordare este să se oprească testarea atunci când nu se mai găsesc probleme noi semnificative. Această evaluare trebuie întotdeauna să fie făcută doar dacă există certitudinea că întregul sistem a fost testat.

Se pot folosi metrici bazate pe cerințe sau funcționalități. În cazul proiectelor cu termene limită ferme, informațiile obținute pot fi folosite pentru a prioritiza testele și a justifica eventualele cereri de prelungire a termenelor.

Pentru că testearea negativă este open-ended și poate diminua acoperirea de testare, aceasta nu este o cale utila de a hotari cand e optim sa se opreasca testarea negativă.

Testarea negativă este open-ended.

Așa cum un set de răspunsuri greșite sau nepotrivite este deseori mult mai mare decât unul de raspunsuri corecte, așa și numărul posibil de teste negative depășește cu mult numărul de teste care folosesc acțiuni și date de intrare acceptabile.

Cu toate că e posibil să se folosească tehnici formale pentru a obține un număr limitat de teste, care să valideze funcționalitatea, numărul de teste care pot demonstra contrariul este nelimitat.

Acoperirea de testare într-un set de teste open-ended este greu de realizat. Strategii ca, ‘Întâi riscul cel mai mare’, presupun că testele pentru riscurile cele mai mari sunt deja cunoscute, dar totuși problemele de sistem indică nevoia de noi teste, care sunt mai importante decât cele existente.

Testarea negativă are potențialul de a diminua acoperirea de testare, pentru că poate avea ca rezultat informații despre ineficiența setului de teste existent. Este posibil să fie folosite tehnici formale pentru a obține anumite seturi deteste negative definite, în special pentru testarea tratării excepțiilor.

2.4. Tehnici pentru crearea de teste

Testarea negativă nu este o tehnică de a crea teste, ci mai degrabă este o abordare sau clasificare. Este posibil să folosești numeroase tehnici formale de creare de teste pentru a obține teste care pot fi calificate ca teste negative.

Secțiunea care urmează prezintă aplicarea unor tipuri de tehnici bine cunoscute:

Analiza Valorile de Limită (boundary) si Partiționarea în clase de echivalență

Testarea tranzițiilor de stare

Testarea împotriva unor restricții cunoscute

Modul Failure si analiza efectelor

Simultaneitatea

Use cases și mis-use cases

2.4.1 Analiza valorilor de limită și Partiționarea în clase de echivalență

Aceste două tehnici sunt bazate pe datele de intrare și ieșire și pe comportamentul așteptat la sistemului.Analiza valorilor de limită (Boundary Value Analysis (BVA)) examinează aceste elemente de date care pot lua un interval de valori, folosind cerințele și design-ul pentru a anticipa granițele unde comportamentul sistemului se schimbă.

Ideea este să obții trei valori: una, care este chiar limita și câte una de fiecare parte a limitei (atât de aproape cât cuantificarea permite). Dacă limita este între intervale valide și invalide, testul care utilizează valorile invalide va fi un test negativ; de exemplu, folosind numărul 66 într-un câmp pentru vârsta unei persoane, câmp care acceptă doar valori între 18 si 65.

Partiționarea în clase de echivalență are de a face cu intervalul dintre limite. Fiecare membru a unei clase de echivalență trebuie, în contextul unui test cunoscut, să aibă același efect asupra sistemului (cu alte cuvinte, rezultatele oricărui test din aceeași clasă trebuie să fie similare).

Astfel, testorul nu trebuie să testeze fiecare valoare dintr-o clasă de echivalență.

Intervale de date de input invalide pot fi considerate teste negative. De exemplu, pentru un câmp destinat vârstei unei persoane, se poate presupune că va rejecta toate numerele negative în acelasi mod.

Partiționarea în clase de echivalență (Equivalence Class Partitioning (ECP) conține de obicei mai degrabă valori necontinue decât intervale de valori continue. De remarcat faptul că anumite input-uri pot părea echivalente, dar pot produce rezultate foarte diferite. De exemplu, input-ul într-un simplu formular web poate fi rejectat dacă nu conține nimic sau e prea lung, dar combinația corectă de caractere de control compromite securitatea web server-ului.

2.4.2 Testarea tranzițiilor de stare

Având o diagramă cu tranzițiile de stare sau un concept echivalent, este simplu să creezi teste care să examineze în mod explicit dacă stările, care teoretic nu pot fi atinse, sunt intr-adevăr de neatins.

O variație pe această temă funcționează la fel ca și testarea n-switch; după un set cunoscut de tranziții, sunt încă în stările inițiale. Utilitare grafice, cum ar fi Compendium-TA [10], pot ajuta pentru a crea astfel de teste.

2.4.3 Testarea împotriva unor restricții cunoscute

Majoritatea sistemelor au restricții și limitări explicite și implicite. Considerând aceste restricții ca și cerințe, se pot obține o serie de teste negative [11].

Exemple:

’Site-ul este conceput să poată fi accesat folosind Internet Explorer 9 sau o versiune mai recentă’ – un test negativ ar fi să se folosească Internet Explorer 8 sau Mozilla.

‘Sistemul nu va fi folosit de mai mult de 5 utilizatori în acelaș timp’ – un test negativ ar încerca să folosească 6 utilizatori; apoi 8 utilizatori.

De obicei aceste teste implică analiza și observarea comportamentului sistemului, mai degrabă decât testarea directă împotriva rezultatelor așteptate. Aceasta se poate realiza doar dacă se operează în afara parametriilor operativi ai sistemului, iar observațiile pot conduce la o înțelegere mai bună a sistemului.

2.4.4 Modul Failure si analiza efectelor

Este posibil să prezici o eșuare (failure) caracteristică sistemului pe baza anlizei tehnologiei folosite, implementării și erorilor cunoscute. Această analiză este baza pentru testele care urmăresc comportamentul sistemului în condiții de eșuare.

Este important să capturezi și să documentezi această informație – în mod special dacă este permisă investigarea datelor sau a mediului de testare. O astfel de documentație este deseori cerută de către organizații/clienți ca parte integrantă a rezultatelor testării. Aceste organizații monitorizează propriile sisteme și au experți tehnici care pot interveni în timp ce sistemele sunt în funcțiune (exemple: bănci, companii de telefonie).

Alternativ, în anumite situații, informația poate deveni parte a unui F.A.Q. sau ghid de troubleshooting. Aceste teste pot fi imposibil de executat fără ajutor pentru testare sau un driver de aplicație. Asemenea ajutoare (support) sunt deseori personalizate pentru client.

Totuși, utilitare cum ar fi Canned HEAT și Holodeck (ambele de la institutul de tehnologie din Florida) permit introducerea de failure generice in aplicații Windows [12].

2.4.4.1 Familii de invalidări

Există o varietate de surse care pot fi de folos pentru crearea de familii de moduri failure. Analiza originii a erorilor existente, documentația design-ului sistemului, cunoașterea problemelor caracteristice a infrastructurii, toate acestea pot ajuta pentru identificarea modurilor failure și astfel pot furniza sursa pentru teste derivate.

2.4.5 Simultaneitate

Testarea folosirii resurselor în mod concurențial poate fi o metodă foarte bună pentru a găsi defecte (bugs). Analiza inițială implică identificarea de date, entități ale bazelor de date, fișiere, conexiuni și echipamente, care pot fi folosite/accesate simultan de mai multe procese.

Utilitarele custom-built pot fi de folos, permițând testorului să folosească o resursă inainte ca sistemul să o folosească și să renunțe la acea resursă după ce nu mai are nevoie de ea. Testele trebuie, de asemenea, să verifice dacă requestor-ul următor poate obține controlul acelei resurse.

Testele mai complexe vor considera folosirea mai mult decât două cereri, puneri în coadă de așteptare, timeouts și deadlocks.

2.4.6 Scenarii de folosire corectă si incorectă a sistemului testat

Scenariile de folosire corectă a sistemului testat, în practică, tind să aibă de a face cu folosirea așa-zisului ‘happy path’. Varietatea de input-uri greșite, cicluri de rejectare și tranzacții parțiale este destul de rar întâlnită.

Termenul ‘mis-use case’, chiar dacă nu e folosit de toată lumea la fel, poate ajuta să fie identificate și diferențiate aceste scenarii în mod explicit. Scenariile care folosesc acest tip de abordare pot ajuta pentru îmbunătățirea design-ului, prin ilustrarea activităților utilizatorului care sunt în afara intervalului normal de comportament și permit o abordare formală asupra selecției si acoperirii testării.

Câteva mis-use cases generale pentru un GUI sau browser pot include următoarele acțiuni sau variații:

Completarea câmpurilor: schimbarea ordinii secvențiale obișnuite intr-un formular

Reintroducerea de date după o rejectare a datelor anterior introduse

Schimbarea detaliilor existente

Folosirea opțiunii ‘cancel’

Folosirea opțiunii ‘redo’

În browser-e, navigarea folosind butonul ‘Back’, bookmarks etc

Omiterea folosirii logout-ului dintr-o sesiune

2.5. Testarea parțial scriptată

Testarea parțial scriptată poate introduce o parte din controlul testării scriptate, fără a fi nevoie de prea multă mentenanță. Teste parțial scriptate pot ajuta componentele exploratorii ale testării negative să fie parte importantă a testării negative.

2.5.1 Checklists

Testele scripate pot fi dificil de scris și administrat, pe când un checklist poate controla, limita si măsura activitatea de testare într-un mod simplu. Aceste checklists pot fi administrate mai usor și în cazul în care sunt păstrate centralizat; pot servi ca bază pentru noi teste pentru întreaga organizație.

Checklist-uri utile pentru testarea negativă includ:

Liste de input-uri care să fie folosite atunci când se verifică validarea sau liste cu input-uri negative atunci când se verifică invalidarea

Tehnici de găsire a vulnerabilitățiilor

Liste cu mesaje de eroare

Configurarea în afara valorilor restrictive

Pașii parcurși pentru ‘happy path’

2.5.2 Măsurători în cazul circumstanțelor controlate

Este greu de definit cantitativ rezultatele așteptate ale unor teste. Unele teste necesită măsurători si analizarea unui număr de factori corelați, fără decizia de pass/fail de la sfârșitul testului.

Pentru a obține rezultate consistente sau pentru a măsura gradul de inconsistență, este util să existe o abordare scriptată, repetitivă.Această abordare permite folosirea unui baseline; testorii pot devia de la această bază si pot documenta schimbările care le-au incercat.

Aceasta abordare este în mod particular potrivită pentru analiza modului de invalidare (failure), funcționalitatea de redresare (recovery) în urma unei erori de sistem și acțiunile intreprinse pentru soluționarea problemelor din cadrul sistemului de tratare a excepțiilor.

2.5.3 Scalabilitatea

Testarea este o activitate predictivă. Poate fi necesar să fie folosit doar un sistem simplu pentru a putea prezice comportamentul unui sistem complex sau pentru a putea prezice răspunsul unui sistem la o schimbare de volum. Toate sistemele vor ceda sub o anumită combinație de volum sau stres, iar testele care au ca scop găsirea limitelor sistemului (determindu-l să cedeze), pot fi catalogate ca teste negative.

O eroare poate nu e atât de evidentă ca si un crash de sistem, iar timpii de răspuns și lungimea cozii de asteptare (queue) pot reprezenta niște indicii/avertismente.Observațiile făcute asupra unui sistem care va eșua pot identifica problemele într-un sistem funcțional, inainte ca ele să devină fatale.

Mai simplu de creat decât de executat:

Teste negative sunt deseori simplu de creat, dar dificil de executat. Aceasta se explică în special la modurile de failure, simultaneitate si tratarea excepțiilor. Testele au o valoare deosebita atât pentru design-eri cât si pentru testorii care se ocupă cu testarea exploratorie.

Trebuie avut în vedere că aceste teste să dispună de suficient timp și să aibă suport din partea tool-urilor. Cele pentru injectarea de fault-uri pot converti teste imposibile în teste valide, iar utilitarele pentru monitorizare permit studierea problemelor care apar pe parcursul anumitor tipuri de teste.

Capitolul 3. Testarea negativă a interfețelor sistemului BASE24-eps

BASE24-eps este un sistem integrat de achiziție, autentificare, rutare și autorizare a tranzacțiilor financiare. Sunt procesate atât tranzacțiile tradiționale (folosind carduri de debit și de credit la ATM, , Branch Banking sau Phone Banking), cât și tranzacțiile generate folosind ultimele tehnologii în domeniul plăților electronice (Mobile Commerce Internet Banking și Mobile Banking) [13].

Un puternic interpretor de scripturi permite schimbarea logicii aplicației fără a fi necesare modificări în codul sursă. Asftfel, fiecare client își poate defini sau schimba regulile de autorizare pe parcursul execuției programului, în mod dinamic, fără a necesita cunoștințe de programare.

Sunt suportate o gamă largă de platforme hardware, precum zSeries, pSeries, Sun Solaris, HP Non-Stop sau HP-UX, sistemul de autorizare BASE24-eps având avantajul de a fi cel mai bun în ceea ce privește siguranța în funcționare, performanță, scalabilitate sau stabilitate [14].

Tehnologii:

Arhitectură client-server

Server: ANSI/cross-platform C++ (NSK, Solaris, AIX, HP-UX, zOS)

Client: Java Swing

Baze de date: cTree, Enscribe

Mesaje XML prin MQ pentru comunicare între componente

Figura 3.1: Sistemul BASE24-eps

3.1. Ce este o tranzacție financiară

O tranzacție financiară este un eveniment sau o condiție conținută în contractul dintre un cumpărător și un vânzător pentru a schimba o valoare pe plată. Aceasta implică o schimbare în finanțele a două sau mai multe organizații sau persoane fizice.

Printre tipurile de tranzacții financiare cel mai des întâlnite se numără cumpărarea și împrumutul, precum și variații sau combinații ale acestora.

Cumpărare. Acesta este cel mai frecvent tip de tranzacție financiară. Un element sau un bun este schimbat pentru bani. Această tranzacție determină scăderea finanțelor cumpărătorului și creșterea beneficiilor vânzătorilor. Ca și exemplu poate fi considerată o tranzacție imobiliară.

Împrumut. Acesta este o tranzacție puțin mai complicată, în care creditorul oferă o sumă mare de bani debitorului în schimbul a rambursări mai mici a debitorului de-a lungul timpului, de obicei pe o perioadă fixă. Rambursările întârziate adăugă cost suplimentar sumei inițiale. Diferența plăților se numește dobândă.

Cont bancar. O bancă este o afacere care se bazează aproape în întregime pe tranzacțiile financiare. În plus față de acționarea ca un creditor pentru împrumuturi și credite ipotecare, băncile acționează ca un debitor într-un tip special de împrumut numit cont.

Creditorul este cunoscut ca un client și oferă sume nespecificate de bani la bancă pentru perioade de timp neprecizate. Banca este de acord să ramburseze orice sumă în cont în orice moment și va plăti dobânzi mici la suma de bani lăsată de client în cont pentru o anumită perioadă de timp.

În plus, banca garantează că banii nu vor fi furați în timp ce sunt în cont și va rambursa suma totală în caz de furt client. În schimb, banca poate folosi banii pentru alte tranzacții financiare, atâta timp cât îi deține.

Cardul de credit. Acesta este o combinație specială între cumpărare și împrumut. Vânzătorul oferă cumpărătorului bunul, iar cumpărătorul plătește vânzătorului folosind un card de credit. În acest fel, cumpărătorul plătește cu un împrumut de la compania de carduri de credit, de obicei o bancă.

Banca sau alte instituții financiare eliberează carduri de credit cumpărătorilor care le permit orice număr de împrumuturi până la o anumită sumă cumulativă.

Termenele de rambursare pentru cardurile de credit variază, dar dobânda este adesea extrem de mare. În plus față de dobândă, cumpărătorii plătesc o taxă anuală, uneori, pentru a utiliza cardul de credit.

Cardul de debit. Acesta este un tip special de cumpărare. Elementul sau bunul este transferat în mod normal, dar cumpărătorul utilizează un card de debit în loc de bani pentru a plăti. Un card de debit conține o evidență electronică a contului bancar al cumpărătorului.

Folosind acest card, vânzătorul este capabil de a trimite un semnal electronic la banca cumpărătorului pentru suma de cumpărare, iar suma de bani este simultan debitată din contul clientului și creditată în contul vânzătorului.

Acest lucru este posibil, chiar în cazul în care cumpărătorul sau vânzătorul utilizează diferite instituții financiare. În prezent, taxele atât cumpărător și vânzător pentru utilizarea de carduri de debit sunt destul de reduse, deoarece băncile vor să încurajeze utilizarea de carduri de debit. Vânzătorul trebuie să aibă un cititor de carduri, înființat cu scopul ca astfel de achiziții să fie făcute. Cardurile de debit permit unui cumpărător să aibă acces la toate fondurile din contul său, fără a fi nevoie să se deplaseze cu bani cash [19].

3.2. Entități implicate într-o tranzacție financiară

Prin tranzacție financiară ne referim la plăți electronice realizate cu un card de credit sau de debit. Aceste tranzacții sunt inițiate la diferite terminale și sunt autorizate de către banca emitentă a cardului. În următoarea figură este evidențiat fluxul unei tranzacții financiare.

Figura 3.2: Fluxul unei tranzacții financiare

Clientul. Tranzacția are ca punct de plecare clientul, care deține un card de credit sau de debit. Clientul poate interacționa cu un vânzător în contextul realizării unei tranzacții financiare, are o relație contractuală cu Emitentul (“Issuer”) și plătește Emitentul. Pentru inițierea tranzacției, fie cardul clientului este introdus într-unul din terminalele ATM (“Automated Teller Machine”) sau POS (“Point Of Sale”), fie se utilizează un serviciu web pentru realizarea unei tranzacții online.

Achizitorul (“Acquirer”). Tranzacția inițiată la unul din cele trei terminale posibile este trimisă achizitorului, care este reprezentat de o instituție bancară în cele mai multe cazuri. Acesta are o relație cu vânzătorul, gestionează punctul de interacțiune cu ATM-ul sau POS la care are loc retragerea de bani sau cumpărarea de produse de la vânzător, intră în interacțiune cu asociațiile de transfer a tranzacțiilor.

Rețeaua (“Network”). În cazul în care terminalele de inițiere a tranzacției aparțin unei alte instituții financiare diferite de instituția emitentă a cardului, tranzacția este trimisă de la achizitor la rețea. Aceasta reprezintă de regulă o asociație economică care setează regulile de procesare, oferă cadrul tehnologic, fondează programe de marketing, nu are drepturi asupra contului clientului sau vânzătorului. Dintre cele mai cunoscute rețele amintim VISA, MasterCard, American Express [20].

Emitentul (“Issuer”). Acesta este instituția care a emis cardul, oferă sau facilitează finanțarea plății achiziției, deține linia de credit sau contul de depozit, intră în interacțiune cu asociațiile de transfer a tranzacțiilor.

Mesajul de răspuns pentru tranzacție va urma calea întoarsă până la vânzător, respectiv terminalul de inițiere a tranzacției. Tranzacția poate fi aprobată, refuzată sau informații suplimentare pot fi cerute [13].

3.3. Instrumente folosite în testarea tranzacțiilor financiare

Pentru cei care nu sunt familiarizați cu diverse metodologii de testare în general, sau cu modalitățile de testare ale sistemelor de procesare a plăților în particular, poate fi o surpriză modul în care aceste aplicații foarte complexe sunt verificate și validate.

Există câteva intrumente specifice cunoscute în industria de plăți electronice pe care le folosim și noi la ACI Worldwide și pe care le vom prezenta în continuare.

În primul rand trebuie menționat un adevăr poate mai puțin cunoscut pe care se bazează testarea. După cum menționam într-un capitol anterior testarea exhaustivă este imposibilă.

De aceea se folosesc analize de risc pentru a decide abordarea în fiecare caz în parte. Deoarece sistemele financiare nu sunt aplicații critice din punct de vedere al siguranței ( așa cum sunt de exemplu sistemele aeronautice, automotive sau feroviare), testarea se face pentru a asigura un nivel de calitate cerut de piață.

Testarea are un cost mare și de multe ori chiar clienții presează ca produsele să fie livrate mai repede pentru a fi lansate pe piață mai devreme.

Orice tranzacție financiară poate fi reprezentată sub forma unui mesaj de date, adica un șir de informații relevante

pentru tranzacția care trebuie procesată. Aceste mesaje pot fi

Figura 3.3.1: POS (Point Of Sale) foarte ușor modelate cu ajutorul unor tool-uri specifice, iar

plățile electronice pot fi simulate fără diferențe foarte mari față de cazul în care tranzacțiile ar fi fost inițiate de la dispozitive sau ATM reale.

Worldwide folosește atât simulatoare de tranzacții dezvoltate de către compania noastră ( Asset Simulator) cât și alte simulatoare cunoscute și agreate de către mari procesatori sau instituții bancare și financiare. (Paragon Fastest, Paragon ATMulator, VersaTest, Mastercard Authorization Simulator). Asset, simulatorul dezvoltat de este folosit în marea majoritate a proiectelor pentru testarea tranzacțiilor financiare, dar este și un produs de sine stătător care în ultimii ani a crescut foarte mult, a acoperit o multitudine de funcționalități noi, a devenit mai robust și mai fiabil, și a avut un real succes fiind cumpărat de foarte mulți clienți.

Așa cum am mai menționat anterior orice simulator de tranzacții financiare poate emula tranzacțiile reale din viața

de zi cu zi: pentru ATM retrageri, depuneri, transferuri între

conturi, plăți facturi, printare chitanță etc, iar pt POS Figura 3.3.2: Bancomat (ATM)

cumpărături, încărcare cartelă telefonică, returnare produse

și altele.

Simulatoarele de test oferă și alte functionalități, de exemplu de salvare a unor rezultate, altfel încât la o nouă rulare a aceluiași test îți poate semnala dacă rezultatele sunt similare sau nu. Aceste instrumente sunt foarte flexibile, foarte ușor de folosit, și permit integrarea lor în cele mai complexe

configurații. Pot oferi și servicii de criptografie necesare pentru testarea cardurilor cu chip sau pentru rularea unor tranzacții autorizate prin verificarea -ului.

Simulatorul ASSET

Această aplicație simulează dispozitive ce generează tranzacții electronice de la ATM, și interfețe pentru rețele financiare precum VisaNet, Europay, AMEX (American Express). Tehnologiile folosite sunt limbajul C++, Microsoft Foundation Classes și un limbaj propriu de criptare pentru dezvoltarea de simulatoare.

Acest simulator, impreuna cu alte tool-uri vor fi folosite în continuare pentru testarea interfețelor sistemului BASE24-eps. Prin intermediul acestor interfețe se realizează procesarea de tranzacții inițiate de la diverse tipuri de terminale, transmise apoi catre retele de plati, banca emitentă (cea care a eliberat cardul folosit in tranzacție), iar apoi înapoi către terminalul/locația de unde a fost inițiată tranzacția [21].

Printre terminalele si interfețele care pot fi simulate cu aplicatia ASSET, se numară [15]:

– NCR+ Device Handler

– Diebold Device Handler

– Triton Device Handler

– IFX ATM Device Handler

– Wincor NDC Device Handler

– Standard POS Device Handler (SPDH)

– VISA ISO Interface

– American Express

– Banknet

– MasterCard Debit Switch (MDS)

– ISO Host Interface (ISO8583 1993)

– ISO Host Interface (ISO8583 1987)

Simulatorul ASSET este o applicație Windows. Având in vedere că aplicația este scrisă pentru acest sistem de operare, este usor de intuit că va face uz de interfațare grafică pentru interacțiunea cu utilizatorul.

Simulatorul interfeței testate, precum si cel al issuer-ului generic (în cazul nostru denumit ISO93) este format din mai multe componente. Printre cele mai semnificative se numără:

componenta grafică (GUI) cu ajutorul căreia se configurează si comandă simulatorul

componenta de date: un fișier excel, care conține date de configurare a simulatorului, date de validare etc [16].

un folder care conține logurile tuturor testelor executate

În următoarele 2 imagini sunt prezentate primele 2 componente ale simulatorului care au fost enumerate mai sus: componenta grafică si componenta de date.

Figura 3.3.3: Componenta grafică

Figura 3.3.4: Componenta de date

3.4. Testarea pozitivă

Testarea negativă a interfețelor sistemului BASE24-eps este în strânsă legătură și are o serie de elemente comune cu testatea pozitivă a acestor interfețe. De aceea, pentru o înțelegere cât mai bună a testării negative a interfețelor sistemului BASE24-eps, voi începe cu o descriere succintă a testării pozitive a acestor interfețe.

Pentru testarea pozitivă a interfețelor se vor folosi entitățile implicate intr-un flux simplificat de tranzacției financiară, flux prezentat în figura de mai jos:

Figura 3.4: Fluxul simplificat al unei tranzacții financiare

Testarea mesajelor request ale unei interfețe date

Entitățile vor fi reprezentate după cum urmează:

Acquirer = Simulator ASSET corespunzător interfeței testate (să îl denumim, de exemplu, Simulatorul pentru interfața A sau mai pe scurt Simulatorul IntfA)

Network = Sistemul BASE24-eps

Issuer = Simulator ASSET reprezentând un host generic (să îl denumim, de exemplu, Simulatorul ISO93)

În această configurație vor putea fi testate mesajele de tip request pe Interfata A din BASE24-eps și/sau câmpurile care sunt trimise în acest tip de mesaje.

Simulatorul IntfA trimite un mesaj de tip request către sistemul BASE24-eps. Acesta procesează mesajul primit și, în funcție de rezultatul procesării, trimite mai departe (sau nu) mesajul către simulatorul ISO93.

Având în vedere că în această secțiune este descrisă testarea pozitivă a interfeței, se consideră că rezultatul procesării mesajului de către sistemul BASE24-eps este unul pozitiv, deci fluxul de informații continuă spre simulatorul ISO93 (Issuer).

Issuer-ul, la rândul lui, procesează informația primită și va genera un mesaj de răspuns, care va fi trimis către sistemul BASE24-eps. Apoi, sistemul, după ce procesează raspunsul primit, il trimite mai departe către Acquirer (simulatorul IntfA).

Astfel s-a realizat întregul flux al tranzacției:

Simulatorul IntfA (Acquirer) –> BASE24-eps –> Simulatorul ISO93 (Issuer) –> BASE24-eps –> Simulatorul IntfA (Acquirer).

În configurația de mai sus a fost testat un mesaj de tip request pe Interfata A din BASE24-eps și/sau câmpurile trimise în acest tip de mesaj. Pe lângă acest tip de câmpuri care sunt trimise (doar) în mesaje de tip request, există și câmpuri care sunt trimise în mesaje de tip response și câmpuri care sunt trimise în ambele tipuri de mesaje: request și response.

Testarea mesajelor response ale unei interfețe date

Pentru a testa mesajele de tip response pe Interfața A din BASE24-eps și/sau câmpurile care sunt trimise în acest tip de mesaje, se va folosi aceeasi schemă pentru fluxul tranzacției, doar că entitățile vor fi diferite .După cum urmeaza:

Acquirer = Simulator ASSET reprezentând un host generic (să il denumim, de exemplu, ISO93)

Network = Sistemul BASE24-eps

Issuer = Simulator ASSET corespunzător interfeței testate (Simulatorul IntfA)

Simulatorul ISO93 trimite un mesaj de tip request către sistemul BASE24-eps. Acesta procesează mesajul primit și, în funcție de rezultatul procesării, trimite mai departe (sau nu) mesajul către simulatorul IntfA (Issuer).

Simulatorul IntfA, la rândul lui, procesează informația primită și va genera un mesaj de răspuns, care va fi trimis către sistemul BASE24-eps. Apoi, sistemul, după ce procesează răspunsul primit, îl trimite mai departe către Simulatorul ISO93 (Acquirer).

Astfel s-a realizat întregul flux al tranzacției:

Simulatorul ISO93 (Acquirer) –> BASE24-eps –> Simulatorul IntfA (Issuer) –> BASE24-eps –> Simulatorul ISO93 (Acqurer).

În configurația de mai sus a fost testat un mesaj de tip response pe Interfata A din BASE24-eps și/sau câmpurile trimise în acest tip de mesaj.

3.5. Testarea negativă

Similar cu testarea pozitivă, pentru testarea negativă a interfețelor se vor folosi următoarele entități implicate într-un flux simplificat de tranzacție financiară:

Acquirer

Network

Issuer

În cadrul companiei noastre, testarea negativă a interfețelor sistemului BASE24-eps se bazează pe următoarele principii:

testarea negativă se realizează prin injectarea de valori negative, nepermise pentru mesajul/câmpul testat

dacă rezultatul testului negativ este failed, mesajul/câmpul testat are comportamentul corect

dacă rezultatul testului negativ este passed, mesajul/câmpul testat nu are comportamentul corect, deci foarte posibil, a fost găsit un bug. Asta în condițiile în care fault-ul folosit este unul corect, deci reprezintă o valoare negativă validă.

Pentru a detalia rezultatul failed așteptat pentru un test negativ, sistemul BASE24-eps afișează următoarele caracteristici:

un mesaj de eroare este afisat pe consola de monitorizare a sistemului

tranzacția este logată în fișierul de excepții

memoria nu intră într-un subprogram de golire – core dump

Testarea negativă a mesajelor request ale unei interfețe date

Entitățile vor fi reprezentate la fel ca și în cazul testării pozitive al acestor tipuri de mesaje:

Acquirer = Simulatorul IntfA

Network = Sistemul BASE24-eps

Issuer = Simulatorul ISO93

Fault-ul va fi injectat în mesajul de tip request, mesaj care este trimis de Acquirer la Network.

Network-ul nu va valida mesajul și în consecință nu este trimis mai departe către Issuer.

În marea majoritate a cazurilor Network-ul nu va mai trimite nici un răspuns inapoi către Acquirer.

Schema de principiu a injectării fault-urilor pentru mesajele de tip request este prezentată în figura de mai jos:

Figura 3.5.1: Injectarea fault-urilor pentru mesaje de tip Request

Testarea negativă a mesajelor response ale unei interfețe date

Entitățile vor fi reprezentate la fel ca si în cazul testării pozitive al acestor tipuri de mesaje:

Acquirer = Simulatorul ISO93

Network = Sistemul BASE24-eps

Issuer = Simulatorul IntfA

Fault-ul va fi injectat în mesajul de tip response, mesajul care este trimis de Issuer la Network.

Network-ul nu va valida mesajul response și în consecință nu va mai trimite răspunsul mai departe către Acquirer.

În marea majoritate a cazurilor Network-ul nu va mai trimite nici un răspuns înapoi către Issuer.

Schema de principiu a injectării fault-urilor pentru mesajele de tip response este prezentată în figura de mai jos:

Figura 3.5.2: Injectarea fault-urilor pentru mesaje de tip Response

3.6. Fault Injector

3.6.1 Descriere funcțională

Pentru testarea negativă a interfețelor sistemului BASE24-eps, pe lângă folosirea simulatorului ASSET, se va folosi o altă aplicație Windows numită Fault Injector sau mai pe scurt: FI.

Funcționarea acesteia (FI) este în strânsă legătură cu funcționarea simulatorului ASSET.

Fault Injector-ul permite testarea negativă a unui sistem (în cazul nostru o interfață a sistemului BASE24-eps) prin injectarea de valori negative în mesajele de ieșire a simulatorului corespunzător interfeței testate, mesaje care sunt trimise către sistemul care trebuie testat.

Urmând logica prezentată anterior pentru testarea negativă a interfețelor, Fault Injectorul se interpune intre simulatorul ASSET, care genereaza mesajul de request sau de răspuns si sistemul BASE24-eps.

Locația, in cadrul fluxului tranzacției, unde va injecta valorile negative, este determinată de tipul de mesaj care va fi testat.

Mai jos este prezentată schema de funcționare (de principiu) a Fault Injector-ului pentru cazul injectării de valori negative in mesaj de tip Request (Acquirer fault injection):

Figura 3.6.1: Diagrama bloc a Fault Injector-ului pentru mesajele de tip Request

Acest tool joacă rolul de ‘man-in-the-middle’ așa cum se poate vedea din diagrama de mai sus. Fault Injector-ul oferă doar testare functională (spre deosebire de ASSET tool-ul care poate executa și teste de stres).

În momentul pornirii unui test negativ, simulatorul interfeței trimite tranzacția către Fault Injector, care injectează valorile negative (setate cu ajutorul componentei data mentionată mai sus) în tranzacția primită și o trimite mai departe spre System Under Test.

Funcționalitatea Fault Injector-ului pentru testarea mesajelor de tip Request constă în:

selectarea și configurarea simulatorului extern

pornirea simulatorului extern pentru modificarea proprietăților astfel încât simulatorul extern se conectează direct la Fault Injector

afișarea dialogului cu utilizatorul pentru selecția testului, care inițiază testul selectat din simulatorul extern

primirea mesajului pentru testul inițiat și injectarea valorii negative conform configurării componentei de date a Fault Injector-ului

actualizează anumite câmpuri pentru diferite sub tipuri de mesaje, în funcție de datele conținute in componenta de date a Fault Injector-ului

transmiterea mesajului modificat către System Under Test (SUT)

primirea și transmiterea mesajului de tip response catre simulatorul extern

preluarea rezultatului testului din simulatorul extern și afișarea acestuia în aplicația Fault Injector.

Mai jos este prezentată schema de funcționare (de principiu) a Fault Injector-ului pentru cazul injectării de valori negative în mesaj de tip Response (Issuer fault injection):

Figura 3.6.2: Diagrama bloc a Fault Injector-ului pentru mesajele de tip Response

În cazul testării mesajelor de tip Response, Faul Injector-ul are următoarea funcționalitate:

primește mesajul de tip răspuns de la Issuer (în cazul nostru Simulatorul Interfeței IntfA)

mapează răspunsul primit cu datele setate în componenta de date a Fault Injector-ului pentru a stabili dacă este cazul de a injecta valori negative

injectează valori negative în mesajele de tip răspuns

actualizează anumite câmpuri pentru diferite sub tipuri de mesaje, în funcție de datele conținute în componenta de date a Fault Injector-ului

transmite mai departe mesajul de tip răspuns modificat către System Under Test (SUT)

Fault Injector tool-ul este alcătuit din mai multe componente, cele mai semnificative fiind următoarele:

componenta grafică (GUI) cu ajutorul căreia se configurează si comandă utilitarul

componenta de date: un fișier excel, care conține date de configurare a simulatorului, date de validare etc

un folder care conține logurile tuturor testelor executate

un folder care conține documentație

un folder care conține scripturile folosite de tool in procesul de execuție al testelor

Similar cu tool-ul ASSET, utilitarul Fault Injector are la dispoziție un program de configurare, cu ajutorul căruia selectează simulatorul (în cazul nostru) interfeței care va fi folosit pentru testarea negativă si seteată parametrii de runtime al acestuia.

Pe lânga folosirea acestui program de configurare, mai este nevoie de anumite configurări care trebuiesc făcute manual, folosind interfața grafică pusă la dispoziție de către Fault Injector tool-ul, printre cele mai importante fiind setarea comunicării simulatorului ASSET cu Fault Injector-ul, in loc de comunicarea cu sistemul care trebuie testat (System Under Test (SUT)), așa cum se procedează la testarea pozitivă.

3.6.2 Componenta de date

Fișierul Excel care conține componenta de date de configurare, validare, execuție a Fault Injector-ului este format din mai multe tab-uri (worksheets), fiecare gupând un anumit tip de setări/configurări.

În secțiunea următoare voi enumera și prezenta, pe scurt, cele mai importante tab-uri ale fișierului Excel menționat mai sus, urmând ca apoi să descriu mai în detaliu elementele de configurare/date pentru fiecare dintre acestea.

Fault Injector Acquirer Test Cases

Acest tab conține datele și câmpurile care formează setul de teste pentru mesajele de tip Request. Având în vedere că tranzacțiile/mesajele sunt salvate în simulatorul ASSET corespunzător interfeței testate (Simulatorul IntfA), fiecare test din acest tab este de fapt o referință către un test din Simulatorul IntfA.

Fault Injector Issuer Test Cases

Acest tab conține setul de teste (datele și câmpurile) pentru mesajele de tip Response. La fel ca și în cazul Fault Injector Acquirer Test Cases, fiecare test din acest tab este o referință către un test din Simulatorul IntfA.

Fault Injector Interface Data

Acest tab conține setul de date despre Simulatorul IntfA, care va fi controlat de Fault Injector tool. Printre cele mai importante date conținute în acest tab sunt:

numele simulatorului

locația unde este instalat simulatorul

adresa IP si portul corespunzător pentru System Under Test

Fault Injector Fault Data

Acest tab conține lista de fault-uri. Fiecare fault are asociat un ID unic și o valoare negativă.

Fault ID-ul este referențiat în tab-urile mai sus mentionate: Fault Injector Acquirer Test Cases și Fault Injector Issuer Test Cases.

Fault Injector Acquirer Test Cases

În cele ce urmează voi prezenta acele elemente din acest tab care sunt importante pentru acest studiu de caz.

Fault Injector Acquirer Test Cases tab conține datele corespunzătoare testelor și elementelor de configurare folosite de Simulatorul IntfA, precum Fault ID-urile folosite pentru injectare, în cazul testării mesajelor de tip Request (Acquirer test cases).

În figura de mai jos este prezentat conținutul tipic al acestui tab:

Figura 3.6.3: Fault Injector Acquirer Test Cases tab

Printre cele mai importante elemente din acest tab se numără:

Interface ID:Valorile permise în acest câmp sunt numele interfețelor configurate listate in tab-ul Fault Injector Interface Data

Interface Scenario: Scenariul corespunzător testului care va fi executat; test care se află în Simulatorul IntfA

Interface Test Case: ID-ul test case-ului care va fi executat. La fel ca și pentru Interface Scenario, aceste informații se află în Simulatorul IntfA

Key Set ID: Acest ID este folosit în cazul tranzacțiilor care folosesc chei de criptare. De exemplu, pentru tranzacțiile de tip EMV

Batch Mode: Este un flag pentru a indica daca va test case-ul respectiv va fi rulat sau nu în cazul în care testele sunt rulate automat

Fault ID: ID-ul fault-ului corespunzător tranzacției în care va fi injectat. Acest ID este definit in tab-ul Fault Injector Fault Data

Fault Injector Issuer Test Cases

La fel ca în cazul tab-ului prezentat anterior, voi explica în cele ce urmează, pentru tab-ul Fault Injector Issuer Test Cases, elementele importante pentru acest studiu de caz.

Fault Injector Issuer Test Cases tab conține datele corespunzătoare testelor și elementelor de configurare folosite de Simulatorul IntfA, precum Fault ID-urile folosite pentru injectare, în cazul testării mesajelor de tip Response (Issuer test cases).

Anumite câmpuri din mesajul de tip Request sunt comparate cu corespondentele lor definite în acest tab, deci în mesajul de tip Response. Dacă din această comparare rezultă o potrivire, atunci mesajul de tip Response găsit in acest tab va fi folosit ca răspuns al tranzacției.

În figura de mai jos este prezentat conținutul tipic al acestui tab:

Figura 3.6.4: Fault Injector Issuer Test Cases tab

Printre cele mai importante elemente din acest tab se numără:

Interface ID: Ca și în cazul tab-ului pentru Acquirer test cases, valorile permise în acest câmp sunt numele interfețelor configurate listate in tab-ul Fault Injector Interface Data

Key Set ID: Reprezintă același tip de ID ca și cel folosit in tab-ul anterior: pentru tranzacțiile care folosesc chei de criptare

Fault ID: Reprezintă același tip de ID ca și cel folosit in tab-ul anterior: ID-ul fault-ului corespunzător tranzacției in care va fi injectat

O serie de câmpuri al căror rol a fost descris mai sus, și anume: pentru găsirea corespondenței dintre mesajul de tip Request si mesajul de tip Response; iar în caz de potrivire se va folosi Faul ID setat pentru mesajul de tip Response.

Fault Injector Interface Data

Așa cum reiese din numele tab-ului, acesta conține setul de date despre Simulatorul IntfA (simulatorul corespunzător interfeței testate), care va fi controlat de Fault Injector tool.

De reținut faptul că nu orice interfață sau terminal (reprezentat de către un simulator) poate fi folosit împreuna cu utilitarul Fault Injector. Acesta asigură suport pentru o serie de simulatoare, deci înainte de a fi folosit pentru un anumit tip de simulator, trebuie să ne asiguram ca Fault Injector tool-ul oferă suport pentru simulatorul dorit.

În figura de mai jos este prezentat conținutul tipic al acestui tab:

Figura 3.6.5: Fault Injector Interface Data tab

Printre cele mai importante elemente din acest tab se numără:

Interface ID: Reprezintă numele interfeței care va fi testată. Acest ID este referențiat in cele doua tab-uri prezentate anterior:Fault Injector Acquirer Test Cases tab și Fault Injector Issuer Test Cases tab

Repository Path: Este locația (full path) unde se află instalat simulatorul corespunzător interfeței testate (Ex: C:\Simulators\InterfaceA\InterfaceA.exe)

SUT Address: Adresa IP al sistemului testat: System Under Test

SUT Port:Portul sistemului testat

Configuration Test Name: Numele programului de configurare din Simulatorul corespunzător interfeței testate: Simulator IntfA

Functional Test Name: Numele grupului de teste funcționale din Simulatorul IntfA

O serie de câmpuri ale căror valori sunt setate cu numele câmpurilor din Simulatorul IntfA

Faul Injector tool-ul folosește SUT Address si pentru a realiza conexia dintre tool si SUT.

Fault Injector Fault Data

Detaliile despre fault-urile care vor fi folosite (injectate) în mesajele de tip Request și cele de tip Response sunt setate in acest tab. Fiecare rând din acest tab conține datele corespunzătoare unui singur fault.

Valoarea fault-ului definită în câmpul Field Value va fi injectată in mesajul de tip Request sau mesajul de tip Response (în funcție de tipul de mesaj testat) prin referențierea Fault ID-ului în tab-ul Fault Injector Acquirer Test Cases, respectiv tab-ul Fault Injector Issuer Test Cases.

În figura de mai jos este prezentat conținutul tipic al acestui tab:

Figura 3.6.6: Fault Injector Fault Data tab

Printre cele mai importante elemente din acest tab se numără:

Fault ID: Reprezintă numele ID-ul fault-ului și este unic în acest tab. Fault ID-ul este referențiat în cele două tab-uri prezentate anterior: Fault Injector Acquirer Test Cases tab și Fault Injector Issuer Test Cases tab

Field Name: Numele câmpului căruia îi va fi modificată valoarea inițială (setată în Simulatorul IntfA) în cea injectată de către Fault Injector tool

Fault Description: O descriere succintă a fault-ului. Nu are valoare funcțională, dar este utilă din punct de vedere al documentării faul-ului

Fault Type: Reprezintă tipul fault-ului. Acest tip este dictat de tipul câmpului definit în Simulatorul IntfA. Valori permise: ASCII sau HEX

Field Value: Valoarea fault-ului care va fi injectată in câmpul cu numele corespunzător valorii setate in Field Name.

Pentru un fault, dacă Fault Type este setat ASCII, conținutul Field Value-ului va fi inserat în câmp ca si caractere ASCII. Daca Fault Type este setat HEX, conținutul Field Value-ului va fi inserat în câmp ca și număr hexa zecimal (trebuie sa fie număr par de caractere: 0-9 sau A-F).

Fișierul Excel prezentat anterior este setat cu macro-uri care ajută ca datele să fie adăugate dinamic în funcție de opțiunile selectate sau de date care sunt introduse. O altă funcție folositoare adusă de aceste macro-uri este salvarea datelor/modificărilor.

Fiecare tab are câte un buton pentru salvarea modificărilor; butoane care sunt asociate cu macro-uri, care salvează datele într-un format care poate fi folosit de catre Fault Injector tool.

În continuare voi prezenta un exemplu de validare a datelor salvate cu ajutorul butoanelor de care am amintit ceva mai devreme.

Captura de mai jos este rezultatul validării modificărilor făcute în fișierul Excel, modificări neacceptate de către un macro:

Figura 3.6.7: Mesaj de eroare rezultat în urma salvării unor modificări invalide

După cum se poate observa din mesajul afișat, este raportată o eroare în tab-ul Card_Data: în ultima coloană lipsește delimitatorul END. Deocamdată nu voi detalia despre acest delimitator, dar o voi face cu ocazia următorului exemplu.

Tot din captura de mai sus se poate observa și generatorul acestui mesaj de eroare; în cazul nostru aplicația Excel.

Așa cum este descris în mesaj, cauza erorii poate fi lipsa acestui delimitator, dar, din experiența practică cu aceste macro-uri, pot menționa că pot fi si cazuri în care acest delimitator nu lipsește, dar datorită modificările efectuate, datele devin corupte (posibil anumite bug-uri minore ale aplicației Excel), iar macro-ul nu mai poate rula rutina lui cu succes.

În urmatorul exemplu, vom avea un alt tip de eroare de validare a modificărilor, cu următoarele diferențe față de primul exemplu:

în acest exemplu cauza erorii a fost lipsa delimitatorului END

fereastra cu mesajul de eroare nu mai este generată de aplicația Excel, cum a fost cazul la primul exemplu, ci de către simulator

Aceste delimitatoare (END) sunt necesare pentru a se putea determina locația de sfărsit al unui test. Deci, fiecare test trebuie să aibă ca ultim element de dată acest delimitator.

Iată și captura cu rezultatul validării modificărilor făcute în fișierul Excel, modificări neacceptate de către simulator, așa cum am amintit cu câteva rânduri mai sus:

Figura 3.6.8: Mesaj de eroare rezultat în urma rulării testului

Important de notat este faptul că această eroare nu a mai fost afișată în urma acțiunii de salvare a modificărilor făcute in tab-urile fisierului Excel, ci a fost afișată ca rezultat al executării testului.

Un alt exemplu de eroare rezultat în urma executării unui test este ilustrat în figura de mai jos:

Figura 3.6.9: Mesaj de eroare de conectivitate

În acest exemplu avem de a face cu o eroare de conectivitate. Cauzele cele mai frecvente care au ca rezultat acest tip de eroare sunt fie adresa IP a SUT este greșită, fie portul acestuia este greșit.

Aceste valori sunt salvate într-unul din tab-urile prezentate anterior, si anume: Fault Injector Interface Data.

Dacă se dorește testarea negativă a mai multor interfețe folosind același Fault Injector tool, în acest tab vor fi setate datele corespunzătoare noilor interfețe care vor fi testate.

Aceste date vor conține informațiile despre locația simulatorului corespunzător interfeței testate si informațiile de conectivitate a Fault Injector tool-ului cu SUT.

Fault Injector tool-ul trebuie setat în funcție de tipul de mesaje care vor fi testate: mesaje de tip Request sau mesaje de tip Response.

Pentru a testa mesajele de tip request se rulează programul de configurare al Fault Injector-ului și se setează opțiunea Acquirer startup mode pe Interactive.

În figura de mai jos este ilustrată aceasta setare:

Figura 3.6.10: Setarea Fault.Injector. tool-ului in cazul testării mesajelor de tip Request

Pentru a testa mesajele de tip response se rulează programul de configurare al Fault Injector-ului și se setează opțiunea Acquirer startup mode pe Inactive.

În figura de mai jos este ilustrată aceasta setare:

Figura 3.6.11: Setarea Fault.Injector. tool-ului in cazul testării mesajelor de tip Response

3.7. Execuția testelor negative pe un proiect pilot

Testele acestui proiect sunt teste la nivel de câmp și care vizează strict comportamentul/impactul câmpului respectiv.

În testarea negativă pe care o desfășurăm cu acest tool de injectare de fault-uri, este recomandat ca, înainte de a se seta și executa teste negative, să se ruleze întâi teste pozitive.

Beneficiul principal al executării unor teste pozitive, în faza inițială este acela că se verifică cu această ocazia toate componentele sistemul testat, inclusiv Fault Injector tool-ul, conectivitățile componentelor etc.

Din perspectiva Fault Injector-ului, testarea pozitivă se realizează prin setarea Fault Id-ului din tab-ul Fault Injector Fault Data, cu valoarea No Value. Astfel, la rularea testului, Fault Injector-ul nu va injecta nici o valoare în mesajul trimis către sistemul BASE24-eps, acesta va trimite mai departe mesajul către Issuer etc.

În figura de mai jos este prezentat tab-ul Fault Injector Fault Data în care Fault ID corespunzător testului care va fi executat nu are setat nici un Fault ID:

Figura 3.7.1: Setarea Fault ID-ului pentru testarea pozitivă

În imaginea de mai jos este prezentat rezultatul executării testului. Se poate observa meniul cu testele/scenariile care pot fi alese pentru a fi rulate, precum și mesajele afișate de către Fault Injector tool pe parcursul execuției testului:

Figura 3.7.2: Rezultatul executării testului pozitiv

După cum se poate observa din figura de mai sus, rezultatul testului pozitiv, afisat in Fault Injector tool-l este Passed.

Setarea și executarea testelor negative.

Totalitatea câmpurilor care sunt folosite în aceste teste formeaza un mesaj. Formatul acestui mesaj este standardizat conform ISO 8583 (standardul pentru sistemele care procesează tranzacții electronice de tip financiar).

Fiecare câmp este definit într-un format standard care definește tipul câmpului (numeric, alfabetic, alphanumeric, binar etc) cât și formatul lungimii câmpului (variabilă sau fixă) [17].

Câmpurile cu lungimea variabilă reprezintă un format aparte. De aceea, în continuare voi prezenta pe scurt un exemplu generic de astfel de câmp și tipurile de fault-uri care se pot crea pentru a testa negativ acest câmp.

Exemplu de câmp care va fi testat:

Field name: FieldExample1

Field type: alphanumeric

Field format: variabil, având formatul: LLVAR

Field maximum length: 24

Field valid values: orice valoare numerică și alfabetică

Explicarea formatului LLVAR:

LL = lungimea câmpului reprezentată pe 2 digiți

VAR = valoarea efectivă a câmpului

Exemplu: 0512345

LL = 05

VAR = 12345

Pentru testarea negativă a acestui câmp se pot crea o serie de valori negative (fault-uri) ale acestuia.

Avem două categorii principale de fault-uri și anume:

fault de format invalid

fault de valori invalide

Pentru fault-urile de format invalid se pot crea următoarele tipuri de fault-uri:

de tip invalid

de format LL invalid

de lungime a câmpului invalidă

Testarea negativă a unui câmp într-un mesaj de tip Request

În exemplul următor va fi testat câmpul denumit Primary account number (PAN) [17] și

care are următoarele atribute:

Fieeld name: PAN

Field type: numeric

Field format: variabil, având formatul: LLVAR

Field maximum length: 19

Field valid values: orice valoare numerică

Se va folosi un fault de format invalid, după cum urmează:

Injectarea a 3 litere (x, y si z) în locul a 3 cifre

166458xyz235999999

Primele 2 cifre: 16, reprezintă lungimea valorii câmpului

Următoarele 16 cifre reprezintă valoarea câmpului: 6458xyz235999999

Foarte important este formatul câmpului care va fi transmis de Fault Injector tool către BASE24-eps.

Cele 3 tipuri de formate care sunt recunoscute de sistemul BASE24-eps sunt:

HEX

HEX ASCII

HEX EBCDIC

Fiecare câmp are definit unul din cele trei formate enumerate mai sus.

În cazul nostru este vorba de HEX EBCDIC.

Pentru o întelegere mai bună a formatului care este așteptat de către sistemul BASE24-eps, în figura de mai jos este prezentată valoarea in HEX convertită de către simulator:

Figura 3.7.3: Valoarea ASCII si HEX a unui câmp

În tab-ul Fault Injector Fault Data prezentat anterior, vor fi setate următoarele:

Fault ID: BNET_DE02_1

Field Name: PAN

Fault Type: HEX

Field Value: F1F6F6F5F8A7A8A9F2F3F5F9F9F9F9F9F9

În tab-ul Fault Injector Acquirer Test Cases va fi referențiat Fault ID-ul setat in tab-ul anterior, după cum este ilustrat în figura de mai jos:

Figura 3.7.4: Setarea Fault ID-ului în tab-ul Fault Injector Acquirer Test Cases

Având toate aceste elemente setate, se poate executa testul negativ. Din Fault Injector tool se alege dintr-un meniu testul care a fost pregătit și se lansează în execuție.

În imaginea de mai jos este prezentat rezultatul executării testului. Se poate observa meniul cu testele/scenariile care pot fi alese pentru a fi rulate, precum si informațiile afișate de către Fault Injector tool pe parcursul execuției testului:

Figura 3.7.5: Rezultatul executiei testului negativ pentru exemplul prezentat

În consola de monitorizare a sistemului BASE24-eps se poate observa mesajul de eroare generat de execuția testului:

Figura 3.7.6: Mesajul de eroare din consola de monitorizare

Mesajul care conține fault-ul injectat este trimis de către Fault Injector tool la sistemul BASE24-eps, unde are loc parsarea mesajului. Datorită fault-ului injectat parsarea eșuează, mesajul nu este trimis mai departe către Issuer, iar sistemul nu trimite nici un răspuns către Acquirer.

Testarea negativă a unui câmp într-un mesaj de tip Response

În exemplul următor va fi testat câmpul denumit Network management information [17] și care are următoarele atribute:

Fieeld name: Network management information

Field type: alfanumeric si caractere speciale

Field format: variabil, având formatul: LLLVAR

Field maximum length: 50

Se va folosi un fault de format invalid, după cum urmează:

Injectarea unui spatiu in lungimea câmpului (LLL, care este numeric, reprezentat pe 3 digiți)

~100123456789

Primele 3 caractere/poziții: ~10, reprezintă lungimea valorii câmpului (prin ~ s-a reprezentat un spațiu).

Următoarele zece cifre reprezintă valoarea câmpului: 0123456789

Formatul câmpului, la fel ca la exemplul precedent, este de tip HEX EBCDIC.

În tab-ul Fault Injector Fault Data prezentat anterior, vor fi setate următoarele:

Fault ID: COOP_DE125_5

Field Name: NetworkManagementInformation

Fault Type: HEX

Field Value: 40F1F0F0F1F2F3F4F5F6F7F8F9

Având aceste elemente setate, se poate trece la executarea testului negativ.

Din simulatorul Acquirer-ului (ISO93 în cazul nostru) se alege dintr-un meniu testul care a fost pregătit și se lansează în execuție

În imaginea de mai jos este prezentat rezultatul executării testului in simulatorul Acquirer-ului. Se poate observa mesajele afișate de către Acquirer simulator pe parcursul execuției testului:

Figura 3.7.7: Rezultatul execuției testului negativ(mesaj de tip Response) pentru exemplul prezentat

Fault Injector tool-ul controlează Issuer-ul, pentru acest tip de teste.

În imaginea următoare se poate observa informațiile afișate de către Fault Injector tool pe parcursul execuției testului:

Figura 3.7.8: Informațiile afișate de Fault Injector tool în cazul testului prezentat

Concluzii și perspective

Ideea acestei lucrări a pornit de la nevoia de îmbunătățire a performanțelor procesului de testare în cadrul companiei Worldwide și mai specific pe sistemul BASE24-eps. Analizând datele și metricile din proiectele anterioare am ajuns la concluzia că testarea negativă este un aspect căruia i s-a acordat puțină atenție în trecut și care reprezintă un aspect demn de luat în considerare, în special pentru a identifica și rezolva cazurile extreme în care memoria sistemului intră într-un subprogram de golire – core dump.

Pornind de la conceptul de testare pozitivă deja aplicată pe majoritatea proiectelor, am identificat modalitățile prin care testarea negativă ar putea fi aplicată pe tranzacțiile financiare care vizează testarea unei anumite interfețe a sistemului – modalitățile se referă la testare negativă pe mesajul de tip request și testarea negativă pe mesajul de tip response.

Cu ajutorul echipei de dezvoltare a simulatoarelor, am identificat nevoia unei aplicații Windows care să se interfațeze cu simulatoarele deja existente și cu sistemul de test. Aceasta aplicație, numită Fault Injector, a fost pusă la dispoziția noastră și asupra acesteia am executat numeroase încercări până la a ajunge la varianta finală, pentru a o putea folosi pe proiecte.

Având la dispoziție testele pozitive și Fault Injector-ul am putut trece la faza de execuție a testelor negative într-un proiect pilot. În urma testelor negative am identificat mai multe metrici, care pot fi utilizate de colegii noștrii pe toate celelalte proiecte cu scopul de a crește calitatea funcționalității livrate și nivelul de încredere în stabilitatea sistemului.

Prima metrică identificată se referă la dispoziția formatelor câmpurilor trimise către sistemul BASE24-eps pentru o interfață oarecare. Această informație va fi utilizată pentru planificarea proiectelor viitoare care vor include o parte de testare negativă, dar și perspective de îmbunătățire a Fault Injector-ului pentru a reduce timpul petrecut pentru crearea manuală a fault-urilor.

Figura 5.1: Dispoziția formatelor câmpurilor trimise către sistemul BASE24-eps

Cea de a doua metrică rezultată în urma etapei de execuție a testelor negative este dispoziția tipurilor câmpurilor trimise către sistemul BASE24-eps pentru o interfață oarecare.

Figura 5.2: Dispoziția tipurilor câmpurilor trimise către sistemul BASE24-eps

Această metrică are un rol important în crearea unei documentații consistente de concepere a fault-urilor plecând de la tipurile existente de câmpuri și de prioritizare a testării câmpurilor în funcție de apariția tipului în cadrul mesajului. De asemenea, clarificarea tipurilor posibile de câmpuri a generat perspective de îmbunătățire a Fault Injector-ului în direcția de automatizare a creării fault-urilor.

Ca și perspective de îmbunătățire a Fault Injector-ului, perspective rezultate în urma proiectului pilot, am identificat:

extinderea suportului către formatul EBCDIC și posibilitatea introducerii în componenta de date, categoria Fault Data, a câmpului de injectat în clar, care să fie ulterior convertit de Fault Injector în formatul HEX EBCDIC, format acceptat de către sistemul BASE24-eps

generarea automată a fault-urilor pentru tipul lungime fixa, care să fie direct utilizate și injectate în mesaje.

Ce este însă cu adevărat important este faptul că fiecare dintre noi poate optimiza nu doar munca sa, dar poate contribui activ la toate ședintele de brainstorming care aduc îmbunătățiri activitații întregii organizații. Instruirea testorilor pe direcția testării negative, introducerea și optimizarea tool-ului de injectare a valorilor sunt doar câteva dintre direcțiile asupra căruia mă voi concentra pe viitor.

Bibliografie

[1]: Software testing. http://www.softwaretesting.ro/Romana/Files/TestMethods/Software%20Testing%20Methods.html

[2]: http://en.wikipedia.org/wiki/Software_testing

[3]: Negative Testing:

http://support.smartbear.com/articles/testcomplete/negative-testing-with-testcomplete/

[4]: Standardul ISO 9001: 2008

[5]: Suport curs ISTQB, “Certified Tester Foundation Level Syllabus”, 2011

[6]: Dorothy Graham, “Foundation of Software Testing”, 2012

[7]: James Lyndsay, “A Positive View of Negative Testing”, 2003

[8]: BCS SIGIST: Standard Glossary of Testing Terms (British Standard BS 7925-1)

[9]: Boris Beizer, Software Testing Techniques, van Nostrand Reinhold, 1990

[10]: Compendium-TA: http://www.compendiumdev.co.uk/page.php?title=compendiumta

[11]: Suzanne Robertson, James Robertson, Mastering the Requirements Process, Addison-Wesley, 2012

[12]: J.A. Whittaker, How to Break software, Addison-Wesley, 2006

[13]: BASE24-eps Overview, 2014

[14]: ACI Worldwide: Documente interne

[15]: ASSET modules:

http://www.aciworldwide.com/products-and-services/payments-infrastructure/payment-testing/asset/modules.aspx

[16]: A Guide to the ACI Worldwide BASE24-eps on z/OS:

http://www.redbooks.ibm.com/redbooks/SG247684/

[17]: ISO 8583:

http://en.wikipedia.org/wiki/ISO_8583

[18]: Tabelul cu valorile zecimal ASCII, hex ASCII si hex EBCDIC

http://shop.alterlinks.com/ascii-table/ascii-ebcdic-us.php

[19]: http://en.wikipedia.org/wiki/

[20] : http://www.visaeurope.com/

[21]: BASE24 to BASE24-eps Terminology, 2012

Anexa A

Valorile zecimal ASCII, hex ASCII si hex EBCDIC corepunzătoare diferitelor caractere sunt prezentate în tabelul de mai jos [18]:

Bibliografie

[1]: Software testing. http://www.softwaretesting.ro/Romana/Files/TestMethods/Software%20Testing%20Methods.html

[2]: http://en.wikipedia.org/wiki/Software_testing

[3]: Negative Testing:

http://support.smartbear.com/articles/testcomplete/negative-testing-with-testcomplete/

[4]: Standardul ISO 9001: 2008

[5]: Suport curs ISTQB, “Certified Tester Foundation Level Syllabus”, 2011

[6]: Dorothy Graham, “Foundation of Software Testing”, 2012

[7]: James Lyndsay, “A Positive View of Negative Testing”, 2003

[8]: BCS SIGIST: Standard Glossary of Testing Terms (British Standard BS 7925-1)

[9]: Boris Beizer, Software Testing Techniques, van Nostrand Reinhold, 1990

[10]: Compendium-TA: http://www.compendiumdev.co.uk/page.php?title=compendiumta

[11]: Suzanne Robertson, James Robertson, Mastering the Requirements Process, Addison-Wesley, 2012

[12]: J.A. Whittaker, How to Break software, Addison-Wesley, 2006

[13]: BASE24-eps Overview, 2014

[14]: ACI Worldwide: Documente interne

[15]: ASSET modules:

http://www.aciworldwide.com/products-and-services/payments-infrastructure/payment-testing/asset/modules.aspx

[16]: A Guide to the ACI Worldwide BASE24-eps on z/OS:

http://www.redbooks.ibm.com/redbooks/SG247684/

[17]: ISO 8583:

http://en.wikipedia.org/wiki/ISO_8583

[18]: Tabelul cu valorile zecimal ASCII, hex ASCII si hex EBCDIC

http://shop.alterlinks.com/ascii-table/ascii-ebcdic-us.php

[19]: http://en.wikipedia.org/wiki/

[20] : http://www.visaeurope.com/

[21]: BASE24 to BASE24-eps Terminology, 2012

=== anexa ===

Anexa A

Valorile zecimal ASCII, hex ASCII si hex EBCDIC corepunzătoare diferitelor caractere sunt prezentate în tabelul de mai jos [18]: