自动化测试流程

自动化测试流程（精选8篇）

自动化测试流程 第1篇

QTP是HP公司一款成熟的企业级自动化测试工具, 它的核心理念是关键字驱动。作为一款功能自动化测试工具, 能够记录用户在被测应用系统上的有效操作步骤, 自动用VB语言录制测试脚本, 用户通过修改测试脚本, 对测试数据参数化, 回放测试脚本, 以模拟用户的输入和点击达到自动化测试的目的[1,2]。QTP的关键词驱动方式能让脚本开发根据待测系统的功能便捷地添加、更新、和裁剪测试步骤[3]。因此, 我们开发了基于QTP的自动化测试工具, 管理脚本开发和业务流程用例设计。下面以某金融软件测试为例, 介绍业务流程自动化测试的实现与应用。

2 自动化测试工具设计思想与框架

2.1 设计思想

易于维护:采用用例和测试脚本相独立, 脚本与用例之间低耦合, 运用统一对象库管理策略, 方便自动化测试资源的复用和维护。采用XML文本存储数据, 将数据与用户界面分隔开来, 结构简单, 便于数据管理和复用[4]。

易于使用:自主研发自动化测试管理工具, 业务测试人员和脚本开发人员具有独立工作流, 业务测试人员通过工具提供的可视化界面编写业务流程测试场景, 自动化测试开发人员进行脚本开发, 提供实现方法。

面向金融软件的业务级封装:根据金融软件的特点, 自动化回归测试基本单位为业务场景, 每个场景由若干用例组成, 每个用例代表一个业务操作步骤或者业务功能。

2.2 功能架构

自动化测试工具由测试管理端、测试文件、测试引擎及QTP接口组成。测试管理端为可视化应用模块, 通过GUI功能界面管理对象及脚本、测试用例、测试执行、测试结果。测试管理端是自动化测试引擎工具的主控中枢。

测试文件实现以XML形式存储任务调度、脚本、测试用例和测试结果。它实现的是配置管理功能, 记录测试过程中的输入和输出。

测试引擎是自动化测试工具的核心。测试引擎的工作原理为通过读取测试任务调度文件, 载入对象及脚本、测试用例、测试数据, 利用脚本解释器调用QTP提供的方法和属性, 完成测试任务, 输出测试结果和日志。如图1所示。

QTP接口主要为提供脚本解释器, 调用QTP的方法和属性, 完成脚本执行。它的优点是, 让QTP在后台执行脚本, 降低系统资源占用。

3 自动化回归测试实例

某金融软件是以报价、成交、查询为主功能的业务平台, 涉及的交易品种较多, 测试的业务操作较复杂。由于金融平台容易受政策和市场的影响, 业务变更比较频繁, 软件代码修改往往影响的范围较广, 业务流程回归测试占用较多人力。因此, 引入自动化回归测试有着实际的意义。在提高资源利用率及回归测试质量的同时, 也可以释放人力资源投入到需求变更的测试设计和测试执行, 以及项目过程改善和度量中。

3.1 对象及脚本

对象和脚本是自动化测试引擎工具的基础。采用目录层级管理自动化对象和脚本, 方便对多个项目, 多个模块的对象脚本管理。

对象和脚本模块, 分为3个窗口如图2所示, 右上角公共对象库窗口, 适用于整个项目;右下角私有对象库窗口, 仅用于当前模块;左侧的当前模块脚本编辑窗口。首先创建脚本名, 通过载入QTP对象库功能, 获取到功能模块的公共对象和私有对象, 并提供增加、删除、修改功能对对象进行维护。然后业务测试人员使用可视化界面, 根据业务流程将所需的对象加入到左侧列表, 输入步骤名称, 选择方法并设置参数名称。脚本开发人员对方法进行编码, 两者同步进行。完整业务流程测试脚本必须包含该业务所有的业务步骤, 在被测试用例引用时, 进行必要的裁剪, 最大化复用测试脚本。脚本创建完成后以XML文件保存。

3.2 测试用例

自动化测试引擎工具的测试用例是基于业务场景的一系列测试用例集合, 如图3左侧所示。业务测试人员创建一个业务回归测试场景, 并创建用于覆盖此场景所需的用例。测试用例遵循关键字驱动和数据驱动原则, 由脚本和数据组成, 如图3右侧所示。在用例维护界面, 维护该用例用于执行的脚本和数据。首先选择该用例需要的脚本文件, 载入关键字并进行裁剪, 输入参数化数据完成测试用例创建。测试用例以XML文件保存在本地。同时, 测试用例模块提供增加, 修改, 删除功能业务场景和测试用例进行维护。

3.3 测试执行

测试执行任务按回归测试轮次划分。每个测试任务由一个或多个测试场景组成, 场景覆盖本轮测试所有业务流程。测试场景准备完毕后, 运用脚本解释器调用QTP接口, 执行测试用例。执行过程支持断点续跑, 当某个场景无法执行或执行失败时, 自动执行下个场景。对失败的测试用例, 可以单独执行。针对每个用例, 全面记录产生的过程数据、步骤数据、输出数据及结果数据, 为测试总结报告提供基础。

4 结束语

本文介绍的自动化测试引擎工具, 是基于QTP二次开发的一套业务流程自动化测试框架, 是一系列自动化测试策略、思想、规范和代码的集合, 把自动化测试的策略和思想进行了代码封装, 完成了以底层编码为主向侧重业务过程的转变。实践证明, 该框架有效的降低了自动化测试的难度, 提高自动化测试复用度和应用可行性, 为自动化测试的实施提供了新的途径。

摘要：金融系统有着较复杂的业务流程和业务规则, 随着业务的不断扩展, 软件持续迭代, 系统越来越庞大。金融市场瞬息万变, 为了快速响应业务需求, 这就要求系统的回归测试能够快速完成。为了解决大量重复的回归测试, 结合金融系统测试的特点, 基于Quick Test Professional (以下简称为QTP) 工具的功能, 研发业务流程自动化测试工具及框架, 为回归测试提供解决方案。实践表明, 该自动化测试工具易于维护, 成本低, 使用简单, 有效地提高回归测试效率。

关键词：自动化测试工具,回归测试,测试引擎,业务流程

参考文献

[1]接卉, 兰雨晴, 骆沛.一种关键字驱动的自动化测试框架[J].计算机应用研究, 2009, (3) :927-929.

[2]许丽花.QTP在Web自动化测试中的应用[J].电脑知识与技术, 2010, (33) :9440-9441+9444.

[3]符瑞秋.QTP在国家科技计划预算管理系统测试中的应用[J].信息安全与技术, 2015, (4) :85-87+90.

产品测试流程 第2篇

需求分析由产品人员制定，他们要做的不是一份简单的文档，而是细化每一个功能的细节，每一个按钮的位置，对于稍大或复杂一点的需求都进行建模。

需求评审

需求评审（产品需求人员、开发人员、测试人员、设计人员）前期需求进入会大大增加测试人员对产品的功能的整体把握，现在测试人员担任的是测试和产品体验员的身份。测试人员提出需求，开发人员考虑功能实现的方案与可行性、当然开发负责也是要参与的。测试人员主要是对需求的理解提出疑问，以便才能根据需求写用例。QA人员是最终对软件质量进行验证的人，所以也需求了解需求。

开发人员编写排期

开发人员需求根据需求功能点进行排期。然后将开计划转交给测试人员。

测试计划排期

测试人员根据开发计划，对测试具体测试时间，也就是开发功能完成后的时间，进行几轮测试等。然后，把项目的开发与测试计划发送给各部门负责人及参与项目的所有人员。

编写测试用例

根据详细的需求分档，开始进行用例的编写。

【开发人员写开发计划--》测试人员编写测试计划--》邮件通知所有人员及部门负责人。】

用例评审

在用例进行评审之间，先以邮件形式将用例发送给相关人员，以便他们事先了解用例对哪些功能进行验证以及验证的细节。

然后，测试人员组进行用例评审，开发人员对用例与实际功能不符合有哪些，产品人员对会通过用例对功能的具体实现进行把握等等。

【测试用例评审（产品需求人员、开发人员、测试人员、QA人员）】

提交基线

开发人员完成所有功能后，会对自己的功能进行一个自测。自测完成后提交测试人员进行基线。【开发代码及自测---》编写测试用例】

具体测试流程

开发人员对于基到测试线的功能进行测试，发现的问题通过缺陷管理工具进行反馈，开发人员对问题进行修复，然后，准备第二轮测试。

测试人员完成第一轮测试后，需要写测试结论，发到相关人员。然后对基线后的第二轮进行测试，第二轮会对第一轮中发现的问题进行重点回归。

测试具体流程如下：

1、测试和发现软件中存在的软件缺陷

使用各种测试技术和方法来测试和发现软件中存在的软件缺陷。测试技术主要分为黑盒测试和白盒测试两大类。

其中黑盒测试技术主要有等价类划分法、边界值法、因果图法、状态图法、测试大纲法以及各类典型的软件故障模型等;白盒测试的主要技术有语句覆盖、分支覆盖、判定覆盖、基本路径覆盖等;

2、测试工作需要贯穿整个软件开发生命周期

完整的软件测试工作包括单元测试、集成测试、确认测试和系统测试工作。

单元测试工作主要在编码阶段完成，由开发人员和软件测试工程师共同完成，其主要依据是详细测试。集成测试的主要工作测试软件模块之间的接口是否正确实现，基本依据是软件体系结构设计。确认测试和系统测试是在软件开发完成后，验证软件的功能与需求的一致性、验证软件在相应的硬件条件下的系统功能是否满足用户需求，其主要依据是用户需求。

3、缺陷报告编写及提交

测试人员将发现的缺陷编写成正式的缺陷报告，提交给开发人员进行缺陷的确认和修复。缺陷报告编写最主要的要求是保证缺陷的重现。要求测试人员具有很好的文字表达能力和语言组织能力。

4、软件质量分析

测试人员需要分析软件质量。

在测试完成后，测试人员需要根据测试结果来分析软件质量，包括缺陷率、缺陷分布、缺陷修复趋势等。给出软件各种质量特性包括有功能性、可靠性、易用性、安全性、时间与资源特性等的具体度量。最后给出一个软件是否可以发布或提交用户使用的结论。

5、测试计划制定

测试过程中，为了更好地组织与实施测试工作，测试负责人需要制定测试计划，包括有测试资源、测试进度、测试策略、测试方法、测试工具、测试风险等。

6、测试用例报告形成测试人员为了更好更有效地进行测试，保证测试工作质量，需要在执行测试工作之前首先需要设计测试用例，形成测试用例报告。设计测试用例是保证测试质量的核心工作，很多测试技术都可以用来指导设计用例。

7、自动化测试工具引进

为了提高工作效率或提高测试水平，测试工作需要引进自动化测试工具，测试人员需要学会使用自动化测试工具，编写测试脚本，进行性能测试等。

8、测试水平提高

测试负责人在测试工作中，还需要根据实际情况不断改进测试过程，提高测试水平，进行测试队伍的建设等。

缺陷管理

使用bug缺陷管理工具，redmine项目管理，通过测试对发现的问题提交到redmine上并进行跟踪。视情况可以将比较简单的bug直接对接开发人员，通过当面交流的方式阐明简单bug的问题所在，提高开发人员修复bug的效率，同时要在redmine上做好bug记录，发布测试新的版本的时候复测问题。

测试管理

经过两到三轮或四轮的测试后，直到没发现新的问题，或暂时无法解决，或不紧急的问题。通过上级确认，可以通过。编写测试报告与验收方案。

验收方案是交由QA进行验证的。在现公司的流程中是将测试与QA分开的，测试人员重点关注的是功能是否可以正常运行。QA关注的是整个流程的质量以及最终用户的质量。有些公司QA与测试是不区分的，但这对测试的要求会更高，除了关心功能，还需要关心整体流程与质量。

上线后测试

海上测试流程地面管线选型 第3篇

本文所指的“常规“指的是非高温高压、非高产、非加砂压裂井及硫化氢/二氧化碳井。

常规地面测试流程从压力等级上分, 流程主要以油嘴管汇为界分为上游高压流程部分及下游低压流程;从功能上分, 流程主要分为高压流体控制流程、低压流体处理及安全泄压流程。

上游高压流程包括但不限于地面测试树、地面安全阀及油嘴管汇等设备;下游低压流程包括但不限于蒸汽换热器、三相分离器、密闭罐、计量罐、平台固定油气分配管汇、平台固定油气管线及燃烧臂等设备;地面辅助流程包括但不限于锅炉、压风机、输油泵、数据采集系统、喷淋冷却系统等设备。

常规条件下, 油嘴管汇下游的管线宜采用内径为2.3英寸的公称通径为3寸的Weco Union 1502管线, 油嘴管汇下游的管线宜采用内径为2.75英寸的公称通径为3寸的W e c o Union 602管线。

常规海上测试流程见图1:

2 地面管线的连接及密封方式

2.1 由壬连接

由壬 (Weco Union) 连接方式目前是地面测试流程最为常见的临时管线的连接方式, 目前此种连接方式发展出超过十种不同压力等级及用途的接头类型, 其最大工作压力可以达到140Mpa;除Weco Figure 200以外, 其它型号均需橡胶密封元件密封, 其选型见表1:

2.2 法兰连接

法兰连接方式是除了由壬连接方式以外最常用的管线连接方式, 通常用于永久或者半永久测试流程的铺设, 法兰为金属密封;国际上, 对于井口高压流程所用的法兰 (超过35M p a压力等级) , 均应符合A P I 6A标准, 其参数的选择参见API 6A标准;对于低压流程所用的法兰, 均应符合ASME B16.5标准;另外, 法兰管线本身应符合ASME B16.3标准。

2.3 Grayloc及Hub连接

这两种连接方式与法兰连接方式均为金属密封, Grayloc及Hub连接非常相似。相对于法兰连接方式来说, 这两种接头在同等压力等级条件下要远远轻于法兰连接方式, 并具备自密封效果。

3 地面管线的材质

海上测试流程地面管线的材质均应符合NACE MR01-75 (美国腐蚀工程师协会标准) 及等效标准ISO 15156 (国际标准化委员会标准) , 或者GBT 20972 (国家标准) 标准, 此标准规定了石油和天然气工业油、气生产中含硫化氢环境下使用的材料。

对于常用的并符合此标准的碳钢或者低合金钢, 其硬度均不应超过22 HRC;对于管线材质, 适用于高压流程的管线材质以AISI4130 Cr-Mo低合金钢为代表, 适用于低压流程的管线材质以ASME A333 Grade 6或者ASME SA106 Grade B为代表。

4 影响地面管线选型的主要因素与对策

4.1 最高压力与最高温度

通常情况下, 特别是对于气井测试, 最高压力应采用预测最高地层孔隙压力, 最高温度应采用预测最高井口温度;

高压流程地面管线最大工作压力的选择, 通常情况下对需综合考虑, 并采用较高的安全系数, 本文推荐地面管线的额定工作压力应不低于预测的最高地层孔隙压力的1.2倍。若已获得实际最高地层孔隙压力, 则按实际最高地层孔隙压力的1.2倍配置;在实际管线等级选型时, 高压流程地面管线推荐的最小压力等级为70M p a, 若实际计算压力超过70Mpa, 则需在105Mpa、140Mpa及以上压力等级中选取。

高压挠性软管对于海上半潜式平台及深水平台的地面测试流程是必不可少的设备, 用于测试流程高压端, 作为压井管线及流动管线;由于其具备耐高压、耐硫化氢 (Coflon内衬) 的良好性能, 对其使用也必须遵循相应的安全原则:由于软管线的特殊性, 作为流动端的高压挠性软管的安全系数须达到4以上, 即其试验破裂压力应为其最大允许使用压力的4倍以上;高压软管在运输与使用过程需注意其最小弯曲半径及对其接头的保护, 否则会大大降低其试验破裂压力, 从而减低其工作压力等级。

对于地面测试设备工作温度的选择, 通常情况下选定地面管线最大工作温度不低于预测井口温度的1.1倍;但应注意, 因为在高温条件下, 密封橡胶件的老化速度加快, 因此对于有可能出现井口高温 (譬如:大于100摄氏度) 的非常规井, 则需考虑地面管线采用何种密封方式;对于高温高压井, 测试流程地面管线首选金属密封方式。

4.2 硫化氢及二氧化碳

由于硫化氢及二氧化碳极易使橡胶密封件失效, 并使金属发生电化学腐蚀甚至氢应力腐蚀开裂, 对于硫化氢 (流体含量大于10P P M) 及二氧化碳井 (体积浓度大于4%) , 本文推荐井口高压流程采用金属密封方式的管线连接, 即采用法兰连接、Groyloc或者Hub连接方式。

4.3 地层出砂

在严重的情况下, 地层出砂会导致地面管线的刺漏及引起严重的安全事故, 因此对于测试过程中的出砂可能性, 测试流程部分必须对管线进行优化及监测, 具体原则如下:

在高压流程上安装实时含砂监测系统。

流程上的直角部分采用加厚弯头代替常规弯头, 以增加安全系数, 并定时对拐角弯头壁厚测量, 防患于未然。

流程尽量平直, 减少拐弯, 以减弱流程上可能出现的沉砂。

地面管线内流体流速大于3米/秒。

管线内最大允许流速

天然气在管线中的最大流速不能超过管线的最大允许流速umax, 随着天然气产量的产量的增加, 对于一定内径的天然气管线来说, 天然气的流速随之增加, 流速增加到一定的数值后会引起管线的震动及噪音, 在经过一定的时间后, 会对管线壁厚产生冲蚀作用。

另根据《API RP 14E Recommended Practice for Design and Installation of Offshore Production Platform Piping Systems》的推荐, 为了避免可能存在的管线冲蚀, 对于气井的最大流速不应超过150英尺每秒。

5 现场实例

实例:以预测最高产量为35MMscf/D的气井为例, 预测最大产量条件下井口压力为3000Psi, 井口温度为140华氏度, 天然气比重为0.65, 硫化氢含量小于10P P M, 对地面管线进行选型如下:

流程管线符合NACE MR01-75的要求;

根据井口预测最大工作压力, 选择最大工作压力10, 000Psi, 工作温度-20～250华氏度的井口设备;

考虑到硫化氢含量较小, 选择W e c o Union连接方式, 注意采用防硫由壬密封垫圈;

通过计算油嘴管汇上游流速, 油嘴管汇上游管线选择3寸公称通径;油嘴管汇下游管线宜选择4寸公称通径, 特别是分离器天然气管线应选择4寸公称通径到燃烧臂;

根据地层情况, 选择是否采用除砂器并对整个流程管线采用防砂设计。

摘要：地面试油流程作为油气井测试一个重要组成部分, 其管线的选型及校核对测试顺利进行起着重要的保障作用。本文从地面管线的密封方式、压力温度等级、材质等方面进行选型, 目的是指导对于特殊作业井, 譬如高温高压井、硫化氢/二氧化碳井及加砂压裂井。

关键词：测试流程,高产气井,酸性环境,材质,安全泄压

参考文献

[1]D-SR-007《Well Testing Systems》.

[2]朱克祥.气井试气地面流程.江汉石油职工大学学报, 2008年7月21卷4期.

自动化测试流程 第4篇

一、实验过程

1.1连通攻击机与靶机。在Parallels Desktop虚拟机环境中, 安装Back Track5系统的攻击机与Metasploitable Ubuntu系统的靶机, 靶机中含有Samba服务漏洞。两台虚拟机通过桥接方式连接到虚拟网络, 在命令行界面中输入以下命令释放ip并获取新ip:

dhclient-r

dhclient

通过ifconfig命令查看攻击机与靶机的ip, 确保两台虚拟机在同一个网段中。实验中攻击机与靶机的ip分别是192.168.1.103与192.168.1.106

1.2对靶机发起渗透攻击。在Back Track5攻击机的命令行窗口中, 输入msfgui命令进入Metasploit的图形界面。在菜单中依次点击exploits--multi--samba--usermap_script, 在弹出的对话框中进行渗透攻击配置。与本次实验相关的配置主要有:1) 攻击载荷:在payloads的下拉选项中选择bind_netcat, 该攻击载荷用于在渗透靶机后将shell绑定到开放端口。2) 目标主机IP:在RHOST文本框填写靶机ip (192.168.1.106) 。

点击Run Exploit按钮开始渗透攻击, 成功渗透后, 在session标签中可看到对应内容。

1.3取得靶机的root权限。在session标签界面中选中已控制的靶机, 右键点击并选择Interact, 如图1所示。

之后在shell标签界面中输入命令, 确认获取了靶机的root权限, 如图2所示。

二、结语

实验在虚拟机环境中连通了攻击机与靶机, 并通过Metasploit图形界面对含有samba漏洞的靶机进行了一次完整的渗透测试。通过本次实验, 对渗透测试的流程----选择目标、渗透攻击、注入攻击载荷、获取root权限、控制目标主机, 有了整体性的认识。也对基于Metasploit渗透攻击的主要参数RHOST、payload有了直观认识。同时, 虚拟机实验环境的搭建为后续的Metasploit渗透测试研究打下基础。在后续的研究与实验中, 将重点关注不同网络拓扑结构下的渗透测试方法与技巧。

参考文献

[1]诸葛建伟, 陈力波, 等.Metasploit渗透测试魔鬼训练营[M].机械工业出版社, 2013.

信息安全渗透测试流程的研究 第5篇

为了保证网络系统的安全可靠, 人们经常通过渗透测试来模拟黑客的攻击来评估网络系统的安全性。渗透测试人员在不同的位置 ( 比如从内网、从外网等位置) 利用各种手段对某个特定网络进行测试, 以期发现和挖掘系统中存在的漏洞, 然后输出渗透测试报告, 并提交给网络所有者。网络所有者根据渗透人员提供的渗透测试报告, 可以清晰知晓系统中存在的安全隐患和问题。

依据《辽宁省公路水路信息化发展指导意见》, 将为全省交通行业信息化提供完备的基础设施支撑, 辽宁省交通厅云数据中心基础设施平台在2015年启动建设。为了解决辽宁省交通厅尤其是云数据中心面临的安全问题, 辽宁省云环境下交通信息安全策略研究课题以辽宁省交通行业重要信息系统为对象, 分析其面临的信息安全问题与挑战, 以提升辽宁省交通行业现有信息安全水平。辽宁省云环境下交通信息安全策略研究课题研究的重点包括设施云安全技术标准、渗透测试检查标准、辽宁省交通厅信息系统安全管理体系和云安全策略管理软件。其中, 渗透测试检查标准的编制目的是为指导和规范针对辽宁省交通行业信息系统的渗透测试工作, 明确了渗透测试的基本概念、原则、实施流程、在各阶段的工作内容和基本要求。

本文提出了一个包括渗透测试准备阶段、信息收集阶段、渗透攻击阶段、风险分析阶段、整改阶段和报告编写等6 个阶段的信息安全渗透测试流程和各阶段工作内容。

2 渗透测试流程

如图1 所示, 渗透测试过程应该包含准备阶段、信息收集阶段、渗透攻击阶段、风险分析阶段、整改阶段和报告编写等6 个阶段。以下是各阶段工作基本要求:

( 1) 准备阶段: 双方确定测试方案, 确定项目人员等信息;

( 2) 信息收集阶段: 针对测试对象进行安全相关的信息收集, 为之后工作提供重要依据;

( 3) 渗透攻击阶段: 在信息收集的基础上进行有针对性地、有次序地、有重点地测试;

( 4) 风险分析阶段: 对渗透攻击发现的漏洞和隐患做进一步分析, 明确漏洞和隐患可能导致的风险, 并评估风险级别;

( 5) 整改阶段: 将风险分析阶段发现的不可接受风险进行整改;

( 6) 报告编写阶段: 完成文档和报告。

2. 1 准备阶段

渗透测试的准备阶段应明确渗透测试的目标, 即通过渗透测试能帮助用户发现信息系统的问题类型, 以及预期达到的目标, 从而为渗透测试的过程提供导向。渗透测试的准备是整个渗透测试过程有效性的保证。组织实施渗透测试是一种战略性的考虑, 其结果将受到组织业务战略、业务流程、安全需求、系统规模和结构等方面的影响。因此, 在渗透测试准备阶段应明确如下要素:

(1) 渗透测试目标;

(2) 渗透测试范围;

(3) 渗透测试团队;

(4) 渗透测试方法;

(5) 过程沟通机制;

(6) 风险规避及应急;

(7) 操作方案制定;

( 8) 双向责任书。

2. 2 信息收集阶段

信息收集是渗透测试工作中必不可少的阶段, 也可以说是整个渗透测试成败的关键, 信息搜集阶段要尽可能多的搜集到与系统相关的信息, 可以借助自动化扫描探测工具和手工收集等方法, 至少要获取但不限于如下信息:

负责测试的人员需要通过交流或者文档的方式, 收集关于: 机房的物理位置, 网络分布图, 业务情况, 业务伙伴, 物业服务轮廓图, 会议安排, 关键日期等信息; 对于员工尤其是关键员工需要收集其履历背景, 社交关系网, 互联网足迹, 博客, 最新动态, 物理位置, 移动足迹, 工资银行帐户等个人信息。

了解信息系统业务的客户范围, 并且建立目标列表, 包括:

( 1) 确定各个系统版本信息, 包括: 业务系统服务器, 数据库服务器等相关系统的版本信息;

( 2) 识别补丁级别, 并且找到没有安装补丁的过时系统;

( 3) 识别系统的错误信息。

对于漏洞探测可以进行主动探测和被动探测。主动探测可以包括主动自动化探测和手工探测。在主动自动化探测方面, 可以通过端口以及服务的扫描获得相应漏洞信息; 对于应用程序也可以通过自动化探测软件对于通用的应用层漏洞扫描、目标列举和暴力破解, 应用服务版本和漏洞识别等进行漏洞探测; 还可以通过网络漏洞扫描器对于VPN或者IPv6等网络进行漏洞探测。主动手工探测可以对于一些针对性链接进行手工漏洞探测。被动探测主要是对于从内部获取的元数据和流量数据进行漏洞探测。

2. 3 渗透攻击阶段

根据收集的漏洞信息, 在没有防御措施的情况下, 对其进行相应的攻击。在有防御措施的情况下, 对于漏洞进行渗透攻击。包括反病毒攻击 ( 加壳, 白名单绕过, 进程注入, 纯内存方式等) 、人工检查、网络入侵防御系统 ( FW/WAF/IDS /IPS) 、应用防火墙和栈保护等。

2. 4 风险分析阶段

风险分析阶段是针对渗透测试过程中发现的漏洞和隐患, 进行后果和影响分析的过程。要对发现的漏洞充分分析其产生的根源, 以及分析它的发生原理, 对整个组织业务层面危害的程度。当信息搜集和分析完成后, 风险就可以评价了, 在这种评价当中, 使用“可接受风险”、“不可接受风险”或其他类似的术语。另外, 风险级别可分为“高”、“中”、“低”或“一般”等程度。

2. 5 整改阶段

被测方对发现的不可接受风险进行修补, 解决发现的安全隐患。测试方要将发现的问题通告给相关人员, 其相关人员可以对发现的问题进行质询, 在问题得到确认后, 要在问题确认单上签字。被测方对发现的问题进行限期的安全整改工作, 弥补系统中存在的薄弱环节, 并在安全整改完成后要向测试方提交整改报告, 包括整改证据如配置截图等。如测试方针对整改第二次测评, 应以第二次测评编写最终的渗透测试报告, 并对整改情况进行说明。

2. 6 报告编写阶段

渗透测试报告是交付给用户的最终成果。报告内容应该通俗易懂, 突出重点, 恰当地提及到测试中发现的所有风险点, 具体内容应该包含但不仅限于如下内容:

( 1) 识别系统性问题和技术根源分析;

( 2) 渗透测试评价指标 ( 包括: 范围内的系统数量, 范围内的应用场景数量, 范围内的业务流程数量, 漏洞/漏洞主机数量, 被攻陷的系统数量, 成功攻击的应用场景数量, 攻陷的业务流程次数等) ;

( 3) 技术发现 ( 包括: 描述, 截图, 抓取的请求与响应, 概念验证性样本代码) ;

( 4) 可重现结果 ( 包括测试用例和触发错误) ;

( 5) 应急响应和监控能力 ( 信息收集阶段、漏洞分析阶段、渗透攻击阶段、后渗透攻击阶段和其他方面) ;

( 6) 标准组成部分 ( 方法体系、目标、范围和风险评定的术语附录) ;

( 7) 对发现的安全漏洞给出的修复建议, 要注重测试建议的可操作性;

(8) 风险总体分析;

(9) 渗透测试结论;

( 10) 如果存在整改阶段, 应该附上整改报告。

3 结论

浅析软件系统性能测试流程规划 第6篇

随着现代软件构架技术的发展,特别是WEB技术的发展,各种软件在系统实施过程中,需要满足客户的一些特殊要求。如果软件系统没有经过测试和优化,软件系统将无法满足用户的需求,还会给软件在实际应用中带来很大风险。软件系统性能问题越来越受到开发商、最终用户的重视。

性能测试包括3个方面:一是用于测试系统在正常的预期工作量以及所指定的事务或业务功能情况下的响应、时间、事务处理速率和其他与时间相关的需求;二是用于验证系统在不同工作量条件下的性能行为以及持续正常运行的能力;三是重复运行测试,验证调整系统的活动得到了预期的结果,从而改进性能。

本文主要针对性能测试流程规划中应把握的几个重点步骤进行讨论,如测试前期准备、测试导通、实际测试、性能调优与反复测试等。

二、系统性能测试流程

整个测试流程大致可以划分为:测试前期准备、测试导通、实际测试、性能调优与反复测试,直至系统性能达标为止。针对上述流程,做如下说明。

(一)测试需求分析

测试需求分析阶段的主要目标是被测试的各个系统,了解以下主要内容,为后期的测试工作做准备。具体包括:①测试目的——性能指标如何描述、性能测试结束的标志是什么等;②整个测试环境的体系结构及详细描述,测试环境的网络协议有哪些,具体连接方式如何;③测试环境中相关软件的版本详细情况,如OS、DB、Middle Ware等;④测试中关键点、难点判断分析;⑤应用软件的开发工具情况;⑥测试用例有哪些,配比如何。针对该部分,重点分析是否可测、存在难点等问题。

(二)组织与人员确定

组织与人员确定阶段主要是由甲乙双方根据后期即将展开的测试工作,确定测试人员的组织情况、人员分工情况,确定各自的职责范围,为后期工作打下基础。

建议将参加测试的工作人员按工作内容分为技术支持与优化、方案与测试实施两个小组,其职责分工如下。

1. 技术支持与优化小组

负责测试环境的搭建、安装,测试所需基础数据和交易数据的准备,主机、数据库、中间件的配置和调优。

2. 方案与测试实施小组

负责测试方案的编写、测试过程记录等测试实施工作。

上述两个小组应由甲乙双方协调,确定小组负责人、小组成员人选,并根据实际情况,在不影响相关工作进度的情况下进行兼职,人员分工可交叉。

(三)编写测试方案

该阶段的主要任务是:由相关人员参与,针对各个被测系统的测试目的、测试内容编写测试方案、测试计划等。测试方案中,应包括主要测试目标描述、测试硬件环境说明、测试软件环境说明、测试的基础数据、测试的交易数据、测试案例及交易配比说明、测试方法说明、测试进度安排、相关的测试记录表格说明等主要内容。

(四)测试导通

测试导通阶段的主要任务是:针对被测系统已经选定的测试案例,从使用自动化测试工具角度,进行测试的相关准备,保证测试使用的脚本正常运行、测试用数据准备正确、测试涉及的交易能够正确导通、相关的参数收集方法确定等目标的实现。

该阶段最鲜明的特点是相当于预测试。测试的环境并非一定要求是实际测试的真实环境,可以在临时搭建的环境中完成导通工作。因此,该阶段在对测试环境的配置要求上可以低一些,但配置的操作系统、数据库、中间件等软件支撑环境应尽量保持与真实测试环境一致。

测试导通阶段的主要任务包括:①测试导通环境的搭建——网络环境、操作系统、数据库、中间件、应用程序等;②测试脚本录制、调试;③测试脚本用数据种类、规格、数量、生成方式确定;④测试脚本用数据的生成;⑤垫底数据种类、规格、数量、生成方式的确定;⑥测试启动数据准备—种类、规格、数量、生成方式的确定(针对某些交易的测试,需要一些前导交易运行,产生一定量的数据之后,才能继续进行测试。这些前导交易生成的数据称为测试启动数据,他们与测试脚本用数据、测试垫底数据存在一定的逻辑约束关系);⑦测试启动数据的生成;⑧垫底数据、测试启动数据、脚本用数据的逻辑正确性校验;⑨负载模式确定;⑩脚本中相关计时器、各种参数的设置及合理性分析;(11)参数收集方法确定及相关准备,如打开相关服务、相关权限设置、打开防火墙的一些设置等;(12)相关衍生辅助工具的定制;(13)结果分析准备——相关性能参数的解释与出处的搜集、整理,如CPU、Memory、DisklO、DB、Middle Ware等;(14)测试文档的命名方式、存档方式确定等。

(五)实际测试准备

在测试导通完成后,即可开始为实际测试进行准备。此时,作为被测的软件系统在功能上已经进入比较稳定的阶段,但在性能上还必须经过严格的性能测试和反复的性能调优,以达到性能优化的目标。

在测试的实际准备阶段,主要是针对实际的测试环境,进行相关的测试准备。主要内容包括:①实际测试环境搭建——网络环境、操作系统、数据库、中间件、应用程序等;②测试用机环境搭建——该任务是针对测试工具所使用的环境进行准备;③垫底数据准备—按照已经确定的垫底数据的种类、规格、数量、生成方式等在实际环境中生成垫底数据;④测试启动数据准备——按照已经确定的测试启动数据的种类、规格、数量、生成方式等在实际环境中生成为测试启动数据;⑤在实际环境中,完成收集性能参数的前后端相关设置,如OS、DB、Application Server、Middle Ware等;⑥被测应用就绪状态确认,指应用的功能测试通过正确安装配置。

(六)性能实测

性能实测阶段的主要任务是:在真实的测试环境中,使用自动化性能测试工具,按照测试方案的要求,针对每个测试案例,按照其要求的交易配比关系、压力负载模型、网络连接状况等要求,模拟真实环境产生压力负载,同时,收集系统各方面的性能参数,测试系统性能情况,由自动化测试工具产生系统的性能报告。

与此同时,还要监测系统的运行状况,随时处理各种突发事件。

(七)报告整理

在性能测试的实测阶段,测试工具会自动产生详细的测试报告,该测试报告作为原型报告,还需要进一步整理,按照测试方案确定的表格形式填写相关内容,整理测试记录,对主要参数进行分析并对相关结果进行解释、说明,然后进一步提出优化建议。

在该阶段会将上述内容整理,提交本轮测试报告。

(八)性能调优

该阶段的主要任务是:针对性能测试的结果进行分析,查找出性能的瓶颈所在,进行性能调优。调优的主要方向分为代码调优和参数配置调优。

代码调优主要是进行程序代码的优化,需要由开发商进行;参数配置的调优主要是针对系统运行环境的软、硬件参数进行一系列的调优,包括硬件参数、操作系统、数据库、中间件等。

(九)性能调优后测试准备

在性能调优工作之后,还需进一步进行性能测试,以确认调优工作是否有效。此时,需要进行相关的准备工作。准备工作依据调优内容的不同进行相应调整,主要内容包括:①如果发生了源代码修改,则须进行测试导通过程中的相关准备工作并按照测试流程进行后面的工作;②如果只是参数配置发生变化,则须进行实际测试准备阶段的各项准备工作,并按照测试流程进行后面的工作。

(十)提交正式报告

在经过反复性能测试与调优之后,确认被测系统已经达到性能指标要求或明确无法达到指标要求时,即可确认性能测试结束。此时,应提交正式测试报告。

(十一)资料归档

将整个测试工作的各种文档,包括需求分析文档、各种测试脚本、自动化测试工具生成的测试报告以及每一轮的测试报告等,进行整理,统一归档,并提交乙方。

三、某大型应用系统性能测试流程规划

某省中心业务系统性能测试是在统一版本省中心业务系统上线之前,对系统性能(主要包括实时联机性能和日终批处理能力)能否满足设计要求的测试。

性能测试针对生产机型,分别在应用服务器和数据库服务器物理分离、应用服务器和数据库服务器使用同一主机两种结构模式上进行。测试主机分别在正常工作情况、不同负荷情况下、超常负荷下的各项性能指标。

性能测试前和测试过程中要对操作系统参数、数据库参数、中间件参数等进行适当优化调整,使系统的性能达到最优状态。

通过压力测试软件模拟网点、外围接入系统(A,TM、POS、中间业务)、银联中心、全国中心产生各类联机交易,对省中心系统进行联机交易压力测试,同时对系统的批处理能力进行测试,测试应用软件在大量交易的压力下是否能够正常处理,是否能够达到相应的性能指标,确保应用软件上线之后平稳高效地运行,以达到预期的质量要求。

测试指标项包括系统每小时最大的联机处理能力、系统每秒最大的联机处理能力、交易成功率、单笔交易响应时间、日终批处理时间等。

测试的网络环境虽然在局域网内进行,但要考虑用测试软件对广域网的情况进行模拟，并对测试结果进行对比和分析。

测试内容包括3个方面:①正常工作情况下,各项性能的指标;②不同负荷情况下,每笔交易的响应时间,以及主机在不同负荷情况下系统资源的占用情况;③测试主机在超常负荷下的各项性能指标。

具体网络连接见图1和图2。

日间联机处理测试的范围包括与网点、全国中心、渠道接入、中间业务等系统的交易。

主要测试步骤为:①搭建省中心性能测试环境,包括省中心系统、测试工具和其他仿真系统;②按照本省业务量准备垫底数据，可采用数据移植形成的数据;③按照本省实际准备标准数据;④使用测试工具进行交易导通;⑤使用测试工具,按照测试步骤进行测试导通;⑥确定压力测试模型;⑦使用测试工具,执行测试脚本,仿真各相关系统发起压力;在测试过程中检测主机资源使用情况;⑧测试完成后,使用压力测试工具形成测试报告;⑨变换压力测试模型,重新进行测试。

部分测试结果见表1。

本次省中心业务系统日间联机性能测试是在新购主机上进行。从测试结果看,省中心业务系统忙时处理能力最好能达到49.7万笔/小时,可以满足设计指标。

四、结束语

机场行李处理系统始发流程测试探讨 第7篇

关键词：行李处理系统,测试方法,始发流程,测试场景

1 机场行李处理系统的子系统组成及始发流程

机场行李处理系统是航站楼内对于旅客交运行李进行处理的一套复杂机械和电控系统。通常由以下子系统组成：值机岛子系统、到达子系统、中转子系统、早到储存子系统、分拣子系统、大件子系统、安全检查子系统等。这些子系统的组合组成了多个行李流程，包括：始发行李处理流程（简称始发流程）、到达行李处理流程（简称到达流程）、中转行李处理流程（简称中转流程）、早到行李处理流程（简称早到流程）等。

始发流程中典型节点设备包含值机输送机、安检输送机、过渡输送机、收集输送机、开包间前分流器、输送机、分拣机（可选）、离港转盘。主要流程如图1。

在旅客将行李在值机柜台托运后，行李经过收集输送机称重、贴标签，安检机安全检查（有时后场检查），按照“窗口技术”送至收集输送机，通过水平分流器进行安全/可疑行李的初步分流，安全行李输送至行李房，经过分拣机自动分拣，或点对点直通到达行李离港转盘；可疑行李开包检查，检查为安全的行李送回系统，问题行李则移交公安机关。本文就始发行李点对点直通的流程测试进行详细介绍。

2 测试思路及重点难点

测试思路：依据上述始发行李点对点直通流程，明确测试目标，针对始发行李流程中某条始发输送线，明确流程中的测试重点及难点，并制作测试表，形成完整的测试内容，根据实际检测列出准备工作、配置资源等成功操作项目的措施。本测试中重点设备：值机柜台（称重输送机、安检输送机、过渡输送机）、收集输送机、水平分流器、离港转盘、行李控制室。技术难点：窗口技术。

3 始发行李点对点直通流程测试大纲

1）测试目标：检测始发行李点对点直通正常流程和相关的重点及难点的功能。

2）测试条件：测试所涉及的设备的机械和电控状态均正常，值机柜台、安检机、收集输送机、水平分流器、离港转盘都可用。

3）测试的行李系统资源

通过图2，可详细说明场景流程-资源的关系，并选择相关资源进行测试。

例如始发行李点对点直通流程，选定C0n号值机岛，就确定了输送路由，确定了输送线编号PLC0 n，以及和离港转盘编号Mxx。在检测大纲中简化成“场景-资源”表，同时同一场景在其他不同的设备区域测试时与此步骤相同。下面将举例说明“直通”和“分拣”2类流程的“场景-资源”明细表（表1、表2）。

4 场景测试功能

始发行李点对点直通线场景测试的功能围绕着重点设备进行检测，包含功能：（1）托运行李的值机功能；（2）柜台行李标签手持扫描仪功能手持扫描；（3）安检功能；（4）收集输送机“窗口”功能；（5）可疑行李跟踪、开包间的行李分流功能；（6）离港装卸转盘的功能。由于在检测过程中，遵循单项功能测试纳入场景的原则，将启动和节能以及噪音检测纳入场景中，也不干扰场景测试结果。针对每项功能的测试，建立相应的测试表，将操作步骤和预期结果列出，便于各个节点的测试员能核对和填写。举例见表3。

以值机、手持条码扫描和安检功能测试为例，介绍测试记录表的设计思路，见表4。

由于值机岛有多个值机柜台，测试时每个值机柜台都需要有检测人员进行观察记录，每个柜台都要投放几十件行李，因此设计补充附表（表5），目的是让每个检测员针对每件行李投放输送时，系统的状况都有所记录，保证不漏任何细节。

5 本场景测试设计

在测试前一天需要准备的工作：

1）与航班信息系统接口———航班计划及资源计划准备

集成系统按照以下要求提前生成航班计划及资源计划，并下达给行李系统。行李系统应提前确认航班计划及资源计划正确接收到。

2）与离港系统接口--行李标签及BSM报文准备

离港系统按照以下要求提前打印行李标签，并生成BSM报文发送给行李系统。行李系统应提前确认BSM报文正确接收到。见表6示例。

3）行李准备

确定使用行李的尺寸、数量、种类等。测试前按照规划好

的行李贴好行李标签、放置可疑物品、放置在值机柜台位置。见表7示

根据测试功能来计算行李配置各类行李的数量。其中可疑行李依据开包率占常规行李(X)的10%左右。本场景要纳入节能和超规格行李值机测试，则增加1件常规行李用于节能测试，增加几件大件行李用于超规格测试。

4）人员安排及岗位分配建立

关键设备位置配置人员的

情况，需要人员提前熟悉岗位环境及相应测试表格，同时手持测试设备上岗。具体清单见表8，岗位职责描述见表9。

5）测试步骤

(1）测试前检查

(1)检查每个值机柜台前的行李数量；

(2)所测试值机柜台、安检机、输送机、分流器机械和控制条件具备，设备可用；

(3)所有设备无故障；

(4)所有急停按钮都未被按下。

(2）对讲机确认人员到位情况，人员检查负责区域的测试条件，并且准备好相应记录表，等待指令。

(3）对讲机确认人员就位，各个值机柜台按照正常值机流程办理值机手续，将X件常规行李倒入行李系统。各岗位记录人员监督操作员投放行李是否规范，同时记录测试结果。

(4）在常规行李(X)件都离开收集输送机后，将靠近开包间的最后一个值机柜台旁的1件常规行李进行值机，用于节能测试。

(5）在靠近开包间的最后一个值机柜台上对超规格的行李进行测试。

6）测试结果统计分析

汇总值机柜台处检测人员、开包间处检测人员及离港装运转盘处的记录的表格后，与行李监控系统SCADA记录结果和安检系统的安检记录结果进行比较分析。对出现的问题，列出问题清单，积极整改。

6 结语

本文中所介绍的始发流程测试方法是通过规划一个测试场景来完成行李处理系统中始发流程中典型环节的测试工作,此测试方法在上海虹桥综合交通枢纽工程的行李处理系统测试中得到成功应用。虹桥综合交通枢纽体量大,行李系统分布在交通枢纽和航站楼两部分约为60×104m2的区域。由于各个机场的行李处理系统不完全相同,所以其测试方法也存在多种形式,希望本文介绍的测试方法能够给从事相关工作同人一些借鉴。

参考文献

自动化测试流程 第8篇

目前业界认可度比较高、对WEB应用支持比较好的GUI测试自动化工具有Testcomplete及QuickTest Professional(简称QTP)，后者的应用更加广泛一些，本文将以移动定位平台测试实践为基础，介绍基于QTP的WEBGIS自动化测试方法。

1 GUI测试自动化技术介绍

GUI测试是通过对系统输入不同的测试数据，得到应用反馈来检测该应用程序是否满足功能性要求的测试方式。GUI测试自动化即由机器代替手工敲键盘输入的数据输入方式，提升测试效率，增强测试路径的覆盖。

GUI测试自动化的技术实现基础是UI部件识别，即测试工具或脚本对窗口、图标、菜单等的识别。但是任何一种工具都不可能完全支持对各种应用的测试,所以通常的做法是在借助自动化测试工具录制操作脚本的基础上，根据回放效果及用例设计思路，利用脚本语言完善。

2 移动定位平台产品自动化测试方法

数字城市车灵通移动定位平台基于SOA软件架构设计,是集成地图服务、WEB服务、GPS定位等技术的移动位置服务平台产品,采用了面向服务的WEBGIS架构,并以地图服务为依托,提供车辆定位功能。

使用QTP进行该产品自动化功能测试的流程，分为五个部分：设计测试用例，录制测试脚本，编辑测试脚本，回放测试脚本，查看测试结果。

2.1 设计测试用例

进行自动化测试，首先对需要进行测试的功能点，设计出自动化测试的用例。用例描述功能输入，预期结果，录制的脚本内容，输入参数化，和插入的检查点。以登录、地图平移、地图测距为例，设计出如下的测试用例。

2.2 录制测试脚本表2

测试人员在系统上按照测试用例中的脚本步骤进行操作，QTP的自动录制机制记录下每一个操作步骤及被操作的对象，生成VB语言格式的测试脚本。

2.3 编辑测试脚本

脚本录制完成以后，编辑脚本，进行输入的参数化，以及插入检查点。以登录为例，需要对用户名和密码进行参数化，将参数输入在QTP内置的DataTable中，回放的时候，QTP会运行3次此功能，加载3类参数。同时，插入相应的检查点，检查是否运行结果正确。QTP支持的检查点类型多种，包括文本检查点、图片检查点、数据库检查点等。

2.4 回放测试脚本

QTP脚本完善以后，回放测试脚本。QTP会从脚本的第一行开始执行语句，运行的过程中用实际数据代替参数值，并对设置的检查点进行验证。当验证结果为错误时，在测试报告中记录下来，标明此功能未正确实现。

2.5 分析测试报告

运行测试脚本结束后，系统自动生成一份详细的测试结果报告，包括脚本运行中通过的功能，以及失败的功能。测试人员查看分析测试报告，得出功能回归测试结果。

3 难点和解决办法

车灵通移动定位系统自动化测试过程中，遇到了两大难点：如何识别和录制特殊的web对象和操作，例如地图;如何进行地图操作结果检查。根据这两个难点，分别提出对应解决办法：一是地图对象和操作识别;二是地图对象检查。

3.1 地图对象和操作识别

使用QTP常规录制脚本的方法，无法识别地图对象，也不能录制对地图的操作。我们通过如下步骤解决了此问题：

首先，手动使用object spy(对象识别方法)，识别出地图对象，以及地图对象的操作函数，如图1。默认将地图对象识别为’WebElement’，命名为’objwebcontainer’，包含的函数有CaptureBitmap、Click、Drag、Drop等。

然后,将对象添加到对象库中。

最后，编辑测试脚本。地图的单击、拖动的操作脚本如下：

3.2 检查地图对象

借助图片检查点功能，我们可以实现对地图对象检查的目的，即通过对比脚本执行时截取的图片和目标图片的一致程度，来判断地图服务的相关功能是否正常，具体方法如下：

首先，在编辑录制的脚本中选择合适的位置，插入图片检查点，然后使用对象识别工具，识别系统界面，并选择需要检查的区域，最后，保存QTP自动截屏的目标图片。通常我们会设定3到5秒的超时等待时间，即系统在界面上等待识别的时间。如果超过此时间与目标图片一致或类似的图片依然不出现，即判定为检查点识别失败，实际出现的图片会保存到测试结果报告中。

4 结束语

在数字城市车灵通移动定位平台产品研发、升级过程中，积累了大量可重用的自动化测试场景、用例及脚本，取得了良好的测试效果，目前该系统已应用于勘测、物流等多个行业，并已开展与电信运营商的合作，功能完善稳定，支撑着几千台终端设备的日常运行。

在笔者的其他多个WEBGIS测试中都有类似的GUI自动化测试方法应用，也取得了良好效果。随着自动化测试技术的不断成熟，在以后的WEBGIS项目实施中，自动化功能测试将发挥越来越大的作用。

摘要：该文介绍了WEBGIS软件测试中的自动化测试,以数字城市车灵通移动定位平台产品自动化测试为例,探索了使用QTP进行GUI自动化测试的方法与流程,解决了测试过程中的关键难点,为保障WebGIS平台质量提供了一套自动化的解决方法。

关键词：WEBGIS,地理信息系统,软件测试,测试自动化,WEB测试

参考文献

[1]Li KangLin,Wu Mengqi.图形用户界面测试自动化[M].北京:电子工业出版社,2005.

[2]陈述彭,鲁学军,周成虎.地理信息系统导论[M].北京:科学出版社,2003.

[3]蒋波涛,朱强,钱旭东.WebGIS开发实践手册—基于ArcIMS,OGC和瓦片式GIS[M].北京:电子工业出版社,2009.