北京市农业节水信息工程系统测试方案.docx

项目编号：S-QH1301-G1605

北京市农业节水工程信息管理系统建设项目
（测试方案）

北京圣世信通科技发展有限公司
2016年11月

文档修订记录
版本号
变化状态
简要说明
日期
变更人
批准日期
批准人
V0.1
C
初次创建

*变化状态：C = 创立，A = 增加，M = 修改，D = 删除

文档审批信息
序号
审批人
角色
审批日期
签字
备注
1

2

3

目 录
1 简介 4
1.1 目的 4
1.2 背景 4
1.3 范围 5
1.3.1 测试阶段和测试类型概述 5
1.3.2 功能测试范围 6
1.3.3 非功能测试范围 12
2 测试参考文档和测试提交文档 12
2.1 测试参考文档 12
2.2 测试提交文档 13
3 测试计划 13
4 测试策略 14
4.1 功能测试 14
4.2 用户界面测试 15
4.3 安全性和访问控制测试 16
4.4 回归测试 16
4.5 性能测试 18
5 问题严重度描述 19
6 资源 21
6.1 人力资源 21
6.2 测试环境 22
6.3 测试工具 24
6.4 优先级 24
7 存在的风险及应对措施 25
7.1 存在的风险 25
7.2 应对措施 25

1 简介
1.1 目的
本测试计划的编写目的在于使测试人员更好地执行测试工作，说明了测试工作的各项要求指标，明确具体的测试任务，阐述测试范围及背景，提供维护人员解决问题所需的条件，形成本系统的质量记录，为以后工作提供参考资料。本测试计划的预期读者是北京市农业节水工程信息管理系统项目的软件开发人员、项目管理人员、技术总监、测试经理、测试人员、维护人员。
1.2 背景
＜项目名称＞ 北京市农业节水工程信息管理系统建设项目
＜项目简介＞根据《中共北京市委、北京市人民政府关于调结构转方式发展高效节水农业的意见》（京发[2014]16号），到2020年，北京市的耕地面积由目前的348万亩减少到250万亩，大力推进高效农业节水灌溉工程建设，实现农业高效节水灌溉设施全覆盖，农业用水量从目前的7.3亿m3减少到5.0亿m3。为落实“细定地、严管井、上设施、增农艺、统收费、节有奖”的工作思路以及“缺什么、补什么”的建设原则，急需对北京市250万亩农田基本情况进行摸底调查，便于对北京市农业节水灌溉进行统筹规划和精细化管理。北京市水务局选择顺义区作为试点，启动北京市农业节水图斑项目（一期）建设。
采用GIS（地理信息系统）、RS（遥感）等先进技术，将250万亩农田逐村逐地块落实到空间地图上，使地块分布、输配水工程、水源工程、用水户、工程档案等形成农业节水信息网络。信息主要包括水源信息表、输水管道信息表、地块信息表、用水户信息表和工程档案信息表，同时建立相互之间的关联关系，形成农业节水信息库。并通过对数据和图形进行挖掘、处理等，使数据和图形交互显示，为管理者提供可以查询、统计和管理的可视化信息平台。
1.3 范围
1.3.1 测试阶段和测试类型概述
根据《北京市农业节水工程信息管理系统建设项目需求规格说明书》及《项目实施计划》，初步制定以下测试阶段和测试类型。
表1-1测试阶段和测试起停标准表
测试阶段
开始标准
停止标准
测试类型
执行者

测试准备阶段
输入：
1、 项目需求分析完毕
2、 提供项目需求规格说明书文档
3、 提供系统原型
4、提供项目概要设计文档
输出：
1、测试计划
2、测试用例
3、测试资源的分配
4、搭建测试环境
测试准备
测试工程师

单元测试阶段
输入：
模块代码设计完毕
输出：
单元测试结束，撰写单元测试报告
代码测试
开发工程师

模块/ 集成 测试阶段

输入：
1、测试准备工作结束
2、单元测试通过
3、每个模块的低级bug不超过5个，页面不出现500或404错误
4、提交版本说明
5、提交版本，SVN代码及数据库脚本等
6、《开发集成计划》文档
输出：
1、 部署测试版本。
2、 版本说明内容测试完毕
3、 所有模块/集成测试项无遗留三级及以上错误，一级二级低级错误修复率应达到90%以上。
4、 Rejected Bug需要项目经理、技术经理确认。
1、功能测试、容错性测试、
2、业务流程测试、
3、角色权限测试、
4、数据关联流转测试
5、用户界面测试
测试工程师、项目测试经理、技术经理

系统测试阶段
输入：
模块和集成测试结束，达到模块测试和集成测试停止标准

输出：
1、系统满足《需求规格说明书》中定义的功能及非功能需求。
2、缺陷状态只允许存在closed或later或rejected状态，其中later或rejected状态需要项目经理和技术经理确认。
3、不允许遗留严重级别为三级及以上缺陷；对于一级二级低级错误修复率应达到95%以上。
4、完成测试报告。
1、用户界面测试
2、安全性与访问控制测试
3、系统整体功能流程联调测试（两轮）
4、回归测试
5、性能测试
项目测试经理、测试工程师、性能测试工程师
1.3.2 功能测试范围
根据系统需求规格说明书，列出所有需要测试的子系统及功能模块。

表1-2功能模块测试范围
计划测试内容
用户级
子系统名称
功能模块
子模块

登录
登录
登录
村级上报用户
系统管理
用户管理
查询用户的基本信息和权限信息
添加用户
编辑用户
批量删除用户
角色管理
查询用户角色
数据上报
查看审批状态
添加上报数据
查看文件
系统日志
查询所有角色操作信息统计
录入人员用户
统计分析
灌溉类型统计
节灌面积统计
喷灌统计
管灌统计
微灌统计
渠灌统计
机井统计
机井个数统计
两田一园井数
水表统计
井房统计
机井状况统计
管线统计
总管长统计
两田一园管长统计
用水量统计
机井用水量统计
年用水量统计
节水图集
输水工程
对上传图片进行增删查
田间工程
对上传图片进行增删查
基础信息
机井信息
对机井信息进行查看、添加、导入
输水工程信息
对输水工程信息进行查看、添加、导入
地块信息
对地块信息进行查看、添加、导入
粮田信息
对粮田信息进行查看、添加、导入
菜田信息
对菜田信息进行查看、添加、导入
果园信息
对果园信息进行查看、添加、导入
节灌信息
对节灌信息进行查看、添加、导入
用水户信息
对用水户信息进行查看、添加、导入

市区级审批用户

系统管理

用户管理

查询用户的基本信息和权限信息
添加用户
编辑用户
批量删除用户
角色管理

查询用户角色
数据上报

查询审批状态
查看文件
系统日志
查询所有角色操作信息统计
浏览人员用户
统计分析
灌溉类型统计
节灌面积统计
喷灌统计
管灌统计
微灌统计
渠灌统计

普通管理员

统计分析
两园一田统计
面积统计
灌溉方式汇总统计
粮田统计
菜田统计
果园统计
灌溉类型统计
节灌面积统计
喷灌统计
管灌统计
微灌统计
渠灌统计
机井统计
机井统计
两田一园井数统计
水表统计
井房统计
机井状况统计
管线统计
总管长统计
两田一园管长统计
用水量统计
机井用水量统计
年用水量统计
基础信息
机井信息
对机井信息进行增删改查导出
输水工程信息
对输水工程信息进行增删改查导出
地块信息
对地块信息进行增删改查导出
粮田信息
对粮田信息进行增删改查导出
菜田信息
对菜田信息进行增删改查导出
果园信息
对果园信息进行增删改查导出
节灌信息
对节灌信息进行增删改查导出
用水户信息
对用水户信息进行增删改查导出

系统管理

用户管理
对用户进行增删改查
角色管理
对角色进行增删改查
数据上报
对上报数据进行增删查
系统日志
查询所有角色操作信息统计

超级管理员

系统管理
用户管理
对用户进行增删改查
角色管理
对角色进行增删改查
数据上报
对上报数据进行增删查
系统日志
查询所有角色操作信息统计

1.3.3 非功能测试范围
根据系统需求规格说明书，列出非功能性测试类型如下：
1、 性能测试：
进行系统的最大并发测试
（1） 在获得详细机井数据情况下，10分钟内完成包括数据导入、数据处理、初步评估分析等工作并将结果展示给用户，1小时完成详细评估分析并展示；
（2） 基于北京市农业节水工程节水图片数据进行大量上传，并处理相关文件时间不超过5分钟，10分钟后能正常展示给用户。
2、用户界面测试
3、容错性测试
4、安全性与访问控制测试
2 测试参考文档和测试提交文档
2.1 测试参考文档
下表列出了制定测试计划时所使用的文档，并标明了各文档的可用性：
表2-1 测试参考文档
文档
（版本/日期）
已创建或可用
已被接收或已经过复审
作者或来源
备注
北京市农业节水工程信息系统建设项目需求规格说明书
是■ 否□
是■否□
刘阳

项目实施计划
是■否□
是■否□
刘阳

2.2 测试提交文档
《北京市农业节水工程信息系统建设项目测试方案》
《北京市农业节水工程信息系统建设项目测试分析报告》
3 测试计划
表2-2测试进度表
测试阶段
计划开始日期
计划结束日期
备注
测试前期准备
2017.03.13
2017.03.16
完成测试计划，设计测试用例、系统熟悉、测试环境搭建
模块测试/集成测试
2017.03.18
2017.03.23
版本编译部署、完成系统各个功能的测试、界面测试、回归测试、流程测试等
系统测试
2017.03.24
2017.03.28
安全性与访问控制测试、用户界面测试、整体ALPHA测试、流程测试、回归测试
测试收尾
2017.03.27
2017.03.28
完成性能测试报告，更新测试分析报告，完成最终版的测试分析报告

4 测试策略
本系统主要进行以下内容的测试：功能测试、用户界面测试、集成测试、安全和访问控制测试、回归测试、容错性测试、性能测试。下面将对各测试类型的具体测试策略进行介绍。
测试策略提供了对测试对象进行测试的推荐方法，对每种测试都提供了测试说明，并解释其实施的原因，说明了制定测试策略时所考虑的主要事项，将要使用的技术以及判断测试何时完成的标准等。
4.1 功能测试
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面（GUI）与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要：
表4-1 功能测试策略
测试目标
确保测试的功能正常，模块满足需求。
测试范围：
表1-2中涵盖的功能列表模块中所有功能点
技术：
采用手工测试方式。
测试前提：
1、正确理解各模块的业务要求；
2、确定被测试的功能点、设计测试用例；
3、利用有效的和无效的数据来执行各个用例，以核实以下内容，在使用有效数据时得到预期的结果，在使用无效数据时应显示相应的错误消息或警告消息，各业务规则都得到了正确的应用。
开始标准：
模块开发完成
完成标准：
所有计划的功能测试都已完成、缺陷已被修改
测试重点和优先级：
单个功能点的正确执行
需考虑的特殊事项：
无
4.2 用户界面测试
用户界面测试用于核实用户与软件之间的交互。用户界面测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，用户界面测试还可确保界面中的对象按照预期的方式运行，并符合公司或行业的标准。
表4-2 用户界面测试策略
测试目标
系统用户界面显示正确、友好。
测试范围：
所有界面及信息提示窗
测试内容：
核实以下内容：
1、 界面整体采用蓝白为主色调，上部为菜单、子菜单和用户信息，左侧为评估对象列表区，中部为地图展示区采用分块显示的方式，清晰完整的显示主要内容。
2、 整体界面、样式是否统一；有无信息显示不完整，出现错乱页面等；布局是否合理；字体、字型、字号、字颜色是否统一；图形使用适当并且显示正确。窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准。
技术：
采用手工测试的方法为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。
开始标准：
所有界面开发完成
完成标准：
成功地核实出各个窗口都与设计要求一致，符合标准和规范。具有灵活性、正确性、直观性、实用性、一致性要素
测试重点和优先级：
1. 界面信息的正确显示
2. 界面布局
3. 界面控制，如链接（发现404错误）、导航（死导航、乱导航、操作复杂）、返回按钮等
需考虑的特殊事项：
IE兼容性
4.3 安全性和访问控制测试
安全性和访问控制测试侧重于安全性的两个关键方面：
1.应用程序级别的安全性，包括对数据或业务功能的访问。
2.系统级别的安全性，包括对系统的登录或远程访问。
应用程序级别的安全性可确保：在预期的安全性情况下，用户访问特定的功能或用例，或者只能访问有限的数据。
系统级别的安全性可确保：只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。
4-4 安全性和访问控制测试策略
测试目标
应用程序级别的安全性：核实用户只能访问的功能或者数据
系统级别的安全性：核实只有具备系统和应用程序访问权限的用户才能访问系统和应用程序
测试范围：
所有模块
技术：
手工测试：1、根据需求说明书中所划分的角色，及各角色所赋予的权限，对应用安全性展开测试，确保各角色只能访问所赋予的权限功能。2、对系统的登录用户进行验证，确保系统访问安全。
开始标准：
系统测试开始
完成标准：
1、各种已知的用户都可正确的按照权限访问相应的功能或数据 2、系统登录验证正确
测试重点和优先级：
权限的运用、session过期的控制、非正常访问（如直接获取模块IE链接等）等情况的安全性验证
需考虑的特殊事项：
页面上的安全控制以及通过事务的控制，是否存在漏洞。
4.4 回归测试
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，选择正确的回归测试策略来改进回归测试的效率和有效性是非常有必要的。
表4-5 回归测试策略
测试目标
改进回归测试的效率和有效性，减少测试工作量和工作强度
测试范围：
测试各个阶段
技术：
手工测试
开始标准：
模块第一轮测试结束，开发修改了缺陷
测试策略：
1、测试用例库的维护，测试用例的维护是一个不间断的过程，通常可以将软件开发的基线作为基准，维护的主要内容包括下述几个方面。
(1)删除过时的测试用例
(2)改进不受控制的测试用例
(3)删除冗余的测试用例
(4)增添新的测试用例
2、回归测试执行包的选择
选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括：
(1)再测试全部用例
选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。
(2)基于风险选择测试
可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，测试从主要特征到次要特征。
(3)基于操作剖面选择测试
如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性，但实施起来有一定的难度。
(4)再测试修改的部分
当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。
再测试全部用例的策略是最安全的策略，但已经运行过许多次的回归测试不太可能揭示新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可以选择适当的策略进行缩减的回归测试。
本项目根据实际情况，采取第（4）种回归方式，并根据测试经验，对修改部分相关联的用例进行再次执行，以确保未引起新的错误。
完成标准：
达到回归测试要求。
测试重点和优先级：
根据开发修改bug 的先后，来进行回归
需考虑的特殊事项：
版本更新的正确性
4.5 性能测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。以下列出了性能测试的简单策略
4-7性能性测试策略
测试目标
进行系统最大并发测试，系统对本地数据访问和数据交换的响时间不超过30S
测试范围：
整个系统
技术：
通过性能测试工具LoadRunner,进行模拟测试场景，根据测试目标建立性能测试策略，得出测试结果。
开始标准：
完成性能测试策略脚本的编写
完成标准：
性能测试结果符合测试目标
测试重点和优先级：
测试重要为系统常用功能进行性能测试，优先测试
需考虑的特殊事项：
系统可能受框架影响的性能结果，注意登录是否存在瓶颈

5 问题严重度描述
Bug的严重程度依据该项bug对系统造成的影响程度来划分为5级，QC中的定义及划分标准如下：
表6-1 Bug严重程度定义表
QC中级别定义
具体说明
5_紧急
　5级bug：系统崩溃或挂起等导致系统不能继续运行。包括以下各种错误：
1）由于程序所引起的死机，非法退出
2） 死循环
3） 数据库发生死锁
4） 因错误操作导致的程序中断
5） 与数据库连接错误
6） 数据通讯错误
7） 与需求不一致
4_非常高
四级bug：即严重地影响系统要求或基本功能的实现，且没有更正办法。使系统不稳定、或破坏数据、或产生错误结果，或导致部分功能无法执行，而且是常规操作中经常发生的主要问题。包括以下各种错误：
1） 程序接口错误
2） 因错误操作迫使程序中断
3） 业务流程实现不正确
4） 用户权限无法实现
5） 功能实现不完整，如删除时没有考虑数据关联
6）基本功能未实现，影响流程或其他重要功能的进行。
3_高
三级bug：即严重地影响系统要求或基本功能的实现，但存在合理的更正办法，产生错误的中间结果但不影响最终结果等影响有限的问题。包括以下各种错误：
1、 功能的实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用；对数据库的操作不能正确实现
2、 基本功能未实现，但不影响执行工作功能或重要功能
3、 字段输入内容未作验证判断，导致错误内容出现
4、操作界面错误（包括数据窗口内列名定义、含义是否一致）
5、打印内容、格式错误（只影响报表的格式或外观，不影响数据显示结果的错误）
6、删除操作未给出提示
2_中
二级bug：即易用性差，或界面拼写错误及用户使用不方便小问题。包括以下各种错误：
1、界面不规范
2、 辅助说明描述不清楚
3、 长时间操作未给用户提示
4、 提示窗口文字未采用行业术语
5、 可输入区域和只读区域没有明显的区分标志
6、 必填项与非必填项应加以区别
7、 滚动条无效
8、 键盘支持不好，如在可输入多行的字段中，不支持回车换行；或对相同字段，在不同界面支持不同的快捷方式
9、 界面不能及时刷新，影响功能实现
10、错别字
1 _低
一级bug ：其他错误。包括以下各种错误：
1、 光标跳转设置不好，鼠标（光标）定位错误
2、 一些建议性问题

Bug的修改优先级依据bug是否将影响测试流程继续进行下去的程度来划分为5级，QC中的定义及划分标准如下：

表6-2 Bug修改优先级定义表
QC中级别定义
具体说明
5_紧急
1. 导致测试工作无法进行
2. 导致测试流程无法进行
4_非常高
缺陷严重程度为非常高(包含非常高)以上级别，缺陷所在的模块作为其他模块的前序操作模块或者作为其他模块的结果显示模块
3_高
缺陷严重程度为高（包含高）以上级别，缺陷所在的模块独立于系统其他模块的业务、数据流程。不作为其他模块的前序操作模块也不作为其他模块的结果显示模块
2_中
bug的严重程度为中及以下的所出现的缺陷将引起歧义，产生误导，导致操作的不方便
1 _低
修改建议
6 资源
6.1 人力资源
下表列出了在此项目的人员配备方面所作的各种假定。
表3-1 测试人员需求表
角色
测试人员
所推荐的最少资源（所分配的专职角色数量）
具体职责或注释
测试工程师
熊亮
1
撰写测试计划、搭建服务器及数据库的测试环境、建立测试用例树，确认测试版本，建立QC的相关项目人员权限及版本信息，相关成果的SVN提交，部分功能测试、撰写测试分析报告。
测试工程师
黄亚坤
1
部署测试版本，设计测试用例、执行具体测试，配合撰写测试报告，作测试记录，整理测试问题，总结测试结果。
测试工程师
汪洪征
1
部署测试版本，设计测试用例、执行具体测试，配合撰写测试报告，作测试记录，整理测试问题，总结测试结果。
性能测试工程师
田彩云
1
搭建性能测试环境、设计性能方案、录制性能脚本、准备性能数据、测试
6.2 测试环境
下表列出了测试的系统环境。
表3-2 测试环境说明表
软件环境（相关软件、操作系统等）
应用服务器端软件环境：
Windows server 2008 R2
JDK 1.6 以上版本
Tomcat6.0
数据库服务器端软件环境：
Windows server 2008 R2
Oracle10g
Plsql7.0
GIS服务器端软件环境：
水利统一GIS平台
客户端软件环境（1）
Windows 7
IE9，10
客户端软件环境（2）
Windows XP
IE8.0
硬件环境（网络、设备等）
应用服务器配置：
CPU：Intel(R)_Core(TM)_i5-3350P_CPU_@_3.10GHz
内存：8G
硬盘：1T
网卡100M
数据库服务器配置：
CPU：Intel(R)_Core(TM)_i5-3350P_CPU_@_3.10GHz
内存：8G
硬盘：1T
网卡100M
GIS服务器配置：待GIS开发组补充
CPU：
内存：
硬盘：
客户端配置（1）：
CPU：Intel(R)_Core(TM)_i5-3350P_CPU_@_3.10GHz
内存：8G
硬盘：1T
客户端配置（2）：
CPU：Pentium(R)Dual E2200 @2.20GHz
内存：2G
硬盘：500G
6.3 测试工具
此项目将列出测试使用的工具。
表3-3 测试工具使用表
用途
工具
生产厂商/自产
版本
测试用例
QC
HP

Bug 管理
QC
HP

配置管理工具
TortoiseSVN

1.3.5
文档书写
OFFICE
Microsoft
2003/2000
远程控制工具
MSTSC
Microsoft

6.4 优先级
按照代码编制与开发进度进行测试，特殊要求的模块优先级设为高，否则按照编码模块提交顺序作为优先级的先后进行排列。
7 存在的风险及应对措施
7.1 存在的风险
目前大部分项目系统集成和软件开发是分开进行的。因此软件系统赖以运行的硬件环境和网络环境的建设进度对软件系统是否能顺利实施具有相当大的影响。

7.2 应对措施
和用户签定相关的协议、跟进系统集成部分的实施进度、及时提醒用户等。
并且保证会在出现系统宕机时，在48小时之内远程或现场将问题给于解决。