2.3 技术解决过程
2.3.1 技术解决过程与单元测试有关的论述
过程总体概述(Process Overview)
编码与测试活动流程图(Activity Flow Diagram)
编码与测试活动的任务描述摘录
编码与单元测试一般要经历“编程—>代码审查—>单元测试—>模块测试”等步骤，并且通常需要反复迭代，“缺陷管理与改错”贯穿始终。
（1） 编程
* 开发人员根据“编程计划”编写软件的代码，并随时记录编程技术、问题与对策、心得体会等等，产生《编程文档》（类似于编程日记）。
* 开发人员在编写完成每个模块时，必须对自己的代码进行必要的审查和测试。
（2） 代码审查
* 由品质保证部对代码按照相关代码规范进行审查，并填写《代码审查报告》。
（3） 单元测试
* 开发人员首先撰写单元测试用例。
* 开发人员根据“单元测试计划”和相应的“测试用例”来测试同伴的代码，产生“测试报告”。
2.3.2 技术解决过程对单元测试活动论述的不足之处
从编码与测试流程图及其任务描述中可以看出，技术解决过程对单元测试的时机、内容、结果等方面都做了规定。但是应该认识到，单元测试不是一个单薄的活动，单元测试是代码级的白盒测试，测试方法与软件代码和软件运行环境密切相关，对软件实施单元测试前需要对软件代码和运行环境进行分析，确定相应的单元测试方法。
技术解决过程没有明确规定进行单元测试的详细方法和过程，也没有制定严格的单元测试审查标准。开发人员在实际开发过程中，由于缺乏实施单元测试的方法指导，很难对工作代码进行有效的单元测试，也就看不到单元测试对开发活动所能产生的积极效用，这些原因导致单元测试活动经常被忽略，使我们不得不依赖紧密地依赖测试人员的功能测试工作，以确定我们的代码能够正确运行。但是，功能测试（包括模块测试、集成测试、回归测试、系统测试等）的效果严重依赖于测试人员的工作，不在我们能够掌控的范畴之内。
如果我们写的代码没有经过严格和有效的单元测试，那么它们的质量或多或少将会存在隐患，我们将带有质量隐患的代码发布出去，这些隐患可能被测试人员发现，也可能直到生产环境中才暴露出来，可想而知，这时我们的工作将会极为被动。
如果我们实行严格有效的单元测试，那么可以在很大程度上确保代码的质量，并为后续的改进、重构、维护等工作提供切实的保障。
