Huawei software programming specification Learning (7)-Testability

Huawei software programming specification Learning (7) -- Testability

7-1: In the same project group or product group, you must have a set of unified commissioning switches and corresponding printing functions for Integrated Testing and system joint debugging, which must be described in detail.

Note: This rule applies to project teams or product groups.

7-2: In the same project group or product group, the format of the information string to be tested and printed must be uniform. The information string must contain at least the module name (or source file name) and line number.

Note: The unified debugging information format facilitates integration testing.

7-3: When programming, You must select an appropriate test point for unit testing, carefully construct the test code and test cases, and give clear comments. The test code part should be used as a sub-module (in the module) to facilitate the installation and disassembly of the test code in the module (through the commissioning switch)

Note: Prepare for unit testing.

7-4: Before integration test/system joint debugging, you must construct the test environment, test items, and test cases, and analyze and optimize the test cases carefully to improve the test efficiency.

Note: Good test cases should try to simulate the boundary values encountered by the program, various complex environments, and some extreme situations.

7-5: Use assertions to discover software problems and improve code Testability

Note: assertion checks certain hypothetical conditions (it can be understood that if the condition is true, there is no action; otherwise, a report should be reported). It can quickly detect and locate software problems, at the same time, automatic alarms are triggered for system errors. Assertions can be used to locate problems that are hidden deep in the system and difficult to find by other means, thus shortening the software issue locating time and improving the testability of the system. In actual applications, You can flexibly design Assertions based on specific situations.

Example: The following is an asserted in C language that is designed with a macro. (Null is 0l)

# Ifdef _ exam_assert_test _ // if you use assertions to test 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 is null; else // otherwise report exam_assert (_ file __, _ line _) # else // if no asserted test is used # define exam_assert (condition) null # endif/* end of assert */

7-6: Use assertion to check whether the program should not occur during normal operation but may occur during commissioning

7-7: you cannot use assertions to check whether the final product will encounter and must handle errors.

Note: assertions are used to handle situations where errors should not occur. For situations that may occur and must be handled, write error prevention programs instead of assertions. If a module needs to check the rationality of the message after receiving messages from other modules or links, this process is a normal error check and cannot be implemented using assertions.

7-8: add clear comments to complicated assertions

Note: complex assertions can be annotated to clarify the meaning of assertions and reduce unnecessary misuse.

7-9: Use assertions to confirm the function parameters

Example: If a function parameter has a pointer, you can check it before using the pointer, as shown below.

Int exam_fun (unsigned char * Str) {exam_assert (STR! = NULL); // use assertion to check the condition "if the pointer is not null"... // other program code}

7-10: Use assertions to ensure that unspecified features or features are not used

Example: Assume that a communication module is designed to provide "no connection" and "connection" services. However, the current version only implements the "No connection" service, and in the official release of this version, users (upper-layer modules) should not generate "connection" service requests, in the test, you can use assertions to check whether the user uses the "Connect" service. As follows.

# Define exam_connectionless 0 // connectionless business # define exam_connection 1 // connection business int msg_process (exam_message * MSG) {unsigned char service;/* message service class */exam_assert (MSG! = NULL); service = get_msg_service_class (MSG); exam_assert (service! = Exam_connection); // assume that the connection service is not used... // other program code}

7-11: Use assertions to check the assumptions of the Program Development Environment (OS/Compiler/hardware)

Note: The software and hardware environment and configuration requirements required for running the program cannot be checked by assertions, but must be handled by a specific piece of code. With assertions, you can only check the assumptions in the program development environment and whether the software and hardware of a configured version have certain functions. If a network card is configured in the system running environment, it should be checked by the program's formal Code; and whether the network card has a certain function, it can be checked by assertion.

Enable assertion checks on the functions and features provided by the compiler because the final software product (that is, the running code or machine code) has no direct relationship with the compiler, that is, during the software running process (note that it is not in the compilation process), no need should be raised for the compiler functions.

Example: Use assertions to check whether the memory space occupied by the int type data of the compiler is 2, as shown below.

EXAM_ASSERT( sizeof(int ) == 2 );

7-12: In formal software products, the assertions and other commissioning code should be removed (that is, the relevant commissioning switch should be turned off)

Description: accelerates software operation.

7-13: In the software system, setting and canceling relevant testing methods cannot affect the functions implemented by the software.

Note: software with code testing and software with code testing turned off should be consistent in functional behavior.

7-14: Use the commissioning switch to switch between the debug version and the official version of the software, instead of having different source files of the official version and the debug version at the same time, to reduce the maintenance difficulty

7-15: the debug and release versions of the software should be maintained in a unified manner and should not be separated from each other. In addition, always ensure the functional consistency of the two versions.

Others

7-1: before writing code, you should design the methods and means for program debugging and testing in advance, and design various debugging switches and corresponding testing codes, such as printing functions.

Note: program debugging and testing are an important stage in the software life cycle, how to conduct comprehensive and high-rate testing on the software and identify errors in the software as much as possible becomes a critical issue. Therefore, before writing the source code, in addition to a comprehensive test plan, a series of code testing methods should be designed to facilitate unit testing, integration testing and system joint debugging.

7-2: The commissioning switch should be divided into different levels and types

Note: The setting and classification of the commissioning switch should be taken into account in the following aspects: commissioning of a module or a part of the system code; commissioning of a module or a function of the system; for some other purpose, such as performance and capacity tests. This facilitates the commissioning of software functions, unit testing of modules, and joint commissioning of systems.

7-3: Write an error prevention program, and then use assertions to announce an error after handling the error.

Example: If a module receives a message on the communication link, the validity of the message should be checked. If the message category is not specified in the communication protocol, an error should be processed, the following is an example of an asserted report.

# Ifdef _ exam_assert_test _ // if you use assertion test/* notice: thisfunction does not call 'abort 'to exit Program */void assert_report (char * file_name, unsigned int line_no) {printf ("\ n [exam] Error Report: % s, line % u \ n", file_name, line_no) ;}# define assert_report (condition) if (condition) // if the condition is true, no action is null; else // otherwise, assert_report (_ file __, _ line _) is reported __) # else // test without assertions # define assert_report (condition) null # endif/* end ofassert */INT msg_handle (unsigned char msg_name, unsigned char * MSG) {Switch (msg_name) {Case msg_one :... // The message msg_one processes return msg_handle_success ;... // other valid message processing default :... // assert_report (false) for message error handling; // The "valid" message is invalid and return msg_handle_error;} is reported ;}}