测试的主题是广泛的。从外面看起来可能很简单，但事实并非如此。例如，人们可以将测试定义为检查软件是否适合其目的。
1. 单元测试
单元测试是一门有据可查的学科：无论使用哪种语言，都已经出版了大量关于该主题的书籍。他们通常重复相同的事情。
[… ] 单元测试是一种软件测试方法，通过该方法测试各个源代码单元 [… ] 以确定它们是否适合使用。
—维基百科
唯一有争议的点是什么构成了一个单元：在OOP 中，有些人认为它是类；其他人认为它是一个模块， 即一组协作类。
2. 集成测试
虽然单元测试的定义和理解相当好，但相比之下，集成测试似乎是处女地。
集成测试 [… ] 是软件测试的阶段，在该阶段中，各个软件模块被组合在一起并作为一个组进行测试。
—维基百科
集成测试背后的核心概念之一是被测系统。在单元测试中，SUT是单元（即类或模块，如上所述）。在集成测试中，需要为每个测试定义 SUT：它可以小到两个协作的单元，大到整个系统。
关于单元测试与集成测试存在激烈的争论。有的只考虑前者，有的只考虑后者。
3. 端到端测试
在大多数应用程序都是人对机器的时候，端到端测试意味着测试从用户界面到数据库的流程，然后再返回。由于 Web 应用程序几乎无处不在，这涉及到浏览器。因此，E2E测试与之前的方法有很大不同。自动化用户与浏览器的交互并非易事，即使可用工具随着时间的推移而改进。
E2E 测试中最大的问题来自UI层的脆弱性。现代架构清晰地分为基于 JavaScript 的前端和REST后端。为了应对提到的脆弱性，它有助于首先通过集成测试测试REST 层。
使用E2E 测试，有一个从单元测试到集成测试的完整连续体。
4.系统测试
随着时间的推移，越来越多的应用程序针对机器对机器交互而不是H2M交互。端到端测试之于 H2M 就像系统测试之于M2M。
好处是不涉及浏览器。因此，可以重用来自单元测试和集成测试的相同自动化技术。
5. 性能测试
以前的大多数方法都侧重于测试功能需求。很容易忘记软件组件的适用性包括功能需求和非功能需求。性能作为NFR 的一部分，以及可靠性等。
请注意，性能测试中的SUT可以是整个系统，也可以只是被视为关键的子组件。然而，在这种情况下，断言每个单独组件的性能可能不足以保证整个系统的性能。
[… ] 性能测试通常是一种测试实践，用于确定系统在特定工作负载下的响应能力和稳定性方面的表现。
—维基百科
根据我的经验，术语性能测试被过度使用，而且过于笼统。它有很多方面：这里是最常见的方面。
6. 负载测试
负载测试通常是人们谈论性能测试时隐含的意思。在这种情况下，可以为测试设置不同的参数。这些参数模拟来自生产环境的代表性负载。在现实中，大多数组织无法提供生产负载的质量样本，而负载是推断出来的。
例如，在电子商务环境中，测试参数将包括：
- 不同类型的请求：浏览目录、查看不同的产品、将它们添加到购物车、结账、付款等。
- 它们之间的重新分配，例如70% 的浏览、20% 的查看、6% 的购物车操作、3% 的结帐和 1% 的付款
- 并发请求数
- 并发用户会话的数量，以及它们如何在请求之间分布
- 等等。
7. 耐力测试
在常规负载测试中，测试运行直到它们完成执行。目标是检查系统在特定负载下的行为是否符合人们的预期。
在耐久性测试也被称为浸泡测试，目的是检查有系统的行为演变随着时间的。相比之下，这些测试的持续时间更多是几天，甚至几周。
耐力测试涉及在连续可用性期间测试具有典型生产负载的系统，以验证生产使用下的系统行为。
—维基百科
8. 压力测试
压力测试是对系统进行测试，直到它崩溃。负荷逐渐增加。压力测试的目标是了解系统的性能限制。
压力测试（有时称为酷刑测试）是一种有意进行的密集或彻底测试，用于确定给定系统、关键基础设施或实体的稳定性。它涉及超出正常操作能力的测试，通常会达到一个临界点，以观察结果。
—维基百科
此类实验的结论是：在x请求负载/秒内，一y小部分请求返回5xx错误代码。
9. 混沌测试
混沌测试，也称为混沌工程，是一种随机移除系统组件以了解其崩溃方式并检查其在胁迫下的整体弹性的实践。
混沌工程是在生产中对软件系统进行试验的学科，目的是建立对系统承受动荡和意外情况的能力的信心。
—维基百科
混沌测试的定义属性是它通常在生产环境中执行。这并不意味着在其他环境中进行的实验不能带来可操作的反馈，恰恰相反。但是，每个人都在生产中遇到过以前环境中从未发生过的问题。根本原因可能是架构略有不同、数据数据不同、负载更高等：最终，唯一需要经过实战测试和防弹的环境是生产环境。
虽然起初违反直觉，但这个想法现在已经在成熟的组织中根深蒂固，这些组织非常重视系统的弹性。
10. 安全测试
就像性能测试是一个过于宽泛的术语一样，安全测试涵盖了许多不同的领域。最著名的安全测试形式是渗透测试。
渗透测试 [...] 是对计算机系统进行的授权模拟网络攻击，用于评估系统的安全性。
执行测试是为了识别两个弱点 [...]，包括未经授权方访问系统功能和数据的可能性，以及优势，从而能够完成完整的风险评估。
—维基百科
11.突变变异测试
大多数形式的测试侧重于软件部分或整个系统的适用性。Mutation Testing的独特之处在于它的目标是对单元测试进行后见之明，更具体地说是在误导性代码覆盖率指标上。
变异测试 [… ] 用于设计新的软件测试和评估现有软件测试的质量。
—维基百科
12. 探索性测试
许多测试方法侧重于回归错误，即出现在以前工作的软件中的错误。为此，测试是自动化的：它们在每次构建时运行。如果之前运行的测试失败，构建也会失败。
探索性测试的目标是捕捉测试工具无法触及的错误。为了实现这一点，人们以新的和意想不到的方式与系统交互。
探索性测试是一种软件测试方法，简明地描述为同步学习、测试设计和测试执行。
—维基百科
由于其探索性，此过程是手动的。我的经验告诉我，探索性测试被低估了。很遗憾，因为我亲眼目睹了测试人员在系统中发现了以前自动化步骤没有发现的问题。
尽管具有手动性质，探索性测试并不是要到处点击。这是一种工程实践，需要纪律和严格的方法来记录导致问题的步骤。最好的测试人员还能够：
- 隔离问题
- 重现导致它的步骤
- 以一种可以减轻需要修复错误的开发人员的工作的方式来创建问题
13. 用户验收测试
大多数形式的测试由技术人员执行：开发人员、自动化测试人员等。相反，验收测试由非技术人员执行，例如业务分析师或最终用户。顾名思义，目标是评估他们是否接受适合其使用的软件。
用户验收测试包括验证解决方案是否适合用户的过程。
—维基百科