【软件构造】课程提纲（5）

第七章

1. 健壮性和正确性

（1）健壮性：处理各类情况的能力

（2）正确性：正确实现规格说明的能力

（3）测量：平均故障间隔时间（MTBF）、残余缺陷率（软件发布后留下的bug）

2. Throwable：有两个子类，即error和exception

（1）error：程序无法处理的错误，通常是JVM的问题，不需要catch

　　·处理策略：预先阻止、错误中恢复、优雅地退出

　　·处理方式

　　　　- 返回中立值

　　　　- 替换下一个有效数据

　　　　- 返回与前一次相同的答案

　　　　- 代替最接近的法律价值

　　　　- 将警告消息记录到文件

　　　　- 返回错误代码：设置状态值 -> 返回状态值 -> 利用异常机制

　　　　- 调用一个错误处理例程/对象

　　　　- 显示错误信息

　　　　- 在本地处理错误

　　　　- 关掉程序

（2）exception：程序自身可以处理，代码可以通过异常机制将错误或异常事件传递给调用它的代码，Java无法以正常方式完成其任务时允许每种方法都有一个替代退出路径

3. Runtime 异常、其他异常

（1）Runtime异常：程序员自己的错误，如空指针、数组越界、类型转换等

（2）其他异常：通常为IOE异常，即找不到文件路径等

4. Checked 异常、Unchecked 异常

（1）Checked 异常：每个调用者都应知道并处理的错误

　　·处理机制

　　　　- 抛出：声明是throws，抛出时throw

　　　　- 捕获（try/catch）：try出现异常，忽略后面代码直接进入catch；无异常不进入catch；若catch中没有匹配的异常处理，程序退出；若子类重写了父类方法，父类方法没有抛出异常，子类应自己处理全部异常而不再传播；子类从父类继承的方法不能增加或更改异常

　　　　- 处理：不能代替简单的测试，尽量苛刻、不过分细化、将正常处理与异常处理分开、利用好层次结构、早抛出晚捕获、避免不必要的检查

　　　　- 清理现场、释放资源（finally）：finally中语句不论有无异常都执行

（2）Unchecked 异常：JVM抛出，如空指针、数组越界、数据格式、不合法的参数、不合法的状态、找不到类等

5. 自定义异常类：继承自Exception，在构造函数中可通过super(key)修改默认值

6. 断言

（1）作用：允许程序在运行时检查自己，测试有关程序逻辑的假设，如前置条件、后置条件、不变量等，可将黑盒测试转换为白盒测试

（2）应用场合

　　·输入/输出参数落在预期范围内

　　·程序运行/结束时文件流的打开和关闭

　　·程序开始（结束）时文件处于开始（结束）

　　·文件流以只读、只写或读写方式打开

　　·输入变量的值不被方法改变

　　·判断指针不是空值

　　·判断数据结构是否是指定长度

　　·判断真值表是否初始化

　　·当一个方法开始执行时（或完成时）容器是空的（或满的）

　　·高度优化的复杂方法的结果与较慢但清晰编写的例程的结果相匹配

（3）注意

　　·编译时加入-ea选项运行断言，-da关闭断言

　　·条件语句或开关没有涵盖所有可能的情况，最好使用断言来阻止非法事件

　　·可以在预计正常情况下程序不会到达的地方放置断言：assert false

　　·在开发和调试阶段设置断言，在软件发布时禁止断言

　　·断言有代价，需慎用，一般用于验证正确性，处理绝不应该发生的情况

　　·不能作为公共方法的检查，也不能有边界效应

7. 调试（Debugging）

（1）进攻式编程：在开发阶段让异常显现出来，而在产品运行时让其自我恢复

　　·产品版与开发版：开发版只要开发顺利可以放肆一些，产品版必须克制

　　·做好计划，避免调试代码和程序代码纠缠不清

　　·使用存根例程

　　·开发中希望错误尽可能明显，发布后希望错误尽可能不明显

　　·确定程序的哪些部分能够承受未检测出错误而造成的后果，哪些不能，如果后果微不足道，可通过make或版本控制删除检测代码（不是物理删除）

　　·如果您的程序包含检测潜在致命错误的调试代码，可将代码保留在其中，以使程序稳妥地崩溃

　　·考虑在产品代码中留下调试代码，但改变他们的行为，以便适合生产版本

（2）Bug的状态

　　·被发现提出（New）-> 被审核批准（Open）-> 被分配给开发者（Assign）-> 被解决/修正/测试（Resolved/Fixed/Test）-> 重新测试（Retest）-> 通过测试（Verified）-> 修复后仍存在问题（Reopen）-> 成功修复（close）

　　·若bug优先级低，推迟到下一个版本，有时可能需要无限推迟

　　·如果开发人员认为系统的特定行为（测试人员报告为错误的行为）必须相同，并且错误无效，那么该错误将被拒绝并标记为“等待拒绝”

　　·如果bug无法通过QA的报告中给出的步骤重现，则开发人员可以将该错误标记为“CNR”， QA需要采取措施来检查是否重现了bug，并且可以向开发人员分配详细的重现步骤

（3）基本过程：重现问题 -> 找到原因（95%） -> 进行修正 -> 反思

（4）方法

　　·重现问题 

　　　　- 找到一个产生失败的小的可重复测试用例（保持复现bug的前提下降低输入规模）

　　　　- 消除因版本、环境、配置等不同引起的差异（通过构建软件实现），确定bug出现的环境（通过程序模拟硬件平台的细节，实现不同的操作系统环境）

　　　　- 利用逆向设计推断导致错误的输入

　　　　- 若无法重现，则无法观察以证明分析和修补的正确性

　　·诊断错误（插桩、分治、VCS、寻找特例、学习他人）

　　　　- 从假设开始，构造实验，证明它是对的或者错的

　　　　- 从不符合理论的观察结果开始，修正理论

　　　　- 查看导致错误的测试输入，以及错误的结果，失败的断言以及由此导致的堆栈跟踪

　　　　- 提出一个与所有数据一致的假设，说明错误发生的位置或错误发生的位置，设计实验测试假设

　　　　- 收集实验数据，减少错误可能出现的范围，做出新的假设

　　　　- 设计不同的实验：检查内部状态、修改运行方式、改变本身逻辑

　　　　- 每次只做一个修改、做好记录、不忽略细节、运行不同的测试用例、设置断点、用可实现相同功能并且被证实无问题的组件替代当前组件 

　　·修复bug

　　　　- 确保从干净的源代码树开始

　　　　- 运行现有的测试，并证明它们通过

　　　　- 添加一个或多个新测试，或修复现有测试，以演示错误

　　　　- 修复错误、发现可改进之处

　　　　- 证明你的修复工作正常且没有引入回归（以前通过的测试现在失败）

　　　　- 如果引入回归，通过回顾以前的版本来找出确切的变化

（4）调试工具

　　·语法和逻辑检查

　　·源代码比较器

　　·内存堆转储

　　·打印调试/记录

　　·堆栈跟踪

　　·编译器警告消息

　　·调试器

　　·执行分析器

　　·测试框架

8. 黑盒测试用例的设计

（1）黑盒测试：在没有任何内部实现知识的情况下检查功能，而无需查看源代码

（2）测试用例：围绕规范和要求构建，一般来自软件的外部描述，包括规范，要求和设计参数，主要是功能性的

（3）等价类划分：将程序的输入域划分为可导出测试用例的数据类

　　·若一组对象自反、对称、传递，则为等价类

　　·可产生相似结果的输入集合中的一个可代替整个集合

　　·同理，对输出也可以划分等价类

　　·两个极端：每个分区只有一个测试用例，覆盖所有分区

（4）边界值分析：错误通常隐藏在边界中，如一位偏移、边界值需单独处理等

9. 以注释的形式撰写测试策略

（1）在测试类的顶端写策略

　　 

（2）在每个测试方法前说明测试用例是如何选择的

　　 

10. JUnit 测试用例写法

（1）@Before：每个测试方法前执行一次

（2）@After：每个测试方法后执行一次

（3）@Test：表明测试方法，内含Assert语句

　　·@Test(expected=*.class)：对错误的测试，expected的属性值是一个异常

　　·@Test(timeout=xxx)：测试方法在制定的时间之内没有运行完则失败

（4）@ignore：忽略测试方法

11. 测试覆盖度

（1）通常无法完全覆盖，因此只需尽量提高

（2）代码覆盖率高的程序在测试期间执行了更多的源代码，与低代码覆盖率的程序相比，包含未检测到的软件错误的可能性较低

（3）基本覆盖标准：函数、语句、决策或分支、条件或谓词、路径

（4）覆盖强度：路径 > 分支 > 语句