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