SE 5 3 Testing Conven Softw

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 13

SOFTWARE

ENGINEERING
Module 5 - Part 3

TEST STRATEGIES FOR CONVENTIONAL


SOFTWARE
● Test Strategies For Conventional Software
● Unit Testing
● Integration Testing
● Regression Testing
Overview ● Smoke Testing
● Validation Testing
● System Testing
● Black Box Testing
● White Box Testing
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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

You might also like