测试类型是一组基于特定测试目标的测试活动，旨在测试软件系统或部分系统的特定特性。这些目标包括：
• 评价功能质量特性，如完整性、正确性和适合性
• 评价非功能性质量特性你，如可靠性、性能效率、安全性、兼容性和易用性
• 评估组件或系统的结构或框架是正确的、完整的并符合规定
• 评估变更的影响，如确认缺陷已修复（确认测试）和查找软件或环境变更而导致的不可预料的行为变更（回归测试）
2.3.1 功能测试
系统的功能测试包括对系统应执行的功能进行评估的测试。功能需求可以在工作产品中描述，如业务需求规格说明、史诗、用户故事、用例或功能规格说明，也会存在没有文档的情况。功能指的是系统应该做的。
功能测试应该在所有测试级别上进行（例如：基于组件测试规格说明的组件测试），尽管每个测试级别的关注点是不同的（见2.2节）。
功能测试考虑的是软件的行为，因此黑盒技术可用来获取针对组件或系统功能的测试条件和测试用例（见4.2节）。
功能测试的完整性可以通过功能覆盖来衡量。功能覆盖是指某种类型的功能元素在多大程度上已通过测试得到检查，并以所覆盖的元素类型的百分比表示。例如：利用测试和功能需求之间的可追溯性，可以计算通过测试覆盖需求的百分比，从而识别覆盖的差距。
功能测试设计和执行会涉及特殊技能或知识，例如对软件所解决的特定商业问题的了解(例如石油和天然气工业的地质建模软件)或软件所发挥的特定作用(例如提供互动娱乐的电脑游戏软体）。
2.3.2 非功能测试
系统的非功能测试用来评估系统和软件的特性，如易用性、性能效率或安全性。软件产品质量特性的分类请参照ISO标准（ISO/IEC 25010）。非功能性测试是测试系统表现得“多好”。
与常见的误解相反，非功能测试可以且经常应该在所有测试级别上执行，并尽早完成。晚发现非功能缺陷对项目的成功是极为危险的。
黑盒技术（见4.2节）可用于获取非功能测试的测试条件和测试用例。例如：边界值分析可以用来定义性能测试的压力条件。
非功能测试的完整性可以通过非功能覆盖来测量。非功能覆盖是指某种类型的非功能元素在多大程度上已通过测试得到检查，并以所涵盖的元素类型的百分比表示。例如：利用测试和移动应用程序支持的设备之间的可追溯性，可以计算通过兼容性测试的设备的百分比，从而确定潜在地覆盖差距。
非功能性测试的设计和执行会涉及到特殊技能或知识，例如关于设计或技术内在弱点的知识(例如与特定编程语言相关的安全漏洞)或特定用户基础(例如医疗设施管理系统用户的角色）。
关于非功能质量特性测试的详细信息，请参阅ISTQB-ATA高级测试分析师大纲、ISTQB-ATTA高级技术测试分析师大纲、ISTQB-SEC高级安全测试课程大纲和其他ISTQB专家级模块。
2.3.3 白盒测试
白盒测试基于系统内部结构或实现识别测试。内部结构包括系统内的代码、架构、工作流和/或数据流(见4.3节)。
白盒试验的完备性可以通过结构覆盖来测量。结构覆盖是指某种类型的结构元素在多大程度上通过测试得到了检查，并以所涵盖的元素类型的百分比表示。
在组件测试级别，代码覆盖基于已测试组件的代码的百分比，并可根据代码的不同方面（覆盖项）来测量，例如组件中测试的可执行语句的百分比，或是经过测试的判定结果的百分比。这些类型的覆盖统称为代码覆盖。在组件集成测试级别，白盒测试可以基于系统的体系架构，例如组件之间的接口，结构覆盖可以用测试所使用的接口的百分比来测量。
白盒测试的设计和执行可能涉及特殊技能或知识，例如代码的构建方式（例如使用代码覆盖工具）、数据的存储方式（例如评估可能的数据库查询），以及如何使用覆盖工具和正确解释其结果。
2.3.4 与变更相关的测试
在对系统进行变更以修复缺陷或由于增加或变更功能时，都应该进行测试以确认这些变更修复了缺陷或正确实现该功能，并且没有造成任何意外的不利后果。
• 确认测试：缺陷修复后，所有因该缺陷而失败的测试用例都需要在软件中进行测试，并应在新的软件版本上重新执行。例如：如果缺陷是缺少功能，软件也可以用新的测试进行测试。至少，由于该缺陷造成的失效的重现步骤必须在新的软件版本上重新执行。确认测试的目的是确认原始缺陷是否已成功修复。
• 回归测试：代码某个部分的变更，无论是修复还是其他类型的变更，都有可能意外地影响到代码其他部分的行为，不管是在同一个组件中，在同一系统的其他组件中，还是在其他系统中。变更包括环境的变化，例如操作系统或数据库管理系统的新版本。这种意外的影响叫做回归。回归测试包括运行测试以检测这种意外的影响。
确认测试和回归测试可以在所有测试级别开展。
特别是在迭代和增量开发生命周期（例如敏捷）中，新功能、已有特性的更改以及代码重构都会导致代码频繁变更，这也需要与变更相关的测试。由于系统的不断发展，确认和回归测试非常重要。这对于物联网系统尤其相关，其中的单独对象（例如设备）经常需要升级或替换。
回归测试套件需要运行多次，通常演化缓慢，因此回归测试非常适合进行自动化。这些测试的自动化应在项目早期就开始（见第6章）。
2.3.5 测试类型和测试级别
前述的任何测试类型都可以在任何测试级别开展。下面以银行应用程序为例，描述功能测试、非功能测试、白盒测试和与变更相关测试在所有测试级别中的应用。首先从功能测试开始：
• 对于组件测试，测试的设计是基于组件是如何计算利息的。
• 对于组件集成测试，测试的设计是基于用户界面捕获的帐户信息如何传递到业务逻辑中。
• 对于系统测试，测试的设计是基于账户持有人如何在其支票账户上申请信贷额度。
• 对于系统集成测试，测试的设计是基于系统如何使用外部微服务来检查账户持有人的信用评分。
• 对于验收测试，测试的设计是基于银行如何处理批准或拒绝信贷申请。
以下是非功能测试的例子：
• 对于组件测试，性能测试的设计旨在评估执行复杂的总利息计算所需的CPU周期的数量。
• 对于组件集成测试，安全测试的设计是针对从用户界面传递到业务逻辑的数据所产生的缓冲区溢出漏洞。
• 对于系统测试，移植性测试的设计旨在检查表示层是否适用于所有支持的浏览器和移动设备。
• 对于系统集成测试，可靠性测试的设计用来评估在信用评分微服务没有响应时系统的健壮性。
• 对于验收测试，易用性测试的设计旨在评估银行信贷处理界面对残疾人的无障碍性。
以下是白盒测试的例子：
• 对于组件测试，测试的设计是为所有进行财务计算的组件实现完整的语句和判定覆盖（见第4.3节）。
• 对于组件集成测试，测试的设计是为了检查浏览器接口中的每个屏幕如何将数据传递到下一个屏幕和业务逻辑。
• 对于系统测试，测试的设计是为了覆盖信用额度应用中出现的网页序列。
• 对于系统集成测试，测试的设计是为了检查所有可能的查询类型发送到信用评分微服务。
• 对于验收测试，测试的设计是为了覆盖银行对银行转账所支持的所有财务数据文件结构和价值范围。
最后，以下是与变更相关的测试的例子：
• 对于组件测试，为每个组件构建自动回归测试，并将其纳入持续集成框架。
• 对于组件集成测试，测试的设计是为了确认与接口相关的缺陷已得到修复，当修复已集成到代码库时。
• 对于系统测试，假如工作流上的任何屏幕发生变更，则相关工作流的所有测试都将重新执行。
• 对于系统集成测试，每天重新进行应用程序与信用评分微服务之间交互的测试，并作为该微服务持续部署的一部分。
• 对于验收测试，在验收测试中发现的缺陷得到修复后，所有先前失败的测试都将重新执行。
虽然本节提供了各个级别的不同测试类型的示例，但对于所有软件来说，没有必要让每个级别包括所有测试类型。但是，必须在每个级别上运行适用的测试类型，特别是特定测试类型发生的最早级别。