目的：

作为测试，提交Bug是一项必备技能，而提交一个描述清晰、细化的Bug更为重要，避免开发将时间花费在问题确认和澄清上，保证效率最大化。

Bug报告的格式：

在我的工作中，Bug提交与跟踪管理都是采用Jira这个工具，此工具有可定制的字段来描述一个Bug，每次提交，只需要按照既定的模板来填写，就可以满足格式上的需求。

下面是它的格式内容和解释，实际可以按项目需要来选择一些字段共同组成一个“规范”的bug报告：

• 项目：必须，该bug所属项目。

• 问题类型：必须，缺陷（还可以是“改进”等）。

• 严重级别：必须，从用户角度出发，只考虑这个bug若出现对用户的影响程度，分为致命、紧急、严重、一般、提示这几个等级。

• 优先级：必须，从开发角度出发，处理这个bug的先后顺序，分为紧急、严重、重要、次要、微小这几个等级；一般而言，严重程度越高，优先级也越高，但并不是严格的联动关系，还需要衡量bug的出现概率和bug的修复代价。

  • 例如：一个严重级别为“严重”的bug，但是出现概率极低，且修复成本较大(耗时，难重现)，那么这个bug的优先级将不是“严重”，可能是“重要”或更低。

  • 再例如：一个严重级别为“一般”的小bug（文案类别），但是开发修复起来只是改一个文字的事情，几秒钟就完成，那么这个bug的优先级可能较高，为“紧急”也不为过。

• 到期日：非必须，测试认为该bug需要在哪一天解决，有些阻碍性的bug，必须尽快，就可以使用这个提示开发。

• 模块：非必须，该bug属于产品的哪一个模块，例如：客户端、服务器端、web前端、web后端。

• 影响版本：非必须，这个bug已经影响了哪些已有版本，尤其是影响的线上版本。

• 解决版本：非必须，必须在哪一个版本解决掉这个bug。

• 经办人：必须，这个bug是谁的，就交给谁。

• 出现环境：必须，出现的环境，测试环境、预生产环境还是线上环境。

• 主题：必须，这个bug的标题，尽量一句话描述，需要清晰地表述当前问题。

• 描述：必须，bug的详细描述：出现概率、出现前提、问题现象描述、期望结果、测试所用数据等对该bug理解和重现有帮助的信息。

• 附件：非必须，必须的附件、截图。

• 标签：非必须，方便筛选用的，非必要。

• 迭代：非必须，当前迭代周期。

• 测试人：必须，这个bug交给谁来测试。

• 关注人：非必须， 你希望关注这个bug的人。