仓库管理系统软件缺陷报告.docxVIP

仓库管理系统软件缺陷报告 仓库管理系统软件缺陷报告 仓库管理系统软件缺陷报告 缺陷管理和用例管理是一个软件测试项目的必备，无论是数千人的国际化大企业，还是三五人的小软件作坊。这都是测试队伍的两大工作成果。其中，测试用例描述测试过程的意图，缺陷则描述这些测试用例的结果。 缺陷工作流程为： 文字描述如下： 产品代码-》运行测试用例-》创建缺陷报告-》三方会审讨论缺陷 如果缺陷没有批准-》把缺陷当作不修正来解决-》关闭缺陷 如果缺陷批准了要调查-》研究是代码错误还是设计错误 如果是代码错误，提议修正代码错误-，在提交三方会审-》如果修正批准了-》修改代码-》解决缺陷-》重现缺陷-》通过了则关闭缺陷；不通过，则重新激活-》重新调查是代码错误还是设计错误 如果是设计错误，修正错误直到批准-》再进行三方会审。其他后续流程和以前类似。 在这里需要注意的是，有些缺陷需要综合考虑优先级别，产品发布周期等因素，标注为不予修复。也就是说虽然承认该缺陷，但不会修正，或者决定推迟修正，即该缺陷会在未来的版本修正。这些不予修正的缺陷应该在releasenotes 中予以注明。 这里所说的三方会审，一般意义上指的是开发测试和项目管理。 缺陷报告中应该经常避免的几个错误： 1、电子邮件讨论 电子邮件和缺陷系统是大多数的工程师常用的工具，所以很多时候两者被混用就不足为怪了。然后除了开发工程师和测试工程师之外，缺陷报告还有其他的广泛用途，所以和缺陷不直接相关的信息不应该被写入报告。 缺陷渐变是说在同一个缺陷的报告中，缺陷从一个问题演变成另外一个不相关的问题。这种现象有时候发生很快，有时候过几天或者几个月。不管怎么样，都要极力避免缺陷渐变。对于已经变形的缺陷，通常很难分析其中根本原因，产品支持工程师在有哪些信誉好的足球投注网站相关问题时候还会发生混淆。如果一个缺陷报告开始演变，要及时停止，并就新问题重新报告一个新的缺陷。 如果测试人员很忙碌，他们可能会相关的缺陷记录放在一个缺陷报告中。尽管我们尽力避免这类问题，在一个缺陷报告中报告几个问题从来就不是好主意。这会带来一系列的问题，比如： （1）缺陷的优先级别不能单独设置 （2）缺陷的决定不能单独设置，比如立即修复还是推迟到下一版本 （3）虽然缺陷在类似领域，但是可能需要分配给不同的开发工程师 （4）在分析产品缺陷的根本原因时候，同一缺陷报告中的每个缺陷可能有不同的错误根源。 关于缺陷报告的时候 这似乎是管理层最喜欢干的事情，这些报告发掘和代表了各种各样的数据。比如下面的一些度量： （1）修复的缺陷/所有解决了的缺陷：可以衡量缺陷修正和其他决断的比例 （2）缺陷发现率 （3）缺陷修正率：当缺陷会审标准提高时候，修正的百分比下降 （4）每个组件的缺陷数：根据功能排序可以影响哪些领域需要更多的测试 （5）如何发现缺陷：了解缺陷如何发现可以帮助根源分析和实现缺陷防止技术 （6）每个测试活动发现的缺陷：分析测试类别包括结构化测试，发布前测试，测试用例开发，自动化测试等 （7）平均解决缺陷的时间：跟踪开发团队对输入的缺陷的响应速度 （8）平均关闭缺陷的时间：跟踪缺陷的平均反应时间 缺陷数据唯一不能使用的时候：绩效衡量 缺陷数据具有太多的可变量，比如： （1）所测试功能的复杂性 （2）开发人员的编程能力 （3）规格完整性 （4）缺陷预防和缺陷发现 软件缺陷属性包括缺陷标识，缺陷类型，缺陷严重程度，缺陷产生的可能性，缺陷优先级，缺陷状态，缺陷来源，缺陷原因等。 软件缺陷处理技巧 ? 软件缺陷处理的基本技巧如下： 软件缺陷的处理和跟踪 ? 软件缺陷跟踪管理是测试工作的一个重要部分，它的目的 是确保每个被发现的缺陷能够及时得到处理。 ? 软件缺陷跟踪管理的目标有： – 确保每个发现的缺陷都能够被解决； – 收集缺陷数据并根据缺陷趋势曲线识别测试过程； – 收集缺陷数据并在其上进行数据分析。