【项目问题】项目中的问题归类必要性

测试

我们不是看哪里都是bug,只是活的比较细致而已

1.功能是否符合需求:符合的定义是等于,多了,少了都是不符合预期

2.凡是影响使用都是问题:环境,数据,功能,体验,甚至于使用习惯,操作场景

3.功能使用范围:大众需要,小众需求,主要功能,特殊场景,异常情况

4.功能稳定性:使用时间多久,用户群是否固定

5.信息安全性

行话:项目中百分之八十的问题出在百分之二十的模块上

所以项目前:

测试可以提前预期哪里容易出问题,哪些逻辑需要重要关注,也为测试排期提供依据

项目中:

高级bug,问题反复的及时与开发沟通,明确信息一致性

需求问题,及时产品,开发一起沟通
没有阻碍bug,但bug数量较多,及时整体问题,与开发一起梳理问题,有顺序,有条理解决,并确定问题解决的deadline


及时跟进bug状态,开发解决后及时回归

1.验证后有问题方便开发再次跟进;

2.测试中验证bug,继续测试可以作为bug回归,节省时间;

3.避免bug积累,大量bug验证容易遗漏回归点;

4.将bug验证放在功能回归中,容易遗漏测试点,整体回归应该在稳定环境(没有问题,代码不在改动)执行

项目后:

 bug分类整理

开发角度:查看bug产生原因--自测问题,环境问题,数据问题,代码问题,其它

测试角度:查看bug功能类型--文案问题,前端问题,后端问题,使用问题,体验问题,场景问题

                  查看bug产生类型--新功能产生,优化产生,修复问题引出,环境问题,特殊数据导致

产品角度:查看bug影响--测试环境,线上环境,问题范围,评估影响,调整需求

原文地址:https://www.cnblogs.com/87060524test/p/10723666.html