由一个隐蔽的bug引发对自测的思考

前情

最近团队推广自测，在积极实行过程中，踩了一个很隐蔽的坑。在线下和线上的测试环境测试时，一直表现正常，但一发布就出了问题。
具体业务逻辑是扫描单据占用工单，根据单据号查询关联的工单表记录，将工单状态改为占用。
出现的问题是，扫描单据号A，却占用了工单B。

步骤梳理

终归要在代码中找原因，一步一步调试后终于在自动占用工单的逻辑中发现了问题。
扫单占用的流程细化后可以分为如下几步：

1. 根据单号查询占用状态工单，有则跳到4。
2. 根据单号查询工单，没有则报错退出。
3. 占用查询到的工单
4. 查询当前操作人占用中的工单，有则跳到6
5. 自动占用一条工单，没有则拦截
6. 作业

错误定位

而错误产生在第三步，更新工单时没有记录操作人id，使得第四步查询失败。
于是，进入第五步，自动占用一条工单。
巧合地是，在测试环境时只有一条可用的工单。当第四步查询失败时，自动占用的工单正好是当前扫描的工单。
所以扫单时没有任何异常，仍然占用了当前工单。

深层原因

分析后发现原因很简单，但也很隐蔽。
那么更深层的原因我觉得和测试方法、CodeReview、用例覆盖率也有关系

1. 最主要的问题，是自测流程太单一，只是一单一单地测，没有覆盖到线上多单并存的情况。
2. CodeReview当时因为急着上线没做，仔细codereview也能发现这个问题。

如何避免

这种隐蔽的问题，能及时发现是万幸，当然还得源头上避免
我总结了如下几点：

1. 自测时一定要对测试场景考虑充分，一单/多单的场景都要想到
2. 自测设计测试用例时，可以拉上测试一起设计，保证覆盖更多场景
3. CodeReview一定要做，实际上时间花得不太多，往往能从代码上检查出一两个问题。