Gray box test

The gray-box test is between the white-box test and the black-box test. It can be understood that the gray-box test focuses on the correctness of the output for the input, and also on the internal performance, however, this kind of attention is not as detailed and complete as it is in the white box. It only uses some characterization phenomena, events, and signs to determine the internal running status. Sometimes the output is correct, but it is actually an internal error. This is a lot of cases. If we use a white box test every time, the efficiency will be very low. Therefore, we need to adopt such a gray box method.
Directory [hide]

• 1. Academic meaning
• 2. Target task
• 3 principle object
• 4 validation criteria
• 5 References
• 6 References

Grey box test-academic meaning

The Gray Box is a device that is locally recognized by a program or system's working process. The gray-box test, also known as the gray-box analysis, is a software debugging method based on the limited awareness of the internal details of the program. Testers may know how system components interact, but lack a detailed understanding of internal program functions and operations. For internal processes, the gray-box test regards the program as a black box that must be analyzed from the outside.

Gray box test

Gray-box testing is usually used with web service applications because the Internet can still provide relatively stable interfaces despite the complexity and changes of applications and the continuous development and progress. Since the tester is not required to access the source code, the gray-box test is not aggressive and biased. There is a significant difference between developers and testers, and the risk of personnel conflicts is minimized. However, gray-box testing is more difficult to identify and solve potential problems than white-box testing. Especially in a single application, the internal details of white-box testing can be fully grasped.

The gray-box test combines the elements of the white-box test box black-box test. It takes into account the user end, specific system knowledge and operating environment. It evaluates the design of application software in the collaborative environment of system components. The gray-box test consists of methods and tools that are derived from the environment in which the internal knowledge box of the application interacts with it, it can be used for black box testing to improve test efficiency, error discovery, and error analysis efficiency. Gray-box tests involve input and output, but design tests using information about code and program operations that are typically out of the tester's field of view.

Gray-box test-target task

4th white box replacement Test Method

Software testing is an important part of the software development process. It is used to confirm whether the quality or performance of a program meets the requirements set forth before development. Software testing is the final review of Software Requirement Analysis, Design Specification Description and Coding before the software is put into operation. It is a key step to ensure software quality. Software testing is the process of executing programs to detect errors. Software testing spans two phases in the software life cycle: Usually the necessary tests (unit tests) are performed on each module after it is compiled ). Encoding and unit testing are in the same phase of software survival. After this stage, comprehensive testing of the software system is required, which is another independent stage of the software survival, namely the testing stage.

Purpose of software testing

The first is to confirm the quality of the software. One is to confirm that the software has done what you expect (Dotherightthing), and the other is to confirm that the software has done this event (Doitright) in the correct way ).

The second is to provide information, such as feedback to developers or program managers and information prepared for risk assessment.

Third, software testing is not only testing software products, but also the software development process. If many problems are found after a software product is developed, the software development process may be defective. Therefore, the third purpose of software testing is to ensure that the entire software development process is of high quality.

Software quality is measured in several aspects:

1. Use the correct method to make a job right at the right time (Doingtherightthingsrightattherighttime ).
2. meet the requirements of some application standards, such as the different operation habits and requirements of users in different countries, the maintainability and testability of the project, and so on.
3. Quality itself means that the software meets the requirements set at the beginning, and the elegant or exquisite code skills do not represent the high quality of the software (Qualityisdefinedasconformancetorequirements, notas "goodness" or "elegance ").
4. Quality also indicates that it meets the customer's needs (Qualityalsomeans "meetcustomerneeds "). As a software testing industry, the most important thing is to look at the product from the customer's needs and from the customer's perspective. How can customers use this product, what problems will be encountered during use. Only when these problems are solved can the quality of software products be said to be improved.

Tasks of testers during software development:

1. Search for bugs;
2. Avoid defects in the software development process;
3. measure the quality of software;
4. Focus on user needs.
The overall goal is to ensure the quality of the software.

Gray-box test-principle object

Gray-box test cycle diagram

Principles of software testing

Software testing will derive two different testing principles from different perspectives. From the user's perspective, we hope that the software testing can fully expose the problems and defects in the software, to determine whether the product can be accepted, from the developer's point of view, we hope that the test can indicate that the software product does not have errors and has correctly met the user's needs, establish people's confidence in software quality.

To achieve the above principles, pay attention to the following points:
1. "early and continuous testing" should be taken as the motto of developers
2. programmers should avoid checking their own programs. testing should be done by an independent professional software testing organization.
3. legal input, illegal input, and various boundary conditions should be taken into account when designing test cases. In special cases, extreme states and unexpected states should be created, such as abnormal network interruptions and power outages.
4. Be sure to pay attention to errors in testing. This has a lot to do with the programmer's programming level and habits.
5. There must be A confirmation process for the test error result. Generally, there must be a B to confirm the error, for serious errors, a review can be held for discussion and analysis.
6. Develop a strict test plan and make the test schedule as loose as possible. Do not complete a high-level test in a very short time.
7. The relevance of regression testing must be fully noticed. It is not uncommon to modify an error and cause more errors.
8. It is self-evident that all testing process documents should be properly stored. the reproducibility of testing often depends on testing documents.

Software testing objects

Software testing is not equal to program testing. Software testing should run throughout the entire software definition and development period. Therefore, the requirements analysis, outline design, detailed design, program code, and other documents obtained at various stages, including requirement specifications, outline design specifications, detailed design specifications, and source code, should be the object of software testing. In the verification of requirement understanding and expression correctness, design and expression correctness, implementation correctness, and Operation correctness, problems occurring at any stage may be manifested in software testing.

Gray-box test-validation criteria

Gray box test

After the comprehensive test, the software has been fully assembled and interface errors have been eliminated. The last step of the software test is to confirm the test. Validation testing should check whether the software works as required by the contract, that is, whether the validation criteria in the software requirement specification are met.

1. Confirm test criteria

Implementation software validation should pass a series of cartridge tests. The validation test also requires the development of the test plan and process, the test plan should specify the test Type and Test Progress, and the test process defines some special test cases to indicate whether the software and requirements are consistent. Whether the software meets all the functions and performance stipulated in the contract, whether the documents are complete, accurate man-machine interface and other aspects (for example, portability, compatibility, error recovery capability, and maintainability) are satisfactory to users. There are two possibilities to confirm the test results: one is that the functional and performance indicators meet the requirements of the Software Requirement Description, and the other is that the software does not meet the requirements of the Software Requirement Description, the user is unacceptable. Serious errors and deviations found at this stage of the project are generally difficult to correct within the scheduled period. Therefore, you must negotiate with the user to find a proper solution to the problem.

2. configuration review

Another important part of validation testing is configuration review. The purpose of the review is to ensure that the software is fully configured, sorted, and detailed necessary for software maintenance.

System testing should consist of several different tests to fully run the system, verify that all components of the system can work with political parties and complete the assigned tasks. The following briefly discusses several types of system tests:

Gray box test

1. Recovery test

The recovery test mainly checks the system's fault tolerance capabilities. When a system error occurs, can the system be corrected and restarted at a specified time interval. The recovery test should first adopt various methods to force the system to fail, and then verify whether the system can be restored as soon as possible. For automatic recovery, You need to verify the correctness of reinitialization, checkpointingmechanisms, datarecovery, and restart mechanisms. For manual recovery systems, you also need to estimate the average repair time to determine whether it is within the acceptable range.

2. Security Testing

The security test checks the system's defense against illegal intrusions. During the Security test, the tester pretended to be an illegal intruder and tried to break through the defense line in various ways. For example, ① attempts to intercept or decrypt passwords; ② specialized software damages the protection mechanism of the system; ③ intentionally leads to system failure and attempts to illegally access the recovered machine; ④ attempts to browse non-confidential data, deduce the required information, and so on. Theoretically, as long as there is sufficient time and resources, there is no inaccessible system. Therefore, the principle of system security design is to make the cost of illegal intrusion more than the value of protected information. At this time, the illegal intruder is no longer available.

3. Strength Testing

The strength test checks the program's ability to resist exceptions. The intensity test always forces the system to run under abnormal resource configuration. For example, ① when the normal frequency of interruption is one or two per second, the test cases that generate ten interruptions per second are run; ② increase the data input rate quantitatively and check the ability of the input sub-function to reflect; ③ run the test cases that require the maximum storage space (or other resources); ④ run the test cases that may cause the virtual storage operating system to crash or the disk data to shake violently, and so on.

4. Performance Testing

For real-time and embedded systems, even if the software meets functional requirements, it may not be able to meet performance requirements. Although from unit testing, each test step includes performance testing, however, only after the system is truly integrated can the system fully and reliably test the running performance in the real environment to complete this task. Performance testing is sometimes combined with strength testing and often requires support from other software and hardware.

Gray-box test-Reference

Gray box test

1. Black box testing

A black box test is also called a function test or a data-driven test. It is a function of a known product. It is tested to check whether each function can be used normally. during testing, taking the program as an unopened hacker, the tester tests the program interface without considering the internal structure and features of the program, it only checks whether the program functions are normally used according to the requirements of the specification, and whether the program can properly receive the input saw to generate the correct output information, and maintain the integrity of external information (such as databases or files. Black box testing methods include equivalence classification, edge value analysis, cause and error prediction, and are mainly used for software validation testing. The black box method focuses on the external structure of the program, does not consider the internal logic structure, and tests the software interface and software functions. The "black box" method is a testing of input. Only when all possible input is used as a test can all errors in the program be detected in this way. In fact, there are infinite number of tests. People should not only test all valid inputs, but also test those illegal but possible inputs.

2. white box testing

The white-box test is also called the structure test or logic-driven test. It knows the internal working process of the product and can be used to test whether the internal actions of the product are normal according to the specifications, test the program according to the internal structure of the program to check whether each channel in the program can work correctly according to the predefined requirements, regardless of its functions, the main methods of white box testing include logic-driven and baseline testing, which are mainly used for software verification.

The "white box" method provides a comprehensive understanding of the internal logic structure of the program and tests all logical paths. The "white box" method is to test the exhaustive path. When using this scheme, the tester must check the internal structure of the program and obtain the test data starting from the logic of the program. The number of independent paths throughout the program is astronomical. However, even if each path is tested, errors may still occur. First, the exhaustive path test cannot identify that the program violates the design specifications, that is, the program itself is a wrong program. Second, the exhaustive path test cannot identify errors caused by missing paths in the program. Third, some data-related errors may not be found in the exhaustive path test.