通过用户界面测试应用程序的测试叫什么？端到端测试？功能测试？系统测试？selenium测试？这些我都听说过，还有更多。我想你也听过。针对较少堆栈的测试？同样令人沮丧的不一致。到底什么是集成测试？单元测试？我们该如何给这些东西命名？
嘎嘎！
很难说服自己的团队就每个名称的实际含义达成共识。如果遇到其他团队或项目的人使用与你不同的术语，挑战就更大了。更有趣的是，你和其他团队可能对不同的测试类型使用相同的术语。 “哦！那种集成测试？两个团队被共同的术语隔开了。
双倍嘎嘎！
命名测试类型的问题在于，这些名称往往依赖于对特定短语含义的共同理解。这就给模糊定义和混淆留下了很大的空间。一定有更好的办法。就我个人而言，我喜欢我们在 Google 所做的事情，我想我应该与大家分享一下。
谷歌喜欢根据数据做出决策，而不是仅仅依靠直觉或无法衡量和评估的东西。随着时间的推移，我们逐渐形成了一套以数据为导向的测试命名规则。我们称之为 “小型”、”中型 “和 “大型 “测试。它们的区别如下：
| Feature | 小型 | 中型 | 大型 |
| 网络访问 | No | localhost only | Yes |
| 数据库 | No | Yes | Yes |
| 文件系统访问 | No | Yes | Yes |
| 使用外部系统 | No | Discouraged | Yes |
| 多线程 | No | Yes | Yes |
| 沉睡语句 | No | Yes | Yes |
| 系统属性 | No | Yes | Yes |
| 时间限制(seconds) | 60 | 300 | 900+ |
至于每种测试类型的优缺点，我们将在另一篇博客中讨论，但显而易见的是，每种测试类型都有其特定的作用。同样显而易见的是，这并不涵盖可能运行的所有测试类型，但肯定涵盖了项目运行的大多数主要类型。
小型测试等同于单元测试，大型测试等同于端到端测试或系统测试，中型测试等同于确保应用程序中两个层级能够正常通信的测试（通常称为集成测试）。
这些测试定义的主要优点是可以让测试遵守这些限制。例如，在 Java 中很容易安装一个安全管理器，与测试套件一起使用（也许使用 @BeforeClass），该管理器为特定的测试大小配置，并禁止某些活动。由于我们使用一个简单的 Java 注释来表示测试的大小（没有注释表示这是一个小型测试，因为这是常见的情况），因此很容易就能将所有特定大小的测试收集到一个测试套件中。
我们还为测试设置了其他更难定义的限制。其中包括要求测试可以以任何顺序运行（经常是这样！），这反过来又意味着测试需要高度隔离–你不能依赖其他测试留下的数据。这有时会造成不便，但却大大方便了我们并行运行测试。最终结果是：我们可以轻松构建测试套件，并以尽可能快的速度持续运行它们。
完全没有 “嘎！”的感觉。
本文文字及图片出自 Test Sizes
你的反应是：