软件开发是一门学科，包括多种手段来确保质量。每一个开发人员都应该对这个领域的可能性有一个清晰的认识。本文收集了有关这一主题的常识，并提供了一个最新的图片，以便为每一种情况选择最合适的方法和工具。
如何对测试的类型进行分类
最早和最有名的关于测试主题的尝试之一是Brian Marick的《敏捷测试矩阵》。在这组文章中，作者提供了一个阅读钥匙，以涵义不同的测试方法：
- Y轴跨越了面向技术的测试和面向业务的测试之间的长度。
- X轴从支持开发到对产品进行批评。
X轴：开发支持和产品评论
考虑一下矩阵中从左到右的划分。 在左边，是支持编程行为的工具和实践。它们的目的是帮助开发人员建立符合质量和功能要求的软件组件。一些例子是静态测试，单元测试，和集成测试。
在右边，有一些测试把整个软件解决方案放在镜头下，寻找缺陷。其目的是对产品进行批评，发现潜在的问题或遗漏。在这个类别中，有各种非功能测试，可以评估性能和验证安全问题。
Y轴：技术和商业
在Y轴上，我们可以将测试安排为面向业务或面向技术的测试。 第一个代表测试，证明解决方案对具体业务案例的适用性。它描述了商业专家感兴趣的功能，没有技术术语，只有简单的语言和领域概念。
比方说，你正在为网上银行开发软件。在这种情况下，一个面向业务的测试将检查。"鉴于账户余额为1000美元。当账户持有人进行200美元的电汇时。那么账户余额应该是800美元"。
在另一边，你可以发现面向技术的测试，因为它们讲的是程序员的语言。对于业务专家来说，这种关注没有那么有趣，但对于实现一个强大的解决方案来说同样重要。继续前面的例子："不同的浏览器以不同的方式实现JavaScript，所以我们测试我们的电汇功能是否在最重要的浏览器上工作。"
一个更新的测试矩阵
随着时间的推移，新的测试实践和工具被证明是有效的。在下面的段落中，我们将研究四个象限的最新观点，描述使每个测试方法具有吸引力的特征。
支持开发，面向技术的象限
从左下角象限开始，我们有支持代码编写行为的测试。这些类型的测试被开发人员用作构建工作软件的指南，同时关注质量和技术细节。
静态测试
在地图的这一部分，我们发现了静态测试，这是一个总括术语，指的是在不实际执行代码的情况下进行的所有测试。这里有一些最相关的：
- 提示：这个术语指的是检查源代码中的程序和风格错误的过程。皮特（或林特）是一个能使皮特化的程序。大多数语言都有提示器。一些著名的提示器是JSLint、CSSLint、Pylint。
- 类型检查：在编程语言的世界里，我们有强类型和弱类型系统。当类型系统很强时，编译器会在出现错别字和错误时向你发出警告。但是当类型系统很弱时，比如在JavaScript中，一些错误就很难被发现。在这种情况下，像Flow这样好的类型检查库可以派上用场。
- 静态代码分析：最后，还有其他一些工具，通过分析代码并给出有用的见解，帮助确保代码质量。像SonarQube、PhpMetrics或SpotBugs这样的套件可以提供诸如循环复杂性、漏洞报告和关于技术债务的反馈等度量。
单元测试
单元测试 ，通常是由开发人员编写和运行的自动化测试。在面向对象编程中，一个单元通常是一个完整的类或一个单一的方法。用汽车做比喻，盘式制动器就是一个单元。一个单元可以是一个完整的模块，但更常见的是一个独立的功能或过程。
测试驱动开发（TDD）方法邀请开发人员在实际实现之前编写单元测试，用它们作为编码的指导。开发人员习惯于在测试框架的支持下完成这项工作，如Java的JUnit或JavaScript的Jest。
集成测试
在单元测试之上的一个层次，是集成测试。单元测试是关于编写所需功能的良好实现，而集成测试是关于验证一组单元（组件）的合作。 回顾前面的比喻，一个集成测试检查汽车的整个制动系统。
集成测试可以通过使用单元测试的相同测试框架来编写。有一些专门的工具可以帮助应用测试替身技术，例如Mockito或Mocha，或者其他一些解决方案来测试单元与数据库的集成，如DBUnit，或与REST APIS，如REST-Assured。
系统测试
在系统测试中，我们更上一层楼，测试各组件的交互。最后，回到我们的比喻，是时候把整辆车放在测试台上，检查重要的东西是否在工作，如发动机和变速器。
系统测试评估系统是否符合产品的要求；此外，它寻找部件组装和整个系统中的缺陷。这方面的一个著名工具是机器人框架。
荣誉称号：突变测试
突变测试是一种迷人的技术。突变 "是对代码的一部分进行有目的的修改，以验证是否有测试能够捕获产生的错误。如果一个突变能在测试中存活下来，你就知道有一个漏洞。在汽车的例子中，这就像断开大灯电缆，看看仪表盘上是否显示出相应的警告灯。在这个领域，PITest是一个卓越的工具，同时还有StrykerJS。
支持开发，面向业务的象限
在我们的矩阵中往上走。对于这些类型的测试，我们转移到面向业务的区域，持有所有的测试，让利益相关者和开发人员检查当前对业务规则的理解。在开发汽车时，这是测试司机开始在赛道上将其推向极限的地方。
验收测试
验收测试是业务和开发团队内部的一种合同。例如，当考虑完成一个功能时，至少要有一个验收测试来证明它尊重业务规则和行为正确，这是非常有用的。验收测试通常是用户故事的一部分。
这可以作为我们的汽车比喻的一个例子："以一辆刚出厂的汽车为例，在沥青状况良好的道路上，从100公里/小时到零的制动距离必须小于100米。"
验收测试在意义上是不同的，但在形式上并不一样。我们可以使用前述的一些测试框架来组成它们，或者也许可以利用行为驱动开发（BDD）方法和Cucumber等工具来更好地表达意图，并促进开发人员和业务专家之间的共同语言。
端到端测试
端到端测试（E2E）发生在我们尝试我们的软件解决方案，看看主要功能是否按预期工作，即看看 "所有的电缆是否连接"。用这种方法，我们可以看到所有的功能需求是否得到满足。 继续这个比喻，我们把新车进行短暂的试驾，以确保在交付给汽车经销商之前一切都按预期工作。
前面提到的许多工具都适用于放置这类测试；在构建Web应用时，Selenium、Cypress或Postman可以派上用场。
烟雾测试
烟雾测试是E2E测试的一个子集，寻找可能出现的障碍。其目的不是进行详尽的测试，而是验证系统的基本功能是否正常。这类测试通常是自动化的，但在一些复杂的解决方案中，需要人工干预。
荣誉称号：合同测试
契约测试是一种方法，用于确保两个独立的系统（如两个微服务）是兼容的，并能够相互通信。它捕捉每个服务之间交换的交互，将其存储在合约中，然后可以用来验证双方是否遵守合约。 这种测试形式与其他具有相同目标的方法的区别在于，每个系统可以独立于其他系统进行测试。合同是由代码本身生成的，这意味着它总是最新的。这方面的主要工具是Pact。
批评产品，面向业务的象限
向右移动，我们有一系列的测试，旨在验证我们不容易自动化的东西，如网站的可访问性和可用性或不希望出现的行为。
技术演示
如果你了解Scrum和它的活动，你已经知道了冲刺回顾。或者你熟悉用户验收测试（UAT）。在工作中演示软件（当然还有收集反馈）是你可以做的一件好事，可以将错误的风险降到最低。 技术演示主要是为了确认预期的行为，通过像用户那样使用软件解决方案。这当然是一种手动活动。这就像邀请潜在的买家进行试驾，看看你的车是否是他们要找的车。
探索性测试
演示是确认现有的路径，而探索性测试是寻找新的路径。 这是QA工程师在发现 "非预期功能 "的能力方面的闪光点。
探索性测试也经常由项目或需求经理进行。为了做一个比较，汽车行业中最著名的探索性测试之一是麋鹿测试，它决定了某辆车在躲避意外障碍物方面的能力。
可用性测试
可用性测试包括观察一个人对产品的操作。一般来说，有一个主持人要求这个人执行开放的任务（如："你在这个电子商务网站上寻找一个礼物：你会怎么做？"）或封闭的任务（如："使用导航菜单来查看大学的学位课程"）。
另一个独特的元素是研究人员在相邻的观察室里，分析受试者的行为。这些类型的测试的目的是为了收集反馈，以改进解决方案。
α和β测试
大爆炸式的交付可能是有风险的。一个缓解的策略是首先将新的或修改后的功能提供给一个严格的圈子，这些人愿意接受故障并乐意提供反馈。
这基本上是alpha和beta测试的目的，即使两者之间有一些细微的差别：在alpha阶段，你征集为你的公司工作的员工。而β测试是对公司以外的人开放的，他们构成了一个值得信赖的客户圈子。
另一件重要的事情是，在阿尔法阶段，你通常使用测试环境，更多地关注功能而不是其他技术方面，如性能或可靠性；而在测试阶段，你在实际环境中测试最终的解决方案。当测试阶段结束时，该解决方案就可以向所有客户开放了。
荣誉奖、可访问性、国际化、本地化
一个全球性的解决方案不能忽视国际化、本地化和无障碍性这样的主题。无障碍性 （a11y）是指使产品能被尽可能多的人使用的做法。我们传统上认为这是关于残疾人的，但使网站更容易访问的做法也有利于其他群体，如那些使用移动设备或网络连接缓慢的人。
在网络领域，标准是《网络内容可访问性指南》（WCAG）。虽然有一些工具（例如，验证是否为读屏器正确使用可用的HMTL标签），但这些测试大多是由人类完成的。例如，在网络应用中，基本测试包括在纯键盘模式下的浏览或在语音合成系统的帮助下的盲目浏览。
国际化（i18n）是设计一个软件应用程序的过程，以便它可以适应各种语言和地区，而不需要改变任何代码。这是编码、日期格式或文本方向等主题的归宿。
本地化（l10n）是指通过添加本地特定的组件，使应用程序能够适应特定地区或地方的文化、语言和其他要求的过程。这不仅是翻译文字，也是为了满足当地的法规和习惯。
批评产品，面向技术的象限
最后一个象限将所有探索软件解决方案的非功能方面的测试分组，如复原力和安全性。其重点是确保整个系统的准备就绪。
非功能测试
这一组测试的目的是验证软件应用的非功能方面（性能、可用性、可靠性，等等）。功能方面，如业务规则和功能，已经在其他地方测试过了：重点是它在所有可能情况下的可用性。
下面是对最相关的测试类型的分类。
- 弹性测试：是指观察应用程序在压力下如何行动的测试技术。它是为了确保产品在混乱的条件下执行的能力，而不损失核心功能或数据。这可以确保在发生不可预见的、不可控的事件后迅速恢复。今天，有一些软件解决方案非常庞大，你只能在生产中测试它们。在这种情况下，像混沌工程这样的技术显示了事情出错时的情况。Netflix是这个领域的先锋，它有著名的混沌猴子工具。
- 性能测试：旨在测试我们的应用程序及其组件的可持续性。人们和工具将软件推向极限，以发现和定义可接受的负载。压力测试或负载测试是对这些活动进行分类的其他常见方式。JMeter是这个领域的一个成熟的工具，但像Taurus这样的新工具正在获得势头。
- 安全测试：在这个术语下，我们有所有你可以做的测试，以确保你的软件解决方案解决已知的安全隐患。软件开发领域的专家们知道，没有 "100%安全 "的软件。然而，这种测试技术定义了 "足够安全 "对我们的解决方案意味着什么。 在这个领域最大的支持者是OWASP基金会。在该基金会的网站上，有一个精心策划的应用程序安全和漏洞扫描工具的列表。
总结
这篇文章对软件开发领域的重要测试类别做了一些说明。关于采用哪种测试方法并没有精确的配方，这在很大程度上取决于你的软件的背景。建议的图表设计有助于理解哪些测试领域需要被覆盖，让开发人员根据他们的经验在特定情况下找到正确的平衡。
用最近的这些文章来加深你的测试功夫：
