电商平台测试报告实例资料.pdf

上传人:白大夫 文档编号:5437115 上传时间:2020-05-11 格式:PDF 页数:12 大小:643.05KB
返回 下载 相关 举报
电商平台测试报告实例资料.pdf_第1页
第1页 / 共12页
电商平台测试报告实例资料.pdf_第2页
第2页 / 共12页
电商平台测试报告实例资料.pdf_第3页
第3页 / 共12页
电商平台测试报告实例资料.pdf_第4页
第4页 / 共12页
电商平台测试报告实例资料.pdf_第5页
第5页 / 共12页
点击查看更多>>
资源描述

《电商平台测试报告实例资料.pdf》由会员分享,可在线阅读,更多相关《电商平台测试报告实例资料.pdf(12页珍藏版)》请在三一文库上搜索。

1、产品名称密级 * 机密 产品版本 共10 页 FMS 客服管理系统测试报告 拟制 * 日期 2015-05-26 审核日期 批准日期 深圳市 * 电子商务有限公司 版权所有侵权必究 (供内部使用) *测试报告机密 * 机密,未经许可不得扩散第2页,共 12页 修订记录 日期修订版本CR 号修改章节修改描述作者 2015-05-26 1.00 初稿完成* *测试报告机密 * 机密,未经许可不得扩散第3页,共 12页 目 录 1概述 5 1.1被测对象概述 5 1.2测试方案概述 5 2测试时间、地点及人员. 6 3环境描述 . 7 4测试覆盖分析 8 4.1测试覆盖分析 8 4.2缺陷统计与分析

2、 8 4.2.1缺陷统计 . 8 4.2.2缺陷分析 . 10 5测试总结和建议 10 5.1软件质量评估 11 5.2软件风险 . 11 5.3测试结论 . 11 5.4测试建议 . 11 6测试过程评估 12 6.1测试设计评估 12 6.2测试执行评估 12 6.2.1其他风险和规避措施. 12 6.2.2测试维度分析 12 6.3交付的测试工作产品. 12 *测试报告机密 * 机密,未经许可不得扩散第4页,共 12页 FMS 客服管理系统测试报告 关键词: 客户 通过 * 商城进行商品购买并享受购物服务的人。一般一个人对应着一个系统中的一个帐户 用户 通过系统进行业务运营的人,具有一定

3、的角色和权限 销售单号 前台下单后生成的订单号 部分出库 一般指销售单状态,如下的订单有N 件,只发了一部分,未发齐全 供应商 提供产品的商家 预付款添加 即采购时给供应商的定金 摘要: 本规范对 FMS 财务管理系统的财务应收、财务应付、付款申请管理,发票结算单管理、财务 单管理、财务系统工具等进行系统测试方案设计。 缩略语清单: 缩略语英文全名中文解释 CBD Component-Based Development 基于组件开发 MVC Model-View-Controller 模式 -视图 -控制器 RUP Rational Unified Process Rational 统一过程

4、OO Object Oriented 面向对象 SOA Service-Oriented Architecture 面向服务架构 SP Service Provider 服务提供商 UMAP Universal Management Application Platform 统一管理应用平台 USEE Unified Service Execution Environment 统一服务执行环境 *测试报告机密 * 机密,未经许可不得扩散第5页,共 12页 1 概述 1.1 被测对象概述 FMS 为财务管理系统,其目的就是管理支付这一块,所有涉及到资金流动的情况。它包括了6个子 模块,分别是财务

5、应收、财务应付、付款申请管理,发票结算单管理、财务单管理、财务系统工具。部 分主要功能如下描述。 预付款查询,主要功能为在线支付的支付方式做收款验证的,默认是由支付成功后系统自动产生验 证数据,也可以手动添加验证数据。可以查询相关支付验证信息。高级搜索包括销售单系统编号、状 态、支付方式、创建时间区间。查询结果包括销售编号、支付方式、支付金额、来源、审核信息、创建 信息。 应付款查询,主要功能为应付款信息查询和查询结果导出到EXCEL 。高级搜索包括采购单号、采 购状态、采购创建时间区间、采购单入库时间区间、付款时间区间、货币、供应商、采购人、支付状 态、发票状态、带票类型、是否需要催票、PM

6、 。查询结果包括采购单号、创建信息、入库信息、采购 金额、已付金额、付款时间、供应商、采购单状态、支付状态、打印、催票、PM。发票状态更新包含 发票状态、发票签收时间、备注 付款单管理,主要功能为付款单维护。包括新增付款单、申请付款单、作废付款单、修改付款单、 支付付款单。快捷查询包含所有付款单、待审核、待支付、已支付。采购人查询按照个人已经所有采购 人分类查询。高级搜索包括采购单号、采购人、供应商、支付类型、状态、凭证号、帐期付款时间区 间、创建时间区间、预计支付时间区间、审核时间区间、申请时间区间、凭证时间区间、备注、供应商 名称、排序方式、付款单编号、是否带赠票。查询结果包括采购单号、供

7、应商、支付金额、支付类型、 创建信息、申请信息、审核信息、预计支付信息、实际支付信息。 收款单管理,主要功能为收款单查询和修改以及生成EXCEL 。快捷查询包含所有收款单、默认、 今日收款单、所有待确认、今日已确认。财务凭证包括凭证号和凭证时间更新选中收款单的凭证号和凭 证时间。高级搜索包含单证号、单证类型、单证日期、设置配送日期、确认日期、凭证日期、收入类 型、收入状态、支付方式、配送人、凭证号、销售单状态、配送结算单号。查询结果包括系统编号、销 售单状态、收入类型、单证号、单证类型、单证金额、收入金额、收入信息、确认信息、收入状态、凭 证号、凭证时间、支付交易号、配送方式、支付方式。 1.

8、2测试方案概述 本测试方案主要针对FMS 系统的功能测试,对FMS 每一个不同的功能,结合其实际逻辑,详细 测试其内部功能,准备正常和异常数据,同时考虑到与其他系统集成的地方,以此保证功能的完 整性、正确性。 *测试报告机密 * 机密,未经许可不得扩散第6页,共 12页 2 测试时间、地点及人员 版本名 称 版本类别测试时间测试人员 测试地点 配套测试的配套版 本 起始时间结束时间产品名 称与版 本号 版本说 明 V1.0 测试版04-21 05-26 *重庆研发 中心 *测试报告机密 * 机密,未经许可不得扩散第7页,共 12页 3 环境描述 硬件列表详细配置说明备注 HP C7000 刀笼

9、 Dell R720 双路 E5CPU ,128G内 存, 300G*2+600G*10硬盘, RAID 卡,双电,远程控制卡,千兆网 卡 cisco WS-C2960S-48TS-L 千兆 交换机 Dell R720 双路E5CPU,128G内存, 300G*2+600G*10硬盘, RAID 卡,双电,远程控制 卡,千兆网卡 千兆交换机 cisco WS-C2960S-48TS-L *测试报告机密 * 机密,未经许可不得扩散第8页,共 12页 4 测试覆盖分析 4.1 测试覆盖分析 测试覆盖根据经过测试的测试用例和设计测试用例的比值,通过这个指标获得测试情况的数据。 需求 /功能数测试用例

10、数执行数未执行数通过数失败数备注 48 146 122 0 96 4阻塞状态 22 个 测试覆盖率 =执行数 /用例总数 100=83.56% 测试通过率 =通过数 /执行数 100=78.69% 4.2 缺陷统计与分析 对测试过程中产生的缺陷进行统计和分析。 4.2.1 缺陷统计 1. Bug严重程度统计 所属环境 () A类B类C类D类 概况 1 6 25 3 已关闭 1 6 25 1 未关闭 0 0 0 2 *测试报告机密 * 机密,未经许可不得扩散第9页,共 12页 2. Bug状态统计 版本类别已关闭已解决激活 2582 3. Bug解决方案 版本类别外部原因设计如此重复 bug延期

11、处理不予解决无法重现 已解决 150001 26 *测试报告机密 * 机密,未经许可不得扩散第10页,共 12页 4.2.2 缺陷分析 根据测试发现的问题,bug 集中的模块,可以发现缺陷前中期发现的bug数量最多,后后期 明显的收敛趋势,缺陷逐渐减少。 5 测试总结和建议 *测试报告机密 * 机密,未经许可不得扩散第11页,共 12页 5.1 软件质量评估 1. 质量评价结果 经过 3轮系统测试、回归测试,软件质量呈有效收敛趋势。 2. 资料评估 目前 FMS财务管理系统的实现逻辑还存在着争议,未完全确定下来。所以后期在逻辑和功能模块方 面都是需要完善的。就现目前阶段的FMS系统所实现的功能

12、,基本可以达到目标。后期如有大改动, bug数量又会有递增和递减的一个波动。 3. 质量评估 FMS系统已经开发的功能,实现情况基本通过。 4. 兼容性评估 浏览器名称测试版本测试结果测试版本测试结果测试版本测试结果 Chrome 最近版本PASS 5.2 软件风险 FMS系统的产品需求,并没有很确定。后期可能有大改动。而且新一轮发布无法保证上次修复的 bug不会重现。所以在迭代更新的过程中,需要在每次上线前都进行一次完整的测试。 5.3 测试结论 通过 3轮的功能测试,共计发现35 bug 并且待修复 bug为2。确定所有功能符合需求设计要求, 功能正确无误,开发和测试相关文档齐全。 第一轮

13、测试:7个BUG; 第二轮测试:19个BUG; 第三轮测试:9个BUG 。 5.4 测试建议 新一轮发布无法保证上次修复的bug不会重现。所以在迭代更新的过程中,需要在每次上线前 都进行一次完整的测试。 1. 每次新功能在开发完成前,将新功能的需求分析及时的同步到测试部门,这样就有充足的 时间罗列测试点。 2. 根据缺陷的优先级,由重到轻,合理分配。 3. 根据缺陷的提出时间,进行合理修复安排。 4. 测试介入时间可以从需求分析阶段就开始,这样中间过程文档才会更清晰、更完善。 5. 可以引入自动化测试,每次上线前跑自动化脚本即可,减少了很大工作量。 6. 开发人员的更新或修改,及时反馈测试人员。 *测试报告机密 * 机密,未经许可不得扩散第12页,共 12页 7. 功能需求可以对开发和测试人员都进行一次总得框架培训。 6 测试过程评估 6.1 测试设计评估 本测试报告针对系统功能性测试和兼容性测试,性能测试不在此报告中。 6.2 测试执行评估 本系统共进行3轮系统测试,3轮回归测试,缺陷有明显的收敛趋势,严重的缺陷全部修复并 通告验证。 6.2.1 其他风险和规避措施 无 6.2.2 测试维度分析 无 6.3 交付的测试工作产品 1. 测试方案 2. 测试用例 3. 测试报告

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 其他


经营许可证编号:宁ICP备18001539号-1