Chapter 6 Examining the Code

Examining the Code
Chapter 6

Scenarios
 Military
 Financial
 Factory automation
 Medical software
 Disciplined development model

Highlights
 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: Examining
the Design and Code
 Review: Static testing and dynamic testing
 Static white-box testing
 Process of carefully and methodically reviewing the
software design, architecture or code for bugs without
executing it
 Structural analysis
 Find bugs early and find bugs that would be difficult
to uncover or isolate with dynamic black box testing
 Side benefit: give black-box tester ideas for test
cases to apply

Formal Reviews
 Four essential elements
 Identify Problems
 Be directed to the design or code, not the person
created it
 Follow Rules
 Amount, time, and comment
 Prepare
 Know duties and responsibilities
 Write a Report
 Summarizing the results of the review

Formal Review (2)
 A few indirect results of formal review:
 Communications
 Black-box tester --- Where problems may lie
 Inexperienced programmers --- Learn new techniques
 Management --- better feel
 Quality
 More careful work attitude for programmers
 Team Camaraderie
 Build respect to each other’s skills and to be better
understand each other’s jobs and job needs
 Solutions
 Solutions may be found for tough problems

Peer Reviews
 Easiest way
 Least formal method
 People
 The programmer who designed the architecture or
wrote the code and one or two other programmers or
testers acting as reviewers
 Action
 Review the code together and looks for problems and
oversights
 Don’t turn it into a coffee break
 Make sure the four key elements are in place
 Better than nothing

Walkthroughs
 Up in formality from peer reviews
 People
 Programmer who wrote the code
 formally presents it to a small group of five or so other
programmers and testers
 Action
 Receive copies in advance and get preparation
 Presenter reads through and explain
 Ask at the review
 Presenter writes a report about bugs and solutions
 At least one senior programmer as reviewer

Inspections
 Most formal type of review
 People
 Presenter or reader
 Isn’t the original programmer
 Forces some else to learn and understand with
different slant and interpretation
 Inspector
 Act as different roles (user, tester or product support
team)
 Different views reveals different bugs
 Even backward inspector
 Modulator and recorder
 Assure the rule
 Assure the effectiveness

Inspections (2)
Do
inspection meeting;
programmer makes change;
moderator verifies change;
while (inspection result == false OR critical level
== high)

Coding Standards and Guidelines
 Classic bugs
 Something just won’t work as written
 Careful analysis by senior programmers and testers
 Code may operate properly but may not be written to
meet a specific standard or guidelines
 Grammatical and syntactical rules
 Established, fixed, have-to-follow rules
 Best practice
 National and international standards
 Why change the workable and stable software?
 Reliability
 Readability/Maintainability
 Portability

Example of Programming Standards
and Guidelines
 Standard about using goto, while, and if-else in C
language
 Four main parts of the standard
 Title
 Standard
 What’s allow and not allowed
 Justification
 Example
 Simple programming example
 The differentiating factor is style
 Even style could possibly become company standard

Obtaining Standard
 American National Standards Institute (ANSI)
 http://www.ansi.org
 International Engineering Consortium (IEC)
 http://www.iec.org
 International Organization for Standardization (ISO)
 http://www.iso.ch
 National Committee for Information Technology
Standards (NCITS)
 http://www.ncits.org
 Some best practice in the industrial
 Your companies’ own standards

Generic Code Review Checklist
 Checklist
 Covers some problems you should look for
 You MUST have some programming
experience
 GET YOUR HAND DIRTY

Data Reference Errors
 Bugs caused by improperly using variable, constant , array,
string or record
 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
 Are there any potential “off by one” errors in indexing
operations or subscript references to arrays
 Is a variable used where a constant would actually work
better
 Is a variable ever assigned a value that ’s of a different type
than the variable?
 Is memory allocated for referenced pointers?
 If a data structure is referenced in multiple functions or
subroutines, is the structure defined identically in each one?

Data Declaration Error
 Bugs caused by improperly declaring or usng
variables or constants
 Are all variables assigned the correct length, type, and
storage class?
 If a variable is initialized at the same time as it’s
declared, is it properly initialized and consistent with its
type?
 Are there any variables with similar names?
 Are any variables declared that are never referenced
or are referenced only once?
 Are all the variables explicitly declared within their
specific module? Or higher module?

Computation Errors
 Bad math
 Do any calculations that use variables have different data types?
 Do any calculations that use variables have the same data type but are
different lengths?
 Are the compiler’s conversion rules for variables or inconsistent type or
length understood and taken into account?
 Is the target variable of an assignment smaller than the right-hand
expression?
 Is overflow or underflow in the middle of a numeric calculation possible?
 Is it ever possible for a divisor/modulus to be zero?
 In case of integer arithmetic, result in loss of precision?
 Can a variable’s value go outside its meaningful range?
 For expressions containing multiple operators, is there any confusion
about the order of evaluation and is operator precedence correct? Are
parentheses needed for clarification?

Comparison Errors
 Susceptible to boundary condition problems
 Are the comparison correct?
 < OR <=
 Are there comparison between fractional or floatingpoint
value?
 Does each Boolean expression state what it should
sate? Does the Boolean calculation work as expected?
Is there any doubt about the order of evaluation?
 Are the operands of a Boolean operator Boolean?
 Especially in language like C

Control Flow Errors
 Usually caused directly or indirectly by
computational or comparison errors
 Are the end explicit and do they match?
 Will the block eventually terminate?
 Possibility of premature loop exit?
 Possibility that a loop never executes?
 Can index variable ever exceed the number of
branch possibilities like switch?
 Are there any “off by one” errors that would
cause unexpected flow through the loop?

Subroutine Parameter Errors
 Due to incorrect passing of data to and from subroutines
 Do the types and sizes of parameters received match by the
calling order?
 If a subroutine has multiple entry points, is a parameter ever
referenced that isn’t associated with the current point of
entry?
 If constants are ever passed as arguments, are they
accidentally changed in the subroutine?
 Does a subroutine alter a parameter that ’s intended only an
input value?
 Do the units of each parameter match the units of each
corresponding argument?
 If global variable are present, do they have similar definitions
and attributes in all referencing subroutines?

Input/Output Errors
 Does 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 condtion handled?
 Does the software handle the situation of the external
device being disconnected, not available, or full
during a read or write?
 Are all conceivable errors handled by the software in
an expected way?
 Have all error messages been checked for
correctness, appropriateness, grammar, and spelling?

Other Checks
 Language issue?
 Portable issue?
 Compatibility?
 Compilation?