Software Engineering (3150711)

Unit-6
Software Coding &
Testing

Dr. Pradyumansinh U. Jadeja

Computer Engineering Department
Darshan Institute of Engineering & Technology,
Rajkot
[email protected]
+91-9879461848
✓ Outline
Looping
▪ Code Review
▪ Software Documentation
▪ Testing Strategies
▪ Testing Techniques and Test Case
▪ Test Suites Design
▪ Testing Conventional Applications
▪ Testing Object Oriented Applications
▪ Testing Web and Mobile Applications
Coding Standards
Most software development organizations formulate their
own coding standards that suit them most, and require
their engineers to follow these standards strictly
The purpose of requiring all engineers of an organization
to adhere to a standard style of coding is the following:

A coding standard gives a uniform appearance to the codes

Good software written by different engineers.
development
organizations normally It enhances code understanding.
require their It encourages good programming practices.
programmers to adhere
to some well-defined and
standard style of coding
called coding standards.

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 3
Coding Standards Cont.
A coding standard lists several rules to be followed such as, the way variables are
to be named, the way the code is to be laid out, error return conventions, etc.
The following are some representative coding standards
1 Rules for limiting the use of global
These rules list what types of data can be declared global and what cannot.
2 Naming conventions for global & local variables & constant identifiers
A possible naming convention can be that global variable names always start with a capital letter,
local variable names are made of small letters, and constant names are always capital letters.
3 Contents of the headers preceding codes for different modules
• The information contained in the headers The following are some standard header data
of different modules should be standard for Module Name Creation Date Author’s Name
an organization.
• The exact format in which the header Modification history Synopsis of the module
information is organized in the header can Global variables accessed/modified by the module
also be specified Different functions supported, along with their input/output
parameters
Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software Engineering 4
Coding Standards Cont.
Sample Header
/*
* MyClass <br>
* This class is merely for illustrative purposes. <br>
*Revision History:<br>
* 1.1 – Added javadoc headers <br>
* 1.0 - Original release<br>
* @author P.U. Jadeja
* @version 1.1, 12/02/2018
*/
public class MyClass {
. . .
}

4 Error return conventions and exception handling mechanisms

• The way error conditions are reported by different functions in a program are
handled should be standard within an organization.
• For example, different functions while encountering an error condition should
either return a 0 or 1 consistently.
Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software Engineering 5
Coding guidelines The following are some representative coding
guidelines
Do not use a coding style that is too clever or too difficult to understand
Do not use an identifier for multiple purposes Avoid obscure side effects
The code should be well-documented • The side effects of a function call include
modification of parameters passed by
The length of any function should not exceed 10 reference, modification of global variables,
and I/O operations.
source lines
• An obscure side effect is one that is not
Do not use goto statements obvious from a casual examination of the
code.
• Obscure side effects make it difficult to
Well Documented

Do not use goto

understand a piece of code.
• For example, if a global variable is changed
obscurely in a called module or some file I/O
is performed which is difficult to infer from
the function’s name and header information, it
becomes difficult for anybody trying to
understand the code.
#3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software
Prof. Pradyumansinh U. Jadeja 6
Software Faults Types of
Quite inevitable Faults
(unavoidable) Algorithmic Logic is wrong Code reviews

Many reasons Syntax Wrong syntax; typos Compiler

Software systems with Computation/ Precision Not enough accuracy

large number of states Documentation Misleading documentation

Complex formulas, Stress/Overload Maximum load violated

activities, algorithms Capacity/Boundary Boundary cases are usually special cases

Customer is often unclear Timing/Coordination Synchronization issues Very hard to replicate

of needs Throughput/Performance System performs below expectations
Size of software Recovery System restarted from abnormal state

Number of people Hardware & related software Compatibility issues

involved Standards Makes for difficult maintenance

#3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software

Prof. Pradyumansinh U. Jadeja 7
Software Quality

Software Quality remains an issue Code Review

Who is to blame?
Code Walk
Customers blame developers Through
Arguing that careless practices lead to low-quality software
Code Inspection
Developers blame Customers & other stakeholders
Arguing that irrational delivery dates and continuous stream of
changes force the to deliver software before it has been fully
validated

Who is Right? Both – and that’s the problem

#3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software

Prof. Pradyumansinh U. Jadeja 8
Code Review
Code Review is carried out after the Few classical programming errors
module is successfully compiled and all
the syntax errors have been eliminated. Use of uninitialized variables
Code Reviews are extremely Jumps into loops
cost-effective strategies for reduction Nonterminating loops
in coding errors and to produce high Incompatible assignments
quality code.
Types of
Array indices out of bounds
Reviews Improper storage allocation and deallocation
Mismatches between actual and formal
Code Walk Code parameter in procedure calls
Through Inspection Use of incorrect logical operators or incorrect
precedence among operators
Improper modification of loop variables

#3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software

Prof. Pradyumansinh U. Jadeja 9
Code Review Code Walk Through & Code
Inspection
Code Walk Code Inspection
Through
Code walk through is an informal code The aim of Code Inspection is to
analysis technique. discover some common types of errors
The main objectives of the walk through are caused due to improper programming.
to discover the algorithmic and logical In other words, during Code Inspection
errors in the code. the code is examined for the presence
A few members of the development team are of certain kinds of errors.
given the code few days before the walk For instance, consider the classical error of
writing a procedure that modifies a
through meeting to read and understand code. parameter while the calling routine calls
Each member selects some test cases and that procedure with a constant actual
simulates execution of the code by hand parameter.
It is more likely that such an error will be
The members note down their findings to discovered by looking for these kinds of
discuss these in a walk through meeting mistakes in the code.
where the coder of the module is present. In addition, commitment to coding
standards is also checked.
Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software Engineering 10
Software Documentation
When various kinds of software products are developed, various kinds of
documents are also developed as part of any software engineering process e.g..

Users’ manual Design documents Test documents Installation manual

Software requirements specification (SRS) documents, etc

Different types of software documents can broadly be classified into the following:

Software
Documents

Internal External
Documentation Documentation

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 11
Software Documentation Cont. Internal & External
Documentation
Internal Documentation External
Documentation
It is the code perception features provided as part of It is provided through various
the source code. types of supporting documents
It is provided through appropriate module headers and such as users’ manual
comments embedded in the source code. software requirements
specification document
It is also provided through the useful variable names, design document
module and function headers, code indentation, code test documents, etc.
structuring, use of enumerated types and constant
identifiers, use of user-defined data types, etc. A systematic software
development style ensures that
Even when code is carefully commented, meaningful
variable names are still more helpful in understanding a all these documents are
piece of code. produced in an orderly
fashion.
Good organizations ensure good internal documentation
by appropriately formulating their coding standards and
guidelines.
Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 12
Software Testing
Testing is the process of
exercising a program with the
specific intent of finding
errors prior to delivery to the
end user.

Don’t view testing as a

“safety net” that will catch
all errors that occurred
because of weak software
engineering practice.
Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 13
Who Test the Software
Developer

Who Test

Tester
the
Software?

Understands the system but, will Must learn about the system, but,
test "gently" will attempt to break it <Developer
and, is driven by "delivery" and, is driven by quality > O
Testing without plan is of no
Testing need a strategy R
[Tester
Dev team needs to work with
point ]
Test team, “Egoless
It wastes time and effort
Programming”
Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 14
When to Test the Software?
Component Code Component Code Component Code
Unit Test Unit Test Unit Test

Design Specifications Integration Test Integrated

modules
System functional requirements Function Test Functioning system

Other software Performance Test Verified, validated

requirements software
Customer Acceptance Test Accepted
SRS system
User Installation Test System in
environment use!
Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software Engineering 15
Verification & Validation
Verification Verificatio Validatio
Are we building the product
n
Process of evaluating
products of a Process of evaluating n
software at the
right? development phase to find out end of the development to determine
The objective of Verification is whether they meet the specified whether software meets the customer
to make sure that the product requirements. expectations and requirements.
being develop is as per the
Activities involved: Reviews, Activities involved: Testing like black
requirements and design
Meetings and Inspections box testing, white box testing, gray box
specifications. testing

Validation Carried out by QA Carried out by testing team

team
Are we building the right Execution of code is not comes under Execution of code is comes under
product? Verification Validation
The objective of Validation is to
make sure that the product Explains whether the outputs are Describes whether the software is
according to inputs or not accepted by the user or not
actually meet up the user’s
requirements, and check whether Cost of errors caught is Cost of errors caught is high
the specifications were correct in less
the first place.

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 16
Software Testing Strategy

Unit Testing
It concentrate on each
unit of the software as
implemented in source
code
Unit Testing It focuses on each
Integration Testing component individual,
Validation Testing ensuring that it functions
properly as a unit.
System Testing

#3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software

Prof. Pradyumansinh U. Jadeja 17
Software Testing Strategy Cont.

Integration Testing Validation Testing System Testing

It focus is on design and Software is validated The software and other software
construction of against requirements elements are tested as a whole
software architecture established as a part of Software once validated, must be
requirement modeling combined with other system
Integration testing is the
elements e.g. hardware, people,
process of testing the It give assurance that database etc…
interface between two software meets all
software units or informational, functional, It verifies that all elements mesh
modules behavioral and properly and that overall system
performance requirements function / performance is achieved.

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software Engineering 18
Unit Testing
Unit is the smallest part of a software system which is testable.
It may include code files, classes and methods which can be tested individually
for correctness.
Unit Testing validates small building block of a complex system before testing
an integrated large module or whole system
The unit test focuses on the internal processing logic and data structures
within the boundaries of a component.
The module is tested to ensure that information properly flows into and out of
the program unit
Local data structures are examined to ensure that data stored temporarily
maintains its integrity during execution
All independent paths through the control structures are exercised to ensure
that all statements in module have been executed at least once
Boundary conditions are tested to ensure that the module operates properly
at boundaries established to limit or restricted processing
All error handling paths are tested
#3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software
Prof. Pradyumansinh U. Jadeja 19
Diver & Stub (Unit Testing)
A B C
Let’s take an example to understand it in a better
way.
Suppose there is an application consisting of three
modules say, module A, module B & module C.
Developer has design in such a way that module B
depends on module A & module C depends on
module B
Component-testing (Unit Testing) may
The developer has developed the module B and now
be done in isolation from rest of the
wanted to test it.
system
In such case the missing software is But the module A and module C has not been
replaced by Stubs and Drivers and developed yet.
simulate the interface between the
software components in a simple manner In that case to test the module B completely we can
replace the module A by Driver and module C by
Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software Engineering 20
Diver & Stub (Unit Testing) Cont.
Driver Stub
Driver and/or Stub software must be Stubs serve to replace modules that are
developed for each unit test subordinate (called by) the component to
A driver is nothing more than a "main be tested.
program" A stub or "dummy subprogram"
It accepts test case data Uses the subordinate module's interface
Passes such data to the component and May do minimal data manipulation
Prints relevant results. Prints verification of entry and
Driver Returns control to the module undergoing
testing
Used in Bottom up approach
Lowest modules are tested first. Stubs
Simulates the higher level of components Used in Top down approach
Dummy program for Higher level component Top most module is tested first
Simulates the lower level of components
Dummy program of lower level components
#3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software
Prof. Pradyumansinh U. Jadeja 21
Integration Testing
Integration testing is the process of testing the interface between two software units or
modules
It can be done in 3 1. Big Bang 2. Top Down 3. Bottom Up
ways Approach Approach Approach
Big Bang Top Down
Approach
Combining all the modules Approach
Testing take place from top to bottom
once and verifying the
High level modules are tested first and then low-level modules and
functionality after completion
finally integrated the low level modules to high level to ensure the
of individual module testing
system is working as intended
Stubs are used as a temporary module, if a module is not ready for
integration testing
Bottom Up
Approach
Testing take place from bottom to up
Lowest level modules are tested first and then high-level modules and finally integrated the high level
modules to low level to ensure the system is working as intended
Drivers are used as a temporary module, if a module is not ready for integration testing
Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 22
Regression Testing When to do regression
Repeated testing of an already tested testing?
When new functionalities are added to the
program, after modification, to application
discover any defects introduced or E.g. A website has login functionality with only Email.
uncovered as a result of the changes in Now the new features look like “also allow login using
the software being tested Facebook”
Regression testing is done by When there is a change requirement
re-executing the tests against the Forgot password should be removed from the login
modified application to evaluate page
whether the modified code breaks
anything which was working earlier When there is a defect fix
E.g. assume that “Login” button is not working and
Anytime we modify an application, we tester reports a bug. Once the bug is fixed by developer,
should do regression testing tester tests using this approach
It gives confidence to the developers When there is a performance issue
that there is no unexpected side effects
E.g. loading a page takes 15 seconds. Reducing load
after modification time to 2 seconds
When there is an environment change
E.g. Updating database from MySQL to Oracle
#3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software
Prof. Pradyumansinh U. Jadeja 23
Smoke Testing
Smoke Testing is an integrated testing Build
approach that is commonly used when product
software is developed
This test is performed after each Build Release
Smoke testing verifies – Build Stability F1 F2 F3 F4 F5 F6
This testing is performed by “Tester” or Critic Critic Majo Majo
“Developer” al al r r
This testing is executed for Integration It test the build just to check if any major
Testing, System Testing & Acceptance or critical functionalities are broken
Testing
If there are smoke or Failure in the build
What to Test? after Test, build is rejected and developer
All major and critical functionalities of the
application is tested
team is reported with the issue
It does not go into depth to test each
functionalities
This does not incudes detailed testing
Prof. Pradyumansinh U. Jadeja
for the
#3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 24
Validation Testing
The process of evaluating software to determine whether it satisfies specified business
requirements (client’s need).
It provides final assurance that software meets all informational, functional, behavioral, and
performance requirements
When custom software is build for one customer, a series of acceptance tests are conducted
to validate all requirements
It is conducted by end user rather then software engineers
If software is developed as a product to be used by many customers, it is impractical to
perform formal acceptance tests with each one
Most software product builders use a process called alpha and beta testing to uncover
errors that only the end user seems able to find

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 25
Validation Testing – Alpha & Beta Test
Alpha Test
The alpha test is conducted at the developer’s site by a representative group of end users
The software is used in a natural setting with the developer “looking over the shoulders” of
the users and recording errors and usage problems
The alpha tests are conducted in a controlled environment
Beta Test
The beta test is conducted at one or more end-user sites
Developers are not generally present
Beta test is a “live” application of the software in an environment that can not be
controlled by the developer
The customer records all problems and reports to the developers at regular intervals
After modifications, software is released for entire customer base
Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 26
System Testing
In system testing the software and other system elements are tested.
To test computer software, you spiral out in a clockwise direction along streamlines that
increase the scope of testing with each turn.
System testing verifies that all elements mesh properly and overall system
function/performance is achieved.
System testing is actually a series of different tests whose primary purpose is to fully
exercise the computer-based system.

Types of System
Testing
1 Recovery Testing 4 Performance Testing
2 Security Testing 5 Deployment Testing
3 Stress Testing

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 27
Types of System Testing
Recovery Testing
It is a system test that forces the software to fail in a variety of ways
and verifies that recovery is properly performed.
If recovery is automatic (performed by the system itself)
Re-initialization, check pointing mechanisms, data recovery, and restart
are evaluated for correctness.
If recovery requires human intervention
The mean-time-to-repair (MTTR) is evaluated to determine whether it
is within acceptable limits
Security Testing
It attempts to verify software’s protection mechanisms, which
protect it from improper penetration (access).
During this test, the tester plays the role of the individual who
desires to penetrate the system.

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 28
Types of System Testing Cont.
Stress Testing
It executes a system in a manner that demands resources in
abnormal quantity, frequency or volume.
A variation of stress testing is a technique called sensitivity testing.

Performance Testing
It is designed to test the run-time performance of software.
It occurs throughout all steps in the testing process.
Even at the unit testing level, the performance of an individual
module may be tested.

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 29
Types of System Testing Cont.
Deployment Testing
It exercises the software in each environment in which it is to
operate.
In addition, it examines
All installation procedures
Specialized installation software that will be used by customers
All documentation that will be used to introduce the software to end
users

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 30
Acceptance Testing
It is a level of the software testing where a system is tested for acceptability.
The purpose of this test is to evaluate the system’s compliance with the business
requirements.
It is a formal testing conducted to determine whether or not a system satisfies the
acceptance criteria with respect to user needs, requirements, and business processes
It enables the customer to determine, whether or not to accept the system.
It is performed after System Testing and before making the system available for actual use.

#3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software

Prof. Pradyumansinh U. Jadeja 31
Views of Test Objects
Black Box Testing White Box Testing Grey Box Testing
Close Box Testing Open Box Testing Partial knowledge of
Testing based only on Testing based on actual source code
specification source code

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 32
Black Box Testing
Also known as specification-based testing
Tester has access only to running code and the specification it is supposed to satisfy
Test cases are written with no knowledge of internal workings of the code
No access to source code
So test cases don’t worry about structure
Emphasis is only on ensuring that the contract is met
Advantages
Scalable; not dependent on size of code
Testing needs no knowledge of implementation
Tester and developer can be truly independent of each other
Tests are done with requirements in mind
Does not excuse inconsistencies in the specifications
Test cases can be developed in parallel with code
Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software Engineering 33
Black Box Testing Cont.
Disadvantages Test Case Design
Examine pre-condition, and identify Test size will have to be small
equivalence classes Specifications must be clear, concise,
All possible inputs such that all classes are and correct
covered May leave many program paths
Apply the specification to input to write down untested
expected output Weighting of program paths is not
possible

Test Case 1
Specification Input: x1 (sat. X)
Specification-
Operation op Exp. Output: y2
Based Test
Pre: X
Case Test Case 2
Post: Y
Design Input: x2 (sat. X)
Exp. Output: y2

#3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software

Prof. Pradyumansinh U. Jadeja 34
Black Box Testing Cont.
Exhausting testing is not always possible when there is a large set of input combinations,
because of budget and time constraint.
The special techniques are needed which select test-cases smartly from the all combination
of test-cases in such a way that all scenarios are covered

Two techniques are

used
1 Equivalence Partitioning 2 Boundary Value Analysis (BVA)

Equivalence Partitioning
Input data for a program unit usually falls into a number of
partitions, e.g. all negative integers, zero, all positive numbers
Each partition of input data makes the program behave in a similar
way
Two test cases based on members from the same partition is likely to
reveal the same bugs
Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 35
Equivalence Partitioning (Black Box Testing)
By identifying and testing one member of each partition we gain 'good' coverage with 'small'
number of test cases
Testing one member of a partition should be as good as testing any member of the partition

Example - Equivalence
Partitioning
For binary search the following partitions exist Pick specific conditions of the array
Inputs that conform to pre-conditions The array has a single value
Inputs where the precondition is false Array length is even
Inputs where the key element is a member of the array Array length is odd
Inputs where the key element is not a member of the array

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 36
Equivalence Partitioning (Black Box Testing) Cont.

Example - Equivalence
Partitioning
Example: Assume that we have to test field which accepts SPI (Semester Performance
Index) as input (SPI range is 0 to 10)

SPI * Accepts value 0 to 10

Equivalence Partitioning
Invalid Valid Invalid
<=-1 0 to 10 >=11

Valid Class: 0 – 10, pick any one input test data from 0 to 10
Invalid Class 1: <=-1, pick any one input test data less than or equal to -1
Invalid Class 2: >=11, pick any one input test data greater than or equal to 11
Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 37
Boundary Value Analysis (BVA) (Black Box Testing)
It arises from the fact that most program fail at input boundaries
Boundary testing is the process of testing between extreme ends or boundaries between
partitions of the input values.
In Boundary Testing, Equivalence Class Partitioning plays a good role
Boundary Testing comes after the Equivalence Class Partitioning
The basic idea in boundary value testing is to select input variable values at their:

Just below the minimum Minimum Just above the minimum

Just below the Maximum Just above the maximum

maximum
Boundar
y

Boundary Values

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 38
Boundary Value Analysis (BVA) (Black Box Testing)
Suppose system asks for “a number between 100 and 999
inclusive”
999 999
The boundaries are 100 and 999 99 100 101
1000
We therefore test for values Lower Upper
BVA - Advantages boundary boundary
The BVA is easy to use and remember because of the uniformity of identified tests and the
automated nature of this technique.
One can easily control the expenses made on the testing by controlling the number of identified
test cases.
BVA is the best approach in cases where the functionality of a software is based on numerous
variables representing physical quantities.
The technique is best at user input troubles in the software.
The procedure and guidelines are crystal clear and easy when it comes to determining the test
cases through BVA.
The test cases generated through BVA are very small.
Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 39
Boundary Value Analysis (BVA) (Black Box Testing) Cont.
BVA - Disadvantages
This technique sometimes fails to test all the potential input values. And so, the results
are unsure.
The dependencies with BVA are not tested between two inputs.
This technique doesn’t fit well when it comes to Boolean Variables.
It only works well with independent variables that depict quantity.

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 40
White Box Testing
Also known as structural testing
White Box Testing is a software testing method in which the internal
structure/design/implementation of the module being tested is known to the tester
Focus is on ensuring that even abnormal invocations are handled gracefully
Using white-box testing methods, you can derive test cases that
Guarantee that all independent paths within a module have been exercised at least once
Exercise all logical decisions on their true and false sides
Execute all loops at their boundaries
Exercise internal data structures to ensure their validity

...our goal is to ensure that

all statements and conditions
have been executed at least
once ...
#3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software
Prof. Pradyumansinh U. Jadeja 41
White Box Testing Cont.
It is applicable to the following levels of software testing
Unit Testing: For testing paths within a unit
Integration Testing: For testing paths between units
System Testing: For testing paths between subsystems

Advantages Disadvantages
Testing can be commenced Since tests can be very complex, highly skilled
at an earlier stage as one resources are required, with thorough knowledge of
need not wait for the GUI to programming and implementation
be available. Test script maintenance can be a burden, if the
Testing is more thorough, implementation changes too frequently
with the possibility of Since this method of testing is closely tied with the
covering most paths application being testing, tools to cater to every kind of
implementation/platform may not be readily available

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software Engineering 42
White-box testing strategies
One white-box testing strategy is said to be stronger than another strategy, if all types of
errors detected by the first testing strategy is also detected by the second testing strategy, and
the second testing strategy additionally detects some more types of errors.
White-box testing
strategies
1 Statement coverage 2 Branch coverage 3 Path coverage
Statement coverage
It aims to design test cases so that every statement in a program is executed at least once
Principal idea is unless a statement is executed, it is very hard to determine if an error exists
in that statement
Unless a statement is executed, it is very difficult to observe whether it causes failure due to
some illegal memory access, wrong result computation, etc.

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 43
White-box testing strategies Cont.
Consider the Euclid’s GCD computation algorithm

int compute_gcd(x, y) By choosing the test set {(x=3, y=3),

int x, y; (x=4, y=3), (x=3, y=4)}, we can
exercise the program such that all
{
statements are executed at least once.
1 while (x! = y){
2 if (x>y) then
3 x= x – y;
4 else y= y – x;
5 }
6 return x;
}

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 44
White-box testing strategies Cont.
Branch coverage
In the branch coverage based testing strategy, test cases are designed to make each
branch condition to assume true and false values in turn
It 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
Branch coverage guarantees statement coverage, so it is stronger strategy compared to
Statement Coverage.
Path Coverage
In this strategy test cases are executed in such a way that every path is executed at least
once
All possible control paths taken, including
All loop paths taken zero, once and multiple items in technique
The test case are prepared based on the logical complexity measure of the procedure design
Flow graph, Cyclomatic Complexity and Graph Metrices are used to arrive at basis path.
Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 45
White-box testing strategies Cont.
Branch coverage Path Coverage
In the branch coverage based testing In this strategy test cases are executed in
strategy, test cases are designed to such a way that every path is executed at
make each branch condition to assume least once
true and false values in turn All possible control paths taken, including
It is also known as edge Testing as in All loop paths taken zero, once and multiple
this testing scheme, each edge of a items in technique
program’s control flow graph is The test case are prepared based on the
traversed at least once logical complexity measure of the procedure
design
Branch coverage guarantees statement
coverage, so it is stronger strategy Flow graph, Cyclomatic Complexity and
compared to Statement Coverage. Graph Metrices are used to arrive at basis
path.

#3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software

Prof. Pradyumansinh U. Jadeja 46
Grey Box Testing
Combination of white box and black box testing
Tester has access to source code, but uses it in a restricted manner
Test cases are still written using specifications based on expected outputs for given input
These test cases are informed by program code structure

#3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software

Prof. Pradyumansinh U. Jadeja 47
Testing Object Oriented Applications
Unit Testing in the OO Context

The concept of the unit testing changes in object-oriented

software
Encapsulation drives the definition of classes and objects
Means, each class and each instance of a class (object) packages
attributes (data) and the operations (methods or services) that
manipulate these data
Rather than testing an individual module, the smallest testable unit
is the encapsulated class
Unlike unit testing of conventional software,
which focuses on the algorithmic detail of a module and the data that
flows across the module interface,
class testing for OO software is driven by the operations
encapsulated by the class and the state behavior of the class

#3150711 (SE) ⬥ Unit 1 – Introduction to Software & Software

Prof. Pradyumansinh U. Jadeja 48
Integration Testing in the OO Context
Object-oriented software does not have a hierarchical control structure,
conventional top-down and bottom-up integration strategies have little meaning
There are two different strategies for integration testing of OO systems.
1. Thread-based testing
▪ integrates the set of classes required to respond to one input or event for the system
▪ Each thread is integrated and tested individually
▪ Regression testing is applied to ensure that no side effects occur
2. Use-based testing
▪ begins the construction of the system by testing those classes (called independent classes) that use very few (if
any) of server classes
▪ After the independent classes are tested, the next layer of classes, called dependent classes, that use the
independent classes are tested
Cluster testing is one step in the integration testing of OO software
Here, a cluster of collaborating classes is exercised by designing test cases that attempt to
uncover

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 49
Validation Testing in an OO Context
At the validation or system level, the details of class connections disappear
Like conventional validation, the validation of OO software focuses on user-visible actions
and user-recognizable outputs from the system
To assist in the derivation of validation tests, the tester should draw upon use cases that are
part of the requirements model
Conventional black-box testing methods can be used to drive validation tests

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 50
Testing Web Applications
WebApp testing is a collection of related activities with a
single goal to uncover errors in WebApp content, function,
usability, navigability, performance, capacity, and security
To accomplish this, a testing strategy that encompasses both
reviews and executable testing is applied.
Dimensions of Quality
Content is evaluated at both a syntactic and semantic level.
At the syntactic level spelling, punctuation, and grammar
are assessed for text-based documents.
At a semantic level correctness of information presented,
Consistency across the entire content object and related
objects, and lack of ambiguity are all assessed.

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 51
Dimensions of Quality Cont.
Function is tested to uncover errors that indicate lack of conformance to customer
requirements
Structure is assessed to ensure that it properly delivers WebApp content
Usability is tested to ensure that each category of user is supported by the interface and can
learn and apply all required navigation.
Navigability is tested to ensure that all navigation syntax and semantics are exercised to
uncover any navigation errors
Ex., dead links, improper links, and erroneous links
Performance is tested under a variety of operating conditions, configurations and loading
to ensure that the system is responsive to user interaction and handles extreme loading
Compatibility is tested by executing the WebApp in a variety of different host configurations
on both the client and server sides
Interoperability is tested to ensure that the WebApp properly interfaces with other applications
and/or databases
Security is tested by assessing potential vulnerabilities
Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 52
Content Testing User Interface
Errors in WebApp content can be Testing
Verification and validation of a WebApp
as trivial as minor typographical errors or user interface occurs at three distinct points
as significant as incorrect information,
improper organization, or violation of
1. During requirements analysis
intellectual property laws the interface model is reviewed to ensure that
it conforms to stakeholder requirements
Content testing attempts to uncover these
and many other problems before the user 2. During design
encounters them the interface design model is reviewed to
ensure that generic quality criteria established
Content testing combines both reviews and for all user interfaces have been achieved
the generation of executable test cases 3. During testing
Reviews are applied to uncover semantic the focus shifts to the execution of
errors in content application-specific aspects of user interaction
as they are manifested by interface syntax and
Executable testing is used to uncover semantics.
content errors that can be traced to In addition, testing provides a final
dynamically derived content that is driven assessment of usability
by data acquired from one or more
databases.
Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 53
Component-Level Testing Navigation
Component-level testing (function
Testing
The job of navigation testing is to ensure
testing), focuses on a set of tests that that
attempt to uncover errors in WebApp the mechanisms that allow the WebApp user
functions. to travel through the WebApp are all
functional and,
Each WebApp function is a software to validate that each Navigation Semantic
component (implemented in one of a Unit (NSU) can be achieved by the appropriate
variety of programming languages) user category
WebApp function can be tested using Navigation mechanisms should be tested
black-box (and in some cases, white-box)
techniques. are
Navigation links,
Component-level test cases are often Redirects,
driven by forms-level input. Bookmarks,
Once forms data are defined, the user selects Frames and framesets,
a button or other control mechanism to
initiate execution. Site maps,
Internal search engines.

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 54
Configuration Testing Security
Configuration variability and instability are
Testing
Security tests are designed to probe
important factors that make WebApp testing a vulnerabilities of the client-side
challenge. environment,
the network communications that occur
Hardware, operating system(s), browsers, as data are passed from client to server
storage capacity, network communication and back again, and
speeds, and a variety of other client-side factors the server-side environment.
are difficult to predict for each user.
Each of these domains can be
One user’s impression of the WebApp and the attacked, and it is the job of the
manner in which he/she interacts with it can security tester to uncover weaknesses
differ significantly. that can be exploited by those with the
Configuration testing is to test a set of intent to do so.
probable client-side and server-side
configurations
to ensure that the user experience will be the same
on all of them and,
to isolate errors that may be specific to a
particular
Prof. Pradyumansinhconfiguration
U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 55
Performance Testing
Performance testing is used to uncover
performance problems that can result from lack of server-side resources,
inappropriate network bandwidth,
inadequate database capabilities,
faulty or weak operating system capabilities,
poorly designed WebApp functionality, and
other hardware or software issues that can lead to degraded client-server performance

Prof. Pradyumansinh U. Jadeja #3150711 (SE) ⬥ Unit 6 – Software Coding & Testing 56
 Software Engineering (3150711)

Than
k
You
Dr. Pradyumansinh U. Jadeja
Computer Engineering Department
Darshan Institute of Engineering & Technology,
Rajkot
[email protected]
91-9879461848