稳定性建设之e2e

闲聊下，最近也是比较忙，这篇e2e本来是没啥时间写的，但最近有些心得感觉还是想分享一下。

本文就不过多的介绍e2e的概念和实际如何写了，网上随便一搜有很多

整理一下，这篇主要想分享几个点，可选择性看

1. e2e框架选择

2. e2e能带来的收益

3. e2e在稳定性建设中能cover住的场景

4. 如何衡量e2e对业务的价值

5. 一些e2e的难点场景

一. e2e框架选择

推荐cpress，docs.cypress.io/ ，写起来还很顺手，很高效。并且框架已经带好了各项配套。感兴趣的自己耐心看文档学哈

二. e2e能带来的收益

这个第二点其实是我最想讲的一点

个人觉得：

1. 写e2e非常爽，爽在哪呢？能极大提升未来维护一个项目的成本和效率，可以让自己无需再掉进重复的case校验

2. 没写过之前，不熟悉e2e，感觉有学习成本，学过后，真的很简单，很香

总结一下，e2e能带来的收益：

1. 减少QA回归的人力成本

2. 减少开发回归的人力成本（很爽的，看着自动走case，自己可以偷懒）

3. e2e本身覆盖的case，很利于后来的维护者了解项目业务。作为一个后来的接手项目的开发，写一遍覆盖各场景的e2e是一个很好熟悉业务的办法

4. 可以加入发布的流水线的流程内去，进一步保障业务稳定性

三. e2e在稳定性建设中能cover住的场景

1. 可以加入发布的流水线的流程内去，甚至是预发流水线，可以自动运行，保障核心流程没问题

2. 可以设置定时e2e巡检一些核心流程，或页面渲染，保障核心流程不会出问题

四. 如何衡量e2e对业务的价值

可以用2个指标衡量e2e的价值

1. 线上缺陷召回数

   有些项目，一些负责流程，很难每次都被能回归到。后续代码的变动，很可能导致隐藏的问题，在写e2e的过程中，本身就有在review页面的业务逻辑，很可能会召回出线上bug

2. 减少的QA和开发人力

   原本QA可能需要5天，加上e2e后，可能只需2天

五. 一些e2e的难点场景

e2e也并非都是些简单无脑操作，还是有些难点场景的。比如

1. 注册新用户

   可能涉及3D点选，图像识别，手机/邮箱验证码，这种可能会很难写e2e，如果不能豁免掉的话，几乎实现不了，而豁免的过程，可能也会很麻烦..

2. 登录的场景

   很可能会需要 手机/邮箱验证码。这种场景，可能需要一些测试超级账号，同样也是需要熟悉额外流程/审批

3. 一些和ip相关的功能验证

   e2e大概率是要接入一些自动化流程里面去的，在自动化流程里面，很难给你分配特定的ip。很多时候只能走其他后门来解决，这里可能涉及到改动原本业务代码

---

码字不易，点赞鼓励！

写的较粗糙，有补充欢迎评论。