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

1、测试执行,Chapter 1 测试执行,Chapter 2 软件缺陷,课程目录,Chapter 3 测试报告,Chapter 1 测试执行,1.1 什么是执行测试用例 1.2 测试执行过程注意事项,什么是执行测试用例,根据已有的测试用例，按照里面的步骤一步一步的执行，查看预期结果与实际结果是否一致。,明确要在被测软件的哪个版本上执行？ 确认要验证的测试点，在被测版本上已经实现了。 按照测试用例的预置条件、步骤进行执行 按照测试用例的预期结果进行结果判断 如果结果失败，说明找到了缺陷,测试用例的执行,当用例还尚未被执行时，是No Test未执行状态 当执行结果与预期结果相符时，是Pass通过状态

2、 当执行结果与预期结果不符时，是Fail失败状态 当因为软件有缺陷而妨碍了用例步骤的执行，且该缺陷并不是我们的测试点，则用例是Block阻碍状态。 当用例正在执行中，但是需要耗较多时间去观察其结果，是Investigate观察中状态。,用例执行结果,测试执行过程注意事项,搭建测试环境事项 注意前提条件和特殊说明 测试用例要全部执行 不要忽视任何偶然现象 加强测试过程记录 详细预期与实际的不一致 提交缺陷时与开发的关系处理 提交一份优秀的问题报告单 及时更新测试用例,Chapter 2 软件缺陷,2.1 缺陷的理论基础 2.2 缺陷的生命周期 2.3 缺陷的流程 2.4 缺陷的状态 2.5 缺陷

3、的等级 2.6 缺陷实例与练习,缺陷理论基础,2.1.1 缺陷的定义 2.1.2 缺陷的原因 2.1.3 缺陷的修复成本 2.1.4 缺陷的分布特征 2.1.5 缺陷的抗药性 2.1.6 并非所有缺陷都要修改,缺陷的定义,软件未实现需求和规格要求的功能 软件出现了需求和规格指明不该出现的错误 软件实现了需求和规格未提及的功能 软件未实现需求和规格未明确提及但应该实现的内容 软件难以理解，不易使用，运行缓慢，或者最终用户(估计会)认为不好。 测试用例执行中发现的与预期结果不符的现象 缺陷又名为BUG（臭虫）,缺陷的原因,缺陷的修复成本,缺陷的分布特征,集结（二八定理） 缺陷往往喜欢扎堆，一个模块

4、已经发现的缺陷比别的模块多，通常不是代表这个模块已经把缺陷暴露完了，而是意味着这个模块还存在有同样多的缺陷尚未被发现。这就是著名的二八定理：80%的缺陷出现在 20%的模块。,并非所有的缺陷都需要修复,有一些原因，使得有些缺陷我们不修复： 没有足够的时间 不算真正的软件缺陷 修复的风险太大 不值得修复,缺陷的生命周期,缺陷的流程,缺陷生命周期状态,缺陷的等级,缺陷单的编写,一个好的缺陷单，是你提交之后就再也没人联系你，然后过了一段时间已经被完美地修复，转回到你手上进行验证测试这样的一个单子 要做到这样，你应该怎么做呢 1、提供足够的错误环境信息，使得开发人员既能够明确如何重现故障现象，又有足够

5、的信息定位到问题的根源 2、书写良好的重现步骤； 3、上传附件，例如软件运行日志，抓图，网络抓包，声音，视频等。 4、使用特殊的颜色对重点词语进行标记； 5、使用关键词进行强调 6、特殊标记,一个缺陷的基本要素,缺陷ID 缺陷复现步骤 缺陷标题 期望结果 测试环境 实际结果 缺陷发现的日期和时间 附件 缺陷提交人 缺陷的优先级 缺陷的严重等级； 测试类型 发现缺陷的软件版本,例子-excel表,例子-bugfree,如何写好每部分（1）,标题：创建一个简短的标题，让问题看起来更清晰。“应用崩溃”是一个很恼人的标题因为它没有足够的信息包括在这份报告里面。取而代之的是标题应该包含错误消息和消息码，

6、或者是结果的名称以及失败时你正在做的事情。例如：Error 402:访问拒绝当点击“发送邮件”这个例子就提供了缺陷系统的上下文信息。 差：“程序崩溃”，“报错”，“Bug” 好：“从Kifu中打印时5C79错误”，“Kifu honors报表为空” 产品：用名称标识产品，告知你使用的是哪个版本。绝大部分软件都包含有版本信息。web应用的版本信息通常在页脚。 差：“你的应用” 好：”Kifu v1.01 平台：告诉我们软件运行在什么平台。尤其是操作系统的名字及版本和游览器名称版本。特别是web应用，这些信息对我们很重要。 差：“Windows” 好：“Windows7,IE9” 是否能重现：有些

7、恼火的Bug是间歇性的出现，我们想预先知道，如果我们正在处理一个灵异事件或者正逢Bug出现时。 差：留空白 好：“每次”，“偶然”，“不重现”,如何写好每部分（2）, 总结：用简洁的语言概括出Bug出现时你正在做的事情。从上下文开始，在操作应用的哪个部分。聚焦在你做的时候软件做了什么？ 差：“系统不能用了” 好：在“honor report”页面单击“打印按钮”，但是报表是空的。 发生了什么：一步一步描述你做的事情当bug出现时，为什么你认为是错误的。事无巨细，打印出菜单的名称，页面标题，点击时的按钮或者链接的名称。做相同的操作是不是出现一样的错误。 差：“空白报表” 好：“点击 File/S

8、ave as，Save对话空弹出，然后点击OK按钮，但是文件没有保存” 错误时什么：如果错误消息出现时，拷贝粘贴整个信息，这样更有利于我们跟踪错误。 差：“有个错误，点击它始终读不出” 好：“Error 403：访问拒绝” 复现的步骤：如果你可以让bug重现，那太好了，这能提供很大的帮助。一步步描述如何重现次bug。 差：“打印没法使用” 好：“从Honors Report页面，点击打印按钮”,如何写好每部分（3）, 预期结果：描述你预期发生的结果当bug发生时，这部分特别有用如果程序没有按照你期待的结果发生时，因为它很诡异。 差：“我期待能正常工作” 好：“我期待能看到Honors Repo

9、rts的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情况,测试风险,测试对象评估,测试结论,测试结果分析,测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴