最近几个月因为线上问题好头疼，说两个最近遇到的吧
1，第一个是开发有个字段取错了，这个字段以前一直都是别人系统传过来的，但是这次要查别人接口取，忘记检查字段取值了，结果影响线上 1000 多个单
2，java 的一个工具类计算今天是周几，因为老外一周的第一天是周日，所以周日返回 1，周一返回 2，以此类推周六返回 7，开发直接把得到的数减 1，所以周一到周六都是没问题的，周日本来就是 1，减一就成 0 了。当时我没测到周日这个点，结果上线了又出问题了文章源自玩技e族-https://www.playezu.com/452037.html
大家能说说工作中怎么尽量避免类似的问题吗？文章源自玩技e族-https://www.playezu.com/452037.html 文章源自玩技e族-https://www.playezu.com/452037.html
玩技站长微信
添加好友自动发送入群邀请
rainbow-shownow
玩技官方公众号
官方微信公众号
PLAYEZU
未知地区 17F
回答一下标题好了，怎么避免漏测。
有没有可能和其他测试同学做个交叉测试呢，个人认为漏测的缺陷测再多次也发现不了，不如用其他人的测试思路加测一轮，当然这个可能得从测试团队工作安排去解决了，如果其他产品线也有这类问题，可以尝试团队内部讨论一下交叉测试可行性
其次，历史漏测的这些问题都整理好，楼里很多热心的小伙伴也都深度分析了一下这俩问题的原因以及给了相应的解决办法，下次测的时候注意这些问题，养成好的测试思维，多积累经验，吃一堑长一智，总会有进步的
未知地区 16F
第一个问题确实不该漏测，校验取值的正确性是必要的
未知地区 15F
事前处理：加强需求理解、完善测试用例、用例评审
事中执行：严格按照用例执行，期间有新的用例，补充到用例库
事后总结：收集上线问题，总结测试问题，
不断完善自己的用例库
未知地区 14F
嗯，其实两个问题我觉得有部分因素是经验不足吧，接口的取值跟其他系统相关的这部分其实是非常容易出问题的，数据格式不对，参数缺失 ，参数命名不同，需要参数映射等等，这块如果你不知道改动的话，情有可原，知道的话，这是个很明显的测试点，有变动跟之前不一样的地方，理论上应该都要检验一下吧。
至于第二个问题，逻辑上是减一的话，那 0-1，这个其实也是很常见的校验点。不过研发的这个实现逻辑上确实是让人意外，过于简单粗暴了，这个有点看个人经验了。这个慢慢积累吧
未知地区 13F
第 2 个问题不应该是必测的边界值吗？
未知地区 12F
关于两个问题，如果不客气一点的说，楼主还是明白什么道理，问题分析的非常模糊。而且逻辑也不够通。
1，第一个是开发有个字段取错了，这个字段以前一直都是别人系统传过来的，但是这次要查别人接口取，忘记检查字段取值了，结果影响线上 1000 多个单
这里我有问题问： 别人系统传过来的？和查别人接口获取，有区别吗？别人系统怎么传过来的？无论是别人送过来的还是自己主动调用，对你测试系统来说都是输入，不能完全相信输入这是一条准则？ 别人传过来和自己去查询，就是一回事，不要被开发忽悠了。收到输入参数要做合法性校验的，测试起来确实有点麻烦，但是不是到处在说什么 Mock 吗，那就 Mock 一个了呗。 忘记字段检查取值是个什么意思？这个字段是必须要的还是不必须的？这个字段是变化的还是不变的？都没有挖的底，直知道漏侧，但是不深挖是很难避免的。最少这个事情里面， 对你的帮助：
是不是可以使用 Mock 帮助你测试？
如果一个业务有几个关键字段会直接影响订单的，这几个字段的正常值，null，空，都需要用例去覆盖一下，还有字段的阈值也需要验证
2，java 的一个工具类计算今天是周几，因为老外一周的第一天是周日，所以周日返回 1，周一返回 2，以此类推周六返回 7，开发直接把得到的数减 1，所以周一到周六都是没问题的，周日本来就是 1，减一就成 0 了。当时我没测到周日这个点，结果上线了又出问题了
这个问题有点坑，我觉得对我的启发就是，类似于这种情况，开始和结束时间都需要试一下，这样才能确定这个顺序是怎么排的。 当然工具类，其实可以直接把代码拿出来，自己跑一下测试，工具类其实没什么依赖的。还有就是周 1-周日业务上有什么不同吗？为什么 0 就不行了，星期几不是只用来做一下表示吗？
未知地区 11F
老功能的话试试流量回放呢。 新功能的话，就很依赖于经验了