《软件测试的艺术》总结

软件测试的艺术

文章目录

• 软件测试的艺术
• • 2.软件测试的心理学和经济学
  • • 软件测试的心理学
    • 软件测试的经济学
    • 软件测试的原则
  • 3.代码检查、走查与评审
  • 4.测试用例的设计
  • • 白盒测试
    • 黑盒测试
    • 错误猜测
  • 6.更高级别的测试
  • • 软件产品开发周期
    • 功能测试
    • 系统测试
    • 验收测试
    • 安装测试
    • 测试计划
  • 5.模块（单元）测试
  • • 测试用例设计
    • 将模块组装成工作程序的方式
    • 增量测试
    • 执行测试
  • 7.可用性（或用户体验）测试
  • • 可用性测试流程
  • 8.调试
  • • 调试的步骤
    • 调试方法
  • 9.敏捷开发模式下的测试
  • • 敏捷测试
    • 极限编程与测试
  • 10.互联网应用测试
  • • 互联网应用系统
  • 11.移动应用测试
  • • 面临的挑战

2.软件测试的心理学和经济学

软件测试的心理学

• 软件测试是为发现错误而执行程序的过程

软件测试的经济学

• 黑盒测试（数据驱动的测试）
  • 穷举输入测试
• 白盒测试（逻辑驱动的测试）
  • 穷举路径测试

软件测试的原则

• 测试用例中一个必需部分是对于预期输出或结果的定义
• 程序员应当避免测试自己编写的软件
• 编写软件的组织不应当测试自己编写的软件
• 应当彻底检查每个测试的执行结果
• 测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效的输入情况和未预料到的输入情况
• 检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”
• 应避免测试用例用后即弃，除非软件本身就是一个一次性的软件
• 计划测试工作时不应默许假定不会发生错误
• 程序某部分存在更多错误的可能性，与该部分已发生错误的数量成正比
• 软件测试是一项极富创造性、极具智力挑战性的工作

3.代码检查、走查与评审

代码检查

代码走查

桌面检查

同行评审

4.测试用例的设计

白盒测试

• 语句覆盖：程序中的每个语句至少能被执行一次
• 判定覆盖：程序中每个判定至少有一次为真值，有一次为假值，使得程序中的每个分支至少执行一次
• 条件覆盖：程序各判定中的每个条件获得各种可能的取值至少满足一次
• 判定/条件覆盖：程序中每个判定至少有一次为真值，有一次为假值，使得程序中的每个分支至少执行一次，且使得各判定中的每个条件获得各种可能的取值至少满足一次
• 多重条件覆盖：判定中的每种组合都至少被执行一次

黑盒测试

• 等价划分
  • 确定等价类
    • 有效等价类
    • 无效等价类
  • 生成测试用例
    • 测试用例尽可能多的覆盖有效等价类，单个测试用例覆盖无效等价类
• 边界值分析
• 因果图
  • 约束E表示其必须总为真，而二者最多只有一个为1
  • 约束I表示其为真时，三者中至少有一个为1
  • 约束0表示有且只有一个必须为1
  • 约束R表示如果一个为1，另一个也必须为1
  • 约束M表示如果一个为0，则另一个强制为0

错误猜测

6.更高级别的测试

软件产品开发周期

• 1.将软件最终用户的要求转换为一系列书面的需求
• 2.通过评估可行性和成本、消除相抵触的用户需求、建立优先级和平衡关系，将用户需求转换为具体的目标
• 3.将上述目标转换为一个准确的产品规格说明，将产品视为一个黑盒，仅考虑其接口以及与最终用户的交互。该规格说明被称为”外部规格说明“
• 4.如果该产品是一个系统，那么下一步骤就是系统设计。该步骤将系统分割为单独的程序、部件或子系统，并定义它们的接口
• 5.通过定义每个模块的功能、模块的层次结构以及模块间的接口，来设计程序或程序集合的结构
• 6.设计一份准确的规格说明，定义每个模块的接口与功能
• 7.经过一个或更多的子步骤，将模块接口规格说明转换为每个模块的源代码算法

功能测试

• 一个试图发现程序与其外部规格说明之间存在不一致的过程

系统测试

• 将系统或程序与其初始目标进行比较

验收测试

安装测试

测试计划

• 一个良好的测试计划应该包括目标、结束准则、进度、责任、测试用例库及标准、工具、计算机时间、硬件配置、集成、跟踪步骤、调试步骤、回归测试

5.模块（单元）测试

测试用例设计

• 模块的规格说明
• 模块的源代码

将模块组装成工作程序的方式

• 增量测试（集成）
  • 先将下一步要测试的模块组装到测试完成的模块集合中，然后再进行测试
• 非增量测试（“大爆炸”测试）
  • 先独立的测试每个模块，然后再将这些模块组装成完整的程序

增量测试

• 自顶向下测试
  • 要成为合乎条件的下一个模块，至少一个该模块的从属模块（调用它的模块）事先经过了测试
  • 关键模块（容易发生错误）、I/O模块尽可能早地添加进来
• 自底向上测试
  • 要成为合乎条件的下一个模块，该模块所有的从属模块（它调用的模块）事先经过了测试

执行测试

• 模块存在错误
• 预期结果不正确

7.可用性（或用户体验）测试

可用性测试流程

• 测试用户的选择
• 需要多少用户进行测试
• 数据采集方法
  • 发生思考
  • 眼球追踪
• 可用性调查问卷
• 判断何时收工

8.调试

调试的步骤

• 确定程序中可疑错误的准确性质和位置
• 修改错误

调试方法

• 蛮力法调试
• 归纳法调试
• 演绎法调试
• 回溯法调试
• 测试法调试

9.敏捷开发模式下的测试

敏捷测试

极限编程与测试

• 极限编程（XP）
• 极限测试（连续测试）
  • 极限单元测试
  • 验收测试

10.互联网应用测试

互联网应用系统

• 表示层
  • 提供了GUI
• 业务逻辑层
  • 模拟业务流程，比如用户身份验证、事务处理
• 数据访问层
  • 内容
    • 存储了供应用系统使用的或从最终用户收集来的数据
  • 测试
    • 响应时间
    • 数据完整性
      • 在数据存储的方式中发现问题
    • 容错性和可恢复性
      • 最大化MTBF(平均故障间隔时间)，最小化MTTR(平均恢复前时间)

11.移动应用测试

面临的挑战

• 移动设备多样性
• 运营网络基础设施
• 脚本编程
• 可用性测试

XMind - Trial Version