软件缺陷描述规范

软件缺陷描述规范

一、 缺陷基本定义

软件缺陷（Software Defect）：

软件缺陷是对软件产品预期属性的偏离现象。它包括检测缺陷和残留缺陷。

缺陷的优先性，分为5级，参考下面的方法确定：

1)最高优先级(Blocker)，例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷，或用户重点关注的问题,缺陷导致系统几乎不能使用或者测试不能继续，需立即修复。

2)较高优先级(Critical)，例如，影响软件功能和性能的一般缺陷, 严重影响测试，需要优先考虑；

3)一般优先级(Major)，例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷,需要正常排队等待修复；

4)低优先级(Minor)，例如，对软件的质量影响非常轻微或出现几率很低的缺陷,可以在开发人员有时间的时候再被纠正；

5)最低优先级(Trival),例如，属于优化，可以不做修改的问题或暂时无法修复但影响不大的问题。

二、 缺陷描述

软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发工程师交流的最好机会。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员,因此，正确评估缺陷的严重程度和优先级，是项目组全体人员交流的基础。

缺陷描述的原则：

有效的缺陷描述有以下几个原则：

 可以重现：在缺陷的详细描述中提供精确的操作步骤，可以让发人员容易看懂；

 定位准确：缺陷描述准确，不会引起误解和歧义；

 描述清晰：对操作步骤的描述清晰，易于理解，应用客观的书面语，避免使用口语；

 完整统一：提供完整、前后统一的软件缺陷的步骤和信息，按照一致的格式书写全部缺陷报告，有关缺陷的格式参见“缺陷的格式”；

 短小简练：通过使用关键词，可以使问题摘要的描述短小简练，又能准确解释产生缺陷的现象。如“在新建任务窗口中，选择直接下达，负责人收不到即时消息”中“新建任务窗口”、“直接下达”、“即时消息”等是关键词；  特定条件：许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。如“网站在IE7.0和IE8.0的兼容问题”；

 不做评价：在软件缺陷描述不要带有个人观点，对开发软件进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。

1. 缺陷的格式：提交一条缺陷后，最好能够再检查一遍缺陷格式是否有问题。常见的格式问题如下：

 问题摘要中不能有句号；

 问题摘要后不要有空格，直接填写内容；

 问题摘要比较长时，可以用“，”分隔；

 详细描述中序号后面“.”一定是半角的宋体，不是全角符号，并且后面不要

再有空格；

 详细描述中分号一定要使用全角的分号；

 详细描述中的“->”应统一。应在英文输入法的半角状态下输入箭头； 注意缺陷中不要出现错别字，例如“登陆”应写为“登录”。

2. 缺陷描述常见的问题：

 问题摘要过长，不够简练、准确；

 问题摘要与详细描述的内容不一致；

 详细描述不清楚，无法复现；

 详细描述冗长，不宜于理解；

 缺陷定位不正确；

 缺陷等级定位错误；

 缺陷的类型定位不正确；

 不是缺陷。

三、 缺陷管理

1. 缺陷跟踪

 缺陷的提交人，实时跟踪缺陷状态，对开发人员提出的疑问，及时作出回答；  及时更新缺陷状态。

四、 缺陷示例

缺陷优先级会涉及从Critical到Trivial，严重程度等级会涉及从S1到S5。 一般地，严重程度高的软件缺陷具有较高的优先级，但是严重程度和优先级并不总是一一对应。有时候严重程度高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重程度低的缺陷却需要及时处理，反而具有较高的优先级。例如，公司名字和软件产品徽标是重要的，一旦它们误用了，这种缺陷是用户界面的产品缺陷，并不影响用户使用。但是它影响公司形象和产品形象，因此这也是优先级高的软件缺陷。

通常功能性的缺陷较为严重，具有较高的优先级，而软件界面类缺陷的严重性一般较低，优先级也较低。但实际上，优先级和严重程度是有联系也有区别。严重程度高的，必然优先级也要高，但优先级高的，严重程度却并非也一定高。

1. 功能性：

1）S1级/Critical

 导致系统崩溃：执行正常操作或者误操作后，导致整个系统，或者大部

分模块无法正常使用：



导致死机：执行正常操作或者误操作后，导致死机：

 主业务流程出现断点：业务流程可以分为主业务流程和一般业务流程，

是根据功能在流程中的重要程度进行区分的，例如在OA

办公系统中，发文后无法收文应该是主业务流程的问题，收文后归档存在问题，则是流程的一个分支，属于一般业务流程：

 出现不可挽救的数据丢失或损坏；

 内存泄漏；

2）S2级/Blocker：发现影响被测模块正确运行的严重问题；

 导致程序模块丢失或未实现：执行正常操作或者误操作后，导致部分模

块丢失，或者某个模块功能未实现：

 被测数据处理错误：如果数据处理错误导致模块级的问题，或者对系统

的影响重大，例如下例中职工住房补贴重要的数据计算出错，缺陷的等级应该是S2；如果数据错误造成的影响不大，则可以定义为S3；

 软件错误导致数据丢失：

 用户需求未实现：没有实现用户需求规格说明书或者特定文档中规定的

功能：

 一般业务流程出现断点：

 异常退出：执行正常操作或者误操作后，系统异常退出：

3）S3级：发现影响被测功能正确实现的问题；

 功能未实现：某项功能点的功能没有实现，例如点击某个按钮系统没有

响应、设置某项功能后无效、无法执行某项操作等等：

 功能实现不正确；

 数据处理错误，但对系统的影响不大；

 链接页面不正确；

4）S4级：一般性的错误或功能实现有不完善处；

 一般性的错误：通常不会影响用户正常使用，具体缺陷描述参见下例：

 功能实现有不完善处

5）S5级：建议性问题。

2. 可靠性：

需要指出的几个问题：

 对于执行某项操作异常退出的问题，缺陷类别均提交为可靠性，在填写

原始记录时，在功能性中可以引用此条缺陷。

 数据校验问题，如果由于该数据未作校验，而且对系统其他功能未造成

影响的，该缺陷提交为可靠性，在填写原始记录时，在功能性中可以引用此条缺陷。

 如果由于数据校验问题造成了系统某项功能不能实现或功能实现有误，

则该条缺陷提交为功能性，填写原始记录时，在可靠性中可以引用此条缺陷。

1) 成熟性：系统崩溃属于S1级别，异常退出和数据丢失一般属于S2级别的问题；

 使用的容量达到规定的极限时,系统不崩溃、不异常退出也不丢失数据；  试图使用的容量超出规定极限时，系统不崩溃、不异常退出也不丢失数

据；

 产品描述中列出的其他程序或用户造成的错误输入时，系统不崩溃也不

丢失数据；

 输入用户文档中明确规定的非法指令时，系统不崩溃也不丢失数据；

 不会因掉电、异常退出、网络异常中断等原因而使软件或数据遭到破坏。

2) 容错性

 能屏蔽用户的误操作；

 对错误有正确提示；

 输入错误数据时，系统不崩溃、不异常退出也不丢失数据；

 有错误操作时，系统不崩溃、不异常退出也不丢失数据。

3) 易恢复性

 系统运行失效后，应能较快重建系统。

4) 数据校验机制：数据校验的问题一般是S4级别。

 应对数据项之间的逻辑关系进行校验，保证数据的有效性；

 应保证数据的完整性和一致性，不会因删除或反复的更新而被破坏或留

下垃圾数据；

 对不符合要求的输入数据，系统应使用中文给出简洁、准确的提示信息，

必要时应给出帮助。

3. 易用性：

首先要说明的几个问题：

 易用性缺陷的级别一般是S4和S5；

 任何提示信息（或页面显示）有错、有误或不正确的词语出现时，首先

一定是功能性的缺陷；

 页面风格不一致、提示信息不易理解、提示信息不明确、不符合用户习

惯等“不易理解、不易浏览、不易操作”的问题才是易用性的；

 既属于功能又属于易用性的缺陷，在填写原始记录时需要同时引用。

1) 易理解性

 通过选择适当的术语、图形表示、背景信息和帮助，帮助用户理解、使

用；

 出错消息中提供差错产生的原因和纠正的详细信息。

2) 易浏览性

 数据媒体具有产品标识，可辨别编号或文本；

 具有必要的信息，指导用户使用程序；

 输入、输出设计规矩，输出结果应简洁、直观、美观、方便阅读、易懂

和使用；

 人机界面简洁、美观、实用，风格相对一致，符合办公习惯；  在界面、人机交互、输出中的用语应与业务用语一致。

3) 易操作性

 具有严重后果的功能执行可逆，或者给出明显警告，执行前要求确认：

特别是数据的删除和重写，以及中断一个过长的处理操作，这种动作往往有严重后果；

 软件操作简便，系统支持标准的鼠标、键盘操作，支持鼠标的单击、双

击和右键操作，支持快捷键操作；

 提供辅助输入手段（如选择输入、默认值等），数据检索方便、灵活；

 安装参数应当给出默认值或提示，需要用户干预的地方应尽量少，操作 21

方便；

 根据用户熟练程度（外行、初学、熟练）和使用频度，能提供不同的操

作方式或用户界面。

4. 可维护性

1) 易分析性

 系统可以正确判断缺陷或失效原因；

 对于软件运行错误，应当提示清晰，为用户和系统管理员自己解决问题

提供可能。

2) 易改变性

 对相关配置文件、库、表的参数可以提供方便的修改；

 对于非程序内部错误，由数据元素属性设置、控制规则不当而引起的软

件运行错误，软件应为系统管理员提供自行修正的手段；

 软件应充分考虑在设计环境与适用范围下不同用户的要求，为用户进行

本地化配置提供手段。

3) 稳定性

 系统在测试过程中运行稳定：执行正常操作导致异常退出、数据丢失或

者系统崩溃。

22

5. 可移植性

1) 适应性：在测试期间系统能够正常使用，一般就能够说明可以适应性不同带宽和和不同的网络运行状态；

 系统应能适应不同带宽的网络；

 系统应能适应不同的网络运行状态。

2) 兼容性

 软件（如：操作系统、数据库、办公套件、打印机、WEB服务器等）兼

容性。

23

6. 中文特性

1) 中文显示

 对话框、菜单、图标、窗口等界面：界面中存在错别字或者乱码；  信息提示，帮助文档符合中文使用习惯：例如错别字的问题。

2) 汉化程度

 系统全部中文汉化。

24

3) 编码支持程度

 支持GB 2312 编码；

 支持GB 13000.1 编码；

 支持GB 18030 编码。

7. 安全性

1) 身份认证

 用户权限管理

 提供客户端用户身份识别

 提供用户功能权限管理

 提供用户数据访问权限管理

 授权（功能授权、数据授权）机制是否灵活安全

 验证控制

 身份验证不成功有次数限制及相应处理措施

 用户唯一：

25

 用户名称应具有唯一性；

 用户在被删除或被停用后，保留该用户记录，新增用户不得与该用户

同名。

 电子签名

 对电子签名进行验证

 客户端用户身份识别

 是否提供USBkey加密验证、提供数字证书验证或提供其他加密验证

方式

2) 数据加密及安全传输

 对于有特殊安全要求的数据，应在传输中进行必要的加密处理

 提供数据的安全可靠传输，支持断点续传、屏蔽线路瞬间故障和主机故

障

 数据加密使用的算法应符合国家规定

3) 安全缺陷屏蔽

 对非法访问有识别和屏蔽功能

26

 授权（功能授权、数据授权）机制是否灵活安全



软件程序本身不存在可能引起安全缺陷的语句、命令

4) 日志和审计

 对关键数据的变更应记入日志

 对日志信息进行查询、统计、分析和分类管理

 提供安全审计功能

5) 密码设置

 进入系统需要密码身份验证

27

 应有密码设置策略，包括有效期、最小长度、复杂度、非空设置、大小

写敏感度等

 所有的密码不得明码显示、存储与传输

6) 数据备份与还原

 是否提供数据备份与还原手段

7) 超时自动退出

 超过一定的时限未进行操作，系统自动退出

8) 安全补丁检查

 操作系统是否安装所有安全补丁

 对于使用IE的客户端，是否安装所有IE安全补丁

8. 标准符合性

标准符合性测试中，凡是不符合标准规定的问题，至少应该为S3级别，具体缺陷描述参见下例：

28

29