微软校园之星物流管理系统测试计划.docx

微软校园之星物流管理系统测试计划.docx

《微软校园之星物流管理系统测试计划.docx》由会员分享，可在线阅读，更多相关《微软校园之星物流管理系统测试计划.docx（7页珍藏版）》请在冰豆网上搜索。

微软校园之星物流管理系统测试计划

微软“校园之星”物流管理系统

测试计划

参赛院校：

贵阳学院

文档编写：

贵阳学院Netsln小组

小组成员：

段相勇，何书昌，高雪冬

指导老师：

张牧

2009年9月14日

1引言

1.1编写目的

为了检测软件设计和编码过程中实现是否能满足需求的规定，是否能达到预期的要求，查找系统存在的漏洞和不足，从而编写了此测试计划。

使用此文档的人为：

最终用户：

用来核实是否推荐使用了适当的测试策略，反映出系统或应用程序按照预定的用途进行应用。

系统集成员和实施员：

用来核实测试需求和测试策略是否与实施及开发计划一致。

测试设计员：

作为对测试设计活动的输入。

软件测试员：

以此作为测试指南

1.2背景

1.2.1测试系统的名称

物流管理系统

1.2.2项目历史和前期工作

该项目为第三届ATA-微软“校园之星”大赛复赛任务第一个版本，作第一次测试和查错，编写此文档前，项目已经完成需求分析和系统设计。

1.3定义

1.4参考资料

ATA-微软“校园之星”大赛复赛任务书

XX百科

MSDN帮助文档

CSDN博文

2计划

2.1软件说明

2.1.1主参与者：

运输管理员

场景：

1、运输管理员输入车队信息

2、运输管理员提交车队信息

其他场景：

如果车队编号已存在，系统提示车队编号已存在用

3、运输管理员查询车队信息列表，选择需要更新的具体车队信息4、运输管理员修改车队信息，提交更新信息

其他场景：

如果车队编号已存在，系统提示车队编号已存在

5、运输管理员输入查询条件

6、运输管理员查询车队信息

7、运输管理员选择要删除的车队信息，删除车队信息

8、运输管理员输入车辆信息

9、运输管理员提交车辆信息

其他场景：

如果车牌号码已存在，系统提示车牌号码已存在用10、运输管理员查询车辆信息列表，选择需要更新的具体车辆信息

11、运输管理员修改车辆信息，提交更新信息

其他场景：

如果车牌号码已存在，系统提示车牌号码已存在

12、运输管理员输入查询条件

13、运输管理员查询车辆信息

14、运输管理员选择要删除的车辆信息，删除车辆信息

15、运输管理员输入驾驶员信息

16、运输管理员提交驾驶员信息

17、运输管理员查询驾驶员信息

18、运输管理员修改驾驶员信息，提交驾驶员信息。

19、运输管理员输入查询条件

20、运输管理员查询驾驶员信息

21、运输管理员选择要删除的驾驶员，删除驾驶员。

其它场景：

如果驾驶员目前尚有承运任务，则不能删除。

2.1.2主参与者：

调度员/承运业务员

场景：

1、调度员/承运业务员输入查询条件查询承运车队

2、调度员/承运业务员查询承运车队

3、调度员/承运业务员选择车队查询承运车辆

4、调度员/承运业务员查询输入查询条件

5、调度员/承运业务员查询历史承运单任务。

2.1.3主参与者：

承运业务员

场景：

1、承运业务员填写初始信息

2、承运业务员填写承运单详细信息，提交承运单信息

3、承运业务员输入查询条件

4、承运业务员查询承运单信息

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连接速度测试

测试目标：

系统TPS达到40。

测试方法：

1.选择系统某个重要业务作为一个事务；

2.基准测试，记录处理完一个事务需要的时间;测试三次记录每次花费时间，最后计算平均时间；

3.测试处理5个事务花费的时间；（目标：

125ms）

……….

测试处理40个事务花费的时间。

最后将测试结果和目标分解结果比较，检验是否达到要求。

2.2.2.2负载测试

并发测试

测试目标：

50个用户同时登录系统，测试能否全部成功登录。

测试方法：

1.1个用户登录系统，测试是否成功登录，若成功，则下一步

2.2个用户同时登录系统，测试是否全部成功登录，若成功，下一步

3.3个用户同时登录系统，测试是否全部成功登录，若成功，则下一步

…

50个用户同时登录系统，测试是否全部成功登录。

若有不成功登录的，则中止测试。

稳定性测试

测试目标：

登录本系统，持续业务（用户的新增－查询－修改－删除）处理8小时，系统是否出现异常。

测试方法：

登录系统，依照新增－查询－修改－删除流程，每隔5分钟对用户信息进行一个流程处理，持续运行1小时，若有异常，则中止；若运行正常，同样方法继续2小时，…同样方法持续运行8小时，测试系统是否稳定。

压力测试

测试目标：

10000个用户同时登录系统，测试能否全部成功登录。

测试方法：

1.1个用户登录系统，测试是否成功登录，若成功，则下一步

2.500个用户同时登录系统，测试是否全部成功登录，若成功，则下一步

3.1000个用户同时登录系统，测试是否全部成功登录，若成功，则下一步

…

10000个用户同时登录系统，测试是否全部成功登录。

若有不成功登录的，则中止测试。

2.2.2.3兼容性测试

测试方法：

分别用IE6.0及其以上版本和NetscapeNavigator6.0及其以上版本浏览系统，分别观察其显视是否正常，脚本是否出错

2.2.2.4日志文件

测试方法：

在后台，要注意验证服务器日志工作正常。

日志是否记所有的事务处理?

是否在每次事务完成的时候都进行保存?

记录IP地址吗?

记录用户名吗?

3测试设计说明

3.1测试说明

3.1.1控制

本测试80%是人工测试，20%是软件测试，测试前重新启动IIS

清空应用程序池。

2009-9-14