目录
一, 报告缺陷注意事项
二, 如何编写缺陷报告
在一些项目中, 缺陷报告是测试工程师最主要的工作输出. 一份好的缺陷报告可以帮助开发人员快速定位问题, 帮助产品经理了解缺陷的严重性及用户质量信息, 同时可以快速确定修复优先级; 项目周期的例会中, 可以有效提高会议效率; 如果是在测试作为第三方公司提供时, 项目组会以缺陷报告的质量来评估该测试人员的工作能力和职业素养. 所以, 编写出高质量的缺陷报告是测试人员重要基本功之一.
首先, 报告缺陷的目的是解决缺陷, 但是由于项目组中每个角色分工不同, 对待缺陷站的立场也不同, 做出具有说服力且完善的缺陷报告非常重要.
提交缺陷时描述清楚问题产生步骤及严重级别.
测试过程中, 测试人员经常遇到的问题是提交的缺陷被开发以无法重现打回, 或者提交的用户建议被需求标注为不予修复. 测试人员不能清楚描述出问题步骤或没有标出具体发生环境或工具时, 开发按照自己的环境去复现很可能失败, 而提的用户建议若未说明其对用户的影响程度时, 也会因工期原因被产品不予修复.
每个公司对缺陷报告的评审人不尽相同, 这就需要测试人员从多个角度向评审人来传递正确有效的信息. 使用 Bug 管理工具时, 特别注意选择好优先级, 如果是自己本地提交, 也需要注明优先级, 测试时, 我们要始终站在用户的角度去思考, 而不是由开发人员自己去给 Bug 定义是否重要. 其次测试人员需要关注测试的网络服务是否输出了足够的日志, 长远来看, 更多的日志有利于测试更快地发现错误并定位问题. 而不是一直让自己保持在黑盒状态. 另外, 如果发现了兼容性问题, 比如执行特定操作时, 在弱网情况下会发生页面异常, 类似的问题需要测试人员自己评估严重性, 阅读需求规格说明书, 询问相关需求人员, 该特定操作可能出现的频率及特定用户使用习惯等等.
2. 尽早提交缺陷报告
项目周期临近结束时, 如果再有新的 Bug 提交 , 开发会评估可能引入新的缺陷, 而且修复完成测试需要回归整个 Module, 或者对于风险较高的缺陷暂不修复. 所以测试人员需要做的是, 做测试计划时制订好测试策略, 尽量在项目前期发现严重级别的 Bug; 同时编写的缺陷报告尽早提交 .
3. 对于难以重现的 Bug 也要全部提交
如果一个项目同时多个测试的话, 尽量避免提交重复 Bug;
一轮测试通过后, 可以在 Bug 管理系统中检索下 Bug 分布情况, 如按模块, 按功能, 按类型看哪部分问题分布相对多, 则很可能该处会隐藏更多 Bug.
测试人员不能判断是否是 Bug 时, 可以先记录下, 如果涉及到核心功能, 可以及时询问需求人员. 但不能遗漏.
对于难以重现的 Bug, 测试人员需要尽早记下所有相关信息, 并标注重现频率 . 尽可能多试几次 , 由哪些特殊因素触发.
针对难以重现的 Bug, 一来可以利用服务器日志来查询报错内容, 二来在测试之前可以部署相应的录屏工具来解决.
来源: http://www.bubuko.com/infodetail-2484872.html