这是《落叶》文集里第 208 片落叶，希望你能喜欢，不为别的，只为这份坚持。
【背景】
请问最科学的对待bug的心态是怎样?
如果追求在一次测试中尽可能多地发现bug，铺天盖地地写测试点，导致进度缓慢，工作强度过大。个人认为这是一种比较偷懒的思维方法，不能有的放矢，胡子眉毛一把抓。哪些测试点是可以在“本次测试”中放过的?个人认为:不涉及需求功能实现的测试点，可以在以后更新版本的时候再测。
这是今天小密圈的朋友发起的讨论，正好契合当下实际项目里遇到的测试策略问题，所以就多说了一些，再补充整理一下，作为此问答。
【你问】
最科学的对待 Bug 的心态是怎样的?
【我答】
我觉得这是很多优秀测试工程师的“通病”，他们能发现很多深层次和细微的问题，如果把一个项目给他们测一个月，60%~70%以上的 bug 肯定都给挖出来了。
可是他们有一个问题，就是容易陷入问题的细节，从一个问题点垂直且延展测试下去，而忘了当前阶段的测试目的和测试重点，等酣畅淋漓地挖了一堆 bug 出来之后，才发现，阶段性进度严重 delay 了。
比如，某个项目需要在三天内完成测试，用于客户演示，所以这三天对质量的要求其实就是保证主流程通畅和逻辑正确，演示所需要展示的页面不能有明显的错误。那这个阶段的测试策略，就不能发散或者深入，而是需要快速扫清主流程路上的逻辑性问题，确保正向的场景可以正常使用。
在完成上述测试之后，再深入展开，分层细测也不迟。Bug 是永远都找不完的，而且并不是说，在任何时候，找 Bug 都是最重要的事情，我们得看具体的测试策略，也不管具体的质量要求和测试目标，不管什么项目，什么产品，什么阶段，拿到就进行详尽的测试，往往会适得其反，也许你保证了质量，却丢失了最重要的：时机。
因为不同的阶段，有不同的测试目标，针对不同的测试目标，我们应该采取相应的测试策略。而前文中说的很多优秀测试工程师的“通病”，其实根源在于：不擅长在项目的不同阶段采取不同的测试策略。
有同学通过定义用例级别来解决这个问题，从方法上是可行的。我们可以在做用例设计时，将用例分成1/2/3等级，这个等级的定义可以依据测试深度或主次分支，不同阶段可以选择相应级别的用例执行，让测试人员完全按照用例去严格执行。
不过，这种方法有几个弊端：
1、现在的很多互联网项目中，测试设计不需要细到 case 级，只是分析到测试点层面，具体的测试执行，需要测试工程师根据测试点再做更细一层的测试；
2、如果要求测试工程师严格按照测试用例去执行测试，势必会约束到他们的创造性和发散性思维；
3、测试用例的持续维护和及时更新，包括对测试用例的筛选和归类，也会耗费相当大的人力；
所以，想要从根本上解决这个问题，还是需要测试工程师提高自身的测试策略认知，以及测试分析能力的应用。
《测试路上你问我答》里的 Q&A 66，如果是你要的，甚好！如果不是，你问，我答！
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
