Implementarea Unor Politici Qa In „unit Tests”

Implementarea unor politici QA în „Unit Tests”

CUPRINS

1. Introducere

1.1. Scopul aplicației

1.2. Scurtă trecere în revistă a capitolelor

2. Management al ciclului de viata al Bazelor de date

2.1. Cum ALM ȘI DLM conlucreaza?

2.1.1. Îmbunătățirea ALM și continuă

2.1.2. Provocarea de a gestiona baza de date

2.2. Definirea Managementului ciclului de viata al bazei de date (DLM)

2.2.1. Importanța unei strategii de gestionare a datelor

2.3. DLM cu ALM

2.3.1. Unificarea echipelor cu ALM si DLM

2.3.2. ALM, DLM, și livrare continuă

2.3.3. Livrare continuă cu DLM

2.3.4. Ce inseamna DLM și livrare continuă

2.4. Managementul ciclului de viata al aplicatiei cu Visual Studio Team Foundation Server (Visual Studio Online)

2.4.1. Istoric legat de Team System

2.4.2. TFS 2013 și Visual Studio Online

2.5. Visual Studio Online

2.5.1. Statistici ale aplicatiei, Build-Measure-Learn

2.5.2. Caracteristici Visual Studio Online

a. Setare initiala

b. Controlul sursei

c. Lucru

d. Construiți / Release

2.6 Soluții și Proiecte

2.6.1 Soluții

2.6.2 Proiecte

2.6.3. Item-uri

2.6.4. Crearea Proiectelor din Șabloane

2.7. Proiecte SQL Server

2.7. 1. Elementele ce pot fi adăugate Proiectului

2.7.2 Dezvoltarea bazei de date SQL Server în Visual Studio

2.8. Verificarea codului bazei de date prin utilizarea SQL Server “Unit Test”

2.8.1. Instrument DLM (SQL Server Data Tools)

2.8.2. Noțiuni de bază cu Unit Testing în bazele de date SQL Server în SSDT

2.8.3. Proiecte de testare și conversia proiectelor existente

2.8.4. Generarea Testelor Unitare SQL Server din obiecte în SQL Server Object Explorer

2.8.5. Crearea manuală de Teste Unitare SQL Server

2.8.6. Configurarea unui Proiect de test

2.8.7. Definirea scripturilor de test T-SQL

2.8.8. Definirea Conditilor de Test

2.8.9. Conditile de testare

2.8.10. Rularea Testului

2.9. Strategii pentru izolarea bazei de date în testare

2.9.1 Bază de date de test pentru fiecare dezvoltator

2.9.2. Tranzactile de tip “Roll back”

2.9.3. Resetarea bazei de date înainte de fiecare încercare

2.9.3.a. Baze de date în memorie

2.9.4. Ce este testarea unitară în bazele de date?

2.9.5. De ce să realizăm Teste unitare asupra bazelor de date?

2.9.6. Tipuri de teste unitare de baza de date

2.9.7. Gestionarea stării bazei de date

2.9.8. Generarea de date

3. Prezentarea aplicativă

Concluzii

Direcții viitoare

Bibliografie

Introducere

Prezenta lucrare are ca scop înfățișarea unor concepte de Quality Assurance în implementarea bazelor de date, acestea fiind necesare atât în momentul dezvoltării cât și în lansarea în producție.

Dezvoltarea industriei IT din ultimii ani a condus către o automatizare a majorității proceselor, vorbind astfel despre o eliminare treptată a forței de muncă manuală.

Construirea unui produs software nu este niciodată doar despre cod. Cum descrie și Grant, este, de asemenea, despre gestionarea a multiple echipe, termene și, adesea, evoluția continuă a cerințelor clienților.

Inițial, Managementul ciclului de viață al aplicației (ALM prescurtat) a fost numit Librarie de Management. Era orientat către dezvoltator, limitat în funcționalitate (numai codul sursă software a fost versionat) și static (colectarea versiunilor diferite ale codului sursă).

Ulterior, managementul a vrut să acopere procesul de dezvoltare complet. Acest interes în schimbarea procesului software a făcut management o disciplină mai dinamică.

Managementul ciclului de viață al aplicației modern vrea nu numai să abordeze procesul de dezvoltare și a activităților conexe în avans, dar, de asemenea, mediul de producție (de implementare), precum și activitățile ulterioare, cum ar fi cerințele de management și urmărirea defectelor.

În cele din urmă ALM are un impact enorm asupra eficienței și costurilor asupra procesului de dezvoltare a aplicațiilor.

Prima generație de instrumente ALM s-a limitat la colectarea unui set de instrumente folosite în cadrul unei organizați. Cu toate acestea, în mediul exigent de astăzi, aceste soluții ALM 1.0 prezintă o mulțime de deficiențe, cum ar fi: lipsă de integrare între diferitele instrumente, neconcordanțele din cauza diferitelor caracteristici ALM, lipsă de comunicare între părți componente implicate în proces, lipsă de transparență, o mulțime de interventi manuale necesare pentru a păstra totul în sincronizare, costisitor de întreținut.

Noua generație de instrumente ALM, așa-numitele soluții ALM 2.0, rezolvă o mulțime din aceste deficiențe. Instrumentele nu doar sunt colectate, dar sunt complet integrate pentru a sprijini întregul proces de dezvoltare. Instrumentele de integrate comunică și împart caracteristici, servicii comune de asigurare a transparenței (flux de lucru, de securitate și de analiză) și toate procesele sunt automatizate. Soluții ALM 2.0 sunt metodologi independente, instrumente independente și depozite neutre (care să permită dezvoltarea între diferite platforme).

Dacă o aplicație are o bază de date în back-end cu date critice de afaceri care urmează să fie menținute în condiții de siguranță și în mod corect, acest lucru aduce bazelor de date provocări suplimentare, și pentru echipe pentru a rezolva. Complexitatea gestionării bazelor de date care stă la baza Managementului ciclului de viață al bazelor de date (DLM), o abordare care are o viziune largă a unghilui peste ciclului de viață software, încurajând echipele pentru a utiliza o gamă largă de procese și infrastructurii tehnologice pentru a gestiona schimbările de baze de date. Aceste procese coexistă și ar trebui să fie gestionate în procesele și politicile utilizate în Managementul ciclului de viață al aplicației (ALM). [www.alm]

Scopul aplicației

Această lucrare explorează ce înseamnă DLM în ALM, întrebări importante ce trebuie luate în considerare pentru o strategie puternică de gestionare a datelor, precum și modul în care Microsoft Visual Studio și instrumentele Microsoft oferă suport pentru livrarea continuă de baze de date în DLM.

Aplicația realizată („Unit Tests”) are ca scop prezentarea modului de implementare a unei testări eficientă și ușoară, la nivel de teste de caracteristici („Feature Tests”), aplicată pe produsele celor de la Microsoft, ce integrează aceste posibilități.

În urma etapei de implementare este absoult necesară și o etapă de testare a aplicațiilor realizate. Prin uneltele existente la momentul actual, acesta opțiune este accesibil tuturor, dar acest lucru trebuie organizat în cadrul unui ALM pentru a implementa o politică de dezvoltare și de QA pentru a elimina problemelor apărute cât mai eficient.

Scurtă trecere în revistă a capitolelor

În primul capitol se va face o scurtă trece prin tehnologiile actuale care oferă această funcționalitate cât și o descriere a bazelor de date și a conceptului. Astfel vom discuta despre ce înseamnă managementul ciclului de viață al aplicațiilor dar și al bazelor de date. Ca și tehnologii ale celor de la Microsoft vor fi descrise moduri de lucru în uneltele dezvoltate și utilizarea corectă în etapa de testare.

Conceptul de testare unitară și strategiile de testare vor fi prezentate în Capitolul 2 unde vom întâlni și probleme ce necesită o abordare specială. De asemenea sunt ilustrate tipurile de teste ce pot fi aplicate dar și posibilitatiile de gestionare a bazelor de date și datelor acestora.

În Capitolul 3 este descrisă aplicația în sine și sunt prezentate exemple de rulări ale testelor realizate, ale erorilor apărute, dar și al rezultatelor întoarse. Aici se poate înțelege utilitatea acestora în procesul de dezvoltare și tot în acest capitol se poate observa ușurința și în același timp complexitatea acestui proces. Pentru a crea un test corect este necesar ca acțiunile să acopere toate posibilitatiile și de asemenea, în cazul bazelor de date, acestea pot fi efectuate asupra proiectului de dezvoltare atâta timp cât se realizează și procesul invers.

În final, și anume Capitolul 4 vor fi prezentate concluziile, dar și direcții viitoare ale politicilor de “Quality Assurance” în testarea bazelor de date, astfel putem să evoluăm și să înțelegem ca nu doar cantitatea contează, ci și calitatea.

Capitolul 5 conține bibliografia proiectului realizat, această fiind reprezentată de materialele din care au fost extrase date și referințe către sursele citate.

Management al ciclului de viața al Bazelor de date

Managementul ciclului de viața al aplicației (ALM) a fost mult timp folosit de către organizați pentru a gestiona cu atenție ciclul de viață al aplicațiilor software din punctul de început până la livrare, monitorizare și întreținere. Acest lucru înseamnă că raza de acțiune a ALM extinde mult mai departe decât ciclului de dezvoltare software, acoperind trei etape majore: guvernare, dezvoltare și operațiuni.

De la bun început al ciclului de viață, ALM acoperă procesul de generare, rafinare, și de gestionare a ideilor proiectului și cerințe pentru aplicația software, de asemenea, cunoscut sub numele de guvernare. Etapa de guvernare continuă în linii mari până la sfârșitul ciclului de viață pentru a se asigura că cerințele sunt îndeplinite, iar cererea este apoi menținută corect, revizuită și actualizată în funcție de necesități. Faza de dezvoltare a ciclului de viață, crearea aplicației software, vine la scurt timp după etapa de rafinare și cerințelor de aprobare. În cazul în care aplicația software sau modificările sale sunt aproape de a fi gata de lansare, stadiul operațiunilor începe, cu scopul său principal de a gestiona și monitoriza implementarea la client în siguranță.

Implementat bine, ALM sprijină echipele pentru a depăși provocările multiple, și a proceselor disparate, metrici, și infrastructuri. Trei etape iterative facilitează un mod agil, ciclu de viață repetabil, care este compatibil cu o abordare de îmbunătățire continuă față de evoluția calității, eficienței și comunicări.

Cum ALM și DLM conlucrează?

Managementul ciclului de viață al bazelor de date este parte a managementului ciclului de viață al aplicației, în special, partea care este în cauză cu baza de date.

Managementului ciclului de viață al aplicației în sine este format din trei părți: guvernare, dezvoltare și operațiuni.

Îmbunătățirea ALM și continuă

Cele trei etape ale ALM sunt concepute pentru a gestiona fluxul de oameni, procese și activități într-o abordare incrementală pentru a livra software.

Cererea de feedback în ciclul de viață al cererii și de măsurare a calității și eficienței înseamnă procese și tehnologii, care pot automatiza activitățile repetitive și oferă trasabilitatea crescută ce sunt importante pentru o practică de îmbunătățire continuă.

Provocarea de a gestiona baza de date

Baze de date prezintă o provocare deosebită pentru integrarea cu strategiile managementului ciclului de viață al aplicației și totul se reduce la protecția datelor. Spre deosebire de aplicați, bazele de date conțin stări. Acest lucru trebuie să fie gestionat și păstrat corect, ca parte nouă sau actualizarea software-ului existent. După cum explică Grant, nu se poate arunca sau suprascrie baza de date de ieri, atunci când implementați modificările bazei de date. Pentru a face acest lucru se riscă pierderea datelor, și menținerea datelor de-a lungul ciclului de viață este esențială pentru funcționarea și, de obicei, respectarea legală a oricărei organizații.

Este complexitatea pe care bazele de date și datele lor le aduc ciclului de viață aplicație și au evoluat în managementul ciclului de viață al bazelor de date (DLM). DLM aduce procese suplimentare, punctele de control, și controale la ALM pentru a oferi o abordare mai riguroasă pentru gestionarea schemei, datelor și metadatelor pentru baza de date.

Definirea Managementului ciclului de viata al bazei de date (DLM)

  Datorită cerințelor de a gestiona în condiții de siguranță schema, datele și metadatele, DLM introduce procese suplimentare de dezvoltare și de operare etapele ciclului de viață al aplicației:

• Managementul datelor și a proceselor disparate, metrici, și infrastructuri. Trei etape iterative facilitează un mod agil, ciclu de viață repetabil, care este compatibil cu o abordare de îmbunătățire continuă față de evoluția calității, eficienței și comunicări.

Cum ALM și DLM conlucrează?

Managementul ciclului de viață al bazelor de date este parte a managementului ciclului de viață al aplicației, în special, partea care este în cauză cu baza de date.

Managementului ciclului de viață al aplicației în sine este format din trei părți: guvernare, dezvoltare și operațiuni.

Îmbunătățirea ALM și continuă

Cele trei etape ale ALM sunt concepute pentru a gestiona fluxul de oameni, procese și activități într-o abordare incrementală pentru a livra software.

Cererea de feedback în ciclul de viață al cererii și de măsurare a calității și eficienței înseamnă procese și tehnologii, care pot automatiza activitățile repetitive și oferă trasabilitatea crescută ce sunt importante pentru o practică de îmbunătățire continuă.

Provocarea de a gestiona baza de date

Baze de date prezintă o provocare deosebită pentru integrarea cu strategiile managementului ciclului de viață al aplicației și totul se reduce la protecția datelor. Spre deosebire de aplicați, bazele de date conțin stări. Acest lucru trebuie să fie gestionat și păstrat corect, ca parte nouă sau actualizarea software-ului existent. După cum explică Grant, nu se poate arunca sau suprascrie baza de date de ieri, atunci când implementați modificările bazei de date. Pentru a face acest lucru se riscă pierderea datelor, și menținerea datelor de-a lungul ciclului de viață este esențială pentru funcționarea și, de obicei, respectarea legală a oricărei organizații.

Este complexitatea pe care bazele de date și datele lor le aduc ciclului de viață aplicație și au evoluat în managementul ciclului de viață al bazelor de date (DLM). DLM aduce procese suplimentare, punctele de control, și controale la ALM pentru a oferi o abordare mai riguroasă pentru gestionarea schemei, datelor și metadatelor pentru baza de date.

Definirea Managementului ciclului de viata al bazei de date (DLM)

  Datorită cerințelor de a gestiona în condiții de siguranță schema, datele și metadatele, DLM introduce procese suplimentare de dezvoltare și de operare etapele ciclului de viață al aplicației:

• Managementul datelor și a datelor de migrație

• Monitorizarea datelor

• Recuperare de date

Aceste procese suplimentare dau o mai mare vizibilitate, predictibilitate și eficiență managementului schimbării bazei de date. De asemenea, ele stau în centrul unei strategii puternice de gestionare a datelor.

Importanța unei strategii de gestionare a datelor

O strategie prost implementat de gestionare a datelor amenință nu numai protecția datelor critice pentru afacere, dar, de asemenea, comportamentul cererii dumneavoastră. Echipele de dezvoltare a unei aplicați cu o bază de date în back-end, dar fără o strategie de gestionare a datelor, poate suferi de:

• Pierderea unora sau tuturor datelor într-o bază de date

• Incapacitatea de a derula înapoi la versiunea anterioară a unei baze de date

• Riscante modificări ale schemei de baze de date

• Testarea puțină sau deloc de baze de date înainte de implementare

• Defecte (sau lipsa) procedurile de backup

• Structuri de date foarte complexe sau depășite

Modificări la procesele ambelor echipe și a tehnologiilor poate face o diferență la strategia de gestionare a datelor și modul în care să vă gestionați cu succes bazelor de date în contextul DLM. Pe măsură ce ia în considerare ceea ce ai nevoie pentru a evolua, ca parte a strategiei de gestionare a datelor, există trei întrebări principale pentru echipe să ia în considerare pentru manipularea modificărilor bazelor de date într-o strategie de release:

• Ce s-a schimbat în schema bazei de date, ce obiecte au fost schimbate, eliminate, adăugate?

• Cum se poate migra schema și datele modificate în condiții de siguranță?

»între medii multiple direct în mediul de producție?

DLM cu ALM

Cerințele unice de management a bazei de date nu înseamnă că proiectul de dezvoltare a bazei de date ar trebui să fie detașat de la eforturile de dezvoltare de aplicații.

De fapt, este cea mai bună practică de a coordona procesele de aplicare și dezvoltare a bazei de date în etape specifice ale ciclului de viață ori de câte ori este posibil. Echipele ce lucrează la aplicație și baza de date ar trebui să fie, de asemenea, conștiente și să sprijine practicile reciproc.

În plus, cerințele aplicației și bazei sale de date din back-end ar trebui luate în considerare în timpul etapei de guvernare. Există, de asemenea, puncte în etapele de dezvoltare și de operare în cazul în care eforturile de dezvoltare pot fi coordonate.

Unificarea echipelor cu ALM si DLM

Prin furnizarea unei serii comune de procese pentru echipele de dezvoltare pentru a gestiona ciclul de viață al aplicațiilor și al bazelor de date din back-end, ALM și DLM facilitează:

• O mai mare colaborare la aplicarea caracteristicilor și cerințele bazelor de date

• Un sistem cu valori comune

Aceste echipe de ajutor pentru a îmbunătăți treptată a calități pe parcursul ciclurilor de viață software și, la rândul său a organizaților ajută la reducerea riscului de la punctul de release.

Tratarea obiectele bazei de date sub formă de cod sursă face versiunarea alături de codul sursă al aplicației posibil. Versionand obiectele bazei de date, împreună cu codul aplicației oferă echipei o singură sursă de adevăr pe care se pot întemeia procesele de dezvoltare și implementare. Dezvoltarea bazei de date în caz contrar poate sta în urma proceselor de dezvoltare a aplicației. Dacă acest lucru se întâmplă, ea poate duce la un flux de lucru fragmentat, care la rândul lor, pot afecta capacitatea unei organizații pentru livrarea eficientă a software-ului.

ALM, DLM, și livrare continuă

Dacă, în cadrul etapei de dezvoltare, echipele versioneaza pentru un control al scripturilor și bazei de date pentru dezvoltarea împreună, aceastea deschid oportunități atât în alinierea cât și în automatizarea proceselor de dezvoltare și de operare.

Dacă, în cadrul ALM, organizația dumneavoastră practică livrarea continuă pentru a automatiza implementările aplicației, se pot aduce aceleași concepte de control al versiunii, integrarea continuă (CI), precum și management al release-ului al bazelor de date.

De managementul datelor suplimentare, migrația și monitorizarea proceselor sunt uneori necesare DLM pentru protejarea suplimentară a datele, dar și beneficiile mai mari de livrare continuă, de standardizare a proceselor de implementare prin automatizare. Suportul de livrare continuă asigură mai ușor, mai rapid eliberarea de schimbări înseamnand că echipele nu mai trebuie să se bazeze pe "big bang" de presă pentru a oferi valoare clientului.

Livrare continuă cu DLM

În schimb, organizațiile au procesele și mecanisme ce asigură un flux mai susținut de versiuni mai mici. Această abordare, ca parte a proceselor mai mari, structurate de DLM și ALM înseamnă că dezvoltarea, operațiunile, și echipa de afacere sunt capabile să lucreze mai eficient împreună pentru a construi și livra software.

Practicarea de livrare continuă ca parte a DLM necesită o combinație de procese de echipă și tehnologie. Mai presus de toate, este nevoie de o voință din toate părțile organizației să participe și să sprijine abordarea, această practică este mai mult despre evoluția abordărilor și filozofii decât schimbare imediată și instantanee. Ca urmare, este important pentru afacere, dezvoltare, și echipele de operațiuni să înțelega ce înseamnă acest mod de lucru pentru livrarea de software.

Ce înseamnă DLM și livrare continuă

Pentru organizație

O mai mare consistență – Dacă echipele de dezvoltare a aplicației și a bazei de date lucrează în paralel și coordonează modificări prin aceleași procese pentru release, aceasta crește probabilitatea ca echipele să facă release la versiuni mai stabile și consistente ale aplicațiilor. De-a lungul timpului, această creștere a predictibilității și orchestrarea procesului a sprijinit foarte mult guvernare în ciclul de viață al aplicație și bazei de date, reducerea pierderilor, a riscului, și probabilitatea de întârzierile la livrare software.

Agilitate și flexibilitate pentru a schimba – Mai bună coordonare a proceselor de dezvoltare a bazei de date înseamnă de asemenea, o livrare mai rapidă de software de către echipe. În urma acestui mod de lucru se încurajează un răspuns mai flexibil pentru schimbare și mai în măsură să susțină automatizarea proceselor de implementare prin integrarea continuă și livrare continuă.

Release frecvent, iterativ – Release mai frecvent, și mai rapide prin livrarea continuă înseamnă că organizațiile au posibilitatea de a da feedback la echipele de dezvoltare mai devreme și să lucreze împreună mult mai mult de-a lungul unui proiect, mai degrabă decât să aștepte mai mult pentru a vedea atât rezultatele cât și valoarea de la investiția în proiect.

Suport pentru o strategie de gestionare a datelor de primă clasă – Cu DLM, organizațiile pot beneficia de o strategie de gestionare a datelor de primă clasă, pentru a permite aplicației și bazei de date modificări ce merg corect și pot fi implementate mai eficient ca rezultat. Schimbările specifice clientului devin, de asemenea, mai ușor de gestionat ca baze de date și versiuni de aplicație pentru fiecare client.

Pentru echipele de dezvoltare

Bazele de date pot ține mai bine pasul cu dezvoltarea aplicației – Orchestrarea de baze de date și schimbări în dezvoltarea de aplicații în aceleași ciclu de viață ale proiectului aduce beneficii importante pentru echipele de dezvoltare. Baza de date nu mai este deconectat de la managementul proiectului, asigurându-se că baza de date și datele sale sunt dezvoltate de la început pentru cerințele ciclului de viață. Apoi este mult mai ușor pentru baza de date să țină pasul cu schimbarea din cadrul aplicației.

Feedback-ul incipient pentru o mai mare eficiență – Automatizarea proceselor de implementare a bazelor de date aduce beneficii suplimentare. Integrarea continuă și livrare continuă pentru bazele de date încurajeze o abordare iterativă a dezvoltării. Mai mici, schimbările mai frecvente ale bazei de date înseamnă că echipele de dezvoltare a bazei de date integreză munca lor mai devreme, pentru a se vedea rezultatele pentru testare și feedback, și astfel sunt capabili să acționeze proactiv cu privire la orice problemă mult mai ușor. Acest nivel de automatizare, combinată cu o abordare de tip „Agile” de dezvoltare, înseamnă echipe au, de asemenea, o mai mare capacitate de face release la schimbări ale bazei de date mai frecvent și mai rapid. Modificările ajung în mâinile utilizatorilor devreme, oferind o valoare mai mare afacerii, mai devreme în ciclul de viață al proiectului.

Pentru echipele de operațiuni

Teste riguroase înainte de pre-producție – O organizare a proceselor mai devreme în partea de dezvoltare a ciclului de viață este necesar în rândul administratorilor de baze de date din echipele de operațiuni. Teste mai riguroase și automate mai devreme în proces, datorită integrării continue și unui set de procese de testare înainte de a ajunge la release chiar înainte de pre-producție, înseamnă că orice problemă este detectată mult mai devreme decât s-ar putea fi altfel. Echipele pot folosi, de asemenea, instrumente și practici pentru a încorpora date de producție în ciclurile lor de testare, ceea ce face posibilă găsirea unor probleme de compatibilitate a datelor mai devreme în procesul de release.

Asigurarea Calității – Prea des inginerii software utilizează standarde de calitate ce sunt cu mult mai scăzute ca ale altor discipline inginerești. Cu toate acestea, software-ul de calitate superioară poate diferenția o companie de alta, în sectorul său.

O mai mare vizibilitate și control înainte ca release-ul să intre în producția – Diferite modalități de release pot fi proiectate pentru a include o poartă de aprobare înainte de ca un release să intre în producție. Acest lucru înseamnă că administratorii de baze de date să poată efectua mai multe controale de validare cu privire la script-uri de implementare pentru a determina dacă sunt gata pentru producție și dacă trebuie să se facă modificări ulterioare.

Trasabilitate crescută și monitorizare – Plasarea unei porți de aprobare, cu acces restricționat, înainte de punerea într-un mediu de producție direct, poate fi util dacă organizația necesită în procesele de implementare separarea DBA și sarcinilor de administrator IT, ca parte a unor politicii de "atribuții separate". De asemenea, etapa de aprobare sau revizuire dă trasabilitatea ulterioară a modificărilor pe teritoriul unei modalități. Dacă echipa ta este deja are un control al versiuni și testează schimbări ale bazei de date în etapa de dezvoltare, administratorii de baze de date pot folosi instrumente pentru a monitoriza și raporta cu privire la fiecare schimbare pe măsură ce trece de la dezvoltare în mediile de testare, QA, de pre-producție, și de producție.

Managementul ciclului de viață al aplicației cu Visual Studio Team Foundation Server (Visual Studio Online)

Soluția Microsoft pentru Managementul ciclului de viață al aplicației este Microsoft Visual Studio 2013 împreună cu Microsoft Visual Studio Online ce au fost lansat oficial pe 13 noiembrie 2013.

Istoric legat de Team System

Microsoft a lansat în noiembrie 2004 (9 ani în urmă) prima versiune a unei soluții integrate de management a ciclului de viață al unei aplicații(nume de cod Burton): Microsoft Visual Studio Team System 2005. Înainte, Visual Studio a fost doar un instrument dedicat pentru dezvoltatori / programatori. Acest s-a schimbat complet cu lansarea Team System, unde mai multe părți interesate au fost implicate în procesul de dezvoltare de software.

Microsoft a studiat modul în care echipele dezvoltă software și a decis să construiască un nou produs care ar crește substanțial probabilitatea de succes a proiectului, previzibilitate și de calitate software. Team System a transformat, de fapt, Visual Studio IDE într-un instrument de colaborare puternic pentru întreaga echipă de dezvoltare de software. Visual Studio 2005 Team System a fost conceput pentru a atinge patru obiective principale:

• Fiți productiv prin reducerea complexității, furnizarea de soluții orientate spre servicii moderne

• Fi integrat cu toate instrumentele, și facilitează o mai bună colaborare cu echipa

• Fiți extensibil prin permiterea proceselor să fi personalizate

Soluția completă a constat dintr-o serie de ediții diferite, specifice pentru părți diferite:

• Visual Studio 2005 Team Edition pentru Arhitecți software

• Visual Studio 2005 Team Edition pentru Dezvoltatorii de software

• Visual Studio 2005 Team Edition pentru Testeri

• Visual Studio 2005 Team Foundation Server

O concepție greșită a fost că TFS a înlocuit Visual SourceSafe doar ca un nou sistem de control al versiunii. Aceasta este, desigur incorect deoarece controlul de versiune este doar o mică parte din setul de caracteristici TFS. Team Foundation Version Control (TFVC) a fost scris de la zero (nici o legătură cu SourceSafe) și folosește o bază de date SQL Server ca un mijloc de scalare la medii și infrastructuri mari.

Team Foundation Server este componentă centrală și cheie în soluția ALM care a oferit o colaborare de echipă extensibilă. Team System a fost în mod clar conceput ca o platformă de ciclul de viață, care a permis părților terțe, clienții și furnizorii de soluții pentru a extinde funcționalitatea de bază cu noi caracteristici și personaliza instrumentul pentru aspectele unice ale anumitor întreprinderi. Soluție Framework Microsoft (MSF) este un set de procese de dezvoltare software, principii și practici dovedite, a fost fuzionat în produs prin intermediul a două modele de procese de tip „Team Projects”: MSF pentru Agile Software Development și MSF pentru procesul de îmbunătățire CMMI.

TFS 2013 și Visual Studio Online

Cea mai recentă versiune de Visual Studio Team Foundation Server (Visual Studio 2013) va permite echipelor de dezvoltare de a se ridica la cererea de un nou tip de aplicații, de a dezvolta și de a gestiona software, ce oferă o mai bună experiență. Valul de caracteristici suplimentare ALM vor ajuta să devină mai productivi și să faciliteze colaborarea dintre membrii echipei cu suport îmbunătățit pentru practici de dezvoltare Agile: Agile Portfolio Management, Camere pentru Echipe, Management de testare din browser, local suport pentru Git, Indicatori pentru codul sursă(CodeLens), Testarea Cloud Load prin Team Foundation service.

O tendință importantă care a continuat să se reflecte în release-ul 2013 este integrarea îmbunătățită față de alte produse Microsoft (de exemplu, System Center și Windows Azure). În acest sens, probabil, se vor vedea, de asemenea, unele modificări viitoare în integrarea cu InRelease, o soluție de management de eliberare din InCycle. Microsoft a ajuns la un acord pentru a achiziționa InRelease pe 3 iunie, 2013. soluție permis, echipele de dezvoltare software pentru a implementa în mod automat lansarea și urmărirea aplicaților (de la Team Foundation Server) ca un ansamblu de medii multiple, până la producție, bazat pe un flux de lucru de business.

Visual Studio Online

Dar, anunțuri importante au fost făcute la evenimentul oficial de lansare. Team Foundation Server a devenit Visual Studio Online în perspectiva lărgirii complete și pentru a indica faptul că Visual Studio Online va deveni componentă de servicii de instrumente de dezvoltare pentru viitor.

Visual Studio Online, fost Team Foundation Service, este originea datele de proiect în cloud. Acestea pot fi urcate și funcționale în câteva minute pe infrastructura cloud, fără a fi nevoie să se instalaze sau să se configureze un singur server. Configurarea unui mediu care include totul, de la operațiuni repo găzduite Git și instrumente de urmărire a proiectului, la integrare continuă și un IDE, toate ambalate într-un plan lunar per utilizator. Utilizatorul se poate conecta la proiect în cloud, folosind instrumentul de dezvoltare preferat, cum ar fi Visual Studio, Eclipse sau Xcode.

Statistici ale aplicației, Build-Measure-Learn

Această caracteristică Visual Studio Online oferă acum o imagine de 360 ​​de grade pentru a rula aplicații de colectare, prelucrare și afișare a o mare varietate de telemetri în trei domenii: performanță, utilizare și disponibilitate.

Fără nici un efort în timpul ciclului de dezvoltare (experiență integrare), echipele de dezvoltare vor beneficia de un set extins de diagnosticare colectate pentru a analiza ce se întâmplă în cererile lor de implementare. Cu aceste perspective valoroase, viitore îmbunătățiri pot fi mai concrete și de impact. Statistica aplicației va fi în măsură să ofere valorile necesare pentru a adopta învățarea validată și să se mute într-un ciclu real, Build-Măsura-Learn.

O altă evoluție importantă a soluției ALM Microsoft a fost de a sprijini, de asemenea, medii non-Windows. TeamExplorer Everywhere (TEE) a fost rezultatul atenției acordate pentru colaborarea cross-platform de la un grup dedicat în interiorul Microsoft (după cumpărare Teamprise). În prezent, toate echipele de produse TFS din interiorul Microsoft împărtășesc o viziune comună pentru a oferi caracteristici ALM pentru medii hibride cu o extensibilitate în minte.

Cu recentele anunțuri de Statistici ale aplicației și Monaco, Microsoft demonstrează să conducă industria mai departe într-un îmbunătățit și rapid ciclu Build-Măsura-Learn (Lean ALM), cu un accent sporit de a îmbrățișa oportunitățile de cloud computing.[ www.intovsts]

Caracteristici Visual Studio Online

De ani de zile, Visual Studio a permis organizațiilor de dezvoltare software a se rupe de rigiditatea, procesului orientat al ciclurilor de viață ale aplicației ce izolează dezvoltarea, testarea, management proiectului și echipele de operare. Abordarea Microsoft asupra managementului ciclului de viață ale aplicației (ALM) oferă un mediu flexibil, care se adaptează la nevoile echipei, elimină barierele dintre roluri, și simplifică procesele astfel încât acestea se pot concentra pe furnizarea de software de calitate mai rapid și mai eficient. Într-o lume în care dezvoltarea software de calitate este din ce în ce mai critic pentru succesul afacerii, principiile enunțate de ALM Visual Studio sunt mai relevante ca niciodată.

Mai jos sunt descrise caracteristicile Visual Studio Online.

Setare inițială

Configurarea TFS, creați un proiect de echipă, și adăugați conturi ale membrilor echipei.

b. Controlul sursei

Se poate împarte sau construi codul utilizând controlul versiuni al Team Foundation (TFVC) sau Git. Dezvoltă aplicația cu TFVC sau dezvoltă aplicația într-un depozit Git.

Indiferent de preferințe, centralizat sau descentralizat, Visual Studio ALM oferă instrumentele necesare pentru a lăsa echipa să gestioneze efficient codul de baza.

Utilizatorii Git vor găsi conturi Git nelimitate în Visual Studio Online, inclusiv suport pentru ramificare, comentare ușoară a codului, și cereri. Integrarea Visual Studio face ramuri de schimbare, comite modificări, și sincronizare la o anumită comitere.

Team Foundation Version Control (TFVC) oferă control și caracteristicile prin care se poate gestiona centralizat codul.

Lucru

Planificare Proiecte, urmărire lucru, colaborare ca o echipă, și raportare ale progresele înregistrate.

Se pot crea comenzi nerezolvate, lucrul în sprint-uri și colaborarea cu ajutorul team rooms.

Pentru a accesa instrumentele de planificare Agile și multe instrumente de colaborare în echipă, este nevoie pentru a lucra în Team Web Access. Alte instrumente, cum ar fi muncă proprie și a construi explorer, se pot accesa de la Team Explorer.

Construiți / Release

Configurarea locală serverului de construire și de a defini procesele de construire.

Cu atât mai rapid software-ul este implementat, cu atât mai repede se poate obține feedback. Cu management de release în Visual Studio se poate configura, aprobă și implementa aplicații pentru orice mediu. Creați metodele de implementare automate pentru fiecare mediu, indiferent cât de complexă este configurarea. Livrarea de software mai des și ușor la un mediu permite celor ce testează pentru a ajunge la validarea sistemului și păstrarea părților interesate implicate în oferirea de feedback.

Testare

Se pot planifica teste și urmări progresul pentru fiecare etapă. Se pot rula teste manuale sau automate, inclusiv teste de performanță și de stres. Se pot implementa în medii virtuale, pentru a permite dezvoltarea și testarea mai sofisticată. Mașinile virtuale pot rula pe orice cadru de virtualizare care este gestionat de System Center Virtual Machine Manager (SCVMM).

Se poate deci folosi Visual Studio pentru managementul ciclului de viață (ALM) pentru a gestiona produsul, reduce riscurilor, și de a îmbunătăți eficiența. [www.visualstudioonline]

În continuare voi descrie modul în care se creează Soluțiile și Proiectele în Visual Studio, cât și creearea de proiecte SQL și Unit Testing.

2.6 Soluții și Proiecte

Visual Studio oferă două recipiente pentru a ajuta gestionarea eficientă a elementelor care sunt necesare dezvoltări, cum ar fi referințe, conexiuni de date, foldere și fișiere. Aceste containere sunt numite soluții și proiecte. Puteți utiliza “Solution Explorer” pentru a vizualiza și gestiona proiecte și soluții și articole asociate acestora.

2.6.1 Soluții

Soluțile conțin obiectele necesare pentru a crea aplicația. O soluție include unul sau mai multe proiecte, plus fișiere și metadate care ajută la definirea soluției în ansamblu. Visual Studio generează automat o soluție atunci când se crează un nou proiect. Acesta stochează definiția pentru o soluție în două fișiere: .sln și .suo. Fișierul definiție soluție (.sln) stochează metadatele care definește soluția dvs., inclusiv:

• Proiectele care sunt asociate cu soluția.

• Elementele care nu sunt asociate cu un anumit proiect.

• Configurațiile “build-ului” care determină ce configurații de proiect să se aplice în funcție de fiecare tip de “build”.

Metadatele stocate în fișierul .suo în soluțile create sunt folosit pentru a personaliza IDE-ul ori de câte ori soluția este activ. De exemplu, Solution Explorer afișează un folder Diverse fișiere pentru o soluție dacă se activează această opțiune, și instrumente adecvate pentru tipurile de proiecte incluse în soluția vor fi disponibile din Toolbox.

2.6.2 Proiecte

Proiectele sunt folosite într-o soluție pentru a gestiona în mod logic, a construe, și depana elementele care alcătuiesc aplicația. Rezultatul unui proiect este de obicei un program executabil (.exe), o bibliotecă (.dll) sau un modul, printre altele.

Visual Studio oferă mai multe șabloane predefinite de proiect. Se pot folosi aceste șabloane pentru a crea container de proiect de bază și un set preliminar de elemente de care este nevoie pentru a dezvolta o aplicație, clasă sau o bibliotecă. De exemplu, dacă s-a ales să se creeze o aplicație Windows, proiectul oferă un articol Windows pentru a-l personalize.

2.6.3. Item-uri

Elemente proiectului pot fi fișiere, referințe la biblioteci, conexiunile de date și foldere care sunt în proiect. Unele elemente reprezintă un element fizic ce se poate localiza în storage. Alte elemente sunt link-uri și reprezintă trimiteri pentru alte elemente.

Soluțile se găsesc în folderul elementelor soluției. Aceste elemente sunt fișiere de proiect independente care se pot crea în plus față de fișierele de proiect. Articole soluției reprezintă fișiere care sunt importante pentru dezvoltarea proiectelor, dar nu aparțin unui anumit proiect.

2.6.4. Crearea Proiectelor din Șabloane

Se pot crea noi proiecte din șabloanele instalate local sau modele disponibile online. Lista de șabloane disponibile variază în funcție de versiunea de .Net Framework vizata. Pentru a vedea o scurtă descriere despre modelul dorit se selectează șablonul respective.

2.7. Proiecte SQL Server

Se pot folosi limbajele .NET Framework în plus față de limbajul Transact-SQL pentru a crea obiecte de bază de date, cum ar fi procedurile stocate și triggere, și pentru a prelua și a actualize datele pentru bazele de date de tip Microsoft SQL Server. Dezvoltarea obiectelor bază de date prin limbaj .NET Framework pentru pentru SQL Server folosind cod gestionat are multe avantaje în comparație cu Transact-SQL.

Pentru a crea un obiect de bază de date, trebuie creat un proiect SQL Server, se adaugă elementele necesare proiectului, și se adăugă codul la aceste elemente. Ulterior proiectul se implementează în SQL Server.

Pentru a începe un proiect de tip SQL Server, trebuie adăugat un nou proiect la o soluție nouă sau existentă Visual Studio. Șablonul de SQL Server Database se găsește în "Other Languages> SQL Server" în "Add New Project Dialog".

Odată ce proiectul este numit și creat, obiectele SQL Server pot fi adăugate la proiect. În cazul în care baza de date țintă există deja, instrumentul oferă un mijloc de a importa schema bazei de date în trei moduri diferite.

1. Folosind un fișier SQL Server Data-tier (* .dacpac)

2. Conectarea directă la o bază de date SQL Server

3. Folosind unul sau mai multe fișiere script cu toate definițiile obiectelor

Toate cele trei opțiuni sunt destul de ușor de utilizat și în cele din urmă oferă același rezultat final și toate obiectele din baza de date sunt încărcate ca script individual în proiect. În timp ce se importa baza de date, Visual Studio permite definirea structuri de foldere care va organiza scripturile obiecte in soluția generează. Obiectele pot fi organizate de către Schema, Object Type și Schema \ Object Type.

2.7. 1. Elementele ce pot fi adăugate Proiectului

Noi proiecte SQL Server conțin numai referințe și informații de asamblare. Pentru a crea obiectele bazei de date, trebuie adăugat mai întâi un element pentru proiect și apoi adăugați codul lor.

Următorul tabel listează elemente specifice proiectelor SQL Server ce se pot adăuga.

2.7.2 Dezvoltarea bazei de date SQL Server în Visual Studio

Una din sarcinile dificile pe orice proiect software este de a gestiona schimbările de baze de date și să păstreze toate modificările sincronizate. Lucrul este mai greu atunci când avem un mediu de test multiple sau mai multe servere intr-un loc. Spre deosebire de schimbările bazei de date, gestionarea modificări de cod este ușora datorită disponibilității de control a versiunii. Este o sarcină foarte responsabilă pentru orice DBA pentru a urmări toate schimbările și să implementeze aceste modificări la cât mai multe servere. Acest lucru este destul de predispus erori și necesită o mulțime de teste.

Problema prezentat mai sus există până când se va lucra cu proiecte de baze de date SQL folosind Visual Studio. Se poate dezvolta, gestiona, compara și implementa schimbările de baze de date folosind Visual Studio foarte ușor. Putem păstra, de asemenea, toate modificările de obiecte de baze de date sub control de versiune.

Se poate crea un proiect de bază de date nou de la o bază de date existentă cu doar un click sau putem crea un proiect de bază de date de la zero.

2.8. Verificarea codului bazei de date prin utilizarea SQL Server “Unit Test”

Se pot folosi testele unitare SQL Server pentru a stabili o stare de bază pentru baza de date și apoi să verifice orice modificare ulterioară ce este realizată la niveulul obiectelor bazei de date.

Pentru a stabili o stare de referință pentru o bază de date, se crează un proiect de testare și se scriu seturi de Transact-SQL ce operează pe obiectele bazei de date. Prin utilizarea acestor teste, puteți verifica într-un mediu de dezvoltare izolat dacă aceste obiecte funcționează conform așteptărilor. Unitate de testare SQL Server funcționează bine în combinație cu dezvoltarea de baze de date offline, folosind proiecte de baze de date SQL Server. Odată ce un set de bază de teste unitare SQL Server este creat, se pot utiliza acestea pentru a verifica dacă baza de date funcționează corect înainte de a verifica în modificări la variantă de control.

Teste pot verifica schimbările pentru orice obiect bază de date. În plus, pot genera automat resturile de cod Transact-SQL ce testează functile bazei de date, triggerele și proceduri stocate.

Pe măsură ce membrii echipei modifică schema bazei de date, există posibilitatea utilizări acestor teste pentru a verifica dacă modificările au stricat funcționalitățile existente. Puteți crea teste unitare SQL Server pentru a completa teste unitare ce dezvoltatorii de software le creează. Trebuie să completeze ambele seturi de teste pentru a verifica comportamentul general al aplicației.

Testele unitare pot verifica dacă procedurile au succes atunci când sunt de așteptat pentru a reuși și că procedurile nu au atunci când acestea sunt de așteptat să eșueze. Testarea că eșecurile adecvate apar este denumită Testarea Negativă.

2.8.1. Instrument DLM (SQL Server Data Tools)

Instrumente SQL Server de date (SSDT) transformă dezvoltarea bazelor de date prin introducerea unui model omniprezent și declarativ ce se întinde pe toate fazele de dezvoltare a bazei de date și de întreținere / modificare în interiorul Visual Studio. Se pot utiliza capacitățile de proiectare SSDT Transact-SQL pentru a construi, depana, menține, și refactoriza baza de date. Lucrul se poate efectua fie cu un proiect de bază de date, sau direct cu o instanță de bază de date conectată sau off-premise.

SQL Server Object Explorer în Visual Studio oferă o vedere a obiectelor de baze de date similar cu SQL Server Management Studio. SQL Server Object Explorer permite administrarea bazelor de date și proiectarea. Se poate crea cu ușurință, edita, redenumi și șterge tabele, proceduri stocate, tipuri și funcții. De asemenea, se editează datele din tabel, compară scheme, sau execută interogări utilizând meniuri contextuale chiar de la SQL Server Object Explorer.

Dezvoltatorii pot folosi instrumente Visual Studio familiare pentru dezvoltarea bazei de date. Instrumente precum: navigarea codului, IntelliSense, suport pentru limbaj ce face o paralelă între ceea ce este disponibil pentru C # și Visual Basic, validare-platforma, depanare, și editarea declarativă în editorul Transact-SQL. SSDT oferă, de asemenea un tabel vizual pentru design pentru a crea și edita tabelele fie în proiectele de baze de date sau instanțe de baze de date conectate. În timp ce se lucrează pe proiecte de baze de date într-un mediu bazat pe echipe, se pot folosi versiuni de control pentru toate fișierele. Când e timpul de a publica proiectul, există posibilitatea de a publica pe toate platformele SQL suportate; inclusiv baze de date SQL și Microsoft SQL Server 2014. Platforma SSDT, platformă de validare asigură faptul că scripturile lucrează la țintă ce este specificată.

SSDT include, de asemenea tipuri de proiecte speciale și instrumente pentru dezvoltarea de servicii de analiză, raportare servicii și integrarea serviciilor de Business Intelligence (BI) ca soluții SQL Server 2014.

2.8.2. Noțiuni de bază cu Unit Testing în bazele de date SQL Server în SSDT

SSDT permite dezvoltarea, depanarea și executarea testelor unitare de baze de date interactive în Visual Studio, care poate fi apoi rulate din linia de comandă sau dintr-o mașină de construit, de exemplu, un server Build Team Foundation configurat pentru integrarea continuă. SSDT ajută la echivalarea testări bazei de date cu alte aspecte de testare aplicate, ajutând la creșterea și apoi menținerea calități aplicațiilor de baze de date SQL Server.

Testarea unitară a bazelor de date SQL Server cu SSDT este foarte simplu, deși există o serie de lucruri ce trebuie urmărite. În primul rând trebuie este necesar Visual Studio instalat.

2.8.3. Proiecte de testare și conversia proiectelor existente

Teste unitare SQL Server sunt create într-un proiect de test în VB sau C #. Infrastructura MSTest este folosită pentru a rula testele și a vedea rezultatele. Dacă există proiecte de testare ce conțin teste pentru baze de date create cu o versiune anterioară de Visual Studio, atunci trebuie convertite aceste proiecte înainte de a lucra pe ele cu SSDT. Pentru a converti, pur și simplu faceți clic dreapta pe proiectul de testare în Solution Explorer și selectați Convert to SQL Server Unit Tesing project…

SSDT introduce un nou șablon SQL Server de testare unitatara. Există două moduri de a crea teste unitare SQL Server într-un proiect de testare: fie prin generarea de teste dintr-o bază de date proiect deschisă în SQL Server Object Explorer (SSOX), ce creează testele unitare cu un script T-SQL schelet pentru a finaliza, sau prin adăugarea manuală de teste unitare într-un proiect de testare folosind șablonul. Dacă se creează aceste teste de SSOX va exista opțiunea de a crea un proiect de testare nou sau adăugați testele într-un proiect existent. În multe cazuri, scheletul generat va fi un bun punct de plecare, este cel mai bun mod de a începe și se poate încerca această metodă.

2.8.4. Generarea Testelor Unitare SQL Server din obiecte în SQL Server Object Explorer

Dacă un proiect de baze de date SQL Server este în soluție se pot genera teste unitare din orice procedure stocate, funcție sau trigger DML definit în proiect. Pentru a face acest lucru, se găsește proiectul de sub nodul de noi proiecte în SSOX, se face clic dreapta pe obiectul pe care doriți să testați și selectați Creare Test Unitar…. Se pot genera teste pentru un obiect individual, sau prin selectarea nodul mamă în SSOX, generează teste pentru toate obiectele din acel nod. Dacă pentru orice motiv nu există acces la un proiect de baze de date ce trebuie testați, se poate crea un nou proiect navigând la baza de date în SSOX, și realizând clic dreapta pe ea, și apoi Create New Project.

În caseta de dialog care urmează (a se vedea mai jos) se verifică toate obiect(le) pentru care se adaugă teste generate și se alege dacă se crează un proiect nou test sau testul (e) este adăugat la un proiect de testare existent. Acest dialog arată toate obiectele candidate în cadrul proiectului cu care se lucrează. Dacă proiectul are trimiteri la aceeași baze de date cu alte proiecte sau dacpacs, atunci aceste referințe sunt rezolvate și dialogul va cuprinde obiecte candidate din proiectele referite și dacpac. După ce se selectaza toate obiectele sursă care trebuie utilizate, se face clic pe OK și proiectul și / sau teste vor fi generate.

2.8.5. Crearea manuală de Teste Unitare SQL Server

Se pot adăuga, de asemenea teste goale la un proiect și acestea trebuie definite de la zero. Pentru a face acest lucru, creați sau deschideți un proiect de test, faceți clic dreapta pe proiect în Solution Explorer, apoi utilizați Adaugă> New Item și localizați șablonul SQL Server Unitate de testare sub nodul SQL Server.

 2.8.6. Configurarea unui Proiect de test

Indiferent de ruta pe care se crează teste unitare de baze de date, atunci când se adaugă mai întâi un test unitary SQL Server la un proiect de test se va solicita să se configureze proiectul pentru unitatea de testare. În dialogul de configurare (afișat mai jos) se alege baza de date ce se testează, și, opțional, un proiect de baze de date SQL Server pentru implementare înainte de a rula testele. Exemplul de mai jos folosește baza de date de depanare implicită AdventureWorks restaurată dintr-un backup pentru un proiect de bază de date, dar se poate folosi orice bază de date, sau se poate crea o nouă bază de date din acest dialog. Capacitatea de a specifica sau de a crea o bază de date în timpul configurării de test vă permite să testați diferite instanțe ale aceeași bază de date fără a deranja baza de date de debug al proiectului sursă. Dacă se utilizează o bază de date locală va trebui create o nouă conexiune din dialogul de configurare, și specificat numele serverului. Dacă se alege pentru a implementarea unui proiect de bază de date atunci când se execută testele, se va implementa folosind conexiunea specificată în acest dialog, cu proprietățile de implementare specificate în filă Debug în proprietatiile proiectului de bază de date. Se poate schimba configurația proiectului de testare, la orice moment din meniul contextual al proiectului sau din meniul SQL cu proiectul de testare selectat.

2.8.7. Definirea scripturilor de test T-SQL

Cu configurație proiectului realizată, proiectarea testului unitary de baze de date va fi deschis pe testul creat, permițând definirea scriptului de test și condițiilor de testare stabilite. Dacă s-a ales să se genereze un script de test schelet, se va observa în panoul superior de editora(mai jos). Acum trebuie scris script de test sau îmbunătățit scheletul generat. Script-ul ar trebui să acționeze asupra obiectelor din baza de date ce se doresc a fi testate. Se pot folosi cuvintele cheie THROW sau RAISERROR în timpul execuției pentru a indica ca un test a eșuat, sau pentru a evalua rezultatele, folosind condiții de testare.

2.8.8. Definirea Conditilor de Test

Când testul este executat, scriptul de test este distribuit bazei de date, iar rezultatele sunt transmise înapoi la test ce urmează să fie evaluate cu ajutorul uneia sau mai multor condiții de testare. Odată ce script-ul T-SQL este gata, trebuie eliminate condiția de test implicită din panoul inferior (care va eșua întotdeauna), iar apoi se adaugă una sau mai multe condiții de testare corespunzătoare din lista verticală și se configurează, dacă este necesar în fereastră de proprietăți (a se vedea mai sus).

2.8.9. Conditile de testare

În mod evident, utilizatorii ar avea nevoie de un set de sarcini de verificare frecvent efectuate, iar produsul ar trebui să ofere o modalitate mai bună de a efectua aceste atribuții. Astfel s-a născut conceptul de condiție de testare bazat pe UI care verifică rezultatele testului după ce scriptul SQL a fost executat. Se pot seta și configura aceste condiții în interiorul ferestrei de design al unității de testare.

Modulul SSDT include condițiile de încercare care apar în tabelul 1.

Prin definirea unei condiți personalizate de test, se poate verifica comportamentul unui obiect din baza de date într-un mod în care condițile built-in nu suportă. În mod implicit, aveți posibilitatea să utilizați următoarele condiții:

Table 1. Condiții de test disponibile

Dacă se dorește să se testeze alte condiții, cum ar fi verificarea valorilor într-un set de rezultate, trebuie creată o condiție personalizată. O condiție de testare personalizată este un tip de caracteristică de extindere. Înainte de a putea utiliza o condiție personalizată, trebuie instalat ansamblul ce conține condiția în cache la nivel de asamblare mondial. După trebuie să se înregistreze condiția pe orice calculator se intenționează a o utiliza.

2.8.10. Rularea Testului

În acest moment proiectul de testare trebuie construit și rulat testul și examinat rezultatul. Înainte de a construi proiectul pentru prima dată, trebuie șters fișierul de testare creat inițial de VB sau C # în fiecare proiect nou de test. Se poate rula testul din meniul de Test > Run. Când testele sunt executate din acest meniu proiectul va construi automat dacă nu ați construit înainte sau au fost făcute modificări la teste.

În Visual Studio se pot vizualiza toate testele în proiectul dumneavoastră de testare și se ruleza selectiv din meniul Test > Windows > Test Explorer și rula, vizualizați rezultatele și alege anumite teste pentru rulare în fereastra separată de rezultate (vezi mai jos). [www.msdn/ssdt]

2.9. Strategii pentru izolarea bazei de date în testare

Una dintre cheile pentru a avea teste ce pot fi întreținute o reprezintă asigurarea că testele sunt izolate și reproductibile. Pentru testele de unitate, acest lucru este ușor, atâta timp cât vom sta departe de variabile globale, clase statice și în general stare globală.

Acest lucru devine un pic mai provocator, cu teste de integrare, care interacționează cu o bază de date, în cazul în care starea este prin definiție, la nivel global și împărtășita. Pentru a avea suită de teste de integrare mentenabila, trebuie avută o asigurare că testele au întotdeauna un punct de plecare consistent.

Mai ușor de zis decât de făcut, dar din fericire există destul de puține opțiuni pentru acest lucru.

2.9.1 Bază de date de test pentru fiecare dezvoltator

O greșeală des făcută de o mulțime de echipe este că nu izolează în mod corespunzător baze de date pentru fiecare dezvoltator. Cel mai corect mod de implementare este cu o singură instanță de bază de date împărtășită pentru fiecare echipă.

Acest lucru face ca testarea și dezvoltarea frustrantă pentru ambele echipe implicate, nu numai că nu am împărtășita pe propria mașină, dar și faptul că alte persoane ar putea face o schimbare a datelor de sub nivelul propriu. Se poate avansa un pas și fiecare dezvoltator să aibă o bază de date locală:

Acum fiecare dezvoltator poate face în condiții de siguranță modificări la baza de date locală fără a se preocupa de alte interferențe ale dezvoltatorilor. Dar pentru o și mai bună organizare, fiecare devoltator este necesar să aibă două baze de date locale: una pentru testare și una dezvoltare:

Baza de date “Dev” trece prin migrații de scheme, dar nu este niciodată "goală". Datele sale rămân în continuare astfel încât în timpul dezvoltării nu trebuie să se înceapă cu o bază de date gola. În plus, în cazul în care dezvoltarea necesită o mulțime de date în baza de date “Dev”, se pot păstra totuși, pentru o dezvoltare normală.

Pentru testare, unde vrem condițiile de instalare deterministe, bază de date de test este folosită doar pentru testare automată și este menținuta într-o stare cunoscută înainte de fiecare încercare. Este nevoie doar de a crea strategia migrări pentru a păstra ambele baze de date locale la nivel local (dar acest lucru nu ar trebui să fie o problemă cu instrumentele de migrare de astăzi).

Acum, că există o configurare locală adecvată, putem aminti unele opțiuni pentru păstrarea bazei de date de testare într-o stare consistentă și fiabilă.

2.9.2. Tranzactile de tip “Roll back”

Una dintre cele mai simple moduri de a reveni în urma modificărilor efectuate în timpul unui test este de efectua “roll back” la modificările făcute în timpul unui test. A fost deschisă o tranzacție la începutul unui test, s-au realizat unele modificări, iar la sfârșitul testului, se face “roll back” la această tranzacție.

Deoarece bazele de date (în funcție de nivelul de izolare) includ modificări care le-am făcut în interiorul unei tranzacți cu citire ulterioară, testele pot interoga încă pentru actualizările efectuate. Și apoi, la sfârșitul testului, modificări dispar.

Dacă un rollback nu va fi suficient, trebuie mai simplu curățată baza de date înainte de fiecare încercare.

2.9.3. Resetarea bazei de date înainte de fiecare încercare

Acest moment este punctual în care lucrurile devin interesante deoarece majoritatea bazelor de date nu au nici un fel de comutator "reset". În schimb, trebuie să se elaboreze metode interesante de curățare a datelor din aplicația de baze de date înainte de fiecare test. Sunt enumerate câteva moduri de a face acest lucru:

Detașarea bazei de date și restaurarea unei copii de rezervă

Dezactivarea tuturor constrângerile FK, truncarea fiecărei tabele, și restaurarea constrângerile FK

Găsirea ordini "corecte" de a șterge datele bazate pe relații, și de a șterge datele din fiecare tabelă în ordine

Prima modalitate nu funcționează cu adevărat dacă baza de date nu se schimbă des. Păstrarea unei copii de rezervă care poate fi restaurată în mod eficient este enervantă dacă schema se modifică, și trebuie ținută copia la zi. E doar foarte util în cazul utilizării unei baze de date de producție, dar altfel, este o destul de complicat de aplicat această metodă.

Opțiunea următoare implică doar curățarea fiecărei tabele din baza de date, indiferent de ordine. Pentru a evita încălcări de constrângere, se pot dezactiva toate constrângerile, trunchia fiecare tabelă, apoi a restabili constrângeri. Problema cu această abordare este faptul că este destul de lentă, cu câte 3 comenzi pe fiecare bază de date.

În cele din urmă, ultima opțiunea, este de a examina metadatele SQL pentru a construi un grafic de tabele și relațiile. Dacă se șterg datele într-un mod de primul în adâncime, această asigură că nu se încalcă constrângeri FK când s-ar am șterge entități.

Ca și proces, acesta este îndelungat, dar ideea este că se poate crea listă de tabele în ordinea corectă doar o dată, și apoi înainte de fiecare test, să se șteargă toate datele în ordinea corectă.

Următoarea opțiune poate fi foarte bine folosită în unele cazuri.

2.9.3.a. Baze de date în memorie

Dacă se poate, folosind baze de date în memorie este o altă opțiune grozavă la ștergerea bazei de date înainte de fiecare test. În loc de a avea o bază de date la nivel global pe cutia noastră de dezvoltare pentru fiecare test, putem crea o versiune de baze de date în memoria cu fiecare test.

Capacitatea de a face acest lucru depinde foarte mult de câțiva factori:

• Ce fel de baza de date de producție se folosește

• Ce caracteristici ale bazei de date de producției folosim

• Dacă există o versiune de bază de date în memoria ce se utilizează

Indiferent în ce strategie este aleasă, trebuie ținut cont de faptul că cele mai bune teste, testele cele mai fiabile, au un punct de plecare cunoscut și consistent. Cel mai bun mod de a realiza acest lucru este de a avea o bază de date de test locală, care se poate reseta cumva, înainte sau după teste, la o stare cunoscută.

2.9.4. Ce este testarea unitară în bazele de date?

Testare unitară este un concept bine înțeles în dezvoltarea de aplicații, dar comunitatea de baze de date nu a îmbrățișat încă avantajele și strategiile acestei abordări. În continuarea vom începe prin explorarea principiile fundamentale ale metodologiei de unități de testare. Testarea unitară oferă un mod structurat și automatizat de testare a componentelor individuale ale unui sistem. Testele unitare sunt cel mai adesea scrise de dezvoltatorul componentei care este testată. Fiecare test unitary testează un modul specific de cod într-un mod izolat pentru a se asigura că elementul comportă conform așteptărilor.

Cum fac toate aceste lucruri referire la dezvoltarea de baze de date? Analogia directă a testări unitare de aplicați din lumea bazelor de date sunt teste de obiecte programabile. Aceste obiecte includ, de exemplu, procedurile de baze de date stocate, funcții și triggere.

2.9.5. De ce să realizăm Teste unitare asupra bazelor de date?

Ca metodologie, testarea unitară are multe avantaje față de testarea ad-hoc și manuală și depanarea. Prin dezvoltarea testelor unitare de baze de date, se pot crea o colecție de teste și să fie rulate în timpul dezvoltari pentru a se asigura funcționalitatea corectă a caracteristici așteptate. Deoarece fiecare test unitar se concentrează în special pe o metodă individuală, se poate determina mai ușor sursa de eșec pentru un test ce nu a funcționat. Prin urmare, testele unitare ale bazelor de date ajută la determinarea surselor de bug-uri în cod.

O astfel de colecție de teste este foarte util pentru testarea de regresie. Pe măsură ce noi caracteristici se adaugă în aplicație, se pot rula testele existente pentru a se asigura funcționalitatea existentă și faptul că funcționează. O astfel de suită de teste de regresie facilitează schimbările bazei de date, deoarece puteți face acum schimbări știind implicațiile acestora.

Testele unitare, în plus, serveasc ca documentație pentru utilizatori ai metodelor de testare. Dezvoltatorii pot revizui rapid testelor unitare pentru a determina exact modul cum componentele trebuie consumate.

2.9.6. Tipuri de teste unitare de baza de date

Testarea unitară a bazei de date nu se limitează doar la testarea obiectelor programabile ale bazei de date. Se pot realiza patru clase de teste care sunt descrise în continuare:

2.9.6.a. Testarea caracteristicilor

Primul și probabil cea mai răspândită clasă a testării unitare de baze de date este un test de caracteristici. Probabil, testele de caracteristici testează caracteristicile nucleelor sau API-urile, bazei de date din perspectiva consumatorului de baze de date. Testarea obiecte programabile a unei baze de date este scenariul principal aici. Deci, testarea tuturor procedurile stocate, funcțiile, și triggerele în interiorul bazei de date constituie teste de caracteristici. Pentru a testa o procedură stocată, se va executa procedura stocată și verificați dacă rezultatele așteptate au fost returnate sau comportamentul adecvat a avut loc. Cu toate acestea, se poate testa mai mult decât aceste tipuri de obiecte. De exemplu se dorește asigurarea că un “view”, oferă randamentul de calcul corespunzător dintr-o coloană computerizată.

2.9.6.b. Teste de schemă

Unul dintre cele mai importante aspecte ale unei baze de date este schema sa și pentru a se asigura că se comportă cum este de așteptat există o altă clasă importantă de teste unitare de baze de date. Aici, se va dori de multe ori pentru a se asigura că un „view” returnează un set de coloane așteptat, de tipul de date, corespunzătoar în ordinea corespunzătoare. Se poate dori asigurarea că baza de date conține 1.000 de tabele ce se doreau a fi așteptate ca rezultat.

2.9.6.c. Teste de Securitate

În ziua de astăzi, securitatea datelor, care sunt stocate în baza de date este critică. Astfel, o altă clasă importantă de teste unitare de baze de date sunt cele care testează securitatea bazei de date. Aici, se va dori asigurarea faptului că există anumiți utilizatori în baza de date și să fie atribuite permisiunile corespunzătoare. Se va dori de multe ori a se crea teste negative care încearcă să preia date din tabele cu acces restricționat sau “views” și să se asigure că accesul este refuzat în mod corespunzător.

2.9.6.d. Teste Stock-date

Multe baze de date conțin date de stoc, sau date inițiale. Aceste date se schimbă rar și sunt adesea folosite ca date de căutare pentru aplicații sau utilizatori finali. Codurile ZIP și orașele lor asociate și state sunt exemple mari ale acestui tip de date. Prin urmare, este util de a crea teste pentru a se asigura că datele de stoc există în baza de date.

Frumusețea condiților de testare este că acestea pot fi personalizate. Personalizarea conditilor de test este o extensie importantă.

2.9.7. Gestionarea stării bazei de date

Un aspect important în testarea unitară a bazei de date este gestionarea stării bazei de date. Acest aspect al testării unitare a bazei de date o face mai dificilă decât omologul său de aplicație. Cu toate acestea, este fundamental pentru ceea ce testarea unitară a bazei de date este, pentru că o bază de date nu este nimic mai mult decât o colecție de date sau de stări.

Deci, întrebarea principală este: Cum se pot garanta că datele din baza de date sunt ceea ce am se așteptă a fi atunci când se rulează testele?

Această întrebare are două aspecte principale:

• În primul rând, trebuie să se asigure că baza de date are starea așteptată, înainte de a executa o colecție de teste.

• În al doilea rând, trebuie să se asigure că baza de date are starea apropiată între fiecare test din colecția de testare.

Se pot utiliza una din mai multe tehnici de a crea starea inițială a bazei de date:

1. Se utilizează un instrument de generare de date pentru a stabili starea bazei de date, înainte de a rula o colecția de teste unitare. Această tehnică este cea mai bună practică pentru gestionarea stării bazei de date.

2. Restaurarea unei baze de date de rezervă, sau atașarea unei bază de date existentă. Dacă există deja un set de date de test ce se doresc a fi utilizate, de multe ori o abordare ușor este de a restabili în mod automat o bază de date dintr-o copie de rezervă înainte de a rula testele unitare. În mod similar, puteți atașa o bază de date existentă server-ul înainte de a rula testele. Această abordare devine problematică atunci când se schimbă în mod constant schema bazei de date, pentru că trebuie actualizată în mod regulat copia de rezervă a bazei de date.

3. Testele se pot presupune ca nu au nici o stare și, ca parte al fiecărui pre-test, se setează starea corespunzătoare. Această tehnică, deși foarte "pură" dintr-o perspectivă filosofică, nu este foarte practică. Nu numai că este scump să se scrie astfel de teste, dar impactul de performanță pentru setarea și distrugerea stării bazei de date pentru fiecare test pot fi prohibitive.

Cea de a două problemă, gestionarea stării între teste, are mai multe tehnici proprii:

1. Tranzacții – Cea mai bună abordare pentru rezolvarea acestor probleme este să se încheie testele unitare în tranzacții, iar apoi se anulează tranzacția după ce se termină de efectuat verificarea testului și înainte de a executa următorul test. Prin această tehnică se asigură că testele bazei de date se tranzacționează și astfel că a revenit baza de date la starea sa înainte de fiecare încercare.

2. Curățenia modificărilor de stare în fiecare script post-test – altă tehnică este de a avea fiecare încercare a reveni la statul anterior al bazei de date. Această abordare este mai manuală decât sugestia anterioară. De exemplu, dacă se testează o procedură stocată dbo.CreateEmployee, în scriptul de post-test, se șterge angajatul adăugat din tabelele relevante pentru a reveni la starea anterioară a bazei de date.

2.9.8. Generarea de date

Să realizăm un exercițiu în tehnică generări de date pentru gestionarea stării bazei de date. Pentru orice dezvoltare serioasă de bază de date, este nevoie de date de testare realiste pentru a verifica sistemul. Se poate lua orice abordare din mai multe comune pentru a testa generarea de date:

• Utilizați datele de producție în scop de testare. Pentru această abordare, utilizați de obicei datele de producție vechi sau se transformă datele de producție prin înlocuirea valorilor efective cu valori care sunt oarecum echivalente. Avantajul acestei abordări este că nimic nu este mai reprezentativ decât datele de producție. Desigur, dezavantajul mare este că sunt pe baza datelor de producție, care are în mod clar implicații mari de confidențialitate, în special în mediu extrem de reglementat astăzi.

• Date de test de la zero. Noi proiecte de dezvoltare nu au de cele mai multe ori date de producție pentru a le imita. Deși această abordare este liberă de toate problemele de confidențialitate, această este de obicei consumatoare de timp pentru a veni cu date de test ușore care imită de fapt mediul de producție.

Prezentarea aplicativă

Conceptul de testare unitară presupune o testare la nivel de unitate funcțională implementată în aplicația software. Astfel pentru arată acest concept, m-am decis să realizez o suită de teste, asupra unui proiect de baze de date, explicând pe parcurs întregul proces de dezvoltare al acestora. Întregul proiect se bazează pe lucrul cu bazele de date Microsoft SQL, testele fiind scrise în Microsoft Visual Studio.

În primul rând, pentru a putea începe conturarea testelor, este nevoie de o bază de date, asupra căreia să putem efectua procesele. Am ales “AdventureWorks2014”, o bază de date mostră, ce poate fi descărcată de pe site-ul Microsoft și este bine conturată pentru a putea exersa pe aceasta.

Primul pas a fost restaurarea bazei de date și modificarea unor tabelelor pentru a permite ștergerea și actualizare anumitor înregistrări fără a afecta structură acesteia.

În urma acestor operațiuni am adăugat baza de date, ce conține o gamă largă de înregistrări, iar în continuare am creat un cont de Visual Studio Online, pentru a-mi defini ALM-ul aplicației create.

Și am creat un nou proiect cu o metodologie Agile, ce se desfășoară în trei Iterații.

Ulterior acestui pas, mi-am conectat Visual Studio 2013 IDE la mediul de lucru creat, pentru a utiliza astfel toate caracteristicile descrise în cadrul acestei lucrări, de control al versiuni, de integrare, de testare și altele.

Schema bazei de date poate fi vizualizată în următoarea imagine împreună cu toate legăturile dintre tabele.

Următorul pas a fost crearea unui proiect de tip SQL în Visual Studio pentru a putea adăuga „Unit Tests” și realiza testarea funcționalităților adăugate și deja existente.

Pentru a crea un proiect dintr-o bază de date importată, Visual Studio ne oferă o unealtă denumită SSDT (SQL Server Data Tools) pentru a converti baza deja adăugată într-un proiect SQL. Acest lucru îl realizăm din fereastra de „Explorer al obiectelor de tip SQL Server” prin selectarea opțiunii de „Create New Project”, Visual Studio generând scripturile necesare tabelelor și tuturor funcțiilor din cadrul bazei noastre de date.

În soluția creată se poate observa proiectul ce conține baza de date, iar lângă aceasta, pentru a realiza testarea, se va adăuga un proiect de tip „Unit Test”, în cadrul căruia voi adăugă și clasele testelor.

Pentru o mai bună exemplificare și lucru cu testele unitare am adăugat un număr de 9 proceduri stocate pentru Crearea, Selectarea, Modificarea și Ștergerea unor tabele cu următoarele secvențe de cod, urmând a le urca în proiectul creat în Visual Studio Online, fiecare fiind atașate unui User Story/Feature corespunzător.

Crearea unei procedure stocate pentru Selectarea unui ‘Employee’ din tabelă

CREATE PROC [HumanResources].[usp_EmployeeSelect]

@BusinessEntityID int

AS

SET NOCOUNT ON

SET XACT_ABORT ON

BEGIN TRAN

SELECT [BusinessEntityID], [NationalIDNumber], [LoginID], [OrganizationNode], [OrganizationLevel], [JobTitle], [BirthDate], [MaritalStatus], [Gender], [HireDate], [SalariedFlag], [VacationHours], [SickLeaveHours], [CurrentFlag], [rowguid], [ModifiedDate]

FROM [HumanResources].[Employee]

WHERE ([BusinessEntityID] = @BusinessEntityID OR @BusinessEntityID IS NULL)

COMMIT

GO

Crearea unei procedure stocate pentru Inserarea unui ‘Employee’ în tabelă

CREATE PROC [HumanResources].[usp_EmployeeInsert]

@BusinessEntityID int,

@NationalIDNumber nvarchar(15),

@LoginID nvarchar(256),

@OrganizationNode hierarchyid = NULL,

@OrganizationLevel smallint = NULL,

@JobTitle nvarchar(50),

@BirthDate date,

@MaritalStatus nchar(1),

@Gender nchar(1),

@HireDate date,

@SalariedFlag Flag,

@VacationHours smallint,

@SickLeaveHours smallint,

@CurrentFlag Flag,

@rowguid uniqueidentifier,

@ModifiedDate datetime

AS

SET NOCOUNT ON

SET XACT_ABORT ON

BEGIN TRAN

INSERT INTO [HumanResources].[Employee] ([BusinessEntityID], [NationalIDNumber], [LoginID], [OrganizationNode], [JobTitle], [BirthDate], [MaritalStatus], [Gender], [HireDate], [SalariedFlag], [VacationHours], [SickLeaveHours], [CurrentFlag], [rowguid], [ModifiedDate])

SELECT @BusinessEntityID, @NationalIDNumber, @LoginID, @OrganizationNode, @JobTitle, @BirthDate, @MaritalStatus, @Gender, @HireDate, @SalariedFlag, @VacationHours, @SickLeaveHours, @CurrentFlag, @rowguid, @ModifiedDate

– Begin Return Select <- do not remove

SELECT [BusinessEntityID], [NationalIDNumber], [LoginID], [OrganizationNode], [OrganizationLevel], [JobTitle], [BirthDate], [MaritalStatus], [Gender], [HireDate], [SalariedFlag], [VacationHours], [SickLeaveHours], [CurrentFlag], [rowguid], [ModifiedDate]

FROM [HumanResources].[Employee]

WHERE [BusinessEntityID] = @BusinessEntityID

– End Return Select <- do not remove

COMMIT

GO

Crearea unei procedure stocate pentru Modificarea unui ‘Employee’ în tabelă

CREATE PROC [HumanResources].[usp_EmployeeUpdate]

@BusinessEntityID int,

@NationalIDNumber nvarchar(15),

@LoginID nvarchar(256),

@OrganizationNode hierarchyid = NULL,

@OrganizationLevel smallint = NULL,

@JobTitle nvarchar(50),

@BirthDate date,

@MaritalStatus nchar(1),

@Gender nchar(1),

@HireDate date,

@SalariedFlag Flag,

@VacationHours smallint,

@SickLeaveHours smallint,

@CurrentFlag Flag,

@rowguid uniqueidentifier,

@ModifiedDate datetime

AS

SET NOCOUNT ON

SET XACT_ABORT ON

BEGIN TRAN

UPDATE [HumanResources].[Employee]

SET [BusinessEntityID] = @BusinessEntityID, [NationalIDNumber] = @NationalIDNumber, [LoginID] = @LoginID, [OrganizationNode] = @OrganizationNode, [JobTitle] = @JobTitle, [BirthDate] = @BirthDate, [MaritalStatus] = @MaritalStatus, [Gender] = @Gender, [HireDate] = @HireDate, [SalariedFlag] = @SalariedFlag, [VacationHours] = @VacationHours, [SickLeaveHours] = @SickLeaveHours, [CurrentFlag] = @CurrentFlag, [rowguid] = @rowguid, [ModifiedDate] = @ModifiedDate

WHERE [BusinessEntityID] = @BusinessEntityID

– Begin Return Select <- do not remove

SELECT [BusinessEntityID], [NationalIDNumber], [LoginID], [OrganizationNode], [OrganizationLevel], [JobTitle], [BirthDate], [MaritalStatus], [Gender], [HireDate], [SalariedFlag], [VacationHours], [SickLeaveHours], [CurrentFlag], [rowguid], [ModifiedDate]

FROM [HumanResources].[Employee]

WHERE [BusinessEntityID] = @BusinessEntityID

– End Return Select <- do not remove

COMMIT

GO

Crearea unei procedure stocate pentru Ștergerea unui ‘Employee’ în tabelă

CREATE PROC [HumanResources].[usp_EmployeeDelete]

@BusinessEntityID int

AS

SET NOCOUNT ON

SET XACT_ABORT ON

BEGIN TRAN

DELETE

FROM [HumanResources].[Employee]

WHERE [BusinessEntityID] = @BusinessEntityID

COMMIT

GO

Aceeași procedură am urmat-o pentru tabelele [HumanResources].[Department] și [Production].[Product].

În orice moment putem verifica caracteristică de control al versiunii oferită de Visual Studio Online.

Prima procedură stocată pentru care am adăugat teste unitare a fost “usp_EmployeeInsert”, aceasta fiind creată pentru a putea adăuga un „Employee” în baza de date.

Testele sunt scrise în Transact SQL și pot conține 3 părți: Pre Test, Test și Post Test.

Pentru această caracteristică am definit un test pentru corpul principal și încă o operație în secțiunea de „Post Test”.

Mai întâi în „Test” am realizat adăugarea de „Employee” în tabelă și am afișat numărul de înregistrări din tabelă înainte de a efectua o modificare asupra acesteia.

Urmând ca în „Post Test” să afișez numărul total de rânduri în urma adăugării, iar ca și condiție am setat „Expected Schema”, pentru a înfățișa o schemă ce o așteptăm în urma rulării testului.

Resultatul testului fiind unul pozitiv și au fost afișate detaliile necesare, adică numărul de înregistrări, înainte și după apelarea procedurii stocate.

Am definit astfel primul „Unit Test” asupra procedurii stocate de adăugare de „Employee” în baza de date. Am continuat în mod asemănător pentru restul procedurilor stocate din baza de date.

Pentru a testa procedura stocată de actualizare, am setat condiția ca setul de rezultate întors să aibă cel puțin o înregistrare, și de asemenea am afișat un mesaj din care să rezulte modificarea realizată.

Rularea suitei de teste întoarce următorul rezultat.

Am continuat să definesc testele pentru mai multe proceduri stocate după cum urmează. Pentru procedurile stocate de inserare, modificare, selectare și ștergere ale înregistrărilor din tabela “Department”.

“Department Insert”

“Pre Test”

/*

delete if exists Department with Name = 'Automation CQA',

*/

delete from HumanResources.Department where Name = 'Automation CQA';

select * from HumanResources.Department where Name = 'Automation CQA';

“Test”

– database unit test for HumanResources.usp_DepartmentInsert

DECLARE @Name AS [dbo].[Name], @GroupName AS [dbo].[Name], @ModifiedDate AS DATETIME;

SELECT @Name = 'Automation CQA',

@GroupName = 'Core QA',

@ModifiedDate = getdate();

EXECUTE [HumanResources].[usp_DepartmentInsert] @Name, @GroupName, @ModifiedDate;

–IF (@@ROWCOUNT > 0)

–RAISERROR ('WOW',2,2)

–SELECT @RC AS RC;

“Post Test”

/*

select the record added with the insert procedure

*/

select * from HumanResources.Department where Name = 'Automation CQA';

“Department Select”

“Test”

– database unit test for HumanResources.usp_DepartmentSelect

DECLARE @RC AS INT, @DepartmentID AS SMALLINT;

SELECT @RC = 0,

@DepartmentID = '7';

EXECUTE @RC = [HumanResources].[usp_DepartmentSelect] @DepartmentID ;

–SELECT @RC AS RC;

“Post Test”

– database post test for HumanResources.usp_DepartmentSelect

DECLARE @RC AS INT, @DepartmentID AS SMALLINT;

SELECT @RC = 0,

@DepartmentID = '17';

EXECUTE @RC = [HumanResources].[usp_DepartmentSelect] @DepartmentID ;

“Department Update”

“Pre Test”

/*

test if the result set contains the wanted row

*/

–INSERT INTO [HumanResources].[Department] ([Name], [GroupName], [ModifiedDate])

–SELECT 'Automation CQA', 'Electronic Arts', getdate();

SELECT * FROM [HumanResources].[Department] WHERE [Name] = 'Automation CQA';

“Test”

– database unit test for HumanResources.usp_DepartmentUpdate

DECLARE @DepartmentID AS SMALLINT, @Name AS [dbo].[Name], @GroupName AS [dbo].[Name], @ModifiedDate AS DATETIME;

SELECT @DepartmentID = (SELECT DepartmentID from [HumanResources].[Department] where GroupName like '%'+'QA'+'%'),

@Name = 'AutomationSpecialist Department',

@GroupName = 'EA',

@ModifiedDate = getdate();

EXECUTE [HumanResources].[usp_DepartmentUpdate] @DepartmentID, @Name, @GroupName, @ModifiedDate;

“Post Test”

/*

testing if Department was UPDATED, by returning the row with the new name

*/

select * from HumanResources.Department where Name = 'AutomationSpecialist Department' AND GroupName = 'EA';

“Department Delete”

“Test”

– database unit test for HumanResources.usp_DepartmentDelete

DECLARE @RC AS INT, @Name AS [dbo].[Name], @DepartmentID AS smallint;

SELECT @RC = 0,

@DepartmentID = (SELECT DepartmentID from [HumanResources].[Department] where Name = 'AutomationSpecialist Department');

EXEC @RC = [HumanResources].[usp_DepartmentDelete] @DepartmentID;

SELECT @RC AS RC;

“Post Test”

/*

post test delete department, check if the department with a certain name was deleted

*/

select * from HumanResources.Department where Name like 'AutomationSpecialist Department';

Testele adăugate le-am compilat și rulat rezultatele fiind toate pozitive, însemnând că toate procedurile testate sunt scrise corect și comportamentul așteptat este întors și testat de condițiile din fiecare test.

Putem vizualiza intrările din tabelă și vom observa o nouă înregistrare ce a fost și modificată.

Ca și rezultat întors fiecare test a avut de validat o condiție și de asemenea poate și afișarea unui mesaj pentru verificarea procedurii create.

Test Name: Test1_Department_Insert

Test Outcome: Passed

Result StandardOutput:

Debug Trace:

Executing pre-test script…

1 batches, 1 ResultSets, 0 rows affected

Validating rowCountCondition1

Executing test script…

1 batches, 1 ResultSets, 0 rows affected

Validating notEmptyResultSetCondition1

Executing post-test script…

1 batches, 1 ResultSets, 1 rows affected

Validating rowCountCondition4

Test Name: Test2_Department_Select

Test Outcome: Passed

Result StandardOutput:

Debug Trace:

Executing test script…

1 batches, 1 ResultSets, 0 rows affected

Validating checksumCondition1

Executing post-test script…

1 batches, 1 ResultSets, 0 rows affected

Validating expectedSchemaCondition1

Test Name: Test3_Department_Update

Test Outcome: Passed

Result StandardOutput:

Debug Trace:

Executing pre-test script…

1 batches, 1 ResultSets, 1 rows affected

Validating expectedSchemaCondition3

Executing test script…

1 batches, 1 ResultSets, 0 rows affected

Validating executionTimeCondition1

Executing post-test script…

1 batches, 1 ResultSets, 1 rows affected

Validating expectedSchemaCondition2

Evaluated schema

Table Table (0) – 4 columns

0 DepartmentID(Int16)

1 Name(String)

2 GroupName(String)

3 ModifiedDate(DateTime)

Test Name: Test4_Department_Delete

Test Outcome: Passed

Result StandardOutput:

Debug Trace:

Executing test script…

1 batches, 1 ResultSets, 1 rows affected

Validating notEmptyResultSetCondition2

Executing post-test script…

1 batches, 1 ResultSets, 0 rows affected

Validating rowCountCondition2

Alte teste am adăugat pentru procedurile stocate din tabela “Product” și am continuat cu adăugarea de teste și asupra funcțiilor dintr-o bază de date. Prima este de tipul valoare scalară, denumită “Get_Product_List_Price” și ceea ce trebuie să întoarcă este prețul unui anumit produs din tabela [Production].[Product].

În Pre-test, am adăugat un produs specific, al cărui ID îl voi căută pentru a-mi întoarce rezultatul dorit, urmând ca în Post-test să îl șterg și să apelăm iar funcția pentru a testa dacă mai există sau nu în baza noastră de date.

“Pre Test”

/*

Insert a Product in our List Price from [Production].[Product]

*/

DECLARE @RC AS INT, @Name AS [dbo].[Name], @ProductID AS INT, @ProductNumber AS NVARCHAR (25), @MakeFlag AS [dbo].[Flag], @FinishedGoodsFlag AS [dbo].[Flag], @Color AS NVARCHAR (15), @SafetyStockLevel AS SMALLINT, @ReorderPoint AS SMALLINT, @StandardCost AS MONEY, @ListPrice AS MONEY, @Size AS NVARCHAR (5), @SizeUnitMeasureCode AS NCHAR (3), @WeightUnitMeasureCode AS NCHAR (3), @Weight AS DECIMAL (8, 2), @DaysToManufacture AS INT, @ProductLine AS NCHAR (2), @Class AS NCHAR (2), @Style AS NCHAR (2), @ProductSubcategoryID AS INT, @ProductModelID AS INT, @SellStartDate AS DATETIME, @SellEndDate AS DATETIME, @DiscontinuedDate AS DATETIME, @rowguid AS UNIQUEIDENTIFIER, @ModifiedDate AS DATETIME;

SELECT @RC = 0,

@Name = CONCAT('Test_Product_',(SELECT MAX(ProductID) +1 FROM [Production].[Product])),

@ProductNumber = CAST(RAND() * 1000 AS NVARCHAR(25)),

@MakeFlag = (1),

@FinishedGoodsFlag = (1),

@Color = NULL,

@SafetyStockLevel = CAST(RAND() * 1000 AS smallint),

@ReorderPoint = CAST(RAND() * 1000 AS smallint),

@StandardCost = CAST(RAND() * 1000 AS money),

@ListPrice = CAST(RAND() * 1000 AS money),

@Size = NULL,

@SizeUnitMeasureCode = NULL,

@WeightUnitMeasureCode = NULL,

@Weight = NULL,

@DaysToManufacture = CAST(RAND() * 1000 AS INT),

@ProductLine = NULL,

@Class = NULL,

@Style = NULL,

@ProductSubcategoryID = NULL,

@ProductModelID = NULL,

@SellStartDate = getdate(),

@SellEndDate = getdate(),

@DiscontinuedDate = getdate(),

@rowguid = newid(),

@ModifiedDate = getdate();

EXECUTE @RC = [Production].[usp_ProductInsert] @Name, @ProductNumber, @MakeFlag, @FinishedGoodsFlag, @Color, @SafetyStockLevel, @ReorderPoint, @StandardCost, @ListPrice, @Size, @SizeUnitMeasureCode, @WeightUnitMeasureCode, @Weight, @DaysToManufacture, @ProductLine, @Class, @Style, @ProductSubcategoryID, @ProductModelID, @SellStartDate, @SellEndDate, @DiscontinuedDate, @rowguid, @ModifiedDate;

SELECT @RC AS RC;

SELECT @ProductID = (SELECT MAX(ProductID) FROM [Production].[Product]);

INSERT INTO Production.ProductListPriceHistory (ProductID, StartDate, EndDate, ListPrice) VALUES (@ProductID, getdate(),getdate(),@ListPrice);

PRINT CONCAT('The product added has the id ',@ProductID,' and the name ',@Name,' has the List Price set to ',@ListPrice);

“Test”

– database unit test for dbo.ufnGetProductListPrice , test if its found the product added in the pre test

DECLARE @RC AS MONEY, @ProductID AS INT, @OrderDate AS DATETIME, @Name AS NVARCHAR(50);

SELECT @RC = NULL,

@ProductID = (SELECT MAX(ProductID) FROM [Production].[Product]),

@OrderDate = getdate();

SELECT @RC = [dbo].[ufnGetProductListPrice](@ProductID, @OrderDate);

SELECT @Name = (SELECT Name FROM Production.Product WHERE ProductID = @ProductID);

PRINT CONCAT('FOUND : The product added in the pre test with id ',@ProductID,' and the name ',@Name,' has the List Price set to ',@RC,' and the order date equal with ',@OrderDate);

SELECT @RC AS RC;

“Post Test”

/*

delete the added Product in the [Production].[Product]

*/

DECLARE @RC AS MONEY, @SProductID AS INT, @ProductID AS INT, @OrderDate AS DATETIME, @Name AS NVARCHAR(50);

SELECT @SProductID = (SELECT MAX(ProductID) FROM [Production].[Product])

DELETE FROM [Production].[Product] WHERE ProductID = @SProductID;

SELECT @RC = NULL,

@ProductID = (SELECT MAX(ProductID) FROM [Production].[Product]),

@OrderDate = getdate();

SELECT @RC = [dbo].[ufnGetProductListPrice](@ProductID, @OrderDate);

IF @SProductID > @ProductID

PRINT CONCAT('TRUE – Product with id',@SProductID,' was deleted from the database');

ELSE

PRINT CONCAT('FALSE – Product with id',@SProductID,' was not deleted from the database');

SELECT @RC AS RC;

În urma acestui test, se va rula, din nou, suită de teste pentru a putea observa comportamentul funcției scalare.

Test Name: Test8_Get_Product_List_Price

Test Outcome: Passed

Result StandardOutput:

Debug Trace:

Executing pre-test script…

Sql Error: 'The product added has the id 1001 and the name Test_Product_1001 has the List Price set to 119.65' (Severity 0, State 1)

1 batches, 2 ResultSets, 2 rows affected

Executing test script…

Sql Error: 'FOUND : The product added in the pre test with id 1001 and the name Test_Product_1001 has the List Price set to and the order date equal with May 14 2015 8:09AM' (Severity 0, State 1)

1 batches, 1 ResultSets, 1 rows affected

Validating rowCountCondition1

Executing post-test script…

Sql Error: 'TRUE – Product with id 1001 was deleted from the database' (Severity 0, State 1)

1 batches, 1 ResultSets, 2 rows affected

Validating expectedSchemaCondition1

La ieșire se poate observa acțiunile ce au fost efectuate asupra tabelelor din baza de date, condițiile de testare fiind în “Test” și “Post-test”,validând pe rând ca în urma apelului funcției se întoarce o înregistrare și că se ajunge la o schemă în care ultima înregistrare adăugată în “Pre-test” a fost ștearsă.

Procedând în aceeași manieră, am creat teste unitare și pentru alte funcții din baza de date dar și proceduri stocate. În următoarea imagine fiind înfățișată o rularea a tuturor testelor și a timpului necesar.

Rezultatul este unul pozitiv, toate acestea rulând fără a interveni probleme în dezvoltarea lor și astfel comportamentul este cel așteptat.

În cazul în care erori există fie în dezvoltarea funcționalităților bazelor de date, sau în cazul în care rezultatul este diferit față de ceea ce s-a dorit, adică a intervenit o eroare în crearea “Unit Test”, acestea vor eșua.

Dar pentru a putea fi integrate în procesul de ALM aceste teste trebuie să fie adăugate și în proiectul creat inițial în cloud, iar acest lucru se poate face fie din Test Management, un instrument ce oferă o facilă administrare și adăugare de teste pentru proiectele create.

Sau din interfață web, unde putem defini “Test Case-urile” și le putem asigna din Visual Studio, id-ului corespunzător.

Ca și rezultat final, testele adăugate vor apărea în “Test Case”-ul definit, și se poate seta ce rezultat vor avea fiecare.

Concluzii

Evoluția instrumentelor ALM pe piață a fost fenomenal. De la instrumente de foarte specifice ale companiilor mici până la soluțiile all-in-one ale jucătorilor tradiționali mari precum HP, IBM și Microsoft. Instrumentele specifice sunt mai răspândite în peisajul de pornire și ar putea fi de multe ori cel mai potrivit pentru un anumit scop. Mari furnizori pe de altă parte vor avea mereu locul lor în organizațiile mari, dar provocarea va rămâne să integreze toate instrumentele legate de ALM-ul activ pentru a îmbunătăți colaborarea și eficiența între părți diferite. Mulți oameni sunt încă dornici de a avea acces rapid la datele de care au nevoie în instrumentul lor de alegere (indiferent de ce instrument este perceput ca instrument ALM master). Datele vor trebui sincronizate perfect în unelte ALM diferite / soluții fără a se pierde concentrarea pe valoarea unei strategii ALM corporative. Companii precum TaskTop și OpsHub joacă deja un rol important în acest domeniu.

Concluzionând cele prezentate în capitolele anterioare putem afirma necesitatea întregului proces de ALM, acesta fiind o parte integrată a dezvoltarii și menținerii produsului software, și necesitatea unor politici de Quality Assurance prin teste unitare, intru-cat acestea asigură o rată de success în depistarea erori foarte ridicată. O eroare în timpul testări a întregii baze de date, poate fi mai greu de găsit, astfel necesitatea acestor teste incipiente este mult sporită, în urma acestora putându-se adăuga și celalalte categorii.

Fiecare produs software dezvoltat, înainte de a fi comercializat, trebuie să fie funcțional. Asigurarea calității are rolul de a realiza concordanță dintre codul scris de dezvoltatori, planul stabilit la începutul procesului și produsul livrat utilizatorilor. Deci putem spune că această disciplină conduce către un produs software mai perfomant și mai bine organizat.

Aceste implementări ar trebui luate în considerare de toți cei ce doresc să asigure un anumit standard produselor dezvoltate, deoarece un sistem software a cărui funcționalitate nu mulțumește clientul final, nu va putea fi mentiunut pe piață.

Direcții viitoare

Testele prezentate au ca rol testarea unei anume funcționalități în cadrul unei baze de date, această etapă fiind prima în procesul de implementare ale unor politici QA.

Testarea unitară poate fi aplicată asupra oricărui sistem software, acesta acțiune fiind indicată înaintea dezvoltării altor modalități de testare.

Un următor pas, în continuarea acestei lucrări de licență este reprezentat de realizarea întregului process de dezvoltare al unei aplicații software, gestionată de un ALM și metodele pentru a realiza toate tipurile de testare prezentate în capitolul 2, adică să trecem prin toate etapele testării, de la testarea unei anumite funcționalități la testarea produsului ca un întreg. În acest pas vor fi necesare implementarea unor politici atât de Quality Assurance, cât și de dezvoltare și integrare, etape definitorii pentru orice organizație, astfel încât produsul realizat să poată fi livrabil consumatorilor.

Bibliografie

J.Date – “ An introduction to Database Systems”, ed. Addison Wesley, 1994

I. Lungu, C. Bodea ș. a. – “Baze de date – organizare, proiectare și implementare “, ed. ALL, 1995

Jeff Tian. Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement. John Wiley and Sons, Inc., and IEEE Computer Society Press. 2005

https://support.office.com/ro-ro/article/No%C8%9Biuni-de-baz%C4%83-despre-proiectarea-bazelor-de-date-1eade2bf-e3a0-41b5-aee6-d2331f158280?ui=ro-RO&rs=ro-RO&ad=RO

http://ro.wikipedia.org/wiki/Baz%C4%83_de_date

https://msdn.microsoft.com/en-us/data/tools.aspx

https://msdn.microsoft.com/en-us/jj851226(v=vs.103).aspx#

[www.msdn/ssdt] http://blogs.msdn.com/b/ssdt/archive/2012/12/07/getting-started-with-sql-server-database-unit-testing-in-ssdt.aspx

[www.alm] http://www.ikanalm.com/alm/what-is-alm-20-.html

[www.intovsts] http://intovsts.net/

[www.visualstudioonline] https://msdn.microsoft.com/en-us/library/fda2bad5.aspx

http://www.biblioteca-digitala.ase.ro/biblioteca/carte2.asp?id=458&idb=

Bibliografie

J.Date – “ An introduction to Database Systems”, ed. Addison Wesley, 1994

I. Lungu, C. Bodea ș. a. – “Baze de date – organizare, proiectare și implementare “, ed. ALL, 1995

Jeff Tian. Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement. John Wiley and Sons, Inc., and IEEE Computer Society Press. 2005

https://support.office.com/ro-ro/article/No%C8%9Biuni-de-baz%C4%83-despre-proiectarea-bazelor-de-date-1eade2bf-e3a0-41b5-aee6-d2331f158280?ui=ro-RO&rs=ro-RO&ad=RO

http://ro.wikipedia.org/wiki/Baz%C4%83_de_date

https://msdn.microsoft.com/en-us/data/tools.aspx

https://msdn.microsoft.com/en-us/jj851226(v=vs.103).aspx#

[www.msdn/ssdt] http://blogs.msdn.com/b/ssdt/archive/2012/12/07/getting-started-with-sql-server-database-unit-testing-in-ssdt.aspx

[www.alm] http://www.ikanalm.com/alm/what-is-alm-20-.html

[www.intovsts] http://intovsts.net/

[www.visualstudioonline] https://msdn.microsoft.com/en-us/library/fda2bad5.aspx

http://www.biblioteca-digitala.ase.ro/biblioteca/carte2.asp?id=458&idb=