Upload
diana-booker
View
213
Download
1
Embed Size (px)
Citation preview
UNIT 2TESTING TECHNIQUES
Testing begins with a proposal for software/system application development/maintenance and end with the system is formally accepted by the user/customer
Proposal Testing• A Proposal is made to the customer on the basis of
Request for Proposal(RFP) or Request for Quotation(RFQ)
• Any proposal prepared in response to such request is reviewed by organisation before sending it to the customer.
• Technical review –Technical feasibility, Overall approach
• Commercial Review- financial feasibility• Validation of Proposal – development of prototype or
proof of concept
Requirements Testing• Requirements creation involves gathering of
requirements and arranging them in a form to verify and validate them.
• Clarity• Complete• Measurable• Testable• Not Conflicting• Identifiable• Validation of Requirements – writing use cases
Design Testing
• The System Architect starts with system high level architectural designing
• Clarity• Complete• Traceable• Implementable• Testable• Validation of design – creation DFD, activity diagrams,
information flow diagram and state transition . Flow interrupted – design is not complete
Code Review
• Reviewing code files, databases, classes and methods.
• Clarity• Complete• Traceable• Maintainable
Unit Testing• Smallest part of a software system which is
testable• Individual units and components• Throwaway drivers and stubs• Debugger mode to find how variables are changed
during execution- not termed as Black box testing• Gray Box testing – code details with its functioning• Derived from use cases
Difference between Debugging and Testing
Debugging TestingCode checking to locate the cause of defect
Checks the defect
Code may be updated Corrections are not involved
Test cases are not defined Test cases are definedCover only positive cases Positive as well as
negative cases
Module Testing
• Many units come together and form a module• Stub/driver• This testing is done on related unit tested
components to find whether individually tested units can work together as a module or not.
• Test cases must be traceable
Integration Testing
• Integration testing involves integration of units to make a module of modules to make a system.
• The objective is to take unit tested components and build a program structure that has been dictated by design.
10
Bottom-Up TestingBegins construction and testing with atomic modules (lowest level in hierarchy)
drivers are replaced one at a drivers are replaced one at a time, "depth first"time, "depth first"
worker modules are grouped into worker modules are grouped into builds and integratedbuilds and integrated
AA
BB
CC
DD EE
FF GG
clustercluster
• Bottom up approach is Suitable for• Object Oriented design.• Low level ComponentsStubs/Drivers:These are Special Purpose arrangements to test
the units individuallyStub: A Piece of Code emulating a called functionDriver: A piece of code emulating a calling function
• Advantages• Tested first for its correctness and if is working
correctly, then only it goes for further integration• Robust• Incremental Integration testing- Individual
components are tested• Disadvantages• Top level components are more important which is
tested at the last