前面已经了解了有关单元测试的一些常识性知识，下面简单介绍一下单元测试的过程。
工作性质的不同，决定了工作的侧重点也会不同，因此程序开发人员在单元测试的过程中关注
得更多的是程序代码本身和已经实现的功能。因此，站在他们的角度看，单元测试的过程就是
有关被测产品的功能培训。
2）准备开发及测试工具和环境，如有必要在各编码组内对临时的编译环境和调试方法进 行约定。
3）对详细设计说明书需要做进一步确认工作，保证接口、工作流程的一致性。如果是多 人参与开发，还需根据实际情况对参与人员进行设计讲解工作。
4）根据单元划分情况编写单元测试用例，并审查是否达到测试需求。
（2）编制阶段。
1）程序员依据详细设计，进行程序单元的编制工作（包括建立相关的构造环境），并调 试和检查。
2）在更正测试问题时，修改源码和测试用例，提交新的源码文件。
（3）代码审查阶段。将编制的源代码文件进行静态代码审查，填写代码审查表（作为单 元测试报告附录形式提交）。
在代码审查阶段，必须执行的活动有以下几个项目：
1）检查算法的逻辑正确性。确定所编写代码的算法、数据结构定义（如：队列、堆栈等）
是否实现了模块或方法所要求的功能。
2）模块接口的正确性检查。确定形式参数个数、数据类型、顺序是否正确；确定返回值 类型及返回值的正确性。
3）输入参数有没有做正确性检查。如果没有做正确性检查，要确定该参数是否的确无需 做参数正确性检查，否则要添加参数的正确性检查。经验表明，缺少参数正确性检查的代码是 造成软件系统不稳定的主要原因之一。
4）调用其他方法接口的正确性。检查实参类型正确与否，传入的参数值正确与否，个数 正确与否，特别是具有多态的方法。检查返回值正确与否，有没有误解返回值所表示的意思。
最好对每个被调用的方法的返回值用显示代码做正确性检查，如果被调用方法出现异常或错误 程序应该给予反馈，并添加适当的出错处理代码。
5）出错处理。模块代码要求能预见出错的条件，并设置适当的出错处理，以便一旦在 程序出错时，能对出错程序重做安排，保证其逻辑的正确性，这种出错处理应当是模块功能 的一部分。若出现下列情况之一，则表明模块的错误处理功能包含有错误或缺陷：出错的描 述难以理解；出错的描述不足以对错误定位，不足以确定出错的原因；显示的错误信息与实 际的错误原因不符；对错误条件的处理不正确；在对错误进行处理之前，错误条件已经引起 系统的干预等。
6）保证表达式、SQL 语句的正确性。检查所编写的 SQL 语句的语法、逻辑的正确性。
对表达式应该保证不含二义性，对于容易产生歧义的表达式或运算符优先级（如：《、=、》、
&&、||、++、--等）可以采用扩号“（）”运算符避免二义性，这样一方面能够保证代码的正 确可靠，同时也能够提高代码的可读性。
7）检查常量或全局变量使用的正确性。确定所使用的常量或全局变量的取值和数值、数 据类型；保证常量每次引用同它的取值、数值和类型的一致性。
8）表示符定义的规范一致性。保证变量命名能够见名知意，并且简洁但不宜过长或过短、
规范、容易记忆、最好能够拼读，并尽量保证用相同的表示符代表相同功能，不要将不同的功 能用相同的表示符表示，更不要用相同的表示符代表不同的功能意义。
9）程序风格的一致性、规范性。代码必须能保证符合企业规范，保证所有成员的代码风 格一致、规范、工整。例如对数组做循环，不要一会儿采用下标变量从下到上的方式（如：
for(i=0;i++;i<10)），一会儿又采用从上到下的方式（如：for(i=10;i--;i>0)）；应该尽量采用统一 的方式，或者统一从下到上，或者统一从上到下。建议采用 for 循环和 while 循环，不要采用 do{}while 循环等。
10）检查程序中使用到的神秘数字是否采用了表示符定义。神秘的数字包括各种常数、
数组的大小、字符位置、变换因子以及程序中出现的其他以文字形式写出的数值。在程序源代 码里，如果一个具有原本形式的数对其本身的重要性或作用没提供任何指示性信息，那么它们 也会导致程序难以理解和修改。对于这类神秘数字必须采用相应的标量来表示。如果该数字在 整个系统中都可能使用到，务必将它定义为全局常量；如果该神秘数字在一个类中使用，可将 其定义为类的属性（Attribute）；如果该神秘数字只在一个方法中出现，务必将其定义为局部 变量或常量。
11）检查代码是否可以优化，算法效率是否最高。如：SQL 语句是否可以优化，是否可 以用一条 SQL 语句代替程序中的多条 SQL 语句的功能，循环是否必要，循环中的语句是否可 以抽出到循环之外等。
12）检查程序是否清晰简洁容易理解。需要注意的是，冗长的程序并不一定不是清晰的。
13）检查方法内部注释是否完整，是否清晰简洁，是否正确地反映了代码的功能。错 误的注释比没有注释更糟。还要检查是否做了多余的注释，对于简单的一看就懂的代码没 有必要注释。
14）检查注释文档是否完整。对包、类、属性、方法功能、参数、返回值的注释是否正 确且容易理解；是否会落了或多了某个参数的注释，参数类型是否正确，参数的限定值是否正 确。特别是对于形式参数与返回值中关于神秘数值的注释，如：对于类型参数，应该指出①代 表什么；②代表什么；③代表什么等。对于返回结果集（Result Set）的注释，应该注释结果 集中包含哪些字段及字段类型、字段顺序等。
（4）单元测试阶段。
1）从配置库获取源码文件，设计测试用例，执行测试用例，并利用相关测试工具对单元 代码进行测试，将测试结论填写到单元测试报告和软件 BUG 清单中。
2）把软件 BUG 清单和测试用例执行结果提交测试负责人，并纳入质量管理。对源码文 件进行的测试，视程序存在缺陷的情况，可能要重复进行，直至问题解决。
3）单元测试的执行者，一般情况下可由程序的编码者担当，特殊情况可由独立于编码者 的测试人员进行。
（5）评审、提交阶段。
1）对源代码文件进行同级评审，给出评审结论（由审查人员填写产品批准表），并将其 提交到配置库中。
2）上述过程完成后，开发人员应提交源代码、代码清单、单元测试用例代码及单元测试 报告。测试人员提交该版本的软件 BUG 清单，代码审查人员提交产品批准表。
上面所列出的测试环节可供读者参考，在具体的单元测试过程中可能会因实际工作要求 的不同和具体单元测试目标的不同有所增加、补充或修改，当然也有一些公司内部会专门规定 相关的单元测试流程和单元测试规范。