如何让缺陷填写的更加规范

 

1      目的

缺陷记录是软件测试生命周期中最重要的可用产出之一。因此，怎么填写有效的缺陷是非常重要的。一般来说，一条好的缺陷记录至少有以下3个方面的积极作用。

1.      减少测试人员和开发人员的沟通成本。

2.      加快缺陷修复的速度。

3.      增加测试的可信度。

缺陷记录的最终目的是准确地传达测试人员的思想或缺陷的真正所在。只要遵循本规范中的一些简单原则，我们就可以轻松的填好每一条缺陷记录，从而提高工作效率。

2适用范围

 

3      填写缺陷规范

3.1    缺陷概要规范

缺陷概要需以简洁的语言表述准确的信息。那么能准确表达意义的缩略语在描述中则具有更高的优先级，一些关键词如“程序崩溃”、“系统无反应”和“文字错误”等，在把缺陷概要作为检索条件的时候，显得非常必要。

3.2    缺陷描述规范

缺陷描述需要遵循以下7个要点：精练、正确、中立、准确、普遍性、可再现和有证据。

3.2.1  精练

缺陷记录的描述需简单明了。不加入与问题无关的叙述，去除不必要的信息。但同时，要涵盖所有必要的信息。

3.2.2  正确

一定要清楚你所记录的缺陷的确存在。在提交前，请先考虑如下5个问题：

1.      我对系统需求是否真正理解？

2.      是否安装和系统相关的软件？我的机器设置有没有问题？

3.      是不是我手动设置的某个地方不合适（被测软件本身的设置）？

4.      是不是我以前测试时遗留的错误数据导致的错误？

5.      会不会是网络状况变化引起的问题？或者其它外在环境因素（如防火墙）引起的错误？

以上这些都对测试的结果有很大的影响，确认这些问题是否存在。

3.2.3  中立

客观地描述每一个缺陷，不要带任何情绪化的语言。在提交一个缺陷记录前首先把它通读一遍，确信你的描述没有伤害到任何人员。

3.2.4  准确

缺陷记录需要准确的描述缺陷发生的位置，产生条件和结果。最好做到让阅读缺陷记录者不需要亲自上机操作就知道问题所在。

例子	缺陷描述
不准确的描述	查询中按项目来源查询发生错误。
准确的描述	科技项目计划下达中，在查询页面按“项目来源”字段的“资金”查询条件进行查询时，查询结果显示出了属于“资金”和“结转”的项目，应只显示出属于“资金”的项目。

3.2.5  普遍性

记录缺陷需要明确的描述出该问题在整个系统中普遍存在的地方。通常，当开发人员修改缺陷的时候，他可能只是修复了你提到的一些特定情况，他并不知道这个问题具有普遍性，尚需更大范围的修复。

3.2.6  可再现

原则上所提交的缺陷都应该能够重现。对很难重现的Bug，你应该记录下什么情况下可以再现它，列出再现Bug的所有步骤，执行次序以及所需要的数据等。

如果你无法再现这个Bug，或者是你怀疑某些条件你还没有想到，你应尽可能的把那些认为可能有用的信息描述清楚。

一个缺陷在你重现它以前，不要假设它是可以重现的，如果你确实无法重现它，在缺陷记录中明确说明也是很重要的。

在考虑对缺陷的重现时我们应该注意以下3点：

1.      怎样才能以最简单的方式把缺陷重现。对于难重现的缺陷，这常常是个漫长而费时的过程。

2.      是否有外在的原因在测试中导致了该缺陷。例如是否和其它软件相冲突的情况。

3.      如果在测试中要输入很多值，尽量在大量的输入中找出导致缺陷的那些特定值，并准确地写出那些导致缺陷的输入。

3.2.7  证据

对于一些数值型的、暂时不能重现的和难以描述的缺陷等，最好提供可以证明它存在的数据、图片和文挡等证据。对记录的缺陷，就应该确信这里的确存在缺陷并提供所有你能提供的证据，说服别人这里确实存在缺陷。这些证据可能来自于系统数据、现场截图以及需求文挡等。当然这也有利于关闭缺陷和做回归测试的时候重现该缺陷。

3.3    缺陷属性规范    

缺陷属性需要根据不同的软件项目定制不同的属性值。

必须的属性值有：Defect ID、Subject、Status、Severity、Assigned To、Summary、Detected By、Detected on Date、Detected in Version和Detected phase。

3.4    缺陷填写建议

在填写一条缺陷记录的时候，提醒你参考以下2点建议：

1.      在提交一条缺陷前，需检查缺陷库中是否已经存在此缺陷。力求避免重复提交。

2.      对于一些难以理解的、 自己还有些模糊的和对缺陷的正确性难以肯定的问题，在记录你的缺陷以前，就需要和有经验的测试人员或开发人员进行讨论。

4      缺陷等级分类与示例

4.1    概述

            测试当中发现的缺陷，严重程度划分为三级：High（高）、Medium（中）和Low（低）。在《软件系统测试规程》中已对这三个级别进行了定义性描述，High等级是指功能不能使用或在使用中出现的问题影响了系统的稳定性、造成数据存储错误或将错误数据带入下一环节、一些重要特性或性能不能达到指定的要求等。Medium等级是指功能可以使用、在出错后做出一定处理，操作能够继续进行或功能实现有误，但问题的出现应不影响本功能或其他功能的实质性使用。Low等级是指用户界面显示、对齐、文字错误等。

            本文结合实际工作情况，对已发现的大量缺陷数据进行归纳，对缺陷的各个等级进行分类，并在每个分类中列举比较典型的例子。以后测试人员在设定缺陷严重等级时将据此进行参考，使缺陷严重等级的定位更加规范统一，同时也使测试人员和开发人员对缺陷等级的定位更容易达成一致。本次分类重点关注系统业务功能在正常操作下可能出现的问题，而有意识地降低了边界值测试发现的缺陷和非正常操作下发现缺陷的等级。

            我们主要考虑High等级和Medium等级的情况。因为Low等级的缺陷主要指界面上的显示、对齐、文字错误等，在这里就不再详细列出。

4.2    High等级的分类与示例

1.      关键数据错误。

例：

a)      统计报表中的项目数量和资金统计不正确。

b)     巡视工作任务中，将缺陷记录中的缺陷上报生产，在缺陷登记模块中可看到3条一样的数据。

c)      物资采购数为10，现场和仓库可分别到货10件。

 

2.      所有功能在正常操作下报错（如500或404等）。

例：

a)      打开计划下达审批页面，系统报500。

b)     点击查询按钮，系统报404。

 

3.      主要功能在正常操作下没有实现。

例：

a)      新增、保存、删除、发送、回退、撤回、导出和查询等操作不成功。

 

4.      主要功能在正常操作下结果不正确。

例：

a)      检查不通过的项目可以上报成功。

b)     选择全部项目发送，只发走部分。

c)      导出功能，导出的文件格式错乱、内容跟列名不对应，以及内容不正确等。

d)     在多个入库单同时上报时，将入库仓库为观澜仓库的入库单上报给水贝仓库的管理员审批。

e)     在新增两票录入记录时，在新增页面点击一次保存操作就会新增一条记录。

f)      PDA中,缺陷表象的信息错误了，严重等级也没有下下来；设备信息中，有些字段没有下下来。比如"安装日期"、"厂家"、"电压等级"等等。

 

5.      主要功能存在性能问题。

例：

a)      分发多个项目时，系统响应很慢，如分发30个项目，系统1分钟还没处理完。

b)     单据过帐时，系统出现白屏，显示时间超过10秒。（系统响应时间应符合需求规格说明书的要求，不同系统的响应时间的要求可能不一致。）

 

6.      系统管理权限错乱，对系统安全造成威胁的。

例：

a)      没有授权用户菜单，但用户登录系统后，能通过该菜单进入相关模块，并对模块的数据进行操作。

b)     未授权的用户可以进行厂家配额。

c)      在角色管理中取消了新增功能位置的权限按钮，在设备台账中变电设施、中心站、设备下还有新增下一级功能位置按钮。

 

7.      系统业务逻辑关系处理不正确，引起主要功能错误。

例：

a)      项目验收后，已验收状态的项目在待下达库中可被获取继续下达。

b)     生成操作票中，对于已审核通过的操作票，还可以增加操作步骤，应该是不能再编辑操作步骤的。

c)      抢修领料在审批过程中可以上报。

d)     领料退库时，导入的领料单列表中即有现场到货单也有现场领料单，造成同一物资多次退库的现象。

 

4.3    Medium等级的分类与示例

1.      非主要功能在正常操作下没有实现。

例：

a)      查询页面有某些查询条件查不出相应的数据。

b)     巡视项目定义中，当只有2条巡视内容时，上下移动巡视内容操作不成功。

c)      在单据中物资明细没有超链接。

 

2.      非主要功能在正常操作下结果不正确。

例：

a)      标题排序不正确。

b)     新增主变压器并修改其技术参数高压额定容量值之后，该设备的上级变电站页面中主变压器总容量的值没有修改。

 

3.      非主要功能存在性能问题。

例：

a)      物资系统中上传附件速度很慢，1M的文件需要30秒以上。

 

4.      所有功能进行边界值测试，系统报错的。

例：

a)      大文本框输满，保存报500。

b)     资金输入最大值，保存报500。

c)      上传大型文件，系统老处于上传状态。

d)     选中大量项目导出，导出不正确。

 

5.      模块中的信息显示不正确，起误导用户作用。

例：

a)      资金单位显示不对。

b)     新增推荐单位后，列表中显示的“关联类型”与新增时的输入不一致。

c)      在单据的物资明细列表中将物资明细显示为项目名称。

d)     停电计划查询中的导出字段中，“停电原因”应该是“停电终止原因”。

 

6.      关键提示不正确，起误导用户作用。

例：

a)      实际操作成功却提示操作失败。

b)     智能操作票系统中，在状态检查时，提示的不合法设备名称不正确。

c)      操作票中，导入操作步骤成功了，但是提示却为不成功。

 

7.      非主要模块的权限控制不正确。

例：

a)      合同管理的授权给相关人员后，相关人员看不到相应的数据。

b)     领料单在材料员审批时不能填写领料原因。

 

8.      系统业务逻辑关系处理不正确，引起非主要功错误。

例：

a)      项目归档后，在项目申请的已上报页面和申请书的查询页面还能看到该项目。

 

4.4    Low等级的分类与示例

1.      页面和记录定位。

例：

a)      变更申请选中列表中的第2条项目新增变更，新增完返回时系统自动定位到列表中的第一条项目。

 

2.      用户界面显示、对齐、文字错误等。

例：

a)      页面太小没有将内容显示完整，只要把页面调大即可。

b)     系统将“帐号”显示成“账号”。

 

3.      报javascript错误，但能操作成功。

 

4.      用户几乎不太可能进行的操作，导致系统报错。

 

4.5    填写缺陷时的注意事项

1.      同类型的缺陷只录一条。例如项目审批模块的发送不成功，其他审批模块也有同样的问题，只录一条缺陷就可以，因为都属于工作流的问题。

2.      同一模块的页面显示有几个问题，也只录一条缺陷，并在缺陷的描述里列出各个问题。因为都是同一模块页面显示的问题，放在一起，开发人员可一次将问题改全。

3.      测试中要经常查看同组测试员填写的缺陷，及时了解已存在的缺陷，如有补充可在注释里填写。

4.      查看同组测试员填写的缺陷时，注意其他人对缺陷严重等级的定义，保持同组人员对严重等级定位的一致性。