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
测试执行
课程目录
Chapter 1 测试执行 Chapter 2 软件缺陷 Chapter 3 测试报告
Chapter 1 测试执行
1.1 什么是执行测试用例 1.2 测试执行过程注意事项
什么是执行测试用例
根据已有的测试用例，按照里面的步骤一步一步的执行， 查看预期结果与实际结果是否一致。
1. 明确要在被测软件的哪个版本上执行？ 2. 确认要验证的测试点，在被测版本上已经实现了。 3. 按照测试用例的预置条件、步骤进行执行 4. 按照测试用例的预期结果进行结果判断 5. 如果结果失败，说明找到了缺陷
•
安全在于心细，事故出在麻痹。20.11. 720.11. 700:31: 3100:3 1:31November 7, 2020
•
加强自身建设，增强个人的休养。202 0年11 月7日上 午12时 31分20 .11.720 .11.7
•
追求至善凭技术开拓市场，凭管理增 创效益 ，凭服 务树立 形象。2 020年1 1月7日 星期六 上午12 时31分 31秒00 :31:312 0.11.7
好。 • 测试用例执行中发现的与预期结果不符的现象
缺陷又名为BUG（臭虫）
缺陷的原因
缺陷的修复成本
缺陷的分布特征
• 集结（二八定理）
缺陷往往喜欢扎堆，一个模块已经发现的缺陷比别的模块多， 通常不是代表这个模块已经把缺陷暴露完了，而是意味着这个模块还 存在有同样多的缺陷尚未被发现。这就是著名的二八定理：80%的缺 陷出现在 20%的模块。
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个
用例
数据统计-问题单分类统计
误的。事无巨细，打印出菜单的名称，页面标题，点击时的按钮或者链接的 名称。做相同的操作是不是出现一样的错误。 • 差：“空白报表” • 好：“点击 ‘File/Save as…’，’Save‘对话空弹出，然后点击‘OK’按 钮，但是文件没有保存” • ● 错误时什么：如果错误消息出现时，拷贝粘贴整个信息，这样更有利于我 们跟踪错误。 • 差：“有个错误，点击它始终读不出” • 好：“Error 403：访问拒绝” • ● 复现的步骤：如果你可以让bug重现，那太好了，这能提供很大的帮助。 一步步描述如何重现次bug。 • 差：“打印没法使用” • 好：“从‘Honors Report’页面，点击‘打印按钮’”
一个缺陷的基本要素
缺陷ID 缺陷标题 测试环境 缺陷发现的日期和时间 缺陷提交人 缺陷陷复现步骤 期望结果 实际结果 附件
例子-excel表
例子-bugfree
如何写好每部分（1）
• 标题：创建一个简短的标题，让问题看起来更清晰。“应用崩溃”是一个很 恼人的标题因为它没有足够的信息包括在这份报告里面。取而代之的是标题 应该包含错误消息和消息码，或者是结果的名称以及失败时你正在做的事情。 例如：Error 402:访问拒绝当点击“发送邮件”这个例子就提供了缺陷系统的 上下文信息。
者如果错误抛出，抛出什么错。 • 差：“没法用” • 好：“我收到是空的PDF文件，或者’403错误，访问拒绝’”
• • ● 附件：如果你知道怎么截屏，做吧，附上一个简短的错误，截屏可
以是错误之前或者发生错误之后，我们的开发者能够看到究竟发生了 什么。如果应用有崩溃的日志，同样附上它。
Chapter 3 测试报告
•
严格把控质量关，让生产更加有保障 。2020 年11月 上午12 时31分2 0.11.70 0:31November 7, 2020
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
缺陷描述
影响程度 后续解决措施
当前规避方法
•
弄虚作假要不得，踏实肯干第一名。0 0:31:31 00:31:3 100:31 11/7/20 20 12:31:31 AM
•
安全象只弓，不拉它就松，要想保安 全，常 把弓弦 绷。20. 11.700: 31:3100 :31Nov -207-Nov-20
•
重于泰山，轻于鸿毛。00:31:3100:31:3 100:31 Saturda y, November 07, 2020
区。
测试总结
• 回顾整个项目的测试过程，总结个人成长经验，取得了什 么成绩、有哪些不足、有什么好的经验或者方法可以和大 家分享呢？对工作进行一个理性的分析和思考。
问答
培训总结
•
加强做责任心，责任到人，责任到位 才是长 久的发 展。20. 11.720. 11.7Sat urday, November 07, 2020
器名称版本。特别是web应用，这些信息对我们很重要。 • 差：“Windows” • 好：“Windows7,IE9” • 是否能重现：有些恼火的Bug是间歇性的出现，我们想预先知道，如果我们
正在处理一个灵异事件或者正逢Bug出现时。 • 差：留空白 • 好：“每次”，“偶然”，“不重现”
如何写好每部分（2）
• ● 总结：用简洁的语言概括出Bug出现时你正在做的事情。从上下文开始， 在操作应用的哪个部分。聚焦在你做的时候软件做了什么？
• 差：“系统不能用了” • 好：在“honor report”页面单击“打印按钮”，但是报表是空的。 • ● 发生了什么：一步一步描述你做的事情当bug出现时，为什么你认为是错
• 差：“程序崩溃”，“报错”，“Bug” • 好：“从’Kifu’中打印时5C79错误”，“’Kifu honors’报表为空” • 产品：用名称标识产品，告知你使用的是哪个版本。绝大部分软件都包含有
版本信息。web应用的版本信息通常在页脚。 • 差：“你的应用” • 好：”Kifu v1.01″ • 平台：告诉我们软件运行在什么平台。尤其是操作系统的名字及版本和游览
评估人员 XX 审核人员 XXX
测试结果分析
•
测试执行结束后，测试活动还没有结束。测试结果分析是必不可
少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一
轮测试工作的开展有很大的借鉴意义。
•
因为通过对问题单的分析、总结不仅能发现不同人提交问题的
类别与差异，还能发现自身思维的局限性，避免下轮测试进入自我盲
如何写好每部分（3）
• ● 预期结果：描述你预期发生的结果当bug发生时，这部分特别有用 如果程序没有按照你期待的结果发生时，因为它很诡异。
• 差：“我期待能正常工作” • 好：“我期待能看到‘Honors Reports’的PDF文件” • 真实结果：当bug发生时是怎么发生的，什么错误，为什么有错，或
2.
性能评估
性能主要体现在：
1.本地阅读设置方面，设置后本地阅读界面都能正常显示；
2.Txt格式图书章节提取，是否精确；
3.下载管理重实现，在线小说的下载，多任务的下载是否顺畅；
4.在线阅读，连续阅读是否顺畅；
5.Wifi和GPRS网络连接下，客户端的使用是否顺畅；
3.
稳定性评估
软件各基本功能稳定
4.
测试风险
暂停的问题：
1、 出现概率比较低，用户操作不易复现的问题，后续由客户端修改； 2、3是本地阅读定位问题，修改比较困难，不影响使用，后续优化； 5、属于遗留问题； 4、6、7属于内容平台问题，内容优化；
暂停问题是产品人员、开发人员与测试人员沟通后暂停的。
测试对象评估
1.
基本功能评估
5.4版本在本地阅读txt格式章节提取、在线阅读预加载、下载管理重实现、用户反馈功能实 现、图书内容分享、网络连接、UI上做了一些修改、优化、调整，增加了一些新功能，本地 阅读、在线阅读等基本功能改动不大，且都已实现稳定。
易用性评估
易用性较5.3版本好，在功能和界面上做了很多优化
5.
其他评估
功能上简单易用，界面友好悦目，功能上在txt格式章节提取、下载速度上做了很大优化
测试结论
1.版本功能基本实现且运行稳定，问题修改及时，在预定日期内完成开发和测试进度
质量评价 测试结论
通过，可以发布及系统上线
□通过，可以发布及系统上线 □不通过，需要进行重大修改更新版本重新测试
2--一般 1--轻微
软件在某些情况下会出错，但是造成的后果影响不大 在某些情况下会出错，但是造成的后果影响很小
缺陷单的编写
• 一个好的缺陷单，是你提交之后就再也没人联系你，然后过了一段时间 已经被完美地修复，转回到你手上进行验证测试这样的一个单子