Coding and testing In Software Engineering

Coding and testing In Software Engineering

• 1.
  Dr. Satya BhushanVerma Assistant Professor
• 2.
   Coding Standardand Guidelines  Code Review  Code walk-through  Code inspection  Testing  Design of Test Cases  Black-box testing  White Box testing
• 3.
   Good softwaredevelopment organization usually develop there own coding standard and guidelines depending on what beat suit their needs and the types of products they develop.
• 4.
   Do notuse coding style that is too clever or too difficult to understand.  Avoid obscure side effect.  Do not use an identifier for multiple purpose  The code should be well documented.  Do not used GOTO statement.
• 5.
   Code reviewfor a module is carried out after the module is successfully compiled and all the syntax errors eliminated. Code reviews are extremely cost-effective strategies for reduction in coding errors in order to produce high quality code. 1. Code walk-through 2. Code inspection
• 6.
   Code walk-throughis an informal code analysis technique. In this technique, after a module has been coded, it is successfully compiled and all syntax errors are eliminated.  The main objectives of the walk-through are to discover the algorithmic and logical errors in the code.
• 7.
   the aimof code inspection is to discover some common types of errors caused due to oversight and improper programming.  The following is a list of some programming errors which can be checked during code inspection:  Use of uninitialized variables  Jumps into loops  Nonterminating loops  Incompatible assignments  Array indices out of bounds  Improper storage allocation and deallocation  Mismatches between actual and formal parameters in procedure calls  Use of incorrect logical operators or incorrect precedence among operators
• 8.
   Testing aprogram consists of subjecting the program to a set of test inputs (or test cases) and observing if the program behaves as expected.  The following are some commonly used terms associated with testing. 1. A failure is a manifestation of an error (or defect or bug). But the mere presence of an error may not necessarily lead to a failure. 2. A test case is the triplet [I, S, O], where I is the data input to the system, S is the state of the system at which the data is input, and O is the expected output of the system. 3. A test suite is the set of all test cases with which a given software product is to be tested.
• 9.
   Following issimple programming error. If (x>y) max = x; else max = x;  The test suite ((x = 3. y = 2); (x = 2, y = 3)) can detect the error  whereas a larger test suite ( (x = 3, y = 2); (x = 4, y = 3); (x = 5, y = 1)] does not detect the error.
• 10.
   Two mainapproaches to systematically designing test cases 1. Black-box approach 2. White-box (or glass-box) approach
• 11.
   In black-boxtesting test cases are designed from an examination of the input/output values only and no knowledge of design or code is required.  The following are the two main approaches to designing black-box test cases. 1. Equivalence class partitioning 2. Boundary value analysis
• 12.
   The followingare some general guidelines for designing the equivalence classes 1. If the input data values to a system can be specified by a range of values, then one valid and two invalid equivalence classes should be defined. 2. If the input data assumes values from a set of discrete members of some domain, then one equivalence class for valid input values and another for invalid input values should be defined.
• 13.
   For asoftware that computes the square root of an input integer which can assume values between 0 and 5000, there are three equivalence classes: The set of negative integers, the set of integers in the range between 0 and 5000, and the integers larger than 5000. Therefore the test cases must include representative values from each of the three equivalence classes and a possible test set can therefore be: [-5, 500, 6000)
• 14.
   Boundary testingis the process of testing between extreme ends or boundaries between partitions of the input values.  Extreme ends like Start- End, Lower- Upper, Maximum-Minimum, Just Inside- Just Outside values are called boundary values and the testing is called "boundary testing". 1. Minimum 2. Just near the minimum 3. Just near the maximum 4. Maximum
• 15.
   For afunction that computes the square root of integer values in the range between 0 and 5000.  The test ceases are ( 0, -1, 1, 5000, 4999, 5001 ).
• 16.
   There areseveral white box testing strategies. Each testing strategy is based on some heuristic.
• 17.
   The statementcoverage strategy aims to design test cases so that every statement in a program is executed at least once.  The principal idea governing the statement coverage strategy is that unless we execute a statement, we have no way of determining if an error exists in that statement. Unless a statement is executed, we cannot observe whether it causes failure due to some illegal memory access, wrong result computation, etc.
• 18.
  int compute_gcd (x,y) int x, y; { while (x != y){ if (xx>y) then x=x-y else y=y-x; } return x; } By choosing the test set ( (x=3, y=3).(x=4. y=3), (x=3, y=4) ). we can exercise the program such that all statements are executed at least once.
• 19.
   In thebranch coverage-based testing strategy, test cases are designed to make each branch condition assume true and false values in turn.  Branch testing is also known as edge testing as in this testing scheme, each edge of a program's control flow graph is traversed at least once.  Testcases for branch Coverage [(x=3, y=3).(x=3. y=2), (x=4, y=3). (x=3, y=4))
• 20.
   The pathcoverage-based testing strategy requires us to design test cases such that a linearly independent paths in the program are executed at least once. A linearly independent path can be defined in terms of the control flow graph (CFG) of a program.