BUG 太少

项目快要上了，昨天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、签字流程，每个系统在设计后，需要有三方签字，确认各自的完成时间