很多项目都会遇到这种情况： 系统测试Bug收敛很慢， 每一轮系统测试都会发现新的问题，让整个团队士气低落， 对质量没信心 验收测试Bug很多，验收过程中，整个项目组都在疲于应付测试发现的问题。
一 真正的原因
系统测试不收敛是系统测试方法不对吗？ 验收测试问题多是系统测试做的不全面吗？ 从直接原因看， 是系统测试导致的。
系统测试问题不收敛
-
为什么系统测试Bug多？ 因为编码问题太多
-
为什么编码出了这么多问题？ 因为设计时没有考虑周全
-
为什么设计时没有考虑周全? 对所实现的内容理解不够深刻
验收问题多
-
为什么系统测试不全面？ 因为系统测试用例写的不全面
-
为什么系统测试用例写的不全面? 因为对实现的内容理解不深刻
二 缺陷在各阶段分布对软件质量的影响
2.1 各阶段缺陷分布统计图
Level 1 ~ level3 表明开发质量越来越好。
2.2 尽早地消除缺陷可以使交付产品的质量大大提高
2.3 尽早消除缺陷不仅可以提高质量， 更重要是降低成本
设计->开发->测试->客户阶段修复缺陷的成本是成比例上升的， 大约是1：10：100：1000
三 理想Bug分布
所以， Bug多的真正原因不是系统测试，而是设计做的不好导致。
四 如何保证做好分析和设计
问题的原因找到了， 看似很简单，但是要解决这个问题其实并不容易。 开发人员都有一个特点着急写代码，因为最终任务交付的就是他们的代码。怎么让每一个开发人员将分析和设计过程当成一个重要的任务， 怎么对其进行检查和督促？ 如何确认分析和设计确实真正深刻理解了？ 互动交互的方式进行检查 项目成员根据自己感兴趣的任务进行分析， 但是要保证每个点有2～3人（太多也不好）同时分析， 每个人都要讲哦。 分析的内容要进行量化， 讲解的内容要尽量保证2个小时可以讲完（太多了效果不好） 讲解过程中，每个人都进行提问和参与讨论。 如果讲解人讲的每个人都听懂， 并且能回答提出的问题。 讲解人和听的人都人为理解透彻了，那么这个分析就通过。 迭代完成每一个任务 采用交互的方式不仅可以对讲解人起到一个督促作用， 讲解和讨论更能让分析全面。通过review的方式不会有互动的效果。 同时还可以筛选谁更适合做那一个任务。
想不到就做不到， 编码和系统测试都一样， 没有分析到位， 编码就会有漏洞， 系统测试就会遗漏测试点。 无论做什么事情，保证“一次把事情做好”，才是最好的方式。但是我们总犯急于求成， 到最后了为以前的偷工减料付出更多的代价。 所以，我们需要采用正确的方法和流程保证我们“一次把事情做好”。
