程序代写 Test Techniques

Test Techniques
Lecture 04

By the end of this chapter

Recap – Software Maintenance
Explain the characteristics, commonalities and differences between black-box test techniques, white-box test techniques and experience-based techniques.

What sort of problems do we ﬁnd
management gets new ideas
organisation looks for new beneﬁts
users suggest improvements
business processes change
software suppliers make new releases
developers see how could have been done better
hardware and software platforms get updated
the regulatory framework and law change
software must co-evolve with the organisation it supports

software evolution work
corrective maintenance: diagnosis and ﬁxing of errors
adaptive maintenance: making it work properly following
changes in the environment
perfective maintenance: adding new functions and
enhancing existing functions
preventive maintenance: making sure that future changes
can be done more rapidly and easily

Class Exercise
What type of software maintenance and evolution activity does each
represent?
A text-based word processor needs a speech recognition module
implemented and incorporated into it.
An operating system needs a missing driver implemented for it.
Sales point software needs to be changed to support the latest security
identiﬁcation procedures for credit and debit cards.
An email program needs to be changed to make it robust against a new
type of software virus to which it is vulnerable.
Spreadsheet software has a malfunction which prevents a particular
function from being accessed by the user.
corrective
perfective
preventive

Class Exercise
What type of software maintenance and evolution activity does each represent?
A text-based word processor needs a speech recognition module implemented and
incorporated into it.
Perfective, clearly a speech recognition module is a new function for an otherwise text- based word processor.
An operating system needs a missing driver implemented for it.
Perfective, since a new driver represents an improvement in capability for the operating
system ; however it might be considered adaptive.
Sales point software needs to be changed to support the latest security
identiﬁcation procedures for credit and debit cards.
Adaptive, changes in legislation and business practices can be seen as changes in the external environment of the software and hence their implementation represents adaptive changes.

Class Exercise
What type of software maintenance and evolution activity does each represent?
An email program needs to be changed to make it robust against a
new type of software virus to which it is vulnerable.
Adaptive, since a new software virus potentially present in the environment of the software represents a change in that environment, hence the adaptive nature of this change.
Spreadsheet software has a malfunction which prevents a
particular function from being accessed by the user.
Corrective, since it consists of ﬁxing a defect.

Categories of test techniques and their Characteristics

Common characteristics of black box testing
Test Conditions, test cases and test data are derived from
a test basis that may include software requirements, specifications, use cases and user stories.
The source of information for black-box test is come description of what the system or software is supposed to do.
Test cases may be used to detect gaps between the requirements and the implementation of the requirements as we all deviations for the requirements.
Coverage is measured based on the items tested in the test basis and the technique applied to the test basis. Coverage at black box level is based on items from the test basis.

White box testing
Test Conditions, test cases and test data are derived from
a test basis that may include code, software architecture, detailed design or any other source of information regarding the structure of the software.
Coverage is measured based on the items tested within a selected structure for example the code statements, the decisions, the interfaces, the menu structure or any other identified structural element.
White box test techniques determine the path through the software that either was taken or that you want to be taken and this is determined by specific inputs to the software.

Basic Testing Strategies
Testing Strategy Tester’s View Knowledge Source Techniques
Black-box Requirement
Specification
Domain Knowledge Equivalence Partitioning
Boundary Value Analysis
Decision Table
Error Guessing
State Transition Testing

White-box Low-level design
Internal Structure
Source code Statement Coverage
Branch Coverage
Condition Coverage

Black-box vs. White-box
External/User View;
Internal behaviour is unknown
Examines functionality based on
specification

Also known as;
Closed box testing, data driven testing,
functional testing

Performed by;
Testers and End users

Least time consuming and exhaustive
not suited for algorithm testing
Internal/Developer View;
Internal workings are fully known
Examines program structure and derives
test data from program logic/code

Also known as;
Clear box testing, structural testing,
code-based testing

Performed by;
Testers and developers

Most time consuming and exhaustive
(suited for algorithm testing)

Black-box vs. White-box
External/User View;
Internal behaviour is unknown
Examines functionality based on
specification

Also known as;
Closed box testing, data driven testing,
functional testing

Performed by;
Testers and End users

Also known as;
Clear box testing, structural testing,
code-based testing

Performed by;
Testers and developers

Most time consuming and exhaustive
(suited for algorithm testing)

Gray-box Testing

Mix of Internal + External View;
Testers have limited knowledge of the internal
workings of the software (e.g., using high level database
diagrams and data flow)

Black-box vs. White-box

specification
implementation
Missing functionality:
Cannot be directly revealed by white-box techniques
Unexpected functionality:
Cannot be directly revealed by black-box techniques

Types of Testing
Level of Detail
Accessibility
Characteristics
integration
functionality
reliability
efficiency
maintainability
portability

Black-box testing techniques
Equivalence Partitioning (EP)
Boundary Value Analysis (BVA)
Decision Table (will cover at the later lecture)
Error Guessing
State Transition Testing (will cover at the later lecture)

Equivalence
Partitioning
Split input/output test conditions into a partition that can be considered the same
Select test cases to cover from each partition

Equivalence
Partitioning #1
Requirement;
“The customer is eligible for a life insurance discount, 5% if they are at least 18 and 25, 3% if they are over 25 and no older than 65 years of age”

Equivalence Partitioning #2

Age[18…..25]
Age[26…..65]
Age[over 65]
Age[under 18]
Partition3
Partition1
Partition2
Partition4
range[18….25]
Range[26…65]

Equivalence Partitioning #3

Partition3
Partition1
Partition2
Partition4
Which covers EP?
(10, 40, 60)
(10, 20, 40, 80)
(15, 20, 40, 60)
(20, 40, 60, 80, 100)

range[18….25]
Range[26…65]

Equivalence Partitioning #4

Partition3
Partition1
Partition2
Partition4
Problem with EP: errors more common at boundary values, either just below, just above, or specially on the boundary values
range[18….25]
Range[26…65]

Boundary Value
Adds to the equivalence partitioning
Select test cases to represent each side of the partition boundaries

Boundary Value Analysis #1
For each boundary, we test +/- 1 in the least significant digit of either side of the boundary
Boundary limit -1
Boundary limit
Boundary limit +1

Boundary Value Analysis #2
Previous example with BVA;
range[18….25]
Range[26…65]

Boundaries
Test values with; 17, 18, 19, 24, 25, 26, 64, 65,66, all be valid for BVA

Boundary Value Analysis #3
Other error conditions to consider;
A typical mid range value (e.g., 37)
Zero (since divide by 0 errors can occur)
Negative values
Numbers out of range by a long way (e.g., 1000 years of age)
Illegal data entries like “nineteen” as letters
Illegal characters such as # $ % @ ..

Often EP and BVA are used together
Partition3
Partition1
Partition2
Partition4
range[18….25]
Range[26…65]
Test Cases to cover EP, BVA, and others?
EP; typical mid range values (10, 21, 45, 80) and random values in the range (3, 19, 40, 70),
BVA; boundary limits (17-19,24-26,64-66),
Others (-10, 0, seventeen, 1000, special characters etc.,)

Decision Table
Effective when different combinations of inputs result in different actions being taken
Decision table associates conditions with actions to perform
Similar to flowchart, if-then-else, switch-case statements
A decision table lists causes and effects in a matrix

Decision Table #1
Requirements:
“Enable the flight button only if both fly-from and fly-to fields are entered”
Conditions
Rule1 Rule2 Rule3 Rule4
Flight Button

Figure. Decision Table Template

Decision Table #2
Conditions
Rule1 Rule2 Rule3 Rule4
Fly from F
Flight Button F

Rule 1: neither “fly-from” nor “fly-to” entered

Decision Table #3
Conditions
Rule1 Rule2 Rule3 Rule4
Fly from F T
Fly to F F
Flight Button F F

Rule 2: fly-from is entered but not fly-to

Decision Table #4
Conditions
Rule1 Rule2 Rule3 Rule4
Fly from F T F
Fly to F F T
Flight Button F F F

Rule 3: fly-from not entered but fly-to entered

Decision Table #5
Conditions
Rule1 Rule2 Rule3 Rule4
Fly from F T F T
Fly to F F T T
Flight Button F F F T

Rule 4: both fly-from and fly-to entered

State Transition testing
It is used when some of the aspects of the system can be described in what is called a “finite state machine”.
This means that system can be in a limited number of different states and transition from one to another are determined by the rules of the machine.

For example: Open, close (any software application), Bank account (sufficient funds, insufficient funds- funds will only be dispensed when you have sufficient amount)

State Transition Testing
Useful to create test cases where you get a different output for the same input, depending on what has happened before
A state transition model has basic parts:
the states that the software may occupy
the transitions from one state to another
the events that cause a transition

State transition diagram #1
Transition

State Name
Close Door

transitions

State transition diagram #2
ATM machine PIN Entry

Use-case Testing
Identify test cases that exercise the whole system focus on the actors (typically users).
The focus of the tests are actors not systems.
A use case is a description of a particular use of the system by an actor
Each use case describes the interactions the actor has with the system in order to achieve a specific task.

Use Case Testing

Main Success Scenario
S: System Step Description
1 A: insert card
2 S: Validates card and asks for PIN
3 A: Enters PIN
4 S: Validates PIN
5 S: Allows access to account

Extensions 2a Card not valid
S: Display message and reject card
4a PIN not valid
S: Display message and ask for re-try (twice)
4b PIN invalid 3 times
S: Eat card and exit

Structural Testing
Testing of the structure of the system
Often referred as White-box testing
Statement Coverage
Decision Coverage

White Box Testing
What is the concept of coverage?
How it can be used to measure some aspects of the thoroughness of testing?
How to measure coverage of statements and decisions?
How to write test cases to extend coverage if this is not 100%?

Types of Testing
Level of Detail
Accessibility
Characteristics
integration
functionality
reliability
efficiency
maintainability
portability
Structures such as statements, decisions, branches or distinct paths.
Structures such as the call tree, diagram showing how modules call one another.
Structures such as a menu structure, business process or web page structure.
Coverage measurement
Structural test case design

What is coverage?
Coverage measures the amount of testing performed by a set of tests that may have been derived in a different way, e.g. using Blackbox techniques.
Coverage = Number of coverage items exercised X 100%
Total Number of Coverage Items

Where coverage item is whatever we have been able to count and see whether a test has exercised or used this item.

Code Coverage Analysis
Goal: define test cases to cover as many (disjoint) code items as possible
It is a major white-box testing technique
Finding areas of a program not exercised by test cases
Creating additional test cases to increase code coverage
Determining a quantitative measure of code coverage, believe to be a predictor of code quality

Two kinds of basic program statements:
Assignment statements (e.g. x = 2*y; )
Conditional statements (e.g. if(), for(), while(), …)
Control flow
Successive execution of program statements is viewed as flow of control.
Conditional statements alter the default flow.
Program path
A program path is a sequence of statements from entry to exit.
There can be a large number of paths in a program.
There is an (input, expected output) pair for each path.
Executing a path requires invoking the program unit with the right test input.
Paths are chosen by using the concepts of path selection criteria.
Tools: Automatically generate test inputs from program paths.
What is Control-Flow?

Control Flow
Control flow depicts a program as a graph which consists of Nodes and Edges
Nodes represent Processing Tasks
Edges represents control flow (between the nodes)

Outline of Control Flow Testing

Code Coverage Analysis
Requirement
“Reject male insurance applicants, if aged over 80, reject female insurance applicants, if aged over 85”
Different coverage methods
Statement Coverage
Decision Coverage

Statement Coverage
The percentage of executable statements that have been exercised by a test suit.
Execute each statement at least once
Find shortest path such that all “nodes” are covered at-least once
Weakest form of coverage

Statement Coverage =
Total number of statements
Number of executed statements

Statement Coverage
Method AccClient(gender, age)
IF (female and age<85) return (true) IF (male and age<80) return (true) return (false) Statement Coverage Method AccClient(gender, age) IF (female and age<85) return (true) IF (male and age<80) return (true) return (false) AccClient(female, 82) -> Accept

Statement Coverage
Method AccClient(gender, age)
IF (female and age<85) return (true) IF (male and age<80) return (true) return (false) AccClient(female, 82) -> Accept
AccClient(male, 82) -> Reject

Statement Coverage
Method AccClient(gender, age)
IF (female and age<85) return (true) IF (male and age<80) return (true) return (false) AccClient(female, 82) -> Accept
AccClient(male, 82) -> Reject
AccClient(male, 25) -> Accept

Decision Coverage
Also known as Branch Coverage
Execute each branch at least once
Find shortest path such that all “edges” are covered at-least once
Branch is a decision point
Each decision point must have both TRUE and FALSE outcome at least once

Branch Coverage =
Total number of decision outcomes
Number of executed decision outcomes

Decision Coverage
Method AccClient(gender, age)
IF (female and age<85) return (true) IF (male and age<80) return (true) return (false) Decision Coverage Method AccClient(gender, age) IF (female and age<85) (d1) return (true) IF (male and age<80) (d2) return (true) return (false) AccClient(female, 82) -> Accept

Decision Coverage
Method AccClient(gender, age)
IF (female and age<85) (d1) return (true) IF (male and age<80) (d2) return (true) return (false) AccClient(female, 82) -> Accept
AccClient(male, 82) -> Reject

Experienced-based test techniques
Error guessing
Exploratory testing
Checklist-based testing

Error guessing
A test technique in which tests are derived on the basis of the tester’s knowledge of past failures, or general knowledge of failure modes.
May be based on :
How the application has worked in the past?
What types of mistakes the developers tend to make?
Failures that have occurred in other applications.

Exploratory testing
An approach to testing whereby the testers dynamically design and execute tests based on their knowledge, exploration of the test item and the results of previous tests.
Testers are doing minimum planning and maximum test planning.

Checklist-based testing
An experienced-based test technique whereby the experienced tester uses a high-level list of items to be noted, checked, or remembered, or a set of rules or criteria against which a product has to be verified.
Experience of the tester
Knowledge for example what is important for the user
Understanding of why an how software fails

Choosing test techniques
Which technique is best?

Factors that influence the decision about which technique to use?

Type of component/system

What type of component or application is under testing?

A financial application involving calculations would benefit from boundary value analysis.

Component Complexity

More complex more defects, harder to find defects.

A screen with many fields is good candidate for decision table testing, state transition testing and white box testing.

Regulatory standards

Some industries have regulatory standards that govern the test techniques.

Aircraft industry requires the use of equivalence partitioning, boundary value analysis and state transition testing for high integrity system.

Customer or Contractual requirements

Sometimes contracts specify test techniques to use.

Statement or branch coverage

Risk levels and risk types

Greater the risk level, the greater is the need for formal testing.

Commercial risk may be influenced by quality or by time to market issues.

Factors that influence the decision about which technique to use?

Test Objectives

Only to gain confidence or thorough testing

Use cases or rigorous techniques such as white box testing.

Available documentation

Whether or not the test document exists, and how up-to-date it is will affect the choice of test techniques.

If state graphs and decision tables are used then relevant test techniques should be used.

Tester knowledge and skills

How much testers know about the system, and test technique clearly has an effect on their choice of test technique.

程序代写 CS代考加微信: powcoder QQ: 1823890830 Email: powcoder@163.com

Related Posts