5511203

PRACTICAL -7

Aim: Study of software testing and explain testing fundamentals and various techniques.

Software Testing:

Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to the process of executing a program or application with the intent of finding software bugs (errors or other defects).

Software testing can be stated as the process of validating and verifying that a computer program/application/product meets the requirements that guided its design and development; works as expected, can be implemented with the same characteristics, and satisfies the needs of stakeholders.

Software testing, depending on the testing method employed, can be implemented at any time in the software development process. Traditionally most of the test effort occurs after the requirements have been defined and the coding process has been completed, but in the Agile approaches most of the test effort is on-going. As such, the methodology of the test is governed by the chosen software development methodology.

Test cases:

A test case, in software engineering, is a set of conditions or variables under which a tester will determine whether an application, software system or one of its features is working as it was originally established for it to do. The mechanism for determining whether a software program or system has passed or failed such a test is known as test oracle. In some settings, an oracle could be a requirement or use case, while in others it could be a heuristic. It may take many test cases to determine that a software program or system is considered sufficiently scrutinized to be released. Test cases are often referred to as test scripts, particularly when written - when they are usually collected into test suites.

I = input

O = output

S = state of system

5511203

Fig. 7.1 Testing techniques

Types of testing:

Software testing methods are traditionally divided into white- and black-box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases.

Black-box testing: treats the software as a "black box", examining functionality without any knowledge of internal implementation. The testers are only aware of what the software is supposed to do, not how it does it. Black-box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, state transition tables, decision table testing, fuzz testing, model-based testing, use case testing, exploratory testing and specification-based testing.

Techniques of Black box testing:-

Equivalence partitioning (also called Equivalence Class Partitioning or ECP) is a software testing technique that divides the input data of a software unit into partitions of equivalent data from which test cases can be derived. In principle, test cases are designed to cover each partition at least once. This technique tries to define test cases that uncover classes of errors, thereby reducing the total number of test cases that must be developed. An advantage of this approach is reduction in the time required for testing software due to lesser number of test cases. Equivalence partitioning is typically applied to the inputs of a tested component, but may be applied to the outputs in rare cases. The equivalence partitions are usually derived from the requirements specification for input attributes that influence the processing of the test object.

Boundary value analysis is a software testing technique in which tests are designed to include representatives of boundary values. The idea comes from the Boundary

Code

Design document

SRS document

Design test suite Test suite

Run test cases and check

results Failure test

Debug programError list

Corrected errorsCorrected

program

5511203

(topology). Given that we have a set of test vectors to test the system, a topology can be defined on that set. Those inputs which belong to the same equivalence class as defined by the equivalence partitioning theory would constitute the basis (topology). Given that the basis sets are neighbors as defined in neighborhood (mathematics), there would exist a boundary between them. The test vectors on either side of the boundary are called boundary values. In practice this would require that the test vectors can be ordered, and that the individual parameters follow some kind of order (either partial order or total order).

Fig 7.2 Black box testing

White-box testing: (also known as clear box testing, glass box testing, transparent box testing and structural testing) tests internal structures or workings of a program, as opposed to the functionality exposed to the end-user. In white-box testing an internal perspective of the system, as well as programming skills, are used to design test cases. The tester chooses inputs to exercise paths through the code and determine the appropriate outputs. This is analogous to testing nodes in a circuit, e.g. in-circuit testing (ICT).While white-box testing can be applied at the unit, integration and system levels of the software testing process, it is usually done at the unit level. It can test paths within a unit, paths between units during integration, and between subsystems during a system–level test. Though this method of test design can uncover many errors or problems, it might not detect unimplemented parts of the specification or missing requirements.

Techniques used in white-box testing include:

a) Fault based: The objective in fault-based testing is to design tests that have a high likelihood of uncovering possible faults. Fault-based testing begins with the analysis model. The tester looks for plausible faults (i.e., aspects of the implementation of the system that may result in defects) to determine whether these faults exist, test cases are designed to exercise the design or code. If the analysis and design models can provide insight into what is likely to go wrong, then fault-based testing can find a significant number of errors.

5511203

b) Coverage based: In computer science, code coverage is a measure used to describe the

degree to which the source code of a program is tested by a particular test suite. A

program with high code coverage has been more thoroughly tested and has a lower

chance of containing software bugs than a program with low code coverage. For

example;

Statement Coverage:

In this white box testing technique try to cover 100% statement coverage of the code, it means

while testing the every possible statement in the code is executed at least once.

Tools: To test the Statement Coverage the Cantata++ can be used as white box testing tool.

Decision Coverage:

In this white box testing technique try to cover 100% decision coverage of the code, it means

while testing the every possible decision conditions like if-else, for loop and other conditional

loops in the code is executed at least once. Tools: To cover the Decision Coverage testing in the

code the TCAT-PATH is used. This supports for the C, C++ and Java applications.

Condition Coverage:

In this white box testing technique try to cover 100% Condition coverage of the code, it means

while testing the every possible conditions in the code is executed at least once.

Decision/Condition Coverage:

In this mixed type of white box testing technique try to cover 100% Decision/Condition coverage

of the code, it means while testing the every possible Decisions/Conditions in the code is

executed at least once.

Multiple Condition Coverage:

In this type of testing we use to cover each entry point of the system to be executed once.

In the actual development process developers are make use of the combination of techniques

those are suitable for their software application.