软件测试基础知识01—软件缺陷

1.软件缺陷（Bug）的定义

定义：被测软件（系统）中存在破坏其正常运行能力的问题、错误（隐藏的功能缺陷、瑕疵）。
具体体现如下：
1).软件未实现产品规格说明书要求的功能。
2).软件出现产品说明书指明不会出现的错误。
3).软件超出实现了产品说明书要求的功能。
4).软件未实现产品说明书虽未明确指出但应该实现的目标。
5).软件难以理解，不易使用，运行缓慢或者终端用户体验不佳。

2.软件缺陷的种类

1).功能、特性未实现或部分实现。
2).设计不合理，存在缺陷。
3).实际结果与预期结果不一致。
4).运行出错，包括运行中断、系统崩溃、界面混乱。
5).数据结果不正确、精度不够。
6).用户不能接受的其他问题，如存取时间过长、界面不美观。

3.软件缺陷的严重级别

1).致命的
致命的错误：造成系统或应用程序崩溃、死机、系统悬挂，或造成数据丢失、损坏、主要功能完全丧失等。
2).严重的
严重错误：功能或特性没有实现，主要功能部分丧失，次要功能完全丧失，或致命的错误声明。
3).一般的
次要功能丧失，提示信息不太准确，或用户界面差，操作时间长等。
4).微小的
对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等。
5).建议的
程序员处理测试人员所提出的建议或质疑，如建议程序做适当的修改，来改善程序运行状态，或对设计不合理、不明白的地方提出质疑。

image.png

4.软件缺陷的修复优先级

1).最高优先级：立即修复，停止会进一步测试。
2).次高优先级：在产品发布前必须修复。
3).中等优先级：如果时间允许应该修复。
4).最低等优先级：可能会修复，不修复也能发布。

注意：
1).一般严重性和优先级的划分用数字１～４表示，有的小数字表示的级别最高，而有的用大数字表示级别高。
2).严重级和优先级的划分并不唯一，可适当修改。

5.软件缺陷的生命周期(主要状态)

新建、打开（确认、拒绝）、修正（延迟、挂起）、关闭（重新打开）

新建(New)： 测试中新报告的软件缺陷；
打开(Open)： 被确认并分配给相关开发人员处理；
修正(Fixed)： 开发人员已完成修正，等待测试人员验证；
拒绝(Declined)： 拒绝修改缺陷；
延期(Deferred)： 不在当前版本修复的错误，下一版修复；
关闭(Closed)： 错误已被修复；
重新打开(Reopen)： 错误未解决，重新开启。

测试人员提交新发现的缺陷入库，缺陷状态为“New”，
高级测试人员验证错误，
如果确认是错误，则分配给相应的开发人员，设置状态为“Open”，
如果不是错误，则拒绝，设置为“Declined”状态，
开发人员查询状态为“Open”的缺陷，对其进行处理，
如果不是错误，则状态置为“Declined”，
如果是错误，则修复并置状态为“Fix”，
如果不能解决，要留下文字说明并保持缺陷状态仍为“Open”，
对于不能解决或者延期解决的缺陷，不能由开发人员自己决定，一般要通过某种会议（评审会）才能认可
测试人员查询状态为“Fix”的缺陷，验证缺陷是否已解决，做如下处理：
如果问题解决了，置缺陷的状态为“Closed”，
如果问题没有解决，则置状态为“Reopen”。

6.软件缺陷的特征

1).“看不到”
——软件的特殊性决定了缺陷不易看到
2). “看到但是抓不到”
——发现了缺陷，但不易找到问题发生的原因所在

7.软件缺陷的分布

图片1.png

8.BUG管理工具（推荐）

1).禅道
2).TestDirector (Mercury Interative)

9.软件缺陷管理

1).Bug记录信息
测试软件名称
测试版本号
测试人名称
测试用例
标题
测试软件和硬件配置环境
发现软件错误的类型
错误严重等级
详细步骤
必要的附图
发生错误的模块…

2).Bug处理信息
处理者姓名
处理时间
处理步骤
缺陷记录的当前状态

3).Bug处理流程原则
为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重现。
每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug状态。
拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。
错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。
加强测试人员与程序员的交流，对于某些不能重现的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。

4).Bug编写规范
标题：应保持简短、准确，提供缺陷的本质信息。
尽量按缺陷发生的原因与结果的方式书写。
避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状。
为了便于他人理解，避免使用术语、俚语或过分具体的测试细节。
复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。

常见问题：
包含了过多的多余步骤，且句子结构混乱，可读性差，难以理解；
包含的信息过少，丢失了操作的必要步骤；
没有对软件缺陷发生的条件和影响区域进行隔离。

复现步骤的正确书写方式：
提供测试的环境信息；
简单地一步步引导复现该缺陷，一个步骤包含的操作不要多；
每个步骤前使用数字对步骤编号；
尽量使用短语或短句，避免复杂句型句式；
复现的步骤要完整、准确、简短；
将常见步骤合并为较少步骤；
按实际需要决定是否包含步骤执行后的结果。

实际结果：是执行复现步骤后软件的现象和产生的行为。
实际结果的描述应像标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”。
期望结果：描述应与实际结果的描述方式相同，通常需要列出期望的结果是什么。

附件：
对缺陷描述的补充说明，可以是以下一些类型：
缺陷症状的截图；
测试使用的数据文件；
缺陷交流的记录，例如相关邮件等；
解决缺陷的补丁程序。

其它：
选择合适的缺陷严重性属性；
按相应的规定，填写相应的字段信息。

避免常见的错误：
避免使用我、你等人称代词，可以直接使用动词或必要时使用“用户”代替
避免使用情绪化的语言和强调符号；
避免使用诸如“似乎”、“看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果；
避免使用自认为比较幽默的语句，只需客观地描述缺陷的信息；
避免提交不确定的测试问题，自己至少需要重现一次再提交。

10.Bug的数据分析

1).Bug数据关注的问题
正在测试的软件哪个模块的问题最多？
测试人员中谁报告的软件缺陷最多？
各类缺陷所占的数量百分比分别是多少？
开发人员能及时修复软件缺陷吗？
开发人员一次正确修复缺陷的百分比是多少？
正在开发的软件能否在计划的时间内正常发布？
。。。
2).Bug数据分析的重要性
统计未修复的缺陷数目（特别是严重性高的缺陷），预计软件是否可以如期发布。
分析缺陷的类型分布，发现存在较多缺陷的程序模块，找出原因，进行软件开发过程改进。
根据测试人员报告缺陷的数量和准确性，评估测试有效性和测试技能。
根据报告的缺陷修复是否及时，改进软件开发与测试的关系，使测试与开发更有机的配合。
3).Bug数据分析的数据指标
每天/周报告的新缺陷数目；
每天/周修复的缺陷数；
累计报告的缺陷数目；
累计修复的缺陷数；
不同严重性类型的缺陷数；
程序模块与发现的缺陷的对应关系；
。。。