测试执行及测试报告

并非所有的缺陷都需要修复
• 有一些原因，使得有些缺陷我们不修复：
没有足够的时间 不算真正的软件缺陷 修复的风险太大 不值得修复
缺陷的生命周期
缺陷的流程
缺陷生命周期—状态
缺陷状态
New
测试中新报告的软件缺陷，等待分派
Open
已确认的缺陷，等待开发人员修改
描述
Fixed Rejected Reopen Closed
缺陷的定义
• 软件未实现需求和规格要求的功能 • 软件出现了需求和规格指明不该出现的错误 • 软件实现了需求和规格未提及的功能 • 软件未实现需求和规格未明确提及但应该实现的内容 • 软件难以理解，不易使用，运行缓慢，或者最终用户(估计会)认为不
好。 • 测试用例执行中发现的与预期结果不符的现象
缺陷又名为BUG（臭虫）
者如果错误抛出，抛出什么错。 • 差：“没法用” • 好：“我收到是空的PDF文件，或者’403错误，访问拒绝’”
• • ● 附件：如果你知道怎么截屏，做吧，附上一个简短的错误，截屏可
以是错误之前或者发生错误之后，我们的开发者能够看到究竟发生了 什么。如果应用有崩溃的日志，同样附上它。
Chapter 3 测试报告
易用性评估
易用性较5.3版本好，在功能和界面上做了很多优化
5.
其他评估
功能上简单易用，界面友好悦目，功能上在txt格式章节提取、下载速度上做了很大优化
测试结果分析
•
测试执行结束后，测试活动还没有结束。测试结果分析是必不可
少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一
轮测试工作的开展有很大的借鉴意义。
•
因为通过对问题单的分析、总结不仅能发现不同人提交问题的
类别与差异，还能发现自身思维的局限性，避免下轮测试进入自我盲
区。
测试总结
• 回顾整个项目的测试过程，总结个人成长经验，取得了什 么成绩、有哪些不足、有什么好的经验或者方法可以和大 家分享呢？对工作进行一个理性的分析和思考。
问答
培训总结
• ● 总结：用简洁的语言概括出Bug出现时你正在做的事情。从上下文开始， 在操作应用的哪个部分。聚焦在你做的时候软件做了什么？
• 差：“系统不能用了” • 好：在“honor report”页面单击“打印按钮”，但是报表是空的。 • ● 发生了什么：一步一步描述你做的事情当bug出现时，为什么你认为是错
缺陷的原因
其它 编码
比例
设计
需求与规格
需求与规格 设计 编码 其它
缺陷的修复成本
缺陷的分布特征
• 集结（二八定理）
缺陷往往喜欢扎堆，一个模块已经发现的缺陷比别的模块多， 通常不是代表这个模块已经把缺陷暴露完了，而是意味着这个模块还 存在有同样多的缺陷尚未被发现。这就是著名的二八定理：80%的缺 陷出现在 20%的模块。
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” • 好：“从’Kifu’中打印时5C79错误”，“’Kifu honors’报表为空” • 产品：用名称标识产品，告知你使用的是哪个版本。绝大部分软件都包含有
版本信息。web应用的版本信息通常在页脚。 • 差：“你的应用” • 好：”Kifu v1.01″ • 平台：告诉我们软件运行在什么平台。尤其是操作系统的名字及版本和游览
测试执行
课程目录
Chapter 1 测试执行 Chapter 2 软件缺陷 Chapter 3 测试报告
Chapter 1 测试执行
1.1 什么是执行测试用例 1.2 用例的状态；
什么是执行测试用例
根据已有的测试用例，按照里面的步骤一步一步的执行， 查看预期结果与实际结果是否一致。
1. 明确要在被测软件的哪个版本上执行？ 2. 确认要验证的测试点，在被测版本上已经实现了。 3. 按照测试用例的预置条件、步骤进行执行 4. 按照测试用例的预期结果进行结果判断 5. 如果结果失败，说明找到了缺陷
1、Bug严重级别统计 致命
பைடு நூலகம்严重
0
7
功能
26
3、Bug状态统计 未解决
37
4、Bug根源分析表 需求类
4
UI
1
打回
0
设计类
0
一般
提示
26
4
2、BUG类型统计
异常
体验
0
10
挂起
已解决
0
0
编码类
其他
0
0
合计
37
合计
37
打开合计
0
关闭合计
0
遗留bug情况
序号
BugID
缺陷描述
影响程度 后续解决措施
当前规避方法
1
224 Web页面—下载热门推荐，中间的节日专区，配置 未 影 响 功 能 暂时忽略
在下载热门推荐时，不采用new、
new，hot标识时，在IE6下将产生换行。
（兼容性问
hot配置
题）
2
314 后台管理—图片管理，点击上传图片在IE6.0下，随 比较小
暂时忽略
后台维护时，请采用IE7.0浏览器
机出现上传窗口无法打开的情况。
误的。事无巨细，打印出菜单的名称，页面标题，点击时的按钮或者链接的 名称。做相同的操作是不是出现一样的错误。 • 差：“空白报表” • 好：“点击 ‘File/Save as…’，’Save‘对话空弹出，然后点击‘OK’按 钮，但是文件没有保存” • ● 错误时什么：如果错误消息出现时，拷贝粘贴整个信息，这样更有利于我 们跟踪错误。 • 差：“有个错误，点击它始终读不出” • 好：“Error 403：访问拒绝” • ● 复现的步骤：如果你可以让bug重现，那太好了，这能提供很大的帮助。 一步步描述如何重现次bug。 • 差：“打印没法使用” • 好：“从‘Honors Report’页面，点击‘打印按钮’”
2--一般 1--轻微
软件在某些情况下会出错，但是造成的后果影响不大 在某些情况下会出错，但是造成的后果影响很小
缺陷单的编写
• 一个好的缺陷单，是你提交之后就再也没人联系你，然后过了一段时间 已经被完美地修复，转回到你手上进行验证测试这样的一个单子
• 要做到这样，你应该怎么做呢 1、提供足够的错误环境信息，使得开发人员既能够明确如何重现故障 现象，又有足够的信息定位到问题的根源 2、书写良好的重现步骤； 3、上传附件，例如软件运行日志，抓图，网络抓包，声音，视频等。 4、使用特殊的颜色对重点词语进行标记； 5、使用关键词进行强调 6、特殊标记
XX、XXX
工作量（人天） 1天/人 9.5天/人（XX：5.5天，XXX：4天）
9.5天/人
数据统计-用例覆盖率
用例总数
通过用例数 未通过用例数（NG） （OK）
尚未测试（NT） 无测试条件，暂时尚未开发（ND）通过率（％） 不能测试（NC）
备注
263
251
0
0
1
11
1
新增加19个
用例
数据统计-问题单分类统计
如何写好每部分（3）
• ● 预期结果：描述你预期发生的结果当bug发生时，这部分特别有用 如果程序没有按照你期待的结果发生时，因为它很诡异。
• 差：“我期待能正常工作” • 好：“我期待能看到‘Honors Reports’的PDF文件” • 真实结果：当bug发生时是怎么发生的，什么错误，为什么有错，或
测试风险
暂停的问题：
1、 出现概率比较低，用户操作不易复现的问题，后续由客户端修改； 2、3是本地阅读定位问题，修改比较困难，不影响使用，后续优化； 5、属于遗留问题； 4、6、7属于内容平台问题，内容优化；
暂停问题是产品人员、开发人员与测试人员沟通后暂停的。
测试对象评估
1.
基本功能评估
5.4版本在本地阅读txt格式章节提取、在线阅读预加载、下载管理重实现、用户反馈功能实 现、图书内容分享、网络连接、UI上做了一些修改、优化、调整，增加了一些新功能，本地 阅读、在线阅读等基本功能改动不大，且都已实现稳定。
3.1 测试报告的主要内容<实例> 3.2 测试结果分析 3.3 测试总结
测试报告的主要内容（掌上书院）
3.1.1 数据统计 3.1.2 遗留bug情况 3.1.3 测试风险 3.1.4 测试对象评估 3.1.5 测试结论
数据统计-人力投入
投入项 测试用例维护 测试执行
合计
测试人员 XXX XX、XXX
2.
性能评估
性能主要体现在：
1.本地阅读设置方面，设置后本地阅读界面都能正常显示；
2.Txt格式图书章节提取，是否精确；
3.下载管理重实现，在线小说的下载，多任务的下载是否顺畅；
4.在线阅读，连续阅读是否顺畅；
5.Wifi和GPRS网络连接下，客户端的使用是否顺畅；
3.
稳定性评估
软件各基本功能稳定
4.
已经被开发人员修改的缺陷，等待测试人员校验 不是缺陷或不需要修复 没有修复，重新打开返回开发人员 已经被测试人员确认得到正确修复，可以关闭
缺陷的等级
缺陷严重程度
描述
4--致命
软件无法运行，或者软件的主要功能丧失，或者很大可能性会造成严重不良后果
3--严重
–软件的次要功能丧失，或者主要功能在一些特定情况下会出错 ，比如金额计算等
器名称版本。特别是web应用，这些信息对我们很重要。 • 差：“Windows” • 好：“Windows7,IE9” • 是否能重现：有些恼火的Bug是间歇性的出现，我们想预先知道，如果我们
正在处理一个灵异事件或者正逢Bug出现时。 • 差：留空白 • 好：“每次”，“偶然”，“不重现”
如何写好每部分（2）
1. 当用例还尚未被执行时，是No Test未执行状态
2. 当执行结果与预期结果相符时，是Pass通过状态
3. 当执行结果与预期结果不符时，是Fail失败状态
4. 当因为软件有缺陷而妨碍了用例步骤的执行，且该缺陷 并不是我们的测试点，则用例是Block阻碍状态。
5. 当用例正在执行中，但是需要耗较多时间去观察其结果， 是Investigate观察中状态。
一个缺陷的基本要素
缺陷ID 缺陷标题 测试环境 缺陷发现的日期和时间 缺陷提交人 缺陷的优先级 缺陷的严重等级； 测试类型 发现缺陷的软件版本
缺陷复现步骤 期望结果 实际结果 附件
例子-excel表
例子-bugfree
如何写好每部分（1）
• 标题：创建一个简短的标题，让问题看起来更清晰。“应用崩溃”是一个很 恼人的标题因为它没有足够的信息包括在这份报告里面。取而代之的是标题 应该包含错误消息和消息码，或者是结果的名称以及失败时你正在做的事情。 例如：Error 402:访问拒绝当点击“发送邮件”这个例子就提供了缺陷系统的 上下文信息。