单元测试理论 & 测试用例设计总结

dq_0413

单元测试的内容（测试者熬根据详细设计说明书和源程序清单，了解模块的I/O条件和模块的逻辑结构。）

1.从以下几个方面进行测试：

   1）模块接口：测试模块的数据流。如果数据不能正确地输入和输出，就谈不上其他测试。因此，对于模块借口需要如下的测试项目：
     ·调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配
     ·是否修改了制作输入用的形式参数
     ·输出给标准函数的参数在个数、属性、顺序上是否匹配
     ·全局变量的定义在各个模块中是否一致
     ·限制是否通过形式参数来传递
   2）局部数据结构测试：模块的举办数据结构式最常见的错误来源，应设计测试用例以检查以下各种错误：
     ·检查不正确或不一致的数据类型说明
     ·使用尚未复制或尚未初始化的变量
     ·错误的初始值或错误的默认值
     ·变量名拼写或书写错误
     ·不一致的数据类型
   3）路径测试：对基本执行路径和循环进行测试会发现大量错误。根据白盒测试盒黑盒测试用例设计方法设计测试用例。设计测试用例查找由于错误的计算、不正确的比骄傲或不正常的控制流而导致的错误。
     ·常见的不正确的计算有：
       |-运算的优先次序不正确或误解了运算的优先次序
       |-运算的方式错误（预算的对象彼此都在类型上不相容）
       |-算法错误
       |-初始化不正确
       |-运算精度不够
       |-表达式的符号表示不正确等
     ·常见的比较和控制流错误哦
       |-不同数据类型的比较
       |-不正确的逻辑运算符或优先次序
       |-因浮点云山精度问题为找茬的两值比较不等
       |-关系表达式中不正确的变量和比较符
       |-“差1错”，即不正确地多循环或少循环一次
       |-错误的或不可能的循环终止条件
       |-当遇到发散的迭代时不能终止循环
       |-不适当地修改了循环变量等
  4)错误处理测试：比较完善的模块设计要求能遇见出错的条件，并设置适当的出错处理对策，以便在程序出错时，能对出错程序重新做安排，保证其逻辑上的正确性。这种出错处理也是模块功能的一部分。表明出错处理模块有错误或缺陷的情况有：
     ·出错的描述难以理解
     ·出错的描述不足以对错误定位和确定出错的原因
     ·显示错误与实际错误不符
     ·在对错误进行处理之前，错误条件已经引起了系统的干预
     ·如果出错情况不予考虑，那么检查回复正常后模块可否正常工作
   5）边界测试：边界上出现错误上常见的。设计测试用例检查：
     ·在n次循环的第0次、1次、n次是否有错误
     ·运算或判断中取最大最小值时是否有错误
     ·数据流、控制流中刚好等于、大于、小于确定的比较值时是否出现错误

2.测试的环境构成（两种辅助模块）
     ·驱动模块（Driver）:所测模块的主程序。它接收测试数据，把这些数据传递给所测试模块，最后在输出测试结果。当被测试模块能完成一定功能时，也可以不要驱动模块
     ·桩模块：用来代替所测模块调用的子模块。被测试模块、驱动模块和桩模块共同构成了一个测试环境。

3.用例设计
   1）测试用例的组成(单元测试中测试用例基本上由测试脚本组成)
    ·用例运行前置条件
     ·被测模块/单元所需环境(全局变量赋值或初始化实体)
    ·启动测试驱动
     ·设置桩
     ·调用被测模块
     ·设置预期输出条件判断
     ·恢复环境(包括清除桩)
2）测试用例设计原则
     ·一个好的测试用例在于能给发现至今没有发现的错误
     ·测试用例应由测试输入数据与之对应的预期输出结果这两部分组成
     ·在测试用例设计时，应当包含合理的输入条件和不合理的输入条件
     ·为系统运行起来而设计测试用例
     ·为正向/逆向而设计测试用例
     ·为满足特殊需求而设计测试用例
     ·而代码覆盖而设计测试用例
  3）用例设计方法
     ·规范(规格)导出法
     ·等价类划分法
     ·边界值分析法
     ·状态转移测试法
     ·分支测试法
     ·条件测试法
     ·数据定义-使用测试法（数据流测试法）
     ·内部边界值测试法
     ·错误猜测法
4.特定的测试用例设计
  1）声明测试：检测模块中的所有变量是否被声明。
  2）路径测试：要求模块汇总所有可能的路径走被执行一遍，属逻辑覆盖测试
     基本测试路径集要保证：
     ·每个确定语句的每一个方向要测试到
     ·每条语句最少执行一次
  3）循环测试：重点检查循环的条件-判断不烦以及边界条件。 它是一种特殊的路径测试，因为循环比其他语句都复杂一些。循环中错误的发生机会比其他代码构成部分多。
      ·循环不执行
      ·执行一次循环
      ·执行两次循环
      ·反映执行典型的循环的执行次数
      ·如果有最大循环次数，最大循环次数-1
      ·最大循环次数
      ·大于最大循环次数
      对于增量和减量不是1的for语句，要特别注意，因此程序员习惯于增量1
4）循环嵌套：使逻辑的次数呈几何级数增长。
      ·把外循环设置为最小值，并运行内循环所有可能情况
      ·把内循环设置为最小值，并运行外循环所有可能的情况
      ·把所有循环变量都设置为最小值运行
      ·把所有循环变量都设置为最大值运行
      ·把外循环设置为最大值，并运行内循环的所有可能情况
      ·把内循环设置为最大值，并运行外循环的所有可能情况
  5）边界值测试：(指专门设计用例测试当条件语句中引用的值处在边界或边界附近时系统的放映)把程序内部边界测试。检查确定代码在任何边界情况下都不会出差错。重点检查小于、等于、大于边界条件的情况。被测 语句最好是"if-then...else-end if"
  6）接口测试：检查模块中数据流(输入、输出)是否正确。检查输入的参数和声明的变量的个数，数据类型和输入顺序是否一致。检查全局变量是否被正确的定义和使用等。
  7）确认测试：是否接受有效的输入数据(操作)，拒绝无效的数据(操作)
  8）事务测试：输入-->输出，错误处理

5.测试评估

1）测试完备性评估，主要检查测试过程中是否已经执行了所有测试用例，对新增的用例是否已即使更新测试方案等。
2）代码覆盖率评估，主要是根据代码覆盖率工作提供的语句覆盖情况报告，检查是否达到方案中的要求，公司要求语句覆盖100%.但很多情况下，第一轮测试用例执行完后事很难达到的，这是在评估过程中要对覆盖率进行分析，主要从以下方面来考虑：
      ·不可能的路径或条件
      ·不可达的或冗余的代码
      ·不充分的测试用例
3）从覆盖的角度，应该测试覆盖：
      ·功能覆盖
      ·输入域覆盖
      ·输出域覆盖
      ·函数交互覆盖
      ·代码执行覆盖

[ 本帖最后由 dq_0413 于 2009-6-17 16:37 编辑 ]

dq_0413

今天第一次接触单元测试，一头雾水！
感觉这些概念都很难运用到实际中。

DeViLIvy

总结的不错啊！
看了你的资料，原来我们还是老乡。有空多交流