《测试执行及测试报告》.ppt

测试执行,Chapter 1 测试执行,Chapter 2 软件缺陷,课程目录,Chapter 3 测试报告,Chapter 1 测试执行,1.1 什么是执行测试用例 1.2 测试执行过程注意事项,什么是执行测试用例,根据已有的测试用例，按照里面的步骤一步一步的执行，查看预期结果与实际结果是否一致。,明确要在被测软件的哪个版本上执行？ 确认要验证的测试点，在被测版本上已经实现了。 按照测试用例的预置条件、步骤进行执行 按照测试用例的预期结果进行结果判断 如果结果失败，说明找到了缺陷,测试用例的执行,当用例还尚未被执行时，是No Test未执行状态 当执行结果与预期结果相符时，是Pass通过状态 当执行结果与预期结果不符时，是Fail失败状态 当因为软件有缺陷而妨碍了用例步骤的执行，且该缺陷并不是我们的测试点，则用例是Block阻碍状态。 当用例正在执行中，但是需要耗较多时间去观察其结果，是Investigate观察中状态。,用例执行结果,测试执行过程注意事项,搭建测试环境事项 注意前提条件和特殊说明 测试用例要全部执行 不要忽视任何偶然现象 加强测试过程记录 详细预期与实际的不一致 提交缺陷时与开发的关系处理 提交一份优秀的问题报告单 及时更新测试用例,Chapter 2 软件缺陷,2.1 缺陷的理论基础 2.2 缺陷的生命周期 2.3 缺陷的流程 2.4 缺陷的状态 2.5 缺陷的等级 2.6 缺陷实例与练习,缺陷理论基础,2.1.1 缺陷的定义 2.1.2 缺陷的原因 2.1.3 缺陷的修复成本 2.1.4 缺陷的分布特征 2.1.5 缺陷的抗药性 2.1.6 并非所有缺陷都要修改,缺陷的定义,软件未实现需求和规格要求的功能 软件出现了需求和规格指明不该出现的错误 软件实现了需求和规格未提及的功能 软件未实现需求和规格未明确提及但应该实现的内容 软件难以理解，不易使用，运行缓慢，或者最终用户(估计会)认为不好。 测试用例执行中发现的与预期结果不符的现象 缺陷又名为BUG（臭虫）,缺陷的原因,缺陷的修复成本,缺陷的分布特征,集结（二八定理） 缺陷往往喜欢扎堆，一个模块已经发现的缺陷比别的模块多，通常不是代表这个模块已经把缺陷暴露完了，而是意味着这个模块还存在有同样多的缺陷尚未被发现。这就是著名的二八定理：80%的缺陷出现在 20%的模块。,并非所有的缺陷都需要修复,有一些原因，使得有些缺陷我们不修复： 没有足够的时间 不算真正的软件缺陷 修复的风险太大 不值得修复,缺陷的生命周期,缺陷的流程,缺陷生命周期状态,缺陷的等级,缺陷单的编写,一个好的缺陷单，是你提交之后就再也没人联系你，然后过了一段时间已经被完美地修复，转回到你手上进行验证测试这样的一个单子 要做到这样，你应该怎么做呢 1、提供足够的错误环境信息，使得开发人员既能够明确如何重现故障现象，又有足够的信息定位到问题的根源 2、书写良好的重现步骤； 3、上传附件，例如软件运行日志，抓图，网络抓包，声音，视频等。 4、使用特殊的颜色对重点词语进行标记； 5、使用关键词进行强调 6、特殊标记,一个缺陷的基本要素,缺陷ID 缺陷复现步骤 缺陷标题 期望结果 测试环境 实际结果 缺陷发现的日期和时间 附件 缺陷提交人 缺陷的优先级 缺陷的严重等级； 测试类型 发现缺陷的软件版本,例子-excel表,例子-bugfree,如何写好每部分（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 测试总结,数据统计-人力投入,数据统计-用例覆盖率,数据统计-问题单分类统计,遗留bug情况,测试风险,测试对象评估,测试结论,测试结果分析,测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴