项目软件测试计划定稿.docx
- 文档编号:4291336
- 上传时间:2023-05-06
- 格式:DOCX
- 页数:32
- 大小:100.69KB
项目软件测试计划定稿.docx
《项目软件测试计划定稿.docx》由会员分享,可在线阅读,更多相关《项目软件测试计划定稿.docx(32页珍藏版)》请在冰点文库上搜索。
项目软件测试计划定稿
**项目测试计划
文件名称:
**项目v1.2.0测试计划
文件编号:
0234245
版本号:
V1.2.0
编制:
马工日期:
2018-2-18
审核:
张三日期:
2018-2-19
文档标识
当前版本
V1.2.2
当前状态
编制
√
发布日期
2018/5/24
发布
√
修订历史记录
版本
日期
AMD
修订者
修改内容
评审号
变更控制号
1.0
2018/5/22
AMD
马工
需求分析、测试策略
001-1A-bb
V_1.0
1.0
2018/5/24
MD
马工
进度安排、资源配置
001-1A-bb
V_1.0
1.0
2018/5/24
M
马工
项目简介、项目进度
001-1A-bb
V_1.0
(A-添加,M-修改,D-删除)
目录
**项目测试计划1
1.简介3
1.1目的3
1.2背景3
1.3范围4
2.测试参考文档和测试提交文档5
2.1测试参考文档5
2.2测试提交文档5
3.测试工作周期和进度6
3.1测试周期安排:
6
3.2测试进度安排:
7
4.测试资源8
4.1人力资源安排及分工8
4.2测试环境8
4.3测试工具9
5.系统风险、优先级9
5.1系统风险9
5.2风险管理10
5.2.1项目进度风险10
5.2.2需求变更风险10
5.2.3沟通不良风险10
5.2.4功能和需求不一致风险11
5.3优先级11
6.测试策略11
6.2接口测试12
6.3集成测试13
6.4功能测试14
6.5用户界面测试14
6.6性能评测15
6.7负载测试16
6.8强度测试17
6.9容量测试18
6.10安全性和访问控制测试19
6.11故障转移和恢复测试20
6.12配置测试21
6.13安装测试22
7.问题严重度描述23
8.附录23
1.简介
1.1目的
<**项目>的这一“测试计划”文档有助于实现以下目标:
Ø对每个测试模块制定测试策略和方法
Ø制定测试测试进度和任务安排
Ø确定软件测试目标
Ø准备测试所需的环境
Ø预测测试风险
1.2背景
<**项目>是由**信息技术有限公司第一小组承接的实际测试任务,
随着当今互联网在各个行业里面的盛行和普及,给社会分工和协同配合创造了史无前例的巨大商机,打破固有的商业模式,模糊了现有的行业边界,使全世界更为有机的结合,共同推动着社会的进步,提高生产力,优化生产关系,为实现中华民族的伟大复兴迈开了伟大的一步,我党顺应时代的步伐,积极筹建和推进“互联网+”的伟大举措,优化各个产业、各个阶层的资源分配,进一步推进社会制度的进化,深化供给侧改革,加大城市化进程,通过互联网技术合理的将各个地域和各个行业不同深度和广度的连接起来,全球统一一盘棋,而信息的共享就势在必行,我公司的web共享业务正式在这种时代背景下应运而生!
也必将成为时代的弄潮儿!
!
!
1.3范围
需要测试的目标:
在<**项目>中包含:
【登陆界面】、【个人中心】、【设置】、【地图查看界面】、【我的钱包】、【我的预约】、【意见反馈】、【账单】等八大模块。
系统性能指标要求如下:
1、系统支持的在线用户数不低于500
2、登录、学生管理、就业管理、档案管理、就业统计、作业管理等模块,相关操作的平均响应时间不超过3s
软硬件环境需求:
1、系统可运行于Windows平台,支持Apache服务程序
2、系统主体采用C/S架构,支持手机客户端(安卓4.5、IOS等)
3、系统部分采用B/S架构,支持IE11、谷歌浏览器对系统的访问
3、系统数据库使用MySQL5.5(或更高版本)
界面需求:
1、系统界面规范,颜色、风格搭配
2、页面布局合理,人性化
3、界面文字信息准确
4、系统界面中的窗体与各种控件可正常显示和使用,易用性好
5、Tab键、enter键、快捷键等可以正常使用
2.测试参考文档和测试提交文档
2.1测试参考文档
文档
(版本/日期)
已创建或可用
作者或来源
可行性分析报告
是
需求评审
软件需求定义
是
需求报告
软件概要设计
是
概要设计报告
软件详细设计
是
详细设计报告
软件测试需求
是
需求报告
硬件测试需求
是
测试1组
模块开发手册
是
开发组
用户操作手册
是
上级领导
安装指南
是
上级领导
2.2测试提交文档
测试阶段
提交文档
需求评审
《软件测试可行性分析》
测试准备
《软件测试计划书》、《软件测试方案书》、《测试用例》
冒烟测试
《冒烟测试简报》
联合测试
《联合测试简报》
全流程测试
《全流程测试简报》、《软件性能评估报告》、《软件运行环境指导》
安装测试
《安装卸载说明书》
验收测试
《验收测试报告》、《用户使用手册》
3.测试工作周期和进度
3.1测试周期安排:
预计历时1.5个月,分为三个轮次,每个伦次有冒烟测试、联合测试、全流程测试和验收测试以及相应的β测试各个测试阶段的时间安排如下:
测试活动
测试轮次
天数统计(天)
开始日期
结束日期
需求评审
0.5
2018-2-1
2018-2-19
测试要点提取
0.5
2018-2-19
2018-2-19
制定测试计划
1
2018-2-20
2018-2-20
制定测试方案
1
2018-2-21
2018-2-21
编写测试用例
2
2018-2-22
2018-2-23
冒烟测试
2
2018-2-24
2018-2-25
联合测试
2
2018-2-26
2018-2-27
全流程测试
第一轮
3
2018-2-28
2018-3-2
第二轮
2
2018-3-3
2018-3-4
第三轮
2
2018-3-5
2018-3-6
性能测试
7
2018-3-7
2018-3-13
稳定性测试
2
2018-3-14
2018-3-15
兼容性测试
1
2018-3-16
2018-3-16
安装测试
1
2018-3-17
2018-3-17
安全性测试
1
2018-3-18
2018-3-18
编写测试总结
1
2018-3-19
2018-3-19
测试评估
1
2018-3-20
2018-3-21
验收测试
2
2018-3-22
2018-3-23
项目总结
2
2018-3-24
2018-3-25
3.2测试进度安排:
单阶段占总项目时间比例图:
项目进程比例线性图:
4.测试资源
4.1人力资源安排及分工
角色
人力资源配置
具体职责或注释
人数
角色
测试项目负责人
1人
李工
﹥分析测试需求
﹥编写测试《可行性报告》
﹥编写测试计划和方案
﹥编写测试用例
﹥组织评审相关测试文档
﹥安排测试任务
﹥协调测试事务
﹥管理测试文档
测试工程师
3人
徐工、刘工、马工
﹥测试环境的搭建
﹥执行测试用例
﹥完善自动化测试用例
﹥录制自动化测试脚本
﹥参与测试评审和讨论
﹥编写测试总结报告
辅助测试开发工程师
2人
刘工
李工
﹥协助测试(编写测试函数)
﹥参与测试(白盒自测)
﹥协助搭建测试环境(自动化环境)
﹥协助自动化框架制定和实施
4.2测试环境
下表列出了测试的系统环境
资源名称/类型
基本配置及数量
软件环境(相关软件、操作系统等)
应用软件
调试器、Xtest
测试工具
Jmeter、Apacheab…
浏览器
Firefox、遨游、360浏览器、Opera、搜狗、Chrome、QQ、XX、世界之窗、猎豹、鋭影、蚂蚁、IE8
测试管理平台
禅道
PC系统
Windows7、Windows10、OS
硬件环境(网络、设备等)
测试数据库服务器
PostgreSQL、mongodb
PC台式机
Lenovo、Mac
安卓机
VivoX6SA、RedMiNote3、MateBNXT-AL10
(第三方平台调试上百台机型)
IOS机
IPHONE6SPLUS、IPHONE7、IPHONE6
4.3测试工具
此项目将列出测试使用的工具:
用途
工具
生产厂商/自产
版本
单元测试
Junit
由KentBeck和ErichGamma
5.0
性能测试
Jmeter
Apache
3.3
性能测试
Apacheab
Apache
2.4.27
性能测试
LoadRunning
惠普-水星公司
8.1
接口测试
Postman
Chrome
5.1.3
版本管理
SVN
Apache
1.10.0
Bug管理
禅道
4.0
5.系统风险、优先级
5.1系统风险
系统在测试阶段的风险主要有:
Ø对质量需求或产品的特性理解不准确,造成测试范围分析的误差。
Ø测试用例没有得到百分之百的执行。
Ø需求的临时变化,导致设计的修改和代码的重写,导致测试时间不够。
Ø测试用例设计不到位,忽视了一些边界条件,深层次的逻辑,用户场景等。
Ø测试环境,一般不可能和实际运行环境完全一致,造成测试结果的误差。
Ø有些缺陷的出现频率不是百分之百,不容易被发现。
Ø回归测试一般不运行全部测试用例,是有选择性的运行,必然带来风险。
5.2风险管理
5.2.1项目进度风险
Ø料:
需求变更、测试用例数据设计不充分、质量标准不统一;
Ø人:
疲态、同化效应、定位效应、业务不熟、测试人员变动;
Ø时:
测试时间不足、测试时间延长;
Ø环:
被测试软件版本不统一、被测试环境不一致、被测试硬件环境不一致、测试硬件未及时到位;
Ø法:
错误或缺失测试方法、场景缺失或部分缺失、测试用例实施不充分;
Ø其他:
沟通不良、开发提交测试时间比计划延时。
5.2.2需求变更风险
Ø针对需求变更过快问题,测试人员与开发人员应及时保持联系取得最新需求,并且测试人员必须和开发人员高度一致,保证测试人员所掌握需求是第一手资料。
一旦发生需求改动而测试人员不知情的情况,首先确认需求变动。
必要情况下可增加测试人员,同时,测试相关文档可以稍后修改,完成预定目标。
Ø针对需求不清晰问题,找相应的需求人员和开发人员进行需求评审,一定要和需求人员和开发人员意见达到一致。
5.2.3沟通不良风险
预防这种风险应该是项目建设之初测试人员就和此项目的相关人员进行交流和沟通,注意培养和锻炼自身的沟通技巧。
5.2.4功能和需求不一致风险
测试结束时,应用功能和需求不一致:
告知项目经理,并留下文档进行说明。
5.3优先级
Ø低:
暂时不影响继续测试,可以在方便时解决。
Ø中:
部分功能无法继续测试,需要优先解决。
Ø高:
测试暂停,无法进行,必须立即解决。
6.测试策略
本次测试将和开发同步进行,从开发的需求分析阶段,测试部门遍开始介入,进行相应的评审和需求测试,以及项目的测试可行性分析,一直到项目交付上线,都做好不同阶段的测试工作。
单元测试阶段以黑盒测试为主,辅以白盒测试,检测各个模块的相应功能是否正确。
集成测试阶段以冒烟测试为主,检测各个模块的衔接和组装的问题,检查模块间的兼容性问题。
系统测试阶段主要第黑盒测试,对比需求说明书,检测集成后的软件能不能实现用户的要求,以及相应的软硬件的运行环境和兼容性测试和安装测试、安全性测试等。
验收测试阶段在一定程度上使用α测试和β测试,已检查用户体验和相关性能(压力测试、强度测试、稳定性测试等)。
针对这次的测试计划,所有的功能都需要检查到位,但从软件的角度考虑,将模拟20万人同时登陆或使用的情况,以判断软件的承载量和第三方(电子地图提供商、银行系统)的多线程处理事务的衔接能力,以及和数据库读取数据、存储数据、修改数据的高并发下的处理能力。
另外,良好的用户体验和软件的易用性和友好性也是本次测试的重点,将会针对性找一些用户,做体验测试。
在<**项目>中,数据库和数据库进程应作为一个子系统来进行测试。
在测试这些子系统时,不应将测试对象的用户界面用作数据的接口。
对于数据库管理系统(DBMS),还需要进行深入的研究,以确定可以支持以下测试的工具和技术。
测试目标:
确保数据库访问方法和进程正常运行,数据不会遭到损坏
测试范围:
低频段到高频段、不同的移动运营商提供的网络服务、特殊的地理位置、不同的终端机、不同的地域
技术:
调用各个数据库访问方法和进程,并在其中填充有效的和无效的数据(或对数据的请求)。
检查数据库,确保数据已按预期的方式填充,并且所有的数据库事件已正常发生;或者检查所返回的数据,确保正当的理由检索到了正确的数据
交接标准:
所有的正常输入能够正常的运行、所有的异常操作又都相关的正常提示返回
通过标准:
所有的数据库访问方法和进程都按照设计的方式运行,数据没有遭到损坏。
测试重点和优先级:
压力测试和强度测试,优先级最高
测试风险(人员、时间、环境三因素):
测试可能需要DBMS开发环境或驱动程序在数据库中直接输入或修改数据。
进程应该以手工方式调用。
应使用小型或最小的数据库(记录的数量有限)来使所有无法接受的事件具有更大的可视度。
6.2接口测试
测试目标
确保接口调用的正确性(软件接口传参和返参的正确性、硬件接口的连接性能和稳定性)
测试范围:
所有软件、硬件接口,记录输入输出数据
技术:
软件接口使用Postman辅助测试。
硬件接口会考虑不同的环境下做测试,以及软硬件的兼容问题
交接标准:
软件接口是在单元测试完成之后立即准备执行,硬件接口是在系统测试完成之后在全面检测
通过标准:
模拟现在市场上的绝大部分场景的要求,设计相关测试用例,并且执行通过,满足足够的用户需求
测试重点和优先级:
接口的测试和集成测试
测试风险(人员、时间、环境三因素):
接口的限制条件(软件接口的数据类型和硬件接口的型号)
6.3集成测试
测试目标
将系统的八大模块至下而上依次集成,逐步检测需求中业务流程,数据流的正确性,尽可能做到低耦合,高内聚,既要检查模块的独立性,又要测试模块组合之后的实用性和可重用性
测试范围:
需求中明确的业务流程,或组合不同功能模块而形成一个大的功能。
尤其是模块组合之后参数传递的正确性和堆其他功能的影响,以及整体的运行效率,对资源的使用等
技术:
利用有效的和无效的数据来执行各个用例、用例流或功能,以核实以下内容:
在使用有效数据时得到预期的结果。
在使用无效数据时显示相应的错误消息或警告消息。
各业务规则都得到了正确的应用。
运用Jmeter模拟相应的场景,检查模块在一定条件下运行的效率
交接标准:
在完成某个集成测试时必须达到标准
通过标准:
所计划的测试用例已全部执行。
所发现的缺陷已全部解决。
所有功能都能良好的运行。
测试重点和优先级:
重点测试登陆界面、个人中心、设置、地图查看界面、我的钱包等模快,这几个模快集成的子模块偏多或者有和第三方软件的接口连接或者是模块内部接口角落,逻辑复杂,其他功能可以考虑优先级排低点,相对比较容易解决。
测试风险(人员、时间、环境三因素):
用户需求变更或者是因为某种原因,开发进度跟不上,需要测试部门作出一定的调整,比如某功能暂时不需要或者是增加一些其他模块。
6.4功能测试
测试目标
确保八大模块的功能都能良好的执行,且相互之间不紊乱,符合需求分析的要求
测试范围:
登陆界面、个人中心、设置、地图查看界面、我的钱包、我的预约、意见反馈、账单
技术:
利用有效的和无效的数据来执行各个用例、用例流或功能,以核实以下内容:
在使用有效数据时得到预期的结果。
在使用无效数据时显示相应的错误消息或警告消息。
各业务规则都得到了正确的应用。
通过猴子测试和大猩猩测试来模拟用户随机情况和极端情况下对软件的操作,已检测软件各个模块的功能的完整性和对业务需求的满足性。
交接标准:
任何子模块测试完成后,都可以初步集成,以检测生成的模块的功,直至软件组装完毕。
通过标准:
测试用例的覆盖率达到100%;
严重Bug的修复率达到100%;
所有的用户功能都满足;
没有任何多余的功能;
所有为实现用户需求所需要提供的(但是没有明确提出的)功能,校测完毕且符合要求;
对于所有常用的可能出现的情况都进行了模拟测试,且达到了产品说明书指定的标准。
测试重点和优先级:
需求说明里面明确规定了的功能是最终要的。
测试风险(人员、时间、环境三因素):
用户需求的更改
6.5用户界面测试
用户界面(UI)测试用于核实用户与软件之间的交互。
UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。
另外,UI测试还可确保UI中的对象按照预期的方式运行,并符合公司或行业的标准。
测试目标
核实以下内容:
通过测试进行的浏览可正确反映业务的功能和需求,这种浏览包括窗口与窗口之间、字段与字段之间的浏览,以及各种访问方法(Tab键、鼠标移动、和快捷键)的使用
窗口的对象和特征(例如,菜单、大小、位置、状态和中心)都符合标准。
测试范围:
登陆界面、个人中心、设置、地图查看界面、我的钱包、我的预约、意见反馈、账单的图形化界面和动态界面
技术:
为每个窗口创建或修改测试,以核实各个应用程序窗口和对象都可正确地进行浏览,并处于正常的对象状态。
使用正交法和因果图法等方法合理设计测试用例,确保最大的功能检测率和最合理的测试用例方案。
交接标准:
有任一模块达到了测试的标准,并且具备可测性
通过标准:
成功地核实出各个窗口都与基准版本保持一致,或符合可接受标准,排版合理,界面友好且功能完备。
没有错别字没有意义的字符等,符合绝大多人的操作习惯和审美习惯,简单易用,功能键表意能力强,易上手。
测试重点和优先级:
登陆界面和使用界面(所有用户最关心的界面和使用过程中停留时间最长的界面)
测试风险(人员、时间、环境三因素):
用户需求的变更
6.6性能评测
测试目标
核实所指定的事务或业务功能在以下情况下的性能行为:
正常的预期工作量
预期的最繁重工作量
测试范围:
不同的情况下(高并发地跨地域、跨网络、跨平台、跨行等)软件的反应速度和数据传输速度以及正确性
技术:
使用为功能或业务周期测试制定的测试过程。
通过修改数据文件来增加事务数量,或通过修改脚本来增加每项事务的迭代数量。
脚本应该在一台计算机上运行(最好是以单个用户、单个事务为基准),并在多个客户机(虚拟的或实际的客户机,请参见下面的“需要考虑的特殊事项”)上重复。
交接标准:
系统测试完成之后,第一轮、第二轮、第三轮测试都要进行
通过标准:
单个事务或单个用户:
在每个事务所预期时间范围内成功地完成测试脚本,没有发生任何故障。
多个事务或多个用户:
在可接受的时间范围内成功地完成测试脚本,没有发生任何故障。
能够满足复杂多变的实际应用场景的需求,且测试通过率达到相应的指标。
测试重点和优先级:
全省、全国范围之内的抽样使用覆盖。
测试风险(人员、时间、环境三因素):
综合的性能测试还包括在服务器上添加后台工作量。
可采用多种方法来执行此操作,其中包括:
直接将“事务强行分配到”服务器上,这通常以“结构化语言”(SQL)调用的形式来实现。
通过创建“虚拟的”用户负载来模拟许多个(通常为数百个)客户机。
此负载可通过“远程终端仿真(RemoteTerminalEmulation)工具来实现。
此技术还可用于在网络中加载“流量”。
使用多台实际客户机(每台客户机都运行测试脚本)在系统上添加负载。
性能测试应该在专用的计算机上或在专用的机时内执行,以便实现完全的控制和精确的评测。
性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。
6.7负载测试
测试目标
核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。
模拟软件在一些比较极端的情况下、以及特殊时间段的使用频率的使用情况。
测试范围:
以至少一周的时间为准,模拟软件的每天各个频段的使用情况,逐步增加难度,结合产品手册等相关的其他文档,设置高频段和低频段的测试用例。
以及使用错误验证法追加一些其他的用例,都需要做好相应的检测。
技术:
使用为功能或业务周期测试制定的测试。
通过修改数据文件来增加事务数量,或通过修改脚本来增加每项事务发生的次数。
交接标准:
集成测试之后就可以搭建相应的测试环境,并且投入相应的测试中。
通过标准:
多个事务或多个用户:
在可接受的时间范围内成功地完成测试,没有发生任何故障。
一方面检查服务的事务处理能力和高并发情况下的线程安全性和稳定性,另一方面检查软件运行的效率和第三方接口使用时的有效性和正确性。
测试重点和优先级:
我的钱包和账单以及地图查看等模快的使用。
数据库服务器的负载和处理能力。
测试风险(人员、时间、环境三因素):
负载测试应该在专用的计算机上或在专用的机时内执行,以便实现完全的控制和精确的评测。
负载测试所用的数据库应该是实际大小或相同缩放比例的数据库。
6.8强度测试
测试目标
核实测试对象能够在以下强度条件下正常运行,不会出现任何错误:
服务器上几乎没有或根本没有可用的内存(RAM和DASD)
连接或模拟了最大实际(实际允许)数量的客户机
多个用户对相同的数据或帐户执行相同的事务
最繁重的事务量或最差的事务组合(请参见上面的“性能测试”)。
服务器和客户端硬件配置(PCB、CUP等)边界条件下的使用情况和使用性能。
测试范围:
客户机和服务器以及相应的网络环境的软硬件配置下对软件使用性能的影响
技术:
使用为性能评测或负载测试制定的测试。
要对有限的资源进行测试,就应该在一台计算机上运行测试,而且应该减少或限制服务器上的RAM和DASD。
对于其他强度测试,应该使用多台客户机来运行相同的测试或互补的测试,以产生最繁重的事务量或最差的事务组合。
使用自动化测试工具,模拟多用户同时在线时软件的运行情况
交接标准:
集成测试和系统测试并发的去进行强度测试,相关的测试环境准备就绪便可以开始测试
通过标准:
所计划的测试已全部执行,并且在达到或超出指定的系统限制时没有出现任何软件故障,前面几轮测试提出的Bug都已得到妥善的处理和修复,或者导致系统出现故障条件的并不在指定的条件范围之内。
测试重点和优先级:
测试服务器的内存、CUP和主板、硬盘等硬件设备在极端条件下的使用性能,高并发情况下服务器的多线程运行情况。
网络资源紧张的情况下软件的执行效率
测试风险(人员、时间、环境三因素):
如果要增加网络工作强度,可能会需要使用网络工具来给网络加载消息或信息包。
应该暂时减少用于系统的DASD,以限制数据库可用空间的增长。
使多个客户机对
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 软件 测试 计划 定稿