软件缺陷工作流程和缺陷报告解析

发表于:2015-05-06来源:uml.org.cn作者:不详点击数: 标签:缺陷
最近在读《How We Test Software at Microsoft》 其中的缺陷和测试用例管理,发现很多思路和做法跟目前我们在进行的也颇为相似,总结如下:

  最近在读《How We Test Software at Microsoft》

  其中的缺陷测试用例管理,发现很多思路和做法跟目前我们在进行的也颇为相似,总结如下:

  缺陷管理和用例管理是一个软件测试项目的必备,无论是数千人的国际化大企业,还是三五人的小软件作坊。这都是测试队伍的两大工作成果。其中,测试用例描述测试过程的意图,缺陷则描述这些测试用例的结果,今天谈谈缺陷工作流程。

  缺陷工作流程为:

  文字描述如下:

  产品代码-》运行测试用例-》创建缺陷报告-》三方会审讨论缺陷

  如果缺陷没有批准-》把缺陷当作不修正来解决-》关闭缺陷

  如果缺陷批准了要调查-》研究是代码错误还是设计错误

  如果是代码错误,提议修正代码错误-,在提交三方会审-》如果修正批准了-》修改代码-》解决缺陷-》重现缺陷-》通过了则关闭缺陷;不通过,则重新激活-》重新调查是代码错误还是设计错误

  如果是设计错误,修正错误直到批准-》再进行三方会审。其他后续流程和以前类似。

  在这里需要注意的是,有些缺陷需要综合考虑优先级别,产品发布周期等因素,标注为不予修复。也就是说虽然承认该缺陷,但不会修正,或者决定推迟修正,即该缺陷会在未来的版本修正。这些不予修正的缺陷应该在releasenotes中予以注明。

  这里所说的三方会审,一般意义上指的是开发测试和项目管理

  缺陷报告中应该经常避免的几个错误:

  1、电子邮件讨论

  电子邮件和缺陷系统是大多数的工程师常用的工具,所以很多时候两者被混用就不足为怪了。然后除了开发工程师测试工程师之外,缺陷报告还有其他的广泛用途,所以和缺陷不直接相关的信息不应该被写入报告。

  2、缺陷渐变

  缺陷渐变是说在同一个缺陷的报告中,缺陷从一个问题演变成另外一个不相关的问题。这种现象有时候发生很快,有时候过几天或者几个月。不管怎么样,都要极力避免缺陷渐变。对于已经变形的缺陷,通常很难分析其中根本原因,产品支持工程师在搜索相关问题时候还会发生混淆。如果一个缺陷报告开始演变,要及时停止,并就新问题重新报告一个新的缺陷。

  3、对个缺陷

  如果测试人员很忙碌,他们可能会相关的缺陷记录放在一个缺陷报告中。尽管我们尽力避免这类问题,在一个缺陷报告中报告几个问题从来就不是好主意。这会带来一系列的问题,比如:

  (1)缺陷的优先级别不能单独设置

  (2)缺陷的决定不能单独设置,比如立即修复还是推迟到下一版本

  (3)虽然缺陷在类似领域,但是可能需要分配给不同的开发工程师

  (4)在分析产品缺陷的根本原因时候,同一缺陷报告中的每个缺陷可能有不同的错误根源。

  关于缺陷报告的时候

  这似乎是管理层最喜欢干的事情,这些报告发掘和代表了各种各样的数据。比如下面的一些度量:

  (1)修复的缺陷/所有解决了的缺陷:可以衡量缺陷修正和其他决断的比例

  (2)缺陷发现率

  (3)缺陷修正率:当缺陷会审标准提高时候,修正的百分比下降

  (4)每个组件的缺陷数:根据功能排序可以影响哪些领域需要更多的测试

  (5)如何发现缺陷:了解缺陷如何发现可以帮助根源分析和实现缺陷防止技术

  (6)每个测试活动发现的缺陷:分析测试类别包括结构化测试,发布前测试,测试用例开发,自动化测试等

  (7)平均解决缺陷的时间:跟踪开发团队对输入的缺陷的响应速度

  (8)平均关闭缺陷的时间:跟踪缺陷的平均反应时间

  缺陷数据唯一不能使用的时候:绩效衡量

  缺陷数据具有太多的可变量,比如:

  (1)所测试功能的复杂性

  (2)开发人员的编程能力

  (3)规格完整性

  (4)缺陷预防和缺陷发现

  (5)报告的及时性

原文转自:http://www.uml.org.cn/Test/201109231.asp