Brainscape's Knowledge GenomeTM

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


See full index

ECSE_321 > Quality Assurance Software Testing > Flashcards

Quality Assurance Software Testing Flashcards

1
Q

What are the basic testing definitions?

A

Test cases, stubs, and drivers:
- Test cases provide
- a set of inputs and
- list a set of expected outputs
- Test stubs:
partial implementations of components
on which a component under test (CUT) depends
- Test drivers:
partial implementations of components
that exercise and depend on the tested component

Test Driver -> (dependsOn) CUT -> (dependsOn) Test Stub

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

What is the ugly truth about software testing?

A

Bugs are inescapable:
- It is impractical to test all possible uses
- Nonetheless, testing raises our confidence
that software has its desired behaviour
The impracticality of exhaustive testing:
- Large input space
- Large output space
- Large state space
- Large number of possible execution paths
- Subjective or imprecise requirements

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

What is exhaustive testing?

A

Testing all possible input combinations (but often infeasible). Some input spaces are finite. impractical or impossible (at worst),

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

What is an execution path?

A

Pssible flor of control of program
=sequence of executed statements
ex;
i = 2
j = 3
res = i * j
print(res) -> 1 paht

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

What is the execution path in this code?
i = i + j
if (i < 10):
print(“ok”)
else:
i = i/2

A

2 paths:
1:
i = i + j
print(“ok”)
2:
i = i + j
i = i/2

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

What is the execution path in this code?
for (i in [1..n]):
if (condition):
stmtA
else:
stmtB

A

2^n paths:
N = 1
Path 1:
stmtA
Path 2:
stmtB

N = 2
Path 1:
stmtA, stmtA
Path 2:
stmtA, stmtB
Path 3:
stmtB, stmtA
Path 4:
stmtB, stmtB

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

How many execution paths?
for (int i = 0; i < n; ++i) {
if (a.get(i) == b.get(i)) {
x[i] = x[i] + 100;
} else {
x[i] = x[i]/2;
}
}

A

2^n

->Loop Header-> +100 -> Loop Header
-> /2 -> Loop Header
(+100 or /2) then back to Loop Header

n Number of paths
1 2
2 4
3 8
10 1024
etc

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

What is a control flow diagram?

A

Representation of all execution paths:
Using graph notation
o Show where the flow is divided
o 1 node per block
oEdges to show different paths
o Predicate node: condition + several outgoing edges
o Terminal node
(see slide 17 for image)

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

Draw the execution path of:
i = i + j
if (i < 10):
print(“ok”)
else:
i = i/2

A

Path 1:
i = i + j
print(“ok”)
Path 2:
i = i + j
i = i/2
(see slide 18 for answer)

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

Draw the execution path of:
for (i in [1..n]):
if (condition):
stmtA
else:
stmtB

A

see slide 19 for answer

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

Why is this path infeasible? How many execution paths?
inputs: n and m
…
if (n > m)
x = n;
else
x = m;
if (x >= n)
y = 1;
else
y = 0;
…

A

There are two execution paths:
1. if (n > m) true, then x=n; so if (x >=n) always true since then n>=n always holds -> y=1
2. if (n>m) not true (so n<=m), then x=m; so since n<=m then if (x>=n) true since m=x which is x>=n.

So last else is never visited!
This means that this code has infeasible path executions.

Feasibility challenge: Even if we could test all
execution paths, some of them may not be feasible!

See slides 20-22 for more info!

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

What is the ugly truth about testing?

A

Lack of continuity.

Testing a bridge:
- If a bridge can sustain weight w1,
then it can also sustain w2 < w1
Testing software: Butterfly effect
- Small differences in operating
conditions can dramatically impact
software behaviour!

So… solution:
Striking a balance:
- A balance must be reached
between the cost of testing
and the risk of missing bugs

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

What is the truth about bugs…?

A

The truth about bugs:
- Not all known bugs are fixed
- Not enough time
- Too risky to fix (might create more problems)
- When is a bug really a bug?
- Time pressure may lead to downgrading bugs
to feature requests
- Since many people struggle to process criticism,
QA personnel are not the most popular people…

See slide 26 for info about oracles, verdicts and Test coverage.

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

What is a Test Coverage Criteria?

A

Measured in percentage: Tested / All
* Statement Coverage:
- executed statements / all statements
* Branch Coverage:
- both true and false branches of all conditions
- execution branches / all branches
* Path Coverage:
- Executed paths / all paths (see CFG)

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

How many test cases are
needed for 100% coverage?
inputs: m, n
int x=0, y=0, z=0
if (m > 0)
x = m;
if (n > 0)
y = n;
if (m < n)
z = n-m;
return (x+y)*z;

A

There are three if statements, each with two possible outcomes (the condition can either be true or false), making
2^3=8 paths in total. This is the full combination of all true/false outcomes for the three if conditions. (slide 29 for CFG). Every path is one test

Branch is 2 because you cover all true and false branches of all conditions. Doing all ifs or not.

Statement is 1 since you only need one test case that covers all the statements (statement is all lines/action tbd).

Recall:
Measured in percentage: Tested / All
* Statement Coverage:
- executed statements / all statements
* Branch Coverage:
- both true and false branches of all conditions
- execution branches / all branches
* Path Coverage:
- Executed paths / all paths (see CFG)

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

What are the testing stages?

A

Development testing:
- Tests that are typically written by the
development team
Release testing:
- Separate QA team produces tests to check
the system before it is released
User testing:
- Tests run by users to ensure that they will
be satisfied with the product

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

What are the three Granularities of development testing?

A

Unit Testing, Integration Testing, and System Testing.

17
Q

What is Unit Testing?

A

Unit testing:
- Target: particular program unit (class)
- Focuses on testing the functionality of an
object or a method
Unit testing:
- Maximize coverage of the system while
minimizing execution time
- Our test cases should cover all the possible
paths through our methods
- But we want our tests to finish quickly so
that we do not delay the release process

18
Q

What are the key phases of unit testing?

A

Key phases:
- Setup part: Prepare the system for
executing the test case
- Call part: Call the method under test
- Assertion part: Check that the system state
is in its expected form
- Teardown part: Clean up after a test

19
Q

What are the goals within unit tests?

A

Goals in designing unit tests:
(1) Show that (when used as expected) the
unit does what it is supposed to do
(2) If there are defects in a unit, the test cases
should reveal them!
Need different types of unit tests!

20
Q

What is equivalence partitioning?

A
  • Equivalence partitioning:
  • Inputs can be thought of as members of sets with
    common characteristics
  • Rule of thumb
  • Select test cases on the edge of the partitions
  • Select a test case near the middle as well
  • Can be applied to inputs or outputs

Many inputs could be lead to the same output ex: error if the bounds are incorrect.

Invalid <=50, Valid 50-90, Invalid >=90
see slide 38 and 39 for image.

21
Q

Exercise equivalence partionning:
Password:
- At least 8 characters long, at least one
number, lower & upper case letters, no
special characters (!@#…)
Gender
GRE score for Quantitative Reasoning:
- Between 130 and 170, 1 point increments
Postal code:
- According to Canadian system

A

Valid:
Password:
- length >= 8 (1)
- at least one number (2)
- at least one lower case letter (3)
- at least one upper case letter (4)
- no special characters (5)
Gender:
- in {F, M} (11)
GRE score:
- 130 <= score <= 170 (13)
Postal code:
- length is 6 characters (16)
- start with letter (17)
- alternates between letters and numbers (18)

Invalid:
Password:
- length < 8 (6)
- no number (7)
- no lower case letter (8)
- no upper case letter (9)
- at least one special character (10)
Gender:
- not in {F, M} (11)
GRE score:
- score < 130 (14)
- score > 170 (15)
Postal code:
- length < 6 (19)
- length > 6 (20)
- does not start with letter (21)
- does not alternates between letters and numbers (22)

Combine as many valid equivalence classes into
one test case as possible:
- Assuming that there is one method that validates
password, gender, GRE score, and postal code at
the same time
- One test case covers all valid equivalence
classes (1–5, 11, 13, 16–18)
One test case for each invalid equivalence class:
- 12 test cases are needed (6–10, 12, 14, 15, 19–22)

22
Q

What is Testing Integration?

A

Integration testing:
- Target: the combination of units
- Focuses on interface that is exposed to
others
- It’s all about dependencies and testing
order

23
Q

What is a stub?

A

Stub:
Called from the software component

Stubs are used to simulate the behavior of lower-level modules or components that are not yet implemented or are unavailable for testing. If you are testing a higher-level module and it depends on a lower-level module to function, you would use a stub to represent the lower-level module. Stubs provide the necessary outputs when called upon by the higher-level module, and they are also known as “called programs.”

  • Replaces a called module
  • Stubs for input modules pass test data
  • Stubs for output modules return test results
  • Can replace whole components (e.g.,
    persistence layer, network communication)
  • Must be declared/invoked like the real unit
  • Same name
  • Same parameter list and return type
  • Same modifiers (e.g., static)

public static int someFunc(floatfThat) {…}

stub example:

public static int someFunc(floatfThat) {
int iDummy = 42;
System.out.println(“In method someFunc “ +
“Input float =” + fThat);
System.out.println(“Returning “ + iDummy +
“.”);
return iDummy;
}

24
Q

What is a driver?

A

Drivers are used in the opposite situation; they simulate higher-level modules that call functions of a lower-level module. If you have developed a lower-level module but the higher-level module that uses it is not yet available, you would use a driver to simulate the calling of the lower-level module. Drivers provide the necessary inputs to the module being tested and can invoke a module or a component. They are also known as “calling programs.”

Driver:
- Replaces a calling module
- Passes parameters
- Handles return values
- Usually simpler than stubs

ex:
public class TestSomething {
public static void main (String[] args) {
floatiSend = 98.6f;
Whatever what = new Whatever();
System.out.println(“Sending someFunc: “ +
iSend);
int iReturn = what.someFunc(iSend);
System.out.println (“SomeFunc returned: “ +
iReturn);
}
}

25
Q

What are the development Testing Strategies?

A

Big Bang integration strategy
All at once:
- Avoid except for small/stable systems

see slide 49 for visual

Top-Down integration strategy
From high-level to low-level units:
- Few drivers needed, but many
stubs since stubs similate low level modules

see slide 50 for visual

Bottom-Up integration strategy
From low-level to high-level units:
- Few stubs needed, but many
drivers

see slide 51 for visual

26
Q

What are the type of interface errors in development testing?

A

Misuse:
- Caller makes an error in the use of an
interface
Misunderstanding:
- Caller makes an invalid assumption about
the use of an interface
Timing:
- Some interfaces are time sensitive
- Even if a caller uses an interface correctly,
it may be too early or too late

27
Q

What are the Development testing
Guidelines for interface testing?

A

(1) Examine the code to be tested and identify
each call to an external component
(2) Where objects are accepted as parameters,
always test a null input
(3) Design tests to deliberately cause the
component to fail
(4) Where components use a shared memory
interface, design tests to vary their order of
access

Code reviews are great for finding
component/interface problems

28
Q

What is system level testing?

A

System testing:
- Target: the combination of components that make
up a subsystem or the entire system
- Focuses on testing the interactions between
components

How to specify interactions?
Interactions between components in software can be specified using a variety of methods, such as sequence diagrams, interface definitions, and interaction specifications. These documents or diagrams will outline how different parts of the system communicate with each other, the sequence of operations, the data passed between components, and the expected outcomes.

How to derive system-level tests?
System-level tests can be derived from the requirements specification documents. These are usually high-level documents that outline what the system should do from the user’s perspective. To derive system-level tests, one would create test cases that cover all the functionalities listed in the requirements. These test cases aim to simulate real-world usage scenarios to ensure that the system meets the specified requirements when it is used as intended.

As for the question in the speech bubble, “How is this different from integration testing?”:

System testing differs from integration testing in its scope and objectives. Integration testing focuses on the interactions and interfaces between integrated units to ensure they work together correctly. It’s done after unit testing and before system testing.
System testing, on the other hand, is performed on a complete and integrated software to evaluate the system’s compliance with the specified requirements. It covers not just the interactions, but also the system’s overall behavior under various conditions, including both functional and non-functional aspects such as performance, security, and usability.

29
Q

How to write a good system test?

A

Testing end-to-end scenarios
- Detailed use case specifications
- Sequence diagrams
- Capture communication between components
* Testing end-to-end lifecycle
- Captures the state-based behavior of a complex
business entity (UML Statecharts)
- Captures complex business workflows
(UML Activity Diagrams)
* Model-based testing

30
Q

How much system testing is enough?

A
  • Policies:
  • Each project should outline testing policies to
    reach the level of risk that is comfortable
  • Some example guidelines:
    (1) All system functions that are accessed through
    menus should be tested
    (2) Combinations of functions that are accessed
    through the same menu must be tested
    (3) Where user input is provided, all functions must be
    tested with correct and invalid input
31
Q

What are the difference between types of testing (unit, integration and system)?

A

Unit:
-from module specifications
- visibility of code details
- complex scaffolding
- behaviour of single modules
Integration:
- from interface specifications
- visibility of integr. structure
- some scaffolding
- interactions among modules
System:
- from requirements and specifications
- no visibility of code
- no drivers/stubs
- system functionalities

32
Q

What is release testing?

A

What is release testing?
- Similar to system testing, release testing
is performed on the entire system and is
based on use cases
- Unlike system tests, release tests:
- Must be written by (and executed by) a
team that does not report to development
- Check that the system meets requirements
(while system tests aim to find bugs)

33
Q

Release testing
How does it differ from system testing?

A

Black-box vs. white box:
- Technically speaking, some development
organizations write white-box system tests
- Release tests are never white-box tests, they are
always black-box!

Recall: Black Box testing is focused on external or end-user perspective whereas White Box testing is focused on code structure, conditions, paths and branches

34
Q

What is user testing and what are the types?

A
  • What are user tests?
  • User tests are performed by customers to ensure that
    the software meets their expectations
  • Useful approach for validation
  • Types of user tests
  • Alpha tests:
  • A select group of users works closely with the
    development team to test early releases
  • Defects are expected, but alpha users get access to
    “bleeding edge” features!
  • Beta tests:
  • A larger group of users is allowed to experiment with a
    release
35
Q

User testing, what are the Types of user tests?

A

Acceptance tests:
- Customers test a software system to make sure
it meets their expectations and can be adopted
in their environment

see slide 64 for a visual

36
Q

What are the testing visibility specifiers?

A

Black-box testing:
- Tests that are written without considering
how the code is written (based on specs)
- Treats the system like an opaque box that
accepts inputs and checks outputs
White-box testing:
- Tests that are written with an understanding
of the structure of the code
- Tests the inner workings of the system itself

37
Q

What are the differences between Black-box and White-box?

A

Black-box:
+ Check conformance
with spec
+ Scales up
- Depends on detail in
spec
- Does not tell how
much of the system
is being tested -> cannot reveal errors due to implementation details
White-box: -> looks at code
+ Allows for measuring
“test coverage” of
system
+ Based on control or
data flow coverage
- Does not scale up well
- Cannot reveal missing
functionality! -> since do not have specs

38
Q

Do we need both types of tests (white and black box)?

A

see slide 68:

Missing functionality cannot be revealed by white-box techniques
Unexpected functionalities cannot be revealed by black-box techniques

39
Q

Are they (typically)
black-box or white-box?
(1) Unit tests?
(2) System tests?
(3) Stress tests?
(4) Integration tests?
(5) Acceptance tests?

A

(1) Unit tests? WB
(2) System tests? BL
(3) Stress tests? BL
(4) Integration tests? BW
(5) Acceptance tests? BL
See slide 72 for image on how every test gets puzzled together

ECSE_321 (4 decks)

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