White Box Test & black Box test

White-Box Testing (White-box testing, also known as logic-driven testing, structural testing) is the test object as an open box. When using the White-box test method for dynamic testing, it is necessary to test the internal structure and processing process of software products without testing the function of software products. White-Box testing is also known as structural testing and logic-driven testing.

The coverage standard of the White box test method is logic overlay, loop overlay and basic path test. The logic overrides include statement overlay, decision overlay, conditional override, decision/condition overlay, conditional combination override, and path overlay.

Six coverage criteria: statement coverage, decision coverage, conditional coverage, decision/condition coverage, conditional combination coverage, and path coverage the ability to find errors is changed from weak to strong. Statements are overwritten at least once per statement. Determine that each branch that overrides each decision is executed at least once. Each condition that the condition overrides for each decision should be taken to a variety of possible values. The decision/conditional override also satisfies the coverage of the decision coverage condition. The combination of conditions overrides each of the conditions in each decision at least once. Path overrides cause every possible path in the program to be executed at least once.

White box testing is also known as structural testing or logic-driven testing, it is aware of the internal work process, can be tested to determine whether the internal action of the product according to the specifications of the normal, according to the procedures within the structure of the test procedures, inspection procedures in each path is able to work according to predetermined requirements, regardless of its function, The main methods of white box testing are logic-driven, base-path test, etc., which are mainly used for software verification.

The White box method thoroughly understands the internal logic structure of the program and tests all logical paths. The "white Box" method is a poor lift path test. When using this scenario, the tester must examine the internal structure of the program, starting with the logic of the checker and drawing the test data. The number of independent paths through the program is astronomical. But even if each path is tested, there may still be errors. First, the exhaustive path test must not be able to find out that the program violates the design specification, that is, the program itself is a wrong program. Second, the exhaustive path test cannot detect errors in the program due to missing paths. Third, the exhaustive path test may not find some data-related errors.

White box testing is mainly used in the field of software with high reliability requirements, such as: Military software, aerospace software, industrial control software and so on. The White Box testing tool should be mainly to support the development language, the depth of code coverage, the testing of embedded software, and the visualization of testing.

Support for development languages: the White Box Test tool is the source code test, the main content of the test includes lexical analysis and syntax analysis, static error analysis, dynamic detection and so on. However, for different development languages, the way and content of the test tool implementation is quite different. The main development languages currently supported by the test tools are: Standard C, C + +, Visual C + +, Java, Visual J + +, etc.

The coverage depth of the code: from the detailed analysis of the coverage source program statement, the logic coverage standard includes the following different coverage criteria: statement coverage, decision coverage, conditional coverage, conditional combination coverage, multi-conditional coverage, and correction criteria coverage.

• Statement overrides in order to expose errors in the program, each statement in the program should be executed at least once. So the meaning of the statement overlay (STatement coverage) is to select enough test data so that each statement in the program is executed at least once. Statement overrides are very weak logical overrides.

• The coverage criterion for determining coverage is slightly stronger than the statement overlay is the decision overlay (decision coverage). The meaning of the decision overlay is: design enough test cases, so that each decision in the program obtains at least one "truth" or "false value", or so that each of the program in the "true" branch and take "false" branch at least once, so the decision overlay is also known as branch coverage.

• Conditional coverage in a design program, a decision statement is a compound decision composed of multiple conditions. In order to achieve a more thorough logic overlay, the criteria for conditional coverage (ConDItion coverage) can be applied. Conditional overrides mean that a set of test cases is constructed so that the possible values for each logical condition in each decision statement are met at least once.

Multi-conditional coverage multi-conditional coverage is also referred to as conditional combination coverage, meaning: design enough test cases so that the various possible combinations of conditions in each decision appear at least once. It is obvious that the test cases satisfying the multi-conditional coverage are satisfied with the coverage of the decision, the conditional coverage and the conditional judgment combination.

• Correction Condition determination coverage correction condition The coverage is the "air transport and equipment system software certification standard" jointly developed by aviation/aerospace manufacturers and users in Europe and America, and is widely used in foreign defense and aerospace field. This coverage metric requires sufficient test cases to determine the outcome of each condition that can affect the included decision. It requires that two conditions be met: first, the entry and exit points of each program module must be considered at least once, and each program's decision to all possible result values must be converted at least once; second, the program's decision is decomposed into a Boolean condition that is connected by a logical operator (and, or). Each condition is independent of the result value of the decision.

Black box testing is also known as functional testing or data-driven testing, it is a known product should have the function of testing to detect whether each function can be used, in the test, the program as a non-open black pot, regardless of the program internal structure and internal characteristics of the case, the tester in the program Interface test, It only checks whether the program function is normally used in accordance with the requirements specification, whether the program can properly receive the input number saw and produce the correct output information, and maintain the integrity of external information (such as databases or files). The black box test method mainly includes equivalence class division, boundary value analysis, cause-fruit graph, error inference, etc., mainly used for software validation testing. The "black Box" method focuses on the external structure of the program, regardless of the internal logic structure, testing the software interface and software functions. The "black Box" method is an exhaustive input test, in which all possible inputs are used as test cases in order to detect all errors in the program in this way. In fact, there are an infinite number of test cases where people are not only testing all legitimate inputs, but also testing those that are illegal but possible.

The methods of designing test cases using black box technology are: Equivalence class division, boundary value analysis, error inference, causality diagram and comprehensive strategy.

Black-Box testing focuses on the functional requirements of testing software, or black-box testing, which enables software engineers to derive input criteria for all functional requirements of the program. Black-Box testing is not a substitute for white-box testing, but is used to assist white-box testing to find other types of errors.

The black box test attempts to discover the following types of errors:

1) function error or omission;

2) interface error;

3) data structure or external database access error;

4) Performance error;

5) initialization and termination errors.

Advantages of black Box testing

1. Basically does not have the personnel management, if the program stops running normally is the test procedure crash

2. After the design of the test example, the work is cool, of course, the more depressed is to determine the cause of crash

Disadvantages of black Box testing

1. The result depends on the design of the test example, the design part of the test example comes from experience, OUSPG is worth learning

2. There is no concept of a state transition, and some of the successful examples are mostly for PDUs, and there is no state transition for the program being tested.

3. In the absence of a State concept test, it is troublesome to find and determine the test case that caused the program crash, and it is necessary to confirm the possible test cases in the surrounding area separately. In the case of stateful testing, it is even more troublesome, especially if it is not a single testcase problem. These are more prominent in the heap problem.