Saturday, January 26, 2008
Saturday, January 19, 2008
Software Testing
Software Testing:
It is a destructive process,yes a creative destruction.
Testing adds value to the program by increasing your level of confidence in it.
Testing adds value to the program by raising its quality or reliability.
Testing - When is a program correct?
There are levels of correctness. We must determine the appropriate level of correctness for each system because it costs more and more to reach higher levels.
No syntactic errors
Compiles with no error messages
Runs with no error messages
There exists data which gives correct output
Gives correct output for required input
Correct for typical test data
Correct for difficult test data
Proven correct using mathematical logic
Obeys specifications for all valid data
Obeys specifications for likely erroneous input
Obeys specifications for all possible input
Testing - How do you do it?
Reference: Myers, The Art of Software Testing
You might also consult
Pfleeger, Software Engineering, Chapters 7 - 8 Sommerville, Software Engineering, Chapters 20 - 23
Testing is the process of executing a program with the intent of finding errors .
A good test case is one which has a high probability of detecting an as yet undiscovered error.
A successful test case is one which detects an as yet undiscovered error.
An unsuccessful test case is one for which the program produces the correct result.
Test cases must be written for the invalid and the unexpected, as well as for the valid and expected.
"Testing is the process of demonstrating that errors are not present" (or that "the system works correctly") is an impossible task
Testing to uncover errors is a feasible task.
Thoroughly inspect the results of each test. Compare carefully with the expected results.
An error is present if the program does not do what it is supposed to do.
An error is also present if the program does what it is not supposed to do.
A programmer should avoid attempting to test his or her own program.
A programming organization should avoid attempting to test its own programs.
Testing - How do you do it
Black box testing (data driven or input/output driven)
Not concerned about the internal behavior or structure Test cases are derived solely from the specifications. Exhaustive input testing --- Desirable, but impossible Create equivalence classes of test cases Programs with memory.
White box testing (logic driven)
Examine the internal structure, Execute every statement, Execute every path. Too many paths --- May still not match its specifications
--- Solving the wrong problem?
--- Missing paths
--- Data sensitivity
Testing - Test case design
What subset of all possible test cases has the highest probability of detecting the most errors?
Logic coverage testing
Decision (branch) coverage
--- Each decision is true once and false once
Condition coverage
--- Each condition in a decision takes all possible values Decision/condition coverage
Equivalence partitioning
Good test case reduces by more than one the number of other test cases which must be developed .Good test case covers a large set of other possible cases Classes of valid inputs Classes of invalid inputs
Boundary value analysis
Situations on, above, or below edges of input, output, condition classes have high probability of success
Cause-effect graphing
Myers gives a formal methodology Explore combinations of conditions Good way to uncover ambiguities and incompleteness in specifications
Error guessing
Intuition and experience Maintain a list of possible errors or error-prone situations
The Strategy - Some of all
Testing - How do you do it?
Myers also discusses
Program inspections, walkthroughs, and reviews Module testing High-order (integration) testing, Debugging strategies, Test tools
Testing - What are the milestones?
Reference: Pfleeger, Software Engineering, Chapter 8.
The test results demonstrate that the test criteria for each module, and for the system, have been met. For each test performed, the test results typically include:
Means of control - initiate and control by manual or automatic means
Test data - includes input data, input commands, output data, and messages produced by the system
Test script - step-by-step description of how to perform the test, including how to end it Results - evidence that the test was performed according to its data and script specifications
For each error or deficiency uncovered, a discrepancy report typically includes:
State of the system before the error occurred.
Evidence of the error
Action which appears to have led to the error's occurrence
Description of how the system should work
Reference to relevant requirements
Impact of the error on system performance
Source of the error
Changes made to remove the error
A detailed record of errors discovered and corrected during development often saves hours of maintenance time.
Testing - What tools are available to help you?
See Myers, The Art of Software Testing, Chapter 8
Module drivers
Static flow analysis
Test coverage
Mathematical proofs of correctness
Program correctness proving programs
Symbolic execution
Test data generators
Environment simulators
Virtual machines
Software error studies
Software error data collection
Predictive models
Complexity measures
Program library systems
Interactive debugging
It is a destructive process,yes a creative destruction.
Testing adds value to the program by increasing your level of confidence in it.
Testing adds value to the program by raising its quality or reliability.
Testing - When is a program correct?
There are levels of correctness. We must determine the appropriate level of correctness for each system because it costs more and more to reach higher levels.
No syntactic errors
Compiles with no error messages
Runs with no error messages
There exists data which gives correct output
Gives correct output for required input
Correct for typical test data
Correct for difficult test data
Proven correct using mathematical logic
Obeys specifications for all valid data
Obeys specifications for likely erroneous input
Obeys specifications for all possible input
Testing - How do you do it?
Reference: Myers, The Art of Software Testing
You might also consult
Pfleeger, Software Engineering, Chapters 7 - 8 Sommerville, Software Engineering, Chapters 20 - 23
Testing is the process of executing a program with the intent of finding errors .
A good test case is one which has a high probability of detecting an as yet undiscovered error.
A successful test case is one which detects an as yet undiscovered error.
An unsuccessful test case is one for which the program produces the correct result.
Test cases must be written for the invalid and the unexpected, as well as for the valid and expected.
"Testing is the process of demonstrating that errors are not present" (or that "the system works correctly") is an impossible task
Testing to uncover errors is a feasible task.
Thoroughly inspect the results of each test. Compare carefully with the expected results.
An error is present if the program does not do what it is supposed to do.
An error is also present if the program does what it is not supposed to do.
A programmer should avoid attempting to test his or her own program.
A programming organization should avoid attempting to test its own programs.
Testing - How do you do it
Black box testing (data driven or input/output driven)
Not concerned about the internal behavior or structure Test cases are derived solely from the specifications. Exhaustive input testing --- Desirable, but impossible Create equivalence classes of test cases Programs with memory.
White box testing (logic driven)
Examine the internal structure, Execute every statement, Execute every path. Too many paths --- May still not match its specifications
--- Solving the wrong problem?
--- Missing paths
--- Data sensitivity
Testing - Test case design
What subset of all possible test cases has the highest probability of detecting the most errors?
Logic coverage testing
Decision (branch) coverage
--- Each decision is true once and false once
Condition coverage
--- Each condition in a decision takes all possible values Decision/condition coverage
Equivalence partitioning
Good test case reduces by more than one the number of other test cases which must be developed .Good test case covers a large set of other possible cases Classes of valid inputs Classes of invalid inputs
Boundary value analysis
Situations on, above, or below edges of input, output, condition classes have high probability of success
Cause-effect graphing
Myers gives a formal methodology Explore combinations of conditions Good way to uncover ambiguities and incompleteness in specifications
Error guessing
Intuition and experience Maintain a list of possible errors or error-prone situations
The Strategy - Some of all
Testing - How do you do it?
Myers also discusses
Program inspections, walkthroughs, and reviews Module testing High-order (integration) testing, Debugging strategies, Test tools
Testing - What are the milestones?
Reference: Pfleeger, Software Engineering, Chapter 8.
The test results demonstrate that the test criteria for each module, and for the system, have been met. For each test performed, the test results typically include:
Means of control - initiate and control by manual or automatic means
Test data - includes input data, input commands, output data, and messages produced by the system
Test script - step-by-step description of how to perform the test, including how to end it Results - evidence that the test was performed according to its data and script specifications
For each error or deficiency uncovered, a discrepancy report typically includes:
State of the system before the error occurred.
Evidence of the error
Action which appears to have led to the error's occurrence
Description of how the system should work
Reference to relevant requirements
Impact of the error on system performance
Source of the error
Changes made to remove the error
A detailed record of errors discovered and corrected during development often saves hours of maintenance time.
Testing - What tools are available to help you?
See Myers, The Art of Software Testing, Chapter 8
Module drivers
Static flow analysis
Test coverage
Mathematical proofs of correctness
Program correctness proving programs
Symbolic execution
Test data generators
Environment simulators
Virtual machines
Software error studies
Software error data collection
Predictive models
Complexity measures
Program library systems
Interactive debugging
Amod Purandare
Hi Friends,
I'm Amod.
Here I am
This is me
This is the place where you can get information about
1>Transformer Designing
2>Software Testing
3>Market tips
4>Movies
5>Songs
6>Meditation
7> Yog
8>Cricket
9>more things that you require from this blog.
Please let me know.
Fill free to ask anything.
We will find the solutions.
But I will not display any content which is confidential , privileged.
I would appreciate if you could leave any feedback and comments on my blog.If possible share information to help others.
Some of the posts posted in this blog are collected. Some have been prepared by me. If any one have objections regarding any copied posts. Please mail me to make that post removed.
& remember friends this is our blog.You can give me your openion about this blog.
You can mail me
We will make the information interactive.
We will make the world better.
Subscribe to:
Posts (Atom)