全程软件测试（一一零）：软件测试原则与工程师要求—读书笔记

一、 软件测试的原则

1 所有的测试都应追溯到用户需求

1.1 缺陷的源头

根据相关调查，软件缺陷出现最多的地方是软件需求规格说明书（即软件需求定义），而不是程序代码。

1.2 如何应用此原则

测试第一个任务是需求分析

测试需求分析要做好

时刻都要提醒自己考虑用户需求

制造缺陷的罪魁祸首不是程序员

做好需求评审

审查所做的内容是否符合用户的需求

2 尽早启动测试工作

2.1 缺陷雪崩

2.2 测试的成本

2.3 如何应用此原则

测试应该早进行。

测试应该是与软件开发或维护工作并行进行的一个过程，测试应该持续进行。

3 早做测试计划

软件测试不仅仅是测试执行。

应该在测试工作真正开始前的较长时间内就进行测试计划。

4 穷尽测试不可能 & 软件测试有风险

完全测试、完美测试、充分测试。

4.1 无法穷尽测试的主要原因

测试数据输入量太大、时间不够等。

4.2 如何应用此原则

如果决定不去测试所有的情况，那么我们就面临了很大的风险。

如果时间不够，无法进行充分的测试怎么办?

使用风险分析，确定测试的重点和优先级，控制测试的开销（时间、成本、资源）。

风险分析需要判断技能、常识、感觉和经验。

5 测试工作的 Good-enough 原则

5.1 含义

既不要做过多测试，也不做不充分的测试。

5.2 如何应用此原则

解决办法是通过需求分析和风险分析（时间、费用、资源）找到测试重点，制定最低测试通过标准和测试内容，然后具体问题具体分析。

6 Pareto 法则应用于软件测试

6.1 含义

Pareto（帕累托）法则由意大利经济学家帕累托提出，又称为 28 效率法则。

一般情况下 80％的缺陷聚集在 20％的关键核心业务模块中。

在分析、设计、实现阶段的复审和测试工作能够发现和避免 80%的缺陷，而系统测试又能找出其余缺陷中的 80%，最后的 4%的缺陷可能只有在用户的大范围、长时间使用后才会曝露出来。

6.2 如何应用此原则

做好测试需求分析和测试计划，分清测试重点。

尽早测试。

持续测试。

7 尽可能使用分阶段测试

单元测试→集成测试→系统测试→验收测试

代码规模不断加大

8 为了达到最佳效果，应该由独立的第三方来构造测试

“最佳效果”指最有可能发现错误的测试。

1、程序员从来都不会承认自己写的程序有错误。

2、程序员测试自己的编码是一件很糟糕的事，但是让他们测试别人的编码却成了最好的测试人员。

3、程序员的测试思路有明显的局限性。

4、多数程序员没有经过严格正规的职业训练。

5、程序员无良好的 BUG 跟踪和回归测试习惯。

9 测试旨在发现存在的缺陷

软件测试可以 告软件缺陷存在，却不能 告软件缺陷不存在；

既使在测试过程未发现软件的失效，也不能证明被测软件没有错误。

10 为了保证测试的有效性和高效性，测试必须是破坏性、系统化的

充分、有效、系统的测试可以减少软件中未被发现缺陷的可能性；

测试既要验证软件的正确性，更要通过破坏软件，发现缺陷的不正确性。

11 找到的软件缺陷越多，说明软件隐含的缺陷越多

缺陷具有群集效应。

应该在发现缺陷的地方继续找找。

12 杀虫剂怪事

用于描述软件测试越多，其对测试的免疫力越强的现象。

程序员对测试人员的“惯用伎俩”已经可以主动躲避了！

为了克服杀虫剂怪事，软件测试员必须不断编写不同的、新的测试程序，对程序的不同部分进行测试，以找出更多软件缺陷。

13 并非所有软件缺陷都要修复

没有足够的时间；

不算真正的软件缺陷；

修复的风险太大；

不值得修复。

14 使用木桶原理

木桶原理在软件产品生产方面就是全面质量管理（QTM）的概念。

团队合作。

15 前进两步，后退一步

测试中的一个基本问题是——缺陷修复总会以（20-50）%的机率引入新的缺陷。

每次修复之后，必须做确认测试和回归测试。

再测试/确认测试：测试人员提交缺陷，开发人员修复缺陷以后，测试人员需要重新测试，验证之前的提交的缺陷是否真正修复。

回归测试：测试人员提交缺陷，开发人员修复缺陷以后，测试人员需要重新测试，确保对程序修改改没有给软件其他未改变部分带来新的缺陷。软件修改或者环境变更后，必须进行回归测试。

16 软件测试是一个迭代的过程

无论项目采用何种开发模型，测试人员总是一个版本接一个版本地测试，其测试活动总是迭代向前的

测试版本 1->提交缺陷->修复缺陷->测试版本 2->提交新缺陷->修复新缺陷->测试版本 3->…

17 测试需要遵循标准

17.1 什么是标准

你家的某个电器或家具脱落了一个螺丝钉，你可能会很随意地到街市买一个回家安上，这说明什么——制造业的标准在起作用。家用电器是依据标准制造的，所以随之而来的各种标准配件也会很容易找到。

17.2 标准的分类

国际标准：如 ISO、CMM（Capability Maturity Model，软件能力成熟度模型）、IEEE（国际电气电子工程师协会）

国家标准：GB、GB/T

行业标准

公司标准

用户规定

17.3 案例

测试 5 层居民楼的电梯

1+0.1=？

18 其他的一些测试理念

思路决定测试

具体问题具体分析

无责任心不成测试

测试不能靠猜测

二、 软件测试行业概述

1 乐趣

破坏程序纯粹的快乐

破坏行为具有价值

体现出魔术般的力量

学习的乐趣

2 烦恼

必须追求完美

由他人来设定目标，供给资源，提供信息

测试往往是线性收敛

投入了大量辛苦，用户发现的致命缺陷将否定全部工作

3 第三方测试

是指独立于软件公司自身测试的测试，所谓的第三方是指在软件公司和软件用户之间的另一方。

4 机遇

微软公司的测试

国内的测试

在认识上重开发、轻测试；

在管理上随意、简单，没有建立有效、规范的软件测试管理和评判体系；

缺少自动化工具的支持。

三、 软件测试工程师的要求

1 行业知识与软件测试

高效的测试团队应该由具备各种专门技术的成员（具备行业知识、专业技能、测试技术等）组成，同时也应该由具备各种经验的成员（测试新手和测试专家）组成。

目前被测软件正在变的多元化，各个行业的软件都有可能会碰到，如何判断需求是否已经包含所有可能的细节？

如何高效准确的进行测试，在最短的时间内确定问题的所在？

2 优秀的软件测试工程师品质

态度

有责任心

破坏的态度

对事不对人

三心二意

细心、信心、耐心

团队合作的沟通意识、时刻保持怀疑的态度（即缺陷预防意识）

具备一定的开发技能

了解开发原理

便于与开发沟通

习惯打破砂锅问到底（善于思考）

3 改善测试员和其他小组成员之间的沟通和相互关系的方法

以合作而不是争斗的方式开始项目

时时提醒项目的每位成员：共同目标是追求高质量的产品。

对产品中发现的问题以中性的和以事实为依据的方式来沟通

不要指责引入这个问题的小组成员或个人。比如，客观而实际地编写缺陷 告和评审发现的问题。

换位思考

尽量理解其他成员的感受，以及他们为什么会有这种反应。

有效沟通

开发与测试具有不同的思维方式，确信其他成员已经理解你的描述，反之亦然。

提高开发技能