最终版缺陷管理(软件测试与度量).pptVIP

直方图 ..... * 圆饼图 ..... * Bug举例3 替换字符串长度未作限定： Word2000中，如果替换字符串长度过长，则会引起程序崩溃。 ..... * 软件问题报告（Bug报告） 软件问题（Bug）报告是软件测试过程中最重要的文档。它记录了Bug发生的环境，如各种资源的配置情况，Bug的再现步骤以及Bug性质的说明。 更重要的是它还记录着Bug的处理过程和状态。Bug的处理进程从一定角度反映了测试的进程和被测软件的质量状况以及改善过程。 ..... * 如果没有报告缺陷，后果？ ..... * 第1份缺陷报告 ..... * 判断Bug的规则 软件未达到产品规格说明书（需求）标明的功能。 软件出现了规格说明书指明不会出现的错误。 软件功能超出规格说明书指明的范围。 软件未达到规格说明书虽未指出但应达到的目标（隐含需求）。 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。 需要注意的是，测试人员报告Bug时，应当保证Bug是可以重现的。对于有时不可重现的Bug，应当反复测试，直到最终确定Bug的发生场景为止。 ..... * 报告Bug的基本原则 尽快报告Bug 修改成本小、修改风险小 避免报告同类缺陷 有效描述Bug 简单、明确、具体 每个缺陷一份报告 简化和优化操作步骤 保证重现缺陷 缺陷描述客观公正，不带评价和感情色彩 保证每个缺陷被报告和处理 ..... * 有效描述Bug 单一准确，每个报告只针对一个软件缺陷 可以再现，不要忽视或省略任何一项操作步骤，特别是关键性的操作一定要描述清楚，确保开发人员按照所描述的步骤可以再现缺陷 完整统一，提供完整的软件缺陷描述信息 短小简练，如使用业务关键词 特定条件，必须注明缺陷发生的特定条件 不做评价，客观描述 ..... * 一个简单的缺陷报告 ..... * 缺陷报告的描述 缺陷的严重性和优先级 缺陷的类型和来源 缺陷附件 完整的缺陷信息列表 ..... * 缺陷的严重性和优先级 严重性：缺陷对软件产品使用的影响程度 优先级：缺陷必须被修复的紧急程度 缺陷越严重，越要优先得到修正，缺陷严重等级和缺陷优先级相关性很强 也有例外，如有些缺陷比较严重，但由于技术的限制或第3方产品的限制，暂时没法修正，其优先级就会低 ..... * ..... * 缺陷的类型和来源 缺陷类型可以分为业务逻辑、数据处理、接口、UI、性能、安全性、兼容性、配置、文档等 缺陷来源，如需求说明书、设计规格说明书、代码、用户手册等 缺陷关联的模块名，缺陷来自于产品的特定模块的名称 缺陷发生的阶段，例如需求、系统架构设计、详细设计、编码等 ..... * 缺陷附件 一张图片可能胜过千言万语 Log file 工具捕捉的其它数据文件等 ..... * 完整的缺陷信息列表 ID 标题 前提 环境 操作步骤 期望结果 实际结果 频率 严重程度 优先级 类型 缺陷提交人 缺陷指定解决人 来源 产生原因 构建包跟踪 版本跟踪 提交时间 修正时间 验证时间 所属项目/模块 产品信息 状态 ..... * 编写Bug摘要 Bug的摘要是要用一句话的形式简明扼要地将Bug描述出来，要清晰指出Bug所在部位以及其错误类型，不能太笼统。 如“页面对非法输入有问题”可以修改为“流量信息查询页面对于非法输入没有进行校验”。 ..... * 有效描述Bug 操作步骤： 使用MappingBuilder对URL为“jdbc:mysql://2/test”的数据库进行映射，虚拟数据库名称设置为“VMysql”。 进入DataView主页面，在DAS List中点击“VMysql”右侧的“高级查询”链接。 在高级查询页面底端的输入框中，输入SQL语句“select * from empinfo”，点击查询按钮。 在得到的查询结果页面中，点击“下一页”链接。 翻页到下一页后，没有出现“保存当前页面的查询结果”链接，无法保存当前页面结果。 ..... * 有效的缺陷描述所带来的益处 容易再现所报告的问题，加快缺陷的修正 提高工作效率 提高测试人员的信任度，有利于开发团队和测试团队之间的的沟通和合作 客观、准确的产品质量评估 预防缺陷 ..... * 分离和再现缺陷的技巧 记下每一个操作步骤和中间结果 逐步尝试并缩小侦察范围 查找时间依赖问题 查找资源依赖问题 考虑软件和硬件配置不同的可能 ..... * 软件缺陷的处理和跟踪 软件缺陷生命周期 缺陷的跟踪处理 缺陷状态报告 发现 打开 修复 关闭 ..... * 缺陷状态 ..... * 软件缺陷生命周期 ..... * 复杂的软件缺陷生命周期 ..... * 缺陷的跟踪处理 密切跟踪缺陷状态的变化，及时处理缺陷，使项目按预