准确报告软件缺陷

1、准确报告软件缺陷作者:日期:软件缺陷的描述是是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发小组交 流的最初且最好的机会。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员。准确报告软件缺陷是非常重要的，因 为：? 清晰准确的软件缺陷描述可以减少软件缺陷从开发人员返回的数量? 提高软件缺陷修复的速度，使每一个小组能够有效的工作? 提高测试人员的信任度，可以得到开发人员对清晰的软件缺陷描述有效的响应? 加强开发人员，测试人员和管理人员的协同工作，让他们可以更好的工作在多年实践的基础上，我们积累了较多的软件缺陷的有效描述规则，

2、主要是：? 单一准确。每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常 常会导致缺陷部分被注意和修复，不能得到彻底的修正。? 可以再现。提供缺陷的精确操作步骤，使开发人员容易看懂，可以自己再现这个缺陷， 通常情况下，开发人员只有再现了缺陷，才能正确地修复缺陷。? 完整统一。提供完整、前后统一的软件缺陷的步骤和信息，例如：图片信息，Log文件等。? 短小简练。通过使用关键词，可以使软件缺陷的标题的描述短小简练，又能准确解释产 生缺陷的现象。如 主页的导航栏在低分辨率下显示不整齐”中 主页” 导航栏” 分辨率”等是关键词。? 特定条件。许多软件功能在通常情况下没有问题，而是在某种

3、特定条件下会存在缺陷， 所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、 浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。如搜索功能在没有找到结果返回时跳转页面不对 ”。? 补充完善。从发现 bug那一刻起，测试人员的责任就是保证它被正确的报告，并且得到 应有的重视，继续监视其修复的全过程。? 不做评价。在软件缺陷描述不要带有个人观点，对开发人员进行评价。软件缺陷报告是 针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议 论。软件缺陷属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、 缺陷状态、缺陷起源、缺陷来

4、源、缺陷原因。1. 缺陷标识：是标记某个缺陷的唯一的表示，可以使用数字序号表示2. 缺陷类型：是根据缺陷的自然属性划分缺陷种类，如表1所示表1软件缺陷类型列表缺陷类型描述功能影响了各种系统功能、逻辑的缺陷用户界面影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷文档影响发布和维护，包括注释，用户手册，设计文档软件包由于软件配置库、变更管理或版本控制引起的错误性能不满足系统可测量的属性值，如执行时间，事务处理速率等。系统/模块接口与其他组件、模块或设备驱动程序、调用参数、控制块或参数 列表等不匹配、冲突。<!-if !supportLists->3.

5、 缺陷严重程度：是指因缺陷引起的故障对软件产品的影响程度，所谓“严重性”我指的是在 测试条件下，一个错误在系统中的绝对影响。如表2所示<!-e ndif_>表2软件缺陷严重等级列表缺陷严重等级描述致命(Fatal)系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃、悬挂、死机，或者危及人身安全严重系统的主要功能部分丧失、数据不能保存，系统的次要功(Critical)能完全丧失，系统所提供的功能或服务受到明显的影响一般(Major)系统的次要功能没有完全实现，但不影响用户的正常使用。 例如：提示信息不太准确；或用户界面差、操作时间长等一 些问题。较小(Mi nor)使操作者不方

6、便或遇到麻烦，但它不影响功能的操作和执 行，如个别的不影响产品理解的错别字、文字排列不对齐等一些小问题。4. 缺陷产生的可能性：指缺陷在产品中发生的可能性，通常可以用频率来表示，如表3所示。表3缺陷产生可能性列表缺陷产生可能性描述总是(Always)总是产生这个软件缺陷，其产生的频率是100%通常（Ofte n）按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80-90%有时(Occasionally)按照测试用例，有的时候产生这个软件缺陷，其产生的频率大概是30-50%很少(rarely)按照测试用例，很少产生这个软件缺陷，其产生的频率大概是 1-5%<!-if !sup

7、portLists-> 5.缺陷优先级：指缺陷必须被修复的紧急程度。“优先级”的衡量抓住 了在严重性中没有考虑的重要程度因素，如表4所示。<!-e ndif_>表4软件缺陷优先级列表缺陷优先级描述立即解决（P1级）缺陷导致系统几乎不能使用或测试不能继续，需立即修复高优先级（P2级）缺陷严重，影响测试，需要优先考虑正常排队（P3级）缺陷需要正常排队等待修复低优先级（P4级）缺陷可以在开发人员有时间的时候被纠正。一般来讲，缺陷严重等级和缺陷优先级相关性很强，但是，具有低优先级和高严重性 的错误是可能的，反之亦然。例如，产品徽标是重要的，一旦它丢失了，这种缺陷是用户界面的 产品缺陷

8、，但是它阻碍产品的形象。那么它是优先级很高的软件缺陷。<!-if !supportLists-> 6.缺陷状态：指缺陷通过一个跟踪修复过程的进展情况，也就是在软件生命周期中的状态基本定义，如表5所示。<!-e ndif_>表5软件缺陷状态列表缺陷状态描述激活或打开（Active or Open ）问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处 理，如新报的缺陷。已修正或修复(Fixed orResolved)已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决 但还没有被测试人员验证关闭或非激活(Close orInactive)测试人员验证后，确认缺陷不

9、存在之后的状态。重新打开测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复推迟这个软件缺陷可以在下一个版本中解决保留由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷不能重现开发不能复现这个软件缺陷，需要测试人员检查缺陷复现的步 骤。<!-if !supportLists-><!-if !supportLists-> 7.缺陷来源：指缺陷所在的地方，如文档、代码等，如表 6所示。<!-e ndif_>表6软件缺陷来源列表缺陷来源描述需求说明书需求说明书的错误、或不清楚引起的问题设计文档设计文档描述不准确、和需求说明书不一致的问题系统集成接口系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷数据流（库）由于数据字典、数据库中的错误引起的缺陷程序代码纯粹在编码中的问题所引起的缺陷<!-if !supportLists-> 8.缺陷根源：指造成上述错误的根本因素，以寻求软件开发流程的改进、管理水平的提高，如表7所示。<!-e ndif_>表7软件缺陷根源列表缺陷根源描述测试策略错误的测试范围，误解了测试目标，超越测试能力等过程，工具和方法无效的需求收集过程，过时的风险管理过程，不适用的项目管 理方法，没有估算规程，无效的变更控制过程等。团队/人项目团队职责交叉，缺乏培训。没有经验的项目