（1）    编程

　　开发人员根据“编程计划”编写软件的代码，并随时记录编程技术、问题与对策、心得体会等等，产生《编程文档》（类似于编程日记）。

　　开发人员在编写完成每个模块时，必须对自己的代码进行必要的审查和测试。

　　（2）    代码审查

　　由品质保证部对代码按照相关代码规范进行审查，并填写《代码审查报告》。

　　（3）    单元测试

　　开发人员首先撰写单元测试用例。

　　开发人员根据“单元测试计划”和相应的“测试用例”来测试同伴的代码，产生“测试报告”。

　　2.3.2    技术解决过程对单元测试活动论述的不足之处

　　从编码与测试流程图及其任务描述中可以看出，技术解决过程对单元测试的时机、内容、结果等方面都做了规定。但是应该认识到，单元测试不是一个单薄的活动，单元测试是代码级的白盒测试，测试方法与软件代码和软件运行环境密切相关，对软件实施单元测试前需要对软件代码和运行环境进行分析，确定相应的单元测试方法。

　　技术解决过程没有明确规定进行单元测试的详细方法和过程，也没有制定严格的单元测试审查标准。开发人员在实际开发过程中，由于缺乏实施单元测试的方法指导，很难对工作代码进行有效的单元测试，也看不到单元测试对开发活动所能产生的积极效用，这些原因导致单元测试活动经常被忽略，使我们不得不依赖紧密地依赖测试人员的功能测试工作，以确定我们的代码能够正确运行。但是，功能测试（包括模块测试、集成测试、回归测试、系统测试等）的效果严重依赖于测试人员的工作，不在我们能够掌控的范畴之内。

　　如果我们写的代码没有经过严格和有效的单元测试，那么它们的质量或多或少将会存在隐患，我们将带有质量隐患的代码发布出去，这些隐患可能被测试人员发现，也可能直到生产环境中才暴露出来，可想而知，这时我们的工作将会极为被动。

　　如果我们实行严格有效的单元测试，那么可以在很大程度上确保代码的质量，并为后续的改进、重构、维护等工作提供切实的保障。

　　3    单元测试的必要性

　　3.1    不做单元测试的后果

　　项目进度的黑洞

　　完成99%（后的1%永远无法完成）

　　2个月完成开发，半年过去了还是不稳定

　　骨干员工都投入在维护以前项目上

　　没有力量进行新的研发

　　越来越难维护，导致产品开发难以创新

　　研发成本的大量消耗

　　骨干员工才能进行维护

　　由于模块间耦合，只有骨干才了解整体情况

　　骨干每天都在Debug（没有力量进行新的研发）

　　问题的解决周期(8小时)

　　定位问题4~6小时

　　解决问题1~2小时

　　浪费了（4/5=80%左右的维护工作量）

　　软件质量故障延迟解决的代价

　　开发人员提交了带有隐患的代码

　　测试人员可能轻易发现故障、可能很难发现故障

　　发布到生产环境中的故障被用户使用时发现

　　我们的软件运行不稳定

　　难以为继

　　为了修正问题的改动缺少整体考虑

　　可维护性不断下降

　　不同维护人员思路不同（时间长了容易出现冲突）

　　长期的结果是导致代码必须重写