软件测试在软件开发全流程中占据重要地位，协助生产过程降本增效。

同时软件测试又是一个复杂且难懂的话题。

在本文中，我将介绍软件测试的主要环节，以及这些环节如何协助开发。

目录

• 什么是软件测试?
• 软件测试分类
• 功能测试类型
• 软件测试原则
• 为什么需要软件测试?
• 总结

什么是软件测试？

软件测试就是确保软件或者应用程序正常运行的过程，测试方法种类繁多，方法不同需求也不同。

例如，单元测试需要编写测试用例验证代码是否存在缺陷；β测试需要回测历史版本确保既有功能的正常使用。

软件测试是软件开发生命周期的重要组成部分，协助提升开发效率和产品性能，打造符合要求的优质产品。

此外，测试还能降低缺陷率，降低开发成本投入，缩短开发时间。

软件测试分类

软件测试主要有两类：

功能测试

功能测试是验证系统是否按照客户需求或者规范运行。

这类测试旨在验证每个功能正确输入后会有对应的正确输出。

例如，编写一条测试创建用户的测试用例，用例中包含邮箱地址、姓名和密码等格式正确的输入内容，验证成功创建用户。

功能测试就是根据功能需求，模拟业务场景，验证功能的正常使用。

非功能测试

非功能测试是验证终端用户的使用体验，如压力测试下的性能表现与稳定性，这对用户体验至关重要。

用户可能无法直观感知到非功能测试发现的代码问题，但也是系统中的重点问题。

非功能测试就是测试加压后软件会如何响应。

本文中，我们将聚焦阐述功能测试的内容。

功能测试类型

功能测试有很多类型，每一个都对应具体的目标，下文会简要介绍所有的类型。

单元测试

最小可测试代码称为一个单元，单元测试是验证每一个可独立运行的代码块如何运行及运行的准确性。

目的是测试软件中的每一单元准确运行出所需要的结果。单元测试由开发人员在软件开发过程中自主完成。

单元测试可以发现独立代码模块内可能存在的各种缺陷。独立的函数、方法、过程、模块及对象都可作为一个单元。

集成测试

软件测试的第二阶段，即完成单元测试后，需要进行集成测试，验证软件中的各个组件或者功能可以准确地联动运行。

测试独立单元或者组件组合成的完整功能，主要关注各单元或组件的交互中是否存在缺陷。

系统测试

系统测试是测试整个完整的系统，旨在验证软件是否按照具体需求运行。

系统测试时，质量保证（QA）团队在真实的集成环境中验证APP或软件的每个部分运行是否正常。

验收测试

验收测试是测试软件是否已达到可验收的标准，验证已完成的功能是否符合业务需求并且评估是否可交付。

在正式环境测试系统功能是否符合用户的需求、要求以及业务流程，目的是判断软件是否满足验收标准，用户或者客户是否愿意使用。

验收测试是在完成系统测试后，在产品发布之前的测试步骤，是软件测试的最后一项流程。

回归测试

回归测试是软件增加新功能后，验证现有功能按照既定需求运行。当相关代码产生变动，如在项目中新增一个模块后，需要回归测试。

回归测试使用所有已执行的历史测试用例再次测试，验证现有功能依然能够准确运行。

α测试与β测试

α测试是验收测试的一个环节，属于交付客户前的初次验证测试，通常由QA（质量保证）测试人员或者团队在公司内部完成。

β测试是验证测试的第二环节，将会在外部公网完成测试。

这一阶段将会把β测试版本发到真实生产环境，仅限部分特定人员可以点击查看。例如，freeCodeCamp的数据课程点击这里可以获取。

软件测试原则

每个技术工作都有原则，这些条例将会有利于你打造更好的软件产品，减少缺陷的产生。

下面列出的几个写测试用例时需要遵循的软件测试原则：

测试是证明存在缺陷，而不是确保没有缺陷

软件测试的目的是指出软件的缺陷，尽量减少缺陷存在的可能性。

各种类型的测试都无法保证软件不再存在缺陷，只是协助开发人员知道并定位缺陷，减少缺陷的保有量。

无法做到穷举测试

穷举测试测试是指列出所有可能的输入或者前提条件测试软件

这个方法是不现实的，因为所有的测试用例都是以软件是正确的为基础，验证每一条测试用例的输入条件都会得到正确的输出结果。如果想要测试软件的所有内容，需要耗费大量的时间与精力，实用性并不高。

尽早介入测试

尽早测试有利于避免小缺陷（bug），而且在软件开发生命周期的早期找到的缺陷，往往修复缺陷的成本比较低，所以测试应该从软件项目伊始就介入。

缺陷聚集效应

缺陷聚集效应是指大部分的缺陷集中在应用程序或者软件的几个功能中。如果找到了问题集中出现的功能模块，你可以重点测试该模块。

在测试时需要牢记二八法则：80%的缺陷往往集中于20%的功能模块。

警惕杀虫剂悖论

该原则的理论背景是在农作物上使用的杀虫剂越多时，农作物上的害虫抗药性就会越强，最终杀虫剂就会失效。

同理，如果一直使用既有的测试用例，发现的新缺陷只会越来越少，所以需要不断地更新测试用例并使用最新的测试用例验证软件。

测试与需求文档高度关联

测试的基础是关联各类文档，根据功能需求文档验证测试软件的功能是否符合需求。

测试时需要根据软件的功能目的选择测试方法，因为不同的应用程序会有不同的功能，所以并不是所有的软件共用同一套测试方法。

例如，当测试电商网站的APP时，功能侧重商品展示，所以需要重点测试终端用户的商品页展示；当测试接口时，测试的重点是服务端被请求时，接口的响应返回情况。

这两种情况肯定不能使用相同的测试用例，这就是测试与需求文档高度关联。

无错误谬论

一款基本完美无缺陷但不符合用户需求的软件，对终端用户来说，是不适用的。

所以，测试时要明确一点，基本完美无缺陷的软件需要匹配用户需求，测试用例不仅是测试代码的问题，而且应该是以用户使用习惯或者潜在使用可能为导向测试软件，这在测试环节中非常重要的原则，

而满足这个原则的最佳方式就是进行β测试。

为什么需要软件测试？

软件测试既可以确保软件无缺陷以及达到用户需求，还有另外的优势。

优化安全性能

网络安全是在构建软件时是非常重要的环节，因为黑客可以恶意攻击存在安全漏洞的软件窃取相关信息，用户信息就可能泄露。

经历过测试的产品会让终端用户觉得这是一款安全可靠的产品，他们的信息不会被泄露。所以用户会更倾向于通过软件测试的无安全漏洞问题的软件。

改善产品质量

在构建软件产品代码阶段就引入测试用例和其他测试方法，找到潜在问题，打造无缺陷、低风险、长期稳定运行的软件或者产品。

而且在测试时才会知道产品质量如何，通过测试可以发现非稳定复现的缺陷或者痛点问题，然后修复这些缺陷，在发布正式环境前尽可能打造一个最佳的产品版本。

提高客户满意度

这就像你下载一个新APP后，结果使用时出现了报错，没有办法继续使用，最终可能导致你不会再使用这个APP。

这就是软件测试重要性的实际体现，软件发布正式环境交付用户使用前，通过测试可以发现类似的缺陷，同时也是给开发人员一次机会避免出现这样的问题。

早期开发阶段引入软件测试，也是给用户展示你重视用户体验的一种方式，有助于建立稳定长久的客户关系。

节省成本

软件测试可以帮助你节省很多成本，开发环节的每个阶段都包含了许多事情，比如多团队间的明确沟通与合作，每一步都会有非常长的代办清单，随时都有可能出现混乱。

如果在产品周期内出现了这样的问题是非常棘手的，因为需要你同时处理人员关系，重新分配任务并且定位问题的本质。

同时，在修复问题时用户是没有办法使用APP的，不但违背了产品初衷而且还造成了不良的用户体验。软件测试可以解决这一系列的问题，并且持续测试的话，用户可以体验到最佳的产品。

总结

总的来说，软件测试是开发环节中非常重要的一环，不仅可以让团队避免很多问题，还可以让用户使用到体验感良好且没有缺陷的产品。

如果你对软件测试感兴趣的话，可以点击这里查看freeCodecamp的质量保证课程学习更多的质量保证（QA）内容。QA人员就是专注测试软件或者APP缺陷的科技工作者。

每个重要的应用都应该配备一些测试套件，以验证其稳定性和性能。

有许多类型的测试，每种测试都有自己的目的，涵盖应用的特定方面。因此，当你测试你的应用时，应确保各种测试的良好平衡。

但是有一种测试通常受到开发者的青睐，因此往往被过度使用，这是端对端测试（E2E）。

什么是端对端测试

对于那些仍在探索软件测试世界的人来说，E2E 测试是在完成应用程序及其所有依赖项时进行验证的过程。

在 E2E 测试中，你创建一个与真实用户将使用的环境相同的环境。然后测试用户可能在你的应用程序上执行的所有操作。

通过端到端测试，你可以测试整个流程，比如登录网站或从在线商店购买产品。

但是，如果你过度使用 E2E 测试，你就是在颠倒测试金字塔。我曾经遇到过这样的情况。在我的一个项目中，我计划用 E2E 测试覆盖大部分情况，甚至更糟糕的是，只使用 E2E 测试。幸运的是，我改变了主意。所以现在我想和你分享我学到的东西。

为什么你应该遵循测试金字塔

乱七八糟地编写的测试起初可能看起来和感觉很正常，但最终总是令人痛苦的。

我们编写测试是为了节省更多时间，我们通过自动化测试来实现这一点。当然，我们可以自己打开应用程序并手动测试它们。如果我们只需要做一次，那么就没有问题。但这种情况很少见。

软件总是在不断更新。因此，你需要执行持续测试，以便随时掌握情况。你不可能在每次应用程序更新时都手动运行所有测试。如果你能编写一次测试套件，然后每次想要测试应用程序的某个方面时都运行它，你将节省大量时间。

每个测试都有其自己的目的。如果你超越了每种测试类型的界限，你的测试将开始对你造成伤害而不是帮助。这是因为你最终会花费更多的时间编写和维护测试，而不是开发应用程序本身。换句话说，你将失去自动化测试的最大优势之一。

一个好的起点是遵循测试金字塔。它可以帮助你找到测试的正确平衡。它代表了行业标准的指南，自2000年代中期以来一直持续，因为它仍然具有实用性。

那么这是否意味着开发人员总是遵循其指南？并非如此。有时金字塔看起来像一个倒置的金字塔，其中大部分测试都是 E2E。或者它看起来像一个沙漏，有很多单元测试和 E2E 测试，但没有很多集成测试。

测试金字塔的三层

测试金字塔通常有三层：单元测试、集成测试和E2E测试。现在让我们详细了解它们。

1. 单元测试

单元测试关注代码的最小单元，如函数或类。

它们简短且没有任何外部依赖。如果它们有外部依赖，你可以使用模拟对象代替。

如果一个单元测试失败，找到问题通常是一个简单的过程。它们的测试范围有限，使得编写、运行和维护变得简单、快速和容易。

2. 集成测试

集成测试关注两个独立实体之间的交互。它们通常运行速度较慢，因为需要设置更多内容。

如果集成测试失败，找到问题会更具挑战性，因为失败范围更大。

编写和维护集成测试也相对困难，主要是因为它们需要更高级的模拟和更广泛的测试范围。

3. 端对端测试

最后，E2E 测试关注从最简单到最复杂的流程。它们可以被看成多步骤的集成测试。

这些测试运行速度最慢，因为它们涉及构建、部署、启动浏览器以及在应用程序中执行操作。

如果E2E测试失败，找到问题通常很困难，因为现在失败范围扩展到整个应用程序。基本上，在路径中，任何东西都可能出问题。

在这里考虑的三种测试类型中，它们无疑是最难编写和维护的，因为测试范围巨大，而且涉及整个应用程序。

希望你现在能明白为什么测试金字塔是这样设计的。从底层到顶层，每一层测试都代表着速度的降低以及范围、复杂性和维护需求的增加。

这就是为什么要记住的一件重要事情是，E2E测试不能取代其他方法——它是为了扩展它们。E2E测试的目的是定义明确的，测试不应超出这个范围。

理想情况下，测试应该尽可能地在金字塔的根部捕捉到错误。E2E测试的目的是验证按钮、表单、更改、链接、外部流程以及整个工作流程的功能是否正常运行。

用代码测试与无代码测试

总的来说，有两种测试类型：手动测试和自动化测试。这意味着我们可以通过手动或使用脚本进行测试。

第二种方法是最常用的。但是自动化测试可以进一步分为两部分：
用代码测试 和 无代码测试。

用代码测试

当你使用代码进行测试时，你可以使用能够自动化浏览器的框架。最受欢迎的工具之一是 Selenium，但我更喜欢并经常在我的项目中使用 Cypress（仅适用于 JavaScript）。然而，它们的工作方式大致相同。

基本上，使用这样的工具，你可以模拟网络浏览器并指示它们在目标应用程序上执行不同的操作。之后，你可以测试应用程序是否对相应的操作做出了响应。

下面是一个简单的模拟示例，摘自 Cypress 文档，以帮助你更好地了解这个工具的工作原理：

上图是来自文档的原始代码

让我们看看发生了什么：

1. 假设用户访问 https://example.cypress.io
2. 当他们点击标签为 “type” 的链接时，URL 应该包含 /commands/actions
3. 如果他们在 .action-email 输入框中输入 “fake@email.com”，那么 .action-email 输入框的值应为 “fake@email.com”。

无代码测试

在无代码测试情况下，你使用由人工智能驱动的框架来记录你的操作。根据一些额外的信息，它们测试目标应用程序是否按预期响应。

这些工具通常看起来像低代码平台，你可以拖放不同的面板。其中一个工具是 TestCraft，它是基于 Selenium 的 无代码 解决方案。

由于它们提供的功能（如使用简单的拖放选项创建、维护和运行测试，无需编码知识），这类工具通常价格较高。但我想提一下 TestCraft ，因为它们有一个基本包含所有内容的免费计划。

当然，如果你想要速度和省钱，无代码解决方案可能有优势，但这些解决方案很新。因此，它们还无法解决你自己通过代码才能解决的复杂测试。

如果目标应用程序具有一些非常复杂的流程，包括多个移动部件，那么传统的测试方法是最佳选择。但是，如果你有简单的流程，那么无代码解决方案正是你所需要的。

总结

为任何应用编写测试是必不可少的。如果你遵循基本的原则并根据测试类型编写测试套件，那么你的测试将只会改善你的应用程序，并且编写和维护起来也相对容易。

你应该只在适当的场景下使用端到端测试，就像其他测试一样。它们的目的是通过模拟真实用户场景，从头到尾测试应用程序的工作流程。但最后，请记住，大多数错误应尽可能在根源处被捕获。

如果你想更高效地做测试，就需要知道不同的测试类型，以及在什么时候使用它们。

在这篇文章中，我想谈谈其中的一些测试类型，它们能帮助你确保产品或者应用的可操作性、完整性和安全性。

软件测试金字塔

（《软件测试金字塔》 如果觉得这张图片很赞，可以随意分享到你的博客或者推特。）

软件测试金字塔覆盖了整个软件开发生命周期（SDLC）。它从底层的单元测试开始延伸，穿过集成测试，到顶部的功能性测试结束。

然而，这些测试类型并没有固定的套路，相反，你需要自己来决定哪种才最适合你的需求。为了决定选哪一种，你需要综合考虑使用它们所需的费用、时间以及资源。

敏捷软件开发者也常使用软件测试四象限，这个法则根据是面向业务还是面向技术，是评论产品还是支持团队这两个维度来对测试进行归类。

例如，单元测试是一种支持团队的面向技术的测试，而可用性测试是一种发现产品问题的面向业务的测试。

现在让我们一起来看看一些重要的测试类型。

单元测试定义

单元测试是指测试单个代码组件，而不是整块代码。它验证所有组件逻辑的可操作性，以便在软件开发生命周期的早期阶段就发现缺陷，在进一步开发之前，对其进行修复。

单元测试也叫做“白盒”测试，因为需要完全掌握应用程序的结构和环境才能进行。

下面这个单元测试的例子，创建了模拟对象用于测试代码块，如还未生成参数变量的函数。

const mocha = require('mocha')
const chai = require('chai')  // It is an assertion library
describe('Test to check add function', function(){
  it('should add two numbers', function(){
    (add(2,3)).should.equal(5)  //Checking that 2+3 should equal 5 using the given add function
  });
});

集成测试定义

单元测试往上一步就是集成测试，它把各个组件联合起来，作为一个组来进行测试。集成测试用于识别各个组件之间交互时出现的问题，以检验代码是否符合功能说明书。

集成测试区别于单元测试的一个点是，它关注独立工作在整个组里面的模块和组件。而另外一边，单元测试关注于在测试前隔离模块或组件。

集成测试的关键是，在集成后的模块或组件之间，暴露任何软件缺陷或漏洞。

拿一个更为简单的例子来说，如果你正在对刚创建的邮箱服务进行一项集成测试，那么你需要测试各个组件，如撰写邮件、保存草稿、发件、移动到收件箱、登出等等。

在这之前，你得先对单个特性进行一次单元测试，主要是跟集成测试中相关的每个功能函数。

端到端测试定义

金字塔的顶部是端到端测试。如名所示，端到端测试重复应用程序的所有操作，以测试应用程序的连接性和依赖性的方方面面。这包括网络连接、数据访问和外部依赖。

端到端测试在模拟真实用户的环境下进行。

你可以通过某些指标来定义端到端测试是否成功，包括测试状态（用可视化图表来跟踪）和报告状态（用于展示测试执行的状态和已发现的漏洞或缺陷）。

软件测试类型

测试金字塔的每个层级都包含了各式各样的具体流程，用于测试各种应用程序功能和特性，也包括应用程序的完整性和安全性。

应用程序安全性测试定义

应用程序安全性测试是应用程序各种测试类型中最重要的一个。它帮助你识别应用程序漏洞，这些漏洞很有可能被黑客利用，所以要在发布产品或应用之前把它们修复掉。

有很多应用程序安全性测试供你使用，它们可应用于软件开发生命周期中的不同部分。

你可以在测试金字塔的不同层级找到不同类型的应用安全性测试。每种测试都有其自己的优点和缺点。你应该同时使用不同的测试类型，以确保它们整体上的完整性。

静态应用程序安全性测试（SAST）定义

你应该在软件开发生命周期早期使用静态应用程序安全性测试（SAST）。它是单元测试的一个例子。

SAST 反映了开发人员的能力，包括应用程序的通用设计和实现，因此它是白盒测试，或者叫由内而外的测试。

SAST 分析代码本身而不是最终的应用程序，你不需要执行代码就可以运行起来。

图片来源

云防御的安全分析师说，

“SAST 检查你的代码是否违反安全性规则，同时在源分支和目标分支之间比较已发现的漏洞……一旦项目新发现的漏洞会影响项目依赖性，你就会被通知到。”

一旦发现漏洞，你就可以在最终应用程序构建之前把它们解决掉。

你应该在软件项目的开发阶段就将 SAST 应用进去。在设计和编写应用程序时就将 SAST 扫描包含到开发流程中，不失为一个好方法。

动态应用程序安全性测试（DAST）定义

处于另一端的是动态应用程序安全性测试（DAST），它测试完整编译好的应用程序。你设计和运行这些测试时，不需要知道潜在的结构或代码。

因为 DAST 采用黑客视角，它被称为黑盒测试，或由外向内的测试。

DAST 通过攻击运行中的代码以及寻找可利用的潜在漏洞来进行测试。DAST 可能采用跨站点脚本和 SQL 注入等常见攻击技术。

DAST 在软件开发生命周期后面才进行，它是集成安全性测试的一个例子。由于很慢（一整个完整的应用程序的 DAST 测试平均可能需要花 5 到 7 天），它会为你揭示应用程序中黑客最有可能攻击的漏洞。

交互式应用程序安全性测试定义

交互式应用程序安全性测试（IAST）是一种比较新的测试方法，它结合了 SAST 和 DAST 的高效性，同时克服了与这些确立的测试相关联的问题。

IAST 使用一种插入式的监控代理，来对应用程序进行持续实时扫描，从而发现错误和漏洞。尽管 IAST 是在应用程序运行时进行的, 它仍然被当作是一个 SDLC 早期的测试过程。

不管你在寻找什么样的软件进行测试，IAST 最适合在 QA（质量保证）环境中使用，同样，也很适合专门设计出来用于复制客户或者顾客真实使用产品的场景。

兼容性测试定义

兼容性测试评估你的应用程序如何运行，以及它在各种设备和环境（包括移动设备和不同操作系统）上的安全性。

兼容性测试还可以评估当前版本的软件是否与其他软件版本兼容。版本测试可以是朝后或者朝前的。

图片来源

兼容性测试的例子包括：

• 浏览器测试（检查以确保你的网站或移动网址与不同的浏览器完全兼容）
• 移动测试（确保您的应用程序与 iOS 和 Android 兼容）
• 或软件测试（如果你要创建多个需要彼此交互的软件应用程序，那么需要进行兼容性测试以确保它们正常运行）。

软件测试金字塔之外

测试金字塔的修改版本可以包括与端到端测试相邻或之上的层级。此层级包括针对应用程序用户的测试。

性能测试定义

你需要知道应用程序将如何在各种不同的条件下工作，这就是性能测试的目的。性能测试可以对各种负载和压力进行建模，以评估应用程序的稳健性。性能测试的类型基于所应用的条件。

性能测试的一个例子是负载测试，用于确定最大负载，即系统何时会崩溃。

另一方面，另一个例子，如可扩展性测试，将逐渐增加的负载应用于系统，以评估适应增加的系统压力的方法。

尖峰测试用于评估对系统突然施加大负载变化所带来的影响。

在任何软件系统面向市场之前，你都应该对其进行性能测试。测试其稳定性、可扩展性和速度，这样你才可以在上线之前就识别要修复的内容。

可用性测试定义

测试应用程序接口的实际使用是一项重要的任务。理解应用的功能是否按设计运行是一回事，而这个设计本身是否为用户所接受又是另一回事了。这就是可用性测试的出发点。

通过可用性测试，开发人员可以评估用户对特定应用程序特性和功能的反应。这包括你可能事先知道从用户角度来看不太理想的功能，但是这些功能是强安全性和正确操作所必需的（像强密码这种要求）。

可用性测试与外观问题或修复任何书面文本中的语法错误无关（尽管这两个问题本身当然很重要）。相反，它与终端用户使用应用程序的难易程度有关。

结论

测试不仅仅是应用程序开发结束后 QA 部门应该做的事情，它也是软件开发过程的重要组成部分。

了解你可以使用哪些测试以及它们如何工作，将帮助你保证应用程序运行良好、安全并且为最终用户所接受。

原文：What is Software Testing? The 10 Most Common Types of Tests Developers Use in Projects，作者：Nahla Davies