Scribd
Upload
75 views23 pages

Chapter 7 Static White Box Testing

The document discusses static white box testing, also known as structural analysis, which involves carefully reviewing code without executing it to find bugs early. It describes different types of static reviews like peer reviews, walkthroughs, and inspections. It also discusses coding standards and guidelines and provides a generic checklist for reviewing code, examining for errors like data references, computations, comparisons, control flow, parameters, and input/output. The goal is to find bugs that may be difficult to uncover with dynamic testing alone.

Uploaded by

kamarulzamani
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
75 views23 pages

Chapter 7 Static White Box Testing

The document discusses static white box testing, also known as structural analysis, which involves carefully reviewing code without executing it to find bugs early. It describes different types of static reviews like peer reviews, walkthroughs, and inspections. It also discusses coding standards and guidelines and provides a generic checklist for reviewing code, examining for errors like data references, computations, comparisons, control flow, parameters, and input/output. The goal is to find bugs that may be difficult to uncover with dynamic testing alone.

Uploaded by

kamarulzamani
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 23

1

BTT 310:
SW TESTING &
INSPECTION
Chapter 07: Examining the code – Static White Box
Testing
Contents
 Highlights from this chapter include
 The benefits of static white-box testing

 The different types of static white-box reviews

 Coding guidelines and standards

 How to generically review code for errors


Static white box testing
 Process of carefully and methodically reviewing the software
design, architecture, or code for bugs without executing it.
 It's sometimes referred to as structural analysis.
 Reason: to find bugs early and to find bugs that would be
difficult to uncover or isolate with dynamic black-box testing.
 Side benefit: gives the team's black-box testers ideas for test
cases to apply.
Formal reviews
 Peer Reviews, Walkthrough and Inspections
 4 essential elements
1. Identify Problems - The goal of the review is to find
problems with the software not just items that are wrong,
but missing items as well.
2. Follow Rules - A fixed set of rules should be followed.

3. Prepare - prepare for and contribute to the review.

4. Write a Report - produce a written report summarizing the


results of the review and make that report.
Formal reviews
 Indirect results:
 Communications - Information not contained in the formal

report is communicated.
 Quality - A programmer's code that is being gone over in

detail, function by function, line by line, often results in the


programmer being more careful.
 Team Camaraderie - build respect for each other's skills and

to better understand each other's jobs and job needs.


 Solutions – for tough problems
Peer reviews
 The least formal method. Sometimes called buddy reviews,
this method is really more of an "I'll show you mine if you
show me yours" type discussion.
 Small group: 2 programmers and tester - reviews the code
together and looks for problems and oversights
 4 key elements:
 Look for problems,

 follow rules,

 prepare for the review, and

 write a report
walkthrough
 Medium size group - programmer who wrote the code
formally presents it to a group of five or so other
programmers and testers.
 Participants – The Reviewers, The Presenters
inspection
 most formal type of reviews
 the person who presents the code, the presenter or reader, isn't
the original programmer.
 participants are called inspectors
 tasked with reviewing the code from a different perspective,
such as a user, a tester, or a product support person.
inspection
 Inspection Roles
 Author: The person who created the work product being

inspected.
 Moderator: This is the leader of the inspection. The

moderator plans the inspection and coordinates it.


 Reader: The person reading through the documents, one

item at a time. The other inspectors then point out defects.


 Recorder/Scribe: The person that documents the defects

that are found during the inspection.


 Inspector: The person that examines the work product to

identify possible defects.


Inspection
 Inspection Process
 Planning: The inspection is planned by the moderator.
 Overview meeting: The author describes the background of the
work product.
 Preparation: Each inspector examines the work product to
identify possible defects.
 Inspection meeting: During this meeting the reader reads
through the work product, part by part and the inspectors point
out the defects for every part.
 Rework: The author makes changes to the work product
according to the action plans from the inspection meeting.
 Follow-up: The changes by the author are checked to make sure
everything is correct.
Coding standards & guidelines

 There are also problems where the code may operate properly
but may not be written to meet a specific standard or
guideline.
 Guidelines are the suggested best practices, the
recommendations, the preferred way of doing things.
 Standards have no exceptions, short of a structured waiver
process.
Coding standards & guidelines
 Example 1: A sample
coding standard explains
how several language
control structures should
be used.
Coding standards & guidelines

 The standard has four main parts:


 Title describes what topic the standard covers.

 Standard (or guideline) describes the standard or guideline

explaining exactly what's allowed and not allowed.


 Justification gives the reasoning behind the standard so that

the programmer understands why it's good programming


practice.
 Example shows simple programming samples of how to

use the standard. This isn't always necessary.


Coding standards & guidelines
 An example of a
programming guideline
shows how to use certain
aspects of C in C++.
Generic code review checklist

 The checklists are in addition to comparing the code against a


standard or a guideline and to making sure that the code meets
the project's design requirements.
 Examples:
 Data reference errors
 Data declaration errors
 Computation errors
 Comparison errors
 Control flow errors
 Sub routine parameter errors
 input/output errors
Data reference errors
 Caused by using a variable, constant, array, string, or record
that hasn't been properly declared or initialized for how it's
being used and referenced.
 Is an uninitialized variable referenced? Looking for

omissions is just as important as looking for errors.


 Are array and string subscripts integer values and are they

always within the bounds of the array's or string's


dimension?
Data declaration errors
 Caused by improperly declaring or using variables or
constants
 Are all the variables assigned the correct length, type,

and storage class? For example, should a variable be


declared as a string instead of an array of characters?
 If a variable is initialized at the same time as it's declared,

is it properly initialized and consistent with its type?


Computation errors
 Computational or calculation errors are essentially bad math.
The calculations don't result in the expected result.
 Do any calculations that use variables have different data

types, such as adding an integer to a floating-point number?


 Do any calculations that use variables have the same data

type but are different lengths adding a byte to a word, for


example?
Comparison errors
 Less than, greater than, equal, not equal, true, false.
Comparison and decision errors are very susceptible to
boundary condition problems.
 Are the comparisons correct? It may sound pretty simple,

but there's always confusion over whether a comparison


should be less than or less than or equal to.
 Are there comparisons between fractional or floating-point

values? If so, will any precision problems affect their


comparison? Is 1.00000001 close enough to 1.00000002 to
be equal?
Control flow errors
 Result of loops and other control constructs in the language
not behaving as expected. Caused, directly or indirectly, by
computational or comparison errors.
 If the language contains statement groups such as

begin...end and do...while, are the ends explicit and do they


match their appropriate groups?
 Will the program, module, subroutine, or loop eventually

terminate? If it won't, is that acceptable?


Subroutine parameter errors

 Due to incorrect passing of data to and from software


subroutines.
 Do the types and sizes of parameters received by a

subroutine match those sent by the calling code? Is the


order correct?
 If a subroutine has multiple entry points, is a parameter

ever referenced that isn't associated with the current point


of entry?
Input/output errors
 Related to reading from a file, accepting input from a
keyboard or mouse, and writing to an output device such as a
printer or screen.
 Does the software strictly adhere to the specified format of

the data being read or written by the external device?


 If the file or peripheral isn't present or ready, is that error

condition handled?
Other checks
 Will the software work with languages other than English?
Does it handle extended ASCII characters? Does it need to use
Unicode instead of ASCII?
 If the software is intended to be portable to other compilers
and CPUs, have allowances been made for this? Portability, if
required, can be a huge issue if not planned and tested for.

You might also like