3.2.7 证据

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

3.3 缺陷属性规范

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

必须的属性值有：DefectID、Subject、Status、Severity、AssignedTo、Summary、DetectedBy、DetectedonDate、DetectedinVersion和Detectedphase。

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）主要功能在正常操作下没有实现。

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

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

例：

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

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

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

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

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

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

（5）主要功能存在性能问题。

例：

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

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

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

例：

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

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

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

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

例：

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

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

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

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