E2E 测试用例的一般要求

周会上，聊到我们需要普及自动化 E2E 测试，用自动化 E2E 测试回归降低研发成本。老板问：

测试同学已经准备了不少 E2E 测试用例，能否直接用上？

这个问题需要具体来看。

0. E2E 测试

E2E 测试即端到端测试，一般用来描述一套完整的用户交互行为，要求在这一系列操作中，所有环节工作正常。E2E 测试比较关注操作的完整性，不太关注边界条件的覆盖范围。

前端代码、重前端的产品比较适合用 E2E 测试，因为模仿的是用户实际操作，所以往往能比较好的照顾到主要使用场景，性价比比较高。

之前在 OR 厂，我负责的产品就跟 E2E 测试有关，在几年时间里很好的保障了 OR 厂各商业产品的产品质量。本着拿着锤子找钉子的原则，我也想在我厂推广这种做法。

下面示范一下 E2E 测试用例。比如我们要基于 WordPress 博客软件写一个发布文章的测试用例，那么用伪代码描述大概如此：

打开网站后台 https://blog.meathill.com/wp-admin
输入用户名
输入密码
点击登录按钮
从菜单里打开文章列表页
新建文章
填写随机标题
填写随机内容
点击发布
回到列表页
查看内容是否存在

上面这个测试用例放在自己的环境里跑就没有问题，但是如果要自动化运行，往往还有一些特殊的要求。

一般来说，自动化测试更关注效率，尽量在最短的时间内完成全部测试。所以通常来说，自动化测试一般会多任务并行测试；甚至会部署多个节点一起跑。那么产生以下要求就很合理：

独立性
每个测试用例要能够独立运行，不依赖其它测试用例产生的环境，也不能因为其它测试产生的环境而失败。
随机性
为了能够独立运行，很多时候我们要给测试用例增加足够的随机性，比如上面例子里的标题，就应该是随机的，这样我们多个用例一起跑的时候，不会互相冲突。
完整闭环
为了不影响其它用例，E2E 测试用例一般要实现完整闭环。比如创建了文章，最后要把这篇文章删掉。这样一方面可以测试“删除功能”；另一方面不会产生太多垃圾，影响后面的测试。
尽量不依赖非软件功能
有时候我们会写一些清理、重置脚本，跑完几个测试或者开始跑测试之前制备环境。这样的做法也不好，因为这部分脚本没有被测试覆盖，可能产生新的问题。

所以，最后回到老板的问题上，我的答案是：

可以尝试，但恐怕不行。

希望今年我厂能扛住，希望我也能扛住，把自动化测试体系搭建起来。如果大家对自动化测试、E2E 测试有什么想法，欢迎留言与我交流。