Rezumat: Cursul este a doua dintre cele trei niveluri luând în considerare procesul de verificare. Tema acestui curs - procesul de testare de integrare, scopurile și obiectivele sale. Considerăm că aspectele organizatorice ale testarea integrării - metodele structurale și temporare de testare de integrare de clasificare, de planificare testarea integrării. Scopul acestui curs este de a oferi o idee despre procesul de testare de integrare, componentele sale tehnice și organizatorice
20.1. Scopurile și obiectivele de testarea integrării
Rezultatul testării și de verificare a modulelor individuale care alcătuiesc sistemul software trebuie să se concluzioneze că aceste module sunt consecvente la nivel intern și să îndeplinească cerințele. Cu toate acestea, modulele individuale sunt rareori opereze pe cont propriu, astfel încât următoarea sarcină după testarea modulelor individuale - testarea corectitudinea interacțiunii mai multor module combinate într-o singură unitate. Un astfel de test se numește integrare. Scopul lui - să asigure corectitudinea funcționării în comun a componentelor sistemului.
Testarea de integrare este, de asemenea, numit arhitectura sistemului de testare. Pe de o parte, acest nume datorită faptului că testele de integrare includ verificarea toate tipurile posibile de interacțiune între module software și elemente care sunt definite în arhitectura sistemului - astfel încât testele de integrare a verifica integralitatea interacțiunilor în implementarea sistemului de testare. Pe de altă parte, rezultatele testelor de integrare - una dintre principalele surse de informații pentru îmbunătățirea proceselor și rafinări ale arhitecturii sistemului, interfețe inter-module și interconecteaza. Ie Din acest punct de vedere, teste de integrare a verifica corectitudinea interacțiunii dintre componentele sistemului.
Un exemplu de interacțiune de validare poate servi două module, unul dintre care stochează mesaje pe protocolul adoptat de fișiere, și afișează a doua de Protocolul de pe ecran. Cerințele funcționale pentru sistemul spune ca mesajele să fie afișate în ordine cronologică inversă. Cu toate acestea, unitatea de stocare a mesajelor le stochează într-o manieră directă, și modulul de ieșire utilizează o stivă pentru a fi afișate în ordine inversă. Testele unitare afectează fiecare modul individual, nu dau nici un efect aici - este situație destul de reală inversă, în care mesajele sunt stocate în ordine inversă, și afișează folosind coada. Detecta o potențială problemă poate fi verificată numai cu ajutorul unor teste de integrare module de interacțiune. Punctul-cheie aici este că, în ordine cronologică inversă afișează sistemul de mesaje ca un întreg, și anume, verificarea modul de ieșire și a constatat că acesta afișează mesaje în ordine directă, nu putem garanta că am descoperit defectul.
Ca urmare a testelor de integrare și de a elimina toate defectele identificate se dovedește arhitectură coerentă și integrată a unui sistem software, și anume putem presupune că testarea de integrare - este o arhitectură de testare și nivel scăzut de cerințe funcționale.
Testarea de integrare. în general, este un proces iterativ prin care o funcție de verificare în ce mai crescut în dimensiune modulelor agregate.
20.2. Organizarea testelor de integrare
20.2.1. Clasificarea structurală a metodelor de testare de integrare
De obicei, testarea de integrare a avut loc la sfârșitul unui test de unitate pentru toate modulele integrate. Cu toate acestea, acest lucru nu este întotdeauna cazul. Există mai multe metode de testare de integrare:
- Testarea Strămoși;
- Testarea monolitic;
- Descendentă de testare.
Toate aceste tehnici sunt bazate pe cunoașterea arhitecturii sistemului, care este adesea descris ca diagrame de flux sau diagrame funcție de apeluri [10]. Fiecare nod din această diagramă este un modul software, și săgețile între ele reprezintă dependența de apeluri între module. Diferența principală a metodelor de testare de integrare este pe direcția de mișcare a acestor diagrame și în lățimea unei singure iterație.
Teste Strămoși. Când se folosește această metodă presupune că testul mai întâi toate modulele software care alcătuiesc sistemul, și numai atunci când sunt combinate pentru testarea integrării. Cu această abordare simplifică în mod semnificativ localizarea de eroare: în cazul în care modulele sunt testate în mod individual, eroarea în activitatea lor comună este problema interfeței. Cu această abordare, problemele de căutare în testerul este îngust, și, prin urmare, mult mai probabil pentru a identifica în mod corect defectul.
Fig. 20.1. Dezvoltarea de drivere și cioturi într-o testare de integrare în sus
Cu toate acestea, metoda de testare în creștere are un dezavantaj semnificativ - necesitatea de a dezvolta drivere și cioturi de unitate de testare înainte de testarea de integrare și de necesitatea de a dezvolta drivere și cioturi în timpul testării de integrare a modulelor sistemului (Figura 20.1)
Pe de o parte driverele și cioturi - un instrument de testare puternic, pe de altă parte - dezvoltarea lor necesită resurse semnificative, în special atunci când schimbarea compoziției de module integrate, cu alte cuvinte, poate fi nevoie de un set de drivere pentru unitatea de testare a fiecărui modul, un driver separat si plug pentru a testa integrarea a două module a unui set de separat - pentru a testa integrarea celor trei module, etc. Acest lucru se datorează în primul rând faptului că integrarea modulelor este nevoie de niște dopuri, și doriți să schimbați conducătorului auto, care susține noile teste care implică mai multe module.
Testarea prefabricat din beton sugerează că componentele individuale ale testului severă a sistemului nu a trecut. Principalul avantaj al acestei metode - nu este nevoie de a dezvolta un mediu de testare, drivere și cioturi. Ca urmare a dezvoltării tuturor modulelor se execută integrarea lor, atunci întregul sistem este testat în ansamblu. Această abordare nu ar trebui să fie confundat cu testarea sistemului, care este acoperit în următorul curs. În ciuda faptului că testul monolitic Verificați funcționarea întregului sistem, obiectivul principal al acestui test - pentru a identifica problemele interacțiunii dintre modulele individuale ale sistemului. Obiectul testului de sistem este de a evalua caracteristicile calitative și cantitative ale sistemului în ceea ce privește acceptabilitatea utilizatorului final.
test de solid are o serie de deficiențe grave.
- Este foarte dificil să se identifice sursa de eroare (greșit codul de identificare fragment). În cele mai multe module trebuie să-și asume existența unor erori. Problema se reduce la definiția de ce fel de eroare în toate modulele implicate a dus la rezultatul. Este posibil să se suprapună efecte de eroare. În plus, o eroare într-un singur modul poate bloca un alt test.
- Este dificil să se organizeze corectarea erorilor. Testerul de testare a găsit problema este fix. Un defect în sistemul care a cauzat problema, dezvoltatorul va repara. Deoarece, de regulă, modulele de testare scrise de persoane diferite, există o problemă - una dintre ele este responsabil pentru căutarea înlăturarea defectului? Cu o astfel de rată de „iresponsabilitate colectivă“ de eliminare a defectelor poate prăbușească.
- Procesul de testare este automatizat rău. Avantajul (software suplimentar care însoțește procesul de testare) se transformă într-un dezavantaj. Modificările impun ca fiecare repetare a tuturor testelor.
Testarea Downward sugerează că procesul de testare de integrare se mută pentru a urmări dezvoltarea. Primul test de numai sistemul de control cel mai de sus nivel, module nici un nivel inferior. Apoi, treptat, un modul de nivel superior integrat într-un nivel scăzut. Ca rezultat al acestei metode elimină necesitatea pentru șofer (conducătorul auto îndeplinește rolul unui modul de sistem la nivel înalt), dar există încă nevoie de dopuri (Figura 20.2).
mareste imaginea
Fig. 20.2. Integrarea treptată a modulelor într-un metode de testare în jos
Literatura de specialitate menționează adesea metoda de testare de integrare a sistemului software orientat pe obiecte, care se bazează pe clase selectate de clustere care au o funcționalitate închisă împreună și complet [10]. În esența sa, această abordare nu este un nou tip de testare de integrare, schimbând doar elementul minim, care rezultă din integrarea. Atunci când modulele de integrare pe limbaje de programare procedurale pot fi integrate în orice număr de module care fac obiectul dezvoltării dopurilor. În cazul în clase în clustere integrate există o limită destul de moale privind caracterul complet al funcționalității cluster. Cu toate acestea, chiar și în cazul sistemelor orientate-obiect poate integra orice număr de clase folosind stub de clasă.
Indiferent de metoda folosită, testarea de integrare, este necesar să se ia în considerare gradul de acoperire a funcționalității sistemului de testare de integrare. În [17] a propus o metodă pentru evaluarea gradului de acoperire bazat pe controlul apelurilor între funcții și fluxuri de date. În acest cod de evaluare pentru toate modulele din diagrama bloc a sistemului ar trebui să fie efectuate (care urmează să fie acoperite de către toate nodurile), toate apelurile trebuie să fie efectuate cel puțin o dată (trebuie să fie acoperite de toate comunicările între pe nodurile diagramă structurală), toate secvența de apel ar trebui să fie efectuate cel puțin o singură dată (tot drumul la diagrama structurală trebuie acoperită). [10]