软件缺陷。0520

1、什么是软件缺陷

（1）不符合设计要求；（2）不满足用户确定需求

2、产生缺陷的原因

（1）人员之间的沟通交流不够，交流上有误解或者根本不进行交流
（2）工期短，任务重，时间压力大
（3）参与人员的过度自信
（4）文档不完善
（5）需求不停变化
（6）软件复杂性
（7）程序设计本身有错误
（8）软件开发工具或系统软硬件自身含有缺陷

3、如何有效的记录缺陷？

（1）保证重现缺陷
（2）包含所有重现缺陷的必要步骤
（3）分析故障——使用最少步骤复现故障
（4）报告不能重现的缺陷
（5）方便阅读
（6）尽量简单——一个缺陷一个报告
（7）小缺陷（甚至建议）也要报告
（8）不能夸大缺陷
（9）注意自己的语气
（10）引用别人的报告时，不能修改，可以添加批注之类的补充评论

4、判断发现的问题是否是缺陷的方法

（1）通过参考文档来确认缺陷；
（2）通过了解软件产品的行业背景（或参考同类典型软件）来发现缺陷；
（3）通过沟通来确认和识别缺陷；

• 再现与优化缺陷；
  （1）再现（又叫重现）与优化缺陷的必要性；
  （2）为什么要再现与优化缺陷（需要特别注意，优化缺陷并不是指优化缺陷本身，而是优化缺陷的再现步骤）；
  （3）关于软件中“随机”出现的缺陷；

5、缺陷报告的用途

记录缺陷；缺陷分类；缺陷跟踪；

6、一个缺陷报告中都包含哪些内容？

缺陷编号、Bug 所属模块、Bug 描述、实际结果、预期结果、Bug严重程度、Bug 级别、发现日期、发现人、修改日期、修改人、解决方案、回归结果、备注等

7、缺陷的分类

• 按问题引出不同
• 按功能（模块）
• 按缺陷的严重程度
  （1）影响进度的问题
  （2）死机
  （3）功能问题
  （4）界面问题
• 按修复缺陷的优先级
  （1）应立即修复的问题
  （2）在产品发布之前必须修复的问题
  （3）如果时间允许应该修复的问题
  （4）可以在发布版本中存在的问题
  备注：缺陷的严重程度和优先级各软件公司可根据实际情况自行确定

8、缺陷报告的分类

• 按缺陷所处状态分类
  （1）待确认的
  （2）新提交的
  （3）已分配的
  （4）问题未解决的
  （5）待返测的
  （6）已关闭的
• 按处理意见分类
  （1）已解决的
  （2）不是问题
  （3）无法修复
  （4）延迟解决
  （5）重复bug
  （6）无法复现

9、缺陷的处理流程

10、关于处理缺陷

（1）注意缺陷报告的处理成本
（2）修改缺陷要量力而行
（3）关注被推迟修改的缺陷
（4）如果决定据理力争就一定要赢

11、在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

（1）一条Bug记录最基本应包含：
bug编号；
bug严重级别，优先级；
bug产生的模块；
首先要有bug摘要，阐述bug大体的内容；
bug对应的版本；
bug详细现象描述，包括一些截图、录像…等等；
bug出现时的测试环境，产生的条件即对应操作步骤；

（2）高质量的Bug记录：

（1) 通用UI要统一、准确
缺陷报告的UI要与测试的软件UI保持一致，便于查找定位。
（2) 尽量使用业界惯用的表达术语和表达方法
使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。
（3) 每条缺陷报告只包括一个缺陷
每条缺陷报告只包括一个缺陷，可以使缺陷修正者迅速定位一个缺陷，集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。
（4) 不可重现的缺陷也要报告
首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现，若尽力之后仍不能重现，仍然要报告此缺陷，但在报告中要注明无法再现，缺陷出现的频率。
（5) 明确指明缺陷类型
根据缺陷的现象，总结判断缺陷的类型。例如，即功能缺陷、界面缺陷、数据缺陷，合理化建议这是最常见的缺陷或缺陷类型，其他形式的缺陷或缺陷也从属于其中某种形式。
（6) 明确指明缺陷严重等级和优先等级 时刻明确严重等级和优先等级之间的差别。高严重问题可能不值得解决，小装饰性问题可能被当作高优先级。
（7) 描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置
描述要准确反映缺陷的本质内容，简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试缺陷，包含缺陷发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。
（8) 短行之间使用自动数字序号，使用相同的字体、字号、行间距
短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。
（9) 每一个步骤尽量只记录一个操作
保证简洁、条理井然，容易重复操作步骤。
（10) 确认步骤完整，准确，简短
保证快速准确的重复缺陷，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。
（11) 根据缺陷，可选择是否进行图象捕捉
为了直观的观察缺陷或缺陷现象，通常需要附加缺陷或缺陷出现的界面，以图片的形式作为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或缺陷本质，可以捕捉缺陷或缺陷产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置，通常要求附加中文对照图。

（12）附加必要的特殊文档和个人建议和注解
如果打开某个特殊的文档而产生的缺陷或缺陷，则必须附加该文档，从而可以迅速再现缺陷或缺陷。有时，为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现，可以附加个人的修改建议或注解。
（13) 检查拼写和语法缺陷 在提交每条缺陷或缺陷之前，检查拼写和语法，确保内容正确，正确的描述缺陷。
（14)尽量使用短语和短句，避免复杂句型句式
软件缺陷管理数据库的目的是便于定位缺陷，因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。
以上概括了报告测试缺陷的规范要求，随着软件的测试要求不同，测试者经过长期测试，积累了相应的测试经验，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，经常阅读、学习其他测试工程师的测试缺陷报告，结合自己以前的测试缺陷报告进行对比和思考，可以不断提高技巧。
（15) 缺陷描述内容
缺陷描述的内容可以包含缺陷操作步骤，实际结果和期望结果。
操作步骤可以方便开发人员再现缺陷进行修正，有些开发的再现缺陷能力很差，虽然他明白你所指的缺陷，但就是无法再现特别是对系统不熟悉的新加入开发人员，介绍步骤可以方便他们再现。实际结果可以让开发明白错误是什么，期望结果可以让开发了解正确的结果应该是如何。

12、你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决。

①　将问题提交到缺陷管理库里面
②　获取判断的依据和标准：
i.根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
ii.如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
iii.根据用户的一般使用习惯，来确认是否是缺陷；
iv.与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
③　合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
④　等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。

13、所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？

答：从理论上来说所有的缺陷都是可以修复的，但是并不是所有的缺陷都要修复。
一些对于软件没有影响的、不影响使用的缺陷我们可以不修复。因为修复些细小的缺陷需要花费很多时间。项目上面可能会因为时间问题而先忽略这些小缺陷。

14、发现的缺陷越多，说明软件缺陷越多吗？

答：是的，通常如果发现一个缺陷的话，可能就会发现很多类似的缺陷，由于开发人员的习惯，可能一个地方有缺陷，另外一个地方就会有相同的缺陷。