First Word
There are generally four levels of tests: unit testing, integration testing, system testing, and acceptance testing.
Software testing methods are traditionally divided into white-box and black-box testing.
One of the testing methodologies is “V-model”.
Testing Types and process
Regression testing
There’re a lot of types, one of them is called “Regression testing”.
Regression testing focuses on finding defects after a major code change has occurred. In other words, it encsures that changes does not introduce new faults.
Testing process
Traditional: waterfall. Testing is done by independent group of testers after development. This practice often results in the testing phase being used as a project buffer to compensate for project delays.
New trend: Agile or Extreme, which adhere to TDD Model. In this process, unit tests are written first. This methodology increases the testing effort done by development.
Bottom Up Testing: lowest level components are tested first, then integrated and used to facilitate the testing of higher level components.
Top Down Testing: top integrated modules are tested and the branch of the module is tested step by step until the end.
Testing Methods
Black-box
Black-box testing is a method of software testing that examines the functionality of an application without peering into its internal structures or workings. This can be applied to every level of software testing: unit, integration, system and acceptance.
White-box
White-box testing (also known as structural testing) is a method of testing software that tests internal structures or workings of an application, as opposed to its functionality. In white-box testing, an internal perspective of the system and programming skills are used to design test cases. The tester chooses inputs to exercise paths through the code and determine the appropriate outputs.
Other-box
A black-box tester is unaware of the internal structure of the application to be tested, while a white-box tester has access to the internal structure of the application.
Gray-box testing is a combination of both. Testers require both highlevel and detailed knowledge of the application.
Whitebox in detail
Whitebox testing is based on program code. The extent to which source code is executed (covered).
- statement coverage
- path coverage
- (multiple-) condition coverage
- decision / branch coverage
- loop coverage
- definition-use coverage
Use of “flow graphs” to test the coverage. source
Blackbox in detail
- Equivalence partitioning
- Boundary value analysis
- Behavioural testing (interaction with w/ an environment)
- Random testing (random walk thru the system/mouse click)
- Stress testing (huge data, DoS attack, power off)
- Error guessing (Ad hoc, not really a technique)
Equivalence partitioning
This is related to “validate” input. First identify input equivalence classes, then make the test case by changing each valid cases into invalid.
The testing theory related to equivalence partitioning says that only one test case of each partition is needed. In other words it is sufficient to select one test case out of each partition to test the program. To use more cases will not find new faults.
The values within one partition are considered to be “equivalent”. Thus the number of test cases can be reduced considerably.
Example:
There are 12 months per year
Valid partition is from january to december
Invalid partition is from <=0 and >=13
A longer but better example
Boundary Value Analysis
- Testing boundary conditions (directly on, above, and beneath the edges)
- Choose input boundary values
- Choose input boundary values that reaches output boundary (given the input value, choose expected output +/- 1)
Example:
Suppose an integer boundary is 1 to 50, Then test for 0,2 values & 49, 51 vales.
Suppose input = 5, output = 100, then test input = 5, output = 99, 100, 101
Don’t start with designing white-box test cases! Start with black-box test cases, then check white-box coverage.
More examples
Q: how to test a log-in window?
A: Eq. class: username empty, exits, don’t exist and exceed length limit. Same for password field. Boundary: input length equals, less than or larger than length limit. source
Q: how to test a vendor machine?
Functional: put in $$ and get a coke
Edge condition: put in Chinese RMB?
Stress: keep putting $$ and popping goods
Security: can you break the machine?
Last Word
Sometime it is not feasible to test everything. Instead, prioritize your testing so that you only focus on areas that present the greatest risk or have the greatest probability of occurring.
For example, you might choose to test the slowest client computer, the busiest server, or the least reliable network link.