Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Spring 2018 > csci 387 quiz 4 > Flashcards

csci 387 quiz 4 Flashcards

1
Q

program testing is intended to show that

A

a program does what it is intended to do and to discover program defects before it is put into use

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

when you test software, you execute a program using

A

artificial data

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

program testing goals

A

to demonstrate to the developer and the customer that the software meets its requirements (validation); to discover situations in which the behavior of the software is incorrect, undesirable, or does not conform to its specification (defect)

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

for custom software, there must be at least ? test(s) for every requirement in the requirements document

A

one

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

for generic software products, there must be tests for ?

A

all of the system features, plus combinations of these features, that will be incorporated in the product release

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

defect testing is concerned with

A

rooting out undesirable system behavior such as crashes, unwanted interactions with other systems, incorrect computations, and data corruption

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

verification

A

are we building the product right (the software should conform to its specification)

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

validation

A

are we building the right product (the software should do what the user really requires)

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

aim of verification and validation is to

A

establish confidence that the system is ‘fit for purpose’

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

verification and validation confidence depends on

A

system’s purpose, user expectations, and marketing environment

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

static verification

A

software inspections concerned with analysis of the static system representation to discover problems (may be supplemented by tool-based document and code analysis)

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

dynamic verification

A

software testing concerned with exercising and observing product behavior (the system is executed with test data and its operational behavior is observed)

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

software inspections involve

A

people examining the source representation to discover anomalies/defects

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

inspections do not require ?, so they may be used ? implementation

A

execution of a system; before

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

during testing, ? can mask/hide other errors

A

errors

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

incomplete versions of a system can be inspected (with/without) additional costs

A

without

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

an inspection can also consider broader quality attributes of a program, such as ?

A

compliance with standards, portability, maintainability

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

inspections and testing are ? verification techniques

A

complementary and not opposing

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

both ? and ? should be used during the V&V process

A

inspections and testing

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

inspections can check conformance with ? but not with ?

A

a specification; a customer’s real requirements

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

inspections cannot check ? characteristics such as ?

A

non-functional; performance, usability, etc.

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

stages of testing

A

development, release, user

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

development testing

A

the system is tested during development to discover bugs and defects

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

release testing

A

a separate testing team tests a complete version of the system before it is released to users

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

user testing

A

users or potential users of a system test the system in their own environment

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

development testing includes

A

unit testing, component testing, and system testing

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

unit testing

A

individual program units or object classes are testing

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

unit testing should focus on testing

A

the functionality of objects or methods

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

component testing

A

several individual units are integrated to create composite components

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

component testing should focus on

A

testing component interfaces

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

system testing

A

some or all of the components in a system are integrated and the system is tested as a whole

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

system testing should focus on

A

testing component interactions

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

unit testing is a ? testing process

A

defect

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

units in unit testing may be

A

individual functions or methods within an object, object classes with several attributes and methods, composite components with defined interfaces used to access their functionality

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

object class testing: complete test coverage of a class involves

A

testing all operation associated with an object; setting and interrogating all object attributes; exercising the object in all possible states

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

? makes it more difficult to design object class tests as the information to be tested is not localized

A

inheritance

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

using a state model, identify ? to be tested and the ? to cause these transitions

A

sequences of state transitions; event sequences

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

whenever possible, unit testing should be ? so that tests are run and checked without manual intervention

A

automated

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

in automated unit testing, you make use of a ? to write and run your program tests

A

test automation framework (such as JUnit)

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

unit testing frameworks provide generic test classes that you ? to create specific test cases. they can then run all of the tests that you have implemented and report on ?

A

extend; the success of the tests

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

automated test components

A

setup, call, assertion parts

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

setup part

A

where you initialize the system with the test case, namely the inputs and expected outputs

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

call part

A

where you call the object or method to be tested

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

assertion part

A

where you compare the result of the call with the expected results (true = successful)

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

two types of unit test cases

A
  1. reflect normal operation of a program/show that the component works as expected
  2. use abnormal inputs to check that these are properly processed and do not crash the component
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
46
Q

testing strategies

A

partition, guideline-based

47
Q

partition testing is where you

A

identify groups of inputs that have common characteristics and should be processed in the same way

48
Q

guideline-based testing is where you

A

use testing guidelines to choose test cases (guidelines reflect previous experience of the kinds of errors that programmers often make when developing components)

49
Q

equivalence partition

A

the domain where the program behaves in an equivalent way for each class member

50
Q

boundary value analysis/range checking

A

test boundaries between equivalence partitions; test values at both valid and invalid boundaries

51
Q

test software with sequences which have only a ? value

A

single

52
Q

use sequences of (different/same) sizes in different tests

A

different

53
Q

derive tests so that the ? elements of the sequence are accessed

A

first, middle, last

54
Q

test with sequences of length ?

A

zero

55
Q

choose inputs that force the system to

A

generate all error messages

56
Q

design inputs that cause input buffers to

A

overflow

57
Q

force computation results to be

A

too large or too small

58
Q

software components are often composite components that are made up of

A

several interacting objects

59
Q

you access the functionality of the interacting objects through the defined

A

component interface

60
Q

testing composite components should focus on showing

A

that the component interface behaves according to its specification (you can assume unit tests have been completed)

61
Q

interface types

A

parameter, shared memory, procedural interfaces, message passing interfaces

62
Q

parameter interfaces

A

data passed from one method or procedure to another

63
Q

shared memory interfaces

A

block of memory is shared between procedures or functions

64
Q

procedural interfaces

A

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

65
Q

message passing interfaces

A

sub-systems request services from other sub-systems

66
Q

interface misuse

A

a calling component calls another component and makes an error in its use of its interface (e.g., parameters in the wrong order)

67
Q

interface misunderstanding

A

a calling component embed assumptions about the behavior of the called components which are incorrect (e.g., binary search in an unsorted array)

68
Q

timing errors with interface

A

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

69
Q

for the interface, design tests so that parameters to a called procedure are at the ? ends of their ranges

A

extreme

70
Q

for the interface, always test pointer parameters with ? pointers

A

null

71
Q

system testing during development involves

A

integrating components to create a version of the system and then testing the integrated system

72
Q

the focus in system testing is

A

testing the interactions between components

73
Q

system testing tests the ? behavior of a system

A

emergent

74
Q

during system testing, ? and ? may be integrated with the newly developed components

A

reusable components that have been separately developed and off-the-shelf-systems

75
Q

the use-cases developed to identify system interactions can be used as

A

a basis for system testing

76
Q

testing policies

A

define the required system test coverage

77
Q

examples of testing policies

A

all system functions that are accessed through menus should be tested; combinations of functions that are accessed through the same menu should be tested; etc.

78
Q

test coverage

A

measures the degree to which the specification or code of a software program has been exercised by tests

79
Q

code coverage

A

measures the degree to which the source code of a program has been tested

80
Q

code coverage criteria include

A

equivalence, boundary, control-flow, and state-based testing

81
Q

statement coverage

A

each statement executed at least once by some test case

82
Q

edge coverage

A

every edge (branch) of the control flow is traversed at least once by some test case

83
Q

condition coverage

A

every condition takes true and false outcomes at least once in some test case

84
Q

path coverage

A

finds the number of distinct paths through the program to be traversed at least once

85
Q

control flow testing using the ? of a program to ?

A

control structure; develop the test cases for the program

86
Q

the control flow graph of the program represents

A

the control structure of a program

87
Q

the control flow graph G=(N, E) of a program consists of

A

a set of nodes N and a set of edges E

88
Q

each node on the control flow graph represents ?; there are ? types of nodes; there is a unique ? and a unique ?

A

a set of program statements; five; entry, exit

89
Q

in the control flow graph, there is an edge from node a to node b if

A

the control may flow from the last statement in a to the first statement in b

90
Q

decision node

A

contains a conditional statement that creates two or more control branches (if or switch)

91
Q

merge node

A

represents a program point where multiple control branches merge

92
Q

statement node

A

contains a sequence of statements; control must enter from the first statement and exit from the last

93
Q

state-based testing

A

defines a set of abstract states that a software unit can take and tests the unit’s behavior by comparing its actual states to the expected states

94
Q

the state of an object is defined as

A

a constraint on the values of object’s attributes

95
Q

ensure state coverage conditions by

A

covering all identified states at least once, covering all valid transitions at least once, and triggering all invalid transitions at least once

96
Q

test-driven development is an approach to program development in which you

A

interleave testing and code development; tests are written before code and ‘passing’ the tests is the critical driver of development

97
Q

TDD

A

start by identifying the increment of functionality that is required; write a test for this and implement; run this test; once all tests run successfully, move on

98
Q

benefits of test-driven development

A

code coverage, regression testing, simplified debugging, system documentation

99
Q

regression testing

A

testing the system to check that changes have not ‘broken’ previously working code; all tests are rerun every time a change is made to the program

100
Q

release testing

A

the process of testing a particular release of a system that is intended for use outside of the development team

101
Q

the primary goal of the release testing process is to

A

convince the supplier of the system that it is good enough for use

102
Q

release testing is usually a ? testing process where tests are only derived from the system specification

A

black-box

103
Q

requirements-based testing involves

A

examining each requirement and developing a test or tests for it

104
Q

performance testing

A

usually involves planning a series of tests where the load is steadily increased until the system performance becomes acceptable

105
Q

stress testing is a form of performance testing where the system is

A

deliberately overloaded to test its failure behavior

106
Q

user or customer testing is a stage in the testing process in which

A

users or customers provide input and advice on system testing

107
Q

user testing is essential because

A

the user’s working environment may have a major effect on the reliability, performance, usability, and robustness of a system that cannot be replicated in a testing environment

108
Q

types of user testing

A

alpha, beta, acceptance

109
Q

alpha testing

A

users of the software work with the development team to test the software at the developer’s site

110
Q

beta testing

A

a release of the software is made available to users to allow them to experiment and to raise problems that they discover with the system developers

111
Q

acceptance testing

A

customers test a system to decide whether or not it is ready to be accepted from the system developers and deployed in the customer environment; primarily for custom systems

112
Q

in agile methods, the user/customer is part of ? and is responsible for ?

A

the development team; making decisions on the acceptability of the system

113
Q

in agile methods, there (is a / is no) separate testing process

A

is no

Spring 2018 (23 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions