4.2黑盒测试
4.2.1 等价划分
-
特性：
1.严格控制测试用例的增加——体现尽可能多的不同输入情况 —— 设计最小测试用例集
2.覆盖大部分其他可能的样例——尽量划分输入范围——设计输入条件集合 -
步骤
1.确定等价类——有效等价类（有效输入）与无效等价类（注意无效以及未预料到的输入情况）
取值范围、取值的个数
输入值的集合（每个输入值确定一个有效一个无效）
某些“必须是”的规定
2.生成测试用例
编号
尽可能多覆盖未被涵盖的有效等价类（直到都）
覆盖一个且仅一个剩余的无效等价类（直到都）——某些特定输入错误检查可能会屏蔽或取代其他错误检查
- 不足
忽略掉了某些特定类型的高效测试用例
4.2.2 边界值分析
边界条件：输入和输出等价类中恰好处于边界、超过边界、在边界以下的状态
- 与上一个不同
1.从等价类任意挑选一个元素——>选择一个或多个元素使等价类每个边界都经过测试
2.仅关注输入——>还要考虑输出等价类来设计测试用例
边界值考虑处于等价划分边界或边界附近的状态
- 设计指南
输入值范围——边界与刚刚越界的情况
输入值数量——最小、最大，最小减一，最大加一
输出值的范围、数量
有序序列——第一个和最后一个元素
4.2.3 因果图
- 解决痛点
未对输入条件的组合进行分析（如：程序输入乘积超过某个阈值时会失效，比如程序耗尽内存） - 特性
用系统方法选出高效测试用例集
可以指出规格说明不完整性和不明确之处
将规格说明转化未一个布尔逻辑网络 - 步骤
1.将规格说明分解为可执行的片段
2.确定因果关系并赋予唯一编号
3.分析规格说明语义内容，转化为布尔图（因果图）
4.加注解，说明由于语法或者环境限制无法连接的因与果
5.因果图转化为有限项的判定表，每列表示一个测试用例（最难）
6.表中每列转为测试用例 - 不足
通常不能生成全部应该被确定的有效测试用例
没有充分考虑边界条件
4.3 错误猜测
列举出可能犯的错误与错误易发情况清单，并依次编写测试用例
4.4 测试策略
以上每种方法都可以提供具体有用的测试用例，但不嫩单独提供一个完整的测试用例集
- 规格说明中有输入条件组合的情况——首先考虑因果分析法
- 任何情况都要使用——边界值分析法（注意针对对象），这也可作为补充测试条件
- 对输入和输出划分有效无效等价类
- 使用错误猜测技术增加更多测试用例
- 针对以上检查程序逻辑结构，使用白盒测试
5. 模块(单元）测试
对程序的单个子程序、子程序或过程进行测试的过程
动机
1.管理组合的测试元素的手段
2.减轻了调试的难度
3.为同时测试多个模块提供了可能（将并行工程引入软件测试）
目的
比较模块功能与定义模块的功能规格说明或者接口规格说明，揭出其中存在矛盾
5.1 测试用例设计
所需信息
模块规格说明、模块源代码
设计过程
使用一种或多种白盒测试方法分析模块的逻辑结构，用黑盒测试方法对照规格说明补充测试样例
5.2 增量测试
驱动模块
用来将测试用例驱动或传输到被测模块中
桩模块
模拟被调用模块功能，并且返回此次调用所希望的特定值
非增量测试/"崩溃”测试
先独立测试每个模块（需要一个驱动模块与一个或多个桩模块)，再将这些组装成完整的程序
增量测试
首先将下一个要测试的的模块组装到前面已经测试过的模块集合中去，再进行测试，对每个模块只需要设立一个驱动模块或者桩模块
优点
1.非增量测试工作量更大（设立模块更多）
2.增量测试能更早发现模块中与不匹配接口、不正确假设相关的编程错误，非增量知道最后模块才能相互看到
3.增量测试的台哦是更加容易（很可能与最近添加的模块有关）
4.增量测试将测试进行的更彻底，非增量的模块测试仅影响当前模块本身
不足
1.非增量测试占用机器时间更少
2.非增量测试更有利于并行操作
5.3 自顶向下测试与自底向上测试
5.3.1 自顶向下的测试
原则
要成为合乎条件的下一个模块，至少一个该模块的从属模块（调用它的模块）实现经过的测试
如何提交测试用例
测试数据通过一个或多个桩模块提交给模块
模块序列考虑指南
1.关键部分应该尽早添加进去（复杂模块、采用新算法的模块或被怀疑容易发生错误的模块）
2.I/O模块应尽早添加进来
缺点
1.在进行到下一个模块前未能穷举测试该模块（测试数据嵌入桩模块困难、程序高层次为低层次提供资源）
2.中间模块对测试用例的影响（输入输出之间的距离太远）
3.与程序设计阶段重叠
5.3.2 自底向上的测试
原则
要成为合乎条件的下一模块，该模块所有从属模块（它调用的模块）都已经事先经过了测试
5.3.3 比较
5.4 执行测试
1.输出与预期不匹配——模块存在错误或者测试用例不正确——测试前应对测试用例集进行测试
2.使用自动化测试工具
3.重温心理学与经济学原则
4.避免随意丢弃测试用例，应当按某种格式记录下来，以便将来可以重新使用它们
6 更高级别的测试
当程序无法实现最终用户要求的合理功能时，就发生了一个软件错误
（即使完成了非常完美的模块测试，仍不能保证已经找出了程序中的所有错误）
6.1 功能测试
通常是一项黑盒操作
目的——证明程序未能符合其外部规格说明
6.2 系统测试
目的——将系统或程序与其初始目标进行比较，证明其不一致
6.2.1 能力测试
判断目标文档提及的每一项能力是否都确定实现、通常人工检查就足够
6.2.2 容量测试
为了证明程序不能处理目标文档中的规定的数据容量
6.2.3 强度测试
是程序承受高负载或强度的检验，即在很短的时间间隔内达到的数据或操作的数量峰值
譬如: 基于Web的应用程序（能否处理一定容量的并发用户）、移动设备上的应用程序（压力测试）
6.2.4 可用性测试（用户体验测试）（详细）
发动最终用户在真实环境下对应用程序进行测试
基本要素
测试流程
1.测试用户的选择（如：长廊测试法，即随机选取一批用户）
2.需要多少用户进行测试
3.数据采集方法：”发声思考“、”眼球追踪“等
4.可用性问卷调查：
——方法：是/否问题、真/假问题、某种程度的同意/反对
——技巧：一份问卷中多次询问同一个问题（但从相反的角度来问）
5.何时收工还是多多益善
注意：可用性测试结果必须变成开发人员可读懂的修改意见，改进后再交由原来的测试者，确认是否实现了改进意图
6.2.5 安全性测试
设计测试用例来突破程序安全检查的过程
6.2.6 性能测试
程序在特定负载和配置环境下的响应时间与吞吐率
6.2.7 存储测试
证明软件的存储目标没有得到满足
6.2.8 配置测试
至少使用每一种类型的设备，以最大和最小配置来测试程序
6.2.9 兼容性/转换测试
6.2.10 安装测试
6.2.11 可靠性测试
6.2.12 可恢复性测试
6.2.13 服务、可维护性测试
6.2.14 文档测试
6.2.15 过程测试
6.2.16 系统测试的执行
谁来执行测试——不能由程序员来进行、不能又负责该程序开发的机构来执行
要求
1.执行系统测试的人的思考问题方式必须与最终用户相同
2.至少应当由很少受开发机构的独立人群来执行
6.3 验收测试
客户与最终客户的职责
6.4 安装测试
发现在安装过程中出现的错误，应由生产软件系统的机构来设计，作为软件的一部分来发布
6.5 测试的计划与控制
目标、结束准则、进度、责任、测试用例库与标准、工具、计算机时间、硬件配置、继承、跟踪步骤、调试步骤、回归测试（在对程序做了功能改进或修改后进行，目的是判断程序的改动是否引起了程序其他方面的退步）
6.6 测试结束准则
- 第一类： 根据特定的测试用例设计技术
模块测试结束准则
1.满足多重条件覆盖准则
2.对模块接口规格说明进行边界值分析，产生的所有测试用例最终都是不成功的
功能测试结束准则
测试用例来源于a.因果图分析 b.边界值分析 c.错误猜测 ，并且最终都不成功
- 第二类：以确切的数量描述结束条件
- 第三类：记录每单位时间的错误数量，检查统计曲线的形状
（ 二三类更适用于功能测试与系统测试）
7 调试
测试——证明程序没有实现预期的功能
调试——从成功的测试哟管理开始，明确错误的准确性质与位置，然后修改错误
7.1 暴力法调试
1.利用内存信息输出来调试——最缺乏效率
2.根据一般地”在程序中插入打印语句“建议来调试——主要是碰运气
3.使用自动化的调试工具调试——即可设置断电——同上一条差不多
都忽略了思考的过程，建议仅作为最后的备用方法
7.2 归纳法调试
7.3 演绎法调试
7.4 回溯法调试
适用于小型程序，在产生不正确结果的地方开始逆向执行程序
7.5 测试法调试
常与归纳或者演绎一同使用
7.6 调试原则
7.6.1 定位错误的原则
略
7.6.2 修改错误的技术
略
7.7 错误分析
出现在什么地方，谁犯的，哪些做得不正确，下次如何避免，为什么没有早点发现，如何更早地发现
8 敏捷开发模式下的测试
8.1 敏捷开发的特征
重点——客户满意度
模式共同点——依赖客户的参与、测试驱动以及紧凑的迭代开发周期
