测试执行及测试报告要点.ppt

如何写好每部分（1） 标题：创建一个简短的标题，让问题看起来更清晰。“应用崩溃”是一个很恼人的标题因为它没有足够的信息包括在这份报告里面。取而代之的是标题应该包含错误消息和消息码，或者是结果的名称以及失败时你正在做的事情。例如：Error 402:访问拒绝当点击“发送邮件”这个例子就提供了缺陷系统的上下文信息。 差：“程序崩溃”，“报错”，“Bug” 好：“从’Kifu’中打印时5C79错误”，“’Kifu honors’报表为空” 产品：用名称标识产品，告知你使用的是哪个版本。绝大部分软件都包含有版本信息。web应用的版本信息通常在页脚。 差：“你的应用” 好：”Kifu v1.01″ 平台：告诉我们软件运行在什么平台。尤其是操作系统的名字及版本和游览器名称版本。特别是web应用，这些信息对我们很重要。 差：“Windows” 好：“Windows7,IE9” 是否能重现：有些恼火的Bug是间歇性的出现，我们想预先知道，如果我们正在处理一个灵异事件或者正逢Bug出现时。 差：留空白 好：“每次”，“偶然”，“不重现” 如何写好每部分（2） ● 总结：用简洁的语言概括出Bug出现时你正在做的事情。从上下文开始，在操作应用的哪个部分。聚焦在你做的时候软件做了什么？ 差：“系统不能用了” 好：在“honor report”页面单击“打印按钮”，但是报表是空的。 ● 发生了什么：一步一步描述你做的事情当bug出现时，为什么你认为是错误的。事无巨细，打印出菜单的名称，页面标题，点击时的按钮或者链接的名称。做相同的操作是不是出现一样的错误。 差：“空白报表” 好：“点击 ‘File/Save as…’，’Save‘对话空弹出，然后点击‘OK’按钮，但是文件没有保存” ● 错误时什么：如果错误消息出现时，拷贝粘贴整个信息，这样更有利于我们跟踪错误。 差：“有个错误，点击它始终读不出” 好：“Error 403：访问拒绝” ● 复现的步骤：如果你可以让bug重现，那太好了，这能提供很大的帮助。一步步描述如何重现次bug。 差：“打印没法使用” 好：“从‘Honors Report’页面，点击‘打印按钮’” 如何写好每部分（3） ● 预期结果：描述你预期发生的结果当bug发生时，这部分特别有用如果程序没有按照你期待的结果发生时，因为它很诡异。 差：“我期待能正常工作” 好：“我期待能看到‘Honors Reports’的PDF文件” 真实结果：当bug发生时是怎么发生的，什么错误，为什么有错，或者如果错误抛出，抛出什么错。 差：“没法用” 好：“我收到是空的PDF文件，或者’403错误，访问拒绝’” ● 附件：如果你知道怎么截屏，做吧，附上一个简短的错误，截屏可以是错误之前或者发生错误之后，我们的开发者能够看到究竟发生了什么。如果应用有崩溃的日志，同样附上它。 Chapter 3 测试报告 3.1 测试报告的主要内容实例 3.2 测试结果分析 3.3 测试总结 测试报告的主要内容（掌上书院） 3.1.1 数据统计 3.1.2 遗留bug情况 3.1.3 测试风险 3.1.4 测试对象评估 3.1.5 测试结论 3.2 测试总结 数据统计-人力投入 投入项 测试人员 工作量（人天） 测试用例维护 XXX 1天/人 测试执行 XX、XXX 9.5天/人（XX：5.5天，XXX：4天） 合计 XX、XXX 9.5天/人 数据统计-用例覆盖率 用例总数 通过用例数（OK） 未通过用例数（NG） 尚未测试（NT） 无测试条件，暂时不能测试（NC） 尚未开发（ND） 通过率（％） 备注 263 251 0 0 1 11 1 新增加19个用例 数据统计-问题单分类统计 1、Bug严重级别统计 致命 严重 一般 提示 合计 0 7 26 4 37 2、BUG类型统计 功能 UI 异常 体验 合计 26 1 0 10 37 3、Bug状态统计 未解决 打回 挂起 已解决 打开合计 关闭合计 37 0 0 0 0 0 　 4、Bug根源分析表 需求类 设计类 编码类 其他 　 4 0 0 0 　 遗留bug情况 序号 BugID 缺陷描述 影响程度 后续解决措施 当前规避方法 1 224 Web页面—下载热门推荐，中间的节日专区，配置new，hot标识时，在IE6下将产生换行。 未影响功能（兼容性问题） 暂时忽略 在下载热门推荐时，不采用new、hot配置 2 314 后台管理—图片管理，点击上传图片在IE6.0下，随机出现上传窗口无法打开的情况。 比较小 暂时忽略 后台维护时，请采用IE7.0浏览器 测试风险 暂停的问题： 1、 出现概率比较低，用户操作不易复现的问题，后续由客户端修改；2、3是本地阅读定位问题，修改比较困难，不影响