了解如何 告软件缺陷，如何整理出重现缺陷的必要步骤，如何描述缺陷是其它人可以理解并愿意修改。
一、设法修复软件缺陷
不管计划和执行测试多么努力，并非所有软件缺陷发现了都能修复。
以下列举了不修复软件缺陷的原因：
- 没有足够的时间。
- 不算真正的软件缺陷。
- 修复的风险太大。
- 不值得修复。
- 无效的软件缺陷修复 告。
注意 告软件缺陷的基本规则：
- 尽快 告软件缺陷。
- 有限描述软件缺陷。
（1）短小。
（2）单一。
（3）快速技巧提示。
（4）明显并通用。
（5）可再现。 - 在 告软件缺陷时不要做评价
- 对软件缺陷 告跟踪到底。
二、分离和再现软件缺陷
分离和再现软件缺陷是充分发挥侦探才干的地方，设法找出收缩问题的具体步骤。好消息是不存在随机软件缺陷这样的事——如果建立完全相同的输入和完全形同的环境条件，软件缺陷就会在此出现。
如果找到的软件缺陷需要采用繁杂的步骤才能再现，或者根本无法再现，可以尝试以下的提示和技巧：
（1）不要想当然地接收任何假设。
（2）查找时间依赖和竞争条件的问题。
（3）边界条件缺陷、内存泄漏和数据溢出等百合问题可能会慢慢自己显露出来。
（4）软件缺陷仅在特定软件状态中线路出来。
（5）考虑资源依赖性和内存、 络、硬件共享的互相作用。
（6）不要忽视硬件。
如果尽最大努力分离软件缺陷，也无法用简明的步骤再现，那么仍然需要记录软件缺陷，以免跟丢了。也许测试员禁用重程序员那里了解的信息就能找到问题所在。
三、并非所有软件缺陷生来就是平等的。
在 告软件缺陷时，一般要讲明它们将产生什么结果。测试员要对软件缺陷分类，以简明扼要的方式指出其影响，常用方法是给软件缺陷划分严重性和优先级。
- 严重性（severity） ：是指软件缺陷的恶劣程度，当用户碰到该缺陷时影响的可能性和程度。
- 优先级（priority） ：表示修复缺陷的重要程度和紧迫程度。
以下是严重性和优先级的常用划分方法：
严重性：
（1）系统崩溃、数据丢失、数据损坏、安全性被破坏。
（2）操作性错误、结果错误、功能遗漏。
（3）小问题、拼写错误、UI布局、罕见故障
（4）建议。
优先级：
（1）以及修复，阻止了进一步测试，立竿见影
（2）在产品发布之前必须修复
（3）如果时间允许应该修复
（4）可能会修复，但是即使有产品也能发布。
四、软件缺陷的生命周期
- 打开状态（open state） ：当软件缺陷首先被软件测试员发现时，被记录 告并制定的程序员修复。
- 解决状态（resolved state：一旦程序员修复了代码， 告又指定回到测试员手中时，软件的状态。
- 关闭状态（closed state） ：测试员执行验证测试，确认软件缺陷确实得以修复。如果是，就把它关掉，软件测试进入最后的状态。
- 审查状态（review state） ：是指项目经理或者会员会（有时称为变动控制委员会（Change Control Board））决定软件缺陷是否应该修复。
- 推迟（deferred） ：审查可能认定软件缺陷应该在将来的某一时间考虑修复，但是在软件该版本中不修复。
- 由于软件测试员永远不会放弃，因此原来认定为已经修复、测试和关闭的缺陷可能会再次出现。此类软件缺陷一般称为 回归缺陷（regressions） 。推迟修复的软件缺陷以后可能会被证实为很严重，要立即修复。
五、软件缺陷跟踪系统
软件缺陷跟踪系统 ：在实践过程中，以便记录发现的软件缺陷，并在其真个生命周期中进行监视。
- 标准：测试事件 告
测试实践 告（Test Incident Report）文档 ：目的在于记录在需要调查的测试过程期间发生的任何事件。
软件 告过程：
- 标识符。
- 总结。
- 事件描述。
（1）时间和日期
（2）测试员的姓名
（3）使用的硬件和软件配置
（4）输入
（5）过程步骤
（6）预期结果
（7）实际结果
（8）试图再现以及尝试的描述
（9）有助于程序员定位软件缺陷和其他现象或者信息。
- 自动化软件缺陷 告和跟踪
自动化软件缺陷 告和跟踪系统：
- 一旦输入了软件缺陷，实际就开始了软件缺陷的生命周期，在软件生命周期中的任何时候，可能需要增加新信息已明确细节内容，更爱优先级或者严重性，对数据做小的变动。
- 许多软件缺陷数据库不仅跟踪修的备注，而且跟踪程序员修复软件时做了什么。代码行、模块、声之错误类型也会记录。所有的这些信息有助于在重新测试软件缺陷是确认其修复情况。如果证实软件缺陷没有修复，只需要重新打开缺陷，再一次启动生命周期。
参考文献
- 《软件测试（原书第2版）》
- 《软件测试的艺术（原书第3 版）》
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！