样例公交车车辆管理系统测试计划.docx
《样例公交车车辆管理系统测试计划.docx》由会员分享，可在线阅读，更多相关《样例公交车车辆管理系统测试计划.docx（26页珍藏版）》请在冰豆网上搜索。
样例公交车车辆管理系统测试计划
公交车车辆管理系统
测试计划
学院：
经济管理学院
专业：
信息管理与信息系统
学生姓名：
白宸溪
学号：
111235
班级：
信111
一、系统概述：
3
二、需求分析：
3
三、测试目的：
4
四、参考文档：
4
五、测试项：
4
（一）、测试范围：
4
（二）、风险分析：
4
六、测试方法：
5
（一）、测试流程：
5
（二）、测试要求：
5
（三）、测试用例设计：
7
1、注册模块：
7
2、登录模块9
3、车辆基本信息管理模块11
4、站点基本信息管理模块：
18
5、驾驶人基本信息管理模块：
22
（四）、测试开始条件和结束条件：
28
七、测试组织：
28
（一）、测试团队结构：
28
（二）、功能划分：
28
（三）、联系方式：
29
八、测试环境及进度：
29
（一）、测试环境：
29
（二）、测试进度：
29
（三）、测试环境:
29
九、测试提交物：
30
十、测试计划的审批和变更方式：
30
（一）、测试计划的审批30
（二）、测试计划的变更方式：
30
一、系统概述：
随着城市经济建设的飞速发展，城市规模的不断扩大，公交车数量急剧增加，城市交通问题日益严重。
目前，已成为严重影响许多大中城市发展的重点问题之一。
考虑到，有关公交的各种信息量成倍增长，传统的人工记忆方式管理也慢慢的无法适应形势的变化。
城市公共交通具有客运量大，相对投资少，占有资源少，效率高，污染相对较少，人均占用道路少等优点（与小汽车比）。
所以大力优先发展公共交通，实现数字化、智能化城市交通管理，提高公共交通运营管理效率和社会服务水平，是适合中国国情的现代化大城市发展的必然要求。
使用现代化的智能交通（）技术改造传统的公交产业，以信息化带动现代化。
建设新型智能化、自动化的公交车车辆管理系统，把公交系统的管理，服务水平、工作质量提高到新的层次，从而提升城市交通信息化水平。
因此，伴随着信息技术的不断发展，通过运用计算机技术，推动公交产业不断发展，对公交车车辆实行相关的信息系统集成管理是势在必行的。
二、需求分析：
由于公交车的本身的特点：
线路固定、高峰时间拥挤等，公交车车辆管理系统在市区间或市区内的城域网中应用。
并且有关车辆的各种信息不能及时进行传输，影响车辆管理以及调度事务，减少出现“串车”、“大间隔”现象以及乘客滞留和空车的情况出现。
因此，本系统的设计目的主要用于解决上述问题。
本系统投入运行后，可以达到提高工作效率，减少车次延误等，最终提高工作效益，达到让乘客满意的效果。
本系统从以下几个方面对用户的需求进行分析：
（1）公交车车辆管理系统的需求分析：
随时查询公交车车辆车辆的位置，以及检查车辆的行驶线路、过路费信息、车辆信息、车辆提醒信息，以便及时准确、方便地为公交总部和各分区提供有效的信息，但不能随意修改数据,无信息处理权，即可以打印数据清单、浏览数据等，管理权限由系统管理员掌握和分配。
（2）对数据的安全性、可靠性要求：
公交车车辆各项数据信息必须保证安全性和可靠性。
网络系统设有通信、程序、网络三级权限和口令管理，确保系统整体安全。
（3）定时整理数据：
系统管理员根据车辆历史信息定时整理系统数据库，并将运行结果归档。
三、测试目的：
对于公交车车辆管理系统的相关功能进行确认，验证其功能是否完成需求，功能是否正确，数据计算是否正确等。
同时关注系统运行是否稳定。
四、参考文档：
《软件测试技术》，陈明编著，清华大学出版社
《高级软件测试技术》，杜庆峰编著，清华大学出版社
五、测试项：
（一）、测试范围：
本次测试包括公交车车辆管理系统的全部模块：
1.登录模块
2.注册模块
3.车辆基本信息管理模块
4.车辆站点基本信息管理模块
5.驾驶人基本信息管理模块
（二）、风险分析：
本次测试过程中，可能出现的风险如下：
（1）模块功能的实现情况可能达不到用户预期的效果，在测试的过程中应尽量使用户参与测试。
（2）的修复情况可能因人员不到位而不能及时修复，应与测试人员进行及时沟通。
（3）代码的编写质量可能不是特别高，以及测试人员的经验以及对软件的熟悉度会造成时间的延误，应根据项目组具体情况对测试的工期进行合理安排。
（4）在测试的过程中，有可能人员进行调整，导致研发周期延迟，应根据项目组具体情况对测试的工期进行合理安排。
六、测试方法：
本次测试主要采用手工黑盒测试方法，根据基础用例整理测试，执行全部可执行测试用例，跟据测试要求验证是否达到测试目的中所列内容。
（一）、测试流程：
步骤
动作
测试提交物
要求
1
测试准备
基础用例
描述需求
测试需求
整理需求
2
测试计划
测试方案
经过评审
3
环境测试部署
发布日志，测试入口
日志按时提交，环境可用.
4
测试设计
测试用例
5
测试实施
用例执行情况
6
测试报告
测试报告
经过评审
（二）、测试要求：
第一阶段
整体界面效果检测
1、进入公交车车辆管理系统，检查各模块的操作界面
2、查看各模块界面的整体布局。
具体到字体、字号、颜色等是否满足需求，以及整体的视觉效果。
各模块的界面均满足客户的要求，并且颜色、字体、字号布局得体。
第二阶段
各模块功能测试
1、检查各模块中操作按钮的功能是否可用，并检查功能是否与其名称对应。
2、检验各模块的功能是否能满足需求，有无缺失项或多余项。
3、检查各个属性文本框中的必填项是否齐备
4、检查查询结果数据的正确性
5、检查异常输入数据的提示功能是否齐备
6、其它
1、各模块中操作按钮的功能可用，并与其名称对应一致。
2、各模块中的功能能完全满足需求，操作按钮均可用且没有多余的项。
3、各个属性文本框中的必填项均用“*”标出。
4、查询结果数据均正确。
5、异常输入时，系统会自动弹出输入异常对话框。
第三阶段
系统稳定性及安全性测试
1、统计正常操作下，产生的错误率，并记录相应错误信息。
2、统计任意操作下产生的错误率，并记录相应错误信息。
3、检查系统有无登录超时的限制
4、安全性测试（如登录模块，密码有无限制等约束条件）
5、压力测试
1、正常操作下，系统不产生错误。
2、任意操作下，系统产生的错误相对较少。
3、若长时间不作任何操作，系统将提示登录超时，需重新登录才能使用该系统。
4、密码安全性较高，有大小写敏感变化。
5、压力测试结果良好，无不良反应。
（三）、测试用例设计：
1、注册模块：
模块名
注册模块
开发人员
版本号
用例作者
白宸溪
设计日期
测试类型
功能测试
测试方式
手工
序号
类型
操作说明
输入数据/步骤
期望输出
实际输出
结果
1
界面效果
观察注册模块界面的外观
1、进入公交车车辆管理系统注册模块的操作界面
2、观察注册模块的操作界面的位置摆放是否得体并美观；字体的大小和颜色是否一致、得当。
注册模块的操作界面的位置适中；界面内字体大小及颜色合适且美观。
2
功能
正例
输入用户姓名，身份证号，密码，选择用户类型
小明，
110，
1a2b3C，基层管理者
点击提交按钮后，提示注册成功
3
功能
反例
输入非汉字的用户名，身份证号码，密码，选择用户类型
1122，
1120022，
1a2b3C，基层管理者
点击提交后提示“用户名输入有误，请您填写您的真实姓名”
4
功能
反例
输入用户姓名，有误的身份证号码格式，密码，选择用户类型
小明,112002L,1a2b3C，基层管理者
点击提交后提示“身份证号码有误，请输入正确的身份证号码”
5
功能
反例
输入用户姓名，有误的身份证号码，密码，选择用户类型
小明,1120022,1111，基层管理者
点击提交后提示“请输入多于5位的密码”
6
功能
反例
输入用户姓名，有误的身份证号码，密码，选择用户类型
小明,1120022,1a2b3C
点击提交后提示“请您选择用户类型”
2、登录模块
模块名
登录模块
开发人员
版本号
用例作者
白宸溪
设计日期
测试类型
功能测试
测试方式
手工
序号
类型
测试说明
输入数据/步骤
期望输出
实际输出
结果
1
界面效果
观察登录模块界面的外观
1、进入公交车车辆管理系统登录模块的操作界面
2、观察登录模块的操作界面的位置摆放是否得体并美观；字体的大小和颜色是否一致、得当。
登录模块的操作界面的位置适中；界面内字体大小及颜色合适且美观。
2
功能
正例
输入用户姓名，密码，选择用户类型
小明，1a2b3C，基层管理者
进入公交车车辆管理系统主界面
3
功能
反例
输入未注册过的用户姓名，密码，选择用户类型
小王，1a2b3C，基层管理者
点击登录按钮后提示“该用户名还未被注册，请您先进行注册”
4
功能
反例
输入用户姓名，错误的密码，选择用户类型
小王，1a2b11，基层管理者
点击登录按钮后提示“您输入的密码有误，请您重新输入”
5
功能
反例
输入正确用户姓名，密码为空，选择用户类型
小王，，基层管理者
点击登录按钮后提示“您的密码不能为空，请您重新填写”
6
功能
反例
用户姓名为空，输入正确的密码，选择用户类型
，1a2b3C，基层管理者
点击登录按钮后提示“您的用户姓名不能为空，请您重新填写”
7
功能
反例
用户姓名为空，密码为空，选择用户类型
，，基层管理者
点击登录按钮后提示“请您输入用户名和密码”
8
功能
反例
用户姓名，密码，未选用户类型
小王，1a2b11，
点击登录按钮后提示“请您选择用户类型”
9
功能
反例
用户姓名为空，密码，未选用户类型
，1a2b11，
点击登录按钮后提示“请您填写用户姓名并选择用户类型”
10
功能
反例
用户姓名，密码为空，未选用户类型
小王，，
点击登录按钮后提示“请您输入密码并选择用户类型”
11
功能
反例
用户姓名为空，密码为空，未选用户类型
，，
点击登录按钮后提示“请您输入正确的信息”
3、车辆基本信息管理模块
模块名
车辆基本信息管理模块——修改车辆基本信息
开发人员
版本号
用例作者
白宸溪
设计日期
测试类型
功能测试
测试方式
手工
序号
类型
测试说明
输入数据/步骤
期望输出
实际输出
结果
1
界面效果
观察车辆基本信息修改界面的外观
1、进入公交车车辆管理系统车辆基本信息修改模块的操作界面
2、观察车辆基本信息修改模块的操作界面的位置摆放是否得体并美观；字体的大小和颜色是否一致、得当。
车辆基本信息修改模块的操作界面的位置适中；界面内字体大小及颜色合适且美观。
2
功能
正例
重新选择驾驶人员，设定其他条件均不能改变。
张三
点击提交按钮后提示“修改成功！
”
3
功能
正例
若对驾驶员不做任何修改
保持原数据不变
点击提交按钮后提示“您未进行任何修改，是否重新修改驾驶人员”，如果点击“是”则进入修改界面；如果点击“否”则退出修改界面
模块名
车辆基本信息管理模块——增加车辆基本信息
开发人员
版本号
用例作者
白宸溪
设计日期
测试类型
功能测试
测试方式
手工
序号
类型
测试说明
输入数据/步骤
期望输出
实际输出
结果
1
界面效果
观察车辆基本信息增加界面的外观
1、进入公交车车辆管理系统车辆基本信息增加模块的操作界面
2、观察车辆基本信息增加模块的操作界面的位置摆放是否得体并美观；字体的大小和颜色是否一致、得当。
车辆基本信息增加模块的操作界面的位置适中；界面内字体大小及颜色合适且美观。
2
功能
正例
已有车辆编号为0100的车辆，现新增加一条车辆基本信息记录，如下：
车辆编号自动生成，选择车辆类别、车牌号、选择驾驶人、选择购置日期、购买价格、引擎号、首发时间、末班时间、全程时间、车次
0101，大客，京P12345，张三，2013-6-1，350000，，5:
40，9:
30，
30，631
系统自动提示“添加车辆信息成功！
”
3
功能
反例
已有车辆编号为0100的车辆，现新增加一条车辆基本信息记录，如下：
车辆编号自动生成，选择车辆类别、已添加的车牌号、选择驾驶人、选择购置日期、购买价格、引擎号、首发时间、末班时间、全程时间、车次
0102，大客，京P12345，张三，2013-6-1，350000，，5:
40，9:
30，
30，631
点击提交按钮后提示“已添加过该车牌号”
4
功能
反例
已有车辆编号为0101的车辆，现新增加一条车辆基本信息记录，如下：
车辆编号自动生成，选择车辆类别、车牌号、选择驾驶人、选择购置日期、购买价格、已添加过的引擎号、首发时间、末班时间、全程时间、车次
0102，大客，京P12346，张三，2013-6-1，350000，，
5:
40，9:
30，
30，631
点击提交按钮后提示“已添加过该引擎号”
5
功能
反例
已有车辆编号为0103的车辆，现新增加一条车辆基本信息记录，如下：
车辆编号自动生成，选择车辆类别、车牌号、选择驾驶人、选择购置日期、购买价格、引擎号、首发时间、末班时间、未填全程时间、车次
0102，大客，P12346，张三，2013-6-1，350000，，5:
40，9:
30，，631
提示“请填写将信息填写完整”
4、站点基本信息管理模块：
模块名
站点基本信息管理模块——修改站点基本信息
开发人员
版本号
用例作者
白宸溪
设计日期
测试类型
功能测试
测试方式
手工
序号
类型
测试说明
输入数据/步骤
期望输出
实际输出
结果
1
界面效果
观察站点基本信息修改界面的外观
1、进入公交车车辆管理系统站点基本信息修改模块的操作界面
2、观察站点基本信息修改模块的操作界面的位置摆放是否得体并美观；字体的大小和颜色是否一致、得当。
站点基本信息修改模块的操作界面的位置适中；界面内字体大小及颜色合适且美观。
2
功能
正例
已进入站点基本信息管理修改界面，修改路线的长度，站点、车次的条件不变
1000
点击确定按钮后提示“修改成功！
”
3
功能
正例
已进入站点基本信息管理修改界面，修改车次，站点、路线的长度条件不变
631
点击确定按钮后提示“修改成功！
”
4
功能
反例
已进入站点基本信息管理界面，对车次、站点、路线的长度条件均未改变
保持原有数据
点击确定按钮后提示“您未对该页面做任何修改，是否要退出”，如果点击“是”则修改界面消失，显示站点基本信息管理主界面；如果点击“否”则继续留在该修改界面
模块名
站点基本信息管理模块——增加站点基本信息
开发人员
版本号
用例作者
白宸溪
设计日期
测试类型
功能测试
测试方式
手工
序号
类型
测试说明
输入数据/步骤
期望输出
实际输出
结果
1
界面效果
观察站点基本信息增加界面的外观
1、进入公交车车辆管理系统站点基本信息增加模块的操作界面
2、观察站点基本信息增加模块的操作界面的位置摆放是否得体并美观；字体的大小和颜色是否一致、得当。
站点基本信息增加模块的操作界面的位置适中；界面内字体大小及颜色合适且美观。
2
功能
正例
进入站点基本信息增加界面分别输入车次、站点名称、路线的长度
631，,
500-1000-800-1200
点击提交按钮界面提示“站点基本信息增加成功！
”
3
功能
反例
进入站点基本信息增加界面分别输入站点名称、路线的长度，未输车次
，,
500-1000-800-1200
点击提交按钮后，提示“车次不能为空！
”
4
功能
反例
进入站点基本信息增加界面分别输入车次、站点名称，路线的长度为空
631，
点击提交按钮后，提示“路线长度不能为空！
”
5
功能
反例
进入站点基本信息增加界面分别输入已添加过的车次，站点名称，路线的长度为空
631，，500-1000-800-1200
点击提交按钮后，提示“该车次已被添加！
”
5、驾驶人基本信息管理模块：
模块名
驾驶人基本信息管理模块——修改驾驶人基本信息
开发人员
版本号
用例作者
白宸溪
设计日期
测试类型
功能测试
测试方式
手工
序号
类型
测试说明
输入数据/步骤
期望输出
实际输出
结果
1
界面效果
观察驾驶人基本信息修改界面的外观
1、进入公交车车辆管理系统驾驶人基本信息修改模块的操作界面
2、观察驾驶人基本信息修改模块的操作界面的位置摆放是否得体并美观；字体的大小和颜色是否一致、得当。
驾驶人基本信息修改模块的操作界面的位置适中；界面内字体大小及颜色合适且美观。
2
功能
正例
已进入驾驶人基本信息管理修改界面，修改驾驶人联系电话，驾驶人姓名、性别、年龄、出生日期的条件不变
点击确定按钮后提示“修改成功！
”
3
功能
反例
已进入驾驶人基本信息管理修改界面，修改驾驶人联系电话，驾驶人姓名、性别、年龄、出生日期的条件不变
一三一
点击确定按钮后提示“对不起，您所输入的信息有误，请您重新填写！
”
4
功能
反例
已进入驾驶人基本信息管理修改界面，驾驶人联系电话、驾驶人姓名、性别、年龄、出生日期的条件不变
保持原有数据
点击确定按钮后提示“您未对该页面做任何修改，是否要退出”，如果点击“是”则修改界面消失，显示驾驶人基本信息管理主界面；如果点击“否”则继续留在该修改界面
模块名
驾驶人基本信息管理模块——增加驾驶人基本信息
开发人员
版本号
用例作者
白宸溪
设计日期
测试类型
功能测试
测试方式
手工
序号
类型
测试说明
输入数据/步骤
期望输出
实际输出
结果
1
界面效果
观察驾驶人基本信息管理增加界面的外观
1、进入公交车车辆管理系统的驾驶人基本信息管理增加模块的操作界面
2、观察驾驶人基本信息管理增加模块的操作界面的位置摆放是否得体并美观；字体的大小和颜色是否一致、得当。
驾驶人基本信息管理增加模块的操作界面的位置适中；界面内字体大小及颜色合适且美观。
2
功能
正例
进入驾驶人基本信息管理增加界面分别输入驾驶人姓名、性别、年龄、驾驶人联系电话、出生日期
张三，男，35，，1979-8-22
点击提交按钮界面提示“驾驶人基本信息增加成功！
”
3
功能
反例
进入驾驶人基本信息管理增加界面分别输入驾驶人姓名、性别、年龄、驾驶人联系电话、出生日期未填写
张三，男，35，，
点击提交按钮后，提示“出生日期不能为空，请您重新填写！
”
4
功能
反例
进入驾驶人基本信息管理增加界面分别输入驾驶人姓名、性别、年龄、驾驶人联系电话、出生日期未填写
张三，男，35，，1979年8月22日
点击提交按钮后，提示“对不起，您所输入的出生日期格式有误，请您重新填写！
”
5
功能
反例
进入驾驶人基本信息管理增加界面分别输入驾驶人姓名、性别、年龄、驾驶人联系电话、出生日期未填写
张三，男，35，，1979-8-22
点击提交按钮后，提示“对不起，该驾驶人信息已被添加！
”
（四）、测试开始条件和结束条件：
1、测试开始条件：
测试计划编写完成，其余各项准备工作就绪。
2、测试结束条件：
（1）在测试用例执行过程中，若发现测试用例通过率偏低，则可以返工，将其给开发人员修复后再进行继续测试。
（2）在所有测试用例执行完毕后，并且功能测试用例通过率非常高，达到几乎没有错误的程度，非功能性测试用例达到95%以上，则通过测试，即测试完成。
七、测试组织：
（一）、测试团队结构：
本测试团队由三个人组成，组长一名。
（二）、功能划分：
公交车车辆管理系统由注册模块、登录模块、车辆基本信息管理模块、站点基本信息管理模块、驾驶人员基本信息管理模块五个功能来划分，组长负责其中三个模块，其余每人负责一个模块。
（三）、联系方式：
姓名
联系方式
地址
白宸溪
2014@163
北京石油化工学院
A
北京石油化工学院
B
北京石油化工学院
八、测试环境及进度：
（一）、测试环境：
硬件环境：
计算机三台
软件环境：
7操作系统、数据库、浏览器。
（二）、测试进度：
序号
内容
负责人
进度
工作量（人日）
1
测试准备
全体人员
2014年10月20日
2
2
测试计划
白宸溪
2014年10月22日
1
3
测试环境
A
2014年10月23日
1
4
测试设计
B
2014年10月24日
1
5
测试执行
白宸溪、
A、B
2014年10月25日
2
6
测试报告
白宸溪
2014年10月27日
1
（三）、测试环境:
主机
硬件
软件
服务器
一台:
7
客户端
两台:
7
九、测试提交物：
对公交车车辆管理系统进行测试后，需要提交以下文件：
v测试进度每日小结
v测试问题汇总
v测试报告
十、测试计划的审批和变更方式：
（一）、测试计划的审批
完成测试计划后，由项目经理进行审批，检查测试计划的完善性和规范性，如果测试计划审批通过，则由审批人员签字后生效，否则，需重新修改。
（二）、测试计划的变更方式：
测试计划的变更：
软件测试计划是软件项目计划的子计划，会受到项目计划变更的影响。
若测试计划中需要变更，则说明有可能会导致测试计划变更的事件。
包括测试工具的改进，测试环境的改变或者是添加了新的功能等，都会引起测试计划的变更。
升级会员 