提交bug规范以及bug跟踪

你还只知道BUG六要素么？

常见的软件测试面试题：

一条软件缺陷（或者叫bug）记录包含了哪些内容？

标准答案是：

【标题、严重等级、前置条件、步骤（bug描述）、期望结果、实际结果】

实际上在我们日常软件测试过程中，提交一个bug，不仅仅是这6要素这么简单的事情。以下是个人总结了日常测试工作中常见的一些问题：

• 需求未设计？需求不明确？
• 服务端/前端的数据错误？
• 开发无法重现？能帮开发模拟下数据吗？
• 同类型bug合并？
• UI设计错误/数据展示错误？

个人总结了一个健全的缺陷，应该尽可能的包含以下内容：

 

 

需求未设计？需求不明确？

作为测试人员一般会在两个阶段遇到需求未设计或需求设计不明确的问题。

测试准备阶段：

这个阶段主要是了解需求，设计测试用例阶段，进行过程中发现需求设计不明确或者可能不合理的地方，及时向产品确认，当前阶段不需要提交缺陷（bug）。

确认结果一般有2种：

1.设计如此（不需要变更需求文档）

2.优化设计（若确认结果是优化设计，则要求产品及时更新需求文档，并将信息同步给开发，避免开发测试信息不对称）。

测试周期阶段

这个阶段是正式进入测试流程，执行测试用例+自由探索测试阶段，测试人员需要提交缺陷（bug）。深入真实测试过程中会发现开发实际设计不合理或者需求文档未明确设计的问题，此时测试人员需要提交缺陷（bug）给产品人员。

这个时候缺陷内容除了6要素之外，作为思考全面的测试人员，可以在【期望结果】内写下“建议”的期望，然后将缺陷指派给对应的产品人员，由产品人员确认后转交给开发进行修复解决。最后开发指派给测试进行验收。

数据错误？

测试过程中遇到数据错误时，在提交缺陷报告时，附件上传日志文件，日志文件除了能帮测试人员初步判断缺陷是属于移动端（app端）还是服务端之外，还可帮助开发快速定位缺陷原因。

日志文件的获取方式一般常用的有以下两种：

1. 抓包工具：fiddler/Charles

若为request（请求）错误，则缺陷（bug）应该指派给前端开发

若为response（响应）错误，则缺陷（bug）应该指派给服务端开发

1. 公司内部的日志系统：可要求对应的开发人员提供对应的日志关键字，方便查询过滤日志内容

（除了以上两种通用的外，还有其他的手法来获取日志）

 

无法重现/协助开发复现调试缺陷？

测试人员在提交缺陷后，经常遇到开发人员需要测试人员配合造数据来复现调试bug，此时测试人员不得不停下手上的测试内容，配合开发，浪费沟通成本。

测试人员可以在提交缺陷后，备注附上已准备好的测试数据供开发复现调试缺陷。

同类型bug合并？

测试过程中经常遇到不同页面路径，但是测试人员可以判断是同一个原因引起的缺陷时，可在提交缺陷时，提示开发一并排查，无需一个页面提交一个缺陷，增加人工提交缺陷的成本。

缺陷实例：

UI设计错误/数据展示错误？

遇到UI上的错误时，在提交缺陷时，除了文字描述外，可通过上传截图文件，且在截图上颜色标注出错误内容，方便开发快速理解缺陷内容。

缺陷实例：