Testing Techniques Basics...
![Google](http://www.google.com/images/poweredby_transparent/poweredby_000000.gif)
Custom Search
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.
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.
Testing objectives
A number of rules that act as testing objectives are:
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. It is the uncertainty in debugging that causes testing to be difficult to schedule reliability
Test information flow
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.
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.
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.
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. It is the uncertainty in debugging that causes testing to be difficult to schedule reliability
Test information flow
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.
Black box testing relates to the tests that are performed at the software interface. Although they are designed identify errors, black box tests are used to demonstrate that software functions are operational; that inputs are correctly accepted and the output is correctly produced. A black box test considers elements of the system with little interest in the internal logical arrangement of the software. White box testing of software involves a closer examination of procedural detail. Logical paths through the software are considered by providing test cases that exercise particular sets of conditions and/or loops. The status of the system can be identified at diverse points to establish if the expected status matches the actual status.
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.
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.
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.
Flow Chart
Flow Graph