|
Glossary of Software QA/Testing
Part:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Black-box Testing
1. Functional testing based on requirements with no knowledge of the internal program structure or data. Also known as closed-box testing.
2. Black box testing indicates whether or not a program meets required specifications by spotting faults of omission -- places where the specification is not fulfilled.
3. Black-box testing relies on the specification of the system or the component that is being tested to derive test cases. The system is a black-box whose behavior can only be determined by studying its inputs and the related outputs
4. Black box testing is functional testing, not based on any knowledge of internal software design or code. Black box testing are based on requirements and functionality.
white box testing
1.White box testing is based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths and conditions.
Clear box testing is white box testing. Glass box testing is also white box testing. Open box testing is also white box testing.
2. White box testing is a testing approach that examines the application's program structure, and derives test cases from the application's program logic.
3. Testing approaches that examine the program structure and derive test data from the program logic. This is also known as clear box testing, glass-box or open-box testing. White box testing determines if program-code structure and logic is faulty. The test is accurate only if the tester knows what the program is supposed to do. He or she can then see if the program diverges from its intended goal. White box testing does not account for errors caused by omission, and all visible code must also be readable.
4. White box method relies on intimate knowledge of the code and a procedural design to derive the test cases. It is most widely utilized in unit testing to determine all possible paths within a module, to execute all loops and to test all logical expressions.
Using white-box testing, the software engineer can (1) guarantee that all independent paths within a module have been exercised at least once; (2) examine all logical decisions on their true and false sides; (3) execute all loops and test their operation at their limits; and (4) exercise internal data structures to assure their validity (Pressman, 1997).
This form of testing concentrates on the procedural detail. However, there is no automated tool or testing system for this testing method. Therefore even for relatively small systems, exhaustive white-box testing is impossible because of all the possible path permutations.
Clear box testing?
Clear box testing is the same as white box testing. It is a testing approach that examines the application's program structure, and derives test cases from the application's program logic.
Another term for white-box testing. Structural testing is sometimes referred to as clear-box testing, since “white boxes” are considered opaque and do not really permit visibility into the code. This is also known as glass-box or open-box testing.
Glass box testing?
Glass box testing is the same as white box testing. It's a testing approach that examines the application's program structure, and derives test cases from the application's program logic.
Open box testing?
Open box testing is same as white box testing. It's a testing approach that examines the application's program structure, and derives test cases from the application's program logic.
Grey box testing?
Grey box testing is a software testing technique that uses a combination of black box testing and white box testing. Gray box testing is not black box testing, because the tester does know some of the internal workings of the software under test. In grey box testing, the tester applies a limited number of test cases to the internal workings of the software under test. In the remaining part of the grey box testing, one takes a black box approach in applying inputs to the software under test and observing the outputs.
Part:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
| 