软体测试介绍 — 为什么推荐多写一点整合测试？

什么是 E2E 测试？

相信有接触前后端开发的人，大概都对 E2E 测试这种测试不陌生。所谓的 E2E 是 end-to-end 的缩写，也就是指端到端。

具体来说，E2E 测试会是以模拟使用者使用系统的方式，走过完整的流程，就像模拟使用者在用网站，测试的脚本一步步模拟使用者的行为，并写下每个行为后预期会发生的结果。

测试的核心目的

写自动化软体测试的核心目的，是要给软体产品团队信心，让团队知道当软体实际上线被使用者用时，不会有意想不到的事发生。也因此，当测试越贴近使用者实际使用软体的方式，就能够给团队更多信心。

E2E 测试的优势

从这个角度来看，E2E 测试因为在模拟使用者的行为，理想上应该最接近使用者使用软体产品的形式，所以应该最能带给软体团队信心。不过为什么目前业界多数推荐多写一点整合测试呢?

不论是早期的测试金字塔 (testing pyramid)，或者近几年有听到的测试金杯 (testing trophy)，在 E2E 测试的部分都是相对小的部分。甚至 Google 的 Testing Blog 之前也有一篇《Just Say No to More End-to-End Tests》在谈跟写更多 E2E 测试说不。

E2E 测试的耗时

这些论点背后有几个共通点，第一个是 E2E 测试写起来耗时、跑起来也耗时。这点相对好理解，毕竟要完整模拟使用者操作网站的每个流程，假如网站复杂一点、页面与功能多一点，测试执行起来肯定很耗时。

E2E 测试的稳定性

第二个则是 E2E 测试实际上没那么稳定。怎么说呢?

因为软体团队在写程式时，通常会有外部依赖，所以如果出问题的是外部依赖的模组，那可能会出现团队自己的程式码没问题，但仍无法通过测试的状况。

外部依赖导致的测试问题

举例来说，假如今天某个聊天机器人，背后是呼叫 OpenAI 的 API，而 OpenAI 的伺服器挂掉，导致 E2E 测试在模拟使用者的情况出现测试案例没通过，但这时因为不是自身程式码的问题，就会让测试相对不稳 (俗称有 flakiness)，导致测试案例没过，但没办法透过修改程式码让测试案例跑过。

这种状况就很尴尬，不是你的程式码的错误，却让 E2E 测试的案例没过；而因为是外部依赖出问题，所以测试没有过你也没办法做什么，那这样测试测出没过，对团队程式码的帮助何在呢?

难以测试的特殊案例

除了不稳定，E2E 测试还有一个问题是，相对难去测到某些特殊案例。举例来说，假如今天我们想测试一个状况是 A 模组先呼叫后呼叫 B 模组才可行，而 B 模组先呼叫后才呼叫 A 模组则会进到某个错误处理的情境。

从 E2E 测试的角度来看，这种状况很难被测到，因为 E2E 是模拟使用者操作，所以一般都是照正常情境的 A 模组先呼叫。可能只有在极少数出问题时才会变成 B 模组先呼叫，这样可能要跑非常多次测试才会出现一次异常，从测试角度来说很没效率。

整合测试的优势

因为上述这些点，让业界目前更多人推崇整合测试，因为整合测试可以测到不同模组之间互动的结果，同时比起 E2E 测试更快、更稳定，且更容易去测一些特殊状况。虽然没有像 E2E 这样完全模拟使用者，但总和考量下，还是比较推荐多写一点的。