【外评】谷歌对测试的分类
通过用户界面测试应用程序的测试叫什么?端到端测试?功能测试?系统测试?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
你也许感兴趣的:
- 【程序员搞笑图片】开发人员和测试人员
- 【外评】谷歌测试:复杂难读的布尔表达式
- 【程序员搞笑图片】设计的付出、开发的付出对比写单元测试和自动化测试脚本的付出
- 【译文】谷歌测试技术:如何大规模代码删除
- 【译文】谷歌测试技术:多少测试才算足够?
- Sentry 的前端测试实践:从 Enzyme 迁移到 RTL
- 2021年10大流行软件测试工具
- 谈一谈程序员不愿意写测试的问题
- 程序员文史综合素质测试题,下跪吧
- 为什么说让程序员自己做测试等于白测
你对本文的反应是: