第17章、测试报告和通过准则(理论课).ppt

/ 白盒测试与OO测试 第十七章、测试报告和通过准则 课程回顾 回顾了传统集成测试方法 非增式测试方法 增式测试方法 自顶向下增式测试 自底向上增式测试 面向对象的集成测试方法 结构测试 功能测试 持续集成和敏捷测试方法 本章学习目标 了解单元测试报告 了解单元测试覆盖率准则 了解单元测试设计原则 了解测试单元测试规范 掌握静态白盒测试中应该注意的几种问题类型 单元测试报告 单元测试报告(一) 单元测试报告的编写目的 单元测试报告(二) 被测试单元的描述 单元测试报告(二) 被测试单元的结构 单元测试报告(二) 被测试单元的结构 单元测试报告（三） 单元流程图/顺序图 单元测试报告（四） 单元测试过程（进度、测试环境、工具等） 单元测试报告（五） 测试结果 单元测试报告（五） 测试结果 单元测试报告（六） 单元测试产品 单元测试报告（七） 质量评估 单元测试报告（八） 单元测试总结 覆盖率 基于状态的覆盖率 基于约束的覆盖率 基于状态的覆盖率 以覆盖了状态转换图中多个状态为依据 测试用例是前置条件和后置条件生成的，需要检查 充分性：对象属性值域 基于约束的覆盖率 根据有多少对前置条件和后置条件被覆盖来表示充分性 例如：前置条件有pre1和pre2，后置条件有post1和post2，组合各种情况 单元测试规范 编写本规范的目的 规则适用的人员 单元的划分 参与单元测试的人员、职责等 单元测试采用的单元测试工具 单元测试规范 测试代码书写要求 单元测试中生成文件的命名以及存储的目录结构 单元测试的实施过程 单元测试的入口准则和出口准则 单元测试产品的验收和评审 单元测试规范例子 通过准则 单元测试设计原则（1/5） 过于简单的方法并不必一定测试 单元测试设计原则（2/5） 80/20原则 使对象尽可能简单、容易理解、容易测试、代码更安全 单元测试设计原则（3/5） 注意测试重用 单元测试设计原则（4/5） 尽量测试类的接口而非实现 即使接口不变，实现变化会造成测试的变化 原则：测试要依赖接口，不要依赖实现。 单元测试设计原则（5/5） 不能依赖固定的类方法调用顺序 静态白盒测试中应注意的问题 类中未使用代码错误 编码标准的错误 逻辑错误 条件语句 循环语句 switch语句…… 多线程错误 读取数据错误 集成错误 重用错误 类中未使用代码的错误 先看下面代码： 不符合编码标准的错误 一行中声明了多种类型变量 从一个抽象类库中的构造器调用的抽象方法 包含大量case语句的switch语句 有一个以上的main（）函数 直接弹出的Exception类库 catch语句中的Exception或者RuntimeException 直接弹出的Error没有在接口中定义的变量 长整数应该使用“L”代替小写字母“l” 命名惯例等不符合标准 逻辑错误 条件表达式 循环表达式 switch语句 条件表达式 先看下面代码： 多线程错误 访问和修改共享资源 读取数据错误 先看下面代码： 读取数据错误（续） 先看下面代码： 集成错误 先看下面代码： 重用错误 本章小结 静态白盒测试中容易发生的问题 单元测试的两种覆盖率准则 单元测试设计原则 单元测试规范 单元测试报告 我们在测试传统的软件时，例如当覆盖了所有的功能点，语句覆盖率达到了100％、分支覆盖率达到了95％时，测试就停止了。但是对于面向对象类的测试什么时候表明可以停止了呢？ 也需要一个通过准则，表明测试的充分性。我们也可以完全运用原来的覆盖率标准。但是根据面向对象的特点，又引入了两个新的覆盖率标准。 基于状态的覆盖率以测试系列覆盖了状态转换图中多少个状态转换为依据。假如测试系列没有覆盖一个或一个以上的状态转换，那么对类所进行的测试就不充分，就应该生成更多的测试用例来覆盖那些转换。如果测试用例是根据状态转换图生成的，那么测试用例就达到了这个标准。如果测试用例是根据前置条件和后置条件生成的，那么我们就按照测试用例覆盖了哪些状态转换来对测试用例进行分析，这对我们发现遗漏的测试用例是十分有用的。 即使测试用例对所有的状态都覆盖了一次，测试的充分性仍值得怀疑，因为状态通常包含了各种对象属性的值域。我们必需测试这些值域的所有值。对于典型值和边界值来说，也需要对它们进行测试。 我们还必需关注各个操作在涉及状态转换时彼此是如何交互的。假如有两个转换要进入一个状态，而另一个转换从那个状态出来。 if((a1a=10)(a10a20)) { //执行正常业务处理 } else { //执行异常业务处理 } public void Func1(){ lockDatabase(db); lockFile(file); releaseLock(db);