Differences
This shows you the differences between two versions of the page.
|
mps:laboratoare:laborator-09 [2019/11/20 10:43] iulia.stanica [Exerciții (50 min)] |
mps:laboratoare:laborator-09 [2022/12/13 11:18] (current) iulia.stanica [Test Cases] |
||
|---|---|---|---|
| Line 248: | Line 248: | ||
| == Stubs == | == Stubs == | ||
| - | O problemă des întâlnită în testarea proiectelor este testarea unei părți a proiectului înainte ca alte părți să fie gata. Se pot folosi pentru asta interfețe, numite **Stubs**, care simulează funcțiile de bază ale obiectului respectiv fără să efectueze și teste de integritate a datelor sau ale fluxului logic al problemei. Ele sunt des folosite în cursul dezvoltării unităților proiectului care depind de obiectul simulat. | + | O problemă des întâlnită în testarea proiectelor este testarea unei părți a proiectului înainte ca alte părți să fie gata. Se pot folosi pentru asta interfețe, numite **Stubs**, care simulează funcțiile de bază ale obiectului respectiv fără să efectueze și teste de integritate a datelor sau ale fluxului logic al problemei. Ele sunt des folosite în cursul dezvoltării unităților proiectului care depind de obiectul simulat. Accentul este pus pe verificarea răspunsului dorit / schimbării de stare. |
| == Mockup == | == Mockup == | ||
| - | **Mockups** sunt tot implementarea unor interfețe care testează mai aprofundat funcțiile necesare. Ele simulează spre exemplu funcționarea unui server pentru a putea testa facilitățile clientului și testează de asemenea autentificarea clientului înainte ca acesta să poată efectua anumite tranzacții. Pentru o utilizare mai facilă se recomandă folosirea interfețelor și utilizarea lor în funcția de testare. O implementare pentru testare este o implementare care conține numai cod de test și imită cât mai bine funcționarea viitorului obiect. Mockup-urile sunt utile în multe situații precum: | + | **Mockups** sunt tot implementarea unor interfețe care testează mai aprofundat funcțiile necesare. Ele simulează spre exemplu funcționarea unui server pentru a putea testa facilitățile clientului și testează de asemenea autentificarea clientului înainte ca acesta să poată efectua anumite tranzacții. Pentru o utilizare mai facilă se recomandă folosirea interfețelor și utilizarea lor în funcția de testare. O implementare pentru testare este o implementare care conține numai cod de test și imită cât mai bine funcționarea viitorului obiect. Accentul este pus pe verificarea comportamentului. Mockup-urile sunt utile în multe situații precum: |
| * cazul când obiectul în sine nu există | * cazul când obiectul în sine nu există | ||
| * obiectul real/funcția reală ia foarte mult timp să ruleze | * obiectul real/funcția reală ia foarte mult timp să ruleze | ||
| Line 529: | Line 529: | ||
| Un exemplu complet de chestionar găsiți [[http://michaelgreer.biz/?p=161|aici]] | Un exemplu complet de chestionar găsiți [[http://michaelgreer.biz/?p=161|aici]] | ||
| - | =====Exerciții (50 min)===== | + | ==== Bibliografie ==== |
| - | Raspundeti la urmatoarele intrebari: | + | * http://www.sqatester.com/methodology/PositiveandNegativeTesting.htm |
| - | - Se da urmatorul patch: [[https://curl.haxx.se/CVE-2016-8616.patch|patch]]. Precizati: | + | * http://www.opensourcetesting.org/testmgt.php |
| - | * cate modificari s-au facut? | + | * http://www.sqatester.com/documentation/testcasesmpl.htm |
| - | * cate fisiere au fost modificate? | + | * http://www.computerhistory.org/tdih/September/9/ |
| - | * ce bug ar putea rezolva acest patch? | + | |
| - | * cum ati testa acest fix? | + | |
| - | - Ganditi-va la platforma vmchecker. | + | |
| - | * ce fel de testare face: Boundary testing / Black Box Testing? | + | |
| - | * argumentati si exemplificati | + | |
| - | * Dar dintre urmatoarele: Stubs / Mockups / Regression testing? | + | |
| - | * argumentati si exemplificati | + | |
| - | - Ce fel de testare este ilustrata [[http://i.imgur.com/KHaCdxA.png|aici]] ? | + | |
| - | - **[Bonus]** De unde vine denumirea de bug? | + | |
| - | **Nota**: fiecare subpunct valoareaza un punct, se acorda un punct pentru prezenta. Punctajul total aferent laboratorului curent este de **11p**. | + | |
| + | =====Exerciții (50 min)===== | ||
| + | |||
| + | - Se dau următorul patch: [[https://curl.haxx.se/CVE-2016-8616.patch|patch]] și următorul tweet: [[https://i.imgur.com/KHaCdxA.png|tweet]]. Studiati-le timp de 5 minute. Vor fi importante pentru testul nostru [[https://kahoot.com/schools-u/|Kahoot]] :) | ||
| + | **Nota**: fiecare răspuns corect valorează un punct, se acordă un punct pentru prezență. Punctajul total aferent laboratorului curent este de **11p**. | ||
| <hidden> | <hidden> | ||
| - | Rezolvari: | ||
| - | - 3 modificari (se vad in 3 locuri --/++), un singur fisier afectat. Bug: functie pasibila de erori la verificare username si parola (context: calcula un hash si il verifica sa semene cu unul existent din memorie, insa functia aia existenta nu era case-sensitive. | ||
| - | - Black box - evident (considera tema trimisa ca un black box si ruleaza testele). Poate si si Boundry acceptat, daca se aduce ca exemplu o tema precum tema 0 de la SO, care verifica sa ruleze tema si pe o lista vida de cuvinte. Sigur nu Regression. Stabs este corect. Se accepta exemple precum o tema care verifica functionalitatile pas cu pas (tema 3 la SO). Si Mockups e un raspuns corect: anumite functionalitati din checker sunt mimate/emulate (exeplu: tema 1 la Protocoale de Comunicatie). | ||
| - | - Boundry testing | ||
| - | - Vezi ultimul link de la bibliografie. Special am pus bilbiografia dupa exercitii in aceeasi sectiune din lab (sa vedem daca au inspiratia sa se uite acolo). | ||
| - | </hidden> | ||
| - | - Descrieți sumar conțintul unui SQAP pentru proiectul vostru. | + | Link Kahoot: [[https://create.kahoot.it/v2/share/mps-lab-9-testare/7094976f-b95e-4841-af8b-c4f08e6d7f12|Kahoot]] |
| - | * Parcurgeți secțiunea [[https://ocw.cs.pub.ro/courses/mps/laboratoare/laborator-09#sqap_software_quality_assurance_plan|Software Quality Assurance Plan]] | + | |
| - | - Pregătiți un checklist pentru terminarea proiectului vostru. Argumentați! | + | |
| - | * Parcurgeți secțiunea [[https://ocw.cs.pub.ro/courses/mps/laboratoare/laborator-09#terminarea_unui_proiect_10_min|Terminarea unui proiect]] | + | |
| - | - Răspundeți la întrebările de la procesul PPA pentru proiectul vostru. | + | |
| - | * Parcurgeți secțiunea [[https://ocw.cs.pub.ro/courses/mps/laboratoare/laborator-09#post-performance_analysis_ppa_10_min|Post-Performance Analysis]] | + | |
| - | ==== Bibliografie ==== | + | - Câte modificări s-au făcut în acest patch? |
| + | - Câte fișiere au fost modificate de patch? | ||
| + | - Ce bug ar putea rezolva acest patch? | ||
| + | - Ce fel de testare realizeaza platforma VMChecker: Boundary testing / White Box / Black Box Testing / Regression? | ||
| + | - Ce fel de testare este ilustrata [[http://i.imgur.com/KHaCdxA.png|aici]] ? | ||
| + | - Modificarea unei linii de cod din "a++" in "a+=2" pentru a vedea efectele survenite constituie un exemplu de: Regression / Black box / Stubs / Fault injection. | ||
| + | - NU permite managementul bug-urilor urmatorul program: GitHub, diff, Bugzilla, Trac. | ||
| + | - Care este diferența dintre "regression testing" și "re-testare"? | ||
| + | - Alegeți afirmația corectă referitoare la costul fixării unui defect / bug: scade / creste odată cu apropierea de data lansării / nu este important / nu poate fi determinat. | ||
| + | |||
| + | **[Bonus]** - (10) De unde vine denumirea de bug? | ||
| - | * http://www.sqatester.com/methodology/PositiveandNegativeTesting.htm | + | Rezolvari: |
| - | * http://www.opensourcetesting.org/testmgt.php | + | - 3 modificari (se vad in 3 locuri --/++) |
| - | * http://www.sqatester.com/documentation/testcasesmpl.htm | + | - un singur fisier afectat. |
| - | * http://www.computerhistory.org/tdih/September/9/ | + | - Bug: functie pasibila de erori la verificare username si parola (context: calcula un hash si il verifica sa semene cu unul existent din memorie, insa functia aia existenta nu era case-sensitive). |
| + | - Black box - evident (considera tema trimisa ca un black box si ruleaza testele). Poate si Boundary acceptat, daca se aduce ca exemplu o tema precum tema 0 de la SO, care verifica sa ruleze tema si pe o lista vida de cuvinte. Sigur nu Regression. | ||
| + | - Boundary testing | ||
| + | - Fault injection | ||
| + | - diff | ||
| + | - Re-testarea = repetarea unui test; regression = cautarea de efecte nedorite aparute odata cu avansarea in dezvoltare | ||
| + | - Crește odată cu apropierea de data lansării | ||
| + | - Vezi ultimul link de la bibliografie. Special am pus bilbiografia dupa exercitii in aceeasi sectiune din lab (sa vedem daca au inspiratia sa se uite acolo) - molie blocata in computer. | ||
| + | </hidden> | ||
| + | |||
| + | | ||
| ===== Lucru la proiect (50 min)===== | ===== Lucru la proiect (50 min)===== | ||
| + | - Descrieți sumar conținutul unui SQAP pentru proiectul vostru. | ||
| + | * Parcurgeți secțiunea [[https://ocw.cs.pub.ro/courses/mps/laboratoare/laborator-09#sqap_software_quality_assurance_plan|Software Quality Assurance Plan]] | ||
| + | - Pregătiți un checklist pentru terminarea proiectului vostru. Argumentați! | ||
| + | * Parcurgeți secțiunea Terminarea unui proiect | ||
| + | - Răspundeți la întrebările de la procesul PPA pentru proiectul vostru. | ||
| + | * Parcurgeți secțiunea Post-Performance Analysis. | ||
| + | |||
| Stabiliti ce mai aveti de facut pentru finalizarea proiectelor. | Stabiliti ce mai aveti de facut pentru finalizarea proiectelor. | ||
