软件缺陷管理教案分析.pptVIP

缺陷报告 简单描述： 广联达服务新干线，会员注册时，点击“提交”按钮无反应 详细描述： 环境：测试浏览器为ie6，winXP 步骤：打开网站首页，点击“会员注册”,输入注册时填写的各项信息，点击“提交”按钮 实际结果：页面无法跳转至注册成功页面，并无任何提示信息 期望结果：跳转到注册成功页面 相关附件： 输入的注册信息截图 缺陷初步分析： ie8中不可复现 ie6中复现 Bug提交规范 描述：简单扼要，突出主题 详细描述： 操作步骤：写明测试环境、具体操作步骤，输入的具体数据等 期望结果：预期输出的结果 实际结果：实际输出的结果 其他要素 状态、优先级、严重级别、测试人、测试时间、是否复现、软件版本…. 好的Bug报告应满足以下几方面的要求 结构清晰 复现故障再写报告 归纳比较：是否其他模块也有相同的Bug 总结：报告的开头有Bug的总结 精简：不要有多余的步骤和语言 无歧义：语言明确 中立：无批评性语言 讨论：将要发出的报告送其他测试人员讨论 准确、清楚、完整、简洁、一致 课程内容 一、软件缺陷管理基本概念 二、软件缺陷管理基本流程 三、缺陷报告的写作方法 四、缺陷重现分析技术 1、找人来回答 2、回答不出来的问思路 每个现象用注册一一举例 　　Bug的来源 　　需求阶段的BUG——来源： 　　● 模糊不清的需求 　　● 忽略的需求 　　● 冲突的需求 　　分析、设计阶段的BUG——来源： 　　● 忽略设计 　　● 混乱的设计 ：这样的情况发生在两种设计性质完全相反的情况中，如果在实际的系统中，某块地址规定不允许被多线程访问，而方案却被设计成以多线程方式进行，则会在此层面上产生BUG，严重的会造成整个系统的崩溃。 　　● 模糊的设计：模糊BUG产生的原因在于设计人员对需求没有清晰的认识，或者需求本身就是含糊不清的。 　　实现阶段的BUG——来源： 　　● 遗漏的功能 　　● 内存溢出：属于一种比较严重的软件BUG类型。例如，软件执行了某些强行向操作系统保护地址写入数据的指令，导致整个环境的彻底崩溃；再如：数值除零导致堆栈溢出 　　● 其他实现：表现为出现的错误难以定位其类型，比如在产品化阶段，测试人员或者最终用户提出的部分提高程序运行效率的建议，当然开发人员并不完全处理这些问题，但是这些建议将成为一种特殊的BUG类型，被保留在项目数据库中。 　　配置阶段的BUG 　　● 配置阶段的BUG是最危险的，往往体现在软件交付或者最后的系统测试中。 　　● 配置阶段的BUG出现的原因是复杂的，比较典型的是旧的代码覆盖了新的代码；或者测试服务器上的代码和实现人员本机最新代码版本不一致。这些情况造成了错误代码被修改后，经过一个时间段再次回归测试时又会出现同样的问题。 　　● 配置阶段的BUG解决方案也很简单，项目组可以指定专人（集成员）进行配置和集成管理，集成员保证正确集成整个系统，并将最新的代码发布到测试服务器或者客户服务器上。这个阶段由QA（质量保证）部门负责监管和控制，规定集成的时间间隔和最佳集成时间，统一维护一份项目组集成人员和集成时间列表。 　　短视将来的BUG 　　● 很多软件BUG都是设计人员或者实现人员的眼光短浅造成的，出名的例子就是“千年虫”问题。 　　● 其他短视的BUG例子还有我们以前的身份证号码，原来的15位的编号根本不符合一人一号的设计要求，重码的现象相当严重。所以出现了18位号码。 　　● 再如：中国移动开发了134号段的号码。现在又有了159号段。 　　静态文档的BUG 　　● 文档BUG的定义很简单，即说明模糊、描述不完整和过期的都属于文档BUG。 　　● 说明模糊特指无充分的信息判断如何正确地处理事情。例如设计文档中说明了对类实例方法的调用，却没说明边界条件和特殊的调用顺序。 　　● 描述不完整特指文档信息不足以支持用户完成某项工作。例如某套软件的某一项操作有具体的前置条件，而客户从文档上并没有获取关于该前置操作的相关信息，客户便认为软件存在着BUG。 　　● 过期文档本身就是错的并且无法弥补，这种现象经常发生在后期对系统功能修改而没有及时更新对应的文档，造成了文档的不一致性。 功能类 A. 重复的功能 B. 多余的功能 C. 功能实现与设计要求不相符 D. 功能使用性、方便性、易用性不够 界面类 A. 界面不美观 B. 控件排列、