Software Verification & Validation
Download as PPT, PDF2 likes5,398 views
The document discusses verification and validation (V&V) in software engineering. It defines verification as ensuring a product is built correctly, and validation as ensuring the right product is built. V&V aims to discover defects and assess if a system is usable. Static and dynamic verification methods are covered, including inspections, testing, and automated analysis. The document outlines V&V goals, the debugging process, V-model development, test planning, and inspection techniques.
![©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 10
The structure of a software test plan
The testing process.
Requirements traceability.
Tested items.
Testing schedule.
Test recording procedures.[Jing, bugzilla etc]
Hardware and software requirements.
Constraints.
We will do usability and functionality testing and make test cases
• learning assignment (non-graded)
• My test cases: http://jmp.sh/J0KW3Vz](https://image.slidesharecdn.com/lect6softwareverificationvalidation-150506130545-conversion-gate01/85/Software-Verification-Validation-10-320.jpg)
Software Verification & Validation
- 1. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1 Verification and Validation Thanks to Ian Sommerville for his consent to use his slides for academic purposes Inam Ul Haq Lecturer in Computer Science University of Education Okara [email protected], [email protected]
- 2. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 2 Verification and validation planning Software inspections Automated static analysis Topics covered
- 3. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 3 Verification: "Are we building the product right”. The software should conform to its specification. Validation: "Are we building the right product”. It ensures that software meets customer’s expectations. Verification vs validation
- 4. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 4 Is a whole life-cycle process - V & V must be applied at each stage in the software process. Has two principal objectives • The discovery of defects in a system; • The assessment of whether or not the system is useable in an operational situation. The V & V process
- 5. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 5 V& V goals V & Validation should confirm that the software is fit for purpose. This does NOT mean completely free of defects. Rather, it must be good enough for its intended use.
- 6. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 6 Static Verification • inspect program code for all possible run-time behaviors and seek out coding flaws, back doors, and potentially malicious code. • Code reviews, walkthroughs, or inspections are referred to as static testing • Static code analysis tools: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis Dynamic Verification • It monitors system memory, functional behavior, response time, and overall performance of the system • The system can also be executed with test cases • While static and dynamic analysis can be performed manually & they can also be automated (load-runner). • Testing types: http://www.softwaretestinghelp.com/types-of-software-testing/ Static and dynamic verification
- 7. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 7 Defect testing and debugging are distinct processes. Verification and validation is concerned with establishing the existence of defects in a program. Debugging is concerned with locating and repairing these errors. Debugging involves formulating a hypothesis about program behaviour then testing these hypotheses to find the system error. • Sort of test cases Testing and debugging
- 8. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 8 The debugging process Locate error Design error repair Repair error Retest program Test results Specification Test cases
- 9. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 9 The V-model of development System specification System design Detailed design Module and unit code and test Sub-system integ ration test plan System integration test plan Acceptance test plan Service Acceptance test System integ ration test Sub-system integ ration test Requir ements specification
- 10. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 10 The structure of a software test plan The testing process. Requirements traceability. Tested items. Testing schedule. Test recording procedures.[Jing, bugzilla etc] Hardware and software requirements. Constraints. We will do usability and functionality testing and make test cases • learning assignment (non-graded) • My test cases: http://jmp.sh/J0KW3Vz
- 11. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 11 The software test plan
- 12. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 12 Inspection checklists Checklist of common errors should be used to drive the inspection. Error checklists are programming language dependent and reflect the characteristic errors that are likely to arise in the language. In general, the 'weaker' the type checking, the larger the checklist. Examples: Initialisation, Constant naming, loop termination, array bounds, etc.
- 13. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 13 Inspection checks 1 (self)
- 14. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 14 Inspection checks 2 (self)
- 15. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 15 Inspection rate 500 statements/hour during overview. 125 source statement/hour during individual preparation. 90-125 statements/hour can be inspected. Inspection is therefore an expensive process. Inspecting 500 lines costs about 40 man/hours effort - about £2800 at UK rates.