项目快要上了，昨天BOSS过来开会，提及品质部发现的BUG太少，问其原因。。。
按照现在的项目进展BUG应该会有不少，但实际确只有N个
答：需求不明确，各种不明确。测试没有一个完善的标准，去衡量。
项目延期何因？
答：各种推翻重做，需求变更过于快。
测试的覆盖度不够，如何解决？
答：增加测试用例的三方评审
--------------------------
下来仔细分析了下原因：
1、测试内部人员个人能力，新人无法准确定位，或者说是无法分辨出何为BUG。遗漏15%
2、部门内部缺陷少沟通，对交叉系统的测试覆盖度过底，遗漏10%
3、多人测试的场景模拟的过少，遗漏减少10%
4、需求不明确，遗漏35%
5、测试管理层面对新人的引导，不足，引起新人对常规缺陷的判断能力及分析能力不足。遗漏10%
6、需求变更过于频率，遗漏10%
7、测试用例覆盖度不足，遗漏10%
解决方案：
1、加强对新人的业务能力的培训，做好组长引导新人，主管引导主管的模式。增加新人定位问题的能力
2、部门内部两周组织0.5天的交叉冒烟测试，确保交叉测试的覆盖度
3、每周组织0.5天的多人在线测试环境，尽可能模拟多人在线操作
4、与策划、程序沟通，确保三方对需求的理解在一个层面上
5、加强新人对游戏表现层面、脚本层面、实现层面的理解，做相关培训
6、再有需求变更时，应与主管及别策划商议后，再提及测试、程序进行研发
7、增加三方评审测试用例，加强测试执行前用例覆盖度
与其它部门沟通结果：
1、策划完善需求文档
2、在需求确定后，开三方会议，增强程序、策划对需求的理解
3、测试用例进行三方评审，确定测试用例的覆盖度
4、签字流程，每个系统在设计后，需要有三方签字，确认各自的完成时间