高效提BUG

软件缺陷的判定准则

• 软件未达到产品说明书标明的功能；

• 产品说明书简称为说明（spec）或产品说明（product spec），是软件开发小组 的一个协定。它对开发的产品进行定义，给出产品的细节、如何做、做什么、 不能做什么。这种协定从简单的口头说明到正式的书面文档有多种形式。

• 软件出现了产品说明书指明不会出现的错误；

• 如金融软件 7*24 工作不能宕机

• 软件功能超出产品说明书指明范围；
• 软件未达到产品说明书虽未指出但应达到的目标；

• 如软件在断电时的意外处理

• 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

• 主要体现在易用性方面。

软件缺陷的表现形式

• 用户要求的功能、特性没有实现或部分实现。
• 运行出错，包括运行中断、系统崩溃、界面混乱等。
• 数据结果不正确、精度不够、不完整或格式不统一。
• 文字显示内容不正确或拼写错误。
• 系统性能低下、系统资源浪费。

 分离和再现软件缺陷

• 发现缺陷后，应该做好分离和再现，排查发现的“缺陷”是不是软件本身的问题， 然后才能提交。
• 再现 3 次

• 重现
• 复现
• 避免提交缺陷的缺陷和重复缺陷

• 缺陷的缺陷

• 是测试人员提交的不是缺陷的缺陷；
• 是一种无效缺陷；
• 此类缺陷常使测试人员遭受指责。
• 怎么办

• 正确理解需求；
• 做好复现。

• 重复缺陷

• 同一个缺陷 A 测试工程师提交后，B 测试工程师又提交或者自己提交的缺陷 与之前提交的缺陷相同或类似；
• 是一种无效缺陷；
• 怎么办

• 尽量避免两个人同时测试同一模块；
• 自己提交的缺陷与自己的重复，提交前查找一下，增强开发知识。

 处理无法再现的缺陷

• 首先，对这样的缺陷进行详细的记录，使用不同办法去尝试复现。
• 其次，要合理地安排时间，要考虑到测试项目的整体进度，对一时难以再现的缺陷 可以暂时搁置，以保证项目的正常进度，并尽快提交给开发人员。
• 最后，在测试过程中对未再现缺陷予以关注。

7. 处理有争议的缺陷

• 跟有关人员进行沟通、讨论；
• 搁置。

 缺陷报告的读者对象

• 软件开发人员

• 报告缺陷是为了缺陷得到修复。
• 希望获得缺陷的本质特征和复现步骤。

• 质量管理人员、市场人员、技术支持人员

• 希望获得缺陷的严重程度和分布情况，以及对市场和用户的影响程度。

3. 缺陷报告的写作准则（5C）

• Correct（准确）

• 每个组成部分的描述准确，不会引起误解；

• Clear（清晰）

• 每个组成部分的描述清晰，易于理解；

• Concise（简洁）

• 只包含必不可少的信息，不包括任何多余的内容；

• Complete（完整）

• 包含复现该缺陷的完整步骤和其他本质信息；

• Consistent（一致）

• 按照一致的格式书写全部缺陷报告。

4. 缺陷报告的组织结构

• 缺陷的标题/缺陷摘要/缺陷概述/缺陷基本信息
• 预处理
• 复现步骤
• 期望结果
• 实际结果
• 缺陷的严重程度
• 缺陷的优先级
• 测试的软件和硬件环境
• 测试的软件版本
• 缺陷的类型
• 注释文字和缺陷截图

5. 缺陷报告的写作要求

5.1 缺陷标题

• 尽量按缺陷发生的原因与结果的方式书写；

• 执行完 A 后，发生 B；
• 在什么地方，做了什么事情，出了什么结果；

• 使用“在…以后”，“在…时候”或“在…期间”等连结词有助于描 述缺陷的原因和结果。

• 避免使用模糊不清的词语；
• 为了方便搜索和查询，尽量使用关键字；
• 为了便于他人理解，避免使术语、俚语或过分具体的测试细节。

5.2 复现步骤

• 提供测试的预备步骤和信息；
• 步骤完整，准确，简短，没有缺漏任何操作步骤，没有任何多余的步骤；
• 将常见步骤合并为较少步骤；
• 简单地一步一步地引导复现该缺陷；
• 每一个步骤尽量只记录一个操作；
• 每一个步骤前使用数字对步骤编号；
• 尽量使用短语和短句，避免复杂句型和句式；
• 只记录各个操作步骤是什么，不要包括每个步骤的执行结果。

5.3 预期结果

• 软件应该具有的结果，或者说正确结果应该是什么样子。

5.4 实际结果

• 实际结果的描述要列出具体的表现行为，而不是简单的指出“不正确”或“不起作 用”。
• 如果一个动作产生彼此不同的多个缺陷结果，或者一个动作将产生一个结果，而这 个结果又产生另一个结果。为了易于阅读，这些结果应该使用数字列表分隔开来。 如实际结果：

• 1.显示“命令代码行…错误”；
• 2.显示“并且终止…服务”。

5.5 注释/截图

• 可以包含以下各方面的内容：

• 截取缺陷特征图像文件；
• 测试过程所使用的测试文件；
• 测试附加的打印机驱动程序；
• 再次描述重点，避免开发人员将缺陷退回给测试人员补充更多信息；
• 再次指明该缺陷是否在前一版本已经存在；
• 多个平台之间是否具有不同表现；
• 注释包含缺陷的隔离信息，指出缺陷的具体影响范围。

• 如，缺陷的注释可能包含下面的内容：

• 能在 Win2000 和 WinXP 文本框中显示文本内容，但不支持 Win98
• 屏幕刷新后，现象会消失。
• 使用二进制文件，不存在该错误。
• 参见附加的使用说明书和测试文件。

6. 怎么提交高质量的缺陷报告

• 尽早提交缺陷报告。
• 清楚地说明此问题对用户价值的危害。
• 提供尽可能多的技术信息（如包含复现该缺陷需要的环境变量或测试所用的数据文 件），方便程序员调试。
• 报告的软件缺陷进行了必要的隔离，报告的缺陷信息具体、准确。
• 易于搜索软件测试报告的缺陷。
• 一个缺陷报告中只报告了一种缺陷。
• 缺陷报告中不要提问题。
• 避免常见的错误  我（I）、你（You）、他/她（He/She）

• 情绪化的语言和强调符号！！！
• 似乎（Seems）、看上去可能（Appears to be）
• 认为比较幽默的内容
• 不确定的测试问题（Issues）/不确定是否是缺陷

 

如何有效的报告缺陷？

单一准确：每个报告只针对一个缺陷，如果有多个缺陷，可能开发只修正了其中一个，其他的没有得到修改，加长了缺陷的生命周期

可以再现：不能忽视或省略任何一项操作步骤，特别是关键性的操作，如描述的不够清楚，RD（Research and Development engineer）就会过来沟通怎么操作的，浪费了大家的时间

完整统一：完整的描述信息

短小简练：使用关键词

特定条件：有些问题只在特定环境下存在

 

缺陷报告的重要组成

(1) 编号

提交缺陷的顺序

(2) 标题

简明扼要的描述缺陷

(3) 发现者

谁发现的缺陷，比如工号、用户名、姓名等

(4) 发现日期

提交缺陷的系统日期，一般是当天

(5) 所属模块

哪个功能模块发现的缺陷（方便开发经理根据模块定位该缺陷的负责人）

(6) 所属版本

在软件哪个版本发现的缺陷，如XX系统vYYYY-MM-DD;或XX系统version X.X.X

(7) 指派给谁

测试人员将缺陷指派给开发经理，开发经理会根据该缺陷所在模块再次指派给具体开发人员

(8) 缺陷状态

 

(11) 缺陷描述

把发现缺陷的过程、步骤、使用的数据等记录下来，使开发人员通过该描述再现该Bug

需注意问题：

①　单独记录每一个缺陷，不要把两个或者多个缺陷记录在一起

②　缺陷描述要清晰准确易读，使用必要、量少的步骤保证缺陷复现

③　对缺陷的严重程度和优先级别的划分要准确、客观

④　提交缺陷报告前要认真审核，确保提交的缺陷为有效缺陷

⑤　不要为了引起开发人员的重视而夸大缺陷

⑥　小的缺陷也需要记录缺陷报告

⑦　及时报告缺陷（给开发人员留一些充足的修复时间）

⑧　对发现的缺陷不做任何评价（随意评价缺陷，很容易伤开发人员的心哦）

⑨　随机缺陷也要报告（随机缺陷不易重现，按照固定步骤时有时无，所以需要表明它是随机缺陷，尽量详细描述其出现的步骤，以及出现的频率等）