《测试开发方法论》之 失败处理

方法论》之 失败处理"/>

《测试开发方法论》之 失败处理

 测试开发的领域中，我们做的最多的就是 生产测试数据的工具，还有自动化脚本，工作流自动化等等提效工具。 

今天要说的就是在制作这些工具的时候，要留个心眼，留什么心眼呢？当然不是坏心眼，而是要做好脚本代码执行失败的 处理办法。

执行失败后，确保不生成脏数据。这个意思很简单，比如你做一个自动注册的脚本：原来需要很多恶心的实名认证/验证码/邮箱/昵称设计/推荐码等等一些功能，但是你做的工具可以自动化的去执行这些步骤。但是你要想一下，万一在执行中途，因为某些原因脚本意外中止了。那么之后怎么办？

比如到了昵称设计的接口，接口报错导致脚本终止了。那时，使用者的看到你的平台工具提示说 注册失败。然后她还想重试的时候，却被第一个接口告知，该手机号已被注册！ 她有什么办法呢？这个没有昵称的手机号账户，是否算作一个脏数据呢？

当然，这里的修复办法很简单，比如让她用手机号登陆下，然后自己手动修改昵称，或者你去数据库去手动删除用户表的这个半截数据。

不过，这里举例的是一个很简单的场景，如果遇到比较难的呢？比如构造某个产品。从入库，商标，价格，库存，优惠，活动，然后自动提交审核，自动审核，自动上线等等好几十个维度去构造的时候，如果中途构造一半报错了，那后果可是很严重的，比如脚本执行到 自动提交审核这步，结果报错中止。然后使用者看到的结果是商品正在审核中，他没办法重新再次执行脚本，也没法自己去审核等等，还是需要报告你，让你这个测试开发去手动审核等等，这种事一旦数量上来了，会把自己累死。

不要说什么 只要脚本写的好就不会有报错。这是不可能的，实际中，引发错误的原因太多，完全不可控，很多时候是开发那边的接口服务器的错误甚至网络问题，我们要做的不能只是确保不出现错误，而是要同时做好一旦出现错误，要如何最低代价的修复。这正是和isoo9126中的 可维护性/健壮性等不谋而合。

那么所以我们在一开始设计这个脚本的时候，就要想好一旦出现这种情况要怎么办？

1.报错日志 和 错误提示，要非常清晰明了，让使用者知道目前是因为什么原因在哪一步出错了，要去理智的报告问题或者自行解决不要慌不要着急。

2. 统计报错日志，按照错误频率排序，从最高开始进行异常处理，比如重试该步骤，自动删除/复原，自动报警给负责人等等。  3. 确保好排查，也就是易测试/易修复性，这个主要看你的代码风格和架构算法功底了。高内聚/低耦合 不是一句口号，pep8风格，单双驼峰，类和函数命名最好都规定上，代码注释，函数调用，架构设计都要经过深思熟虑。  4. 成本控制，著名的page-object设计模式就是基于成本的控制角度提出的，把元素定位和元素业务逻辑操作 完全分开，以便之后维护方便。pip可下载的wqrfnium也是基于成本控制，在元素定位失败后自动排查锁定最接近的新元素，试出来后会覆盖原来的定位方式。这些技术都是针对成本控制出发，用来进行失败处理的算法工具。  5.成本转移，出了问题的时候，能不能把这个维护的成本，修复的任务转移给更适合的人呢？比如谁对这业务比较了解，谁目前比较需要这些任务来升职加薪。就给谁去做。但是你作为主程测开，要把其他人维护的门槛成本降到最低，比如底层代码，逻辑能放到页面维护；各种复杂的组件你都封装好，让人简单调用；不重要的边缘技术比如前端开发能给自动生成等等。  好了关于失败重试的问题就探讨到这里来，这也是我总结的做好一个合格的测试开发的方法论的重要一环，希望大家喜欢。