发表于： 2018-09-22 20:45:08
1 626
今天完成的事情：复习了任务二
明天计划的事情：星期天
遇到的问题：
没有
收获：
bug等级
- 致命（一级bug）
通常表现为:主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用。
比如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循坏报错，无法正常退出。
- 严重（二级bug）
通常表现为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
比如：1. 功能未实现；2.功能存在报错；3.数值轻微的计算错误。
- 一般（三级bug）
通常表现为：界面、性能缺陷。
比如：1.边界条件下错误；2.容错性不好；3.大数据下容易无响应；4.大数据操作时，没有提供进度条。
- 4
提示（四级bug）
通常表现为：易用性及建议性问题
比如：1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4.界面格式不规范。
- bug管理流程
角色 | 职责 |
测试工程师 | 1. 根据规范提交bug； 2. 及时验证bug是否已解决； 3. 及时关注开发拒绝bug，和相关人员沟通讨论解决方式； |
测试经理 | 1. 审核测试工程师提交的bug； 2. 定期review bug，报告现状，并给出解决意见； |
开发工程师 | 1. 以优先级为依据分析解决bug |
开发主管 | 1. 定期 review bug，对bug多的模块加强code review和单元测试； 2. 分析bug解决进度，对产品质量及进度进行风险评估； |
产品 | 1、当开发和测试存在意见分歧时，进行需求确认 2、从产品角度划分bug修改的优先级； |
2. Bug书写规范
2.1主题
1. 以一个简短的句子描述某个模块存在的问题；或者某个操作导致了什么问题；
2. 描述问题时要简练、直接切入主题，但是要抓住要点；
3. 偶现bug在主题前标注出现的次数；
4. 有些模块功能比较多，可以在主题描述前标注上具体得操作；
示例：
【偶现3次】【账号切换】登录非本机手机号，切换回本机号码登录后，收不到消息
【偶现2次】添加载体库时程序停止运行
2.2描述
说明区域包括：步骤、预计结果、实际结果、测试环境、bug出现时间、截图、日志
1. 用数字编号，一步步的描述问题的重现步骤；
2. 不同的操作步骤产生不同的问题，需分别报bug；尽量做到一个bug汇报一个问题；
3. 偶现问题必须明确bug出现的时间、提供截图以及日志；
3 Bug跟踪类别
bug：测试人员判定为bug的问题；
优化：功能已实现，需要做性能优化的问题；
建议：测试对于产品的一些改进建议；
需求：需要产品重新梳理的需求问题；
4 Bug状态
新建：测试人员新提交的bug、优化或者建议的问题状态；
进行中：开发人员已确认是bug，需要修改的问题状态；
已解决：开发人员已修复的问题状态；
已关闭：测试验证，确定已解决的问题状态；
已拒绝：开发认为不是bug，拒绝给测试的问题状态；
反馈：反馈给产品确认的问题状态；
公认：确认是bug，但是无法解决的问题状态；
打回：测试验证已解决bug，仍然没有修复的问题状态；
5 Bug严重程度
致命：不能执行正常的功能操作，或者因产品原因导致系统死机，需马上修复的问题
示例：
程序无法启动，或者登录；
程序崩溃、停止运行，系统死机，无法进行下一步的操作
严重：部分功能存在严重缺陷，尚可继续测试，不影响产品稳定性；
示例：
偶现的程序崩溃、停止运行
功能未实现
数据不同步
功能错误，无法进行后续操作
一般：次要功能或者界面存在的一些错误，不影响正常测试；
示例：
界面UI显示和效果图不一致；
提示语不正确；
错别字；
查询结果显示错误
建议：测试对于产品的一些改进建议；
6. Bug优先级
低：对产品的影响比较小，在时间不允许的情况下可以暂时不修改；
中：必须修改，不一定马上修改，需讨论确定在某个特定的里程碑前修改完；
高：必须在版本发布之前修改完；
紧急：影响测试，需立即或者下一个版本修复；
1) 开发人员没有关闭bug的权限，所有问题均需经过测试验证无误后才可关闭；
2) 开发、测试双方有争议的bug，必须经过产品的确认才可进行下一步的操作；
3) 测试需及时验证已修复bug；
4) 产品人员可以根据产品的阶段性需求重新分配bug解决的优先级；
5) 重新指派bug后，需要口头或者QQ告知对方；
6) bug的优先级划分比较重要；
返回列表
评论