Problem:
Myers [Mye79] uses the following program as a self-assessment for your ability to specify adequate testing: A program reads three integer values. The three values are interpreted as representing the lengths of the sides of a triangle. The program prints a message that states whether the triangle is scalene, isosceles, or equilateral. Develop a set of test cases that you feel will adequately test this program.
Answer:
A test case in soft ware engineering is a set of conditions or variables under which a tester will determine if a requirement or use case upon an application is partially or fully satisfied. If may take many test cases to determine that a requirement is fully satisfied.
A set of test cases that adequately test the program.
Test case 1:
Serial no: 1
Test case name: - Scalene triangle
Steps:
1. A program reads three integer values. The three values are interpreted as representing the lengths of the sides of the triangle.
2. The lengths of the sides of the triangle are different i.e is called scalene triangle.
3. The three integer values are 
. This is scalene triangle
Expected results:
The program prints a message that states the triangle is scalene
Serial No: 2
Test case name (or) title: - Isosceles triangle
Steps:
1. A program reads three integer values. The three values are interpreted as representing the lengths of the sides of the triangle.
2. The two lengths of the sides of the triangle are equal and one side of the triangle is different among reaming sides.
3. The three integer values are 
i.e. 
this Isosceles triangle.
Expected results”
The program prints a message that stales the triangle is Isosceles.
Serial no: 3
Test case name (or) title: Equilateral triangle
Steps:
A program reads three integer values. The three values are interpreted as representing the lengths of the sides of the triangle.
The lengths of the sides of the triangle are equal i.e. called equilateral triangle.
The three integer values are 
i.e. 
Expected results:-
This program prints a message that states the triangle is equilateral.
Problem:
Design and implement the program (with error handling where appropriate) specified in Problem 23.1. Derive a flow graph for the program and apply basis path testing to develop test cases that will guarantee that all statements in the program have been tested. Execute the cases and show your results.
Answer:
The implementation of the program
Void triangle ( )
{
int a,b,c ;
read (a,b,c) ; ----(1)
if 
then
print 
else
if 
then
if 
then
print 
else
print 
else
if 
then
print 
else
if 
then
print 
else
print 
}
A flow graph for the program
Cyclomatic complexity , 
Hence , maximum number of test paths = 8
Test cases – one derived from each possible, independent
Path of program execution.
| no | Test path | Input data | remarks | Expected results |
| 1.1 | 1 – 2 – 5 - 19 |
| Test for error detection only a must be –ve Others +Ve | “sides must be positive |
| 1.2 | 1 – 2 – 3 – 5 - 19 |
| Test for error detection only b must be –Ve others +Ve | “sides must be positive” |
| 1.3 | 1 – 2 – 3 – 4 – 5 - 19 |
| Test for error detection only c must be –VE other +Ve | “ sides must be positive |
| 2 | 1 – 2 – 3 – 4 – 6 – 7 – 8 – 10 – 18 -19 |
| All must be +Ve | “ equilateral triangle” |
| 3.1 3.2 4 | 1 – 2 – 3 – 4 – 6 – 7 – 9 – 10 – 18 -19. 1 – 2 – 3 – 4 – 6 – 11 – 12 – 17 – 18 – 19 1 – 2 – 3 – 4 – 6 – 11 – 13 – 15 – 16 – 17 – 18 - 19 |
| Sum of any two Sides must be > 3rd side Sum of any two sides must be > 3rd side. Sum of any two sides must be > 3rd side. | “Iso sceles triangle” “Iso sceles triangle” “Scalene triangle” |
1. A valid triangle exhibits 2 properties
2. Test cases 1 and 3 consists of 3 sub – test cases each upon refinement.
Problem:
Can you think of any additional testing objectives that are not discussed in Section 23.1.1?
Answer:
In addition to those objectives:
• A successful test demonstrates compliance with function and performance;
• A successful test uncovers documentation errors;
• A successful test uncovers interfacing problems;
• A successful test demonstrates an understanding of program architecture, data structure, interface design and procedural design;
• A successful test establishes an entry into a test case database that may later be used for regression testing.
Problem:
Select a software component that you have designed and implemented recently. Design a set of test cases that will ensure that all statements have been executed using basis path testing.
Answer:
592-14-4P SA CODE: 4475
SR CODE: 4467
Recently am implemented the software component for spell checker system
Stem description:
Collect the words from the named document and look them up in a main directory. Display the words on the standard output, if they don’t appear in either directory or cannot be derived from those that do appear by applying certain inflections. Prefix or suffixes.
Design diagram for spell checker:
Procedure for description:
Step 1: Get document file name
Step 2: Splits document into words.
Step 3: Look up each word in the main dictionary and a private dictionary.
(a) If the word appears in either dictionary, or is derivable via various rules, it is deemed to be spelled correctly and ignored.
(b) Other wise, the misspelled word is out put.
Test cases for the spell check system using the basis path testing:
Basis path testing is a white box testing technique. Test cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time during testing.
Input of the basis path test case scenario:-
| S.NO. | Test case name | Test case description | Actual values | Obtained values | Serenity |
| (1) | Spell check login page. Open/close members | Classes
| Abstract classes Alphabetic words | Expected and on limited | |
| (2) | Private dictionary | Cardinality | Expected | Unlimited | |
| (3) | Main dictionary | Static dictionary | Unlimited |
insert word
find word
remove word
next word 1terator
super class members.C++ notation for an interface description:
Class word:
Public:
Word (void)
Word (const string &); int insert (int index, chore);
int clove (word &);
in concept (const word &);
&; int compare ( 
(3) );
Class document:
Public:
Document (void);
Document (void)
Virtual int open (const string & file name);
Int sort (int options);
…
Class document_1terator}
Public
Document_1terator (const Document +&);
Int next item (word &)
…..
};
Problem:
Specify, design, and implement a software tool that will compute the cyclomatic complexity for the programming language of your choice. Use the graph matrix as the operative data structure in your design.
Answer:
Cyclomatic complexity is a software metric that provides a quantitative measure of the logical complexity of a program. When used in the context of basis path testing method, the value computed for Cyclomatic complexity defines the number of independent paths in the basis set of a program and provides us with an upper bound for the number of tests that must be conducted to ensure that all statements have been executed 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 for the flow graph given 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
Each new path introduces a new edge. The path 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 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. Paths 1, 2, 3 and 4 constitute a basis set for the for the above flow graph. That is, if tests can be designed to force execution of these paths(a basis set), every statement in the program will have been guaranteed to be executed at least one time and every condition will have been executed on its true and false sides. This basis set is not unique. In fact a number of different basis sets can be derived for a given procedural design.
Cyclomatic complexity has a foundation in graph theory and provides us with an extremely useful software metric. Complexity is computed in one of the three ways.
1. The number of regions of the flow graph corresponds to the Cyclomatic complexity.2. Cyclomatic complexity, V(G), for a flow graph, G is defined as
V(G) = E – N + 2
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.
Referring to the above figure, the Cyclomatic complexity can be computed using each of the algorithms.
1. the flow graph has four regions.2. V(G) = 11 edges – 9 nodes + 2 = 43. V(G) = 3 predicate nodes + 1 = 4
Therefore the Cyclomatic complexity of the flow graph is 4. The value of 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
Problem:
Read Beizer [Bei95] or a related Web-based source (e.g., www.laynetworks.com/Discrete%20Mathematics_1g.htm) and determine how the program you have developed in Problem 23.5 can be extended to accommodate various link weights. Extend your tool to process execution probabilities or link processing times.
Answer: Problem:
Design an automated tool that will recognize loops and categorize them as indicated in Section 23.5.3.
Answer:
592-14-7P SA CODE: 4475
SR CODE: 4467
Let the sensors tool from the log in identification sensor control process is done through below diagram.
From the above one, Data process is done through the following steps.
(1) Sensor is in ideal state.
(2) Card inserted in to reader.
Reader check the user Id
If it is not correct,
Then it rejects the request.
If it is correct.
Then ask about next request that is Fin square access.
If it is correct then Alarm blinks with accepts. Then door is open.
Other wise, it is not open.
Now we need to apply the loop testing for the above tool.
testing is a white box testing technique that focuses exclusively on the validity of loop
Loops of four types:
Simple loop
Nested loop
Concatenated loop
Unstructured loop
Simple loop for Sensor tool:
(1) Card inserted in to reader.
Step (1)
It checks the user Id
If it is correct, then skip the loop entirely.
Otherwise it shows it false reject
And through this simple loop,
Only one passes through the loop
Two passes through the loop
‘m’ passes through the loop when 
Pass through the loop.
Nested loop:
Based con the sensor tool, it checks the inner most loop and set the all other loops to minimum value,
First it checks the user Id bases on the
(1) Valid numerical value
(2) Finger access
The process is like this
Step (1) Check the user Id with numerical value, if it is not correct
Then go to the previous step
Otherwise it asks for next loop, that is finger access.
If it is also correct
Then Alarm is activate with accept request.
Otherwise control is go back
Concatenated loop:
It is tested by using the approach defined for simple loops, if each of the loops is independent of the other.
Structure is like this,
From the Sensor tool,
First it checks the user Id
If it is valid request then control goes to next loop
Second it checks for finger access
If it is also valid then request pass to next control
Unstructured loops:-
Using this loop, class of loops should be redesigned to reflect the use of the structured programming constructs.
Structure of loop:
From the Sensor’s tool
First it checks for user acceptance
If users Id is valid
Then control goes to check for another loop.
Otherwise
Control comes out.
If user Id & other controls are valid
Then control goes to check for another one.
Otherwise control came out.
The process is going like this until for all loops should be use of the structured programming constructs. Class of loop should be redesigned
Problem:
Extend the tool described in Problem 23.7 to generate test cases for each loop category, once encountered. It will be necessary to perform this function interactively with the tester.
Answer:
From the problem 14.7, we may extend the automated tool. That is sensor tool.
We may extend the sensor tool with basic function. That is “
” when request a
Next “problem light” should be allowed.
Control flow diagrams of above description:-
Test cases for each loop of sensor tool
At first
It check for reader input
If it is access with valid input data
Then request is accept
Otherwise, it show’s the fault result.
Ex: for (request is in numeric)
If // calculate the valid request
}
}; condition……
Nested loops:-
In this, it checks for the valid input and then check for manage copying. If there is a problem occur than problem diagnosis with light 
mode.
Ex: if
{//check for valid input
Else
{
//check for valid copying request
}
};
Concatenation loop:-
Through this loop testing we may test the condition of concatenation.
For each request it checks the valid request. That means,
If the first request is valid than came out from loop and go for next loop
If that also valid then goes for next, otherwise control came out from loop.
Ex: check for reader point
If //access is valid
{/
}
Else // control goes for next level (copy)
{
}
Else // control goes for next one (
{
}
end;
Problem:
Give at least three examples in which black-box testing might give the impression that “everything’s OK,” while white-box tests might uncover an error. Give at least three examples in which white-box testing might give the impression that “everything’s OK,” while black-box tests might uncover an error.
Answer:
In general, it can be easy to achieve, for example, branch coverage, with cases that do not test boundary values. Black box tests will expose these problems.
Some examples in block box testing:
Caught by Black-Box, but likely missed by White-Box
• Division by Zero – white box unlikely to hit the exact number, black box may find this as a boundary value.
• Possible off by one error – likely boundary case in black-box testing.
• All performance issues – white box is not concerned with this at all.
• Memory errors (very large input) – likely to be a block box testing boundary value, but not needed for white-box testing coverage.
• Rounding errors and overflow errors – again, likely block box testing boundary cases, but not needed to test for this to achieve any white-box testing coverage.
• Requirements not implemented (missing path problem) – block box testing would easily catch (missing function), white-box testing would not since we would not know the code is missing.
Some examples in white-box testing:
Caught by White-Box, but missed by Black-Box (examples):
• Unexpected and erroneous branches to optimize the code – if some strange (and wrong) optimization is used for some cases, bb is unlikely to catch it, but white-box testing would force coverage of this code and we might find the problem.
• Missing requirements (the code has been implemented, but the requirement is not there)
• Code and requirements are out of date
Problem:
Will exhaustive testing (even if it is possible for very small programs) guarantee that the program is 100 percent correct?
Answer:
The exhaustive testing doesn’t guarantee that the program is 100 percent correct. In white box testing. The exhaustic path testing has two flaws.
1. The number of unique paths through program is astronomical.
2. It could test every path and program may still have error’s.
(i) in this case, it does not guarantee program matches specification, i.e wrong program.
(ii) Missing paths would not detect absence of necessary paths.
(iii) The tested data could still have sensitive errors
Example: A program has to compare two numbers for convergence if
is wrong because should compare to abs 
The deflection of this error dependent on values used for A and B and world not necessarily be found by executing every path through program.
Problem:
Test a user manual (or help facility) for an application that you use frequently. Find at least one error in the documentation.
Answer:
It is important to note that testing must also extend to the third element of the software configuration – documentation.
Errors in documentation can be as devastating to the acceptance of the program as errors in data source code. Noting is more frustrating than following a user – guide or an on line help facility exactly and getting results or behaviors that do not coincide with those predicted by the documentation. It is for reason that documentation testing should be a meaningful part of every software test plan. Documentation testing can be approached in two phases. The first phase, review and inspection, examines the document for editorial clarity. The second phase live test, uses the documentation in conjunction with the use of the actual program.
Solution: CHAPTER23: TESTING CONVENTIONAL APPLICATIONS
23.1 See Myers [MYE79] for an extremely detailed "solution" to this problem.
23.2 You may elect to distribute the program source code to your students (embedding a few errors purposely).
23.3 In addition to those objectives:
a) A successful test demonstrates compliance with function and performance;
b) A successful test uncovers documentation errors;
c) A successful test uncovers interfacing problems;
d) A successful test demonstrates an understanding of program architecture, data structure, interface design and procedural design;
e) A successful test establishes an entry into a test case database that may later be used for regression testing.
23.4 Answers will vary
23.5 - 23.6 With some extensions, these problems could be assigned as a term project.
23.7 – 23.8 With some extensions, these problems could be assigned as a term project.
23.9 For specific input, an error occurs internally resulting in:
1) Improper data placed in a global data area;
2) Improper flags that will be tested in a subsequent series of tests;
3) Improper hardware control that can only be uncovered during system test; yet "correct" output is produced.
23.10 No, even an exhaustive test (if it were possible) may be unable to uncover performance problems and errors in the specification of the software. In this case both input and output "equivalence classes" are considered. For each class, the student should identify boundaries based on numeric ranges, elements of a set, system commands, etc. This can be a paper exercise in which test cases for a GUI for some well know application are derived.
23.11 It might be a good idea to generate a set of use-cases to help "test" user documentation