模板
教程
环境
性能
功能
管理
怎样才能做好单元测试(2)
单元测试计划
单元测试方案
单元测试用例
单元测试规程
单元测试日报
单元测试问题单
单元测试报告
单元测试输入及输出数据
单元测试工具
单元测试代码及设计文档
为了保证单元测试工作产品的准确性，需要对测试代码和脚本进行走读或检视，对测试文档进行评审。这些工作产品应该纳入到配置管理，对于其修改要走配置变更流程，并及时发布其配置状态，这样可以保持单元测试工作产品的一致性和可回溯性。
必须制订覆盖率指标和质量目标来指导和验收单元测试
单元测试必须制订一定的覆盖率指标和质量目标，来指导单元测试设计和执行，同时作为单元测试验收的标准。设计用例时，可针对要达到的覆盖率指标来设计用例，而在测试执行时，可以依据覆盖率分析工具分析测试是否达到了覆盖率指标，如果没达到，需要分析哪些部分没有覆盖到，从而补充用例来达到覆盖率指标。而单元测试质量目标的制订，需要符合软件企业的实际过程能力，这依赖于软件企业以前单元测试过程度量数据的积累，不能凭空制造出来。有了以前度量数据的积累，完全可以了解当前组织的单元测试能力，例如单元测试每千行代码发现的缺陷数是多少。如果单元测试统计结果没有落到这个质量目标范围内，说明单元测试过程中某些方面存在一些问题，需要对过程进行后找出问题原因进行改进。
这些指标确定下来后，一定要严格推行。会有一些测试人员找出各种理由证明覆盖率指标达不到等等，这需要 QA 根据实际情况分析指标是否合理。实际证明有一个相对简单的标准也比没有标准要好得多，我们的实践发现，通过推行硬性指标，单元测试发现的问题数目比没有标准前至少增加了 2 倍。
下面是印度 SASKEN 公司的质量目标：
| 阶段 | 组织目标 | 目标上限 | 目标下限 |
| HLD （概要设计） | 50 Major Defects / 100 pages | 55 Major Defects/100 pages | 45 Major Defects /100 pages |
| LLD（详细设计） | 40 Major Defects / 100 pages | 44 Major Defects/100 pages | 36 Major Defects / 100 pages |
|
Unit Test Plan （单元测试计划） |
25 Major Defects / 100 pages | 27.5 Major Defects /100 pages | 22.5 Major Defects / 100 pages |
| Code Review （代码走读） | 20 Major Defects / KLOC | 22 Major Defects / KLOC Www.Syue.Com | 18 Major Defects / KLOC |
| Defects during Unit test（单元测试） | 15 Major Defects / KLOC | 16.5 Major Defects / KLOC | 13.5 Major Defects / KLOC |
| Defects during Integration test（集成测试） | 6 Major Defects / KLOC | 6.6 Major Defects / KLOC | 5.4 Major Defects / KLOC |
加强详细设计文档评审
详细设计是单元测试的主要输入，详细设计文档的质量将直接影响到单元测试的质量，所以一定要加强详细设计文档的评审，特别是要写相关测试方案和进行测试用例设计的人员，一定要从写测试用例的角度看这个详设是否符合要求，否则后期进行单元测试设计时会发现无法依据详细设计进行单元测试设计。软件组织可以将详细设计评审的要点以查检表的形式固化下来，这样在详细设计评审的时候依据查检表一项项检查，既提高了评审效率，也能保证评审效果。评审流程需要确定如果不满足查检表 n% 以上的条件，被评审详细设计文档就不能通过，需要重新设计。
通常详细设计文档有两种形式，一种是流程图的形式，另一种是伪码的形式。用流程图表达的优点是直观，利于单元测试用例设计，缺点是描述性比较差，文档写作麻烦，不利于文档的变更和修改;伪码的方式可能正好相反，文档变更修改简单，可以方便地在任何地方增加文字说明，而且翻译成代码更加便捷，但不直观，不利于进行单元测试用例设计。
详细设计和单元测试设计一定要分离。如果单元测试由测试人员承担，这一点不会有什么问题;如果单元测试由开发人员承担，那么实际操作时可以让项目组内做相同或者相近任务的成员相互，根据对方的详设设计对方的单元测试。这样在单元测试开始之前的详细设计评审阶段就要考虑到后面的分工，安排相关的单元测试设计人员参与相关详细设计的评审。
如果代码没有对应的经过评审后的详细设计文档，建议不进行单元测试，而是用代码审查替代单元测试。
开发人员在编码的过程中，可能会发现详设中的问题，并对代码进行修改，这种修改应该回溯到详设，并对详设进行相应的修改，否则到单元测试执行的时候，会发现代码和详设根本对不上，无法执行下去。详设的修改要受控制，要走流程，它的变更也要经过评审。因为单元测试是详细设计的下游活动，如果详细设计随意更改，单元测试文档很难和其保持一致，这样单元测试也就失去了依据和意义。只有详设也纳入配置管理，才能保证单元测试和详设的一致性。
单元测试者技能的提高
1 .加强对单元测试人员的技能
单元测试的质量很大程度上决定于进行单元测试的人的技术水平。如果测试者不具备单元测试的知识，那么应该对测试者进行相关的培训。一个没有做过单元测试人，不经过培训初次是很难做好单元测试的。单元测试在详设阶段结束时开始，但是单元测试相关培训应该尽早准备和计划，培训可以分两个阶段，每个阶段的内容类似。第一阶段是写单元测试方案前，培训对象为测试方案的写作者和详设的写作者，这样可以在设计时多考虑可测试性，培训的内容为单元测试基本概念、单元测试分析方法、单元测试用例的写作、单元测试标准的明确;第二阶段为单元测试执行前，对象为测试执行者，培训内容为具体单元测试的执行，包括驱动函数、桩函数的构造、覆盖率测试工具的使用( TrueCoverage 、 Logiscope 等)、利用自动化单元测试框架构造单元测试自动化( TCL 、 CppUnit 、 JUnit 等)。培训过程中最好结合实例穿插其中，会比较生动，而且增强理解。
