作者：黄鑫（glacier②unnoo.com）
对于多人开发团队来说，程序设计和代码编写人员的编程基础、经验往往参差不齐。所以在一个软件项目进入设计和编码阶段之前，除了制订明确的编码规范，还有必要对代码质量的其他部分提出明确要求，同时这些要求应作为程序设计和代码编写的审核内容列入检查表。
尽量避免可预见的错误或缺陷是提出这些要求的目的之一，另一个目的则是尽快提高开发新手的基本素质。
一、变量/常量/函数命名、注释格式、缩进格式要求：
凡从事软件开发的公司大都制订了自己的编码规范，即使没有，也很容易通过google轻松找到较完整的通用要求。略。
二、代码组织结构要求：
1、对于标准C程序，要求将功能相近的函数集中保存，如文件处理函数组保存在file_operate.c文件中，注册表处理函数组保存在reg_operate.c文件中，且在设计阶段注意保持各文件的相对独立性，避免发生这样的结果：测试单个模块时交叉引用其他文件，最终几乎包含了整个project。简言之，就是要求设计者对于标准C代码也尽量采用面向对象的思想进行设计。
示例：略。
2、对于面向对象程序，只要按照OO的思想进行设计，本身就是将相关的数据结构及方法进行封装，即只要符合OOD要求即可。
示例：略。
三、公用函数设计要求：
多处使用的功能代码必须以函数形式设计和编写，除特殊情况外，不允许两个以上不同的程序段完成相同功能。该项要求的目的是：
1）便于白盒测试中针对公用代码进行完全测试；
2）避免函数内部代码改动时进行多处重复的检查和修改。
示例：略。
四、对于参与白盒测试的函数设计要求：
对于参与白盒测试的所有函数，参数和返回值必须是测试环境下容易构造的数据结构。在
WINDOWS驱动程序或ISAPI等特殊程序中，存在许多应用层难以构造的数据结构，如"DEVICE_OBJECT"、
"UNICODE_STRING"、"HTTP_FILTER_CONTEXT"等，如果需要在应用层对包含这些数据结构的函数进行测试，将大大增加测试代码开发的工作量，且测试效果并不一定理想。对于这类函数，要求将参数转换为普通数据结构并通过独立的函数进行处理，再将结果按需要进行转换并返回。对于代码量过大的单个函数，除特殊情况（如算法复杂且连贯的压缩、加密函数等）外，均应进一步拆分为功能相对单一且独立的多个函数，便于白盒测试中进行条件、路径覆盖以及检测各分支的中间结果。
示例：略。
五、对于面向对象程序的设计要求：
1、预留测试及调试接口：设计对象及编码时应注意为后续的测试或调试工作做好铺垫，预留一些私有变量及成员函数记录该对象的各种中间状态和尽可能详细的错误信息。
示例：略。
2、保证对象的封装性：不允许为了满足白盒测试中对中间结果检测的要求，而将本应为private或protect类型的变量、函数定义为public
类型。对于测试中需要访问的私有成员，可以专门编写public类型的测试函数，将私有变量结果返回，并通过预定义对这类测试函数进行限制，使其只在测试代码中参与编译。
示例：略。
作者：黄鑫（glacier②unnoo.com）
对于大中型软件来说，资源泄漏问题往往很难全面检测和定位。常见的资源泄漏分为两类：一是打开的文件或资源句柄没有及时关闭，二是动态申请的内存没有及时释放。这两种资源泄漏问题在情况严重时都将导致系统性能严重下降甚至死机。这里总结一下发现和解决这类问题的方法：
一、借助外部工具
使用“Numega Bounds Checker”或“Rational
Purify”等工具，设置源代码路径后加载Debug版本的二进制程序运行，会直接报告出可能存在资源泄漏和非法内存访问的代码位置。这两款检测软件都兼容目前常用的开发工具，如VB、VC、BCB、DELPHI等，操作也很方便，但我的实际使用结果却不太理想。误报现象不算严重，不至于影响自己的分析判断，但在漏报情况下就还得靠其他手段来检测了。
二、使用编译器自带的检测功能
1、BCB编译器中可以通过菜单“Project->Options->
CodeGuard”切换到CodeGuard页，选中“CodeGuard
Validation”中需要检测的项目即可。程序运行结束后BCB会对句柄、内存等资源泄漏情况作出详细报告。
2、VC中检测内存泄漏不像
BCB那么方便，需要通过重载malloc()、free()等函数并增加cl_mem_leak_diagnostics等预定义实现。虽然实现起来比较麻烦，但如果能做得完善一些并形成自己的检测库，在后续项目的使用中就方便多了。细节可以参考http://www.tunesmithy.co.uk/memleakcheck/index.htm中的描述和完整示例。
三、其他
1、编写代码时养成良好的编程习惯，在调用malloc()或new的同时写好free()或delete，然后在中间插入代码。
2、尽量不要在函数内的分支中调用return，以确保在统一的出口前释放临时申请的资源。
3、SQA部门将针对资源泄漏问题的检查列入代码检查表和白盒测试中，尽量不将该问题扩散到单元测试以外。
4、除了上面提到的专用工具和编译器以外，还可以通过一些“土办法”对资源泄漏问题进行检测。比如win2k中的任务管理器提供了对单个进程“内存使用”、“高峰内存使用”、“句柄数”等状态的实时监测功能，测试人员通过一段时间的监视，可以很容易发现较明显的资源泄漏问题。
作者：黄鑫（glacier②unnoo.com）
软件质量管理的目标是通过日常工作在开发过程之中内建质量而非修补质量，所以在提出了针对设计文档和代码质量的明确要求后，就应该在文档、代码的定期审核过程中检查提出的要求是否被正确实施，而不是在发现错误无法定位或产品难于维护时才开始纠正。设计文档和代码的审核通常由SQA部门或项目负责人完成，但对于较简单的模块代码，也可以采用开发人员之间交叉评审的放式，以减轻项目负责人的负担。
下面列出的检查内容只是我根据自己可预见的问题整理所得，还需要在实际开发工作中进一步完善。
设计文档检查内容
文档主结构——文档结构是否符合国标或内部要求，文档内容是否完整。
设计合理性——接口部分设计以及参数、返回值是否合理。
容错设计——整体结构或模块结构中是否有足够的容错设计，不会因为某项非致命错误而导致不可恢复的数据损失。
错误处理——是否使用统一的错误处理函数和统一的错误代码，不会在错误发生时无法定位错误模块和获得错误代码。
文档可读性——文档内容描述是否足够清晰，复杂描述部分是否配有相应的图表。
上下层一致性——文档描述与对应的上层设计或原型代码是否一致。
术语一致性——各文档中使用术语是否与《术语字典》中术语对应。
文字缺陷——描述中是否存在歧义或错别字。
示例：略
程序代码检查内容
代码编写风格——是否遵守《代码编写规范》。
代码可读性——代码结构是否清晰、易于理解，变量或函数命名是否存在歧义。
注释风格——主要函数的输入、输出项及返回值是否有详细说明，函数内主要分支是否有相应说明。
与设计文档一致性——代码实现与设计文档是否一致。
代码健壮性——对各个函数或系统API调用失败后是否有足够的错误处理，不会引起非法操作；对传入参数及指针变量的检查是否充分，对临时申请的系统资源是否及时回收。
示例：略
Powered by Haiwit
