软件测试基本理论-IBM模式

软件测试基本理论（1）

IBM生产模式

1   参考书目

《IBM-从菜鸟到测试架构师-一个测试工程师的成长日记》

• 出版社：电子工业出版社
• 印次：2013年6月
• 作者：IBM主要工程师

2   重要提醒

Warning

IBM的业务性质是做大型企业的IT解决方案，仍然属于比较中规中矩的传统企业。所以对传统的软件企业有比较大的借鉴意义，但是对于互联网等新兴企业的从业人员，还是采取保留式的态度，取其精华即可。

3   测试产生的时代背景

1968年NATO会议提出了“软件危机”：

• 脆弱
• 不可靠
• 缺乏安全性
• 性能下降
• 出错
• 难以升级
• 73%的软件项目被延迟/超资/取消或失败

4   软件测试目的-IBM

• 确保软件质量
• 减少质量问题给企业及用户带来隐患

5   测试的现状

测试的理论及实践已经逐渐完善，但是测试的方法和体系却缺乏完整性的讨论。

6   测试分类

• 测试分类
  1. 安装测试
  2. 构建测试
  3. 白盒测试
  4. 黑盒测试
  5. 性能测试
  6. 迁移测试
• 目的 确定软件从安装到使用及至后期维护的稳定性和健壮性。

7   新手入门

• 测试是一个严谨、全面而有条理的过程
• 测试需要有测重点2/8原则） 除了小型项目，进行完全（各种输入和前提条件的组合）的测试是不可行的。需要动用风险分析和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试。

8   单元测试

定义：开发人员针对程序模块（软件设计的最小单位）来进行正确性检验的测试。

• 单元测试是和开发最接近的一种测试
• 由开发人员编写。开发人员编写单元测试用例并执行，验证单元模块是否得出预期的结果
• 单元测试是粒度最小的软件测试
  • 过程化编程：单个程序，函数，过程
  • 对象化编程：方法，基类，抽象类，派生类
• 子系统只有通过单元测试之后才集成到大系统中

9   白盒测试

定义：指测试人员可以直接访问内部数据结果、算法及其代码实现的测试。

常见的方法：

• 接口测试
• 代码覆盖率测试
• 缺陷注入方法

10   “单元测试”和“白盒测试”区别

1. 测试目不同
   • “白”是测试程序的整体逻辑
   • “单”是测试程序中一个独立的模块
2. 执行人员不同
   • 白盒一般是由专门的白盒测试人员完成
   • 单元测试一般由程序员自己完成

11   功能测试（黑盒测试）

定义：通过黑盒模式发现代码集成后存在的功能问题的测试。

• 关注的重点是系统的功能
• 可以自动或者手动执行测试用例

和 单元测试 的区别：粒度不同。

• 单元测试关注的是最小代码片断
• 功能测试关注的是一个完整的业务功能

12   性能测试

• 关注重点 验证软件的非功能性需求的测试
• 应对复杂苛刻的用户场景
  • 吞吐率
  • 稳定性
  • 可靠性
• 主要手段 通过自动化的方法模拟真实用户并发访问的场景
• 最终目的
  • 验证系统的性能指标或发现其性能瓶颈
  • 从根本上保证用户体验和长远利益

13   手工测试特点

• 优点
  • 方便灵活
  • 首次投入成本低
  • 人员素质要求低
• 缺点
  • 效率低
  • 重复开销大
  • 难以模拟复杂的使用场景，如：并发或连续事务

14   自动化测试特点

• 优点
  • 效率高，提供很强的生产力
  • 重复活动开销小
  • 基本可以模拟任何复杂的使用场景，除了图灵测试
  • 弱化了软件测试人员个体差异的影响
• 缺点
  • 首次投入成本高
  • 变更成本大
  • 人员素质要求高

15   自动化vs手动测试（1）

• 形成良好互补，2/8原则
• 因地制宜。测试投资回报比。ROI算法
  • 稳定，持续迭代，增量式的开发，流程固化（目前互联网主流模式），适合以自动化为主
  • 需求不稳定，一次性项目任务（传统软件工业主流模式），适合以手工为主
• 创造性的工作交付人来做，重复性工作交付机器来做
• 大项目适合自动化测试，小项目适合手工测试

16   自动化vs手动测试（2）

估计自动化脚本开发的必要性：

• 自动化测试成本= 脚本开发成本+（平均调试脚本成本 +平均执行脚本成本）× 测试执行次数
• 手工测试成本=平均手工执行工作量×测试执行次数
• ROI=自动化测试成本/手工测试成本

17   自动化vs手动测试（3）

小规模项目成本对比图：

分析：

• 小规模测试基本上手动和自动都可以适用
• 在很小规模的时候，手工在成本上有很大的优势
• 随着回归次数增加，手工成本基本线性增加，自动化则成本趋于稳定

18   自动化vs手动测试（4）

大规模项目成本对比图：

分析：

• 软件项目随着规模增大，很容易产生滚雪球效应
• 手工测试很快遇到天花板，无论是成本还是可操作性都会出现障碍，投入成本增幅远高于开发成本增幅
• 自动化将成为主流，基本成本的增长和开发的成本投入幅度相当

19   瀑布模式和敏捷模式

• 瀑布模式
  • 过程严格划分：需求分析/设计/实现/测试/集成/维护
  • 分工明确，但是灵性性差，项目失败风险大
• 敏捷模式(Agile Development)
  • 迭代开发(Iterative Development)
  • 增量开发（Incremental Development）
  • 把完整的过程分成多个持续时间较短的迭代
  • 能够实现持续集成
  • 具有很好的项目的风险控制能力和项目持续生产能力

20   软件过程自动化

• 构建自动化 自动化从各个模块的源码构建组装成一个完整的产品
• 测试自动化 构建前自动完成相应的测试工作
• 部署自动化 对于通过测试的构建好的产品，做好成品测试后，自动化部署到生产服务器

21   自动化场合选取

• 尽量对稳定的对象做自动化，如API接口
• GUI不建议使用自动化，投资回报比太低，变更大

22   自动化比例

• 自动化脚本的开发工作并不是越早越好，而是应该基于稳定的测试环境和测试计划。
• 有经验的测试工程师，是会在效率和质量上寻求平衡点，把精力集中在最容易出问题的点上。
• 自动化比例
  • 对于API测试的自动化测试选取40%~60%
  • 对于GUI测试的自动化测试选取30%左右

23   保留的争议性观念

1. 文档的重要性不亚于软件产品本身 这和另外的思路“最好的文档就是产品本身的代码”有所出入。
2. 完全的TDD是不适合大多数公司的。毕竟测试是属于上层建筑，建立在已有的开发产品上的。