N this chapter, we will introduce you to the fundamentals of testing: why testing is

Data structure refers to the organization of the data itself, independent of the
program. When data are arranged as a list, queue, stack, or other well-defined
structure, the algorithms for creating, modifying or deleting them are more likely
to be well-defined, too. Thus, the data structure provides a lot of information about
the difficulty in writing programs to handle the data and in designing test cases to
show program correctness. That is, sometimes a program is complex because it has a
complex data structure, rather than because of complex control or data flow.
The important thing for the tester is to be aware that the above mentioned static
analysis measures can be used as early warning signals of how good the code is
likely to be when it is finished.
In summary the value of static analysis is especially for:
l
early detection of defects prior to test execution;
l
early warning about suspicious aspects of the code, design or requirements;
l
identification of defects not easily found in dynamic testing;
l
improved maintainability of code and design since engineers work according to
documented standards and rules;
l
prevention of defects, provided that engineers are willing to learn from their
errors and continuous improvement is practised.
68
Chapter 3 Static techniques

C H A P T E R R E V I E W
Let
’s review what you have learned in this chapter.
From Section 3.1, you should be able to explain the importance and advantages
of static testing. You should know the difference between static testing and dynamic
testing, and also understand the concept of reviews. You should be able to recognize
the software work products that can be examined by static testing. You should know
the glossary terms dynamic testing and static testing.
From Section 3.2, you should understand the difference between formal and informal
reviews. You should be able to recall the main phases of a typical formal review. The
main roles within reviews and their responsibilities should be clear to you. You should
know the differences between the various types of formal review: technical review,
walkthrough and inspection. Finally you should be able to explain the factors for
successful performance of reviews. You should know the glossary terms entry criteria,
formal review, informal review, inspection, metric, moderator, peer review,
reviewer, scribe, technical review, and walkthrough.
From Section 3.3, you should understand the objective of static analysis and be
able to compare it to static and dynamic testing. You should be able to describe the
main features of static analysis and recall typical defects that can be found using
static analysis. Finally, you should be able to recall the benefits of using static
analysis. You should know the glossary terms compiler, complexity, control flow,
cyclomatic complexity, data flow, and static analysis.
Chapter Review 69

S A M P L E E X A M Q U E S T I O N S
Question 1 Which of the following artefacts can be
examined by using review techniques?
a. Software code
b. Requirements specification
c. Test designs
d. All of the above
Question 2 Which statement about the function of a
static analysis tool is true?
a. Gives quality information about the code without
executing it.
b. Checks expected results against actual results.
c. Can detect memory leaks.
d. Gives information about what code has and has not
been exercised.
Question 3 Which is not a type of review?
a. Walkthrough
b. Inspection
c. Informal review
d. Management approval
Question 4 What statement about reviews
is true?
a. Inspections are led by a trained moderator, whereas
technical reviews are not necessarily.
b. Technical reviews are led by a trained leader,
inspections are not.
c. In a walkthrough, the author does not attend.
d. Participants for a walkthrough always need to be
thoroughly trained.
Question 5 What is the main difference between a
walkthrough and an inspection?
a. An inspection is led by the authors, while a
walkthrough is led by a trained moderator.
b. An inspection has a trained leader, while a
walkthrough has no leader.
c. Authors are not present during inspections, while
they are during walkthroughs.
d. A walkthrough is led by the author, while an
inspection is led by a trained moderator.
Question 6 Which of the following characteristics
and types of review processes belong together?
1 Led by the author
2 Undocumented
3 No management participation
4 Led by a trained moderator or leader
5 Uses entry and exit criteria
s. Inspection
t. Technical review
u. Informal review
v. Walkthrough
a. s = 4, t = 3, u = 2 and 5, v = 1
b. s = 4 and 5, t = 3, u = 2, v = 1
c. s = 1 and 5, t = 3, u = 2, v = 4
d. s = 5, t = 4, u = 3, v = 1 and 2
Question 7 What statement about static analysis is true?
a. With static analysis, defects can be found that are
difficult to find with dynamic testing.
b. Compiling is not a form of static analysis.
c. When properly performed, static analysis makes
functional testing redundant.
d. Static analysis finds all faults.
Question 8 Which of the following statements about
early test design are true and which are false?
1 Defects found during early test design are more
expensive to fix.
2 Early test design can find defects.
3 Early test design can cause changes to the
requirements.
4 Early test design takes more effort.
a. 1 and 3 are true. 2 and 4 are false.
b. 2 is true. 1, 3 and 4 are false.
c. 2 and 3 are true. 1 and 4 are false.
d. 2, 3 and 4 are true. 1 is false.
Question 9 Static code analysis typically identifies
all but one of the following problems. Which is it?
a. Unreachable code
b. Undeclared variables
c. Faults in the requirements
d. Too few comments
70
Chapter 3 Static techniques

CHAPTER FOUR
Test design techniques
C
hapter 3 covered static testing, looking at documents and code, but not running
the code we are interested in. This chapter looks at dynamic testing, where the
software we are interested in is run by executing tests on the running code.
4 . 1
T H E T E S T D E V E L O P M E N T P R O C E S S
SYLLABUS LEARNING OBJECTIVES FOR 4 .1 TH E TEST
DEVELOPMENT PROCESS (K3)
LO-4.1.1 Differentiate between a test design specification, test case
specification and test procedure specification. (K2)
LO-4.1.2 Compare the terms test condition, test case and test
procedure. (K2)
LO-4.1.3 Evaluate the quality of test cases in terms of clear traceability
to the requirements and expected results. (K2)
LO-4.1.4 Translate test cases into a well-structured test procedure
specification at a level of detail relevant to the knowledge of
the testers. (K3)
Before we can actually execute a test, we need to know what we are trying to test,
the inputs, the results that should be produced by those inputs, and how we actually
get ready for and run the tests.
In this section we are looking at three things: test conditions, test cases and test
procedures (or scripts)
– they are described in the sections below. Each is specified
in its own document, according to the Test Documentation Standard [IEEE 829].
Test conditions are documented in a Test Design Specification. We will look at
how to choose test conditions and prioritize them.
Test cases are documented in a test case specification. We will look at how to
write a good test case, showing clear traceability to the test basis (e.g. the require-
ment specification) as well as to test conditions.
Test procedures are documented (as you may expect) in a Test Procedure
Specification (also known as a test script or a manual test script). We will look at
how to translate test cases into test procedures relevant to the knowledge of the
tester who will be executing the test, and we will look at how to produce a test
execution schedule, using prioritization and technical and logical dependencies.
Test case
specification A
document specifying a
set of test cases
(objective, inputs, test
actions, expected results,
and execution
preconditions) for a test
item.
71

In this section, look for the definitions of the glossary terms horizontal trace-
ability, test case specification, test design technique, test execution schedule, test
script, traceability and vertical traceability.
4.1.1 Formality of test documentation
Testing may be performed with varying degrees of formality. Very formal testing
would have extensive documentation which is well controlled, and would expect the
documented detail of the tests to include the exact and specific input and expected
outcome of the test. Very informal testing may have no documentation at all, or only
notes kept by individual testers, but we
’d still expect the testers to have in their
minds and notes some idea of what they intended to test and what they expected the
outcome to be. Most people are probably somewhere in between! The right level of
formality for you depends on your context: a commercial safety-critical application
has very different needs than a one-off application to be used by only a few people
for a short time.
The level of formality is also influenced by your organization
– its culture, the
people working there, how mature the development process is, how mature the
testing process is, etc. The thoroughness of your test documentation may also
depend on your time constraints; under excessive deadline pressure, keeping good
documentation may be compromised.
In this chapter we will describe a fairly formal documentation style. If this is not
appropriate for you, you might adopt a less formal approach, but you will be aware
of how to increase formality if you need to.
4.1.2 Test analysis: identifying test conditions
Test analysis is the process of looking at something that can be used to derive test
information. This basis for the tests is called the
‘test basis’. It could be a system
requirement, a technical specification, the code itself (for structural testing), or a
business process. Sometimes tests can be based on an experienced user
’s knowledge
of the system, which may not be documented. The test basis includes whatever the
tests are based on. This was also discussed in Chapter 1.
From a testing perspective, we look at the test basis in order to see what could be
tested
– these are the test conditions. A test condition is simply something that we
could test. If we are looking to measure coverage of code decisions (branches), then
the test basis would be the code itself, and the list of test conditions would be the
decision outcomes (True and False). If we have a requirements specification, the
table of contents can be our initial list of test conditions.
A good way to understand requirements better is to try to define tests to meet
those requirements, as pointed out by [Hetzel 1988].
For example, if we are testing a customer management and marketing system for
a mobile phone company, we might have test conditions that are related to a
marketing campaign, such as age of customer (pre-teen, teenager, young adult,
mature), gender, postcode or zip code, and purchasing preference (pay-as-you-go
or contract). A particular advertising campaign could be aimed at male teenaged
customers in the mid-west of the USA on pay-as-you-go, for example.
Testing experts use different names to represent the basic idea of
‘a list of
things that we could test
’. For example, Marick refers to ‘test requirements’ as
72
Chapter 4 Test design techniques

things that should be tested. Although it is not intended to imply that everything
must be tested, it is too easily interpreted in that way [Marick 1994]. In contrast,
Hutcheson talks about the
‘test inventory’ as a list of things that could be tested
[Hutcheson 2003]; Craig talks about
‘test objectives’ as broad categories of things
to test and
‘test inventories’ as the actual list of things that need to be tested
[Craig 2002]. These authors are all referring to what the ISTQB glossary calls a
test condition.
When identifying test conditions, we want to
‘throw the net wide’ to identify as
many as we can, and then we will start being selective about which ones to take
forward to develop in more detail and combine into test cases. We could call them
‘test possibilities’.
In Chapter 1 we explained that testing everything is known as exhaustive
testing (defined as exercising every combination of inputs and preconditions)
and we demonstrated that this is an impractical goal. Therefore, as we cannot test
everything, we have to select a subset of all possible tests. In practice the subset
we select may be a very small subset and yet it has to have a high probability of
finding most of the defects in a system. We need some intelligent thought
processes to guide our selection; test techniques (i.e. test design techniques)
are such thought processes.
A testing technique helps us select a good set of tests from the total number of all
possible tests for a given system. Different techniques offer different ways of
looking at the software under test, possibly challenging assumptions made about
it. Each technique provides a set of rules or guidelines for the tester to follow in
identifying test conditions and test cases. Techniques are described in detail later in
this chapter.
The test conditions that are chosen will depend on the test strategy or detailed test
approach. For example, they might be based on risk, models of the system, likely
failures, compliance requirements, expert advice or heuristics. The word
‘heuristic’
comes from the same Greek root as eureka, which means
‘I find’. A heuristic is a
way of directing your attention, a common sense rule useful in solving a problem.
Test conditions should be able to be linked back to their sources in the test basis
–
this is called traceability.
Traceability can be either horizontal through all the test documentation for a
given test level (e.g. system testing, from test conditions through test cases to test
scripts) or vertical through the layers of development documentation (e.g. from
requirements to components).
Why is traceability important? Consider these examples:
l
The requirements for a given function or feature have changed. Some of the
fields now have different ranges that can be entered. Which tests were looking at
those boundaries? They now need to be changed. How many tests will actually
be affected by this change in the requirements? These questions can be answered
easily if the requirements can easily be traced to the tests.
l
A set of tests that has run OK in the past has started to have serious problems.
What functionality do these tests actually exercise? Traceability between the tests
and the requirement being tested enables the functions or features affected to
be identified more easily.
l
Before delivering a new release, we want to know whether or not we have tested
all of the specified requirements in the requirements specification. We have the
list of the tests that have passed
– was every requirement tested?
Test design
technique Procedure
used to derive and/or
select test cases.
Traceability The ability
to identify related items
in documentation and
software, such as
requirements with
associated tests. See also
horizontal traceability,
vertical traceability.
Horizontal
traceability The tracing
of requirements for a test
level through the layers
of test documentation
(e.g. test plan, test design
specification, test case
specification and test
procedure specification or
test script).
Vertical
traceability The tracing
of requirements through
the layers of
development
documentation to
components.
Section 1 The Test Development Process 73

Having identified a list of test conditions, it is important to prioritize them, so that
the most important test conditions are identified (before a lot of time is spent in
designing test cases based on them). It is a good idea to try and think of twice as
many test conditions as you need
– then you can throw away the less important
ones, and you will have a much better set of test conditions!
Note that spending some extra time now, while identifying test conditions,
doesn
’t take very long, as we are only listing things that we could test. This is a
good investment of our time
– we don’t want to spend time implementing
poor tests!
Test conditions can be identified for test data as well as for test inputs and test
outcomes, for example, different types of record, different distribution of types of
record within a file or database, different sizes of records or fields in a record. The
test data should be designed to represent the most important types of data, i.e. the
most important data conditions.
Test conditions are documented in the IEEE 829 document called a Test Design
Specification, shown below. (This document could have been called a Test Condi-
tion Specification, as the contents referred to in the standard are actually test
conditions.)
4.1.3 Test design: specifying test cases
Test conditions can be rather vague, covering quite a large range of possibilities as
we saw with our mobile phone company example (e.g. a teenager in the mid-west),
or a test condition may be more specific (e.g. a particular male customer on pay-as-
you-go with less than $10 credit). However when we come to make a test case, we
are required to be very specific; in fact we now need exact and detailed specific
inputs, not general descriptions (e.g. Jim Green, age 17, living in Grand Rapids,
Michigan, with credit of $8.64, expected result: add to Q4 marketing campaign).
Note that one test case covers a number of conditions (teenager, male, mid-west
area, pay-as-you-go, and credit of less than $10).
For a test condition of
‘an existing customer’, the test case input needs to be ‘Jim
Green
’ where Jim Green already exists on the customer database, or part of this test
would be to set up a database record for Jim Green.
A test case needs to have input values, of course, but just having some values to
input to the system is not a test! If you don
’t know what the system is supposed to
do with the inputs, you can
’t tell whether your test has passed or failed.
Should these detailed test cases be written down? They can be formally docu-
mented, as we will describe below. However, it is possible to test without docu-
menting at the test-case level. If you give an experienced user acceptance tester with
I EE E 8 2 9 S T A N D A R D : T E S T D E S I G N
S P E C I F I C A T I O N T E M P L A T E
Test design specification identifier
Features to be tested
Approach refinements
Test identification
Feature pass/fail criteria
74
Chapter 4 Test design techniques

a strong business background a list of high-level test conditions, they could probably
do a good job of testing. But if you gave the same list to a new starter who didn
’t
know the system at all, they would probably be lost, so they would benefit from
having more detailed test cases.
Test cases can be documented as described in the IEEE 829 Standard for Test
Documentation. Note that the contents described in the standard don
’t all have to be
separate physical documents. But the standard
’s list of what needs to be kept track
of is a good starting point, even if the test conditions and test cases for a given
functionality or feature are all kept in one physical document.
One of the most important aspects of a test is that it assesses that the system does
what it is supposed to do. Copeland says
‘At its core, testing is the process of
comparing
“what is” with “what ought to be” ’ [Copeland 2003]. If we simply put in
some inputs and think
‘that was fun, I guess the system is probably OK because it
didn
’t crash’, then are we actually testing it? We don’t think so. You have observed
that the system does what the system does
– this is not a test. Boris Beizer refers to
this as
‘kiddie testing’ [Beizer 1990]. We may not know what the right answer is in
detail every time, and we can still get some benefit from this approach at times, but
it isn
’t really testing.
In order to know what the system should do, we need to have a source of
information about the correct behaviour of the system
– this is called an ‘oracle’
or a test oracle. This has nothing to do with databases or companies that make them.
It comes from the ancient Greek Oracle at Delphi, who supposedly could predict the
future with unerring accuracy. Actually her answers were so vague that people
interpreted them in whatever way they wanted
– perhaps a bit like requirements
specifications!
Once a given input value has been chosen, the tester needs to determine what the
expected result of entering that input would be and document it as part of the test case.
Expected results include information displayed on a screen in response to an
input, but they also include changes to data and/or states, and any other conse-
quences of the test (e.g. a letter to be printed overnight).
What if we don
’t decide on the expected results before we run a test? We can still
look at what the system produces and would probably notice if something was
wildly wrong. However, we would probably not notice small differences in calcula-
tions, or results that seemed to look OK (i.e. are plausible). So we would conclude
that the test had passed, when in fact the software has not given the correct result.
Small differences in one calculation can add up to something very major later on, for
example if results are multiplied by a large factor.
Ideally expected results should be predicted before the test is run
– then your
assessment of whether or not the software did the right thing will be more
objective.
For a few applications it may not be possible to predict or know exactly what an
expected result should be; we can only do a
‘reasonableness check’. In this case we
have a
‘partial oracle’ – we know when something is very wrong, but would
probably have to accept something that looked reasonable. An example is when a
system has been written to calculate something where it may not be possible to
manually produce expected results in a reasonable timescale because the calcula-
tions are so complex.
In addition to the expected results, the test case also specifies the environment
and other things that must be in place before the test can be run (the preconditions)
and any things that should apply after the test completes (the postconditions).
Section 1 The Test Development Process 75

The test case should also say why it exists
– i.e. the objective of the test it is part of
or the test conditions that it is exercising (traceability). Test cases can now be
prioritized so that the most important test cases are executed first, and low priority
test cases are executed later, or even not executed at all. This may reflect the priorities
already established for test conditions or the priority may be determined by other
factors related to the specific test cases, such as a specific input value that has proved
troublesome in the past, the risk associated with the test, or the most sensible sequence
of running the tests. Chapter 5 gives more detail of risk-based testing.
Test cases need to be detailed so that we can accurately check the results and know
that we have exactly the right response from the system. If tests are to be automated,
the testing tool needs to know exactly what to compare the system output to.
4.1.4 Test implementation: specifying test procedures
or scripts
The next step is to group the test cases in a sensible way for executing them and to
specify the sequential steps that need to be done to run the test. For example, a set of
simple tests that cover the breadth of the system may form a regression suite, or all
of the tests that explore the working of a given functionality or feature in depth may
be grouped to be run together.
Some test cases may need to be run in a particular sequence. For example, a test
may create a new customer record, amend that newly created record and then delete
it. These tests need to be run in the correct order, or they won
’t test what they are
meant to test.
The document that describes the steps to be taken in running a set of tests (and
specifies the executable order of the tests) is called a test procedure in IEEE 829, and is
often also referred to as a test script. It could be called a manual test script for tests that
are intended to be run manually rather than using a test execution tool. Test script is also
used to describe the instructions to a test execution tool. An automation script is written
in a programming language that the tool can interpret. (This is an automated test
procedure.) See Chapter 6 for more information on this and other types of testing tools.
The test procedures, or test scripts, are then formed into a test execution
schedule that specifies which procedures are to be run first – a kind of superscript.
The test schedule would say when a given script should be run and by whom. The
schedule could vary depending on newly perceived risks affecting the priority of a
script that addresses that risk, for example. The logical and technical dependencies
between the scripts would also be taken into account when scheduling the scripts.
For example, a regression script may always be the first to be run when a new
release of the software arrives, as a smoke test or sanity check.
I E E E 8 2 9 S T A N D A R D : T E S T C A S E
S P E C I F I C A T I O N T E M P L A T E
Test case specification identifier
Test items
Input specifications
Output specifications
Environmental needs
Special procedural requirements
Intercase dependencies
Test script Commonly
used to refer to a test
procedure specification,
especially an automated
one.
Test execution
schedule A scheme for
the execution of test
procedures. The test
procedures are included
in the test execution
schedule in their context
and in the order in which
they are to be executed.
76
Chapter 4 Test design techniques

Returning to our example of the mobile phone company
’s marketing campaign, we
may have some tests to set up customers of different types on the database. It may be
sensible to run all of the setup for a group of tests first. So our first test procedure would
entail setting up a number of customers, including Jim Green, on the database.
Test procedure DB15: Set up customers for marketing campaign Y.
Step 1: Open database with write privilege
Step 2: Set up customer Bob Flounders male, 62, Hudsonville, contract
Step 3: Set up customer Jim Green male, 17, Grand Rapids, pay-as-you-go, $8.64
Step 4:
…
We may then have another test procedure to do with the marketing campaign:
Test procedure MC03: Special offers for low-credit teenagers
Step 1: Get details for Jim Green from database
Step 2: Send text message offering double credit
Step 3: Jim Green requests $20 credit, $40 credited
Writing the test procedure is another opportunity to prioritize the tests, to
ensure that the best testing is done in the time available. A good rule of thumb is
‘Find the scary stuff first’. However the definition of what is ‘scary’ depends on
the business, system or project. For example, is it worse to raise Bob Founders
’
credit limit when he is not a good credit risk (he may not pay for the credit he
asked for) or to refuse to raise his credit limit when he is a good credit risk (he
may go elsewhere for his phone service and we lose the opportunity of lots of
income from him).
4 . 2
C A T E G O R I E S O F T E S T D E S I GN T E C H N I Q U E S
SYLLABUS LEARNING OBJECTIVES FOR 4 .2 CATEGORIES
OF TEST DESIGN TECHNIQUES (K2)
LO-4.2.1 Recall reasons that both specification-based (black-box) and
structure-based (white-box) test design techniques are useful
and list the common techniques for each. (K1)
LO-4.2.2 Explain the characteristics, commonalities, and differences
between specification-based testing, structure-based testing
and experience-based testing. (K2)
I E E E 8 2 9 S T A N D A R D : T E S T P R O C E DU R E
S P E C I F I C A T I O N T E M P L A T E
Test procedure specification identifier
Purpose
Special requirements
Procedure steps
Section 2 Categories of Test Design Techniques 77

In this section we will look at the different types of test design technique, how they
are used and how they differ. The three types or categories are distinguished by their
primary source: a specification, the structure of the system or component, or a
person
’s experience. All categories are useful and the three are complementary.
Reflecting back on the fundamental test process introduced earlier, it
’s worth
mentioning that there is a fuzzy distinction between test analysis and test design,
which is reflected in the Foundation syllabus itself. In section 4.2, the Foundation
syllabus says,
‘The purpose of a test design technique is to identify test conditions,
test cases, and test data
’. While identifying test conditions during test design is
certainly a common practice, in well-defined test processes, it is more accurate to
say, as the Foundation syllabus says in section 4.1,
‘During test analysis, the test
basis documentation is analyzed in order to determine what to test, i.e. to identify
the test conditions
’.
In our opinion, the ideal case is that test conditions are identified during analysis,
and then used to define test cases and test data during test design. For example, in
risk based testing strategies, we identify risk items (which are the test conditions)
when performing an analysis of the risks to product quality. Those risk items, along
with their corresponding levels of risk, are subsequently used to design the test cases
and implement the test data. Risk based testing will be discussed in Chapter 5.
In this section, look for the definitions of the glossary terms experience-based
test design technique, and structure-based test design technique.
4.2.1 Introduction
There are many different types of software testing technique, each with its own
strengths and weaknesses. Each individual technique is good at finding particular
types of defect and relatively poor at finding other types. For example, a technique
that explores the upper and lower limits of a single input range is more likely to find
boundary value defects than defects associated with combinations of inputs. Simi-
larly, testing performed at different stages in the software development life cycle
will find different types of defects; component testing is more likely to find coding
logic defects than system design defects.
Each testing technique falls into one of a number of different categories. Broadly
speaking there are two main categories, static and dynamic. Static techniques were
discussed in Chapter 3. Dynamic techniques are subdivided into three more cate-
gories: specification-based (black-box, also known as behavioural techniques),
structure-based
(white-box
or
structural
techniques)
and
experience-based.
Specification-based techniques include both functional and non-functional techni-
ques (i.e. quality characteristics). The techniques covered in the syllabus are sum-
marized in Figure 4.1.
4.2.2 Static testing techniques
As we saw in Chapter 3, static testing techniques do not execute the code being
examined and are generally used before any tests are executed on the software.
They could be called non-execution techniques. Most static testing techniques
can be used to
‘test’ any form of document including source code, design
documents and models, functional specifications and requirement specifications.
However,
‘static analysis’ is a tool-supported type of static testing that concen-
trates on testing formal languages and so is most often used to statically test
source code.
78
Chapter 4 Test design techniques

4.2.3 Specification-based (black-box) testing techniques
The first of the dynamic testing techniques we will look at are the specification-
based testing techniques. These are also known as
‘black-box’ or input/output-
driven testing techniques because they view the software as a black-box with inputs
and outputs, but they have no knowledge of how the system or component is
structured inside the box. In essence, the tester is concentrating on what the software
does, not how it does it.
All specification-based techniques have the common characteristic that they are
based on a model (formal or informal) of some aspect of the specification, which
enables test cases to be derived from them in a systematic way.
Notice that the definition mentions both functional and non-functional testing.
Functional testing is concerned with what the system does, its features or functions.
Non-functional testing is concerned with examining how well the system does
something, rather than what it does. Non-functional aspects (also known as quality
characteristics or quality attributes) include performance, usability, portability,
maintainability, etc. Techniques to test these non-functional aspects are less proce-
dural and less formalized than those of other categories as the actual tests are
more dependent on the type of system, what it does and the resources available
for the tests.
Non-functional testing is part of the Syllabus and is also covered in Chapter 2.
There are techniques for deriving non-functional tests [Gilb 1988], [Testing Stan-
dards], but they are not covered at the Foundation level.
Structure-based
Statement
Decision
Condition
Multiple
Condition
Experience-based
Error
Guessing
Exploratory
Testing
Static
Dynamic
Informal
Reviews
Technical
Reviews
Walkthroughs
Static Analysis
Data Flow
Control Flow
Inspection
Specification-based
Equivalence

tải về 6.34 Mb.

Chia sẻ với bạn bè của bạn: