避免漏测，我说说自己的看法，第一是提升自己的业务能力，对需求和影响面尽量多了解，这样在做测试设计的时候也会考虑的更加全面。第二是要进行测试设计以及测试案例的评审，拉通产品、开发、最好是有之前熟悉这个模块的级别比较高的测试同学，可以提高你的设计质量，也可以站在不同的视角分析问题。第三是最好具有一定的代码能力，可以参与开发的设计评审/代码走读，这样在评审过程中提前发现问题。

涉及多地区的系统，一定要注意时区，尽可能使用时间戳来计算，等到最终输出时，客户端自己根据所在的时区把时间戳转换成日期就行。

结合历史发帖看挺有意思的。
第一个问题还要具体分析再判定，第二个不就是等价类、边界值吗？
如果随便点点就当通过了，那不如随便找个应届生把主流程走一遍，线上有没有问题全看开发对异常情况的兜底水平。
测试搞代码只是为了提高自己的效率，从不觉得写代码的一定比做业务的强。
作为团队真要追求代码，还不如从 it 培训班招个开发，何苦逼着测试卷。

第二个你说我随便点点就通过了，我不认同。严格来说这个不是边界值的问题，因为一开始我并不知道开发是这么实现的，是事后复盘才知道的。如果换别人做这个黑盒测试，当周一到周六里面挑了好几天都符合预期了，真的会有人再拿着周日再测一遍吗？
可能有人会说一周总共就 7 天，全部测一遍不就行了，如果一周是 100 天呢？难道也全部测一遍吗

但是，如果做白盒测试，能看到开发的实现逻辑，周日这个问题是有概率可以发现的

我认为站在公司角度，写代码的测试和做业务的测试，前者可能还真没后者贡献多。但是站在自己角度，会写代码的测试跳槽能拿到的工资就是会比只做业务的人多啊

解决方法你自己其实清楚，就是看代码，看开发实现的逻辑，结合自身的经验去测试，考虑可能的风险。如果只是黑盒测试就势必会出现这样的问题，百密一疏，谁也不能保证自己的东西永远不出问题，只要在你的职业生涯中不出问题就行了

你这个回答不能认同，边界值测周几的话应该选 1，4，7 吧？至少周一和周日应该是必测的

非常坑，这很难避免

要看工作量啊，时间充足肯定把用例搞丰富点，交付的时候过下代码什么的最好了

第一个问题，这个字段是重要的字段还是不重要的字段呢，如果是不重要的，我觉得漏测了，情有可原，如果是重要的，是应该要验证一下的
第二个问题，跟地域，特别是国外的有关系的系统，是要应该注意这些差异，我曾经测过几款小程序，在国内适用正常，但是在国外澳洲，就是经常打不开，等各种问题，后来专门进行了弱网测试

老功能的话试试流量回放呢。 新功能的话，就很依赖于经验了

关于两个问题，如果不客气一点的说，楼主还是明白什么道理，问题分析的非常模糊。而且逻辑也不够通。

1，第一个是开发有个字段取错了，这个字段以前一直都是别人系统传过来的，但是这次要查别人接口取，忘记检查字段取值了，结果影响线上 1000 多个单

这里我有问题问： 别人系统传过来的？和查别人接口获取，有区别吗？别人系统怎么传过来的？无论是别人送过来的还是自己主动调用，对你测试系统来说都是输入，不能完全相信输入这是一条准则？ 别人传过来和自己去查询，就是一回事，不要被开发忽悠了。收到输入参数要做合法性校验的，测试起来确实有点麻烦，但是不是到处在说什么 Mock 吗，那就 Mock 一个了呗。 忘记字段检查取值是个什么意思？这个字段是必须要的还是不必须的？这个字段是变化的还是不变的？都没有挖的底，直知道漏侧，但是不深挖是很难避免的。最少这个事情里面， 对你的帮助：

1. 是不是可以使用 Mock 帮助你测试？
2. 如果一个业务有几个关键字段会直接影响订单的，这几个字段的正常值，null，空，都需要用例去覆盖一下，还有字段的阈值也需要验证

2，java 的一个工具类计算今天是周几，因为老外一周的第一天是周日，所以周日返回 1，周一返回 2，以此类推周六返回 7，开发直接把得到的数减 1，所以周一到周六都是没问题的，周日本来就是 1，减一就成 0 了。当时我没测到周日这个点，结果上线了又出问题了

这个问题有点坑，我觉得对我的启发就是，类似于这种情况，开始和结束时间都需要试一下，这样才能确定这个顺序是怎么排的。 当然工具类，其实可以直接把代码拿出来，自己跑一下测试，工具类其实没什么依赖的。还有就是周 1-周日业务上有什么不同吗？为什么 0 就不行了，星期几不是只用来做一下表示吗？

第 2 个问题不应该是必测的边界值吗？

嗯，其实两个问题我觉得有部分因素是经验不足吧，接口的取值跟其他系统相关的这部分其实是非常容易出问题的，数据格式不对，参数缺失 ，参数命名不同，需要参数映射等等，这块如果你不知道改动的话，情有可原，知道的话，这是个很明显的测试点，有变动跟之前不一样的地方，理论上应该都要检验一下吧。
至于第二个问题，逻辑上是减一的话，那 0-1，这个其实也是很常见的校验点。不过研发的这个实现逻辑上确实是让人意外，过于简单粗暴了，这个有点看个人经验了。这个慢慢积累吧

事前处理：加强需求理解、完善测试用例、用例评审
事中执行：严格按照用例执行，期间有新的用例，补充到用例库
事后总结：收集上线问题，总结测试问题，
不断完善自己的用例库

第一个问题确实不该漏测，校验取值的正确性是必要的

回答一下标题好了，怎么避免漏测。

有没有可能和其他测试同学做个交叉测试呢，个人认为漏测的缺陷测再多次也发现不了，不如用其他人的测试思路加测一轮，当然这个可能得从测试团队工作安排去解决了，如果其他产品线也有这类问题，可以尝试团队内部讨论一下交叉测试可行性

其次，历史漏测的这些问题都整理好，楼里很多热心的小伙伴也都深度分析了一下这俩问题的原因以及给了相应的解决办法，下次测的时候注意这些问题，养成好的测试思维，多积累经验，吃一堑长一智，总会有进步的

楼上说的对，交叉测试 +bug 回溯&总结

线上定时巡检还是很有必要的~~

代码覆盖率考虑一下老哥

老油条：学会甩锅就行

第二条，这个开发就很有问题，应该是用枚举，简单的减一，我是醉了。测试应该根据开发的设计思路去设计用例，如果提前知道是按减一方式做，应该关注一些特殊点，从结果来看测试这个缺乏敏感性了

第二个问题不是基本的边界值问题吗？ 我只能说你的测试用例设计水平还要再琢磨提高一下。

“一周总共就 7 天，全部测一遍不就行了，如果一周是 100 天呢？” 但是现实就是一周就是七天没有一百天，很常见的边界值问题，你确保了自己的用例覆盖到位了吗？考虑到日期不同肯定要从两头测一遍，这和白盒不白盒没有关系，黑盒测试一样可以发现这些问题，可能也不能全怪你开发背大锅，但是设计用例的时候应该提前想到

问题一，需要有解决方案测试，即拉通本模块和周边系统模块的场景及测试用例，保证业务功能在上下游是通的。如果只是各模块测自己的一亩三分地，通过 mock 验证各种本模块接口，这类问题还会出现的

自动化的话
直接 for i in range(7):
全部周一到周日测一遍不就行了吗