1 / 35

L evels of Software Testing

L evels of Software Testing. Test Level (1/3)‏. Definition : A package of testing to organize and manage at a time (one to one correspondence between testing and development phases). Levels of testing Unit (Component) test Integration test System test Acceptance test. Test Level (2/3)‏.

kina
Download Presentation

L evels of Software Testing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Levels of Software Testing

  2. Test Level (1/3)‏ • Definition : A package of testing to organize and manage at a time (one to one correspondence between testing and development phases). • Levels of testing • Unit (Component) test • Integration test • System test • Acceptance test

  3. Test Level (2/3)‏ • Feature • Independent planning activity (Separate planning). • Independent test design, execution, completion (evalution of criterion), reporting and test closure activity. • Independent test team (organization), independent environment • The distinguishable contents in each test level seperately • The existance of general goal (purpose) in each test level • The input product of development which is referenced to design test case (test basis)‏ • Test target (something tested)‏ • The need of test harness (driver) and tool supporting • Spcecific testing approach and responsibilty.

  4. The characteristics of each test level

  5. Unit Testing Test Level

  6. Unit Testing • Test one software unit whether it shows functional execution properly. • Test each software unit (module, component) in isolation without the consideration of connection (interface) with other parts • Test targets could be source codes and main tesing technique is white box • Verify functionality described in design document by unit program • If necessary, it could be executed by the other developer or 3rd person rather than own developer

  7. Unit Testing (2)‏ • Objectives • Verifies the functioning of software that are seperately testable • Non-functional characteristics (i.e memory leaks)‏ • Robustness testing • Verifies error tolerance • Verifies interface within module • Verifies local data, boundary values

  8. Unit Testing (3)‏ • Unit testing design techniques • Test cases are devided from work products such as a specification of component, the software design or data model • Control Flow test, elementary comparison test (Condision/Decision coverage), Equivalene Test, Boundary Value Analysis

  9. Unit Testing (4)‏ • Exit Criteria for unit test • The integrator decide when the entry criteria for integration test satisfy • Test coverage which is planned at unit test plan • Specific test design technique used • Decide through reviews of unit test cases and test result • Developer decide (general practice)‏

  10. Test Coverage • The extent that a structure has been exercised by a test suite, expressed as a percentage of the items being covered. • To measure thoroughness of testing • If coverage is not 100%, then more test may be designed to test those items that were missed and therefore increase coverage.

  11. Test Coverage (ctd)‏ • Classification of Coverage • Structure based : Statement coverage, Branch coverage, condition coverage, Path coverage • Extension : Requirement coverage, Functional Coverage, Entry/Exit coverage.

  12. Design Technique - Control Flow Test IF age < 13 yr OR ID already used THEN error message ELSE IF age <25 yr AND usage time per day < 3 hr THEN fee :=50 ELSE fee := 100 IF subscription period < 2 mth OR (subscription period <=5 mth AND unpaid fee >=200) OR no feedback = Y THEN raise fee 200

  13. 1 2 D1 D1 : age < 13 yr. OR ID already used D2 : age <25 yr. AND usage time per day < 3 hr. D3 : subscription period < 2 mth. OR (subs. period <=5 AND unpaid fee >= 200) OR no feedback == Y 3 4 5 D2 6 D3 8 7

  14. Design Technique - Control Flow Test • Test case example – 100% decision coverage? • TC1 : 1,2 • TC2 : 1,3,4,7 • TC3 : 1,3,5,8 • Make combinations of input and output actions of each Decision Point • Additional Test Cases for Depth Level 2 • TC4 : 1,3,4,8 • TC5 : 1,3,5,7

  15. Design Technique - Control Flow Test • Making Test Script • TCid • Input Action (1,2) : choose specific value for each path • Expected output : write specific action or value to verify output result

  16. CFT : Excercise Begin int x, y, power; float z; input(x,y); if (y<0) power=(-y); else power=y; z=1; while (power!=0){ power = power -1; } if (y<0) z= 1/z; output(z); End

  17. Integration Testing Test Level

  18. Integration Testing • Designed to verify interface among the system components • Integration testing tests interfaces between components, interactions with different parts of a system, such as the OS, FS, h/ware • Component integration testing test the interactions between software components and is done after component testing • There may be more than one level of integration testing.

  19. Approach of Integration Testing • Classification of Approach of Integration Testing • Big Bang integration • Bottom up integration • Top down integration • Backbone integration • Central, Collaboration, Layer, C/S integration

  20. Approach of Integration Testing

  21. System Testing • To verify behavior of a whole system/product as defined by the scope of a development project or program • In system testing, the test environment should correspond to the final production environment as much as possible – environment specific minimize risk of failure • System testing investigate both functional and non functional requirements of a system • Effective system testing needs to be executed without unit or integration defects • Testers need to deal with incomplete or undocumented requirements

  22. System Testing – Test Basis • Requirement Specifications • Requirement can be written in text or model • Incomplete requirements are common • Result of Risk Analysis • Business Process • Use Case • High Level descriptions of system behavior • Interactions with OS and system resource

  23. System Testing (ctd.)‏ • System testing investigate both functional and non-functional requirements of system. • Functional Requirement Test • Specification-Based (black box) decision table • Security test : to detect threat from outside • Non-functional Requirement test • Structure based techniques – to assess the thoroughness of menu structure or web page navigation • Performance test, usability test, reliability test etc

  24. Acceptence Testing Test Level

  25. Acceptance Testing • Acceptance testing is often the responsibility of the customer or users of a SUT; other stakeholders may involved as well. • The customers will decide that they will accept the system or program through the Acceptance Test Result

  26. Acceptance Testing • Goal • To establish confidence in the system about (Non)Functional characteristics (finding defect is not the main focus)‏ • To assess the system's readiness for deployment and use • It is not necessarily the final level of testing • Acceptance testing may occur as more that just a single test level • A COTS software product may be acceptance tested when it is installed or integrated • Usability of a component may be done during component testing • A new functional enhancement may come before system testing.

  27. Acceptance Testing • Typical forms of acceptance test • User acceptance testing • Operational (acceptance testing)‏ • Testing of backup/restore, disaster recovery, user management, maintenance task, periodic checks of security vulnerabilities • Contract and regulation acceptance testing • Acceptance criteria should be defined when the contract is agreed • Regulation acceptance testing is performed against any regulations that must be adhered to, such as governmental, legal or safety regulations • Alpha Testing & Beta Testing • Factory acceptance testing (alpha) and site acceptance testing (beta)‏

  28. Type of Testing

  29. Test Types • Functional Testing • Functional testing considers the external behavior of the software(black box testing)‏ • Non-Functional Testing • It is testing of “how” the system works. Such as performance testing, usability testing etc (ISO/IEC9126)‏ • Structural Testing • It may be based on the architecture of software or the system • Confirmation Testing and regression testing • After modification, to confirm that the original defect has been successfully removed and to discover any defects introduced or uncovered as a result of the change(s).

  30. Functional Testing • Test basis • Process flow model • State transition model • Use case model • Plain language specification • May be performed at all test levels • Specification-based technique

  31. Non-Functional Testing • Testing of software product characteristics • Non-functional testing may be performed at all test levels • The test required to measure characteristics of system and software that can be quantified on a varying scale • Quality Model ISO/IEC9126 “Software Engineering – Software Product Quality”

  32. Structural Testing • To help measure the thoroughness of testing assessment of coverage of a type of structure • Coverage : the extent that a structure has been exercised by a test suite, expressed as a percentage of the items being covered • Available Test Basis • Control Flow model, menu structure model • To be performed at all test levels • Program call tree structure may be based on the architecture of the system (calling hierarchy) for system testing level • Business models or menu structures for Acceptance or System integration testing levels)‏

  33. Regression Testing • After modification, to discover any defects introduced or uncovered as a result of the changes • These defects may be either in the SUT, or in another related or unrelated software component • It is performed when the software or its environment is changed • The extent of regression testing is based on the risk of not finding defects in software that was working previously (impact analysis)‏ • It may be performed at all test levels and applies to functional, non-functional and structural test • Regression testing is strong candidate for automation because it runs many times.

  34. Maintenance Testing • Be triggered by modifications, mitigation or retirement of the software or system on an existing operational system • Modification • Planned enhancement changes (i.e. release based), corrective and emergency change and changes of environment (i.e upgrade or patches for OS/DBMS)‏ • Maintenance testing for migration • Operational test of the new environment as well as of the changed software • Maintenance testing for retirement of a system • Data migration testing • Data archiving testing

  35. Maintenance Testing • Regression Test is emphasized in maintenance testing after impact analysis of changes • The scope of maintenance testing • related to the change, size of the existing system and size of change • Depending on the changes, testing may be done at any levels and for any test types

More Related