1、软件测试的基本概念

1.1什么是软件测试

时间? ? ??	提出人（机构）	定义	备注
1973?	Bill Hetzel	软件测试就是为了程序能够按预期设想运行而建立足够的信心	强调的是证实程序按预期运行，不能按预期运行时，就意味着程序有错误，需要修改后再重新测试。软件“证真”
1979? ? ? ?	Glenford	测试是为了发现错误而执行一个程序或者系统的过程	强调的是测试目的是发现错误。软件“证伪”
1983? ? ? ?	IEEE	使用人工或自动化手段来运行和预测某个系统的过程。其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果与预期结果的差异。	接近于hetzel的定义，但强调了识别实际结果与预期结果的差异。
1983	Bill Hetzel	测试是以评价一个程序或者系统的特性或能力为目标的一种活动	程序或者系统的特性与能力是软件质量的重要组成部分。
2014	IEEE	软件测试是动态验证程序针对有限的测试用例集是否可产生期望的结果。	这是最新的定义，关注了测试用例集的有限性特征和对程序是否满足期望结果的验证。但是这是一个狭义的定义，只定义了广义软件测试概念中的动态验证，没有包含静态验证及各类评审（如设计、流程、管理、技术、工具选择等）。

? ? ? ? 不管是哪个时期的定义，软件测试的目的实际上是一致的，这个目的就是“保证软件质量”。具体来讲就是要保证软件或系统符合相关的法律法规技术标准和应用需求，降低软件的产品风险及应用风险。

? ? ? ? 软件测试的对象是软件，包括程序、数据和文档。对于测试的组织者和实施者，第一需要明确测试对象的边界，第二必须认识到环境对测试的影响，以获得恰当环境下的真实测试结果。

1.2验证与确认

英文中验证为“Verification”，确认为“Validation”。很多时候用V&V来代表验证与确认。

GB/T19000-2016《质量管理体系基础和术语》定义如下：

验证——通过提供客观证据来证实规定需求已经得到满足。
确认——通过提供客观证据来证实针对某一特定预期用途或应用需求已经得到满足。

? ? ? ? 对于软件来讲，验证是检验软件是否满足需求规格说明的要求，或者说是否实现的需求规格说明中所有特性（功能性、性能、易用性等），由于需求规格可能是软件生产者主导或参与完成的文件，用于指导后续的软件生产活动，因此，验证是判断生产者是否（按需求规格）正确地构造了软件，或者说是不是“正确地做事”。而确认则是检验软件是否有效，是否满足用户的预期用途和应用需求。由于需求规格不一定真实体现了用户的特定预期用途或应用要求，通过验证的软件也就不一定能够通过确认。因此，确认是要判断生产者是否构造了正确的软件，或者说是否“做了正确的事”。

? ? ? ? 当把软件看成产品时，验证和确认所要做的事情是有不同的依据的。验证的依据是产品要求（需求规格），是生产者自己的内部要求，而确认的依据是用户的应用要求（或许没有在需求规格中得到完全真实体现），对软件生产者来讲是一种外部要求。因此验证和确认所开展的工作有相同的部分也有不相同的部分，除了测试外，确认应该有更多的活动，如评审、用户调查及意见收集等。

1.3软件缺陷

人们常常将软件的问题、错误以及因软件而引起的异常、故障、失效、偏差等均称为软件缺陷。

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

国标GB/T32422-2015：将缺陷定义为“工作产品中出现的瑕疵或缺陷，导致软件产品无法满足用户需求或者规格说明，需要修复或者替换”。

软件异常被定义为：从文档或软件操作观察到偏离以前验证过的软件产品或引用的文档的任何事件。

缺陷的优先级
属性? ?	描述
紧急????????	需要立即处理
高	应在下一个可运行的版本中解决
中	应在第一个交付版本中解决
低	期望在第一个交付版本中解决（在第一个交付版本后升级优先级“中”）
无	无需在第一个交付版本中解决

缺陷的严重性
属性值	描述
阻塞	在纠正或发现合适的方法之前，测试无法进行
严重	主要操作被打乱，导致安全性受到影响
一般	主要操作受到影响但软件产品仍能继续运行
轻微	非主要操作受到影响
可忽略	操作未受影响

1.4测试与质量保证

质量保证：ISO8402:1994：为了提供足够的信息表明实体能够满足质量要求，而在质量管理体系中实施并根据需要进行证实的全部有计划和有系统的活动。

ASQC（美国质量管理协会）：QA是以保证各项质量管理工作实际地、有效地进行与完成为目的的活动体系。

八大质量特性：功能性、性能效率、兼容性、易用性、可靠性、信息安全性、维护性和可移植性；使用质量模型包括了与系统交互结果有关的五个特性：有效性、效率、满意度、抗风险和周境覆盖。

1.5测试用例

GB/T25000.51-2016：就绪可用软件产品的质量要求和测试细则对测试用例有如下定义：为某个特定目标（例如，为演练具体的程序路径或验证对特定需求的依从性）而开发的输入、执行条件以及预期结果的集合。

定义包含了如下一些要点：

第一：，测试用例是测试人员针对具体目标设计或开发出来的，有非常强的目的性；

第二：测试用例将体现软件的某一个具体运行实例或场景，包括输入的测试数据、执行条件、逻辑过程以及预期的逻辑结果等；

第三，测试用例需提供准确的判定准则，即依照该用例实施测试获得实际结果时如何判定。

GB/T38634.2-2020：应当通过确定前置条件，选择输入值以及必要时执行所选测试覆盖项的操作，以及确定相应的预期结果来导出。

测试用例对测试的实施具有非常重要的作用。首先，测试用例是测试实施的依据，测试人员应该按照设计好的测试用例开展测试，获取结果并进行判定；其次，测试用例是根据测试目标系统严密设计出来的测试任务描述，体现了测试的方案、方法、技术和策略，在测试用例的指导下可以保证测试的规范性，提高测试效率，避免测试的随意性和盲目性，从而保证测试的质量；此外，测试用例是软件企业的一类资产，具有相当大的价值。

测试用例应包括用例的表示、名称、说明、环境配置、操作过程、各种条件、评价准则以及建立用例的人员和时间等信息。其中操作过程要描述每一步操作的输入数据、过程说明、预期结果和通过准则等。

1.6测试策略

软件测试策略可以划分为给予分析（如风险分析、需求规格分析）的策略、基于模型（如业务模型、软件质量模型、系统性能烟花模型）的策略、基于规准规范的策略以及基于自动化的回归测试策略等等。

测试策略的输入包括如下方面：

测试所需软硬件资源的详细说明
针对测试和进度约束，需要的人力资源的角色和职责
测试方法、测试标准和完成标准
目标系统的功能性和非功能性需求、技术指标
系统局限（即系统不能够满足的需求）等

测试策略的输出包括如下方面：

已批准或审核的测试策略文档、测试用例、测试计划
需要解决方案的测试项目。

制定测试策略的过程为：

确定测试的需求。需要注意一下几点：
- 测试需求必须是可观测、可评测的
- 软件需求与测试需求以及测试用例不是一对一关系
- 测试需求可能有许多来源
评估风险并确定测试优先级
- 成功的测试需要在测试工作中权衡资源约束和风险。为了确定测试工作优先级，需执行风险评估和实施概要，并将其作为确定测试优先级的基础。
确定测试策略
- 一个好的测试策略应该包括：实施的测试类型和测试目标、实施测试的阶段、技术、评估测试结果和测试是否完成的标准，对测试工作存在影响的特殊事项等。

2.软件测试的原则

溯源性原则：不同阶段的测试有不同的阶段性目的，但汇集起来后的总目标是保证软件质量，这主要通过对需求的符合性验证和确认来体现，因此测试应当溯源到原始需求，而不是仅仅只盯着眼前。
工程性原则：测试不是某一个阶段的活动，而是贯穿软件生产的各阶段，需要以工程化的思想和方法来组织和实施。需尽早按计划开展测试，甚至进行预防性测试，以避免测试延迟带来的巨大代价。
独立性原则：应当避免开发工程师测试自己的程序，自己测试自己的程序会受到定势思维和心理因素的影响大，测试质量将大打折扣，企业应设立独立的测试工程师岗位或测试部门去承担工作。
合理性原则：对软件进行完全测试是不可能的，基于有限的时间和有限的资源，无法对软件开展穷举式的测试。基本规律是测试成本与测试强度成正比，遗留缺陷和测试强度成反比，因此正确的策略是在质量要求和测试强度之间寻找合理的结合点，获得最优的测试效费比，避免测试不足和过度测试。这需要合理地设定测试的终止条件。
不完全性原则：任何人或者机构对软件测试后评价只能描述为“未发现错误”，而不能描述为“没有错误”。
相关性原则：基于大量的测试统计和分析，人们发现一个软件（模块）中被找到的缺陷越多，则这个软件（模块）中残留的缺陷也越多，缺陷常常有聚集现象。这个原则提醒测试工程师对暴露错误多的模块应该加强测试。
可接受性原则：测试的直接目标是发现软件测试，但更进一步的目的是修复发现的缺陷，然而修复缺陷是有代价的，因此时间或修复风险等方面的原因，已发现的缺陷不一定全部修复都。应交由恰当的人员或会议进行决策。
风险性原则：测试虽然是为了降低或化解软件的质量风险，但必须认识到测试本身也是有风险的。需要在做测试设局及构造测试用例时考虑如何规避和减少风险。