《03微软“校园之星”物流管理系统测试计划12页word文档.doc》由会员分享，可在线阅读，更多相关《03微软“校园之星”物流管理系统测试计划12页word文档.doc（12页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、如有侵权，请联系网站删除，仅供学习与交流03微软“校园之星”物流管理系统测试计划【精品文档】第 12 页微软“校园之星”物流管理系统测试计划参赛院校：贵阳学院文档编写：贵阳学院Netsln小组小组成员：段相勇，何书昌，高雪冬指导老师：张 牧2009年9月14日目录1引言31.1编写目的31.2背景31.2.1测试系统的名称31.2.2项目历史和前期工作31.3定义41.4参考资料42计划52.1软件说明52.1.1主参与者：运输管理员52.1.2主参与者：调度员/承运业务员62.1.3主参与者：承运业务员62.1.4主参与者：财务人员72.2测试内容82.2.1功能测试82.2.2性能测试82
2、.2.2.1 连接速度测试82.2.2.2负载测试82.2.2.3兼容性测试102.2.2.4 日志文件103测试设计说明113.1测试说明113.1.1控制111引言1.1编写目的为了检测软件设计和编码过程中实现是否能满足需求的规定，是否能达到预期的要求，查找系统存在的漏洞和不足，从而编写了此测试计划。使用此文档的人为：最终用户：用来核实是否推荐使用了适当的测试策略，反映出系统或应用程序按照预定的用途进行应用。 系统集成员和实施员：用来核实测试需求和测试策略是否与实施及开发计划一致。 测试设计员：作为对测试设计活动的输入。软件测试员：以此作为测试指南1.2背景1.2.1测试系统的名称物流管理
3、系统1.2.2项目历史和前期工作该项目为第三届ATA-微软“校园之星”大赛复赛任务第一个版本，作第一次测试和查错，编写此文档前，项目已经完成需求分析和系统设计。1.3定义1.4参考资料ATA-微软“校园之星”大赛复赛任务书百度百科 MSDN帮助文档CSDN博文2计划2.1软件说明2.1.1主参与者：运输管理员场景： 1、运输管理员输入车队信息 2、运输管理员提交车队信息 其他场景： 如果车队编号已存在，系统提示车队编号已存在 用3、运输管理员查询车队信息列表，选择需要更新的具体车队信息 4、运输管理员修改车队信息，提交更新信息 其他场景： 如果车队编号已存在，系统提示车队编号已存在5、运输管理
4、员输入查询条件 6、运输管理员查询车队信息 7、运输管理员选择要删除的车队信息，删除车队信息 8、运输管理员输入车辆信息 9、运输管理员提交车辆信息 其他场景： 如果车牌号码已存在，系统提示车牌号码已存在 用10、运输管理员查询车辆信息列表，选择需要更新的具体车辆信息 11、运输管理员修改车辆信息，提交更新信息 其他场景： 如果车牌号码已存在，系统提示车牌号码已存在12、运输管理员输入查询条件 13、运输管理员查询车辆信息 14、运输管理员选择要删除的车辆信息，删除车辆信息15、运输管理员输入驾驶员信息16、运输管理员提交驾驶员信息17、运输管理员查询驾驶员信息 18、运输管理员修改驾驶员信息
5、，提交驾驶员信息。19、运输管理员输入查询条件 20、运输管理员查询驾驶员信息 21、运输管理员选择要删除的驾驶员，删除驾驶员。 其它场景： 如果驾驶员目前尚有承运任务，则不能删除。2.1.2主参与者：调度员/承运业务员场景： 1、调度员/承运业务员输入查询条件查询承运车队 2、调度员/承运业务员查询承运车队 3、调度员/承运业务员选择车队查询承运车辆4、调度员/承运业务员查询输入查询条件 5、调度员/承运业务员查询历史承运单任务。2.1.3主参与者：承运业务员 场景： 1、承运业务员填写初始信息 2、承运业务员填写承运单详细信息，提交承运单信息 3、承运业务员输入查询条件 4、承运业务员查询
6、承运单信息 5、承运业务员查询承运单信息 6、承运业务员修改承运单信息，提交承运单信息 7、承运业务员选择要删除的承运单，删除承运单8、承运业务员输入客户信息 9、承运业务员查看未接收承运单列表 10、承运业务员接收承运单2.1.4主参与者：财务人员场景： 1、财务人员输入成本信息 2、财务人员提交成本信息 3、财务人员输入查询条件 4、财务人员查询承运任务 5、财务人员查询承运任务 6、财务人员修改成本信息，提交成本信息 7、财务人员选择查询条件 8、财务人员核算运输成本2.2测试内容2.2.1功能测试测试软件说明中的每一个场景2.2.2性能测试2.2.2.1 连接速度测试 测试目标： 系统
7、 TPS达到 40。 测试方法： 1. 选择系统某个重要业务作为一个事务； 2. 基准测试，记录处理完一个事务需要的时间 ; 测试三次记录每次花费时间，最后计算平均时间； 3. 测试处理 5个事务花费的时间；（目标： 125ms ） 测试处理 40个事务花费的时间。 最后将测试结果和目标分解结果比较，检验是否达到要求。 2.2.2.2负载测试 并发测试 测试目标： 50个用户同时登录系统，测试能否全部成功登录。 测试方法： 1. 1个用户登录系统，测试是否成功登录，若成功，则下一步2.2个用户同时登录系统，测试是否全部成功登录，若成功，下一步 3.3个用户同时登录系统，测试是否全部成功登录，若
8、成功，则下一步50个用户同时登录系统，测试是否全部成功登录。若有不成功登录的，则中止测试。 稳定性测试 测试目标： 登录本系统，持续业务（ 用户的新增查询修改删除 ）处理 8小时，系统是否出现异常。 测试方法： 登录系统，依照 新增查询修改删除流程，每隔 5 分钟对用户信息进行一个流程处理，持续运行 1 小时，若有异常，则中止；若运行正常，同样方法继续 2 小时， 同样方法持续运行 8 小时，测试系统是否稳定。 压力测试 测试目标： 10000个用户同时登录系统，测试能否全部成功登录。 测试方法： 1.1个用户登录系统，测试是否成功登录，若成功，则下一步2.500个用户同时登录系统，测试是否全
9、部成功登录，若成功，则下一步 3.1000个用户同时登录系统，测试是否全部成功登录，若成功，则下一步10000个用户同时登录系统，测试是否全部成功登录。若有不成功登录的，则中止测试。2.2.2.3兼容性测试测试方法：分别用IE6.0及其以上版本和Netscape Navigator 6.0及其以上版本浏览系统，分别观察其显视是否正常，脚本是否出错2.2.2.4 日志文件 测试方法： 在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理 ? 是否在每次事务完成的时候都进行保存 ? 记录 IP 地址吗 ? 记录用户名吗 ? 3测试设计说明3.1测试说明3.1.1控制本测试80%是人工测试，20%是软件测试，测试前重新启动IIS清空应用程序池。2009-9-14