通常详细设计文档有两种形式，一种是流程图的形式，另一种是伪码的形式。用流程图表达的优点是直观，利于单元测试用例设计，缺点是描述性比较差，文档写作麻烦，不利于文档的变更和修改;伪码的方式可能正好相反，文档变更修改简单，可以方便地在任何地方增加文字说明，而且翻译成代码更加便捷，但不直观，不利于进行单元测试用例设计。
详细设计和单元测试设计一定要分离。如果单元测试由测试人员承担，这一点不会有什么问题;如果单元测试由开发人员承担，那么实际操作时可以让项目组内做相同或者相近任务的成员相互交换，根据对方的详设设计对方的单元测试。这样在单元测试开始之前的详细设计评审阶段就要考虑到后面的分工，安排相关的单元测试设计人员参与相关详细设计的评审。
如果代码没有对应的经过评审后的详细设计文档，建议不进行单元测试，而是用代码审查替代单元测试。
开发人员在编码的过程中，可能会发现详设中的问题，并对代码进行修改，这种修改应该回溯到详设，并对详设进行相应的修改，否则到单元测试执行的时候，会发现代码和详设根本对不上，无法执行下去。详设的修改要受控制，要走变更控制流程，它的变更也要经过评审。因为单元测试是详细设计的下游活动，如果详细设计随意更改，单元测试文档很难和其保持一致，这样单元测试也就失去了依据和意义。只有详设也纳入配置管理，才能保证单元测试和详设的一致性。
• 单元测试者技能的提高
1 .加强对单元测试人员的技能培训
单元测试的质量很大程度上决定于进行单元测试的人的技术水平。如果测试者不具备单元测试的知识，那么应该对测试者进行相关的培训。一个没有做过单元测试人，不经过培训初次是很难做好单元测试的。单元测试在详设阶段结束时开始，但是单元测试相关培训应该尽早准备和计划，培训可以分两个阶段，每个阶段的内容类似。第一阶段是写单元测试方案前，培训对象为测试方案的写作者和详设的写作者，这样可以在设计时多考虑可测试性，培训的内容为单元测试基本概念、单元测试分析方法、单元测试用例的写作、单元测试标准的明确;第二阶段为单元测试执行前，对象为测试执行者，培训内容为具体单元测试的执行，包括驱动函数、桩函数的构造、覆盖率测试工具的使用( TrueCoverage 、 Logiscope 等)、利用自动化单元测试框架构造单元测试自动化( TCL 、 CppUnit 、 JUnit 等)。培训过程中最好结合实例穿插其中，会比较生动，而且增强理解。
通过以上的系统培训，可以统一单元测试方法、明确单元测试的标准、掌握单元测试基本技能，为后期单元测试的顺利开展扫平道路。
2 .必须引入工具进行辅助
单元测试非常需要工具的帮助，特别是覆盖率工具不能缺少，否则用例执行后无法得到测试质量如语句覆盖、路径覆盖等情况，也就无法对被测对象进行进一步的分析。应用较广的分析覆盖率的工具有 Logiscope 、 TrueCoverage 、 PureCoverage 等，它们的功能有强有弱，可以根据实际情况采用。
为了提高单元测试的效率，特别是提高进行回归测试时的效率，需要在单元测试中引入自动化。目前常用的方法是采用 TCL 语言编写扩展指令，构造自己的单元测试自动化。也可以直接采用开源的自动化测试框架如 CppUnit 、 JUnit 等。
此外，在单元测试之前，还需要利用 PC_Lint 对被测代码进行检查，排除代码语法错误，确保进行单元测试的代码已经具备了基本质量，保证单元测试能够顺利进行，提高单元测试执行效率。
3 .单元测试者加强对被测软件的全面了解
单元测试的目的除了要发现编码中引入的错误和发现代码与详细设计不一致的地方之外，还有一个目的是为了保证详细设计的质量。因为测试分析和测试用例设计需要依据详细设计来进行，这个过程实际上是对详细设计的重新检视，在这个过程中会发现以前评审中没有发现的问题。
无论是在单元测试的设计活动中还是在单元测试的执行过程中，都需要测试者了解软件的需求和概要，加强对被测软件的全面了解。否则对被测对象了解不深，只能就被测单元的流程而测流程，而对于该流程是否正确就无法保证了。
测试者要注重与开发的交流，这样能对被测单元有更深的了解;同时因为进度的原因，包括详设在内的文档往往来不及更新，所以最新最正确的思想往往存在于开发人员的脑袋里，及时与他们交流才会获得最及时的信息，减少将来更新用例的工作量。
结尾
单元测试是软件开发过程中非常重要的质量保证手段，加强单元测试对提高软件质量具有非常重要的意义。而做好单元测试不是只要掌握单元测试方法就可以了的，这需要从组织、流程和技术三个方面来保证。
文章来源于领测软件测试网 https://www.ltesting.net/
