Homework Title / No.

: term paper on testing techniques Course Instructor :Neha Tewari Date of submission :May 7, 2010 Students Roll No:RD2601A28

Course Code : CSE302

Section No. : D2601

Declaration: I declare that this assignment is my individual work. I have not copied from any other students work or from any other source except where due acknowledgment is made explicitly in the text, nor has any part been written for me by another person. Students Signature : Sushil Goyal Evaluators comments: _____________________________________________________________________ Marks obtained : ___________ out of ______________________ Content of Homework should start from this page only:

ACKNOWLEDGEMENT
Several people played an important role in the accomplishing of this term paper .And i would like to acknowledge them here. Firstly I am heartily thankful to my instructor, Neha Tewari, whose encouragement, guidance and support from the initial to the final level enabled me to develop an understanding of the subject. I also offer my regards and blessings to Poojan Jamwal,Simerdeep Singh and Udai Sood who supported me in any respect during the completion of the term paper. To my roommates for generous support and inspiration. To my family for assisting me in any type of condition. Last but not the least,i thank almighty god for numerous reasons. Sushil Goyal

1.

Software Testing Techniques

The importance of software testing and its impact on software cannot be underestimated. Software testing is a fundamental component of software quality assurance and represents a review of specification, design and coding. The greater visibility of software systems and the cost associated with software failure are motivating factors for planning, through testing. It is not uncommon for a software organization to spent 40% of its effort on testing.

1.1

Software Testing Fundamentals

During testing the software engineering produces a series of test cases that are used to rip apart the software they have produced. Testing is the one step in the software process that can be seen by the developer as destructive instead of constructive. Software engineers are typically constructive people and testing requires them to overcome preconceived concepts of correctness and deal with conflicts when errors are identified.

1.1.1 Testing objectives

A number of rules that act as testing objectives are: Testing is a process of executing a program with the aim of finding errors. A good test case will have a good chance of finding an undiscovered error. A successful test case uncovers a new error.

1.1.2 Test information flow

Information flow for testing follows the pattern shown in the figure below. Two types of input are given to the test process: (1) a software configuration; (2) a test configuration. Tests are performed and all outcomes considered, test results are compared with expected results. When erroneous data is identified error is implied and debugging begins. The debugging procedure is the most unpredictable element of the testing procedure. An error that indicates a discrepancy of 0.01 percent between the expected and the actual results can take hours, days or months to identify and correct Software configuration
Test Results

Evaluation

Errors Debug Corrections

Testing Test configuration

Error rate data Reliability Model

Expected results

Predicted reliability

Test information flow

1.1.3 Test case design

The design of software testing can be a challenging process. However software engineers often see testing as an after thought, producing test cases that feel right but have little assurance that they are complete. The objective of testing is to have the highest likelihood of finding the most errors with a minimum amount of timing and effort. A large number of test case design methods have been developed that offer the developer with a systematic approach to testing. Methods offer an approach that can ensure the completeness of tests and offer the highest likelihood for uncovering errors in software. Any engineering product can be tested in two ways: (1) Knowing the specified functions that the product has been designed to perform, tests can be performed that show that each function is fully operational (2) knowing the internal workings of a product, tests can be performed to see if they jell. The first test approach is known as a black box testing and the second white box testing.

1.2

White Box Testing

White box testing is a test case design approach that employs the control architecture of the procedural design to produce test cases. Using white box testing approaches, the software engineering can produce test cases that (1) guarantee that all independent paths in a module have been exercised at least once, (2) exercise all logical decisions, (3) execute all loops at their boundaries and in their operational bounds, (4) exercise internal data structures to maintain their validity.

1.3

Basis Path Testing

Basic path testing is a white box testing techniques that allows the test case designer to produce a logical complexity measure of procedural design and use this measure as an approach for outlining a basic set of execution paths. Test cases produced to exercise each statement in the program at least one time during testing.

1.3.1 Flow Graphs

The flow graph can be used to represent the logical flow control and therefore all the execution paths that need testing. To illustrate the use of flow graphs consider the procedural design depicted in the flow chart below. This is mapped into the flow graph below where the circles are nodes that represent one or more procedural statements and the arrow in the flow graph called edges represent the flow control. Each node that includes a condition is known as a predicate node, and has two or more edges coming from it.

1.4 Control Structure Testing

Although basis path testing is simple and highly effective, it is not enough in itself. Next we consider variations on control structure testing that broaden testing coverage and improve the quality of white box testing.

1.4.1 Condition Testing

Condition testing is a test case design approach that exercises the logical conditions contained in a program module. A simple condition is a Boolean variable or a relational expression, possibly with one NOT operator

1.4.2 Data Flow Testing

The data flow testing method chooses test paths of a program based on the locations of definitions and uses of variables in the program. Various data flow testing approaches have been examined. For data flow testing each statement in program is allocated a unique statement number and that each function does not alter its parameters or global variables

1.4.3 Loop Testing

Loops are the basis of most algorithms implemented using software. However, often we do consider them when conducting testing. Loop testing is a white box testing approach that concentrates on the validity of loop constructs. Four loops can be defined: simple loops, concatenate loops, nested loops, and unstructured loops.

1.5

Black Box Testing

Black box testing approaches concentrate on the fundamental requirements of the software. Black box testing allows the software engineer to produce groups of input situations that will fully exercise all functional requirements for a program. Black box testing is not an alternative to white box techniques. It is a complementary approach that is likely to uncover a different type of errors that the white box approaches. Black box testing tries to find errors in the following categories: (1) incorrect or missing functions, (2) interface errors, (3) errors in data structures or external database access, (4) performance errors, and (5) initialization and termination errors. By applying black box approaches we produce a set of test cases that fulfill requirements: (1) test cases that reduce the number of test cases to achieve reasonable testing, (2) test cases that tell use something about the presence or absence of classes of errors.

2.

Software Testing Strategies

A strategy for software testing integrates software test case design techniques into a wellplanned set of steps that cause the production of software. A software test strategy provides a road map for the software developer, the quality assurance organization, and the customer. Any testing strategy needs to include test planning, test case design, test execution, and the resultant data collection evaluation. A software test strategy should be flexible enough to promote the creativity and customization that are required to adequately test all large software-based systems.

2.1

Unit Testing

Unit testing concentrates verification on the smallest element of the program the module. Using the detailed design description important control paths are tested to establish errors within the bounds of the module.

2.1.1 Unit test considerations

The tests that are performed as part of unit testing are shown in the figure below. The module interface is tested to ensure that information properly flows into and out of the program unit being tested.
Interface Local data structures Boundary Conditions Independent paths Error-handling paths

Module

Test cases Unit test

2.1.2 Unit test procedures

Unit testing is typically seen as an adjunct to the coding step. Once source code has been produced, reviewed, and verified for correct syntax, unit test case design can start.

2.3

Integration Testing

Once all the individual units have been tested there is a need to test how they were put together to ensure no data is lost across interface, one module does not have an adverse

impact on another and a function is not performed correctly. Integration testing is a systematic approach that produces the program structure while at the same time producing tests to identify errors associated with interfacing.

2.3.1 Top-Down integration

Top-down integration is an incremental approach to the production of program structure. Modules are integrated by moving downwards through the control hierarchy, starting with the main control module.

2.3.2 Bottom-up Integration

Bottom-up integration testing, begins testing with the modules at the lowest level (atomic modules). As modules are integrated bottom up, processing required for modules subordinates to a given level is always available and the need for stubs is eliminated.

2.3.3 Comments on Integration Testing

There has been much discussion on the advantages and disadvantages of bottom-up and top-down integration testing. Typically a disadvantage is one is an advantage of the other approach. The major disadvantage of top-down approaches is the need for stubs and the difficulties that are linked with them. Problems linked with stubs may be offset by the advantage of testing major control functions early. The major drawback of bottom-up integration is that the program does not exist until the last module is included.

2.4

Validation Testing

As a culmination of testing, software is completely assembled as a package, interfacing errors have been identified and corrected, and a final set of software tests validation testing are started. Validation can be defined in various ways, but a basic one is valid succeeds when the software functions in a fashion that can reasonably expected by the customer.

2.4.1 Validation test criteria

Software validation is achieved through a series of black box tests that show conformity with requirements. A test plan provides the classes of tests to be performed and a test procedure sets out particular test cases that are to be used to show conformity with requirements.

2.4.2 Configuration review

An important element of the validation process is a configuration review. The role of the review is to ensure that all the components of the software configuration have been properly developed, are catalogued and have the required detail to support the maintenance phase of the software lifecycle.

2.4.3 Alpha and Beta testing

It is virtually impossible for develop to determine how the customer will actually use the program. When custom software is produced for customer a set of acceptance tests are performed to allow the user to check all requirements. Conducted by the end user instead of the developer, an acceptance test can range from an informal test drive to rigorous set of tests. Most developers use alpha and beta testing to identify errors that only users seem to be able to find. Alpha testing is performed at the developers sites, with the developer checking over the customers shoulder as they use the system to determine errors. Beta testing is conducted at more than one customer locations with the developer not being present. The customer reports any problems they have to allow the developer to modify the system.

2.5

System Testing

Ultimately, software is included with other system components and a set of system validation and integration tests are performed. Steps performed during software design and testing can greatly improve the probability of successful software integration in the larger system. System testing is a series of different tests whose main aim is to fully exercise the computer-based system. Although each test has a different role, all work should verify that all system elements have been properly integrated and form allocated functions. Below we consider various system tests for computer-based systems.

2.6

Conclusion

Software testing accounts for a large percentage of effort in the software development process, but we have only recently begun to understand the subtleties of systematic planning, execution and control.