1. Programinės Įrangos Testavimo Strategijos
Parengė: Dmitrij Mamajev

2. Plan A strategic approach to testing
Test strategies for conventional software
Validation testing
System testing
Pirmiasia as papasakosiu apie Testavimo strategijos kurimo ypatumus.
Toliau papasakosiu kokios buna Testavimo strategijos, siek tiek detaliau.
Ir papasakosiu apie Validavimo testavima ir Systemos testavima.

3. Introduction
A strategy for software testing integrates the design of software test cases into a well-planned series of steps that result in successful development of the software
The strategy provides a road map that describes the steps to be taken, when, and how much effort, time, and resources will be required
The strategy incorporates test planning, test case design, test execution, and test result collection and evaluation
The strategy provides guidance for the practitioner and a set of milestones for the manager
Because of time pressures, progress must be measurable and problems must surface as early as possible
Testavimo strategija sujungia tarpusavyje skirtingus testavimo scenarijus į plana, kurio pagalba galima sukurti sekminga produkta.
Strategija tai yra kaip zemelapis arba kelias, kuris apraso arba parodo kokios priemones –veiklos reikalingos , kiek laiko, pastsngu ir resusrsu bus reikalinga tikslui pasiekti.
Strategija sujungiatestavimo planavima, testavimo scenariju kurima, testavimo vykdyma, rezultatu surinkim ir ju apdorojima.
Strategija padeda programuotojui sukurti gera produkta ir projekto vadovams sekti kurimo eiga, progressa.
Kadangi produktas turi būti pagamintas per tam tikra laika, tai jo kurimo progresas turi būti ismatuojamas, ir visos problemos turi būti sprendziamos kaip imanoma anksciau.

4. General Characteristics of Strategic Testing
To perform effective testing, a software team should conduct effective formal technical reviews
Testing begins at the component level and work outward toward the integration of the entire computer-based system
Different testing techniques are appropriate at different points in time
Testing is conducted by the developer of the software and (for large projects) by an independent test group
Testing and debugging are different activities, but debugging must be accommodated in any testing strategy
2. Pagrindinės testavimo strategijos kūrimo charakteristikos:
Testavimą galima apibrėžti kaip tam tikru veiksmu aibe, kuriuos galima iš anksto suplanuoti ir vykdyti sistemingai.
Todėl galima išskirti bendras charakteristikas arba bruožus kuriant testavimo strategija:
Kad testavimas butu efektyvus , PĮ kūrimo komanda prieš pradedant darbą turi susipažinti ir su dokumentų, kuris vadinasi formalus techninės apžvalgos dokumentas. Taip galima išvengti tam tikrų klaidų vystant produktą.
Formalus techn. apžvalgos dokumentas – tai tam tikrų reikalavimų apžvalgą, aprašanti koks bus busimo produkto tikslas, kur jis bus naudojamas ir nurodomas neatitikimus specifikacijoms ir/arba standartams.
Testavimas prasideda nuo mažu pavienių produkto moduliu- elementu testavimo ir pasibaigia kai visi elementai sujungti tarpusavyje i vieną didelė sistema.
Per visa PI kūrimo ciklą naudojamos skirtingos testavimo technikos arba strategijos.
Testavimui turi vadovauti programuotojas, dideliu projektu atveju vadovavimo role turėtu pereiti i nepriklausomo testuotojo rankas.
Nors testavimas ir derinimas yra skirtingos veiklos, bet derinimas yra neatsėjama testavimo dalys.

5. Verification and Validation
Software testing is part of a broader group of activities called verification and validation that are involved in software quality assurance
Verification (Are the algorithms coded correctly?)
The set of activities that ensure that software correctly implements a specific function or algorithm
Validation (Does it meet user requirements?)
The set of activities that ensure that the software that has been built is traceable to customer requirements
3. Taip pat reikėtu paminėti kad testavimas yra viena is sudedamuju Verifikavimo ir Validavimo procesu.
Kas prisimena kas yra validavimas ir kas yra verifikavimas?
Verifikavimas tai veiksmu aibe kurie turi uztikrinti ar PI tesingai veikia, t.y. ar teisingai veikia sukurtos f-jos ir algoritmai.
Validavimas – ar produktas atitinka uzsakovo reikalavimus.

6. A Strategy for Testing Conventional Software
Narrow to
Broader scope
Abstract to
concrete
4. Testavimo strategija galima butu įsivaizduoti kaip spiralė:
Pacioje pradzioje sukuriame –apibreziame PI role, tiksla.
Apibreziame PI funkcionaluma, elgsena, vykdymo nasumus, apribojjimai, validavimo kriterijai.
Sukuriamas dizainas
Vyksta programavimas.
Taigi siuo atveju mes judame nuo isuorinio sluoksnio i spireles vidu, ir taip sumaziname abstrakcijos lygi, kuris padetu atejus prie kodavimo tureti daugiau apibrezto, dokumentuoto aiskumo kaip mes darba turime programuoti.
Kitas budas pradeti nuo cento ir judeti preis isorinio spirales sluoksnio:
Unit testing – tai tam tikru pavieniu PI moduliu lelmentu testavimo vykdymas
Integracijos testavimas – kai sitie pavieniai moduliai sujungiami i tarpusavyje
Validavimo testavimas – kai visi pavieniai moduliai sujungti is pratestuoti, dabar testuojama ar sujungta sistema atitinka uzsakovo reikalavimus
Pilnas sistemos testavimas – kai sistema jungiama su išoriniais elementais ir vėl testuojama.

7. When is Testing Complete?
There is no definitive answer to this question
Every time a user executes the software, the program is being tested
Sadly, testing usually stops when a project is running out of time, money, or both
One approach is to divide the test results into various severity levels
Then consider testing to be complete when certain levels of errors no longer occur or have been repaired or eliminated
5. Kaip zinoti kada testavimas pasibaige?
I si klausima nera tikslaus atsakymo.
Kiekviena karta kai mes naudojame PI mes ja galima sakyti ir testuojame tuo paciu metu.
Vienas is variantu gali būti kad mes baigiame testavima kai neturime tam laiko arba pinigu.
Vienas is budu butu padalinti testavimo rezultatus i tam tikrus lygius, ir laikyti kad kai tam tikro lygio klaidos jau nepasirodo tai galima sakyti kad baigiame testavima.

8. Ensuring a Successful Software Test Strategy
Specify product requirements in a quantifiable manner long before testing commences
State testing objectives explicitly in measurable terms
Understand the user of the software (through use cases) and develop a profile for each user category
Develop a testing plan that emphasizes rapid cycle testing to get quick feedback to control quality levels and adjust the test strategy
Build robust software that is designed to test itself and can diagnose certain kinds of errors
Use effective formal technical reviews as a filter prior to testing to reduce the amount of testing required
Conduct formal technical reviews to assess the test strategy and test cases themselves
Develop a continuous improvement approach for the testing process through the gathering of metrics
6. Kaip pasirūpinti kad testavimo strategija butu sėkminga:
Prieš testavima reiketu pasirupinti kad butu aiskiai isdestyti produkto reikalavimai, kad juos galima butu ismatuoti.
Tiksliai ir aiškiai suformuluoti testavimo tikslus
Tureti supratima kas bus galutiniai produkto naudotojai, ir atitinkamai sukurti testavimo scenarijus kiekvienai vartotoju grupei atskirai.
Sukurti testavimo plana, kurio pagrindins akcentas butu „rapid cycle testing“- dažnai pasikartojantys testavimas. Tai leistu kontroliuoti kokybes lygi ir pagal poreiki keisti pasirinta tstavimo strategija.
Kurti aukstos kokybes PI kad ji galetu testuoti save pati.
Pries testavima susipazinti su techn apzvalgos dokumentu, kas turetu padeti isvengti nereikalingu klaidu.
Reiketu naudoti techn apzvalgos dokuementa, kuriant pacia testavimo strategija ir testus.
Sukurti plana, kurio tikslas butu pastoviai gerinti testavimo strategija, naudojant testavimo metrikas.

9. Unit Testing Focuses testing on the function or software module
Concentrates on the internal processing logic and data structures
Dabar siek tiek konkeciau apzvelgsime kiekviena is testavimo strategijos etapu.
7. Unit testing – tikslas yra atskiru funkciju ir atskiru moduliu testsavimas
Koncentuojames daugiau ties vidine logika ir duomenu struktura.

10. Integration Testing
Defined as a systematic technique for constructing the software architecture
At the same time integration is occurring, conduct tests to uncover errors associated with interfaces
Objective is to take unit tested modules and build a program structure based on the prescribed design
Two Approaches
Non-incremental Integration Testing
Incremental Integration Testing
8. Integracijos testavimas:
Galima apibrezti kaip sisteminga technika, taikoma konstruojant PI architektura.
Taip pat sio proceso metu vykdomi testai, kuriu tikslas interfeisu patikra.
Pagrindinis tikslas – panaudoti pavienius modulius ir sujungti juos i viena struktura, taikant tam tikra dizaina.
Yra Du Integracijos testavimo taikymo variantai:
Ne inkrementinis
Inkrementinis

11. Non-incremental Integration Testing
Commonly called the “Big Bang” approach
All components are combined in advance
The entire program is tested as a whole
Chaos results
Many seemingly-unrelated errors are encountered
Correction is difficult because isolation of causes is complicated
Once a set of errors are corrected, more errors occur, and testing appears to enter an endless loop
9. Neinkrimentinis Intrecijos testavimas dar vadinamas Dydziojo sprogimo kelias.
Visi komponentai jungiami iskart i viena struktura
Testuojama pilnai sujungta struktura
Rezultatai chaotiški
Apsunkintas klaidu koregavimas, nes sunku surasti identifikuoti klaidos priežastį.
Kai dalys klaidu pataisyta, tai atsiranda kitos klaidos ir taip toliau.

12. Incremental Integration Testing
Three kinds
Top-down integration
Bottom-up integration
Sandwich integration
The program is constructed and tested in small increments
Errors are easier to isolate and correct
Interfaces are more likely to be tested completely
A systematic test approach is applied
10. Inkrimentinis Integracijos testavimas:
yra trys tokio tipo testavimo budai:
Integracija Nuo virsaus i apacia
Integracija nuo apacios i virsu
„Sumustinio“ integracija
Produktas konstruojamas ir testuojamas prijungiant mazas daleles, elemntus, modulius.
Lengviau identifikuoti klaidu priezastis.
Galimybe pratestuoti visus interfeisus
Taikomas sistemingas testavimas, kas padeda isvengti klaidu dauginimosi procesa.

13. Regression Testing / Smoke Testing
Each new addition or change to baselined software may cause problems with functions that previously worked flawlessly
Regression testing re-executes a small subset of tests that have already been conducted.
Smoke Testing:
Preliminary testing to reveal simple failures severe enough to reject a prospective software release.
A subset of test cases that cover the most important functionality of a component or system is selected and run, to ascertain if crucial functions of a program correctly work.
"Does the program run?", "Does it open a window?", or "Does clicking the main button do anything?" 
Keleta zodziu apie Regresijos integracijos testavima ir „Dumu“ testavimo budus.
Tai regresijos testavimas gali būti tiakomas kai mes pridedame prie sistemos strukturos kazkoki viena arba kelis papildomus modulius , elementus. Tai padarome programos testvima kuri veike iki nauju modulio prisijungimo ir taip atrandame klaidas ir jas taisome.
Ir Dumo testavimo budas: tai kai sujungiami moduliai i tam tikrus klasterius, build‘us ir testuojami siu klasteriu pagrindines funkcijos.

14. Validation Testing Validation testing follows integration testing
The distinction between conventional and object-oriented software disappears
Focuses on user-visible actions and user-recognizable output from the system
Demonstrates conformity with requirements
Designed to ensure that
All functional requirements are satisfied
All behavioral characteristics are achieved
All performance requirements are attained
Documentation is correct
Usability and other requirements are met (e.g., transportability, compatibility, error recovery, maintainability)
After each validation test
The function or performance characteristic conforms to specification and is accepted
A deviation from specification is uncovered and a deficiency list is created
A configuration review or audit ensures that all elements of the software configuration have been properly developed, cataloged, and have the necessary detail for entering the support phase of the software life cycle
12. Validavimo testavimas prasideda po integracijos testavimo.
Koncenturojames ties galutiniam vartotojui matomu programos veikimo, ir kad sistemos veiklos rezultatas atitiktu uzsakovo –galution vartotojo reikalavimus.
Pagrindinis tikslas kad programine iranga atitiktu uzsakovo reikalavimus.
Validavimo testavimo turi patikrinti ir isitikinti kad :
Visi funkciniai reiklavaimai patenkinti
Visi elgsenos reikalavimai patenkinti
Visi efektyvumo reikalavimai
Dokumentacija yra teisinga
Panaudojamumo ir kiti reikalavimai patenkinti.
Po kiekvieno validavimo testo sudaromas sarasas:
Kokios funkcijos arba efektyvumas atitinka reikalavimus o kokius dar reiketu pakoreguoti.
Validavimo pabaigoje sudaromas konfiguracijos apzvalgos dokumentas, kuris uztikrina kad visi PI elementai yra teisingai suprogramuoti, surasyti, suruosiuoti ir turi visa reiklainga informacija kuri bus reikalinga PI palaikimui.

15. Alpha and Beta Testing Alpha testing Beta testing
Conducted at the developer’s site by end users
Software is used in a natural setting with developers watching intently
Testing is conducted in a controlled environment
Beta testing
Conducted at end-user sites
Developer is generally not present
It serves as a live application of the software in an environment that cannot be controlled by the developer
The end-user records all problems that are encountered and reports these to the developers at regular intervals
After beta testing is complete, software engineers make software modifications and prepare for release of the software product to the entire customer base
13. Validavimo procesus skirsto i du alfa ir beta etapus.
Tai Alfa testavimas – vykdomas pas progromuotoja, kai uzsakovas dirba su programine iranga ir programuotojas fiksuoja visus neatitikimus, kontroliuojamoje aplinkoje.
Beta testavimas: Kai PI testuojama pas uzsakova, nekontroliuojamoje aplinkoje. Ir uzsakovas sudaro pats netitikimu sarasa ir siuncia ji programuotojui.
Po Beta testavimo programuotjai paruose PI ir isledzia ja naudoti visiems galutinems vartotojams.

16. System Testing Recovery testing Security testing Stress testing
Tests for recovery from system faults
Forces the software to fail in a variety of ways and verifies that recovery is properly performed
Tests reinitialization, checkpointing mechanisms, data recovery, and restart for correctness
Security testing
Verifies that protection mechanisms built into a system will, in fact, protect it from improper access
Stress testing
Executes a system in a manner that demands resources in abnormal quantity, frequency, or volume
Performance testing
Tests the run-time performance of software within the context of an integrated system
Often coupled with stress testing and usually requires both hardware and software instrumentation
Can uncover situations that lead to degradation and possible system failure
Sistemos testavimas siek tiek iseina uz testavimo strategijos kurimo ribu. Nes ten jau gali atsirasti kitos nesusujosios su PI klaidos problemos. Bet visgi galima pamineti kad Sistemos testavimas apima daug skirtingu testu pvz veikimo atsinaujinimo testas, apsaugos testavimas, apkrovos testavimas, efektyvumo testavimas.
Veiklimo atsinaujimo testo metu: tikriname ar programa po kazkokio luzio, gali pati save initizalizuoti ir pradeti veikti be kokioi nors klaidu.
Apsaugos testavimas uztikrina kad niekas negali ilisti i programos vidu. Ir ja paveikti.
Apkrovos testavimas uztikrina kad prie tam tikru apkrovu programa turi veikti teisingai, kaip ji veike ir be apkrovos.
Efektyvumo –našumo testavimas, kartais naudojamas kartu su Apkrovos testavimu , toks testavimas turi užtikrinti kad programa veiktu efektyviai visada ir neluzinetu

17. AČIŪ !
Klausimai ?
Sistemos testavimas siek tiek iseina uz testavimo strategijos kurimo ribu. Nes ten jau gali atsirasti kitos nesusujosios su PI klaidos problemos. Bet visgi galima pamineti kad Sistemos testavimas apima daug skirtingu testu pvz veikimo atsinaujinimo testas, apsaugos testavimas, apkrovos testavimas, efektyvumo testavimas.
Veiklimo atsinaujimo testo metu: tikriname ar programa po kazkokio luzio, gali pati save initizalizuoti ir pradeti veikti be kokioi nors klaidu.
Apsaugos testavimas uztikrina kad niekas negali ilisti i programos vidu. Ir ja paveikti.
Apkrovos testavimas uztikrina kad prie tam tikru apkrovu programa turi veikti teisingai, kaip ji veike ir be apkrovos.
Efektyvumo –našumo testavimas, kartais naudojamas kartu su Apkrovos testavimu , toks testavimas turi užtikrinti kad programa veiktu efektyviai visada ir neluzinetu