行政审批项目测试方案.docx
- 文档编号:25933595
- 上传时间:2023-06-16
- 格式:DOCX
- 页数:16
- 大小:95.39KB
行政审批项目测试方案.docx
《行政审批项目测试方案.docx》由会员分享,可在线阅读,更多相关《行政审批项目测试方案.docx(16页珍藏版)》请在冰豆网上搜索。
行政审批项目测试方案
行政审批电子监察项目
系统测试方案说明书
版本
拟制
日期
审核
日期
批准
日期
文档信息:
版本
日期
AMD
修订者
说明
0.1
2007-08-12
A
陈孝良
创建
(A-添加,M-修改,D-删除)
1.概述
1.1测试目标
为了保证市行政电子监察市到县延伸软件系统的顺利推进,将对中大软件所所提供的系统进行系统测试,测试各项系统功能是否正常,系统界面是否完善,业务流程流转是否顺畅,系统所提供的接口是否正常,模拟正常的电子政务办理,系统管理员对业务的办理,后台控制业务对系统进行功能上的测试,并对系统的典型应用的反应时间、客户端、服务器的CPU、Memory使用情况、服务器的响应速度、系统可靠性测试进行综合的测试。
这一测试计划文档有助于实现以下目标:
1、确定测试的范围和要求,对所需的资源,并对测试的工作量进行估计。
2、协调进度顺序,并描述测试的方法和策略,推荐可采用的测试策略,并对这些策略加以说明。
3、测试产品是否达到设计的要求。
包括:
各个功能点是否以实现,业务流程是否正确。
4、系统正常运行且工作稳定,办事审批流程正确无误运行,系统接口可行。
5、确保BUG数量及缺陷率控制在可接受的范围内。
1.2项目背景
为贯彻中央办公厅、国务院《2006―2020年国家信息化发展战略》精神和落实广东省《关于加快电子政务建设提高政府行政效能和公共服务能力的实施意见》要求,在“市行政审批系统与电子监察系统”一期基础上建设并延伸到各个区县,以此推动以市为中心,覆盖各个区县的“一站式”行政审批系统与电子监察系统,加快体制改革和创新、提高行政效率、改善公共服务、强化综合监管,为市及其区县的社会、经济进一步发展坚实的基础。
中山大学一期建设的基础上,结合“扩大范围、科学设计、有效利用、积极衔接”这4个方面的精神,积极创新,立足实际,建设一套好用、易用、喜欢用的行政审批系统与电子监察系统,使市行政审批与电子监察系统建设能达到“多、快、好、省”的效果(即项目服务功能多、建设速度快、建设效果好、建设成本低),初步形成具有特色的电子政务应用体系。
1.3测试范围
行政审批电子监察市县延伸系统的测试主要包括有功能测试,性能测试,接口测试,业务流程测试,安全测试等,对系统的功能点进行测试,主要依据《需求规格说明书》及《详细设计说明书》,对于应用程序模块需要设计者提供基本路径测试法的测试用例。
性能测试主要对系统运行时的性能性指标,反映时间等性能进行测试,看是否满足系统原先设计的基准。
接口测试指在系统中各系统之间的接口是否正确,预留的接口能否正常使用。
系统基于B/S架构设计,用户通过WebBrowse访问系统,所以需额外测试系统在不同用户的浏览器端的显示是否合适以及从最终用户的角度进行安全性和可用性测试。
因此在功能测试中需添加Cookies测试;性能测试中添加连接速度测试以及安全性测试。
1.4词汇缩写
编号
缩写/术语
全称
描述
备注
1
2
3
4
1.5参考资料
编号
名称
版本号
描述
1
系统需求文档
2
系统设计文档
2.被测的对象
市行政审批电子监察市县延伸系统测试主要包括有:
各个系统功能点的测试,系统性能的测试,各项审批流程的测试,外露接口的测试。
通过测试发现系统中是否在系统功点的实现上存在缺陷,漏洞等,系统能支撑多大用户的同时访问,各项上线的流程存在的问题。
以下分别详细列出系统需要进行测试的各个对象。
2.1功能模块
市行政审批电子监察延伸项目主要包括有五大模块:
应用支撑平台、行政审批系统电子监察系统、政府门户网站系统、应用接入接口系统。
每个大的模块下又细分为很多小的功能点,具体在附录1中有详细说明,需要针对每个功能点进行测试,按照标准的步骤,一定的输入规则,看是否产生正确的结果或提示,其主要任务是检查每个模块是否有错误,发现系统实现时出现的功能性的缺陷。
2.2系统性能
主要用于政府行政审批及电子监查,的广大市民通过网络通道提交申请给政府,政府根据市民提供的材料对其进行审核,如果审核通过,最后办理得到证件。
由于用户量很庞大,政府机构审核流程量大,系统每天需要处理的业务量相当大,所以有必要对系统进行性能测试,查看系统服务器支撑的用户量,系统在用户访问量大时的反映时间。
从而有针对性的对系统服务器的配置,系统网络的架构,软件的开发进行一定的调整。
2.3审批流程
市行政审批电子监察延伸项目中包括有七县一区200个行政单位的2300多项审批事项,每个审批事项又有多个业务流程,在定制业务流程时,需要首先对整个组织机构进行建模,给每个人赋予相应的权限进行受理或审批。
由于调研取得的信息本身不确定性及在实际输入整个人员,组织架构时有可能出现错误输入,导致流程在定制以后,如果不针对每个流程进行测试,将有相当多的流程可能会存在问题。
所以必须针对每个审批通过后录入系统的流程进行测试,看是否流程定制正确,权限的赋予正确否,流程是否按照原来的审批进行流转。
针对整个系统需要测试的三个主要对象进行系统测试,才能保证系统能快速有效的响应客户的需求,减少系统故障次数,减轻后期的系统维护压力。
2.4接口测试
市行政审批电子监察市县延伸系统包括的接口有:
行政审批接口,电子监察接口,统计查询接口等,针对整个系统需要测试的接口进行系统测试,才能保证系统具有良好的扩展性能,后期的政府民声,有形要素、政府办公等系统才能通过接口达到数据交流的目标。
3.应测试的特性
由于市行政审批电子监察延伸项目是属于一个全市共享的系统,其用户包括有市的各层领导,广大的审批办理人员及广大的市民,在系统运行过程中不允许出现错误,所以需要对该系统的特性进行全面的测试,每种特性关系到系统某方面的性能,要全面、正确、合理的进行测试,以保证系统快速、稳定、高效的进行流程处理。
3.1功能完整性
通过各个功能点的测试,对系统的各个模块功能进行测试,测试系统各个功能的实现是否完整,能否支持用户完成一个工作事项。
在每个具体测试用例中通过对输入、预期输出及实际输出的比较,测试整个系统各个功能点是否按照预期的输出进行输出,是否对错误的输入进行处理及提示用户操作。
功能完整性包括有输入信息,预期输出信息,操作步骤及实际的输出信息,无论复杂度如何,把系统作为一个黑盒子来看待。
问题简化为处理输入信息、系统的信息处理和输出信息之间的关系。
通过每个功能点的测试用例的测试,可以确定是否该功能点达到了预定的系统要求。
对于某些暂时无法测试的流程(如系统权限的设置),我们需要记录具体的情况,并把该情况反馈给中大开发团队,开发人员有针对的对这些问题进行软件调整,并使之能正常测试,如果出现个别确实无法测试的用例(如数据的统计功能),则需要重点标记,待测试条件成熟后再行测试。
3.2界面的友好性
系统采用B/S系统架构,用户办公主要通过浏览器对系统进行操作,所以必须要通过测试确定在正常的网络环境的配置下,能打开系统网页进行操作,测试中应详细统计系统中哪些页面不被浏览器支持,系统在何种情况下会有异常情况发生,发生时所表现的状况及应该如何处理,以供开发部门进行改善或者提供良好的意见,以供后期维护参考。
3.3系统安全性
市行政审批电子监察延伸项目外挂到Internet上,需要确保系统Web应用下的安全性,广大的用户提供接入系统的服务,这对系统的安全性提出了一个重大的考验,其安全性主要包括有如下方面:
系统是否有超时的限制,相关的重要信息是否写进日志、是否可追踪,使用了安全套接字时,测试加密是否正确,信息是否完整。
系统不支持直接修改数据库的功能,如果需要对数据库进行修改,需要向相关领导请示,由专业人员进行操作。
3.4流程正确性
由于调研取得的信息本身的不确定性及在实际录入过程中产生的录入误差,导致流程的流转不正确,不能按需求部门的要求进行流转。
所以需要对录入系统的各个流程进行测试,以保证流程在运行后能正确的流转,达到市政府、市民的要求。
针对整个系统需要测试的流程,需要三方面进行配合,一方面中大的开发团队人员需要严格按照软件开发规程进行软件开发及录入工作,以保证流程的录入信息准确性及系统流程准确性。
第二方面中国通信集团广东有限公司分公司需要成立专门的测试团队对流程进行测试,从市民的角度、开发者角度、政府的角度对各个局录入的每个流程进行测试,并形成流程测试报告,确保每个流程都能正常流转。
最后市政府方面也需要在各个局加强电子监察与行政审批系统的宣传力度,并确保每个局能有一位信息专员进行流程的基本的测试,从政府的角度来看待系统问题,看是否有遗漏和不足处。
3.5接口的正确性
行政审批电子监察延伸项目中涉及到七县一区的行政审批系统,电子监察系统的接口的测试,其它外部系统或WAP平台需要调用该系统提供的接口进行查询、审批等工作,需要模拟接口外部系统提供相关参数提交给系统,看接口能否接收数据、业务流程处理是否按照期望进行流转,保证未来其它信赖于本项目的系统的顺利开发。
4.不被测试的特性
市行政审批电子监察延伸项目是属于一个市、县一体化系统,该项目是在成功实施的市行政审批电子监察系统的基础上进行大集中模式的二次开发,由于前期的成功实施,所以有部分的测试可省略,主要针对市、县延伸功能进行详细测试,各个县区可抽取一个县作为案例,测试其上报流程、内部审批流程等通用性的功能的正确性,以此来减少测试量,提高测试工作的效率。
4.1前期成功测试
该项目是在前期的基础上由市一级审批改造成为市、县一级的审批,原先的系统功能变动不大,主要是增加了县级单位的行政审批电子监察功能,故当前我们的测试重点主要是原系统市、县衔接部分功能的测试,县级行政办事单位的行政审批电子监察功能,系统不需要针对以前成功测试过的单元再做测试,只需要对系统正在开发的新的功能模块进行详细的测试,确保功能的完整性。
4.2重复县区测试
市行政审批电子监察延伸项目将覆盖市七县一区所有行政审批单位,我们将选取最便利的梅县作为典型进行测试,测试其应用平台,功能模块、用户界面,政府办公行政审批等基础模块,其它的县、区不需要进行大量测试,只需要针对界面做少量的测试即可,减少整体系统测试的工作量。
5.测试设计综述
5.1功能测试
用于测试应用系统的功能需求的黑盒测试方法。
这类测试应由测试员做,这并不意味着程序员在发布前不必检查他们的代码能否工作(自然他能用于测试的各个阶段)。
本测试方案中利用黑盒测试法对系统进行动态测试时,需要测试软件产品的功能,不需测试软件产品的内部结构和处理过程。
观察下列系统中所列出的功能点是否能正常运行,会不会在运行时出现BUG,影响系统功能的实现,能否实现系统预先设计的功能要求。
在附录一中列出了系统中出现的各个子系统的功能点。
模拟后台操作用户、政府各级行政单位用户、外网用户的操作方法、对照系统使用说明检查模块的功能,看是否实现了全部功能。
用政府、的要求检查,检查界面的正确性,用不同顺序的进行操作,测试程序对各种事件的处理是否有逻辑上错误。
用不正确的操作,测试程序对异常的处理能力。
以用户的眼光看待程序,测试程序是否操作简单,方便。
5.2性能测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
性能测试在软件的质量保证中起着重要的作用,它包括的测试内容丰富多样。
中国软件评测中心将性能测试概括为三个方面:
应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。
通常情况下,三方面有效、合理的结合,可以达到对系统性能全面的分析和瓶颈的预测。
1、应用在客户端性能测试:
考察客户端应用的性能,测试的入口是客户端。
它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等。
2、应用在服务器端性能测试:
对于应用在服务器上性能的测试,可以采用工具监控,也可以使用系统本身的监控命令等。
3、应用在网络上性能的测试:
可采用通过网络进行网络性能的测试,测试网络的反映时间。
5.3流程测试
流程测试是通过模拟用户的操作进行流程申请,再模拟政府的操作进行流程的审批,最后看是否能够从申请到受理,再到审批,最后发证,流程流转完成。
流程的审批工作是政府工作中最重要的一环,不能出现任何差错及遗漏,所以要对各个局的流程进行综合测试,并形成测试报告。
从两方面来进行测试,对系统流程的正确性进行评价。
1、中国通信集团广东有限公司分公司成立专门的测试小组对各个流程进行测试,并将测试的结果形成测试用例及测试报告,针对发现的总是,要求中大开发团队快速进行解决。
2、市政府各个局需要有专人来负责此次流程的测试,对在测试中发现的问题,出现的与实际情况不符合的情况,尽快以书面的形式通知中大开发团队,尽快的解决流程流转的流程与实际不符。
6.测试需求
测试需求是根据本阶段的测试目标从不同的角度明确本阶段的各种需求因素。
包括有:
环境需求、被测试对象需求、测试数据准备等。
6.1环境需求
有许多因素对于项目测试工作能否成功完成具有重要影响,在此将这些因素统称为测试环境。
下面给出一些通用的信息类别,考虑其中各个因素对于测试工作是起促进作用还是阻碍作用,最大限度利用各种可用资源,同时将各种阻碍因素的影响最小化。
6.1.1参测单位
市行政审批电子监察是市市政府委托中国通信集团广东有限公司分公司进行项目协调与招标。
中国通信集团广东有限公司分公司及市市政府协商通过后,交与中大开发商进行行政审批与电子监察系统的开发工作。
测试者从政府的层面、中国通信集团广东有限公司分公司的层面进行测试:
6.1.1.1中国通信集团广东有限公司分公司
作为行政审批电子监察系统的推进者,需要对整个软件的功能、性能、流程进行整体测试,软件测试人员在整个测试过程中作为市民、市政府的代理,在测试的过程中需要以用户的眼光来测试系统,不能以专业的眼光来测试系统,要求系统必须方便,实用,人性化,体现政府办公特色,需要提出方便用户操作的修改意见,这样才能达到测试的目标。
6.1.1.2市市政府
市政府方面也需要在各个局加强电子监察与行政审批系统的宣传力度,指定每个局有一个测试人员,从政府的角度来看待系统问题,看是否有遗漏和不足处,如果发现系统中出现的系统的流程流转与实际的流程流转不相符,人员不配备,组织架构不完全等流程问题,立即形成书面材料提交给中大开发商,中大开发团队需尽快予以解决。
信息产业局需对整个系统的界面,系统的功能点进行审核,界面上需针对界面配色方案、界面的内容,表达形式进地审核,最后获得有关领导的同意,在功能点上检查系统的是澡有政府指定要求的功能,并能正常运行。
6.1.2测试信息
在系统测试时要注意几个方面的内容,测试是否按进度进行实施,是否形成了测试报告,是否形成了测试库,是否测试过程中的任何文档和结果均要保存并进行跟踪,跟踪的结果如何。
其中测试进度在测试计划中有详细说明,测试问题报告在测试用例中有详细记载,形成的问题跟踪报告在系统实施问题总表中记录,并实时进行跟踪。
6.1.3测试团队
1、中国通信集团广东有限公司分公司测试团队
角色
姓名
具体职责或注释
测试审核人
王志祥
负责审核
测试实施人
李志雄
负责具体的测试(功能、接口测试)
测试实施人
陈孝良
负责具体的测试(主要是功能测试)
测试实施人
熊富权
负责具体的测试(主要是功能测试)
测试实施人
姚舒红
负责具体的测试(界面、流程测试)
6.2被测对象需求
软件产品最终体现为提供给客户的一种操作经历或解决方案,包括支撑平台、应用软件和用户操作,以及相互之间的数据交互,具有多维的特点。
为了测试工作取得成效,必须综合考虑这些层面。
以下给出软件产品应包含的一些重要的元素类别,如果仅注意测试其中几个类别则可能会遗漏重要错误。
6.2.1支撑平台
市行政审批电子监察延伸项目软件产品所依赖的事物有:
外部的硬件设施,网络环境,外部支撑的软件、系统应用的各种中间件,平台组件等。
1、硬件设施
硬件设施包括有用于支撑软件产品工作的硬件元素和配置,不作为产品的组成部分,如服务器,磁盘阵列,外部网络环境等等,这些硬件设施共同构成整个网络的硬件支撑平台。
2、软件设施
用于支撑软件产品工作的其他软件元素和配置,不作为产品的组成部分,如操作系统、驱动程序等系统应用到的各种软件,及在软件开发中应用到的各种中间件,平台组件等。
6.2.2软件元素
市行政审批电子监察延伸项目所需要进行测试的对象主要包括有以下三类:
结构、功能、数据。
其中结构包括有:
组成产品的任何代码结构,从可执行码直至单个例程,子系统之间的连接和通信点。
任何协调与用户交换数据的功能,任何协调与用户之外的其他实体(如其他程序、硬盘、网络、打印机等等)交换数据的功能,任何用于定义产品、区分产品或完成核心需求的功能,任何检测错误和从错误中恢复的功能,要处理的任何数据,经过系统处理后产生的任何结果数据。
6.3测试数据准备
系统测试主要是对数据进行输入,通过系统一定的处理后,输出一定的数据给用户,系统中数据主要包括有以下几类:
输入:
产品要处理的任何数据。
输出:
经产品处理后产生的任何结果数据。
预置值:
要作为产品的一部分提供给客户、或直接构建在产品内部的任何数据如预制数据库,缺省值等等。
固定值:
存储在内部、在多个操作中应保持一致的任何数据,包括产品模式或状态如选项设置、视图模式、文档内容等等。
时序:
数据和时间之间的任何关系,如每秒击键次数、文件的时间戳、或分布式系统的同步。
非法:
任何能够触发错误处理函数的数据或状态。
6.4测试时间安排
系统平台成功部署在IAP测试平台后,将于6月18日至6月27日下午,按照测试用例的用例安排逐步进行测试。
前一周主要侧重于行政审批电子监察系统的功能模块、系统界面的测试、安全测试及部分压力测试,下一周主要重点在流程订制、审批流程测试,上报件的接口测试,系统提供的接口测试。
时间
主要测试内容
人员安排
6.18-6.20
功能测试、界面测试、安全测试及部分压力测试等
陈孝良、姚舒红、熊富权
6.22-6.27
流程订制、审批流程测试,上报件的接口测试,外露接口测试等
陈孝良、姚舒红、熊富权
7.测试设计
7.1测试规程设计
通过遵守一定的规程,可以大大减少测试的准备和实施费用。
对最终软件系统进行全面的测试,确保最终软件系统满足产品需求并且遵循系统设计。
测试规程的主要实施步骤
1、制定系统测试计划
系统测试小组各成员共同协商测试计划。
测试组长按照指定的模板起草《系统测试计划》。
该计划主要包括:
·测试范围(内容)
·测试方法
·测试环境与辅助工具
·测试完成准则
·人员与任务表
2、设计系统测试用例
·系统测试小组各成员依据《系统测试计划》和指定的模板,设计《系统测试用例》。
·测试组长邀请开发人员和同行专家,对《系统测试用例》进行技术评审。
3、执行系统测试
·系统测试小组各成员依据《系统测试计划》和《系统测试用例》执行系统测试。
·将测试结果记录在《系统测试报告》中,用“缺陷管理工具”来管理所发现的缺陷,并及时通报给开发人员。
4、缺陷管理与改错
·任何人发现软件系统中的缺陷时都必须使用指定的“缺陷管理工具”。
该工具将记录所有缺陷的状态信息,并可以自动产生《缺陷管理报告》
·开发人员及时消除已经发现的缺陷。
·开发人员消除缺陷之后应当马上进行回归测试,以确保不会引入新的缺陷。
7.2测试用例设计
7.2.1网站功能测试用例
概述:
确保测试的功能正常,如导航,数据输入,处理、检索是否正确,以及业务规则的实施是否恰当。
即对交互的输出或结果进行分析,以此来核实应用程序及其内部进程,这是目前的测试重点。
目标:
利用有效的和无效的数据来执行各个用例流,以核实以下内容:
在使用有效数据时得到预期的结果,在使用无效数据时显示相应的错误消息或警告消息。
案例编号:
T1
目的:
参考资料:
前提条件:
测试方法:
期望结果:
测试结果:
(如果测试结果与期望结果一致,请填写“通过”;否则,请尽量详细描述不一致之处。
)
测试人员:
测试时间:
7.2.2网站性能测试用例
概述:
主要是对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。
性能评测的目标是核实性能需求是否都已满足。
目标:
核实下列情况下的性能行为:
正常的预期工作量、预期的最繁重工作量
需考虑的特殊事项:
可创建“虚拟的”用户负载来模拟许多个(通常为数百个)客户机。
最好使用多台实际客户机(每台客户机都运行测试脚本)在系统上添加负载。
应该在专用的计算机上或在专用的机时内执行,以便实现完全的控制和精确的评测。
其所用的数据库应该是实际大小或相同缩放比例的数据库。
多用户不同网络条件下的连接速度是否满足要求
参考表格如下:
性能A描述
多用户不同上网方式下的测试
用例目的
前提条件
输入数据
期望的性能(平均值)
实际性能(平均值)
7.2.3业务流程测试用例
概述:
主要是对流程流转步骤,流程权限分配,流程的正确性进行评测和评估。
流程测试的目标是核实系统中所有流程是否按需求进行录入并实现。
目标:
核实下列情况下的性能行为:
流程图、权限分配表、流程表、人员组织架构表
流程编号:
T1
目的:
参考资料:
前提条件:
测试步骤:
期望结果:
测试结果:
(如果测试结果与期望结果一致,请填写“通过”;否则,请尽量详细描述不一致之处。
)
测试人员:
测试时间:
7.2.4接口测试用例
概述:
主要是对系统提供的接口的正确性,安全性,可调用性进行测试,包括通过接口对数据库的写入,读取,更新,删除操作,是否不经过安全验证也能联接进入系统进行操作。
接口测试的目标是核实系统中所提供的接口是否按需求实现并能正常工作。
目标:
核实下列情况下的性能行为:
插入大数据量的操作效率;接口的安全性;
测试序号
被测函数名
输入条件或输入数据描述
测试步骤
输入数据
预期输出的结果
测试结论
测试程序
测试人员
测试日期
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 行政 审批 项目 测试 方案