- 清晰准确的软件缺陷描述可以减少软件缺陷从开发人员返回的数量
- 提高软件缺陷修复的速度，使每一个小组能够有效的工作
- 提高测试人员的信任度，可以得到开发人员对清晰的软件缺陷描述有效的响应
- 加强开发人员，测试人员和管理人员的协同工作，让他们可以更好的工作
在多年实践的基础上，我们积累了较多的软件缺陷的有效描述规则，主要是：
- 单一准确。每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复，不能得到彻底的修正。
- 可以再现。提供缺陷的精确操作步骤，使开发人员容易看懂，可以自己再现这个缺陷，通常情况下，开发人员只有再现了缺陷，才能正确地修复缺陷。
- 完整统一。提供完整、前后统一的软件缺陷的步骤和信息，例如：图片信息，Log文件等。
- 短小简练。通过使用关键词，可以使软件缺陷的标题的描述短小简练，又能准确解释产生缺陷的现象。如“主页的导航栏在低分辨率下显示不整齐”中“主页”、“导航栏”、“分辨率”等是关键词。
- 特定条件。许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。如“搜索功能在没有找到结果返回时跳转页面不对”。
- 补充完善。从发现bug那一刻起，测试人员的责任就是保证它被正确的报告，并且得到应有的重视，继续监视其修复的全过程。
- 不做评价。在软件缺陷描述不要带有个人观点，对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。
软件缺陷属性MILY: 宋体">包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。
1. 缺陷标识：是标记某个缺陷的唯一的表示，可以使用数字序号表示。
2. 缺陷类型：是根据缺陷的自然属性划分缺陷种类，如表1所示
表1软件缺陷类型列表
|
缺陷类型 |
描述 |
|
功能 |
影响了各种系统功能、逻辑的缺陷 |
|
用户界面 |
影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷 |
|
文档 |
影响发布和维护，包括注释，用户手册，设计文档 |
|
软件包 |
由于软件配置库、变更管理或版本控制引起的错误 |
|
不满足系统可测量的属性值，如执行时间，事务处理速率等。 | |
|
系统/模块接口 |
与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。 |
<!--[if !supportLists]-->
3. 缺陷严重程度：是指因缺陷引起的故障对软件产品的影响程度，所谓“严重性”我指的是在测试条件下，一个错误在系统中的绝对影响。如表2所示
表2软件缺陷严重等级列表
|
缺陷严重等级 |
描述 |
|
致命(Fatal) |
系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃、悬挂、死机，或者危及人身安全 |
|
严重(Critical) |
系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响 |
|
一般(Major) |
系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确；或用户界面差、操作时间长等一些问题。 |
|
较小(Minor) |
使操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别的不影响产品理解的错别字、文字排列不对齐等一些小问题。 |
4. 缺陷产生的可能性：指缺陷在产品中发生的可能性，通常可以用频率来表示，如表3所示。
表3缺陷产生可能性列表
|
缺陷产生可能性 |
描述 |
|
总是(Always) |
总是产生这个软件缺陷，其产生的频率是100% |
|
通常(Often) |
按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80-90% |
|
有时(Occasionally) |
按照测试用例，有的时候产生这个软件缺陷，其产生的频率大概是30-50% |
|
很少(rarely) |
按照测试用例，很少产生这个软件缺陷，其产生的频率大概是1-5% |
<!--[if !supportLists]-->5. 缺陷优先级：指缺陷必须被修复的紧急程度。“优先级”的衡量抓住了在严重性中没有考虑的重要程度因素，如表4所示。
表4软件缺陷优先级列表
文章来源于领测软件测试网 https://www.ltesting.net/