Cse Viii Software Testing [10cs842] Solution

Software Testing

10CS842

Model Question Bank Solution UNIT 1 A Perspective on Testing, Examples

1. Define the following : a) Error b) Fault c) Failure d) Incident e) Test f) Test case Soln. Error People make errors. A good synonym is “mistake”. When people make mistakes while coding, we call these mistakes “bugs”. Errors tend to propagate; a requirements error may be magnified during design, and amplified still more during coding.

Fault A fault is the result of an error. It is more precise to say that a fault is the representation of an error, where representation is the mode of expression, such as narrative text, dataflow diagrams, hierarchy charts, source code, and so on. “Defect” is a good synonym for fault; so is “bug”. Faults can be elusive.

FailureA failure occurs when a fault executes. Two subtleties arise here: one is that failures only occur in an executable representation, which is usually taken to be source code, or more precisely, loaded object code. The second subtlety is that this definition relates failures only to faults of commission.

Incident When a failure occurs, it may or may not be readily apparent to the user (or customer or tester). An incident is the symptom(s) associated with a failure that alerts the user to the occurrence of a failure.

Test Testing is obviously concerned with errors, faults, failures, and incidents. A test is the act of exercising software with test cases. There are two distinct goals of a test: either to find failures, or to demonstrate correct execution.

Dept. of CSE, SJBIT

1

Software Testing

10CS842

Test Case A test case has an identity, and is associated with a program behavior. A test case also has a set of inputs, a list of expected outputs. 2. Difference between functional testing and structural testing Soln. Functional Testing: With the functional approach to test case identification, the only information that is used is the specification of the software. There are two distinct advantages to functional test cases: they are independent of how the software is implemented, so if the implementation changes, the test cases are still useful, and test case development can occur in parallel with the implementation, thereby reducing overall project development interval. On the negative side, functional test cases frequently suffer from two problems: there can be significant redundancies among test cases, and this is compounded by the possibility of gaps of untested software. Structural Testing: Structural testing is the other fundamental approach to test case identification. To contrast it with Functional Testing, it is sometimes called White Box (or even Clear Box) Testing. The clear box metaphor is probably more appropriate, because the essential difference is that the implementation (of the Black Box) is known and used to identify test cases. Being able to “see inside” the black box allows the tester to identify test cases based on how the function is actually implemented. 3. What is software testing? Why it is so important in SDLC? Soln. There are two main reasons: to make a judgment about quality or acceptability, and to discover problems. We test because we know that we are fallible — this is especially true in the domain of software and software controlled systems. The goal of this chapter is to create a perspective (or context) on software testing.It is so important in SDLC development phases, there are three opportunities for errors to be made, resulting in faults that propagate through the remainder of the development. One prominent tester summarizes this life cycle as follows: the first three phases are “Putting Bugs IN”, the testing phase is Finding Bugs, and the last three phases are “Getting Bugs OUT” . The Fault Resolution step is another opportunity for errors (and new faults). When a “fix” causes formerly correct software to misbehave, the fix is deficient Dept. of CSE, SJBIT

2

Software Testing

10CS842

4. Explain the triangle problem statement along with flow chart for traditional implementation. Soln. The Triangle Program accepts three integers as input; these are taken to be sides of a triangle. The output of the program is the type of triangle determined by the three sides: Equilateral, Isosceles, Scalene, or NotATriangle.

Triangle Program Specification Keyboard Triangle Sides

Triangle Program

Screen Prompts & Triangle Types Data Dictionary Triangle Sides : a + b + c

triangle sides

1. Get Input a, b, c

3. Triangle Type

a, b, c

a, b, c are non-negative integers

2. Is_A_ Triangle

type code : equilateral | isosceles | scalene | not a triangle

True

prompts : 'Enter three integers which are sides of a triangle'

False 4. Output Controller type code

triangle type : 'Equilateral' | 'Isosceles' | 'Scalene' | 'Not a Triangle' prompts

triangle type

Figure 2.1 Flowchart for the Traditional Triangle Program Implementation

5. Explain the IEEE error and fault taxonomy and IEEE standard anomaly process in software testing. Soln. definitions of error and fault hinge on the distinction between process and product: process refers to how we do something, and product is the end result of a process. The point at which testing and Software Quality Assurance meet is that SQA typically tries to improve the product Dept. of CSE, SJBIT

3

Software Testing

10CS842

by improving the process. In that sense, testing is clearly more product oriented. SQA is more concerned with reducing errors endemic in the development process, while testing is more concerned with discovering faults in a product. Both disciplines benefit from a clearer definition of types of faults. Faults can be classified in several ways: the development phase where the corresponding error occurred, the consequences of corresponding failures, difficulty to resolve, risk of no resolution IEEE Standard Classification for Software Anomalies. (A software anomaly is defined in that document as “a departure fro the expected”, which is pretty close to our definition.) The IEEE standard defines a detailed anomaly resolution process built around four phases (another life cycle): recognition, investigation, action, and disposition. Some of the more useful anomalies are given. Table 1 Logic Faults missing case(s) duplicate case(s) extreme condition neglected misinterpretation missing condition extraneous condition(s) test of wrong variable incorrect loop iteration

6. Explain error and fault taxonomies. Soln. Definitions of error and fault hinge on the distinction between process and product: process refers to how we do something, and product is the end result of a process. The point at which testing and Software Quality Assurance meet is that SQA typically tries to improve the product by improving the process. In that sense, testing is clearly more product oriented. SQA is more concerned with reducing errors endemic in the development process, while testing is more concerned with discovering faults in a product. Both disciplines benefit from a clearer definition of types of faults. Faults can be classified in several ways: the development phase where the

Dept. of CSE, SJBIT

4

Software Testing

10CS842

corresponding error occurred, the consequences of corresponding failures, difficulty to resolve, risk of no resolution

7. Explain in detail various levels of software testing with embedded device like STAM as an example. Soln. To better discuss the issues of integration and sytem testing, we need an example with larger scope. The SATM system communicates with bank customers via the fifteen screens. Using a terminal with features SATM customers can select any of three transaction types: deposits, withdrawals, and balance inquiries, and these can be done on two types of accounts, checking and savings. When a bank customer arrives at an SATM station, screen 1 is displayed. The bank customer accesses the SATM system with a plastic card encoded with a Personal Account Number (PAN), which is a key to an internal customer account file, containing, among other things, the customer’s name and account information. If the customer’s PAN matches the information in the customer account file, the system presents screen 2 to the customer. If the customer’s PAN is not found, screen 4 is displayed, and the card is kept. At screen 2, the customer is prompted to enter his/her Personal Identification Number (PIN). If the PIN is correct (i.e., matches the information in the customer account file), the system displays screen 5; otherwise, screen 3 is displayed. The customer has three chances to get the PIN correct; after three failures, screen 4 is displayed, and the card is kept. On entry to screen 5, the system adds two pieces of information to the customer’s account file: the current date, and an increment to the number of ATM sessions. The customer selects the desired transaction from the options shown on screen 5; then the system immediately displays screen 6, where the customer chooses the account to which the selected transaction will be applied.

Dept. of CSE, SJBIT

5

Software Testing

10CS842

UNIT 2 Boundary Value Testing, Equivalence Class Testing, Decision TableBased Testing:

1. What are the limitations of BVA Soln. Boundary value analysis works well when the program to be tested is a function of several independent variables that represent bounded physical quantities. A quick look at the boundary value analysis test cases for NextDate. There is very little stress on February and on leap years, for example. The real problem here is that there are interesting dependencies among the month, day, and year variables. Boundary value

analysis presumes the variables to be truly

independent. Even so, boundary value analysis

happens to catch end-of-month and end-of-

year faults. Boundary value analysis test cases

are derived from the extrema of bounded,

independent variables that refer to physical quantities, with no consideration of the nature of the function, nor of the semantic meaning of the variables. We see boundary value analysis test cases to be rudimentary, in

the sense that they are obtained with very little insight and

imagination. As with so many things, you get what you pay for.

2. Justify the usage of boundary value analysis with function of two variables and highlight the limitations of boundary value analysis. Soln. The basic idea of boundary value analysis is to use input variable values at their minimum, just above the minimum, a nominal value, just below their maximum, and at their maximum. The next part of boundary value analysis is based on a critical assumption; it’s known as the “single fault” assumption in reliability theory. This says that failures are only rarely the result of the simultaneous occurrence of two (or more) faults. Thus the boundary value analysis test cases are obtained by holding the values of all but one variable at their nominal values, and letting that variable assume its extreme values. The boundary value analysis test cases for our function F of two variables are:

{, ,,, , , , , Dept. of CSE, SJBIT

6

Software Testing

10CS842

, } Limitations of Boundary Value Analysis Boundary value analysis works well when the program to be tested is a function of several independent variables that represent bounded physical quantities. The key words here are independent and physical quantities.

3.

Explain weak normal and strong robust equivalence class testing with next date problem an example. Soln. If it is not the last day of a month, the NextDate function will simply increment the day value. At the end of a month, the next day is 1 and the month is incremented. At the end of a year, both the day and the month are reset to 1, and the year is incremented. Finally, the problem of leap year makes determining the last day of a month interesting. With all this in mind, we might postulate the following equivalence classes: By choosing separate classes for 30 and 31 day months, we simplify the last day of the month question. By taking February as a separate class, we can give more attention to leap year questions. We also give special attention to day values: days in D 1 are (nearly) always incremented, while days in D4 only have meaning for months in M2. Finally, we have three classes of years, the special case of the year 1900, leap years, and common years

Weak normal Equivalence Class Test Cases These classes yield the following weak equivalence class test cases. As before, the inputs are mechanically selected from the approximate middle of the corresponding class: Case ID

Month

Day

Year

Expected Output

WE1

6

14

1900

6/15/1900

WE2

7

29

1912

7/30/1912

WE3

2

30

1913

invalid input

WE4

6

31

1900

invalid input

Dept. of CSE, SJBIT

7

Software Testing

10CS842

Strong robust Equivalence Class Test Cases Using the same equivalence classes, we find the strong equivalence class test cases shown in the table below. The same value selection criterion is used. We still don’t have a “perfect” set of test cases, but I think any tester would be a lot happier with the 36 strong equivalence class test cases.

4. Discuss the usage of decision table method to device test cases with example of commission problem and triangle problem. Soln. Decision tables have been used to represent and analyze complex logical relationships since the early 1960s. They are ideal for describing situations in which a number of combinations of actions are taken under varying sets of conditions. Technique : To identify test cases with decision tables, we interpret conditions as inputs, and actions as outputs. Sometimes, conditions end up referring to equivalence classes of inputs, and actions refer to major functional processing portions of the item being tested. The rules are then interpreted as test cases. Because the decision table can mechanically be forced to be complete, we know we have a comprehensive set of test cases. Conditions c1: a emphasis on unit testing and rapid iteration for acceptance testing by customers

Test and Analysis Strategy •

Lessons of past experience –

•

•

an organizational asset built and refined over time

Body of explicit knowledge –

more valuable than islands of individual competence

–

amenable to improvement

–

reduces vulnerability to organizational change (e.g., loss of key individuals)

Essential for –

avoiding recurring errors

–

maintaining consistency of the process

–

increasing development efficiency

Dept. of CSE, SJBIT

39