Testing Flashcards

(23 cards)

1
Q

is a critical process within any
software development and maintenance life
cycle model

A

Testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Testing implementations is often referred to as

A

software testing, or simply testing.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Only _____ can guarantee full
coverage.

A

exhaustive testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

is impractical since it may
take years to complete even for testing small size
programs.

A

Exhaustive testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

difficulty in software testing

A

the inability
to quantify the errors existing in software, and
hence predict how many errors are left
undiscovered.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q
  • Test the software by executing it and applying
    test inputs
  • Observe the output and make a judgment to
    take a verdict
A

Dynamic testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q
  • Check code without executing it
  • Automatic static testing: Code as an input to a
    static analysis tool
  • Non-automatic static testing: review,
    walkthrough, inspection
A

Static testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

is a set of organized test cases

A

test suite

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

includes a test suite

A

Test plan

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

are obtained using known testing
techniques and strategies

A

Test cases

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

module or unit testing

A

White-box:

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

module testing and system testing

A

Black-box:

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

a bit of both (partial knowledge of
internal structure)

A

Grey-box:

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Source Code + Functional Specifications

A

White box based test generation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Functional Specifications only

A

Black box based test generation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Design Document + Functional Specifications

A

Grey box based test generation

17
Q

Black-box unit/module testing techniques

A
  • Boundary value analysis
  • Equivalence class testing
  • Decision table / decision tree based testing
  • State based testing
  • Robustness testing
18
Q

test inputs
obtained from the boundaries
Serious errors hide at the boundaries.
For example, simple boundary values for an
input of integer data type would include
-INT_MAX, -INT_MAX + 1, -1, 0, +1, INT_MAX -1 and
INT_MAX.

A

Boundary Value Analysis (BVA):

19
Q
  • Partitioning input domain into disjoint
    subsets or partitions
  • Partition includes related values
  • Consider one test input from each partition
  • Example: “all positive numbers”
A

Equivalence class testing

20
Q
  • Decision table: each column denoting a rule
    becomes the basis of a test case
  • Conditions produce inputs
  • Actions produce expected outputs
A

Decision table-based testing

21
Q
  • Each distinct path from the root node to a leaf
    node is the basis of a test case
  • If along the path, a variable input value does
    not exist, the test input for that variable can be
    assigned any valid value.
A

Decision tree-based testing

22
Q

An implemented finite state machine (FSM)
conforms to its specification, if the observed
output sequence matches the expected output
according to the specification

A

State-based testing