测试理论

1. 引子

1.1 什么是软件测试

术语概念
软件测试是贯穿整个软件开发生命周期、对软件产品进行验证和确认的活动过程。
验证：Verification：Are we building the product right?
有效性确认：Validation：Are we building the right product?
程序测试是为了发现错误而执行的过程。源自G.J.Myers在其经典的著作《软件测试艺术》（The Art of Software Testing）

深入理解
软件测试是站在软件最终用户的视角和立场，替他们检查软件，用他们所有可能的使用方式去尝试发现软件的问题。
此外，还会用到各种工具，使用用户不使用和用户做不到的方式，深入软件内部进行检查
先于用户，发现软件的问题，并修复。

1.2 软件测试的作用

保证软件产品的质量
给用户带来优秀的使用体验
帮助开发团队，发现软件的问题并修复
软件测试的结果，一定程度上可以给管理层提供决策支持

2. 测试基础

2.1 传统的软件测试过程

单元测试：针对源代码中的方法和函数级别对象进行测试，一般是开发完成，主流认知上认为是开发人员的工作。
集成测试：针对源代码中模块与模块之间的调用进行测试，一般也是开发完成。（主要因为测试人员的编程水平不足以完成），目前比较典型的有接口测试。
确认测试：在正式开始系统测试之前，先试一下软件是否能完成基本的功能，又叫冒烟测试。只有通过该测试的软件，才会正式开始系统测试，否则是浪费测试人员的时间。
系统测试：目前最主要的测试工作。是通过对软件系统的使用，完成测试。
验收测试：由客户执行，或者有客户代理人执行，将软件的主要功能检查一遍，是软件最终的交付前的测试。

2.2软件测试模型

传统测试模型

瀑布模型
V模型：改良型的瀑布模型，测试不再只测试软件本身，而是需要从需求开始测试。
W模型：测试与开发同时进行的测试。

敏捷测试模型

Scrum模型

3. 测试启动

3.1 软件的质量需求

软件质量的定义：质量是反映实体(产品、过程或活动等)满足明确和隐含需要的能力的特性总和。
软件质量的管理体系
ISO9001
CMM：Capability Maturity Model，能力成熟度模型
软件质量的模型
- 功能性：是指当软件在指定条件下使用，软件产品满足明确和隐含要求功能的能力。

适合性：是指软件产品与指定的任务和用户目标提供一组合适的功能的能力。
准确性：是指软件产品具有所需精确度的正确或相符的结果及效果的能力。
互操作性：是指软件产品与一个或多个规定系统进行交互的能力。
保密安全性：是指软件产品保护信息和数据的能力，以使未授权的人员或系统不能阅读或修改这些信息和数据，但不拒绝授权人员或系统对其的访问。
功能依从性：是指软件产品依附与同功能性相关的标准、约定或法规以及类似规定的能力。

- 可靠性：在指定条件下使用时，软件产品维持规定的性能级别的能力。

成熟性：是指软件产品避免因软件中错误发生而导致失效的能力。
容错性：是指在软件发生故障或违反指定接口的情况下，软件产品维持规定的性能级别的能力。
易恢复性：是指在失效发生的情况下，软件产品重建规定的性能级别并恢复受直接影响的数据的能力。
可靠性依从性：是指软件产品依附与同可靠性相关的标准、约定或法规以及类似规定的能力。

- 易用性：是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。

易理解性：是指软件产品使用户能理解软件产品是否合适以及如何能将软件用于特定的任务和使用环境的能力。
易学性：是指软件产品使用户能学习它的能力。
易操作性：是指软件产品使用户能操作和控制它的能力。
吸引性：是指软件产品吸引用户的能力。
易用性依从性：是指软件产品依附与同易用性相关的标准、约定、风格指南或法规以及类似规定的能力。

- 效率：是指在规定条件下，相对于所用资源的数量，软件产品可提供适当的性能的能力。

时间特性：是指在规定条件下，软件产品执行其功能时，提供适当的响应时间和处理时间以及吞吐率的能力。
资源利用性：是指在规定条件下，软件产品执行其功能时，提供合适的数量和类型的资源的能力。
效率依从性：是指软件产品依附与同效率相关的标准或约定的能力。

- 维护性：是指软件产品可被修改的能力，修改可能包括修正，改进或软件适应环境、需求和功能规格说明中的变化。

易分析性：是指软件产品诊断软件中的缺陷或失效原因，以及判定待修改的部分的能力。
易改变性：是指软件产品使指定的修改可以被实现的能力。
稳定性：是指软件产品避免由于软件修改而造成意外结果的能力。
易测试性：是指软件产品使已修改软件能被确认的能力。
维护性依从性：是指软件产品依附与同维护性相关的标准或约定的能力。

- 可移植性：是指软件产品从一种环境迁移到另一种环境的能力。

适应性：是指软件产品无需采用有别于为考虑该软件的目的而准备的活动或手段，就可能适应不同的指定环境的能力。
易安装性：是指软件产品在指定环境中被安装的能力。
共存性：是指软件产品在公共环境中同与其分享公共资源的其他独立软件共存的能力。
易替换性：是指软件产品在环境相同、目的相同的情况下替代另一个指定软件产品的能力。
可移植性依从性：是指软件产品依附与同可移植性相关的标准或约定的能力。

3.2. 软件质量的对立面—软件缺陷

问题的引出
The First “Computer Bug” | 首个“计算机Bug”

Moth found trapped between points at Relay # 70, Panel F, of the Mark II Aiken Relay Calculator while it was being tested at Harvard University, 9 September 1947. The operators affixed the moth to the computer log, with the entry: “First actual case of bug being found”. They put out the word that they had “debugged” the machine, thus introducing the term “debugging a computer program”.
1947年9月9日，哈佛大学测试马克II型艾肯中继器计算机，操作员在电板编号为70的中继器触点旁发现了一只飞蛾。然后操作员把飞蛾贴在计算机日志上了，并写下了“首个发现bug的实际案例”。他们提出了一个词，“debug（调试）”了机器，从而引入新术语“debugging a computer program（调试计算机程序）”。
In 1988, the log, with the moth still taped by the entry, was in the Naval Surface Warfare Center Computer Museum at Dahlgren, Virginia.
1988年，这个仍然贴着飞蛾的日志，保存于弗吉尼亚州达尔格伦的海军水面作战中心计算机博物馆。

以下的两句话明确了缺陷的产生。
程序员犯了一个错误，这个错误在程序中表现为缺陷，
运行带有缺陷的软件或者程序，就可能观察到失效
缺陷：程序或者软件中不正确的步骤、过程或者数据定义等

错误的语句
错误的标量定义
不正确的文档
不正确的程序段
不正确的指令
不正确的数据定义

……

失效：软件系统或单元无法实现需求文档中规定的功能特性或者非功能特性

不正确的系统反应
系统崩溃
系统死机
……

缺陷产生的原因
软件缺陷的产生主要有软件产品的特点和开发过程决定的。比如需求不够清晰，频繁变更等；或者软件由于竞争非常激烈，技术日新月异，使用新技术也容易产生问题。大致有以下几种主要原因：

项目期限的压力
产品的复杂程度
沟通不良
开发人员疲劳、压力过大或者受到干扰
缺乏足够的知识、技术和经验
不了解客户的需求
缺乏动力

缺陷管理的目的
软件测试就是为了更早、更快的发现缺陷。换句话说，缺陷的发现可以看作是测试工作的主要成果之一。软件缺陷管理的实施，至少有如下三个基本目的：

加快缺陷的修正。
产品的质量评估
预防缺陷

最终的定义

软件缺陷（Defect），常常又被叫做Bug。所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

bug 和 defect

飞蛾或者虫子爬进主机引起短路，造成计算机失效的事件中，我们可以看到bug就是虫子或者是虫子引发失效这样的事件。那么defect又是什么呢？
真正的Defect是计算机维护工程师提出来的那个问题：在主机的散热孔那里可以加装一层更加细密的金属网，即不影响散热，又可以防止虫子爬到主机里。这是计算机设计人员疏忽的地方，是产品真正的Defect。而虫子引发的那个故障只是这个Defect导致的故障的其中一种表现形式。也就是说，Bug是Defect的一种表现形式，而一个Defect是可以引起多种Bug的。

术语解释
软件测试使用各种术语描述软件出现的问题，通用的术语如下：

软件错误
Software Error，导致软件包含故障的人的行为。软件生存期内的人为错误，导致软件缺陷产生。是人为过程，相对于软件本身是外部行为。
在可以预见的时期内，软件仍将由人来开发。在整个软件生存期的各个阶段，都贯穿者人的直接或间接的干预。然而，人难免犯错误，这必然给软件留下不良的痕迹。软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种人为过程，相对于软件本身，是一种外部行为。
软件缺陷
Software Defect，软件的异常情况，软件存在的一些短板。存在于软件（文档、数据、程序）中的偏差，导致软件在某个特定条件下出现故障，这时称软件缺陷被激活。
软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一个逗号、多一语句等。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。
软件故障
Software Fault，引起一个功能组件不能完成所要求的功能的一种意外情况。软件运行过程中出现的不希望或不可接收的内部状态。是动态行为。
软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。譬如，软件处于执行一个多余循环过程时，我们说软件出现故障。此时若无时当的措施（容错）加以及时处理，便产生软件失效。显然，软件故障是一种动态行为。
软件失效
Software Failure，功能组件执行其规定功能的能力丧失。软件运行时产生的不希望或不可接受的外部行为结果。
软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。失效是指功能部件执行其规定功能的能力丧失。软件失效是指软件运行时产生的一种不希望或不可接受的外部行为。
软件错误是一种人为错误。一个软件错误必定产生一个或多个软件缺陷。当一个软件缺陷被激活时，便产生一个软件故障；同一个软件缺陷在不同条件下被激活，可能产生不同的软件故障。软件故障如果没有集市的容错措施加以处理，便不可避免地导致软件失效；同一个软件故障在不同条件下可能产生不同的软件失效。

缺陷的类型

遗漏（Missing）
错误（Error）
额外的实现（Extra）
改进（Enhancement）

缺陷的评价标准

软件未实现需求规格说明书要求的功能
软件未实现需求规格说明书虽未明确提及但应该实现的目标
软件出现了需求规格说明书指明不应出现的错误
软件实现了需求规格说明书未提到的功能
软件难以理解、不易使用、运行缓慢，或者从测试工程师的角度来看——最终用户会认为不好

缺陷报告

测试执行过程中，发现软件失效后，提出书面的报告，提供给开发人员或者其他负责人员作为定位缺陷的依据，也作为日后缺陷度量的数据依据。
软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发小组交流的最初并且最好的机会。一个好的描述，需要使用简单、准确、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员。因此，准确的报告软件缺陷是非常重要的。

清晰准确的软件缺陷描述可以减少被开发人员退回来的缺陷数量

提高软件缺陷修复的速度，使每一个小组能够有效的工作

提高测试人员的可信任度，可以得到开发人员对有效缺陷的快速或者及时响应

加强开发人员、测试人员和管理人员的协同工作，让他们可以更好的工作

软件缺陷产生的原因

错误：程序员在写代码的时候犯错误，写错代码，此时程序已经有了缺陷
失效：错误的代码在运行的时候，遇到特定的情况，激发了错误之处，导致程序被观察到失效
缺陷：程序的失效，会证明软件有缺陷

缺陷产生的原因