重庆市XXXX（标题）
系统测试方案
重庆XXXXX有限公司
2018年5月
1.项目概述
1.1.测试目的
本测试方案为XXXX项目的测试方案，目的是针对系统测试过程进行一个完整的安排，同时对重庆市信用信息应用平台二期工程LED大屏及配套改造的各个模块进行整理，给测试人员及相关人员提前了解相关的计划安排。
1.2.测试目标
XXXX项目的测试目标是实现项目需求正确理解、开发按需求进行编制编码，业务功能实现正常，测试验证BUG达到上线标准。
1.3.测试人员
XXXX项目测试人员、项目管理人员。
1.4.测试参考文档
《重庆市XXXX-招标文件》
《重庆市XXXX-投标文件》
《重庆市XXXX-需求规格说明书》
《重庆市XXXX-系统详细设计说明书》
《重庆市XXXX-数据库设计说明书》
《重庆市XXXX-接口设计说明书》
2.用户需求概述
|
系统名称 |
功能名称 |
内容描述 |
|
|
3.设计运行环境
3.1.网络环境要求
运行环境为政务外网环境和互联网环境，通过网闸和防火墙进行隔离。
|
序号 |
需求项 |
需求参数 |
|
1 |
互联网出口带宽 |
>=200M |
|
2 |
互联网和电子政务外网互联 |
>=1000MB |
|
3 |
互联网内部网络 |
>=10000MB |
|
4 |
电子政务外网内部网络 |
>=10000MB |
|
5 |
内网网络延迟 |
<30ms |
|
6 |
外部网络延迟 |
<50ms |
|
7 |
Packets丢包率 |
<0.01%/1000s |
4.测试方案
4.1.测试环境
浏览器
|
浏览器 |
备注 |
|
|
全功能测试 |
|
FireFox |
兼容性测试 |
|
360 |
兼容性测试 |
|
IE 9及以上 |
兼容性测试 |
|
Opera |
兼容性测试 |
屏幕大小及分辨率
|
屏幕大小 |
分辨率 |
备注 |
|
15.6 英寸 |
1920 * 1080 |
兼容性测试 |
|
15.6 英寸 |
1280 * 720 |
兼容性测试 |
|
23.8英寸 |
1920 * 1080 |
兼容性测试 |
4.2.测试需求
4.2.1.测试需求列表
|
序号 |
功能名称 |
测试类型 |
|
1 |
1.1供给侧-第一产业 |
功能测试、数据测试 |
|
2 |
1.2供给侧-第二产业 |
功能测试、数据测试 |
4.2.2.功能测试
测试对象：测试需求列表（见章节4.2.1）里所有标注“功能测试”的需求。
测试用例：在执行前需进行内部评审，并用禅道工具进行执行状况跟踪。
4.2.3.性能测试
测试对象：测试需求列表（见章节4.2.1）里所有标注“性能测试”的需求
测试工具：Jmeter，在PC上对系统进行施压
测试时间：所有功能的性能测试需在相应功能模块完成并通过功能测试后再执行
|
分类 |
用户量 |
指标 |
优先级 |
备注 |
|
登录 |
100 （高峰期） |
系统平均响应时间≤0.2秒 系统最大响应时间≤0.5秒 |
中 |
前端系统指标测试需结合Jmeter的报告
后端CPU利用率可使用Jmeter插件在服务器安装，Jmeter自动监控；若不允许装插件，则使用人工监控记录 |
|
300 （极限） |
系统平均响应时间≤0.3秒 系统最大响应时间≤0.8秒 |
低 |
||
|
查询、统计类 |
100并发 （普通查询、统计） |
系统平均响应时间≤0.2秒 系统最大响应时间≤0.5秒 后端CPU利用率<=50% 后端内存利用率<=50% |
高 |
|
|
100并发 （大数据量查询、统计） |
系统平均响应时间≤0.5秒 系统最大响应时间≤1秒 后端CPU利用率<=70% 后端内存利用率<=70% |
高 |
4.2.4.易用性测试
测试对象：测试需求列表（见章节4.2.1）里所有标注“易用性”测试的需求。
测试内容：
- 应用系统提供一致性的中文图形用户界面、颜色统一、协调、美观。字体应统一大小。
- 应用系统对普通用户的操作界面应该以B/S方式实现。
- 应用系统必须支持同时打开多个管理窗口以对不同任务进行并行的操作。
- 应用系统应该支持通过Tab键或回车键可以访问到同一个窗口的所有空间对象。
- 查询时，若为日期条件、数值条件支持范围查询。
- 查询时，若为字符型条件支持模糊查询。
- 系统必须采用分页机制显示查询结果，并显示返回的记录数目、当前页和总页数。
- 应用系统的查询统计结果可以转存为EXECL等常见格式文件。
- 应用系统发现用户提交有误信息，必须以弹出窗口的形式明确提示用户错误的原因，并把界面控制焦点置于发生错误的控件对象上。
- 应用系统的操作界面必须明确标识出必填的输入信息。
- 在导致系统数据发生变化的操作执行之前，系统应该弹出提示窗口供用户确认。
- 对于复杂的信息结构，系统应该采用分栏的机制在同一个窗口中显示不同的信息内容，并自动刷新不同部分的信息内容。
- 当应用系统正在执行用户提交的请求而无法返回时，必须明确标识系统处于繁忙阶段。
- 应用系统功能菜单必须按照功能域、功能项的分类方法进行组织。
- 对于操作员无权限使用的菜单功能，应用系统不显示该菜单或将其设置为不可用状态。
4.2.5.安全性测试
测试对象：测试需求列表（见章节4.2.1）里所有标注“安全性”测试的需求。
测试内容：
- 登录/注销：对用户进行身份识别和鉴别；登录失败后，采取结束会话、限制非法登录次数和当网络登录连接超时自动退出等措施；登录时采用加密技术
- 执行“删除”、“退出”等有风险操作时，应有“确认”、“放弃”提示对话框。
- 身份鉴别信息具有不易被冒用的特点，口令有复杂度要求，如口令长度至少八位以上，同时包含字母、数字、特殊字符等，并定期更换口令。
- 系统应该对用户在客户端输入或导入的数据进行长度、范围、数据类型等属性的合法性进行检验，对不合法的数据应该禁止输入系统，并且提示明确的错误信息。
- 系统应该在服务器端对将要存储到后台数据库中的数据进行合法性检验，对不合法的数据应该舍弃，并报警。
- 系统应该能够允许多用户同时对同一个系统资源进行不相冲突的访问操作，并且设定保护措施，防止相互可能造成的冲突。
- 系统应该禁止客户端用户执行相互矛盾的操作，例如两个用户同时修改一个资源。
5.测试计划
5.1.测试人员
表５－1－１：测试人员
|
姓名 |
角色 |
角色描述 |
具体职责 |
|
XXX |
测试人员 |
研发测试质量管理 |
协调沟通任务、评审测试用例、辅助测试 |
|
XXXX |
测试人员 |
研发测试 |
制定测试计划、编写测试报告、编写测试用例、执行测试 |
5.2.测试准备工作
表５－2－１：测试准备工作
|
测试类型 |
测试准备内容 |
负责人 |
|
所有 |
编写测试计划 |
XXXX |
|
功能测试 易用性测试 |
编写测试用例 |
XXX |
|
评审测试用例 |
XXXX |
|
|
兼容性测试 |
软件资源（各个浏览器） |
XXXX |
5.3风险评估
表５－3－１：风险评估
|
风险分析 |
预防措施 |
责任人 |
|
测试开始时间受制于开发进度，若开始时间较晚，可能无法在预定的交付时间完成所有测试 |
随时跟踪开发进度调整测试时间计划，若发现测试开始时间较已设定时间延迟时间太长，与项目经理沟通，在进度、范围、质量之间进行平衡。 |
XXXX |
|
测试周期时间可能会受开发质量影响，如bug太多则会延长测试时长 |
与相应团队成员分析质量原因 与项目管理团队沟通是否在进度、范围、质量之间进行平衡 |
XXXX |
|
测试人员对需求的熟练程度、详细设计文档的熟悉程度 |
尽量按照测试用例对所有功能进行全面覆盖。 |
XXXX |
5.4.系统测试进入准则
表５－4－１：系统测试进入准则
|
标准名称 |
标准说明 |
风险 |
|
测试用例 |
测试用例通过测试内部评审、以及其他项目团队成员同意（如项目经理） |
说明：由于个人的测试思维和时间关系，测试时可能会有一定的疏漏，测试操作也具有一定的随机性，不会按部就班。 控制：测试人员在测试前都参与用例的评审，熟悉每个测试用例的测试要点，及设计目的，以保证用例规定的所有要点都被覆盖。 |
|
冒烟测试 |
开发单元测试完成 系统冒烟测试通过 |
说明：编写系统测试用例之前，先准备好冒烟测试用例，待所有的冒烟测试用例（开发版）由开发人员执行通过完后，测试人员方可进行冒烟测试（测试版）和系统测试用例的执行 控制：冒烟测试用例主要针对各页面元素检查、主体流程的功能及页面各链接和按钮跳转是否正确进行测试。 |
5.5.系统测试退出准则
表５－5－１：系统测试退出准则
|
标准名称 |
标准说明 |
风险控制说明 |
|
最低标准 |
测试用例：覆盖率100%，通过率90% 遗留bug：所有严重程度为“1”的修复完毕并通过验证；存在少量严重程度为“2”； |
将未通过的测试用例导出与项目经理分析并确认是否可接受 在阶段结束之前，与项目经理和其他项目团队成员确认需在交付前解决的bug list
|
|
合理标准 |
测试用例：覆盖率100%，通过率95% 遗留bug：所有严重程度为“1”和“2”的bug修复完毕并通过测试验证 |
|
|
较高标准 |
测试用例：覆盖率100%，通过率99% 遗留bug：只存在少量严重程度“3”和“4”的并且其优先级也为“3”或者“4” |
Bug等级说明：
严重程度为1（致命）：系统崩溃、中断、死机、数据丢失、安全问题、主要功能未实现、严重错误且没有应急解决方案、系统性能严重低于最低要求
严重程度为2（严重）：数据错误、程序逻辑错误
严重程度为3（一般）：功能小错误且有应急解决方案
严重程度为4（轻微）：人机交互或界面优化建议、提示语等拼写小错误，不影响用户正常使用。
6.测试用例
6.1.功能测试用例
|
用例标题 |
步骤 |
预期 |
|
1.1供给侧-第一产业 |
1. 点击重庆市宏观经济运行大数据展示系统 |
1. 进入网站首页，查看数据正确性显示 |
6.2.性能测试用例
|
用例标题 |
步骤 |
预期 |
|
001-1000用户并发统一社会信用代码查询 |
1. JmeterGUI模式下创建线程组，并将线程数设置为1000 2. 减少负载机资源不足影响，调整ramp-up period为10秒，即用户启动及准备时间为10秒 3. 新增事务控制器 3.1 添加登录接口进行登录 3.2 添加“统一社会信用代码”查询接口，在该接口上添加Synchronizing Timer集合控制组件，并设置模拟1000用户集合后才执行请求 4. 以jmeter -n -t xx.jmx -l result.jtl命令行方式执行脚本后分析结果 |
1. 3. 4.平均响应时间≤2秒，最长响应时间不超过5秒;后端CPU利用率<=50%，后端内存利用率<=50% |
|
002-1000用户并发登录 |
1. JmeterGUI模式下创建线程组，并将线程数设置为1000 2. 减少负载机资源不足影响，调整ramp-up period为10秒，即用户启动及准备时间为10秒 3. 添加登录接口进行登录，在该接口上添加Synchronizing Timer集合控制组件，并设置模拟1000用户集合后才执行发请求 4. 以jmeter -n -t xx.jmx -l result.jtl命令行方式执行脚本后分析结果 |
1. 3. 4.平均响应时间≤2秒，最长响应时间不超过5秒 |
|
003-3000用户并发登录 |
1. JmeterGUI模式下创建线程组，并将线程数设置为3000 2. 减少负载机资源不足影响，调整ramp-up period为10秒，即用户启动及准备时间为30秒 3. 添加登录接口进行登录，在该接口上添加Synchronizing Timer集合控制组件，并设置模拟3000用户集合后才执行发请求 4. 以jmeter -n -t xx.jmx -l result.jtl命令行方式执行脚本后分析结果 |
1. 3. 4.平均响应时间≤3秒，最长响应时间不超过8秒 |
|
003-1000用户并发企业信用详情查看 |
1. JmeterGUI模式下创建线程组，并将线程数设置为1000 2. 减少负载机资源不足影响，调整ramp-up period为10秒，即用户启动及准备时间为10秒 3. 新增事务控制器 3.1 添加登录接口进行登录 3.2 添加“企业信息详情”查询接口，在该接口上添加Synchronizing Timer集合控制组件，并设置模拟1000用户集合后才执行请求 4. 以jmeter -n -t xx.jmx -l result.jtl命令行方式执行脚本后分析结果 |
1. 3. 4.平均响应时间≤5秒，最长响应时间不超过10秒;后端CPU利用率<=70%，后端内存利用率<=70% |