集成测试怎么做？

任何产品想要长期保持高质量运行，集成测试正是实现这一目标必不可少的工具。

本文重点介绍集成测试实现的流程，而非测试工具本身。我们的目的是聚焦于创建测试过程中你可能遇到的问题，以便你能自主地推进工作。

缺陷的成本

细节决定成败，在软件工程领域，这一点尤为真实，大多数缺陷都隐藏在细节之中。

然而，你是否思考过缺陷究竟是什么？或许你会不假思索地回答，它是应用程序中的一个错误状态，但你可能会感到惊讶，因为这个定义并不准确，实际上这是对应用程序运行不一致的定义。

确实，缺陷表现为一种与预期不一致的行为，但并非所有不一致的行为都是缺陷。两者之间的区别在于，缺陷必须是外部可观察到的。理解这一点至关重要，因为它能帮助我们避免编写无用的测试——这些测试可能会验证一个与预期不一致但并不构成缺陷的场景。

明确了缺陷的定义后，你可能接下来会问自己的第二个问题是：为什么不让缺陷逃逸并让用户去反馈呢？

原因很简单，你是否有过需要重做过去已完成任务的经历？这难道不令人烦恼吗？你需要重新投入进去，努力回忆相关细节，换句话说，你的效率会降低，而这种效率的降低是有代价的。

这就是为什么缺陷发现得越晚，修复它的成本就越高的一个完美例证。在开发初期发现并修复缺陷，比起在产品发布后由用户发现再进行修复，所耗费的时间、资源和对用户信任度的影响都要小得多。因此，通过集成测试等手段提前捕捉并解决缺陷，对于控制成本、提高软件质量和用户满意度至关重要。

这一成本正是我们希望在缺陷尚且廉价且容易修复的早期就发现它们的原因。

验证你是否完成了任务，而非你是否工作过。

关于测试，我最讨厌的一句话之一就是：“你测试过你的代码了吗？”大多数开发者不喜欢这句话，因为他们将测试视为一种被迫承担的任务，而我之所以不喜欢这句话，还有另一个原因：这句话从根本上就是错误的！

良好的意图有时也会导致糟糕的结果，这句话就是一个典型例子。当你对另一位开发者说这句话时，你的本意是好的，提醒他们别忘了测试，但你没有意识到的是，你也正在引导他们走向一个误区。

在进行测试时，你永远不能仅仅测试代码本身，而应该测试代码运行是否符合预期。

它并不是检验你的程序是否完全没有缺陷，而是检查测试预期与你的代码之间是否存在差距。

如果你基于代码来设计测试，那么即使你的代码没有达到项目期望，你也可能找不到任何缺陷，因为两者是匹配的！因此，正确的做法是确保测试是基于项目的实际需求和预期结果来编写的，而不是简单地验证代码逻辑本身。

那么，我们应该测试什么呢？

我们应该基于项目期望来进行测试，确保测试是围绕这些期望展开的，而绝不是在测试过程中揪住代码实现细节。

现在，你或许会对如何测试项目期望以及这些期望是什么感到困惑。这就是我想要向你介绍的——验收标准（Acceptance Criteria）的原因。

制定规范

没有什么比面对着一张白纸，完全不知道接下来该做什么更糟糕的了。而且，可以肯定的是，当你开始学习测试时，这种感觉会经常出现。

不过，我有一个好消息要告诉你，有一种方法可以减少这种迷茫感，那就是以一种特殊的方式编写规范，这种方式被称为验收标准。

验收标准是一句简单的句子，描述了应用程序中的一个原子行为，这样就便于测试，因为我们为每个场景都有了精确的指导。每个场景都会有一个精确描述它的验收标准，这让测试变得更加直接和有针对性。

流程规范

与初学者常认为的不同，编写测试和代码之间存在着一定的顺序。

并非不遵循这一顺序就无法进行，但可能会使过程更加艰难且容易出错。

为此，一种既实用又流行的开发方式是测试驱动开发（Test Driven Development，TDD）。

然而，这种实践也有些教条化，作为初学者，在各种规则间很容易迷失方向。

因此，对初学者而言，回归基础，确保理解这一过程是非常重要的。

这是最重要的，一开始没有采用完美的流程并不可耻，罗马非一日建成，你的测试技能也是如此。

相反，最好专注于测试驱动开发的三个原则，并以最适合自己的方式去应用它们。

1. 第一条原则是在编写任何代码之前先实现测试。

这样做的目的是确保你不是在测试代码本身，而是基于验收标准来设计测试。

1. 第二条原则是，在编写任何代码之前，确保测试失败。

在小型项目中，这可能没有太多意义，但随着项目规模的扩大，很难追踪某个问题是否已被其他部分解决。这个检查是为了确保之前没有完成相同的工作，实施这段代码将为公司带来实际效益。

1. 最后一条原则是，一旦完成代码编写，所有测试都应通过。

确保所有测试都能通过，有助于我们跟踪应用程序中重要的内容，并确保在将来重构或添加新功能时不会破坏任何现有功能。

AAA框架

为了实现一个场景，我们有描述每个场景的验收标准，但如何从一句描述转换成实际代码呢？

第一步是确保验收标准是完整的，为此我们需要了解测试的三个组成部分。

1. 我们要安排应用程序的状态，确保每次运行时都有验收标准中明确规定的特定状态。这里的目的是每次运行测试时都拥有完全相同的状态，确保我们能够复现它。

2. 接下来的步骤是执行我们想要测试的逻辑。

3. 最后一步是断言新的状态是我们预期的，否则就让测试失败。

如你所猜测的那样，如果了解AAA框架，就会发现每个步骤都遵循了该框架的一个步骤，并且为了明确定义验收标准，它也需要遵循这三步。

快速识别并不总是简单，因此设计了一种称为Gherkin的伪代码语言来解决这个问题。

在这个语言中，每个验收标准至少应包含以下每个关键词一次：

• Given：这个关键词与设置步骤相关联，用于定义初始状态。

• When：这个关键词用于定义需要执行的逻辑。

• Then：这个关键词与断言步骤相关联，确保测试在验证最终状态是否符合预期。

最后总结下

测试是复杂的，但是通过遵循一些原则并妥善划分步骤，可以实现有效的测试。

首先，不能为了测试代码而测试，应该关注代码预期。

然后，遵循测试驱动开发的三条规则，确保你为公司编写了真正有效的代码，并且可以跟踪应用程序中哪些内容是重要的。

最后，为了编写每个场景，你需要遵循AAA框架，确保没有遗漏（Arrange）、（Act）和（Assert）这三个步骤中的任何一个。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

​

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！