如何进行单元测试（上）
摘要：
单元测试是
软件测试的基础，本文详细的论述了单元测试的两个步骤人工静态检查法与动态执行跟踪法，所需执行的
工作项目及相关的策略和方法。通过对这两个步骤的描述作者将多年的单元测试经验及测试理论注入于全文。
关键词：单元测试、人工检查、
白盒测试、测试用例、跟踪调试
1 概述
单元测试是针对软件设计的最小单位――程序模块，进行正确性检验的测试工作。其目的在于发现每个程序模块内部可能存在的差错。
单元测试也是程序员的一项基本职责，程序员必须对自己所编写的代码保持认真负责的态度，这是也程序员的基本职业素质之一。同时单元测试能力也是程序员的一项基本能力，能力的高低直接影响到程序员的工作效率与软件的质量。
在编码的过程中作单元测试，其花费是最小的，而回报却特别优厚的。在编码的过程中考虑测试问题，得到的将是更优质的代码，因为在这时您对代码应该做些什么 了解得最清楚。如果不这样做，而是一直等到某个模块崩溃了，到那时您可能已经忘记了代码是怎样工作的。即使是在强大的工作压力下，您也还必须重新把它弄清 楚，这又要花费许多时间。进一步说，这样做出的更正往往不会那么彻底，可能更脆弱，因为您唤回的理解可能不那么完全。
通常合格的代码应该具备以下性质：正确性、清晰性、规范性、一致性、高效性等（根据优先级别排序）。
1. 正确性是指代码逻辑必须正确，能够实现预期的功能。
2. 清晰性是指代码必须简明、易懂，注释准确没有歧义。
3. 规范性是指代码必须符合企业或部门所定义的共同规范包括命名规则，代码风格等等。
4. 一致性是指代码必须在命名上（如：相同功能的变量尽量采用相同的标示符）、风格上都保持统一。
5. 高效性是指代码不但要满足以上性质，而且需要尽可能降低代码的执行时间。
2 单元测试步骤
在代码编写完成后的单元测试工作主要分为两个步骤人工静态检查和动态执行跟踪。
人工静态检查是测试的第一步，这个阶段工作主要是保证代码算法的逻辑正确性（尽量通过人工检查发现代码的逻辑错误）、清晰性、规范性、一致性、算法高效性。并尽可能的发现程序中没有发现的错误。
第二步是通过设计测试用例，执行待测程序来跟踪比较实际结果与预期结果来发现错误。经验表明，使用人工静态检查法能够有效的发现30%到70%的逻辑设计 和编码错误。但是代码中仍会有大量的隐性错误无法通过视觉检查发现，必须通过跟踪调试法细心分析才能够捕捉到。所以，动态跟踪调试方法也成了单元测试的重 点与难点。
3 人工检查
通常在人工检查阶段必须执行以下项目的活动：
第一、 检查算法的逻辑正确性；确定所编写的代码算法、数据结构定义（如：队列、堆栈等）是否实现了模块或方法所要求的功能。
第二、 模块接口的正确性检查；确定形式参数个数、数据类型、顺序是否正确；确定返回值类型及返回值的正确性。
第三、 输入参数有没有作正确性检查；如果没有作正确性检查，确定该参数是否的确无需做参数正确性检查，否则请添加上参数的正确性检查。经验表明，缺少参数正确性检查的代码是造成软件系统不稳定的主要原因之一。
第四、 调用
其他方法接口的正确性；检查实参类型正确与否、传入的参数值正确与否、个数正确与否，特别是具有多态的方法。返回值正确与否，有没有误解返回值所表示 的意思。最好对每个被调用的方法的返回值用显湿代码作正确性检查，如果被调用方法出现异常或错误程序应该给予反馈，并添加适当的出错处理代码。
第五、 出错处理；模块代码要求能预见出错的条件，并设置适当的出错处理，以便在一旦程序出错时，能对出错程序重做安排，保证其逻辑的正确性，这种出错处理应当是 模块功能的一部分。若出现下列情况之一，则表明模块的错误处理功能包含有错误或缺陷：出错的描述难以理解；出错的描述不足以对错误定位，不足以确定出错的 原因；显示的错误信息与实际的错误原因不符；对错误条件的处理不正确；在对错误进行处理之前，错误条件已经引起系统的干预等。
第六、 保证表达式、
SQL语句的正确性；检查所编写的SQL语句的语法、逻辑的正确性。对表达式应该保证不含二义性，对于容易产生歧义的表达式或运算符优先级 （如：《 、=、 》、 &&、||、++、 --等）可以采用扩号“（）”运算符避免二义性，这样一方面能够保证代码的正确可靠，同时也能够提高代码的可读性。
第七、 检查常量或全局变量使用的正确性；确定所使用的常量或全局变量的取值和数值、数据类型；保证常量每次引用同它的取值、数值和类型的一致性。
第八、 表示符定义的规范一致性；保证变量命名能够见名知意，并且简洁但不宜过长或过短、规范、容易记忆、最好能够拼读。并尽量保证用相同的表示符代表相同功能，不要将不同的功能用相同的表示符表示；更不要用相同的表示符代表不同的功能意义。
第九、 程序风格的一致性、规范性；代码必须能保证符合企业规范，保证所有成员的代码风格一致、规范、工整。例如对数组做循环，不要一会儿采用下标变量从下到上的 方式（如：for（I=0；I++；I<10）），一会儿又采用从上到下的方式（如：for（I=10；I--；I>0））；应该尽量采用统 一的方式，或则统一从下到上，或则统一从上到下。建议采用for循环和While循环，不要采用do{}while循环等。
第十、 检查程序中使用到的神秘数字是否采用了表示符定义。神秘的数字包括各种常数、数组的大小、字符位置、变换因子以及程序中出现的其他以文字形式写出的数值。 在程序源代码里，一个具有原本形式的数对其本身的重要性或作用没提供任何指示性信息，它们也导致程序难以理解和修改。对于这类神秘数字必须采用相应的标量 来表示；如果该数字在整个系统中都可能使用到务必将它定义为全局常量；如果该神秘数字在一个类中使用可将其定义为类的属性（Attribute），如果该 神秘数字只在一个方法中出现务必将其定义为局部变量或常量。
第十一、 检查代码是否可以优化、算法效率是否最高。如：SQL语句是否可以优化，是否可以用1条SQL语句代替程序中的多条SQL语句的功能，循环是否必要，循环中的语句是否可以抽出到循环之外等。
第十二、 检查您的程序是否清晰简洁容易理解。注意：冗长的程序并不一定不是清晰的。
第十三、 检查方法内部注释是否完整；是否清晰简洁；是否正确的反映了代码的功能，错误的注释比没有注释更糟；是否做了多余的注释；对于简单的一看就懂的代码没有必要注释。
第十四、 检查注释文档是否完整；对包、类、属性、方法功能、参数、返回值的注释是否正确且容易理解；是否会落了或多了某个参数的注释，参数类型是否正确，参数的限 定值是否正确。特别是对于形式参数与返回值中关于神秘数值的注释，如：类型参数 应该指出 1.代表什么，2.代表什么，3.代表什么等。对于返回结果集（Result Set）的注释，应该注释结果集中包含那些字段及字段类型、字段顺序等。
4 动态执行跟踪
动态执行测试通常分为黑盒测试与白盒测试。黑盒测试指已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。白盒测试指已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格的要求，所有内部成分是否已经经过检查。
对于单元测试来说主要应该采用白盒测试法对每个模块的内部作跟踪检查测试。对于单元白盒测试，应该对程序模块进行如下检查：
1. 对模块内所有独立的执行路径至少测试一次；
2. 对所有的逻辑判定，取“真”与“假”的两种情况都至少执行一次；
3. 在循环的边界和运行界限内执行循环体；
4. 测试内部数据的有效性等等。
单元白盒跟踪测试，通常需要做如下三项工作：
1. 设计测试用例；
2. 设计测试类模块；
3. 跟踪调试。
4.1 测试用例设计
通常动态执行跟踪调试是在编码阶段进行的。在对源程序作静态人工检查之后就可以开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。
4.1.1 测试用例的设计基本原则
设计测试用例基本的原则是：
1. 一个好的测试用例在于能够发现至今没有发现的错误；
2. 测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成；
3. 在测试用例设计时，应当包含合理的输入条件和不合理的输入条件。
4.1.2 白盒测试的测试用例设计
白盒测试测试用例一般采用逻辑覆盖法和基本路径法进行设计。
一、逻辑覆盖法
逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计技术，这一方法要求测试人员对程序的逻辑结构有清楚的了解。逻辑覆盖可分为：语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖与路径覆盖。
1. 语句覆盖就是设计若干个测试用例，运行所测程序，使得每一可执行语句至少执行一次。
2. 判定覆盖就是设计若干个测试用例，运行所测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。
3. 条件覆盖就是设计若干个测试用例，运行所测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。
4. 判定--条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断的所有可能判断结果也至少执行一次。
5. 条件组合覆盖就是设计足够的测试用例，运行所测程序，使得每个判断的所有可能的条件取值组合至少执行一次。
6. 路径测试就是设计足够的测试用例，覆盖程序中所有可能的路径。
每一种覆盖方法都有其优缺点，这6种覆盖方法关系，如图1：
通常在设计测试用例时应该根据代码模块的复杂度，选择覆盖方法。一般的代码的复杂度与测试用例设计的复杂度成正比。因此，设计人员必须做到模块或方法功能 的单一性、高内聚性，使得方法或函数代码尽可能的简单；这样将可大大提高测试用例设计的容易度，提高测试用例的覆盖程度。