软件开发出来之后一般经过了发布，之后会上线商用，如果说此前的测试是实验室的验证的话，那么此时就是真正考验软件质量的时候了，真实的复杂组网，海量的数据，实际的用户规模等等。在这样的情况下，质量不过硬的版本往往过不了关，死机，内存泄露，明显的功能遗漏，挂死，用户体验差等等。此时大量问题出现的时候，项目经理往往会问，“为什么没有发现这些问题？”，作为测试经理面对此问题，如何思考？

　　在《A Practitioner's Guide to Software Test Design》的前言，有这么一段：

　　Today's Testing Challenges

　　For any system of interesting size it is impossible to test all the different logic paths and all the different input data combinations. Of the infinite number of choices， each one of which is worthy of some level of testing， testers can only choose a very small subset because of resource constraints. The purpose of this book is to help you analyze， design， and choose such subsets， to implement those tests that are most likely to discover defects.It is vital to choose test cases wisely. Missing a defect can result in significant losses to your organization if a defective system is placed into production.

　　测试面临的挑战是在有限的资源下，选择测试无穷集的子集，就是某人说的“测试就是赌博”，就看怎么选择这个子集，才能让我们的赢面越大。

　　面对“为什么没有发现这些问题？”这样的问题，我们更应该去反思版本发布前测试选择的子集是否有所偏差，是否把资源投入到了风险最高的地方，测试设计是否存在明显的漏洞。

　　1、什么是风险最高的地方，这就需要测试人员对于项目有充分的了解，对外理解软件开发出来是给谁用的，什么样的客户；对内清楚认识软件开发中的人员状态，项目状态。了解清楚是给谁用的，那么就需要了解可以实际会如何使用，有条件的话到客户实际的环境体验一下他们的作息时间，工作环境，软件运行环境等，并了解客户的知识结构组成（小白用户？专业级用户）等，收集这些信息识别出对外交付风险。软件开发中及时掌握设计/开发人员工作状态，交付件（代码）的质量，项目的紧急程度，识别风险点，适时调整策略。

　　2、测试设计是否存在明显的漏洞？ 测试人员需要掌握基本的测试设计方法，在项目测试测试中灵活运用，确保把时间都花在了刀口子上，利用工具，方法减少无用功，增加赢面。

　　回到这个问题“为什么没有发现这些问题？”，通过以上2点，从测试的角度去分析，基本上能够回答这个问题，理论上，‘马后炮’的说法，所有的问题都是可以测试出来的，那么从改进的角度我们更应该是分析之前的盲点，测试设计确实遗漏了？没有充分了解客户的需求？，策略性的放弃了？进一步，更应该去分析开发过程中的薄弱点，有这么一个比喻“测试是代码他爸，开发是代码他妈”，问题（BUG）是开发生产出来的，作为父亲的测试应该严格的对代码进行‘教育’，那么分析中就必须包括回忆开发过程中漏洞，是否本身就是复杂度比较高，容易弄错；模块之间的交互沟通失误等等，另外很重的一点，摘自《软件测试经验与教训》，关于软件版本发布：

　　最终，要由控制项目、条件最好的人承担发布产品的责任。但是我们所看到的大多数非常有效的项目团队，都采用某种方式的集体决定是否发布产品。如果读者被授权决定产品的发布，我们建议毫不犹豫地立即坚持与项目团队的其他角色一起分担这种权力。

　　请邀请你的项目关键角色和你一起分担这种权利。