软体测试 — E2E 测试是什么? 跟整合测试有什么区别?

E2E 测试如其名是一种端到端 (end-to-end) 的测试，厘清 E2E 测试的定义、E2E 与整合测试的区别，不仅是在实务工作上重要 (因为能让你确保真正能测到想要测的东西)；在准备面试上，因为这是个常会被问的问题，所以如果有要找新工作，也会是推荐要准备的题目之一。

因此，希望透过这篇贴文，用更完整的方式介绍 E2E 测试，让对这类测试还不熟的读者，有更全盘的了解。

首先，E2E 这个词，单看「端到端」其实蛮混淆人的，因为所谓的「端到端」并不是指整个应用流程的全部，而是从使用者这一端开始的动作，一路到相对应的结果完成。

因此，E2E 测试多半会从使用者流程的角度出发看事情，例如在电商网站中测试使用者能顺利完成购物，这时的端到端，就会是从使用者这端进到网站，到完成购物后收到确认信这个结果。

具体来说，在上述的流程中，可能会一路测试包含使用者能够顺利登入、能搜寻商品、能看到商品详情、能把商品加到购物车、能顺利结帐，以及最后有收到确认信，这一路下来需要每一个环节连在一起都顺利完成，才能通过测试。

整合测试与 E2E 测试的关键区别在哪?

相信读完上面这一段 E2E 测试的介绍，有些读者可能会有疑问，因为在业界中有另一个叫「整合测试 integration testing」的方式，也是用来测不同环节能顺利整合在一起，那这两者有什么区别?

或者换个方式问，假如今天整合测试也是把从登入到结帐完成的所有步骤都测过，这样跟 E2E 测试有区别吗?

事实上即使如此，两者仍是有区别的，因为整合测试与 E2E 测试的关注点不同，所以即使整合测试也是把从登入到结帐完成的所有步骤都测过，跟 E2E 的测试方式也会不一样。

这两种测试的关键区别在于

E2E 测试的关注点在是使用者与系统的互动，所以是从使用者的视角出发来测试。
整合测试的关注点则是元件与模组之间能否顺利整合在一起，因此测试的视角不是特别从使用者的视角出发

在整合测试下，需要先厘清「想要测什么之间的整合」，然后根据这个问题，来规划测试案例。在有了清楚明确要测试的东西后，就可以把非重点要测试的东西，直接模拟 (mock) 掉就好。这样做的好处，是可以把关注点切得很干净 (俗称关注点分离)，让想要测的部分不会被其他因素干扰。

在 CircleCI 的《How to test software, part I: mocking, stubbing, and contract testing》一文中 (连结) 用很精辟的方式总结这个观点：在进行整合测试时，测试的是服务与服务之间的关系。一种方法是将所有相依的服务在测试环境中都跑起来，但这并不必要。这么做可能会让那些你无法控制的服务，产生潜在的故障点，从而增加你测试的时间与复杂度。

With integration tests, you are testing relationships between services. One approach might be to get all the dependent services up and running for the testing environment. But this is unnecessary. It can create a lot of potential failure points from services you do not control, adding time and complexity to your testing.

而相较之下，E2E 测试全程仿照使用者的使用流程，不会模拟任何部分。因此，同样是要测试 GitHub 发完 PR 后可以看到 PR 的详细资讯，用整合测试可以模拟掉登入的部分，专注在测试发 PR 的 API 跟拿到 PR 详细资讯的 API 两者共同运作时不会出问题。但是 E2E 测试就不会模拟登入的部分，而是会真的如使用者登入一样，点击输入框、输入帐号密码、点击登入按钮这样详细的操作。

所以假如今天使用者登入的 API 出问题，E2E 测试会无法通过，但是整合测试会能通过 (因为会模拟掉登入的部分)。

为什么不要写太多 E2E 测试?

在了解完 E2E 测试与整合测试之间的区别后，接着我们要来谈过去在业界中普遍有的观点「不要写太多 E2E 测试」。

从早期的测试金字塔 (testing pyramid)、Google 改良后推出的推荐测试比例 (连结)，到后来有的测试金杯 (testing trophy)，可以看到 E2E 测试的比例都很低。甚至在早期 Google 的 Testing Blog 中有一篇文章标题就叫《Just Say No to More End-to-End Tests》的文章 (直译成中文就是「跟写更多 E2E 测试说不」)。

过去业界之所以一直有「不要写太多 E2E 测试」这个观点，最主要是因为以下几个原因

写与维护 E2E 测试比较耗时间，特别是过去因为网页技术还不够成熟，所以要写模拟使用者的操作，会比较复杂一点。
跑 E2E 测试比较花时间，试想同样的从登入到结帐流程测试，整合测试可以拆成不同的子流程，然后同时跑所有测试；但 E2E 测试因为模拟使用者流程，所以必须从头执行到尾，无法拆开并行，因此会花比较多时间。
假如测试没有通过，要找原因会比较慢，因为不像整合测试因为范围比较限缩所以能马上定位问题；许多时候假如是第三方依赖出问题导致测试没通过，E2E 测试会特别难辨别问题出在哪。
测试的不稳定性，因为 E2E 测试不用任何模拟，意即假如有第三方依赖出问题，对开发者本身来说，就会是「自己写的程式码没问题，但测试没通过」的窘境。理论上，假如测试没通过，开发者应该要修复问题让测试通过；但假如是第三方依赖出问题，开发者只能苦等到第三方依赖被修好才能让测试通过。

换句话说，即使 E2E 测试本身是有帮助与价值，因为过去写 E2E 测试、维护 E2E 测试，以及跑 E2E 测试的成本都偏高，所以导致整体的投资报酬率 (ROI) 不如单元测试与整合测试。因此，相较之下不推荐写 E2E 测试，而是推荐把有限的时间花在单元测试与整合测试上。

整合测试与 E2E 测试的关键区别在哪?

为什么不要写太多 E2E 测试?

阅读更多