ISTQB CTFL证书考试之软件开发生命周期中的测试笔记（二）

一、专业术语中英对照表

中文	英文
验收测试	acceptance testing
alpha测试	alpha testing
beta测试	beta testing
变更相关的测试	change-related testing
商业现货软件（COTS）	commercial off-the-shelf
组件集成测试	component integration testing
组件测试	component testing
确认测试	confirmation testing
合同验收测试	contractual acceptance testing
功能测试	functional testing
影响分析	impact analysis
集成测试	integration testing
维护测试	maintenance testing
非功能测试	non-functional testing
运行验收测试	operational acceptance testing
回归测试	regression testing
法规验收测试	regulatory acceptance testing
顺序开发模型	sequential development model
系统集成测试	system integration testing
系统测试	system testing
测试依据	test basis
测试用例	test case
测试环境	test environment
测试级别	test level
测试对象	test object
测试目标	test objective
测试类型	test type
用户验收测试	user acceptance testing
白盒测试	white-box testing

​

二、软件开发生存周期模型及测试级别

1.瀑布模型开发活动包括：软件计划、需求分析、软件设计、程序编码、软件测试、运行维护

2.测试级别的划分：组件测试（单元测试）、集成测试、系统测试、验收测试

3.测试级别的属性：具体目标、测试依据、测试对象、典型的缺陷和失效、特定的方法和职责

4.对于验收测试主要还是会细分为：用户验证测试（UAT）、运行验收测试（OAT）、合同和法规验收测试以及Alpha测试和Beta测试。

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

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

c.合同验收测试：根据合同中生产定制软件的验收标准开展的，验收标准应在双方合同达成一致时确定，通常由用户或独立的测试员进行合同验收测试。法规验收测试：根据必须遵守的法规开展，通常由用户或独立的测试员进行法规验收测试，有时监管机构也会参与见证或审计。其主要目标是建立信心，证明合同或法规要求已得到满足。

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

三、测试类型及维护测试

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

测试类型主要包括：功能测试、非功能测试、黑白盒测试和与变更相关测试。其中大纲中未将黑盒测试包括在内，但个人认为黑盒测试是一个必不可缺的一种测试类型，因为其涉及到软件内部代码，极易引起缺陷，导致失效，所以笔记中加入黑盒测试。与变更相关性测试，主要也是涉及到内部代码块，在修复或变更某个模块的代码时，不经意间可能会影响其曾经涉及相关联的其它部分，这也是为什么要经常在各级别测试中，不断加入回归性测试的原因，回归性测试其实更多的是用自动化去跑。

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

1.功能测试

a.对于组件测试，根据组件是如何计算利息来进行测试设计

b.对于组件集成测试，测试设计是基于如何将在用户界面捕获的账户信息传递到业务逻辑中

c.对于系统测试，测试设计是基于帐户持有人如何在他们的支票帐户上申请信用额度

d.对于系统集成测试，测试设计是基于系统如何使用外部微服务来检查帐户持有者的信用评分

e.对于验收测试，测试设计是基于银行是如何处理批准或拒绝信贷申请。

2.非功能测试

a.对于组件测试，性能测试的设计是为了评估开展复杂的总利息计算所需的 CPU 周期数

b.对于组件集成测试，安全性测试的设计是针对从用户界面传到业务逻辑的数据所产生的缓冲区溢出漏洞。

c.对于系统测试，可移植性测试的设计是为了检查表示层是否在所有支持的浏览器和移动设备上工作

d.对于系统集成测试，可靠性测试的设计是为了在信用评分微服务无法响应时，评估系统的健壮性

e.对于验收测试，易用性测试的设计是为了评估银行信贷处理界面对残疾人的无障碍性

3.黑白盒测试

a.对于组件测试，测试的设计是为了对所有进行财务设计的组件实现完全的语句和判定覆盖

b.对于组件集成测试，测试的设计是为了测试浏览器界面中的每个屏幕如何将数据传递到下一个屏幕和业务逻辑

c.对于系统测试，测试的设计是为了覆盖信用额度应用期间可能发生的网页序列

d.对于系统集成测试，测试的设计是为了检查所有可能发送到信用评分微服务的查询类型

e.对于验收测试，测试的设计是为了覆盖所有支持的财务数据文件结构和银行间转账的价值
范围

4.与变更相关测试

a.对于组件测试，为每个组件构建自动回归测试，并将其归入在持续集成框架内

b.对于组件集成测试，测试的设计是为了确认当修复的代码已经集成到代码库时，与接口相关的缺陷已得到修复

c.对于系统测试，如果工作流上的任何屏幕发生更改，则会重新执行指定的工作流的所有测
试

d.对于系统集成测试，每天重新执行与信用评分微服务交互的应用程序的测试，作为该微服
务的持续部署的一部分

e.对于验收测试，在验收测试中修复发现的缺陷后，将重新执行所有先前失败的测试

维护性测试：多运用在已经投产的软件后期，触发的规则也是因各软件所运用的场景决定，重点是在软件进行版本的更新，或者软件加入新的功能，相对来说它的风险性是比较低的。