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

软件测试基本理论（1）

IBM生产模式

1 参考书目

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

出版社：电子工业出版社

印次：2013年6月

作者：IBM主要工程师

2 重要提醒

Warning

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

3 测试产生的时代背景

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

脆弱

不可靠

缺乏安全性

性能下降

出错

难以升级

73%的软件项目被延迟/超资/取消或失败

4 软件测试目的-IBM

确保软件质量

减少质量问题给企业及用户带来隐患

5 测试的现状

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

6 测试分类

测试分类
安装测试

构建测试

白盒测试

黑盒测试

性能测试

迁移测试

目的
确定软件从安装到使用及至后期维护的稳定性和健壮性。

7 新手入门

测试是一个严谨、全面而有条理的过程

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

8 单元测试

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

单元测试是和开发最接近的一种测试

由开发人员编写。开发人员编写单元测试用例并执行，验证单元模块是否得出预期的结果

单元测试是粒度最小的软件测试

过程化编程：单个程序，函数，过程

对象化编程：方法，基类，抽象类，派生类

子系统只有通过单元测试之后才集成到大系统中

9 白盒测试

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

常见的方法：

接口测试

代码覆盖率测试

缺陷注入方法

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

测试目不同

“白”是测试程序的整体逻辑

“单”是测试程序中一个独立的模块

执行人员不同

白盒一般是由专门的白盒测试人员完成

单元测试一般由程序员自己完成

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 保留的争议性观念

文档的重要性不亚于软件产品本身
这和另外的思路“最好的文档就是产品本身的代码”有所出入。

完全的TDD是不适合大多数公司的。毕竟测试是属于上层建筑，建立在已有的开发产品上的。

作者:	Harmo哈莫
作者介绍:	https://zhengwh.github.io
QQ:	1295351490
时间:	2015-08-24
版权说明:	未经许可，严禁用于商业目的的非法传播
联系或打赏:	http://zhengwh.github.io/contact-donate.html