Software Testing Flashcards
Defect Testing
Involves testing programs to establish presence of defects.
Component Testing
Testing individual program components, usually the responsibility of the component developer.
Integration Testing
Testing of the groups of components integrated to create a system or sub-system, with the responsibility of this falling upon the independent testing team.
Exhaustive Testing
Only way to show a program is free of defects, but exhaustive testing is impossible.
Test Data
Inputted to test the system.
Test Cases
Inputted to test the system, wit predefined outcomes which the system should abide by.
Black-box Testing
Program is tested with no inside knowledge.
Program is considered as a black box, and it tested specifically on system specifications.
Equivalence Partitioning
Input data and outputs often fall into different classes where all members of a class are related.
Each class is an equivalence partition where the program behaves in a similar fashion.
Test cases should be chosen from each partition to account for all behaviours.
Equivalence Sets (Equivalence Partitioning)
Equivalence sets are essentially the partitions of the inputs and outputs, and normally contain some sort of range.
For example, we could have a specific range of inputs which behave similarly. Lets say we could have the inputs as integers, between numbers 1 - 100.
Choosing numbers at the very end of these scales typically are more likely to result inn erroneous behaviours, like 0, 1, 100, 101, 99 etc, and they should be chosen as test cases.
An example can be an email, where inputs with @ are valid inputs and inputs without it are invalid.
Search Routines
Typical search routines include:
- Inputs which conform to the pre-conditions.
- Inputs where a pre-condition does not hold.
- Inputs where the key element is a member of the array.
- Inputs where the key element is not a member of the array.
Testing Guidelines
Testing guidelines typically include:
- Test software with sequences which have only a single value.
- Use sequences of different sizes in different tests.
- Derive tests so that the first, middle and last elements of the sequence are accessed.
- Test with sequences of zero length.
Structural Testing / White-box Testing
Derives test cases according to the program structure.
Inside knowledge is known.
Detailed report is given at the end.
Binary Searching
Type of white-box testing, which is checking for the specifics of arrays to check if the internal workings of these arrays are as to be expected.
Path Testing
Ensures that the set of test cases is such that each path through the program is executed at least once.
The starting point for path testing is a program graph that shows nodes representing the program’s decisions, and arcs representing the flow of control.
Statements with conditions are nodes in the flow graph.
Program Flow Graphs
Describe the program control flow, with each branch shown a separate path and loops shown by arrows looping back to the loop condition node.
Cyclomatic Complexity
The cyclomatic complexity is the number of tests to test all control statements.
In other words, it equals the number of conditions in a program plus one.
Independent Paths
All node paths in a graph.
Integration Testing
Test complete systems or sub-systems composed of integrated components.
Integration testing should be black box testing with tests derived from specifications.
Incremental Integration Testing
Increase test cases every test sequence.
Uses the idea of regression testing, in which future tests also test previous test cases, making sure that adding new modules does not break any of the tests.
Testing Harness
Program that automatically generates test data and records their results.
Top-down Testing
Start with high-level system and integrate from the top-down, replacing individual components by stubs where appropriate.
Bottom-up Testing
Integrate individual components in levels until entire system is created.
Bottom-up Testing is more appropriate for…
- Object-orientated systems -> neat decomposition into classes and methods.
- Real-time systems -> identify the slow bits of code quicker.
- Systems with strict performance requirements -> measure performance of individual methods early.
Architectural Validation (Testing Approach)
Top-down integration testing is better at discovering errors in architecture
System demonstration (Testing Approach)
Top-down integration testing allows a limited demonstration at the early stage in development.
Test implementation (Testing Approach)
Bottom-up is more preferable here.
Test observation (Testing Approach)
Problems with both approaches, since it is hard to view outputs.
Interface Testing
Takes place when modules or sub-systems are integrated to create larger systems.
Detect faults due to interface errors or invalid assumptions about interfaces.
Important in object orientated development as objects are defined by their interfaces.
Interface Types
- parameter interface
- shared memory interface
- procedural interface
- message passing interface
Parameter Interface
Data passed from one procedure to another.
Shared Memory Interface
Block of memory is shared between procedures.
Procedural Interfaces
Sub-system encapsulates a set of procedures to be called by other sub-systems.
Message Passing Interfaces
Sub-systems request services from other sub-systems.
Interface Errors
- interface misuse
- interface misunderstanding
- timing errors
Interface Misuse
A calling component calls another components and makes an error in its use of its interfaces.
Interface Misunderstanding
A calling component embeds assumptions about the behaviour of the called component which are incorrect.
Timing Errors
The called and the calling component operate at different speeds and out-of-date information is accessed.
Interface Testing Guidelines
- Design tests so parameters to a called procedure are at the extreme ends of their ranges.
- Always test pointer parameters with null pointers.
- Design tests with causes components to fail.
- Use stress testing in message passing systems.
- In shared memory systems, vary the order in which components are activated.
Stress Testing
Exercising the system beyond its maximum design load.
Tests failure behaviour; systems should not fail catastrophically.
Object Orientated Testing
The components to be tested are object classes that are instantiated as objects.
No obvious top to the system for top-down integration and testing.
Testing coverage of a class involves testing all operations, setting and interrogating all object attributes and exercising the objects in all possible states.
Testing Levels for OO
- Testing operations associated within objects
- Testing object classes
- Testing clusters of cooperating objects
- Testing the whole OO
Cluster Testing
Integrating and testing clusters of cooperating objects, like in inheritance.
Approaches to Cluster Testing
- use-case or scenario testing
- thread testing
- object interaction testing
Use-case / Scenario Testing
Testing is based upon user interactions with system.
Thread testing
Tests the systems response to events as processing threads through the system
Object interaction testing
Test sequences of object interactions that stop when an object operation does not call on services from another object.
Scenario-based Testing
Identify scenarios from use-cases and supplement these with interaction diagrams that show the objects involved in the scenario.
