软件工程/测试简介

软件测试是指为了向利益相关者提供有关被测产品或服务的质量信息而进行的调查。 软件测试还提供了一个客观、独立的软件视图，使企业能够了解和理解软件实施的风险。测试技术包括但不限于以查找软件错误为目的执行程序或应用程序的过程。

软件测试也可以表述为验证和确认软件程序/应用程序/产品

1. 满足指导其设计和开发的业务和技术需求；
2. 按预期工作； 以及
3. 可以以相同的特性实现。

软件测试，根据所采用的测试方法，可以在开发过程中的任何时间进行。但是，大部分测试工作是在定义了需求并完成了编码过程之后进行的。因此，测试方法受采用软件开发方法的支配。

不同的软件开发模型将在开发过程的不同阶段集中测试工作。较新的开发模型，例如敏捷，通常采用测试驱动开发，并在软件到达正式测试团队之前将更多测试工作交给开发人员。在更传统的模型中，大多数测试执行发生在定义需求和完成编码过程之后。

概述

测试永远无法完全识别软件中的所有缺陷。相反，它提供了一种批评或比较，将产品的状态和行为与先验信息（即人们可能识别问题的原则或机制）进行比较。这些先验信息可能包括（但不限于）规范、合同、可比产品、同一产品的先前版本、对预期或预期目的的推断、用户或客户期望、相关标准、适用法律或其他标准。

每个软件产品都有一个目标受众。例如，视频游戏软件的受众与银行软件的受众完全不同。因此，当一个组织开发或投资软件产品时，它可以评估软件产品是否可以被其最终用户、目标受众、购买者和其他利益相关者接受。软件测试是试图进行这种评估的过程。

NIST 在 2002 年进行的一项研究报告称，软件错误每年给美国经济造成 595 亿美元的损失。如果进行更好的软件测试，可以避免超过三分之一的成本。

历史

调试与测试的分离最初是由 Glenford J. Myers 在 1979 年提出的。 虽然他关注的是破坏性测试（“成功的测试是能够发现错误的测试”），但它说明了软件工程界希望将基本开发活动（如调试）与验证活动分离。Dave Gelperin 和 William C. Hetzel 在 1988 年将软件测试的阶段和目标分为以下几个阶段：

• 直到 1956 年 - 以调试为导向
• 1957-1978 年 - 以演示为导向
• 1979-1982 年 - 以破坏为导向
• 1983-1987 年 - 以评估为导向
• 1988-2000 年 - 以预防为导向

软件测试主题

范围

测试的主要目的是检测软件故障，以便发现并纠正缺陷。这是一项非平凡的任务。测试不能确定产品在所有条件下都正常运行，只能确定它在特定条件下无法正常运行。 软件测试的范围通常包括检查代码以及在各种环境和条件下执行该代码，以及检查代码的各个方面：它是否按预期工作，以及它是否需要工作。在当前的软件开发文化中，测试组织可能与开发团队分离。测试团队成员有各种角色。从软件测试中获得的信息可用于纠正软件开发过程。

功能测试与非功能测试

功能测试是指验证代码特定操作或功能的活动。这些通常可以在代码需求文档中找到，尽管一些开发方法从用例或用户故事中工作。功能测试倾向于回答“用户可以这样做吗”或“这个特定功能是否有效”的问题。

非功能测试是指与特定功能或用户操作无关的软件方面，例如可扩展性或安全性。非功能测试倾向于回答诸如“一次可以登录多少人”之类的问题。

缺陷和故障

并非所有软件缺陷都是由编码错误引起的。昂贵缺陷的一个常见来源是需求差距，例如未识别的需求，导致程序设计人员遗漏错误。 需求差距的常见来源是非功能性需求，例如可测试性、可扩展性、可维护性、可用性、性能和安全性。

软件故障通过以下过程发生。程序员犯了一个错误（错误），导致软件源代码中出现缺陷（故障，错误）。如果执行了此缺陷，在某些情况下系统会产生错误的结果，从而导致故障。 并非所有缺陷都一定会导致故障。例如，死代码中的缺陷永远不会导致故障。当环境发生变化时，缺陷可能会变成故障。这些环境变化的示例包括在新的硬件平台上运行软件、源数据更改或与不同软件交互。 一个缺陷可能会导致各种各样的故障症状。

尽早发现故障

人们普遍认为，发现缺陷越早，修复缺陷的成本就越低。 下表显示了修复缺陷的成本，具体取决于发现缺陷的阶段。 例如，如果在发布后才发现需求中的问题，那么修复它的成本将是需求评审中发现它时的 10-100 倍。

修复缺陷的成本		检测时间
		需求	架构	构建	系统测试	发布后
引入时间	需求	1×	3×	5–10×	10×	10–100×
	架构	-	1×	10×	15×	25–100×
	构建	-	-	1×	10×	10–25×

兼容性

软件故障（真实或感知）的一个常见原因是与其他应用程序软件、操作系统（或操作系统版本，旧或新）或与原始目标环境有很大差异的目标环境缺乏兼容性（例如，打算在桌面上运行的终端或 GUI 应用程序现在需要成为 Web 应用程序，它必须在 Web 浏览器中呈现）。例如，在缺乏向后兼容性的情况下，这可能会发生，因为程序员只在目标环境的最新版本上开发和测试软件，而并非所有用户都可能运行该版本。这导致了一个意外的结果，即最新工作可能无法在目标环境的早期版本或在目标环境的早期版本能够使用的旧硬件上运行。有时可以通过主动地将操作系统功能抽象到单独的程序模块或库中来解决此类问题。

输入组合和前提条件

软件测试的一个非常基本的问题是，即使对于简单的产品，也不可能在所有输入和前提条件（初始状态）组合下进行测试。 这意味着软件产品中的缺陷数量可能非常大，并且在测试中很难找到很少发生的缺陷。更重要的是，质量的非功能维度（它应该是什么与它应该做什么）——可用性、可扩展性、性能、兼容性、可靠性——可能是高度主观的；对一个人来说足够有价值的东西，对另一个人来说可能是不可接受的。

静态测试与动态测试

软件测试有很多方法。审查、演练或检查被认为是静态测试，而使用给定的一组测试用例实际执行已编程代码被称为动态测试。静态测试可以（并且不幸的是在实践中经常被）省略。当程序本身首次使用时（这通常被认为是测试阶段的开始），就会进行动态测试。为了测试代码的特定部分（模块或离散函数），动态测试可以在程序 100% 完成之前开始。此方法的典型技术是使用存根/驱动程序或从调试器环境执行。例如，电子表格程序本质上是在很大程度上以交互方式（“动态”）进行测试的，结果在每次计算或文本操作后立即显示。

软件验证和确认

软件测试与验证和确认相关联：

• 验证：我们是否正确构建了软件？（即，它是否与规范相匹配）。
• 确认：我们是否构建了正确的软件？（即，这是客户想要的吗）。

术语验证和确认在业界通常互换使用；在行业中也常见到这两个术语被错误定义。根据 IEEE 软件工程术语标准词汇表

验证是评估系统或组件以确定给定开发阶段的产品是否满足该阶段开始时施加的条件的过程。

确认是评估系统或组件在开发过程期间或结束时以确定其是否满足指定要求的过程。

软件测试团队

软件测试可以由软件测试人员完成。直到 1980 年代，“软件测试人员”一词被普遍使用，但后来它也被视为一个独立的职业。关于软件测试的时期和不同的目标， 已经确立了不同的角色：经理、测试主管、测试设计师、测试人员、自动化开发人员和测试管理员。

软件质量保证 (SQA)

虽然有争议，但软件测试是软件质量保证 (SQA) 过程的一部分。 在 SQA 中，软件流程专家和审计人员关心的是软件开发流程，而不是像文档、代码和系统这样的工件。他们检查和改变软件工程流程本身，以减少最终交付的软件中的故障数量：所谓的缺陷率。

什么是“可接受的缺陷率”取决于软件的性质；飞行模拟器视频游戏比实际飞机的软件具有更高的缺陷容忍度。

虽然与 SQA 关系密切，但测试部门通常独立存在，并且一些公司可能没有 SQA 功能。

软件测试是一项旨在通过对比计算机程序的预期结果与其针对给定一组输入的实际结果来检测软件缺陷的任务。相比之下，QA（质量保证）是实施旨在从一开始就防止缺陷发生的政策和程序。

测试方法

黑盒方法

软件测试方法传统上分为白盒测试和黑盒测试。这两种方法用来描述测试工程师在设计测试用例时所持的观点。

白盒测试

白盒测试是指测试人员可以访问内部数据结构和算法，包括实现这些算法的代码。

白盒测试的类型

以下列出了几种白盒测试的类型：

• API 测试（应用程序编程接口） - 使用公共和私有 API 测试应用程序
• 代码覆盖率 - 创建测试以满足代码覆盖率的某些标准（例如，测试设计人员可以创建测试，以使程序中的所有语句至少执行一次）
• 故障注入方法 - 通过引入故障来测试代码路径，从而提高测试覆盖率
• 变异测试方法
• 静态测试 - 白盒测试包括所有静态测试

测试覆盖率

白盒测试方法还可以用来评估使用黑盒测试方法创建的测试套件的完整性。这使软件团队能够检查系统中很少测试的部分，并确保已测试了最重要的功能点。

两种常见的代码覆盖率形式是：

• 函数覆盖率，报告执行的函数
• 语句覆盖率，报告为完成测试执行的代码行数

它们都返回代码覆盖率指标，以百分比形式度量。

黑盒测试

黑盒测试将软件视为一个“黑盒子”，不了解内部实现。黑盒测试方法包括：等价类划分、边界值分析、全对测试、模糊测试、基于模型的测试、探索性测试和基于规格的测试。

基于规格的测试：基于规格的测试旨在根据适用的需求测试软件的功能。 因此，测试人员只向测试对象输入数据，并且只能看到输出。这种级别的测试通常需要提供完整的测试用例给测试人员，然后测试人员只需验证对于给定的输入，输出值（或行为）是否与测试用例中指定的预期值相同。

基于规格的测试是必要的，但不足以防范某些风险。

优点和缺点：黑盒测试人员与代码没有任何“关联”，测试人员的观点非常简单：代码必须有 bug。利用“问，就会得到”的原则，黑盒测试人员会发现程序员没有发现的 bug。另一方面，黑盒测试被称为“像在黑暗的迷宫中没有手电筒一样”，因为测试人员不知道正在测试的软件是如何构建的。因此，在某些情况下，（1）测试人员会编写许多测试用例来检查本可以只用一个测试用例测试的东西，和/或（2）某些后端部分根本没有得到测试。

因此，黑盒测试一方面具有“不相关意见”的优点，另一方面具有“盲目探索”的缺点。

灰盒测试

灰盒测试是黑盒测试和白盒测试的结合。灰盒测试（美国拼写：gray box testing）是指利用内部数据结构和算法来设计测试用例，但在用户或黑盒级别进行测试。操纵输入数据和格式化输出不属于灰盒，因为输入和输出明显地位于我们称为测试系统的“黑盒子”之外。当对两个不同开发人员编写的两个代码模块进行集成测试时，这种区别尤为重要，因为只有接口会暴露出来进行测试。但是，修改数据仓库属于灰盒，因为用户通常无法更改测试系统之外的数据。灰盒测试可能还包括逆向工程，以确定边界值或错误消息。

测试级别

测试通常根据它们在软件开发过程中的添加位置，或根据测试的具体程度进行分组。

单元测试

单元测试是指验证特定代码段功能的测试，通常在函数级别。在面向对象的环境中，这通常是在类级别，最小的单元测试包括构造函数和析构函数。

这些类型的测试通常由开发人员在编写代码时（白盒风格）编写，以确保特定函数按预期工作。一个函数可能有多个测试，以捕捉边界情况或代码中的其他分支。仅靠单元测试无法验证软件的功能，而是用来确保软件使用的构建块彼此独立地工作。

单元测试也称为组件测试。

集成测试

集成测试是指任何类型的软件测试，旨在验证组件之间的接口是否符合软件设计。软件组件可以以迭代的方式集成，也可以全部集成在一起（“大爆炸”）。通常，前者被认为是更好的做法，因为它允许更快速地定位和修复接口问题。

集成测试旨在暴露集成组件（模块）之间的接口和交互中的缺陷。逐步将对应于架构设计元素的更大组的测试过的软件组件集成在一起并进行测试，直到软件作为一个系统工作。

系统测试

系统测试测试一个完全集成的系统，以验证它是否满足其需求。

系统集成测试

系统集成测试验证系统是否已集成到系统需求中定义的任何外部或第三方系统。

回归测试

回归测试侧重于在发生重大代码更改后查找缺陷。具体来说，它试图发现软件回归或旧的 bug 再次出现。这种回归发生在先前正常工作的软件功能不再按预期工作时。通常，回归作为程序更改的意外后果而发生，当新开发的软件部分与先前存在的代码发生冲突时。回归测试的常用方法包括重新运行之前运行的测试，并检查之前修复的故障是否重新出现。测试的深度取决于发布过程中的阶段和添加功能的风险。它们可以是完整的，对于在发布后期添加的或被认为有风险的更改，也可以是浅层的，如果更改在发布早期或被认为风险较低，则仅包含每个功能的正向测试。

验收测试

验收测试可以指两种意思之一：

1. 冒烟测试是在将新版本引入主要测试流程之前（即在集成或回归测试之前）进行的一种验收测试。
2. 客户在自己的实验室环境中使用自己的硬件进行的验收测试称为用户验收测试 (UAT)。验收测试可以在开发的任何两个阶段之间进行，作为交接过程的一部分。

Alpha 测试

Alpha 测试是由潜在用户/客户或开发人员现场的独立测试团队进行的模拟或实际操作测试。Alpha 测试通常用于现成软件，作为内部验收测试的一种形式，在软件进入 Beta 测试之前进行。

Beta 测试

Beta 测试在 Alpha 测试之后进行，可以被视为一种外部用户验收测试。软件版本（称为 Beta 版本）会发布给编程团队之外的有限受众。软件会发布给多个群体，以便通过进一步测试确保产品几乎没有错误或缺陷。有时，Beta 版本会向公众开放，以将反馈范围扩大到尽可能多的未来用户。

非功能测试

存在一些专门的方法来测试软件的非功能方面。与功能测试（用于确定软件的正确操作，即与设计要求中定义的预期行为匹配）相比，非功能测试验证软件在接收无效或意外输入时也能正常运行。软件故障注入（以模糊测试的形式）是非功能测试的一个例子。非功能测试，尤其是针对软件的测试，旨在确定被测设备是否能够容忍无效或意外输入，从而确定输入验证例程和错误处理例程的健壮性。软件故障注入页面链接了各种商业非功能测试工具；还有一些可用的开源和免费软件工具可以执行非功能测试。

软件性能测试和负载测试

执行性能测试是为了确定系统或子系统在特定工作负载下的运行速度。它还可以用于验证和确认系统的其他质量属性，例如可扩展性、可靠性和资源使用情况。负载测试主要关注的是测试在特定负载下能否继续运行，无论负载是大量数据还是大量用户。这通常称为软件可扩展性。当负载测试作为非功能性活动执行时，相关的负载测试活动通常称为耐力测试。

容量测试是一种测试功能的方法。压力测试是一种测试可靠性的方法。负载测试是一种测试性能的方法。关于负载测试的具体目标，人们的意见并不一致。负载测试、性能测试、可靠性测试和容量测试等术语通常可以互换使用。

稳定性测试

稳定性测试检查软件是否可以在可接受的时间段内或超过可接受的时间段内持续良好地运行。这种非功能性软件测试活动通常称为负载（或耐力）测试。

可用性测试

可用性测试是用来检查用户界面是否易于使用和理解。它是一种针对应用程序使用的方式。

安全测试

安全测试对于处理机密数据的软件至关重要，可以防止黑客入侵系统。

国际化和本地化

软件的国际化和本地化的一般能力可以通过使用伪本地化来自动测试，而无需实际翻译。它将验证应用程序即使在翻译成新语言或针对新文化（例如不同的货币或时区）进行调整后也能正常运行。

实际翻译成人类语言也必须进行测试。可能的本地化故障包括

• 软件通常通过翻译脱节的字符串列表来进行本地化，翻译人员可能会为含糊的源字符串选择错误的翻译。
• 如果多个人翻译字符串，技术术语可能会不一致。
• 逐字翻译可能在目标语言中听起来不合适、生硬或过于技术化。
• 源语言中的未翻译消息可能在源代码中被硬编码。
• 一些消息可能在运行时自动创建，结果字符串可能不符合语法、功能不正确、误导性或令人困惑。
• 软件可能使用源语言键盘布局中没有功能的键盘快捷键，但用于在目标语言布局中键入字符。
• 软件可能不支持目标语言的字符编码。
• 源语言中合适的字体和字体大小在目标语言中可能不合适；例如，如果字体过小，CJK 字符可能变得无法阅读。
• 目标语言中的字符串可能比软件能够处理的字符串更长。这可能会导致用户无法看到部分字符串，或导致软件出现故障。
• 软件可能缺乏对双向文本读取或写入的适当支持。
• 软件可能显示带有未本地化的文本的图像。
• 本地化后的操作系统可能具有不同命名的系统配置文件和环境变量，以及不同的日期和货币格式。

为了避免这些和其他本地化问题，了解目标语言的测试人员必须运行程序，测试所有可能的翻译用例，以查看消息是否可读、在上下文中是否翻译正确，并且不会导致故障。

破坏性测试

破坏性测试试图导致软件或子系统出现故障，以测试其健壮性。

测试流程

传统的 CMMI 或瀑布模型开发

软件测试的常见做法是，在功能开发完成后，在交付给客户之前，由独立的测试人员小组进行测试。 这种做法通常会导致测试阶段被用作项目缓冲区，以弥补项目延迟，从而影响了用于测试的时间。

另一种做法是在项目开始的同时开始软件测试，并且这是一个持续的过程，直到项目结束。

敏捷或极限开发模型

相反，一些新兴的软件学科，如极限编程和敏捷软件开发运动，坚持“测试驱动软件开发”模型。在这个过程中，单元测试首先由软件工程师编写（在极限编程方法中通常使用结对编程）。当然，这些测试最初会失败；正如预期的那样。然后，随着代码的编写，它会逐步通过测试套件的更大部分。测试套件随着新故障条件和极端情况的发现而不断更新，并将它们与开发的任何回归测试集成在一起。单元测试与其余软件源代码一起维护，通常集成到构建过程中（将固有交互式测试降级为部分手动构建验收过程）。这个测试过程的最终目标是实现持续部署，即软件更新可以频繁地发布到公众。

一个示例测试周期

尽管组织之间存在差异，但测试通常有一个周期。 以下示例在采用瀑布开发模型的组织中很常见。

• 需求分析：测试应该从软件开发生命周期的需求阶段开始。在设计阶段，测试人员与开发人员一起确定设计的哪些方面是可测试的，以及这些测试的哪些参数有效。
• 测试计划：测试策略、测试计划、测试平台创建。由于测试期间将进行许多活动，因此需要一个计划。
• 测试开发：测试程序、测试场景、测试用例、测试数据集、用于测试软件的测试脚本。
• 测试执行：测试人员根据计划和测试文档执行软件，然后将发现的任何错误报告给开发团队。
• 测试报告：测试完成后，测试人员会生成指标并生成有关其测试工作以及测试的软件是否已准备好发布的最终报告。
• 测试结果分析：或缺陷分析，通常由开发团队与客户一起完成，以确定哪些缺陷应该处理、修复、拒绝（即发现软件工作正常）或延迟到以后处理。
• 缺陷重测：开发团队处理完缺陷后，测试团队会对其进行重测。又称解决测试。
• 回归测试：通常会针对每次新的、修改的或修复的软件集成构建一个小的测试程序，其中包含一组测试，以确保最新的交付没有破坏任何东西，并且整个软件产品仍在正常运行。
• 测试关闭：一旦测试满足退出标准，与项目相关的关键输出、经验教训、结果、日志、文档等活动将被存档，并用作未来项目的参考。

自动化测试

许多编程组越来越依赖自动化测试，特别是那些使用测试驱动开发的组。有许多框架可以编写测试，持续集成软件将在每次将代码签入版本控制系统时自动运行测试。

虽然自动化不能复制人类可以做的一切（以及他们想到的所有做事方式），但它对于回归测试非常有用。但是，它确实需要一个完善的测试套件，以便真正有用。

测试工具

程序测试和故障检测可以通过测试工具和调试器得到很大程度的帮助。测试/调试工具包括以下功能

• 程序监视器，允许完全或部分监视程序代码，包括
  • 指令集模拟器，允许完全指令级别监视和跟踪设施
  • 程序动画，允许逐步执行并在源代码级别或机器代码中设置条件断点
  • 代码覆盖率报告
• 格式化转储或符号调试，允许检查程序变量以出错或在选定的点
• 自动化功能 GUI 测试工具用于通过 GUI 重复系统级测试
• 基准测试，允许进行运行时性能比较
• 性能分析（或性能分析工具）可以帮助突出显示热点和资源使用情况

其中一些功能可能已集成到集成开发环境 (IDE) 中。

• 回归测试技术是使用一组标准测试，这些测试涵盖现有的功能，并产生持久的表格数据，并使用 diffkit 等工具将更改前数据与更改后数据进行比较，其中不应该存在差异。检测到的差异表明意外的功能更改或“回归”。

软件测试中的度量

通常，质量仅限于诸如正确性、完整性、安全性等主题，但也可能包括 ISO 标准 ISO/IEC 9126 中描述的更技术性要求，例如能力、可靠性、效率、可移植性、可维护性、兼容性和可用性。

有许多常用的软件度量，通常称为指标，用于帮助确定软件的状态或测试的充分性。

测试工件

软件测试过程可以产生几个工件。

测试计划

测试规范称为测试计划。开发人员清楚地知道将执行哪些测试计划，并将此信息提供给管理层和开发人员。目的是使他们在开发代码或进行额外更改时更加谨慎。一些公司拥有更高层次的文档，称为测试策略。

可追溯性矩阵

可追溯性矩阵是一个表，它将需求或设计文档与测试文档相关联。它用于在源文档更改时更改测试，或验证测试结果是否正确。

测试用例

测试用例通常包含唯一标识符、来自设计规范的需求引用、前提条件、事件、一系列要遵循的步骤（也称为操作）、输入、输出、预期结果和实际结果。临床定义的测试用例是输入和预期结果。 这可以像“对于条件 x，您的推导结果为 y”一样务实，而其他测试用例则更详细地描述了输入场景以及可能预期的结果。它有时可能是一系列步骤（但步骤通常包含在一个单独的测试过程中，该过程可以经济地针对多个测试用例进行练习），但只有一个预期结果或预期结果。可选字段是测试用例 ID、测试步骤或执行顺序号、相关需求、深度、测试类别、作者以及测试是否可自动化以及是否已自动化的复选框。较大的测试用例还可能包含先决条件或步骤，以及描述。测试用例还应包含一个用于放置实际结果的位置。这些步骤可以存储在文字处理文档、电子表格、数据库或其他常用存储库中。在数据库系统中，您还可以查看以前的测试结果、谁生成了这些结果以及用于生成这些结果的系统配置。这些过去的结果通常存储在单独的表中。

测试脚本

测试脚本是测试用例、测试程序和测试数据的组合。最初，该术语源自自动化回归测试工具创建的工作产品的产物。如今，测试脚本可以是手动的、自动化的或两者的结合。

测试套件

测试用例集合最常见的术语是测试套件。测试套件通常还包含每个测试用例集合的更详细说明或目标。它肯定包含一个部分，测试人员在其中识别测试期间使用的系统配置。一组测试用例还可能包含先决条件或步骤，以及对后续测试的描述。

测试数据

在大多数情况下，使用多组值或数据来测试特定功能的相同功能。所有测试值和可变环境组件都收集在单独的文件中并存储为测试数据。将此数据提供给客户以及产品或项目也很有用。

测试平台

软件、工具、数据输入和输出示例以及配置统称为测试平台。

认证

现有多个认证项目，旨在支持软件测试人员和质量保证专家的职业发展。目前没有任何认证要求申请者证明他们有测试软件的能力。也没有任何认证是基于广泛接受的知识体系的。这导致一些人宣称测试领域还没有准备好进行认证。 认证本身不能衡量一个人的生产力、技能或实践知识，也不能保证他们作为测试人员的能力或专业性。

软件测试认证类型

• 考试型：需要通过的正式考试；也可以通过自学学习[例如，ISTQB 或 QAI]
• 教育型：讲师主导的课程，每门课程都需要通过[例如，国际软件测试学院 (IIST)]。

测试认证

• 质量保证研究所 (QAI) 提供的软件测试认证助理 (CAST)
• 国际软件测试学院提供的 CATe
• 质量保证研究所 (QAI) 提供的软件测试认证经理 (CMST)
• 质量保证研究所 (QAI) 提供的认证软件测试人员 (CSTE)
• 国际软件测试学院提供的认证软件测试专业人士 (CSTP)
• K. J. Ross & Associates提供的 CSTP (TM)（澳大利亚版）
• 信息系统考试委员会提供的 ISEB
• 国际软件测试资格委员会提供的 ISTQB 认证测试员，基础级 (CTFL)
• 国际软件测试资格委员会提供的 ISTQB 认证测试员，高级级 (CTAL)
• 信息科学考试研究院提供的 TMPF TMap Next 基础级
• 信息科学考试研究院提供的 TMPA TMap Next 高级级

质量保证认证

• 质量保证研究所 (QAI) 提供的 CMSQ。
• 质量保证研究所 (QAI) 提供的 CSQA
• 美国质量学会 (ASQ) 提供的 CSQE
• 美国质量学会 (ASQ) 提供的 CQIA

争议

软件测试的一些主要争议包括

什么是负责任的软件测试？

"情境驱动"测试学派的成员认为，测试没有"最佳实践"，而是测试是一组技能，使测试人员能够选择或发明测试实践来适应每种独特的情况。

敏捷 vs. 传统

测试人员应该学习在不确定性和持续变化的环境中工作，还是应该以流程"成熟度"为目标？自 2006 年以来，敏捷测试运动在商业领域越来越受欢迎，而政府和军事软件供应商使用这种方法，但也使用传统的最后测试模型（例如在瀑布模型中）。

探索性测试 vs. 脚本测试

应该在执行测试时同时设计测试，还是应该事先设计测试？

手动测试 vs. 自动化测试

一些作者认为，测试自动化相对于其价值而言过于昂贵，因此应该谨慎使用。 更具体地说，测试驱动开发指出，开发人员应该在编写功能代码之前编写 XUnit 类型的单元测试。然后可以将测试视为捕获和实现需求的一种方式。

软件设计 vs. 软件实现

应该只在最后进行测试，还是在整个过程中进行测试？

谁来监督监督者？

这个想法是，任何形式的观察都是一种互动——测试的行为也会影响被测试的对象。

外部链接

• 软件测试工具和产品 在 Curlie
• "让软件变得更好的软件" Economist.com
• 自动化的软件测试指标，包括手动测试指标