/* 头文件开始 */ #ifndef __EXAMPLE_EXT #define __EXAMPLE_EXT
#define _EXAMPLE_DEBUG_ // 模块测试总开关。打开开关的含义是模块可以 // 进行单元测试或其它功能、目的等的测试。 #ifdef _EXAMPLE_DEBUG_
#define _EXAMPLE_UNIT_TEST_ // 单元测试宏开关 #define _EXAMPLE_ASSERT_TEST_ // 断言测试开关 ... // 其它测试开关 #endif
#ifndef _EXAMPLE_UNIT_TEST_ // 若没有定义单元测试 #include // 各模块共用的头文件 #include // 系统接口头文件
#ifndef _SYSTEM_DEBUG_VERSION_ // 如果是发行版本(即非DEBUG版) #undef _EXAMPLE_UNIT_TEST_ #undef _EXAMPLE_ASSERT_TEST_
... // 将所有与测试有关的开关都关掉，即编译时不含任何测试代码 #endif
#include // 与另一模块的接口头文件 ... // 其它接口头文件
#else // 若定义了单元测试，则应构造单元测试所需的环境、结构等。 typdef unsigned char _UC ; typdef unsigned long _UL ; #define TRUE 1
... // 所有为单元测试准备的环境，如宏、枚举、结构、联合等。 #endif
#endif /* EXAMPLE.EXT结束 */ /* 头文件结束 */
<规则4> 在同一项目组或产品组内，调测打印出的信息串的格式要有统一的形式。信息串中至少要有所在模块名(或源文件名)及行号。 统一的调测信息格式便于集成测试。
<规则5> 使用断言来发现软件问题，提高代码可测性。
断言是对某种假设条件进行检查(可理解为若条件成立则无动作，否则应报告)，它可以快速发现并定位软件问题，同时对系统错误进行自动报警。断言可以对在 系统中隐藏很深，用其它手段极难发现的问题进行定位，从而缩短软件问题定位时间，提高系统的可测性。实际应用时，可根据具体情况灵活地设计断言。
示例:下面是C语言中的一个断言，用宏来设计的。(其中NULL为0L) #ifdef _EXAM_ASSERT_TEST_ // 若使用断言测试 void ExamAssert( char * szFileName, unsigned int nLineNo ) {
printf( \ szFileName, nLineNo ) ; abort( ) ; }
#define EXAM_ASSERT( condition ) \\ if ( condition ) \\ // 若条件成立，则无动作 NULL ; \\ else \\ // 否则报告
ExamAssert( __FILE__, __LINE__ )
#else // 若不使用断言测试
#define EXAM_ASSERT( condition ) NULL #endif /* ASSERT结束 */
<规则6> 用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况。 <规则7> 不能用断言代替错误处理来检查最终产品肯定会出现且必须处理的错误情况。
如某模块收到其它模块或链路上的消息后，要对消息的合理性进行检查，此过程为正常的错误检查，不能用断言来代替。 <规则8> 用断言确认函数的参数。
示例:假设某函数参数中有一个指针，那么使用指针前可对它检查，如下。 int ExamFunc( unsigned char *str ) {
EXAM_ASSERT( str != NULL ) ; // 用断言检查摷偕柚刚氩晃 諗这个条件 ... // 其它程序代码 }
<规则9> 用断言保证没有定义的特性或功能不被使用。
示例:假设某通信模块在设计时，准备提供无连接和连接这两种业务。但当前的版本中仅实现了无连接业务，且在此版本的正式发行版中，用户(上层模块)不应产生连接业务的请求，那么在测试时可用断言检查用户是否使用连接业务。如下。 #define EXAM_CONNECTIONLESS 0 // 无连接业务 #define EXAM_CONNECTION 1 // 连接业务 int MsgProcess( _EXAM_MESSAGE *msg ) {
unsigned char cService ; /* 消息服务类 */ EXAM_ASSERT( msg != NULL ) ; cService = GetMsgServiceClass( msg ) ;
EXAM_ASSERT( service != EXAM_CONNECTION ) ; // 假设不使用连接业务 ... // 其它程序代码 }
<规则10> 用断言对程序开发环境(OS/Compiler/Hardware)的假设进行检查。
程序运行时所需的软硬件环境及配置要求，不能用断言来检查，而必须由一段专门代码处理。用断言仅可对程序开发环境中的假设及所配置的某版本软硬件是否具 有某种功能的假设进行检查。如某网卡是否在系统运行环境中配置了，应由程序中正式代码来检查;而此网卡是否具有某设想的功能，则可由断言来检查。
对编译器提供的功能及特性假设可用断言检查，原因是软件最终产品(即运行代码或机器码)与编译器已没有任何直接关系，即软件运行过程中(注意不是编译过程中)不会也不应该对编译器的功能提出任何需求。
示例:用断言检查编译器的int型数据占用的内存空间是否为2，如下。 EXAM_ASSERT( sizeof( int ) == 2 ) ;
<规则11> 正式软件产品中应把断言及其它调测代码去掉(即把有关的调测开关关掉)。 <规则12> 用调测开关来切换软件的DEBUG版和正式版，而不要同时存在正式版本和DEBUG版本的不同源文件，以减少维护的难度。
<规则13> 在软件系统中设置与取消有关测试手段，不能对软件实现的功能等产生影响。
即有测试代码的软件和关掉测试代码的软件，在功能行为上应一致。 <规则14> 发现错误应该立即修改，并且若有必要记录下来。
<规则15> 开发人员应坚持对代码进行彻底的测试(单元测试)，而不依靠他人或测试组来发现问题。
<规则16> 清理、整理或优化后的代码要经过审查及测试。 <规则17> 代码版本升级要经过严格测试。 1.7 代码编译
<规则1> 打开编译器的所有告警开关对程序进行编译。 防止隐藏可能是错误的告警。
<规则2> 在同一项目组或产品组中，要统一编译开关选项。
<规则3> 某些语句经编译后产生告警，但如果你认为它是正确的，那么应通过某种手段去掉告警信息。
在Borland C/C++中，可用“#pragma warn 示例:
#pragma warn -rvl // 关闭告警 int DoExample( void ) {
// 程序，但无return语句。 }
#pragma warn +rvl // 打开告警