软件测试理论课程第五章(单元测试).pptVIP

软件测试 单元测试 章节目标 单元测试回顾 人工静态测试 动态执行跟踪 JUnit 单元测试实例 单元测试 单元测试 人工静态测试 动态执行跟踪 JUnit 单元测试实例 单元测试 单元测试是针对软件设计的最小单位 － 程序模块 单元测试是程序员的一项基本职责 花费小，回报多 合格代码的特点 正确性 清晰性 规范性 一致性 高效性 单元测试步骤  人工静态检查 动态执行跟踪 单元测试 单元测试 人工静态测试 动态执行跟踪 JUnit 单元测试实例 人工检查阶段的活动 检查算法的逻辑正确性 模块接口的正确性检查 输入参数有没有作正确性检查 调用其他方法接口的正确性 人工检查阶段的活动 出错处理 保证表达式、SQL语句的正确性 检查常量或全局变量使用的正确性 表示符定义的规范一致性 人工检查阶段的活动 程序风格的一致性、规范性 检查程序中使用到的神秘数字是否采用了表示符定义 检查代码是否可以优化、算法效率是否最高 检查您的程序是否清晰简洁容易理解 人工检查阶段的活动 检查方法内部注释是否完整；是否清晰简洁 检查注释文档是否完整 单元测试 单元测试 人工静态测试 动态执行跟踪 JUnit 单元测试实例 动态执行跟踪 动态执行测试通常分为 黑盒测试 白盒测试 对于单元测试来说主要应该采用白盒测试法对每个模块的内部作跟踪检查测试 单元白盒测试的任务 对模块内所有独立的执行路径至少测试一次 对所有的逻辑判定，取“真”与“假”的两种情况都至少执行一次 在循环的边界和运行界限内执行循环体 测试内部数据的有效性等等 单元白盒测试的步骤 设计测试用例 设计测试类模块 跟踪调试 测试用例设计基本原则  一个好的测试用例在于能够发现至今没有发现的错误 测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成  在测试用例设计时，应当包含合理的输入条件和不合理的输入条件 测试用例设计 － 逻辑覆盖法 语句覆盖 判定覆盖 条件覆盖 判定-条件覆盖 条件组合覆盖 路径覆盖 6 种覆盖方法关系 每一种覆盖方法都有其优缺点 测试用例设计 － 基本路径法 程序的控制流图 程序环境复杂性 导出测试用例 准备测试用例，确保基本路径集中的每一条路径的执行 图形矩阵 测试类设计  驱动模块（driver） 桩模块（stub） 测试类设计原则 每一个用例编写一个测试类 好处： 能够同时测试包中所有的方法或模块，也可以方便的测试跟踪指定的模块或方法 能够联合使用所有测试用例对同一段代码执行测试，发现问题 便以回归测试 复用 测试代码与产品代码分离 跟踪调试 借助代码跟踪调试工具深入的检查代码的逻辑错误 被测试模块被修改后，应该对每个测试用例进行至少一次的跟踪 排错过程往往是一个艰苦的过程 几种排错时应该采用的方法策略 断点设置 函数调用语句 判定转移/循环语句 SQL语句 复杂算法段 可疑变量查看 SQL 语句执行检查 注意群集现象 单元测试 单元测试 人工静态测试 动态执行跟踪 JUnit 单元测试实例 单元测试实例 － JUnit 简介 JUnit 是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架，供 Java 开发人员编写单元测试之用。 JUnit 本质上是一套框架，即开发者制定了一套条条框框，遵循这此条条框框要求编写测试代码，如继承某个类，实现某个接口，就可以用JUnit进行自动测试了。 JUnit 的下载安装 去 JUnit 主页下载最新版本 用 winzip 或 unzip 将下载后的安装包解压缩到某一目录名为 $JUNITHOME 将 junit.jar 和 $JUNITHOME/junit 加入到CLASSPATH 中，加入后者只因为测试例程在那个目录下。 注意不要将 junit.jar 放在 jdk 的 extension 目录下 运行 JUnit 样例程序 执行 java junit.swingui.TestRunner junit.samples.AllTests JUnit 架构 JUnit 本身是围绕着两个设计模式来设计的 命令模式 （ TestCase 类） 集成模式 （ TestSuite 类） 一个例子 － Money 类 测试 Add（）方法 public?class?MoneyTest?extends?TestCase?{? //TestCase 的子类 ????public?void?testAdd()?{ //把测试代码放在 testAdd 中 ????Mone