C Language Programming specification--------7 testability

7.1 prepare test Code, test case

(1) At the same time programming to select the appropriate test points for unit testing, and carefully construct the test code, test cases, and give a clear annotated description. The Test Code section should act as a submodule (in the module) to facilitate the installation and disassembly of the code in the module (via the commissioning switch)

(2) Before the integration test/system, to build a test environment, test projects and test cases, while carefully analyzing and optimizing test cases to improve testing efficiency. A good test case should simulate as much as possible the boundary values encountered by the program, various complex environments, and some extreme situations.

(3) Before writing the code, the program should be designed to debug and test methods and means, and design a variety of debugging switches and corresponding test code such as printing functions. The debugging and testing of the program is a very important stage in the software life cycle, so it becomes a key problem how to test the software in a comprehensive and high-rate way and find out the errors in the software as much as possible. Therefore, before writing the source code, in addition to a relatively complete set of test plans, you should also design a series of code testing methods, for unit testing, integration testing and system to facilitate the connection.

7.2 use assertions to identify software problems and improve code testability

(1) The assertion is that a certain hypothetical condition is checked (it can be understood that there is no action if the condition is set up, otherwise it should be reported), it can quickly identify and locate software problems, and automatically alarm system errors. Assertions can be hidden deep in the system, with other means very difficult to find the problem of positioning, thereby shortening the positioning time of software problems, improve the system testability. In practice, it is possible to design assertions flexibly, depending on the situation.

Example: Below is an assertion in the C language, designed with a macro. (where null is 0L)

#ifdef _EXAM_ASSERT_TEST_//If using assertion testing

void Exam_assert (char * file_name, unsigned int line_no)

{

printf ("\n[exam]assert failed:%s, line%u\n",

file_name, Line_no);

Abort ();

}

#define EXAM_ASSERT (condition)

if (condition)//If the condition is true, no action

NULL;

else//Otherwise report

Exam_assert (__file__, __line__)

#else//If the assertion test is not used

#define EXAM_ASSERT (condition) NULL

#endif/* End of ASSERT */

(2) Use assertions to check that the program should not occur when it is running properly but that there is a possibility of illegal situations when commissioning.

(3) You cannot use assertions to check the error conditions that the final product will definitely appear and must handle. Assertions are used to handle error conditions that should not occur, and to write a bug-proof program, rather than an assertion, for situations that may occur and must be handled. If a module receives a message from another module or link, it checks the reasonableness of the message, which is a normal error check and cannot be implemented with assertions.

(4) Add explicit annotations to more complex assertions, clarify the meaning of assertions and reduce unnecessary misuse.

(5) Confirm the parameters of the function with an assertion. Example: Suppose a function parameter has a pointer, then you can check it before using the pointer, as follows.

int exam_fun (unsigned char *str)

{

Exam_assert (str = NULL); Check the "Assume pointer is not empty" condition with assertions

.....//other Program Code

}

7.3 Version Control

(1) Formal software products should be asserted and other debugging code removed (that is, the relevant commissioning switch off), speed up the software operation speed.

(2) in the software system to set up and cancel the test means, can not affect the function of the software implementation, such as the software with the test code and the software to turn off the test code, in the functional behavior should be consistent.

(3) Use the commissioning switch to switch between the debug version and the official version of the software, instead of having both the official version and the debug version of the different source files to reduce the difficulty of maintenance

(4) The debug version and release version of the software should be unified maintenance, do not allow separation, and always pay attention to ensure that two versions in the implementation of functional consistency.

C Language Programming specification--------7 testability