Software Testing

Unit-III Code Examination

Notes edited and compiled by Prof. Mohan S. Khedkar

Static White-Box Testing: Examining the Design
and Code
• 1.Static white-box testing is the process of carefully and
methodically reviewing the software design, architecture, or code for
bugs without executing it.

• 2.It’s sometimes referred to as structural analysis.

• 3.Advantage of static white-box testing is that it gives the team’s

black-box testers ideas for test cases to apply when they receive the
software for testing.

• 4.They may not necessarily understand the details of the code, but
by listening to the review comments they can identify feature areas
that sound troublesome or bug-prone.
Formal Review
A formal review can range from a simple meeting between two
programmers to a detailed, rigorous inspection of the code.
There are four essential elements to a formal review
• 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. All criticism
should be directed at the code, not the person who created it.

• 2. Follow Rules: - A fixed set of rules should be followed. Set the amount of code
to be reviewed (usually a couple hundred lines), how much time will be spent (a
couple hours), what can be commented on, and so on.

• 3. Prepare: - Each participant is expected to prepare for and contribute to the

review. Participants may have different roles and responsibilities .They should be
ready to actively fulfill them at the review.

• 4. Write a Report: - The review group must produce a written report summarizing
the results of the review and make that report available to the rest of the product
development team.—how many problems were found, where they were found,
and so on.
Type of Reviews
1. Peer Reviews
2. Walkthrough
3. Inspection

• Peer Reviews
1. The easiest way to get team members together and doing their first formal
reviews of the software is through peer reviews, the least formal method.

2. Peer reviews are often held with just the programmer who wrote the code and
one or two other programmers or testers acting as reviewers.

3. Small group simply reviews the code together and looks for problems and
oversights.

4. To assure that the review is highly effective all the participants need to make sure
that the four key elements of a formal review are in place: Look for problems,
follow rules, prepare for the review, and write a report.
Walkthrough
• Walkthroughs are the next step up in formality from peer reviews.
• In a walkthrough, the programmer who wrote the code formally
presents (walks through) it to a small group of five or so other
programmers and testers.

• In walkthrough, a review team does not require to do detailed

study before meeting while authors are already in the scope of
preparation.

• Make the document available for the stakeholders both outside

and inside the software discipline for collecting the information
about the topic under documentation.
• Study and discuss the validity of possible alternatives and
proposed solutions.
Structured Walkthrough Participants:
• Author - The Author of the document under review.

• Presenter - The presenter usually develops the agenda for the

walkthrough and presents the output being reviewed.

• Moderator - The moderator facilitates the walkthrough session,

ensures the walkthrough agenda is followed, and encourages all the
reviewers to participate.

• Reviewers - The reviewers evaluate the document under test to

determine if it is technically accurate.

• Scribe - The scribe is the recorder of the structured walkthrough

outcomes who records the issues identified and any other technical
comments, suggestions, and unresolved questions.
Inspection
• The trained moderator guides the Inspection. It is most formal type of
review.
• The reviewers are prepared and check the documents before the meeting.

• In Inspection, a separate preparation is achieved when the product is

examined and defects are found. These defects are documented in issue
log.
• In Inspection, moderator performs a formal follow-up by applying exit
criteria.

• Inspections have proven to be very effective in finding bugs in any software

deliverable, especially design documents and code, and are gaining
popularity as companies and product development teams discover their
benefits.
Coding Standards and Guidelines
• Standards are the established, fixed, have-to-follow-the rules—the
do’s and don’ts.
• Guidelines are the suggested best practices, the recommendations,
the preferred way of doing things.
• Standards have no exceptions, short of a structured waiver process.
Guidelines can be a bit loose.
• There are three reasons for adherence to a standard or guideline:
1. Reliability: - It’s been shown that code written to a specific
standard or guideline is more reliable and bug-free than code that
isn’t.
2. Readability/Maintainability: - Code that follows set standards and
guidelines is easier to read, understand, and maintain.
3. Portability: - Code often has to run on different hardware or be
compiled with different compilers.
Generic Code Review Checklist
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.

• Data Reference Errors :- Data reference errors are bugs caused by

using a variable, constant, array, string, or record that hasn’t been
properly initialized for how it’s being used and referenced.

• Data Declaration Errors : - Data declaration bugs are caused by

improperly declaring or using variables or constants

• Computation Errors : - Computational or calculation errors are

essentially bad math. The calculations don’t result in the expected
result.
Generic Code Review Checklist
• Comparison Errors : - Comparison and decision errors are very
susceptible to boundary condition problems.

• Control Flow Errors : - Control flow errors are the result of loops and
other control constructs in the language not behaving as expected.

• Subroutine Parameter Errors : - Subroutine parameter errors are due

to incorrect passing of data to and from software subroutines.

• Input / Output Errors : - These errors include anything 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. The items
presented here are very simplified and generic.
Dynamic White Box Testing
• Dynamic White Box Testing is about testing a running program and since it’s
white-box, it must be about looking inside the box, examining the code, and
watching it as it runs.
• It is also known as structural testing
• The four areas that dynamic white-box testing encompasses are:
1. Directly testing low-level functions, procedures, subroutines, or
libraries. In Microsoft Windows, these are called Application
Programming Interfaces (APIs).
2. Testing the software at the top level, as a completed program, but
adjusting your test cases based on what you know about the software’s
operation.
3. Gaining access to read variables and state information from the
software to help you determine whether your tests are doing what you
thought.
4. Measuring how much of the code and specifically what code you “hit”
when you run your tests and then adjusting your tests to remove
redundant test cases and add missing ones.
Testing the Pieces
• In “The Software Development Process,” there are the various models for
software development.
• In big-bang model, everything was put together at once and, with fingers
crossed, the team hoped that it all worked and that a product would be
born.
• Testing in such a model would be very difficult.
• Unit and Integration Testing
• As a large project or an application software is divided into small modules
or units to reduce the complexity and to minimize the failure rate of the
software.
• Unit testing tests all the modules separately for the functionality and the
correctness of each module.
• The integration testing is than implemented .
Dynamic White Box Testing

Individual pieces of code are built up and tested separately, and then integrated
and tested again.
Data Coverage
1. The logical approach is to divide the code just as you did in black-box
testing into its data and its states (or program flow).

2. By looking at the software from the same perspective, you can more
easily map the white-box information you gain to the black-box cases
you’ve already written.

3. Consider the data first. Data includes all the variables, constants, arrays,
data structures, keyboard and mouse input, files and screen input and
output, and I/O to other devices such as modems, networks, and so on.

4. The declaration of data is complete with the assignment statement and

the variable declaration statements.

5. All the variable declared are properly utilized.

Data Flow
1. Data flow coverage involves tracking a piece of data completely through
the software.
2. At the unit test level this would just be through an individual module or
function.
3. The same tracking could be done through several integrated modules
or even through the entire software product—although it would be
more time-consuming to do so.
4. With dynamic white-box testing, check intermediate values during
program execution.
5. Based on what you see you might decide to change some of your test
cases to make sure the variable takes on interesting values.
6. During data flow , the check is made for the proper declaration of
variables declared and the loops used are declared and used properly.
Sub-Boundaries
1. Sub-boundaries that can cause bugs, but every piece of software will
have its own unique sub-boundaries too.

2. E.g. An operating system running low on RAM may start moving data to
temporary storage on the hard drive. This sub-boundary may not even
be fixed. It may change depending on how much space remains on the
disk.
3. If you perform white-box testing, you need to examine the code
carefully to look for sub-boundary conditions and create test cases that
will exercise them.

4. Ask the programmer who wrote the code if he/she knows about any of
these situations and pay special attention to internal tables of data
because they’re especially prone to sub-boundary conditions.
Formula and Equations
1. Very often, formulas and equations are buried deep in the code and
their presence or effect isn’t always obvious from the outside.
2. A financial program that computes compound interest will definitely
have this formula somewhere in the software:
3. A=P(1+r/n)^nt
where
• P = principal amount
• r = annual interest rate
• n = number of times the interest is compounded per year
• t = number of years
• A = amount after time t
4. A good black-box tester would hopefully choose a test case of n=0, but
a white-box tester, after seeing the formula in the code, would know to
try n=0 because that would cause the formula to blow up with a divide-
by-zero error.
Error Forcing

1. Testing the software in a debugger has the ability to watch variables

and see what values they hold.

2. In the preceding compound interest calculation, if you couldn’t find a

direct way to set the number of compounding (n) to zero, you could use
your debugger to force it to zero.

3. The software would then have to handle it or not.

Code Coverage
1. Attempt to enter and exit every module, execute every line of code,
and follow every logic and decision path through the software.

2. Examining the software at this level of detail is called code-coverage

analysis.

3. Program Statements and Line Coverage : -

• Goal is to make sure that you execute every statement in the program
at least once.
• It is a good measure of testing each part in terms of statements but it
is not a good technique for testing the control flow.
4. Branch Coverage:
• It is also known as Decision coverage testing.

• It aims to test all the branches or edges at least once in the test
suite or to test each branch from a decision point at least once.

• It provides solution for the problem faced in Statement coverage.

5. Condition Coverage:
• It aims to test individual conditions with possible different
combination of Boolean input for the expression.

• It provides better coverage and the problem discussed under

Branch coverage can be resolved
Dynamic White Box Testing versus Debugging
1. The goal of dynamic white-box testing is to find bugs.
• The goal of debugging is to fix them.

2. They do overlap, however, in the area of isolating where and why the bug
occurs.
3. Software tester, narrow down the problem to the simplest test case that
demonstrates the bug. So, it includes information about what lines of code look
suspicious.
• The programmer who does the debugging picks the process up from there,
determines exactly what is causing the bug, and attempts to fix it.

4. While performing this low-level testing, both will use many of the same tools.
• If the program is compiled, you will use the same compiler but possibly with
different settings to enable better error detection.
• E.g. using a code-level debugger to single-step through the program, watch
variables, and set break conditions, and so on.
 Thank You
S/W Testing Notes edited and compiled by Prof. Mohan
S. Khedkar