Software Testing

Question 1

Defect Testing

Answer 1

Involves testing programs to establish presence of defects.

Question 2

Component Testing

Answer 2

Testing individual program components, usually the responsibility of the component developer.

Question 3

Integration Testing

Answer 3

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.

Question 4

Exhaustive Testing

Answer 4

Only way to show a program is free of defects, but exhaustive testing is impossible.

Question 5

Test Data

Answer 5

Inputted to test the system.

Question 6

Test Cases

Answer 6

Inputted to test the system, wit predefined outcomes which the system should abide by.

Question 7

Black-box Testing

Answer 7

Program is tested with no inside knowledge.
Program is considered as a black box, and it tested specifically on system specifications.

Question 8

Equivalence Partitioning

Answer 8

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.

Question 9

Equivalence Sets (Equivalence Partitioning)

Answer 9

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.

Question 10

Search Routines

Answer 10

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.

Question 11

Testing Guidelines

Answer 11

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.

Question 12

Structural Testing / White-box Testing

Answer 12

Derives test cases according to the program structure.
Inside knowledge is known.
Detailed report is given at the end.

Question 13

Binary Searching

Answer 13

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.

Question 14

Path Testing

Answer 14

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.

Question 15

Program Flow Graphs

Answer 15

Describe the program control flow, with each branch shown a separate path and loops shown by arrows looping back to the loop condition node.

Question 16

Cyclomatic Complexity

Answer 16

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.

Question 17

Independent Paths

Answer 17

All node paths in a graph.

Question 18

Integration Testing

Answer 18

Test complete systems or sub-systems composed of integrated components.
Integration testing should be black box testing with tests derived from specifications.

Question 19

Incremental Integration Testing

Answer 19

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.

Question 20

Testing Harness

Answer 20

Program that automatically generates test data and records their results.

Question 21

Top-down Testing

Answer 21

Start with high-level system and integrate from the top-down, replacing individual components by stubs where appropriate.

Question 22

Bottom-up Testing

Answer 22

Integrate individual components in levels until entire system is created.

Question 23

Bottom-up Testing is more appropriate for…

Answer 23

• 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.

Question 24

Architectural Validation (Testing Approach)

Answer 24

Top-down integration testing is better at discovering errors in architecture

Question 25

System demonstration (Testing Approach)

Answer 25

Top-down integration testing allows a limited demonstration at the early stage in development.

Question 26

Test implementation (Testing Approach)

Answer 26

Bottom-up is more preferable here.

Question 27

Test observation (Testing Approach)

Answer 27

Problems with both approaches, since it is hard to view outputs.

Question 28

Interface Testing

Answer 28

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.

Question 29

Interface Types

Answer 29

• parameter interface
• shared memory interface
• procedural interface
• message passing interface

Question 30

Parameter Interface

Answer 30

Data passed from one procedure to another.

Question 31

Shared Memory Interface

Answer 31

Block of memory is shared between procedures.

Question 32

Procedural Interfaces

Answer 32

Sub-system encapsulates a set of procedures to be called by other sub-systems.

Question 33

Message Passing Interfaces

Answer 33

Sub-systems request services from other sub-systems.

Question 34

Interface Errors

Answer 34

• interface misuse
• interface misunderstanding
• timing errors

Question 35

Interface Misuse

Answer 35

A calling component calls another components and makes an error in its use of its interfaces.

Question 36

Interface Misunderstanding

Answer 36

A calling component embeds assumptions about the behaviour of the called component which are incorrect.

Question 37

Timing Errors

Answer 37

The called and the calling component operate at different speeds and out-of-date information is accessed.

Question 38

Interface Testing Guidelines

Answer 38

• 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.

Question 39

Stress Testing

Answer 39

Exercising the system beyond its maximum design load.
Tests failure behaviour; systems should not fail catastrophically.

Question 40

Object Orientated Testing

Answer 40

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.

Question 41

Testing Levels for OO

Answer 41

• Testing operations associated within objects
• Testing object classes
• Testing clusters of cooperating objects
• Testing the whole OO

Question 42

Cluster Testing

Answer 42

Integrating and testing clusters of cooperating objects, like in inheritance.

Question 43

Approaches to Cluster Testing

Answer 43

• use-case or scenario testing
• thread testing
• object interaction testing

Question 44

Use-case / Scenario Testing

Answer 44

Testing is based upon user interactions with system.

Question 45

Thread testing

Answer 45

Tests the systems response to events as processing threads through the system

Question 46

Object interaction testing

Answer 46

Test sequences of object interactions that stop when an object operation does not call on services from another object.

Question 47

Scenario-based Testing

Answer 47

Identify scenarios from use-cases and supplement these with interaction diagrams that show the objects involved in the scenario.