There are 4 levels of testing :
1. Unit Testing or Component Testing
2. Integration Testing ( Small & Large )
3. System Testing
4. Acceptance Testing (UAT – Alpha Testing, Beta Testing )
1. Unit / Component/Module Testing
1.Testing of individual software components(BS 7925 –1)
2.Also known as Unit testing, Module testing, Program testing
3.Searches for defects in, and verifies the functioning of software components(Programs, Objects, Classes, etc.)
4.Stubs ,drivers and simulators may be used
5.May include testing of functionality and specific non-functional characteristics such as memory leaks etc.
6.Also includes structural testing(e.g: branch coverage) with access to the code
7.Usually done by the programmer who wrote the code
8.Defects are typically fixed as soon as they are found, without formally recording incidents
9.Prepare and automate test cases (e.g.: J Unit)
10.BS 7925 –2 defines techniques for the design and measurement of component testing.
2. Integration Testing
“Testing performed to expose faults in the interfaces and in the interaction
between integrated components”.
Two Types:
A) Integration in the Small
B) Integration in the Large
Guidelines on selection of integration method
A) Integration Testing in the Small
Four approaches are there:-
- Top-down
- Bottom-up
- Big-bang
- Functional Incrementation Testing
Integration testing in the small
- more than one (tested) component
- communication between components
- what the set can perform that is not possible individually
- non-functional aspects if possible
- integration strategy: big-bang vs incremental (top-down, bottomup,
- functional)
- done by designers, analysts, or independent tester.
Big-Bang Integration
In theory:
1. If we have already tested components why not just combine them all
at once? Wouldn’t this save time? (based on false assumption of no faults)
In practice:
1. Takes longer to locate and fix faults
2. Re-testing after fixes more extensive
3. End result? takes more time
Top-down Testing
- Main Program is tested first
- Modules are integrated one at a time
- Major emphasis is on testing interfaces
- Interface errors are discovered early
- Test Stub’s are needed
- Errors in critical modules at low levels are found late
- Uses Depth-First approach
- Design errors detected early
“Stubs are used as passive subprograms to allow high level control routines to be
tested when low level component is unavailable”
Stubs
Stub (Baan: dummy sessions) replaces a called component for integration testing.
Keep it Simple
1. Print/display name (I have been called)
2. Reply to calling module (single value)
3. Computed reply (variety of values)
4. Prompt for reply from tester
5. Search list of replies
6. Provide timing delay
Pros & cons of top-down approach
Advantages:
1. Critical control structure tested first and most often
2. Can demonstrate system early (show working menus)
Disadvantages:
1. Needs stubs
2. Detail left until last
3. May be difficult to "see" detailed output (but should have been tested
in component test)
4. May look more finished than it is
Bottom-up Testing:
1. Tests low-level units first
2. Modules are integrated one at a time
3. Test Driver’s s are needed
4. Errors in critical modules at low levels are found early
5. Uses Breadth-First approach
6. Design errors discovered late
“Drivers are used to run low-level modules and to test the interfaces or links
between them”
Bottom-Up Integration
Drivers
1. Driver (Baan: dummy sessions): test harness: scaffolding
2. Specially written or general purpose (commercial tools)
3. Invoke baseline
4. Send any data baseline expects
5. Receive any data baseline produces (print)
6. Each baseline has different requirements from the test driving software
Pros & cons of bottom-up approach
Advantages:
1. Lowest levels tested first and most thoroughly (but
should have been tested in unit testing)
2. Good for testing interfaces to external environment
(hardware, network)
3. Visibility of detail
Disadvantages
4. No working system until last baseline
5. Needs both drivers and stubs
6. Major control problems found last
B) Integration testing in the large
1.Tests the completed system working in conjunction with other systems.
2. LAN / WAN, communications middleware
3. Other internal systems (billing, stock, personnel, overnight batch,
branch offices, other countries)
4. External systems (stock exchange, news, suppliers)
5. Intranet, internet / www
6. 3rd party packages
7. Electronic data interchange (EDI)
Approach
Identify risks
1. Which areas missing or malfunctioning would be most critical - test them first
“Divide and conquer”
2. Test the outside first (at the interface to your system, e.g. test a package on its own)
3. Test the connections one at a time first (your system and one other)
4. Combine incrementally - safer than “big bang”
(non-incremental)
3.System Testing (ST)
Last integration step , Testing the System based on what it is supposed to do
(Functional) and how well it is doing(Non-Functional)
Test - Two Types : Functional & Non-functional
A. Functional
1. Functional requirements and requirements-based testing
2. Business process-based testing
3. Functional testing considers the external behaviour of the software (BBT)
B. Non-functional (product characteristics / requirements include):
Security, Reliability, Usability, Installability, Recovery, Interoperability etc…
1. As important as functional requirements
2. Often poorly specified
3. Must be tested , often done by independent test group.
4. Acceptance Testing: (UAT)
1. “Formal testing conducted to enable a user, customer or other authorized entity to determine whether to accept a system or
component “
2. Acceptance testing is high on the V model , a counter part to the Requirement specification process
3. Final user sign-off.
4. User Acceptance Testing:
5. Testing conducted by and visible to customer
6. It is conducted at the final stage of Validation
7. Contract Acceptance Testing:
8. A demonstration of the acceptance criteria which would have beendefined in the contract being met.
Posts
0 comments:
Post a Comment