1. Chapter 13: Implementation Phase 13.3 Good Programming Practice 13.6 Module Test Case Selection 13.7 Black-Box Module-Testing Techniques 13.8 Glass-Box Module-Testing Techniques Implementation - The process of translating the detailed design into code Programming in the Many - Implementation of a program by a team of individuals July 19, 2000

2. Good Programming Practice  Many recommendations on good coding style are language specific  Language-independent good programming practice  Use consistent and meaningful variable names  Use a language that everyone can understand  Be consistent with the variable names averagefreq, minfr, and frqncytotl  Do not use two different names to denote the identical concept average and mean  Keep ordering consistent Frequencymax, minfrequency  The name of a variable should incorporate type information PtrChTmp - temporary variable of type pointer to an character Hungarian naming convention

3. Good Programming Practice (2)  The issue of self-documenting code  Very hard to achieve, but feasible  Just because the code is self-documenting to one developer does not mean it is self-explanatory to anyone else –SQA Group –Maintenance programmers –inexperienced programmers  Prologue comments - at the top of a module –module name; a brief description of what the module does; programmer’s name; date module was coded; date module was approved and by whom; module parameters; list of variable names and their uses; names of files accessed; input/output; error-handling capabilities; file containing test data; list of modifications made, their dates, and who approve them; and known faults  Use inline comments to explain the difficult sections of code

4. Good Programming Practice (3)  Use of parameters  Remember there are few true constants Pi = 3.141592...  Values that are not genuine constants Solution: declare one variable and use it. If the value changes, only one value will be changed Examples –public static final float salesTaxRate = (float) 6.0;

5. Good Programming Practice (4)  Code layout for increased readability  Use one line per statement  Use indentation CASE tools should be used to ensure that indentation is done correctly  Use blank lines to separate logical areas of code

6. Good Programming Practice (5)  Nested if statements  Use a formatting style Figures 13.2, 13.3, and 13.5  if-if constructs if Try to use a logical “and” construct if and  As a general rule, do not nest if statements more than three levels deep

7. Module Test Case Selection  Two types of testing - informal and methodical  Informal testing is carried out by the programmer at time of module creation  Methodical testing is done by the SQA group  Nonexecution-based and execution-based testing  Execution-based testing - module is run against test cases  Two ways of constructing test cases to test a module  Testing to specifications (TTS)  Black box testing (functional, input/output-driven, behavioral)  Source code is ignored  The specification document is used design the test cases  Testing to code (TTC)  Glass box testing (white-box, logical-driven, path-oriented, structural)  Analyze the source code  Ignore the specification document when drawing up the test cases

8. Feasibility of TTS and TTC  Feasibility of “Testing to Specifications”  20 inputs with 4 different values can lead to 1.1x10 12 (4 20 ) test cases  The number of possible combinations with n inputs is exponential  Assume it takes 30 seconds to generate, run, and examine each test case - one million years to test the product exhaustively  Exhaustive testing to specifications is impossible  Feasibility of “Testing to Code”  All paths must be executed and tested once; even trivial modules may have millions of paths to test (Figure 13.6) 5 1 + 5 2 + 5 3 +..+5 18 =4.77*10 12  Not a very reliable method - it is possible to exercise every path without detecting every fault in the product (Figure 13.7)  Paths can only be tested if present (Figure 13.8)

9. Feasibility of TTS and TTC (2)  Then, what’s the solution?  We need testing techniques that will highlight as many faults as possible, while accepting that there is no way to guarantee that all faults have been detected  Use black-box test cases first and then develop additional test cases using glass-box techniques

10. Black-Box Module-Testing Techniques  Suppose the specifications for a database product state that the product must be able to handle any number of records from 1 through 16,383  If the product works correctly for any one test case in the range from 1 to 16,383, then it will probably work for any other test case in the range  Equivalence class - a set of test cases such that any one member of the class is as good a test case as any other member of the class  Select one test case from EACH equivalence class  EC 1: Less than 1 record  EC 2: From 1 through 16,383 records  EC 3: More than 16,383 records  A successful test case is one that detects a previously undetected fault

11. Black-Box Module-Testing Techniques (2)  Experience has shown that when a test case that is on or just to one side of the boundary of an equivalence class is selected, the probability of detecting a fault increases - boundary value analysis  When testing the database product, seven test cases (TCs) should be selected  TC1: 0 record  TC2: 1 record  TC3: 2 records  TC4: 723 records  TC5: 16,382 records  TC6: 16,383 records  TC7: 16,384 records  In general, for each range (R1, R2) listed in either the input or the output specifications, five test cases should be selected, corresponding to values less than R1, equal to R1, (R1, R2), equal to R2, greater than R2

12. Black-Box Module-Testing Techniques (3)  An alternative form of black-box testing is to base the test data on the functionality of the module - functional testing  In functional testing, each item of functionality of function implemented in the module is identified  After determining all the functions of the module, test data are derived to test each function separately  If the module consists of a hierarchy of lower-level functions, connected together by the control structures of structured programming, then functional testing proceeds recursively ::=if ; else ;

13. Glass-Box Module-Testing Techniques  Test cases are selected on the basis of examination of the code  Glass-box testing techniques: statement coverage, branch coverage, and path coverage  Statement coverage  Each statement is executed at least once  No guarantee that all outcomes of branches are properly tested (Figure 13.9)  Branch coverage  All branches are tested at least once  Path coverage  All paths are tested at least once  Powerful, but the number of paths in a product with loops can be very large

14. Glass-Box Module-Testing Techniques (2)  Selecting paths  Restrict test cases to linear code sequence [Woodward et al., 1980] Identify all points (L) that control flow may jump (entry, exit, branch, goto) Identify all paths that begin at an element of L and end at an element of L  All-definition-use path coverage [Rapps and Weyuker, 1985] Identify all paths between the definition of a variable and the use of that definition A test case is set up for each such path All-definition-use path coverage is a practical test case selection technique  Infeasible paths - Figure 13.10