测试团队的新同事，甚至是有一定经验的同事都喜欢沉浸在探索bug的世界中不能自拔。乍一听这不是好事吗？测试人员不就是找bug的吗？
简单来说就是这种探索超出了范围（如用户需求、时间成本、人力成本等）。如果单纯的站在测试的角度来说那么没问题，测试人员可以无止境的探索可能的问题，但问题是现实中不需要或者说不能如此，测试的标准一定是要基于用户需求的，即使你自己就是用户，你也不可能要求不计成本的保证一个系统100%完美。
举个例子，假如有一个系统是用来处理订单，用户实际使用时处理的订单量并不大，同时使用的用户数也不多，如果你非得测测系统的并发、吞吐量之类的case那就是没事找事，甚至还提一堆性能bug，那都是完全没有必要的。当然这也可以归结于需求不明确，或者说测试人员对需求理解得不够。
要从商业利益的角度考虑。有些情况确实有一些问题，而且也几乎可以判断这是用户关心的，但是需求上没说，用户自己也并没有提出来，这时就要根据情况处理了，不能说有问题就一定要报告，就一定要修复，有的时候合同可能已经签完，再有超出需求的改动是要另算的，这涉及到公司的利益问题，当然了，如果单纯的作为一名测试人员也可以将问题提出来，至于如何处理就留待领导决定。
很多情况（用例）只存在于测试者眼中，我们应该根据情况有所为有所不为，特别是时间比较紧张的时候，如果你过多的探索不需要探索的区域那么肯定就会给其它重要的区域带来测试风险，这反而违背了你“做好事”的初衷。
如何改进测试方式和避免盲目探索呢？当然是熟悉需求，多熟悉系统相关的行业和业务逻辑，比如物流、餐饮、财务等等，对行业相关的业务有一定了解后你甚至可以判断出哪些部分是用户最关注的，从而有的放矢，避免吃力不讨好。
总而言之，测试的原则应该是在有限的时间内找出最有价值的bug。
源自公众号 软件测试相关