ISTQB认证测试工程师学习笔记（2）——测试级别与测试类型

2020年的第一个证书，Foundation Level (CTFL)

测试级别

组件测试

组件测试（单元测试或模块测试）关注可单独测试的组件。

组件测试的目标：
（1）降低风险
（2）验证组件的功能和非功能行为是否符合设计和规定
（3）建立对组件质量的信心
（4）发现组件中的缺陷
（5）放置缺陷遗漏到更高的测试级别

组件测试通常独立于系统其它部分，具体取决于日记开发生存周期模型和该系统，可能需要模拟对象、服务虚拟化、用具、桩和驱动。测试内容可以包括功能（计算是否正确）、非功能（查找内存泄漏）、结构特性（判定测试）。

常用的组件测试依据：
（1）详细设计
（2）代码
（3）数据模型
（4）组件规格说明

典型组件测试对象：
（1）组件、单元或模块
（2）代码和数据结构
（3）类
（4）数据库模块

组件测试的典型缺陷和实效：
（1）功能实现不正确（与设计规格说明描述不一致）
（2）数据流问题
（3）代码和逻辑不正确

集成测试

集成测试侧重于组件或系统之间的交互。（也叫部件测试）

集成测试的目标：
（1）减少风险
（2）验证接口的功能和非功能行为是否符合设定和规定
（3）建立对接口质量的信心
（4）发现缺陷（可能存在于接口本身，也可能存在于组件或系统内部）
（5）防止缺陷遗漏到更高的测试级别

常用的集成测试依据：
（1）软件和系统设计文档
（2）序列图
（3）接口和通信协议
（4）用例
（5）组件或系统级别的架构
（6）工作流
（7）外部接口定义

集成测试的典型测试对象：
（1）子系统
（2）数据库
（3）基础结构
（4）接口
（5）API
（6）微服务

集成测试的典型缺陷和失效：
组件集成测试中的典型缺陷和失效包括：
（1）数据不正确、数据丢失或数据编码不正确
（2）接口调用的顺序或时序不正确
（3）接口不匹配
（4）组件间通信失效
（5）组件间未处理或处理不当的通信失效
（6）关于组件间传递的数据含义、数据单位或数据边界的假设不正确

系统集成测试中的典型缺陷和失效包括：
（1）系统间的消息结构不一致
（2）接口调用的顺序或时序不正确
（3）接口不匹配
（4）系统间通信失效
（5）系统间未处理或处理不当的通信失效
（6）关于系统间传递的数据含义、数据单位或数据边界的假设不正确
（7）未遵守强制性安全规定

组件集成测试和系统集成测试的重点在于集成，测试应侧重于模块或系统之间的通信而不是各个模块或系统的功能。功能测试、非功能测试、结构测试类型都适用于集成测试。

系统测试

系统测试侧重于整个系统或产品的行为和能力，通常会考虑系统可开展的端到端任务和开展这些任务时所展现的非功能行为。

系统测试的目标：
（1）减少风险
（2）确认已完成系统且系统按预期工作
（3）建立对整个系统质量的信心
（4）发现缺陷
（5）防止缺陷遗漏到更高的测试级别或生产

理想条件下，系统测试的测试环境与最终目标或生产环境相对应。

常用的典型系统测试依据：
（1）系统和软件需求规格说明（功能和非功能）
（2）风险分析报告
（3）用例
（4）史诗和用户故事
（5）系统行为模型
（6）状态图
（7）系统和用户手册

典型系统测试对象：
（1）应用程序
（2）软件/硬件系统
（3）操作系统
（4）被测系统（SUT）
（5）系统配置和配置数据

系统测试的典型缺陷和失效：
（1）计算不正确
（2）不正确的或非预期的系统功能或非功能行为
（3）系统内的控制流/数据流不正确
（4）不能正确的开展端到端的功能任务
（5）系统在系统环境中不能正常工作
（6）系统不能按照系统和用户手册中的说明进行工作

系统测试应侧重于整个系统的端到端行为，包括功能和非功能，应针对被测系统的各个方面使用最合适的技术（例如可以创建决策表来验证功能行为是否满足业务规则的要求）。
系统测试通常由高度依赖规范说明的测试员进行。过个说明中产生的缺陷会导致对预期结果缺乏理解或产生分歧。这些情况会导致测试结果出现假阳性（误报）和假阴性（漏报），误报会导致测试工作量的重复，漏报会导致缺陷检测有效性的降低。测试员在软件开发前期参与用户故事细化或静态测试活动（比如需求评审），可以有助于减少此类问题的发生。

验收测试

与系统测试类似，验收测试通常也是侧重于整个系统或产品的行为和功能。
验收测试可以提供信息，用于评估系统是否可以完成部署并交付给用户使用，虽然也可能在测试过程中发现缺陷，但发现缺陷一般不是该阶段的目标。如果在验收测试阶段发现大量缺陷，在某些情况下可能会被认为是重要的项目风险。
验收测试也可能是为了满足法律或法规要求或标准。

验收测试的目标：
（1）建立对整个系统质量的信心
（2）确认系统是否完整且系统将按预期工作
（3）验证系统的功能和非功能行为符合标准规范

验收测试的常见形式：

1.用户验收测试（UAT）
系统的用户验收测试通常侧重于验证系统是否适合在真实用户环境或模拟运行环境下运行。其主要目标是建立信心，让用户能够以最低的难度、成本和风险来使用系统去满足其要求，满足需求和开展业务流程。

2.运行验收测试（OAT）
操作员或系统管理人员对系统的验收测试，通常在模拟的生产环境下进行。测试内容侧重于运行方面，主要包括：测试备份和恢复，安装、卸载和升级，灾难恢复，用户管理，维护任务，数据加载和移植任务，检查安全漏洞，性能测试。
运行验收测试的主要目标是建立信心，操作员或系统管理人员能确保用户在运行环境中正常操作系统，即使在异常或困难的条件下也要确保系统可以正常运行。

3.合同和法规验收测试
合同验收测试是根据合同中规定的验收标准开展的。验收标准应在双方合同达成一致时确定，通常由用户或独立的测试员进行合同验收测试。
法规验收测试根据必须遵守的法规开展，例如政府、法律或安全法规。通常用户或独立测试员进行法规验收测试，有时监管机构也会参与见证或审计。

4.Alpha测试和Beta测试
Alpha 测试是在开发组织所在场地进行的测试，由潜在或现有客户、和/或操作人员或独立测试团队执行。Beta 测试是由潜在或现有的客户、和/或操作人员在他们本地执行。在完成 alpha 测试后，可以执行 Beta 测试，或之前没有执行过任何 alpha 测试的情况下执行 Beta 测试。

验收测试的典型测试依据：
（1）业务流程
（2）用户或业务要求
（3）法规、法律合同和标准
（4）用例或用户故事
（5）系统需求
（6）系统或用户文档
（7）安装规程
（8）风险分析报告
此外，在运行验收测试过程中，作为衍生测试用例的测试依据，也可以使用以下工作产品：
（1）备份和恢复规程
（2）灾难恢复规程
（3）非功能需求
（4）操作文档
（5）部署和安装说明
（6）性能目标
（7）数据库包
（8）安全标准或法规

验收测试的典型测试对象：
（1）被测系统
（2）系统配置和配置数据
（3）完整集成系统的业务流程
（4）恢复系统和热站点（用于业务连续性和灾难恢复测试）
（5）操作和维护流程
（6）表格
（7）报告
（8）现有和转换的生产数据

验收测试的典型缺陷和失效：
（1）系统工作流程不符合业务或用户需求
（2）业务规则未正确实现
（3）系统不满足合同或法规要求
（4）非功能失效（安全漏洞、高负载下的性能不足等）

验收测试通常由客户、业务客户、产品负责人和系统操作员负责，也可能涉及其他利益相关方。
验收测试通常作为顺序开发生存周期中的最后一个测试级别，但也可能在其他时间发生，例如：安装或集成商业现货（COTS）软件产品时，可能会对其进行验收测试；在系统测试之前可能会对新功能增强进行验收测试。
在迭代开发中，项目团队可以在每次迭代期间和迭代结束时进行各种形式的验收测试，例如根
据其验收标准验证新功能，以及确认新功能是否满足用户需求。此外，可能在每次迭代的最后，可能在每次迭代完成后或在一系列迭代之后，开展 alpha 测试和 beta 测试。也可能在每次迭代的最后，或者每次迭代完成或一系列迭代之后执行用户验收测试、运行验收测试、法规验收测试和合同验收测试。

测试类型

测试类型是一组基于特定测试目标的测试活动，旨在测试软件系统或系统的一部分特定特性。
这些目标可能包括:
1.评估功能质量特性，例如完整性、正确性和适当性
2.评估非功能质量特性，例如可靠性、性能效率、安全性、兼容性和易用性
3.评估组件或系统的结构或架构是否正确、完整并符合规定
4.评估变更的影响，例如确认缺陷已得到修复（确认测试）以及寻找因软件或环境变化而导
致的不可预料的行为变化（回归测试）

功能测试

系统的功能测试包括评估系统应该开展功能的测试。功能需求通常在工作产品中描述，例如业
务需求规格说明、史诗、用户故事、用例或功能规格说明，或者它们可能没有文档记录。功能指的是系统应该做“什么”。

尽管每个测试级别的关注点不一样，但所有测试级别都应该执行功能测试。
功能测试考虑软件的行为，因此可以通过使用黑盒技术获取组件或系统功能的测试条件和测试
用例。
功能测试的完整性可以通过功能覆盖来衡量。功能覆盖率是指测试执行某些功能的程度，并以
所覆盖元素类型的百分比形式来表示。例如，使用测试和功能需求之间的可追溯性，可以计算出通过测试的需求的百分比，潜在地识别出覆盖的缺口。

功能测试设计和执行可能涉及特殊技能或知识，如软件解决的特定业务问题(例如，石油和天然
气行业的地质建模软件)的知识。

非功能测试

系统的非功能测试是用来评估系统和软件的特性，例如易用性、性能效率或安全性。非功能测试是测试系统在运行过程中“表现如何”。

与常见的误解相反，非功能测试可以并应该在所有的测试级别上开展，并且应尽早开展。对于项目的成功而言，在项目后期才发现非功能性缺陷是非常危险的。

可以使用黑盒技术生成非功能测试的测试条件和测试用例。例如，边界值分析可用于定义性能测试的压力条件。
非功能测试的完整性可以通过非功能覆盖来衡量。非功能覆盖是指通过测试执行某种类型的非
功能元素所达到的程度，并且以所覆盖的元素类型的百分比形式来表示。例如，根据移动应用程序的测试和支持的设备之间的可跟踪性，可以计算出通过兼容性测试的设备所占百分比，发现潜在的覆盖缺口。

设计和执行非功能测试可能会涉及特殊技能或知识，例如设计或技术的固有弱点（例如，与特
定编程语言相关的安全漏洞）或特定用户基础（例如，医疗设施管理系统的用户角色）的知识。

白盒测试

白盒测试基于系统内部结构或实现来生成测试。内部结构可能包括系统内的代码、架构、工作
流和/或数据流。

白盒测试的完整性可以通过结构覆盖来测量。结构覆盖是指某种类型的结构元素在测试中被使
用的程度，并以所覆盖的元素类型的百分比形式来表示。
在组件测试级别，代码覆盖率基于已测试的组件代码的百分比。可以根据代码的不同方面（覆
盖项）来度量，例如组件中测试的可执行语句的百分比，或者测试的判定结果的百分比。这些类型的覆盖统称为代码覆盖。在组件集成测试级别，白盒测试可能基于系统的架构，例如组件之间的接口，结构覆盖率可以根据测试所执行的接口的百分比来度量。

设计和执行白盒测试可能会涉及特殊技能或知识，例如构建代码的方式、数据的存储方式（例
如，评估可能的数据库查询）以及如何使用覆盖工具并正确解释其结果。

与变更相关的测试

1.确认测试
修复缺陷后，应该在软件的最新版本上，重新执行之前因该缺陷而导致失败的测试用例。为了覆盖修复缺陷所需的变化，也可以使用新的测试来测试软件。至少必须在新的软件版本上重新执行这些由缺陷引起失效的步骤。确认测试的目的是确认是否已成功修复原来的缺陷。

2.回归测试
部分代码所做的变更，无论是修复代码，还是其他类型的更改，都可能会意外地影响到除更改代码外的其他部分代码的行为，不管是在同一组件内，还是在同一系统的其他组件中，甚至在其他系统中。变更也可能包括环境的变化，例如操作系统或数据库管理系统的新版本。这种意外的副作用被称为回归。回归测试包括运行测试来检测这些意外的副作用。
确认测试和回归测试可以应用在所有的测试级别。
特别是在迭代和增量开发生存周期（例如，敏捷）中，新增特征、更改现有特征以及重构代码都会导致频繁更改代码，这也需要与变更相关的测试。随着系统不断发展，确认和回归测试非常重要。这尤其和物联网系统特别相关，在物联网中，会频繁更新或替换个别对象（例如，设备）。

关于测试级别与测试类型的关系

可以在任何测试级别开展上述提到的任何测试类型。

以银行应用程序为例，介绍功能测试、非功能测试、白盒测试以及与变更相关的测试在所有测试级别中的应用。

从功能测试开始：
1、对于组件测试，根据组件是如何计算利息来进行测试设计。
2、对于组件集成测试，测试设计是基于如何将在用户界面捕获的账户信息传递到业务逻辑中。
3、对于系统测试，测试设计是基于帐户持有人如何在他们的支票帐户上申请信用额度。
4、对于系统集成测试，测试设计是基于系统如何使用外部微服务来检查帐户持有者的信用评分。
5、对于验收测试，测试设计是基于银行是如何处理批准或拒绝信贷申请。

非功能测试的示例：
1、对于组件测试，性能测试的设计是为了评估开展复杂的总利息计算所需的 CPU 周期数。
2、对于组件集成测试，安全性测试的设计是针对从用户界面传到业务逻辑的数据所产生的缓冲区溢出漏洞。
3、对于系统测试，可移植性测试的设计是为了检查表示层是否在所有支持的浏览器和移动设备上工作。
4、对于系统集成测试，可靠性测试的设计是为了在信用评分微服务无法响应时，评估系统的健壮性。
5、对于验收测试，易用性测试的设计是为了评估银行信贷处理界面对残疾人的无障碍性。

白盒测试的示例：
1、对于组件测试，测试的设计是为了对所有进行财务设计的组件实现完全的语句和判定覆盖。
2、对于组件集成测试，测试的设计是为了测试浏览器界面中的每个屏幕如何将数据传递到下一个屏幕和业务逻辑。
3、对于系统测试，测试的设计是为了覆盖信用额度应用期间可能发生的网页序列。
4、对于系统集成测试，测试的设计是为了检查所有可能发送到信用评分微服务的查询类型。
5、 对于验收测试，测试的设计是为了覆盖所有支持的财务数据文件结构和银行间转账的价值范围。

与变更相关的测试示例：
1、对于组件测试，为每个组件构建自动回归测试，并将其归入在持续集成框架内。
2、对于组件集成测试，测试的设计是为了确认当修复的代码已经集成到代码库时，与接口相关的缺陷已得到修复。
3、对于系统测试，如果工作流上的任何屏幕发生更改，则会重新执行指定的工作流的所有测试。
4、对于系统集成测试，每天重新执行与信用评分微服务交互的应用程序的测试，作为该微服务的持续部署的一部分。
5、对于验收测试，在验收测试中修复发现的缺陷后，将重新执行所有先前失败的测试。

对于所有软件而言，并不需要在每个级别上都运行每种测试类型，但在每个级别运行适用的测试类型很重要，尤其是测试类型出现的最早级别。

维护测试

一旦部署到生产环境，就需要维护软件和系统。在已交付的软件和系统中，各种各样的变更几乎是不可避免的，比如修复运行使用中发现的缺陷，或添加新功能，或是删除或修改已经交付的功能。在组件或系统的生存周期中，还需要维护或改进其非功能性质量特性，特别是性能效率、易用性、可靠性、安全性和可移植性。

系统维护期间做任何变更时，应该执行维护测试，以评估更改的成功程度，并检查系统中未变更部分(通常是系统的大部分)可能出现的副作用(如回归)。
维护可包含计划发布和计划之外发布（热修复）。

根据维护版本的范围，维护版本可能需要在多个测试级别上进行多种测试类型的维护测试。维护测试的范围取决于：
1）变更的风险程度，例如，变更软件区域与其他组件或系统通信的程度
2）现有系统的规模
3）变更的大小

维护的触发因素
导致软件维护，再到维护测试，其原因很多，包括计划的和计划外的变更。
维护的触发因素分类如下：
1）修改，例如计划的特性改善（例如，基于发布）、纠正和紧急变更，操作环境的更改（例如计划的操作系统或数据库升级）、商业现货（COTS）软件的升级以及缺陷和漏洞的补丁；
2）迁移，例如从一个平台到另一个平台，这可能需要对新环境以及更改的软件进行运行测试，或者当来自另一个应用程序的数据将迁移到正在维护的系统时进行数据转换测试；
3）退役，例如当应用程序的使用周期结束时。
当应用程序或系统退役时，如果需要较长的数据保留期，可能需要测试数据迁移或归档。
在长期保留归档之后，还可能需要测试保存/恢复规程。
可能需要进行回归测试，以确保在使用中的任何功能仍然有效。

对于物联网系统，可以通过将全新或修改过的内容（例如硬件设备和软件服务）引入整个系统来触发维护测试。这类系统的维护测试特别强调在不同级别（例如，网络级别、应用级别）的集成测试和安全方面，特别是那些与个人数据有关方面。