高效提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
需注意问题:
① 单独记录每一个缺陷,不要把两个或者多个缺陷记录在一起
② 缺陷描述要清晰准确易读,使用必要、量少的步骤保证缺陷复现
③ 对缺陷的严重程度和优先级别的划分要准确、客观
④ 提交缺陷报告前要认真审核,确保提交的缺陷为有效缺陷
⑤ 不要为了引起开发人员的重视而夸大缺陷
⑥ 小的缺陷也需要记录缺陷报告
⑦ 及时报告缺陷(给开发人员留一些充足的修复时间)
⑧ 对发现的缺陷不做任何评价(随意评价缺陷,很容易伤开发人员的心哦)
⑨ 随机缺陷也要报告(随机缺陷不易重现,按照固定步骤时有时无,所以需要表明它是随机缺陷,尽量详细描述其出现的步骤,以及出现的频率等)