软件测试 15 报告所发现的缺陷.pptVIP

示例 理想趋势图 示例： 微软公司基于缺陷趋势图的里程碑定义 15.3.3 缺陷分布分析 缺陷分布报告，缺陷数量与缺陷属性的函数。如测试需求和缺陷状态、严重性的分布情况等。 缺陷的四种优先级分布 示例：根本原因图表 缺陷报告 缺陷分布报告，允许将缺陷计数作为一个或多个缺陷参数的函数来显示，生成缺陷数量与缺陷属性的函数。如测试需求和缺陷状态、严重性的分布情况等。 缺陷趋势报告，按各种状态将缺陷计数作为时间的函数显示。趋势报告可以是累计的，也可以是非累计的； 缺陷年龄报告，显示缺陷处于活动状态的时间，展示一个缺陷处于某种状态的时间长短，从而了解处理这些缺陷的进度情况。 测试结果进度报告，展示测试过程在被测应用的几个版本中的执行结果以及测试周期 15.3.3 缺陷跟踪方法 当前缺陷状态 – Bug Dashboard 项目发展趋势: 每天的变化、差异，重点进行趋势分析 级别 总数 未处理的 正在处理的 修正的 不是缺陷 重复的 暂不处理 关闭 致命的 2 0 0 0 0 0 0 2 严重的 216 18 7 5 1 4 20 161 一般的 31 23 1 0 0 0 0 7 微小的 5 2 0 0 0 3 0 0 15.4 软件缺陷跟踪系统 到目前为止所讲述的一切表面上看起来很好，但是运用到实践中还需要软件缺陷跟踪系统，以便描述报告所发现的缺陷，处理软件缺陷属性，跟踪软件缺陷的整个生命周期和生成软件缺陷跟踪图表等。为什么需要建立一套软件缺陷跟踪系统呢？因为它会让我们受益无穷，概括起来有： 软件缺陷跟踪系统拥有软件缺陷跟踪数据库，它不仅有利于软件缺陷的清楚描述，还提供统一的、标准化报告，使所有人的理解一致； 缺陷跟踪数据库允许自动连续的软件缺陷编号，还提供了大量供分析和统计的选项，这是手工方法无法实现的； 基于缺陷跟踪数据库，可快速生成满足各种查询条件的、所必要的缺陷报表、曲线图等，开发小组乃至公司的每一个人都可以随时掌握软件产品质量的整体状况、或测试/开发的进度； 缺陷跟踪数据库提供了软件缺陷属性并允许开发小组根据对项目的相对和绝对重要性来修复缺陷； * 软件缺陷跟踪系统 可以在软件缺陷的生命期中管理缺陷，从最初的报告到最后的解决。确保了每一个缺陷不会被忽略，同时，它还可以使注意力保持在那些必须尽快修复的重要缺陷上； 当缺陷在它的生命周期中变化时，开发人员，测试人员以及管理人员将熟悉新的软件缺陷信息。一个设计良好的软件缺陷跟踪系统可以获取历史记录，并在检查缺陷的状态时参考历史记录； 在软件缺陷跟踪数据库中关闭每一份缺陷报告，它都可以被记录下来。当产品送出去时，每一份未关闭的缺陷报告都提供了预先警告的有效技术支持，并且证明测试人员找到特殊领域突然出现的事件中的软件缺陷。 * 报告缺陷就像写新闻 凯列班有个故事讲的是他最喜欢的缺陷。故事大概是这样的： 我一个月前在实验室中发现了这个缺陷，然后报告了它。没有人注意到；所以在优先分配中，他们把它标记为被“推迟”。上个星期我们最大的客户也发现了它，突然之间，这个缺陷就引发了一场危机。现在，我们需要交付一个维护版本，这就意味着我要整个周末都呆在实验室里检查所做的修复。为什么他们在我第一次报告的时候没注意到这个缺陷呢？ 真正的原因是什么呢？最常见的原因就是缺陷报告写得不清楚，没有把影响充分传达给优先分配小组，所以所报告的缺陷被关闭了。凯列班的经理普洛斯彼罗对于凯列班的故事则有着不同的看法：“为什么凯列班不能把他的缺陷报告写得清楚些，足以让团队能够对它们有所行动呢？”（因此，和前面一样，普洛斯彼罗在他的下一个项目中没有选择凯列班。） * 你的主张驱动你所报告的缺陷的修复 你所写的任何一个缺陷报告都是一个呼唤修复此缺陷的宣传文档。 有的缺陷永远也不会被修复。你的责任不是去保证所有的缺陷都被修复了。你的责任是以一种能让读者理解问题全部影响的方式精确地报告缺陷。 你研究得好不好，报告写得好不好，这些通常都会对缺陷修复的概率有着很重大的影响。 详细描写缺陷就像是写新闻报道（或者网页）。它是新闻学。标题就像是头条新闻，你应该希望大多数读者从来也不看“下面的内容”。新闻记者的6个基本问题：什么、哪里、怎么、谁、为什么和什么时候，需要在一两句摘要中都能覆盖到。 * 了解你的读者 你的缺陷报告的第一个读者就是优先分配小组。 读者所看到的并不是所有的细节，他们仅能看到那些适合查询结果列表的内容。你应当根据缺陷的显示格式编写缺陷。 优先分配小组中包括了项目中最忙的人。通常他们都只花不到1分钟的时间来评审每个缺陷（每日进行优先分配的一个重要原因就是为了保持列表的长度，从而使每个工作项都能获得它们所应获得的关注）。在那个