订餐系统软件测试总结报告分析.doc

订餐系统测试总结报告文档标识：无当前版本：001当前状态：草稿发布日期：2013.12.28发布修改历史日期版本作者修改内容评审号变更控制号目 录1.测试概述31.1编写目的31.2测试范围31.3参考资料32.测试计划执行情况32.1 测试类型32.2 进度偏差42.3测试环境与配置42.4测试机构和人员52.5 测试问题总结53.测试总结53.1测试用例执行结果53.2测试问题解决73.3测试结果分析73.3.1覆盖分析73.3.2缺陷分析84.综合评价94.1 软件能力94.3 建议91. 测试概述1.1 编写目的对订餐系统项目中所有的软件测试活动中，包括测试进度、资源、问题、风险以及测试组和其他组间的协调等进行评估，总结测试活动的成功经验与不足，以便今后更好的开展测试工作。本系统测试总结报告的预期读者是： 项目组小组成员 测试组人员 指导教师1.2 测试范围测试组主要依据需求与设计说明书，对订餐系统进行功能测试。主要功能包括：前台1.登录 后台1.审查注册用户2. 注册2.菜单管理3. 我的餐车3.今日菜单发布4. 我的订餐4.今日订单管理5. 留言板5.留言板的后台管理6. 用户中心1.3 参考资料资料名称版本作者是否经过评审备注订餐系统-需求规格说明书-订餐系统-数据库设计说明书-订餐系统-测试计划1.0是订餐系统-测试用例-是2. 测试计划执行情况 2.1 测试类型测试类型测 试 内 容测 试 目 的所用的测试工具和方法功能测试登录 注册 餐车 订餐留言板 用户中心审查注册用户 菜单管理 菜单发布 订餐管理 留言板后台管理核实所有功能均已正常实现，即可按每个用户的需求选择内容，完成操作。采用黑盒测试，使用边界值测试、等价类划分、数据驱动等测试方法，进行手工测试；2.2 进度偏差测试活动计划起止日期实际起止日期进度偏差备注制定测试计划2013.11.232013.11.232013.11.23-2013.11.252天无测试计划评审2013.12.12013.12.1无无分解测试需求2013.12.42013.12.4无无测试需求Review-选定测试范围2013.11.232013.11.23无无编写测试方案2013.12.72013.12.7无无测试方案评审2013.12.72013.12.15一周因为上课进度和安排设计测试用例2013.12.72013.12.15一周测试用例评审2013.12.212013.12.21无测试结果迟交一0天测试执行2013.12.152013.12.15无测试移交延迟一0天测试总结2013.12.152013.12.2813天因为上课进度2.3测试环境与配置资源名称/类型配 置测试PC机（1台）DELL，硬盘300G，内存2G。数据库管理系统SQL Server应用软件Tomcat客户端前端展示搜狗2.4测试机构和人员测试阶段测试机构名称负责人参与人员所充当角色系统测试测试组邓测试人员2.5 测试问题总结在整个系统测试执行期间，项目组开发人员高效地及时解决测试组人员提出的各种缺陷，在一定程度上较好地保证了测试执行的效率以及测试最终期限。但是在整个软件测试活动中还是暴露了一些问题，表现在：1 测试执行时间相对较少，测试通过标准要求较低；2 开发人员相关培训未做到位，编码风格各异，细节性错误较多，返工现象存在较多；3 测试执行人员对管理平台不够熟悉，使用时效率偏低；4 测试执行人员对系统了解不透彻，测试执行时存在理解偏差，导致提交无效缺陷；3. 测试总结3.1 测试用例执行结果测试用例标识号测试用例名称用例状态测试结果备注前台功能Bug1-001用户登录已执行测试通过Bug2-002用户注册已执行测试通过Bug3-003餐车已执行测试通过Bug4-004订餐已执行测试通过Bug6-006用户中心已执行测试通过能够完成相关的功能Bug5-005留言板已执行测试通过后台功能Bug7-007审查注册用户已执行测试通过Bug8-008菜单管理已执行测试通过Bug9-009菜单发布已执行测试通过Bug10-010今日订单管理已执行测试通过Bug11-011留言板的后台管理已执行测试通过具备基本的后台管理功能.下表中描述测试中发现的、没有满足需求或其它方面要求的部分。 测试用例标识号测试用例名称错误或问题描述错误或问题状态Bug-006用户中心用户中心：点击【提交】没有弹出“提示”；未解决Bug3-003我的餐车在【我的餐车】中，无法看到已顶的订单未解决Bug6-006用户中心模块，其他模块当我们修该信息或添加信息的时候提示对话框切换到了没有背景的新页面未解决Bug-005l 留言板弹出相应的删除确认框，无法点击取消删除操作未解决.lBug-001l 登陆模块没有弹出警告提示，可以重复登录未解决Bug11-011l 后台留言板如果有多条回复，最新一次的回复内容会覆盖以前的回复，只会显示一条回复未解决.l3.2 测试结果分析3.2.1 覆盖分析3.2.1.1. 测试覆盖分析测试覆盖率11/11 100=100需求/功能用例个数执行总数未执行未/漏测分析和原因注册110登录110产生失败数0个餐车110产生失败数0个订餐110留言板110产生失败数0个用户中心110审查注册用户110产生失败数0个菜单管理110产生失败数0个订单管理110产生失败数0个今日菜单110留言板后台1103.2.1.2. 需求覆盖分析本次测试对系统需求的覆盖情况为：需求覆盖率Y（P）项/需求项总数 100 11/ 11 100 = 100%;注：P表示部分通过，N/A表示不可测试或者用例不适用。3.2.2 缺陷分析按缺陷在各功能点的分布情况分： 严重级别需求A-严重影响系统运行的错误B-功能方面一般缺陷，影响系统运行C-不影响运行但必须修改D-合理化建议注册用户 0 000登陆用户00011餐车管理使用00011订餐00011留言板011用户中心的管理00022审查注册用户00000菜单管理00000订单管理00000今日菜单管理00000留言板后台00011774. 综合评价4.1 软件能力经过对订餐系统的简单的功能测试，我们发现了系统在功能方面还存在很多问题，整体流程还不能够很好的进行。订餐和预览以及信息管理还存在一些问题。但功能相对较为完整，可以简单投入使用，再次进行大众测试。4.2 缺陷和限制经过对订餐系统的简单的功能测试，我们发现虽然对功能有了基本的测试之后，也发现了基本功能都属于正常的，可是还是有许多细节的问题需要完善而具体的上面的缺陷分析中已经有了更加细致的描述。4.3 建议需求提出方可以在使用该系统的基础上，继续搜集用户的使用需求反馈，并结合市场同类产品的优势，在今后的版本中不断补充并完善功能。另外，建议当测试组成员确定后，在测试组内部对一些事项进行约定。如WEB开发/测试的通用规范等，以及每一个成员必须完成的具体任务。这样将会在一定程度上提高开发和测试的效率。同时测试的时候我们不能够进行压力测试，所以建议，使用的前期应该进行一次压力测试。