SE

UNIT 5

Software Coding & Testing

5.1 Software Development: Selecting a language, Coding

guidelines & writing code

Software development is a process of analysing, writing and

maintaining a large pool of instructions written in a programming
language. The source code is written and saved by the
programmers and regularly updated if occur with any anomalies.

1. Selecting a language: to develop a software the

programming language is selected as there has been a large no.
of languages available.

2. Coding guidelines & writing code: The code is written

according to a stack of rules called syntax for the selected
programming language.

After the coding is done, it is tested to check whether it is working

to give the desired output or not. The process of checking the
code is called testing.

5.2 Testing process

Software testing is an essential part of software

development process, which is used to identify the correctness,
completeness and quality of developed software. The objective is
to detect errors in the software as errors keeps software from
producing outputs as per user requirement. Software is
considered as incomplete, inconsistent, or incorrect if errors are
present in it.

IEEE defines testing as “process of exercising or evaluating a

system or system component by manual or automated means to
verify that it satisfies specified requirements or to identify
differences between expected and actual results.”
Software testing is closely associated with
the term’s verification and validation.

Verification and Validation

Verification is the process of evaluating a system or component to

determine whether the products of a given development phase
satisfy the conditions imposed at the start of that phase

Validation is the process of evaluating a system or component

during or at the end of development process to determine
whether it satisfies the specified requirements

Testing= Verification + Validation

5.3 Design of test cases

IEEE defines test case as “a set of input values, execution
preconditions, expected results and execution post conditions,
developed for a particular objective or test condition, such as to
exercise a particular program path or to verify compliance with a
specific requirement”. Generally, a test case contains particulars,
such as test case identifier, test case name, its objective, test
conditions/setup, input data requirements, steps, and
expected results.

(a) Test Case Generation

The process of generating test cases helps in locating problems in

the requirements or design of software. To generate a test case,
initially a criterion that evaluates a set of test cases is specified.
Then, a set of test cases that satisfy the specified criterion is
generated. There are two methods used to generate test cases,
which are given below:

• Code based test case generation: also known as structure-

based test used to analyse the entire software code to generate
test cases but not concerned with

User requirements. Unit testing uses this test cases.

• Specification based test case generation:

It deals with external view of software to generate test cases &

is used for integration testing and system testing to
assure software is performing the required task.

Different levels of Testing are summarized below in figure given

below.
 6

5.4 Functional Testing

It is a type of software testing which is used to verify the

functionality of the software application, whether the function is
working according to the requirement specification

Black-box testing

It is also known by “behavioural testing” which focuses on the

functional requirements of the software, and, is performed at later
stages of testing process unlike white box which takes place at
early stage. Black-box testing aims at functional requirements
for a program to derive sets of input conditions which should be
tested. Black box is not an alternative to white-box, rather, it is a
complementary approach to find out a different class of errors
other than white-box testing.

Black-box testing is emphasizing on different set of errors which

falls under following categories:

a) Incorrect or missing functions

b) Interface errors

c) Errors in data structures or external data base access

d) Behaviour or performance errors

e) Initialization and termination errors.

 Boundary value analysis

The input is divided into higher and lower end values. If these
values pass the test, it is assumed that all values in between may
pass too.

b. Equivalence class testing

The input is divided into similar classes. If one element of a class

passes the test, it is assumed that all the class is passed.

c. Decision table testing

Decision table technique is one of the widely used case design

techniques for black box testing. This is a systematic approach
where various input combinations and their respective
system behaviour are captured in a tabular form. That’s why it is
also known as a cause-effect table. This technique is used to pick
the test cases in a systematic manner; it saves the testing time
and gives good coverage to the testing area of the
software application. Decision table technique is appropriate for
the functions that have a logical relationship between two and
more than two inputs.

5.5 Structural testing

Structural testing is done to by coders or developers as it is a way to test

the structure of the code and requires knowledge of coding.
 Cause Effect Graphing Technique

This testing considers single input conditions and do not explore

combinations of input circumstances. The steps are as followed:

Step-1 Causes & effects in the specifications are identified. A cause is a

distinct input condition or an equivalence class of input conditions. An
effect is an output condition or a system transformation

Step -2 semantic content of the specification is analysed and transformed

into a Boolean graph linking the causes & effects

Step-3 Constraints are imposed

Step-4 graph – limited entry decision table. Each column in the table
represent a test case.

Step -5 columns in the decision table are converted into test cases.

b. Basis Path testing

Basis path testing is a white-box testing technique was proposed by Tom

McCabe. This testing method enables the test case designer to derive a
logical complexity measure of a procedural design and further use this
measure as a template for defining a basis set of execution paths. Test
cases derived to exercise the basis set are guaranteed to execute every
statement in the program at least one-time during testing.

Flow Graph Notation

To understand basis path method, a simple notation for the

representation of control flow, called a flow graph (or program graph)
must be explained. The flow graph depicts logical control flow with the
help of symbols.

To demonstrate the use of a flow graph, we consider the procedural

design representation in Figure below where a flowchart is used to depict
program control structure.

Cyclomatic Complexity Measures: Control flow graphs

Cyclomatic complexity is used to measure logical complexity of a

program. When used in basis path testing method, the value computed for
Cyclomatic complexity defines the number of independent paths in the
program to give upper bound for the number of tests that must be
executed at least once.

An independent path is any path through the program that introduces at

least one new set of processing statements or a new condition. When
stated in terms of a flow graph, an independent path must move along at
least one edge that has not been traversed before the path is defined. For
example, a set of independent paths (B) for the flow graph (A) illustrated
in Figures below.

path 1: 1-11

path 2: 1-2-3-4-5-10-1-11

path 3: 1-2-3-6-8-9-10-1-11

path 4: 1-2-3-6-7-9-10-1-11

Note that each new path introduces a new edge. The path is not
considered to be an independent path because it is simply a combination
of already specified paths and does not traverse any new edges.

1-2-3-4-5-10-1-2-3-6-8-9-10-1-11

Cyclomatic complexity has its basis in graph theory and is an extremely

useful software metric. Complexity is computed in one of three ways:

1. The number of regions of the flow graph correspond to

the Cyclomatic complexity.

2. Cyclomatic complexity, V(G), for a flow graph, G, is defined as

V(G) = E + N where E is the number of flow graph edges, N is the number

of flow graph

nodes.
3. Cyclomatic complexity, V (G), for a flow graph, G, is also defined as

V (G) = P + 1,

where P is the number of predicate nodes contained in the flow graph G.

The Cyclomatic complexity can be computed using given equations:

1. The flow graph has four regions.

2. V(G) = 11 edges - 9 nodes + 2 = 4.

3. V(G) = 3 predicate nodes + 1 = 4.

Therefore, the Cyclomatic complexity of the flow graph is 4. V (G) provides

us with an upper bound for the number of independent paths that form
the basis set and, by implication, an upper bound on the number of tests
that must be designed and executed to guarantee coverage of all
program statements.

5.6 Unit testing, Integration and system testing

Unit testing implements all white box testing techniques as it is done

over the code of software.

 Data flow Testing

This testing technique emphasis to cover all the data variables included in
the program. It tests where the variables were declared and defined and
where they were used or changed.

 Control Flow Testing

The purpose of the control-flow testing to set up test cases which covers
all statements and branch conditions. The branch conditions are tested for
both being true and false, so that all statements can be covered

 Decision Coverage Testing

This technique is a white box testing method to test Boolean values. This
technique deals with possibility of two or more outcomes from Control
flow statements. By using control flow graph or chart every true or false
scenario is checked and covered by it.

5.7 Integration Testing

Integration testing is about integrating all the unit modules and test them
for their efficacy. After unit testing of individual modules integration
testing takes place.

Types of Integration Testing:

Top-down testing

In top-down testing approach, testing of higher-level modules with lower

level modules is done till successful completion of all modules. This
testing yields high design flaws which can be rectified early as critical
modules are tested first.

Bottom to up testing

The bottom to up testing approach lower level modules are tested with
higher level modules until testing is successfully completed for all the
modules. Top level modules are tested at end, so it can turn in to a fault.

Acceptance Testing

When the software is ready to hand over to the customer it has to go

through last phase of testing where it is tested for user-interaction and
response. This is important because even if the software matches all user
requirements and if user does not like the way it appears or works, it may
be rejected.

Alpha testing

The team of developer themselves perform alpha testing by using the

system as if it is being used in work environment. They try to find out how
user would react to some action in software and how the system should
respond to inputs.

Beta testing

After the software is tested internally, it is handed over to the users to use
it under their production environment only for testing purpose. This is not
as yet the delivered product. Developers expect that users at this stage
will bring minute problems, which were skipped to attend.

Mutation testing

Mutation testing is a white box approach where a mutant is inserted into

the program to test existing test case can detect the invader or
error or not. The mutant is created by making modification or alteration in
original code. This testing is done to check the ability of test cases to do
testing.

Regression Testing

Whenever a software product is updated with new code, feature or

functionality, it is tested thoroughly to detect if there is any negative
impact of the added code. This is known as regression testing.

5.8 Testing tools & standards

There are several Software testings tools available in market some are
free or open to use and others are for premium users i.e. paying
customers. Users can select the tools on the basis of their requirement of
testing.

The software testing tools are categorized below into the following:

 Test management tool

 Bug tracking tool
 Automated testing tool
 Performance testing tool
 Cross-browser testing tool
 Integration testing tool
 Unit testing tool
 Mobile/android testing tool
 GUI testing tool
 Security testing tool
5.9 Testing standards
 IEEE 829- A standard for the format of documents used in different
stages of software testing.
 IEEE 1008-A standard for unit testing.
 IEEE 1059-Guide for Software Verification and Validation Plans.
 IEEE 1044-A standard for the classification of software anomalies.
 IEEE 1044-1- A guide for the classification of software anomalies.
 BS 7925-1- A vocabulary of terms used in software testing.
 BS 7925-2-A standard for software component testing.