测试中缺陷的概括

测试中识别和描述缺陷

1.缺陷不仅仅特指那些我们常见的程序错误，那些“不符合设计要求”和“不满足用户需求的”的问题也是缺陷，而且是更加严重的缺陷。

产生缺陷的原因

1. 人员之间的沟通交流不够，交流上有误解或者根本不进行交流
2. 文档不完善
3. 需求不断的变化
4. 参与人员的过度自信（模块功能不调试，多个模块不联调）
5. 程序设计本身有错误（拆单发货例子）
6. 软件复杂性
7. 工期短，任务重，时间压力大

8. 软件开发工具与系统软硬件的支持（有的框架对多浏览器的支持程度，app对老机型、用户量小机型的兼容，对手机操作系统，对软硬件支持）

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

1. 通过参考需求文档来确认缺陷（辅助工具：需求分析书、用户手册、联机帮助）
2. 通过了解软件产品的行业背景（或参考同类典型软件）来发现缺陷。（需要了解相关的业务流程，招投标流程）

3. 通过沟通来确认和识别缺陷

再现（又叫重现）与优化缺陷的必要性

优化缺陷并不是指优化缺陷本身，而是优化缺陷的再现步骤。
关于软件中“随机”出现的缺陷。所谓“随机”软件缺陷不过是对软件缺陷重现状态的一种描述方法，将产生这种“随机”缺陷的所有输入条件筛选出来之后，这种在测试中的“随机”出现的缺陷就会百分之百地重现。

对于不能复现的bug，并不是bug不能复现，而是暂时没有找到和定位到bug出现的条件和环境。对于这类问题，一定要把当时出现的了解到的条件，步骤，环境描述清晰并记录在bug中，方便相关人员根据已知线索，继续复现和定位问题。

再现与优化缺陷的方法

1。不要想当然地接受任何假设。记下所做的每一件事－－每一个步骤、每一次停顿、每一件工作。无意间丢掉一个步骤或者增加一个多余步骤都是很容易出现的，要避免发生。确保导致软件缺陷所需的全部细节已经记录下来。

2。查找时间依赖和竞争条件的问题。软件缺陷仅在特定时刻出现吗？也许它取决于输入数据的速度，或者使用慢速磁盘还是快速硬盘保存数据。看到软件缺陷时网络忙吗？在较慢和较快的硬件上尝试测试案例。

3、与压迫和负荷相关的边界条件软件缺陷、内存泄漏和数据溢出等白盒问题也许慢慢在测试过程累加中自己显露出来，但重新启动计算机后消失。执行某个测试可能导致数据覆盖，但是只有在后面的测试中试图使用该数据时才会发现，如果发生仅在执行其他测试之后出现的软件缺陷这种现象，就要查看前面执行的测试，也许要利用一些动态白盒测试技术，看软件缺陷是否在无意间发生了。

4。状态缺陷仅在特定软件状态中显露出来。状态缺陷的例子是软件缺陷仅在软件第一次运行或者在此之后出现。软件缺陷也许仅在保存数据之后，或者按任何键之前发生。状态缺陷看起来很像以来时间盒竞争条件的问题，但是你会发现时间并不重要－－重要的是事件发生的次序，而不是发生的时间。

例如：某个字段没有默认值，会导致第一次使用这个值得时候报错。而经过其他操作后，会更新这个字段，使它有值，这样后续就不会再报错了。

5。考虑资源依赖性和内存、网络、硬件共享的相互作用。软件缺陷是否仅在运行其他软件并与其他硬件通信的“繁忙”系统上出现？软件缺陷可能最终证实是竞争条件、内存泄漏或者状态缺陷，问题被软件的依赖性或者对资源的相互作用进一步恶化，但是审视这些影响有利于分离软件缺陷。

这类问题处理时要抽丝剥茧，分别验证不同条件组合相互作用，以免遗漏缺陷

6。不要忽视硬件。硬件可能不按预定方式工作。板卡松动、内存条损坏或者CPU过热都可能导致像是软件缺陷的失败，但是实际上不是。设法在不同硬件上再现软件缺陷。这在执行配置测试或者兼容性测试时特别重要。应该知道软件缺陷是在一个系统上还是在多个系统上显现。
7. 关注软件的失效问题，对缺陷的修改可能会引发新的缺陷

8. 从阅读缺陷报告入手

怎样有效记录缺陷

1. 保证重现缺陷，不能重现的要着重记录出现缺陷时的操作步骤和环境。
2. 分析故障，使用最少步骤复现故障
3. 包含所有重现缺陷的必要步骤
4. 方便阅读
5. 尽量简单——一个缺陷一个报告
6. 注意自己的语气
7. 值得注意的经验