Softwareengineering-5-3-Testing_conven_softw.pptx
- 1. SOFTWARE ENGINEERING Module 5 - Part 3 TEST STRATEGIES FOR CONVENTIONAL SOFTWARE
- 2. Overview ● Test Strategies For Conventional Software ● Unit Testing ● Integration Testing ● Regression Testing ● Smoke Testing ● Validation Testing ● System Testing ● Black Box Testing ● White Box Testing
- 3. Test Strategies For Conventional Software The testing strategy begins with testing of individual units, then by testing integration of these units and finally tests on the fully constructed system. Unit Testing ● Focus on the smallest unit of software design, i.e module or software component. ● Based on component-level design the internal processing logic and data structures within components are tested. Unit Test Considerations ● Module interface tested to check proper data flow in and out. ● Tests whether local data structures maintain data integrity. ● All control paths of execution tested. ● Boundary conditions are checked. ● Error handling paths are executed and tested.
- 4. Unit Test Procedures • Test cases and expected test results are outlined. • Drivers and stubs are introduced for eligible units. • Drivers act as main program, accepts test cases and passes to unit to be tested, also prints result. • Stubs act as subordinate modules with which unit under test communicates. • Components/units with high cohesion makes unit testing easier and lowers the overhead of creating sophisticated stubs.
- 5. Integration Testing • Through integration testing we systematically build whole software architecture while testing to uncover interfacing errors. • In big bang approach all components are combined and tested as whole. Here, error correction is difficult. • In incremental integration testing is done in small increments after adding one or more components. • Incremental integration can be top-down or bottom-up integration. Top-down integration Beginning with main control moves downward by adding subordinate modules. Can use depth-first or breadth first technique. Depth first integration moves vertically to the depth, components M1, M2, M5 then M8 or M6 as demanded by M2 is added. Breadth first integration moves horizontally through each level, after M1, components M2, M3 and M4 then M5, M6, M7 are added. Steps : 1. Main control used as test driver and stubs are placed as subordinate modules. 2. Stubs replaced by actual modules based on depth first or breadth first integration. 3. Tests take place as each module is integrated. 4. Another stub is replaced and testing is done 5. Regression testing may be conducted.
- 6. Bottom up integration Begins at atomic modules in lower level and moves upward to main control. Steps : •Low level components combined to form clusters(builds). •Driver placed atop to coordinate test cases. •Cluster is tested. •Drivers are removed and clusters are combined.
- 7. Regression Testing Integrating new module introduces new control logic, data flow paths and i/o functions. This may cause problems to parts that worked correctly before. Therefore, regression testing re-executes subset of tests that have already been done to ensure proper functioning of all components. Different classes of test cases in Regression Test Suite : • Test cases that checks all software functions. • On functions that are likely to be affected by change. • On components that have been just changed or added.
- 8. Smoke Testing • Tests only main functionalities of a component to determine whether it works properly. • To reveal severe errors which affect the further development of intended software. Steps : • Components integrated to form builds. • Tests builds to uncover only show-stopper errors. • If tests are passed, the build is integrated with other builds and are smoke tested frequently. Benefits: Integration risk minimized Quality of end product improved Error diagnosis and correction simplified Progress is easier to assess.
- 9. Validation Testing • Begins at the conclusion of integration testing when individual components have been tested, software completely assembled as a package, and interfacing errors have been uncovered and corrected. • Focuses on user-visible actions and user-recognizable output from the system. Validation-Test Criteria Test cases that are designed to ensure • all functional requirements and behavioral characteristics are achieved, • content is accurate • all performance requirements are attained After each test case one of two possible conditions exist: • The performance characteristic conforms to specification and is accepted. • A deviation from the specification is uncovered and a deficiency list is created. Configuration Review : • An important element of validation process to ensure that all elements of the software configuration have been properly developed. It is also known as audit.
- 10. validation testing cont… Acceptance Testing : • Customer validates all requirements. • Conducted by the end user rather than software engineers, an acceptance test can range from an informal “test drive” to a planned and systematically executed series of tests. It can span over a number of weeks or months. Alpha and Beta Testing : • Alpha tests are conducted at developer’s site by a group of end users with the developer “looking over the shoulder” of the users by recording errors and usage problems. They are conducted in a controlled environment. • Beta test is conducted at one or more end-user sites, developer is not present and environment is not controlled by developer. Users record problems and report to the developer who makes modifications and release software to the customer base.
- 11. System Testing At its final stage a software is incorporated with other system elements such as hardware, people and information and is usually carried out by a team that is independent of the development team. It includes :- Recovery Testing Tests that forces a system to fail in a variety of ways to verify recovery is performed properly. Security Testing Tests whether protection mechanism built in fact protects the system from improper penetration. Stress Testing Tests system under conditions where it demands resources in abnormal quantity or volume. Performance Testing Tests run-time performance and is often coupled with stress testing. Deployment Testing/Configuration Testing Exercise software in environments in which it is supposed to operate and also examines installation procedures and documentation.
- 12. Black Box Testing • Also known as Behavioural Testing, is based on testing without knowing the internal implementation/structure of the component being tested. • Mainly focuses on functional requirements and also consider non-functional requirements to small level. • It is done to find errors such as : o Incorrect/missing functions o Interface errors o Data structure / external database errors o Behaviour / performance errors o Initialization / termination errors • Applied in Integration Testing, System Testing, Acceptance Testing Techniques Equivalence partitioning Divides input values into classes of data from which test cases are derived. These equivalence classes contain valid and invalid partitions of the input conditions. Boundary Value Analysis Here test data is selected from boundaries or edges of input domain. The values at the boundary, and just above and below, or adjacent are taken. Graph Based Testing Cause effect graphing involves building a graph based on the causes and effect, i.e., input and output conditions and deriving test cases to cover the graph and find errors.
- 13. White Box Testing • Other names, Glass-Box testing, Code-Based/Structural testing, Clear-Box/Transparent-Box/Open-Box Testing. • Internal structure is known, all program based logic paths are covered. • Test cases are derived to ensure : o All independent paths within the component is covered o True/False logic decisions are exercised o Loops are tested over their input domain and boundary conditions o Examine internal data structures for validity • Applied in Unit Testing, Integration Testing, System Testing. Techniques Basis Path Testing A logical complexity measure can be derived from these technique which acts as a basis to define independent logical paths in a module. It is done with the help of flow graph notations and then deriving paths from them and eventually test cases. Control Structure Testing It includes condition testing, data flow testing, loop testing