Bug优先级划分

切换Jira后，Priority分为P0、P1、P2、P3四类。

由于不同Priority的Bug，重视程度不一样，因此整理一套Kion Bug规范。

>> 描述

1、必现且阻塞流程的Bug；

2、偶现概率 >= 50%，影响功能正常使用的Bug；

>> Example

1、必现的软件崩溃；

2、影响主流程；

3、严重的数值错误；

4、其他导致无法测试的错误，如接口500；

>> Comments

1、影响上线；

2、8小时内，必须在当天解决；

>> 描述

1、必现且影响较大，但不阻塞流程的Bug；

2、偶现概率 < 50%，影响功能正常使用的Bug；

>> Example

1、只在某特定 *** 作下才出现的较严重Bug

2、严重的界面错误

>> Comments

1、影响上线；

2、24小时内，且必须在进入第二轮测试前解决；

（P0/P1不好判断时，可通过期望的解决时间来判断）

>> 描述

1、普通的功能Bug，除其他优先级之外的Bug

>> Example

1、与需求不符的普通Bug

>> Comments

1、影响上线；

2、2天内，必须在进入Prod前解决；

>> 描述

1、低优先级Bug，不影响上线；

2、偶现概率 < 5% 的Bug；

3、界面/边界/兼容性/建议性/易用性Bug

>> Example

1、UI小问题；

2、低频且影响不大的问题；

>> Comments

1、不影响上线；

2、可以放到下个版本解决。

一是项目经理通过和客户的交流，完成需求文档，由开发人员和测试人 员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地 方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合 开发人员，测试人员以及客户的意见，完成项目计划。然后sqa进入项目，开始进行统计和跟踪。
二是开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或 者双方理解不同的地方。测试人员完 成测试计划文档，测试计划包括的内容上面有描述。
三是测试人员根据修改好的需求分析文档开始写测试用例，同时开发人 员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写 测试用例的补充材料。
四是测试用例完成后，测试和开发需要进行评审。
五是测试人员搭建环境
六是开发人员提交第一个版本，可能存在未完成功能，需要说明。测试 人员进行测试，发现 bug 后提 交给 bugzilla。
七是开发提交第二个版本，包括 bug fix 以及增加了部分功能，测试人员进行测试。
八重复上面的工作，一般是 3-4 个版本后 bug 数量减少，达到出货 的要求。
九是如果有客户反馈的问题，需要测试人员协助重现以及回归测试。
在传统的 bugzilla 中，bug 描述应该包括以下的信息：① 和 bug 产生对应的软件版本；② 开发的接口人员；③ bug 的优先级；④ bug 的严重程度；⑤ bug 可能属于的模块，如果不能确认，可以用开发人员来判断；⑥ bug 标题，需要清晰的描述现象；⑦ bug 描述，需要尽量给出重新 bug 的步骤；⑧ bug 附件中能给出相关的日志和截图。
高质量的 bug 记录就是指很容易理解的 bug 记录， 所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。

当年，令狐大侠以其独孤九剑笑傲江湖，不知打败了多少江湖好手。其运作原理就是，无招胜有招，剑锋专指敌方破绽。满手的进攻招式。步步进逼，连防御都省却了。他说：天下武术千变万化，神而明之，存乎一心。不论对方的招式如何精妙，只要是有招，便有破绽
而游戏程序呢，我想也是一样的。虽然程序变化万千，但却不离其宗。无论多么完善的程序，多么敬业的程序开发人员，做过多少遍测试，只要是程序，终究都会有BUG,不要说你找不出破绽或者程序干脆没有破绽一类的话，当年令狐冲学剑的时候曾说：即使我瞧不出破绽，未必便是真无破绽，只是瞧不出罢了．
如何找BUG呢方法就是利用逆向思维和举一反三来寻找BUG的,只要有程序的地方，那就有BUG，只要掌握了正确的方式方法，找出BUG只是时间与机缘的问题。

1、定位bug是指找到BUG的本质(找到必现路径)、提升开发修复BUG的效率、提升自身的逻辑思维与技术能力。
2、修改bug是指修改了运营商权限范围内的漏洞，多出现在软件或应用更新。

---