Software Engineering: Coding and Testing

Software Engineering
Coding and Testing
Sukanya Basu
Computer Science and Engineering Department
Techno India University
July 7, 2021
Sukanya Basu (Techno India University) Software Engineering July 7, 2021 1 / 51

Coding
• The input to the coding phase is the design document

• During coding phase
• modules identified in the design document are coded according to the module
specifications
• At the end of the design phase we have
• module structure (e.g. structure chart) of the system
• module specifications
• data structures and algorithms for each module
• Objective of coding phase
• transform design into code
• unit test the code

Coding Standards
• Good software development organizations require their programmers to

• adhere to some standard style of coding called coding standards
• Many software development organizations
• formulate their own coding standards that suits them most
• require their engineers to follow these standards rigorously
• Advantage of adhering to a standard style of coding
• it gives a uniform appearance to the codes written by different engineers
• it enhances code understanding
• encourages good programming practices

Coding Standards
• A coding standard
• sets out standard ways of doing several things
• the way variables are named
• code is laid out
• maximum number of source lines allowed per function, etc.
• Coding guidelines: Provide general suggestions regarding coding style to be
followed
• leave actual implementation of the guidelines to the discretion of the
individual engineers

Code inspection and code walk throughs
• After a module has been coded

• code inspection and code walk through are carried out
• ensures that coding standards are followed
• helps detect as many errors as possible before testing
• detected errors require less effort for correction
• much higher effort needed if errors were to be detected during integration or
system testing.

Coding Standards and Guidelines
• Good organizations often develop their own coding standards and guidelines
• depending on what best suits their organization
• We will discuss some representative coding standards and guidelines

Representative Coding Standards
• Rules for limiting the use of globals
• what types of data can be declared global and what can not
• Naming conventions for
• global variables
• local variables, and
• constant identifiers
• Contents of headers for different modules
• The headers of different modules should be standard for an organization
• The exact format for header information is usually specified
• Header data
• Name of the module
• date on which the module was created
• author’s name
• modification history
• synopsis of the module
• different functions supported, along with their input/output parameters
• global variables accessed/modified by the module
Representative Coding Standards
• Error return conventions and exception handling mechanisms

• the way error and exception conditions are handled should be standard within
an organization
• For example, when different functions encounter error conditions
• should either return a 0 or 1 consistently
• Do not use too clever and difficult to understand coding style
• Code should be easy to understand
• Clever coding can obscure meaning of the code
• hampers understanding
• makes later maintenance difficult

Representative Coding Guidelines
• Avoid obscure side effects

• Obscure side effects make it difficult to understand a piece of code
• For example
• if a global variable is changed obscurely in a called module
• it becomes difficult for anybody trying to understand the code
• Do not use an identifier (variable name) for multiple purposes
• Programmers often use the same identifier for multiple purposes
• For example, some programmers use a temporary loop variable also for storing
the final result

Representative Coding Guidelines
• Code should be well-documented

• Rules of thumb
• on the average there must be at least one comment line
• for every three source lines
• The length of any function should not exceed 10 source lines
• Lengthy functions
• usually very difficult to understand
• probably do too many different things
• Do not use goto statements
• Use of goto statements
• make a program unstructured
• make it very difficult to understand

Code Walk Through
• An informal code analysis technique

• undertaken after the coding of a module is complete
• A few members of the development team select some test cases
• simulate execution of the code by hand using these test cases
• Even though an informal technique
• several guidelines have evolved over the years
• making this naive but useful analysis technique more effective
• these guidelines are based on
• personal experience, common sense, and several subjective factors

Code Walk Through
• The guidelines should be considered as examples

• rather than accepted as rules to be applied dogmatically
• The team performing code walk through should not be either too big or too
small
• Ideally, it should consist of between three to seven members
• Discussion should focus on discovery of errors and not on how to fix the
discovered errors
• To foster cooperation
• avoid the feeling among engineers that they are being evaluated in the code
walk through meeting

Code Inspection
• In contrast to code walk throughs

• code inspection aims mainly at discovery of commonly made errors
• During code inspection
• the code is examined for the presence of certain kinds of errors
• in contrast to the hand simulation of code execution done in code walk
throughs
• For instance, consider
• classical error of writing a procedure that modifies a formal parameter
• while the calling routine calls the procedure with a constant actual parameter
• It is more likely that such an error will be discovered
• by looking for this kind of mistakes in the code
• rather than by simply hand simulating execution of the procedure

Software Documentation
• When developing a software product we develop various kinds of documents

• In addition to executable files and the source code
• users’ manual,
• software requirements specification (SRS) document,
• design document,
• test document,
• installation manual, etc
• All these documents are a vital part of good software development practice
• Internal documentation
• documentation provided in the source code itself
• External documentation
• documentation other than those present in the source code

How Do You Test a Program?
• Input test data to the program

• Observe the output
• Check if the program behaved as expected
• If the program does not behave as expected
• Note the conditions under which it failed
• Later debug and correct

Overview of Testing Activities
• Test Suite Design

• Run test cases and observe results to detect failures
• Debug to locate errors
• Correct errors

Error, Faults, and Failures
• A failure is a manifestation of an error (aka defect or bug)

• Mere presence of an error may not lead to a failure
• A fault is an incorrect state entered during program execution
• A variable value is different from what it should be
• A fault may or may not lead to a failure

Test cases and Test suites
• Test a software using a set of carefully designed test cases

• The set of all test cases is called the test suite
• A test case is a triplet [I,S,O]
• I is the data to be input to the system
• S is the state of the system at which the data will be input
• O is the expected output of the system

Verification vs. Validation
• Verification is the process of determining

• Whether output of one phase of development conforms to its previous phase
• Validation is the process of determining
• Whether a fully developed system conforms to its SRS document
• Verification is concerned with phase containment of errors
• Whereas the aim of validation is that the final product be error free

Design of Test Cases
• Exhaustive testing of any non-trivial system is impractical

• Input data domain is extremely large
• Design an optimal test suite
• Of reasonable size and
• Uncovers as many errors as possible
• If test cases are selected randomly
• Many test cases would not contribute to the significance of the test suite
• Would not detect errors not already being detected by other test cases in the
suite
• Number of test cases in a randomly selected test suite
• Not an indication of effectiveness of testing

• Testing a system using a large number of randomly selected test cases

• Does not mean that many errors in the system will be uncovered
• Consider foloowing example
• Find the maximum of two integers x and y
• The code has a simple programming error
If (x>y)
max = x;
else
max = x;
• Test suite {(x=3,y=2);(x=2,y=3)} can detect the error
• A larger test suite {(x=3,y=2);(x=4,y=3); (x=5,y=1)} does not detect the
error

• Systematic approaches are required to design an optimal test suite

• Each test case in the suite should detect different errors
• There are essentially two main approaches to design test cases
• Black-box approach
• White-box (or glass-box) approach

Black-Box Testing
• Test cases are designed using only functional specification of the software
• Without any knowledge of the internal structure of the software
• For this reason, black-box testing is also known as functional testing
White-box Testing
• Designing white-box test cases
• Requires knowledge about the internal structure of software
• White-box testing is also called structural testing

Black-Box Testing
• There are essentially two main approaches to design black box test cases
• Equivalence class partitioning
• Boundary value analysis

Equivalence Class Partitioning
• Input values to a program are partitioned into equivalence classes

• Partitioning is done such that
• Program behaves in similar ways to every input value belonging to an
equivalence class
• Why Define Equivalence Classes?
• Test the code with just one representative value from each equivalence class
• As good as testing using any other values from the equivalence classes

Equivalence Class Partitioning
• How do you determine the equivalence classes?

• Examine the input data
• Few general guidelines for determining the equivalence classes can be given
• If the input data to the program is specified by a range of values
• e.g. numbers between 1 to 5000
• One valid and two invalid equivalence classes are defined
• The set of negative integers
• Set of integers in the range of 1 and 5000
• Integers larger than 5000
• The test suite must include
• Representatives from each of the three equivalence classes
• A possible test suite can be: {-5,500,6000}
• If input is an enumerated set of values
• e.g. {a,b,c}
• One equivalence class for valid input values
• Another equivalence class for invalid input values should be defined

Boundary Value Analysis
• Some typical programming errors occur

• At boundaries of equivalence classes
• Might be purely due to psychological factors
• Programmers often fail to see
• Special processing required at the boundaries of equivalence classes
• Programmers may improperly use < instead of <=
• Boundary value analysis
• Select test cases at the boundaries of different equivalence classes
• For a function that computes the square root of an integer in the range of 1
and 5000
• Test cases must include the values: {0,1,5000,5001}

Debugging
• Once errors are identified

• It is necessary identify the precise location of the errors and to fix them
• Each debugging approach has its own advantages and disadvantages
• Each is useful in appropriate circumstances

Brute-Force method
• This is the most common method of debugging

• Least efficient method
• Program is loaded with print statements
• Print the intermediate values
• Hope that some of printed values will help identify the error

Symbolic Debugger
• Brute force approach becomes more systematic

• With the use of a symbolic debugger
• Using a symbolic debugger
• Values of different variables can be easily checked and modified
• Single stepping to execute one instruction at a time
• Break points and watch points can be set to test the values of variables

Backtracking
• This is a fairly common approach

• Beginning at the statement where an error symptom has been observed
• Source code is traced backwards until the error is discovered
• Unfortunately, as the number of source lines to be traced back increases
• the number of potential backward paths increases
• becomes unmanageably large for complex programs

Cause-elimination method
• Determine a list of causes

• which could possibly have contributed to the error symptom
• tests are conducted to eliminate each
• A related technique of identifying error by examining error symptoms
• software fault tree analysis

Program Slicing
• This technique is similar to back tracking

• However, the search space is reduced by defining slices
• A slice is defined for a particular variable at a particular statement
• set of source lines preceding this statement which can influence the value of
the variable

Debugging Guidelines
• Debugging usually requires a thorough understanding of the program design

• Debugging may sometimes require full redesign of the system
• A common mistake novice programmers often make
• not fixing the error but the error symptoms
• Be aware of the possibility
• an error correction may introduce new errors
• After every round of error-fixing
• regression testing must be carried out

Program Analysis Tools
• An automated tool
• takes program source code as input
• produces reports regarding several important characteristics of the program
• such as size, complexity, adequacy of commenting, adherence to programming
standards, etc.
• Some program analysis tools
• Produce reports regarding the adequacy of the test cases
• There are essentially two categories of program analysis tools
• Static analysis tools
• Dynamic analysis tools

Static Analysis Tools
• Static analysis tools

• Assess properties of a program without executing it
• Analyze the source code
• Provide analytical conclusions
• Whether coding standards have been adhered to?
• Commenting is adequate?
• Programming errors such as
• uninitialized variables
• mismatch between actual and formal parameters
• variables declared but never used, etc.
• Code walk through and inspection can also be considered as static analysis
methods
• However, the term static program analysis is generally used for automated
analysis tools

Dynamic Analysis Tools
• Dynamic program analysis tools require the program to be executed

• its behavior recorded
• Produce reports such as adequacy of test cases

Testing
• The aim of testing is to identify all defects in a software product

• However, in practice even after thorough testing
• one cannot guarantee that the software is error-free
• The input data domain of most software products is very large
• It is not practical to test the software exhaustively with each input data value
• Testing does however expose many errors
• Testing provides a practical way of reducing defects in a system
• Increases the users’ confidence in a developed system

Testing
• Testing is an important development phase

• requires the maximum effort among all development phases
• In a typical development organization
• maximum number of software engineers can be found to be engaged in testing
activities
• Many engineers have the wrong impression
• testing is a secondary activity
• it is intellectually not as stimulating as the other development activities, etc.
• Testing a software product is in fact
• as much challenging as initial development activities such as specification,
design, and coding
• Also, testing involves a lot of creative thinking

Testing
• Software products are tested at three levels

• Unit testing
• Integration testing
• System testing

Unit testing
• During unit testing, modules are tested in isolation

• If all modules were to be tested together
• it may not be easy to determine which module has the error
• Unit testing reduces debugging effort several folds
• Programmers carry out unit testing immediately after they complete the
coding of a module

Integration testing
• After different modules of a system have been coded and unit tested
• modules are integrated in steps according to an integration plan
• partially integrated system is tested at each integration step
System testing
• System testing involves
• validating a fully developed system against its requirements

Integration Testing
• Develop the integration plan by examining the structure chart

• big bang approach
• top-down approach
• bottom-up approach
• mixed approach

Big Bang Integration Testing
• Big bang approach is the simplest integration testing approach

• all the modules are simply put together and tested
• this technique is used only for very small systems
• Main problems with this approach
• If an error is found
• It is very difficult to localize the error
• The error may potentially belong to any of the modules being integrated
• Debugging errors found during big bang integration testing are very expensive
to fix

Integration Testing
Bottom-up Integration Testing

• Integrate and test the bottom level modules first
• A disadvantage of bottom-up testing
• when the system is made up of a large number of small subsystems
• This extreme case corresponds to the big bang approach
Top-down integration testing

• Top-down integration testing starts with the main routine
• and one or two subordinate routines in the system
• After the top-level ‘skeleton’ has been tested
• immediate subordinate modules of the ‘skeleton’ are combined with it and
tested

Integration Testing
• Mixed Integration Testing

• Mixed (or sandwiched) integration testing
• uses both top-down and bottom-up testing approaches
• most common approach
• In top-down approach
• testing waits till all top-level modules are coded and unit tested
• In bottom-up approach
• testing can start only after bottom level modules are ready

System Testing
• There are three main kinds of system testing

• Alpha Testing
• Beta Testing
• Acceptance Testing
• Alpha Testing
• System testing is carried out by the test team within the developing
organization
• Beta Testing
• System testing performed by a select group of friendly customers

Acceptance Testing
• System testing performed by the customer himself
• to determine whether the system should be accepted or rejected
Stress Testing
• Stress testing (aka endurance testing)
• impose abnormal input to stress the capabilities of the software
• input data volume, input data rate, processing time, utilization of memory,
etc. are tested beyond the designed capacity

How Many Errors are Still Remaining?
• Seed the code with some known errors

• artificial errors are introduced into the program
• Check how many of the seeded errors are detected during testing
• Error Seeding

Error Seeding
• Let
• N be the total number of errors in the system
• n of these errors be found by testing
• S be the total number of seeded errors
• s of the seeded errors be found during testing
• n/N = s/S
• N = S n/s
• Remaining defects:
N - n = n ((S - s)/ s)

Error Seeding
• Example
• 100 errors were introduced
• 90 of these errors were found during testing
• 50 other errors were also found
• Remaining errors= 50 (100-90)/90 = 6
• The kind of seeded errors should match closely with existing errors
• However, it is difficult to predict the types of errors that exist
• Categories of remaining errors
• can be estimated by analyzing historical data from similar projects.

Software Engineering: Coding and Testing

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering: Coding and Testing

Uploaded by

Copyright:

Available Formats

Software Engineering

Coding and Testing

Computer Science and Engineering Department

Techno India University

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 1 / 51

• The input to the coding phase is the design document

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 2 / 51

• Good software development organizations require their programmers to

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 3 / 51

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 4 / 51

• After a module has been coded

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 5 / 51

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 6 / 51

• Error return conventions and exception handling mechanisms

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 8 / 51

• Avoid obscure side effects

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 9 / 51

• Code should be well-documented

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 10 / 51

• An informal code analysis technique

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 11 / 51

• The guidelines should be considered as examples

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 12 / 51

• In contrast to code walk throughs

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 13 / 51

• When developing a software product we develop various kinds of documents

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 14 / 51

• Input test data to the program

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 15 / 51

• Test Suite Design

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 16 / 51

• A failure is a manifestation of an error (aka defect or bug)

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 17 / 51

• Test a software using a set of carefully designed test cases

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 18 / 51

• Verification is the process of determining

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 19 / 51

• Exhaustive testing of any non-trivial system is impractical

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 20 / 51

• Testing a system using a large number of randomly selected test cases

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 21 / 51

• Systematic approaches are required to design an optimal test suite

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 22 / 51

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 23 / 51

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 24 / 51

• Input values to a program are partitioned into equivalence classes

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 25 / 51

• How do you determine the equivalence classes?

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 26 / 51

• Some typical programming errors occur

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 27 / 51

• Once errors are identified

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 28 / 51

• This is the most common method of debugging

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 29 / 51

• Brute force approach becomes more systematic

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 30 / 51

• This is a fairly common approach

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 31 / 51

• Determine a list of causes

Sukanya Basu (Techno India University) Software Engineering July 7, 2021 32 / 51

• This technique is similar to back tracking