测试过程管理.pptVIP

编写和跟踪测试用例 三、测试用例组织和跟踪 管理和跟踪系统的方法： 1）凭脑子记； 2）书面文档； 3）电子表格； 4）自定义数据库。 跟踪测试用例的理想方法是使用测试用例管理工具，一种为处理测试用例而专门编程设计的数据库。 报告发现的问题 软件测试的主要任务：测试计划、实际测试、报告发现的问题。报告所发现的问题，实际上是也许是软件测试人员要完成最重要的，有时也是最困难的任务！ 软件测试报告 设法修复软件缺陷 分离和再现软件缺陷 并非所有软件缺陷生来就是平等的 软件缺陷的生命周期 软件缺陷跟踪系统 * 报告发现的问题 软件测试报告 软件测试报告是软件测试过程中最重要的文档，它的内容包括： 记录问题发生的环境 如：各种资源的配置情况 记录问题的再现步骤 记录问题性质的说明 记录问题的处理进程 问题处理进程从一定角度上反映测试的进程和被测软件的质量状况以及改善过程。 报告发现的问题 设法修复软件缺陷 不修复软件缺陷的原因 并非所有的软件缺陷被发现就能修复，不修复原因有： 1.没有足够的时间； 2.不算是真正的缺陷，比如“这不算软件缺陷，而是一项功能。也许很多人说发现了能不算吗，但是原因很多诸如理解错误，测试错误或是产品说明书的变更等情况； 3. 修改这个缺陷的风险很大; 4. 不值得修复，有些Bug不经常出现或是这个功能不常用，出现问题的机率很小，但是如果有这样的情况也就要相应的担当商业风险； 5. 无效的软件缺陷修复报告。其它如软件缺陷报告的不是很有效； 报告发现的问题 设法修复软件缺陷（续） 报告软件缺陷的基本原则： 1. 尽早报告软件缺陷 2. 有效的描述软件缺陷 短小、单一、明显并通用、可再现 3. 报告缺陷时不参加评论 4. 对软件缺陷报告跟踪到底 报告发现的问题 分离和再现软件缺陷 1.不要想当然接受任何假设。 记下所作的每一件事－每一个步骤，每一次停顿，每一件工作。 2. 查找时间依赖和竞争性的问题。 3. 边界条件软件缺陷、内存泄漏和数据溢出等白盒问题可能会慢慢自己显露出来。 也许要利用动态白盒技术。 4. 状态缺陷仅在某个特定状态才出现。 注意事件发生的次序。 5. 考虑资源依赖性和内存、网络和资源共享的相互作用、 6. 不要忽视硬件。 比如硬件降级、不按预定方式工作。板卡松动、内存条损坏、CPU过热。 报告发现的问题 并非所有软件缺陷生来就是平等的 通常我们用严重性和优先级表示对软件缺陷的划分，当然这个要结合具体的公司规定。 严重性： 软件缺陷的恶劣程度；用户碰到该缺陷时可能性和影响程度。 优先级：修复缺陷的重要程度和紧迫程度。 注意：并不是说越严重的缺陷优先级就越高。 如，一个可以引起系统崩溃的缺陷，这是一个严重的缺陷，但是这个缺陷是在一些非常极端的情况下才能出现，那么就有可能不是一个优先级很高的缺陷。 再如，一个公司软件的LOGO错了，他对于用户的影响其实不大，所以这个缺陷的严重性可能只是很低，但是对公司的影响是很大的，所以优先级很高。 报告发现的问题 严重性 系统崩溃、数据丢失、数据毁坏、安全性被破坏。 操作性错误、结果错误、功能遗漏。 小问题、拼写错误，UI布局、罕见故障。 建议 优先级 立即修复，阻止了进一步测试，立竿见影。 在产品发布前必须修复。 如时间许可，应修复。 可能会修复，但有产品也能发布。 报告发现的问题 软件缺陷的生命周期 最简单的状态转换： ?????? 打开 － 解决 － 关闭 1.发现缺陷，就要提交报告，这样一个缺陷报告就生成了，处于“打开”状态。 2.缺陷提交以后有人修复，然后就能转到“解决”状态。 3.然后再经过测试员的验证，证实真的修复了，这个缺陷就可以“关闭”了 前3个是最最最简单的3种状态 报告发现的问题 4.通常提交一个缺陷以后会让一个缺陷委员会或者是开发经理来复审，看这个到底是不是缺陷，还有分配给谁来修复，确认优先级等等 5.如果复审证实了是一个缺陷，那么就可以分配给工程师来修复。 6.如果复审完了以后觉得这个不是一个缺陷，可能是一个新的功能，或者这个缺陷在这个版本里面就不去修复了，就会去到Deferred状态那里。 7.如果证实这个根本不是一个缺陷，那么就可以直接“关闭”。 8.对于在“解决”状态，如果测试员检验的时候发现缺陷没有被修复，那么这个缺陷又回到了“打开”状态。 9.如果一个缺陷在这一个版本修复了，但是在下一个版本里面又出现了，那么又回到“打开”状态了。 10.Deferred的缺陷有可能在下一版被处理。 报告发现的问题 软件缺陷跟踪系统 标准为测试事件报告，它的目的：记录在需要调查的测试过程起发生的任何事件。它包含标识符，总结，事件描述和影响。详见教材。 事件描述包含日期和时间，测试缘的姓名，使用的软硬件配置，输