【外评】谷歌对测试的分类

通过用户界面测试应用程序的测试叫什么?端到端测试?功能测试?系统测试?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

你也许感兴趣的:

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注