Chapter 4 Flashcards

1
Q

requirements-based testing

A

An approach to testing in which test cases are designed based on test objectives and test conditions derived from requirements, e.g., tests that exercise specific functions or probe non functional attributes such as reliability or usability

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

specification

A

A document that specifies, ideally in a complete, precise, and verifiable manner, the requirements, design, behavior, or other characteristics of a component or system and, often, the procedures for determining whether these provisions have been satisfied

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

black-box testing

A

Testing, either functional or non functional, without reference to the internal structure of the component or system

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

specification-based technique (or black-box test design technique)

A

Procedure to derive and/or select test cases based on an analysis of the specification, either functional or non functional, of a component or system without reference to its internal structure

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

test basis

A

All documents from which the requirements of a component or system can be inferred. The documentation on which the test cases are based. If a document can be amended only by way of formal amendment procedure, then the test basis is called a frozen test basis

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

test oracle

A

A source to determine expected results to compare with the actual results of the software under test. An oracle may be the existing system (for a benchmark), a user manual, or an individual’s specialized knowledge, but it should not be the code

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

equivalence partition

A

A portion of an input or output domain for which the behavior of a component or system is assumed to be the same, based on the specification

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

equivalence partitioning

A

A black-box test design technique in which test cases are designed to execute representatives from equivalence partitions. In principle, test cases are designed to cover each partition at least once

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

boundary value analysis

A

A black-box test design technique in which test cases are designed based on boundary values

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

boundary value

A

An input value or output value that is on the edge of an equivalence partition or at the smallest incremental distance on either side of an edge, such as, for example the minimum or maximum value of a range

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

cause-effect graph

A

A graphical representation of inputs and/or stimuli (causes) with their associated outputs (effects), which can be used to design test cases

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

cause-effect graphing

A

A black-box test design technique in which test cases are designed from cause-effect graphs

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

decision table testing

A

A black-box test design technique in which test cases are designed to execute the combinations of inputs and/or stimuli (causes) shown in a decision table

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

use case testing

A

A black-box test design technique in which test cases are designed to execute user scenarios

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

use case

A

A sequence of transactions in a dialogue between a user and the system with a tangible result

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

high-level (or logical) test case

A

A test case without concrete (implementation level) values for input data and expected results. Logical operators are used; instances of the actual values are not yet defined and/or available

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

low-level (or concrete) test case

A

A test case with concrete (implementation level) values for input data and expected results. Logical operators from high-level test cases are replaced by actual values that correspond to the objectives of the logical operators.

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

state transition testing

A

A black-box test design technique in which test cases are designed to execute valid and invalid state transitions

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

orthogonal array

A

A two-dimensional array constructed with special mathematical properties such that choosing any two columns in the array provides every pair combination of each number in the array

20
Q

orthogonal array testing

A

A systematic way of testing all-pair combinations of variables using orthogonal arrays. It significantly reduces the number of all combinations of variables to test all pair combinations

21
Q

pairwise testing

A

A black-box test design technique in which test cases are designed to execute all possible discrete combinations of each pair of input parameters

22
Q

classification tree

A

A tree showing equivalence partitions hierarchically ordered, which is used to design test cases in the classification tree method

23
Q

classification tree method

A

A black-box test design technique in which test cases, described by means of a classification tree, are designed to execute combinations of representatives of input and/or output domains

24
Q

branch testing

A

A white-box test design technique in which test cases are designed to execute branches

25
Q

condition testing

A

A white-box test design technique in which test cases are designed to execute condition outcomes

26
Q

condition outcome

A

The evaluation of a condition to True or False

27
Q

condition determination testing (or multiple condition testing)

A

A white-box test design technique in which test cases are designed to execute single condition outcomes that independently affect a decision outcome

28
Q

control flow analysis

A

A form of static analysis based on a representation of sequences of events (paths) in the execution through a component or system

29
Q

data flow analysis

A

A form of static analysis based on the definition and usage of variables

30
Q

decision testing

A

A white-box test design technique in which test cases are designed to execute decision outcomes

31
Q

LCSAJ:

A

A Linear Code Sequence and Jump, consisting of the following three items (conventionally identified by line numbers in a source code listing): the start of the linear sequence of executable statements, the end of the linear sequence, and the target line to which control flow is transferred at the end of the linear sequence

32
Q

path testing

A

A white-box test design technique in which test cases are designed to execute paths

33
Q

path

A

A sequence of events, e.g., executable statements, of a component or system from an entry point to an exit point

34
Q

statement testing

A

A white-box test design technique in which test cases are designed to execute statements

35
Q

structure-based technique (or white-box test design technique)

A

Procedure to derive and/or select test cases based on an analysis of the internal structure of a component or system

36
Q

defect-based technique (or defect-based test design technique)

A

A procedure to derive and/or select test cases targeted at one or more defect categories, with tests being developed from what is known about the specific defect category.

37
Q

defect taxonomy

A

A system of (hierarchical) categories designed to be a useful aid for reproducibly classifying defects

38
Q

experienced-based technique (or experienced-based test design technique)

A

Procedure to derive and/or select test cases based on the tester’s experience, knowledge, and intuition.

39
Q

error guessing

A

A test design technique where the experience of the tester is used to anticipate what defects might be present in the component or system under test as a result of errors made and to design tests specifically to expose them

40
Q

exploratory testing

A

An informal test design technique where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests

41
Q

test charter

A

A statement of test objectives, and possibly test ideas about how to test. Test charters are used in exploratory testing. [Note: This statement is actually incorrect. Not all exploratory testing uses test charters, and test charters can be used in any dynamic testing strategy.]

42
Q

software attacks

A

Directed and focused attempt to evaluate the quality, especially reliability, of a test object by attempting to force specific failures to occur

43
Q

static analysis

A

Analysis of software artifacts, e.g., requirements or code, carried out without execution of these software artifacts

44
Q

dynamic analysis

A

The process of evaluating behavior, e.g., memory performance, CPU usage, of a system or component during execution

45
Q

memory leak

A

A defect in a program’s dynamic store allocation logic that causes it to fail to reclaim memory after it has finished using it, eventually causing the program to fail due to lack of memory

46
Q

wild pointer

A

A pointer that references a location that is out of scope for that pointer or that does not exist