(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语句是否可以优化，是否可以用1条SQL语句代替程序中的多条SQL语句的功能，循环是否必要，循环中的语句是否可以抽出到循环之外等。
(12)、检查您的程序是否清晰简洁容易理解：注意：冗长的程序并不一定不是清晰的。
(13)、检查方法内部注释是否完整：是否清晰简洁；是否正确的反映了代码的功能，错误的注释比没有注释更糟；是否做了多余的注释；对于简单的一看就懂的代码没有必要注释。
(14)、 检查注释文档是否完整：对包、类、属性、方法功能、参数、返回值的注释是否正确且容易理解；是否会落了或多了某个参数的注释，参数类型是否正确，参数的限 定值是否正确。特别是对于形式参数与返回值中关于神秘数值的注释，如：类型参数 应该指出 1.代表什么，2.代表什么，3.代表什么等。对于返回结果集(Result Set)的注释，应该注释结果集中包含那些字段及字段类型、字段顺序等。
3. 动 态执行跟踪：动态执行测试通常分为黑盒测试与白盒测试。对于单元测试来说主要应该采用白盒测试法对每个模块的内部作跟踪检查测试。对于单元白盒测试，应该 对程序模块进行如下检查：(1)、对模块内所有独立的执行路径至少测试一次；(2)、对所有的逻辑判定，取“真”与“假”的两种情况都至少执行一次； (3)、在循环的边界和运行界限内执行循环体；(4)、测试内部数据的有效性等等。
4. 单元测试的目的：在于发现各模块内部可能存在的各种错误，主要是基于白盒测试。
单元测试的目的主要有3方面：验证单元代码和详细设计文档的一致性；跟踪详细设计文档中设计的实现，发现详细设计文档中存在的错误；发现在编码过程中引入的错误。
5. 单元的常见错误：(1)、单元接口；(2)、局部数据结构；(3)、独立路径；(4)、出错处理；(5)、边界条件。
6. 单元测试策略：有三种，独立的单元测试策略，自顶向下的单元测试策略和自底向上的单元测试策略。
独立的测试策略：不考虑每个模块与其他模块之间的关系，为每个模块设计桩模块和驱动模块。每个模块进行独立的单元测试。
自顶向下的测试策略：先对最顶层的单元进行测试，把顶层所调用的单元做成桩模块。其次对第二层进行测试，使用上面已测试的单元做驱动模块。如此类推直到测试完所有模块。