Practical-9

Aim: Explain Testing Methods, Test cases.

Application: Railway Reservation System

TESTING METHODS:

Boundary value analysis:-

1. If input condition specified large bounded by variables X&Y and also the values above & below
X&Y.
2. If input condition specifies the no. of values then test cases should be designed with min & max.
3. If the output condition specifies large bounded by X&Y and then test case should be designed
with value X&Y.
4. If output condition specifies the no. of values then the test cases should be designed with min &
max value.
5. If the internal flag data structure specifies such boundary then the cases must be designed.

The pair wise testing:-

1. These are many parameters that determine the behavioral of software product.
2. Testing such product must be done using different values in different conduct.
3. Testing authors combine action is complex hence a new approach of testing is designed.

State based testing:-

1. States: Entity which has same impart on o/p.

2. Transition: represent how the state changes to another an occurrence of same event.
3. Event: i/p to system.
4. Action: o/p for event.

Control flow based testing:-

1. Designed flow graph for a blogs.

2. Calculate the cyclomatic completely.
3. Select a basic set of path.

Data flow based test coverage criteria:-

1. The testing bound can data flow mechanism perform testing on definition& uses of various in
program.
2. In this method definition &use are required the DV chain is about by identify defination.Use pair
program structure.
3. SET DE(n) condition variables that are defined at model.

Use cases:-
090120107059 Page 1
 1. Deciding whether test case will satisfy conversely critical or not.
2. Generating the test cases or the decided criteria
3. For deciding whether test case will satisfy converge criteria are need to use came to all.
4. But such tools are not easily available hence fully automated tools for selecting the test cases that
satisfy the criteria is must at all available.

The box approach:-

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.

1) White box testing

White box testing is when the tester has access to the internal data structures and algorithms including
the code that implement these.
The following types of white box testing exist:
 API testing (application programming interface) - testing of the application using public
and private APIs
 Code coverage - creating tests to satisfy some criteria of code coverage (e.g., the test
designer can create tests to cause all statements in the program to be executed at least
once)
 Fault injection methods - improving the coverage of a test by introducing faults to test
code paths
 Mutation testing methods
 Static testing - White box testing includes all the test

2) Black box testing

Black box testing treats the software as a "black box"—without any knowledge of internal
implementation. Black box testing methods include: equivalence partitioning, boundary value analysis,
all-pairs testing, fuzz testing, model-based testing, exploratory testing and specification-based testing.

Specification-based testing: Specification-based testing aims to test the functionality of software

according to the applicable requirements.]Thus, the tester inputs data into, and only sees the
output from, the test object. This level of testing usually requires thorough test cases to be
provided to the tester, who then can simply verify that for a given input, the output value (or
behavior), either "is" or "is not" the same as the expected value specified in the test case.
Specification-based testing is necessary, but it is insufficient to guard against certain risks.

Advantages and disadvantages: The black box tester has no "bonds" with the code, and a
tester's perception is very simple: a code must have bugs. Using the principle, "Ask and you shall
receive," black box testers find bugs where programmers do not. On the other hand, black box
testing has been said to be "like a walk in a dark labyrinth without a flashlight," because the tester
doesn't know how the software being tested was actually constructed. As a result, there are
situations when (1) a tester writes many test cases to check something that could have been tested
by only one test case, and/or (2) some parts of the back-end are not tested at all.
Therefore, black box testing has the advantage of "an unaffiliated opinion", on the one hand, and the
disadvantage of "blind exploring", on the other.

090120107059 Page 2
3) Grey box testing

Grey box testing involves having knowledge of internal data structures and algorithms for purposes
of designing the test cases, but testing at the user, or black-box level. Manipulating input data and
formatting output do not qualify as grey box, because the input and output are clearly outside of the
"black-box" that we are calling the system under test. This distinction is particularly important when
conducting integration testing between two modules of code written by two different developers,
where only the interfaces are exposed for test. However, modifying a data repository does qualify as
grey box, as the user would not normally be able to change the data outside of the system under test.
Grey box testing may also include reverse engineering to determine, for instance, boundary values or
error messages.

TEST CASES:

A test case in software engineering is a set of conditions or variables under which a tester will
determine whether an application or software system is working correctly or not. The mechanism for
determining whether a software program or system has passed or failed such a test is known as a 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. Written test cases are usually collected into test suites.

1) Formal test cases

 In order to fully test that all the requirements of an application are met, there must be at least two
test cases for each requirement: one positive test and one negative test; unless a requirement has
sub-requirements. In that situation, each sub-requirement must have at least two test cases.
 Keeping track of the link between the requirement and the test is frequently done using a
traceability matrix. Written test cases should include a description of the functionality to be
tested, and the preparation required to ensure that the test can be conducted.
 A formal written test-case is characterized by a known input and by an expected output, which is
worked out before the test is executed. The known input should test a precondition and the
expected output should test a post condition.

2) Informal test cases

 For applications or systems without formal requirements, test cases can be written based on the
accepted normal operation of programs of a similar class. In some schools of testing, test cases
are not written at all but the activities and results are reported after the tests have been run.
 In scenario testing, hypothetical stories are used to help the tester think through a complex
problem or system. These scenarios are usually not written down in any detail.
 They can be as simple as a diagram for a testing environment or they could be a description
written in prose. The ideal scenario test is a story that is motivating, credible, complex, and easy
to evaluate.

090120107059 Page 3