本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于web的系统测试方法。/kF?RZNAX4^''''8gnv[本资料来源于贵州学习网计算机网络技术]/kF?RZNAX4^''''8gnv
随着internet和intranet/extranet的快速增长，web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和数据库系统正在被移植到互联网上，电子商务迅速增长，早已超过了国界。范围广泛的、复杂的分布式应用正在web环境中出现。web的流行和无所不在，是因为它能提供支持所有类型内容连接的信息，容易为最终用户存取。
yogeshdeshpande和stevehansen在1998年就提出了web工程的概念。web工程作为一门新兴的学科，提倡使用一个过程和系统的方法来开发高质量的基于web的系统。它"使用合理的、科学的工程和管理原则，用严密的和系统的方法来开发、和维护基于web的系统"。目前，对于web工程的研究主要是在国外开展的，国内还刚刚起步。
在基于web的系统开发中，如果缺乏严格的过程，我们在开发、、实施和维护web的过程中，可能就会碰到一些严重的问题，失败的可能性很大。而且，随着基于web的系统变得越来越复杂，一个项目的失败将可能导致很多问题。当这种情况发生时，我们对web和internet的信心可能会无法挽救地动摇，从而引起web危机。并且，web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。
在web工程过程中，基于web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，internet和web媒体的不可预见性使测试基于web的系统变得困难。因此，我们必须为测试和评估复杂的基于web的系统研究新的方法和技术。
一般软件的周期以月或以年计算，而web应用的周期以天计算甚至以小时计算。web测试人员必须处理更短的周期，测试人员和测试管理人员面临着从测试传统的c/s结构和框架环境到测试快速改变的web应用系统的转变。
一、功能测试
1、链接测试
链接是web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的url地址才能访问。
链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个web应用系统的所有页面开发完成之后进行链接测试。
2、表单测试
当用户给web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
3、cookies测试
cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用cookies访问了某一个应用系统时，web服务器将发送关于用户的信息，把该信息以cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果web应用系统使用了cookies，就必须检查cookies是否能正常工作。测试的内容可包括cookies是否起作用，是否按预定的时间进行保存，刷新对cookies有什么影响等。
4、设计语言测试
web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的html等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了html的版本问题外，不同的脚本语言，例如Java、JavaScript、activex、vbscript或perl等也要进行验证。
5、数据库测试
在web应用技术中，数据库起着重要的作用，数据库为web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在web应用中，最常用的数据库类型是关系型数据库，可以使用sql对信息进行处理。
在使用了数据库的web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。,l/u,H*wjY-gM8- [此文转贴于我的学习网计算机网络技术
二、性能测试
1、连接速度测试
用户连接到web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2、负载测试
负载测试是为了测量web系统在某一负载级别上的性能，以保证web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问web系统的用户数量，也可以是在线数据处理的数量。例如：web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？web应用系统能否处理大量用户对同一个页面的请求？
3、压力测试
摘要:
介绍了一款针对航空器上电子设备进行监测的系统的设计与测试方法。该系统可以完成数据的采集与传输、错误曼彻斯特码生成、消息监听等功能，其采用可编程逻辑器件（FPGA），在详细分析1553B总线协议的前提下，采用硬件编程语言VHDL，完成功能逻辑部分设计。最后通过现有的1553B总线通信网，搭建硬件测试平台，完成总体的设计实现与功能测试。
关键词：
1553B总线；信息监听；可编程逻辑器件；系统测试
一、引言
随着航空业的飞速发展，飞行器上出现了越来越多的功能各异的电子终端设备，这些终端设备绝大部分是由不同的设计者设计生产出来的，那么由不同设计者设计生产的终端是否可以在同一个航空总线系统中实现完美融合呢？拥有众多终端的总线系统上所传输的消息是否可以完整记录？当总线系统中出现错误的编码类型时，对终端是影响如何？这是飞行器设计制造者需要妥善解决的问题，并且也是众终端设计生产者迫切想要知道的问题[1]。本系统可以完成数据采集与传输，通过测试后，就解决了终端与总线的融合问题；此外，系统还可以生成若干错误类型的曼彻斯特编码，可以对总线上终端面对错误编码的反应进行测试；最后系统与计算机相结合可以完成总线网络的全信息监听，为飞行器设计与制造提供有效数据。
二、总体设计
根据对系统的功能设想，系统的组成大致分为如下几部分，如图1所示：时钟管理部分为中心逻辑器件提供时钟信号；配置口主要实现对中心逻辑器件的配置；USB接口主要实现系统与计算机的连接；RT地址和功能选择部分主要作用是选择系统的功能和设置系统的终端号；A/D采集部分完成数据的采集，将模拟信号转为数字信号；电源管理为系统各部分提供合适的电源；收发器和变压器连通总线和中心逻辑器件；最后中心逻辑器件选择FPGA。系统的数据流向主要有三条：其一，总线上数据经变压器和收发器进入中心逻辑器件，经处理后通过USB接口传至计算机，实现对总线的消息监听；其二，模拟信号经A/D处理后存入中心逻辑器件，收到发送命令后，经收发器和变压器发送至总线上；其三，收到发送错误码命令后，中心器件直接发出错误码，经收发和变压器发送至总线，用以测试总线网络中其余终端的反应[2]。
三、中心逻辑器件功能模块设计
本设计选择FPGA做为中心逻辑器件，中心逻辑器件功能模块的设计及完成是系统实现的重点和难点，也是我们系统设计及实现最耗费时间的部分。FPGA中功能模块大致有如下几个：编码器，主要是实现数据的曼彻斯特码化，然后发至收发器；译码器，主要是实现从总线上得到的数据进行译码，分析出有效数据或命令；数据整合和缓存，主要是完成对数据的加标处理及缓存转入计算机；协议处理模块，主要是完成对命令字的解读；数据采集模块是可调整部分，可根据用户要求灵活设计；错误数据发生模块，主要是生成不同类型的错误编码。具体划分如图2所示[2]。
四、仿真测试
系统的仿真测试平台主要由北京神州飞航科技有限责任公司生产并销售的AEC1553-31RT/S2型通信板卡和总线耦合器、耦合电阻搭建而成，通信板卡和总线耦合器、耦合电阻、计算机形成了一个小型的航空总线网络，我们可以利用这个网络，测试系统的总线监听功能，测试现场图如图3所示；另外中心逻辑器件FPGA中的各功能模块的测试主要利用QuartusII软件内嵌的在线信号分析工具SignalTapII，该模块可以让使用者实时、在线观测到相关模块的工作运行情况，例如图4所示；缓存模块FIFO的主要信号测试数据表明：触发信号为rdreq,检测时钟为读时钟，wrusedw有效说明存储容量半满，其值为80H时，给出读时钟和读使能，在以后每一个时钟读出16位并行数据。最后，对于系统的错误码发生功能，可以通过示波器直接观察，确认其错误类型。根据以上测试方法，测试后系统达到设计要求。
五、结论
该系统设计功能多样，随着航空业的发展，其应用面也会越发广泛，并且系统中有一部分可以根据用户要求进行灵活设计，适应度高。但是本设计仍然存在一定的不足：其一，功能选择，终端地址配置靠硬件实现，更改不灵活，该部分在未来可以结合配套软件做出设计修整；其二，数据采集设计，因为没有参考具体的用户要求，暂时应用逻辑器件片内存储，导致容量小，可以结合具体要求增添片外存储器，扩大容量；第三，错误编码以字为主，未能拓展至消息类型，尚有较大发展空间。随着更大的需求和更广的应用，系统的设计将会越来越完善，功能也将越来越强大。
参考文献：
[1]张义，张红旗．1553B数据总线用电缆阻抗的测试方法[J].光纤与电缆及其应用技术，2014，（3）.
[2]牛茜．基于FPGA的1553B总线监测系统设计[D]．太原：中北大学，2011．
[3]王诚，吴继华，等．AlteraFPGA/CPLD设计（基础篇）[M]．北京:人民邮电出版社，2005．
[4]夏宇闻.Verilog数字系统设计教程[第二版][M].北京:北京航空航天大学出版社，2008.
【关键词】BRASVLAN业务测试
根据BRAS设备下挂用户业务集中化原则，BRAS设备稳定、可靠的运行变得更为突入。本文根据电信运营商对在网运行的BRAS设备业务测试的需求，介绍了如何利用电信网络现有的资源条件下，方便快捷的完成不同业务控制点的BRAS设备业务测试的方案。对运营商内部组网的优化进行了简单而实效的分析，并将结论充分的运用到BRAS设备业务测试的方案中；同时巧妙的利用交换机不同类型的端口的不同特性，完成BRAS设备业务测试过程中内外网VLAN标签的转换。
一、电信本地网现状及BRAS设备的功用
1.1电信本地网现状
整个电信网络中，每个本地网均为一个小的城域网系统。根据网络层次，可以将本地网划分为核心层、业务控制层和接入层。核心层主要提供高带宽的业务承载和传输，完成和已有网络（如ATM、FR、DDN、IP网络）的互联互通，其特征为宽带传输和高速调度。业务控制层的主要功能是给业务接入节点提供用户业务数据的汇聚和分发处理，同时要实现业务的服务等级分类。接入层利用多种接入技术，进行带宽和业务分配，实现用户的接入，接入节点设备完成多业务的复用和传输。
一般来说，城域网核心层由两台核心路由器组成；业务控制层主要由BRAS设备组成；接入层主要由OLT设备、汇聚（接入网）交换机、楼道交换机等设备组成。
本文阐述的数据业务测试主要是涉及到汇聚层和接入层各种设备，主要关注测试BRAS设备业务的可用性。
1.2BRAS设备功能简介
宽带接入服务器（简称BRAS），是面向宽带网络应用的新型接入网关。BRAS设备位于骨干网的边缘层，可以完成IP/ATM网数据的接入，实现多种业务的汇聚和转发工作，解决不同用户对传输容量及宽带利用率的要求，为用户提供VPN服务、企业的内部组网等，已达到对各种宽带业务的综合管理功能。
BRAS设备作为业务控制层的核心设备，在本地网中承载着用户业务的授权、认证和计费信息的上传，用户IP地址的分配以及用户VLAN的终结等重要作用。一台BRAS设备正常运行与否直接关系到用户宽带业务。时时检测BRAS设备所承载的业务，能够及时反应设备的运行状况。
二、BRAS设备业务测试的先决条件
2.1BRAS设备业务测试建立的前提
在保证网络安全的前提下，通过网络拓扑及VLAN标签的合理规划，将BRAS设备的测试链路，通过点对点网络引入维护内网。通过维护内网和城域网的连通，达到BRAS设备跨局点的业务测试的目的。
2.2维护内网的规划
相对于城域网，往往维护内网因为各种不同的需求，甚至比城域网的组网更加复杂，存在的情况可能更多。为了避免内部网络的因素影响BRAS设备的业务测试工作，必须对维护内网进行相应的优化工作。
维护内网如图1所示：
原先维护内网的所有用户均处在同一VLAN中，某个维护人员的终端中毒或者网内的某些其他故障都有可能造成整个维护内网的所有设备运行瘫痪。对于数据网的维护人员而言，无法与设备互通存在很大的隐患。
同时在维护内网中存在维护人员因为自身的某种需求要在网络中侧挂DHCP服务器的现象。在进行BRAS业务测试过程中，WLAN业务等涉及DHCP服务的测试往往会出现各种问题，不能够得到准确的测试结果。因此在进行业务测试网络的规划之前，对于维护内网的网络优化势在必行。
3.2BRAS设备业务测试方案
3.2.1测试VLAN的划分
根据测试链路所经过的汇聚交换机目前所承载的VLAN情况，结合点对点网络的VLAN部署，重新划分出一段两张网络均未使用的VLAN范围，并一一规划到每台需进行业务测试的链路中。
3.2.2物理链路的开通
首先完成城域网、大客户点对点网络、维护内网的连通。如图2所示，在核心节点新建一台汇聚交换机SW18，新增三条链路分别连通城域网、点对点网络以及维护内网，并根据已经规划的VLAN进行数据配置。
在各业务控制点将BRAS设备测试链路通过大客户点对点网络交换机引入大客户点对点网络。
3.2.3数据配置
将三网汇聚交换机新建规划好的VLAN并透传至大客户点对点网络的汇聚交换机。
在大客户点对点汇聚交换机，通过原点对点链路将相应的VLAN透传至不同的业务控制点。同时在各业务控制点将VLAN透传至BRAS设备。
维护内网配置较为复杂。首先将内网的数据包通过防火墙透传至汇聚交换机；
其次，在汇聚交换机上，选择两个以太网口，并用网线互联。在互联链路一端剥离内网数据包VLAN标签，并在另一端打上VLAN标签（此VLAN为需要测试的BRAS设备的测试业务VLAN）。这样在进行业务测试时，只需在端口进行VLAN切换即可完成不同业务控制点BRAS设备的业务测试。
3.2.4利用城域网建立测试系统方案
考虑到不是每个本地网都具备大客户二层VPN专网，另设计了一种不依赖该专网的实现方式。
该方式利用业务控制点的城域网汇聚交换机，迅速搭建二层VPN网络来承载业务控制点的测试电路。具体操作办法是以办公局点的汇聚交换机为中心，和每个业务控制点的汇聚交换机之间开通一条GE/FE电路，简单搭建一个星型的二层VPN网络。市公司业务控制点的电路可用裸纤或城域波分的方式开通，县公司业务控制点的电路可以用MSTP或城域波分开通。
该方式简便易行，亦不占用宝贵的BRAS端口资源；在裸纤连接的场景中，如果改用单纤GE模块，占用的局间中继纤芯数量仅为市区业务控制点数量减一。同时汇聚交换机兼做二层VPN交换机，也省去了两者互联的电路。
将每台BRAS当成一个二层VPN用户，为每台BRAS规划一个独立的测试VLAN；在大客户二层专网将这些VLAN全部透传至花雨路汇聚交换机，每个VLAN对应一台BRAS的测试子接口；在花雨路汇聚交换机上和维护内网交换机互联的端口上切换VLAN，便可选择不同BRAS对应的测试子接口，从而实现在维护内网对所有bras下挂业务的远程测试。
四、网络安全性的保证
将维护人员的内网、大客户的专网以及城域网串联在一起势必存在网络安全方面的隐患。隐患消除包括以下几个方面：（1）网络的规划。将各网络串联最担心就是网络成环的问题。合理的规划网络的各项属性能够很好的避开网络成环。首先根据城域网和专网的VLAN使用情况，合理的划分出一段暂时未用的VLAN段，分别分配给各个业务控制点的BRAS设备。（2）网络数据配置的准确。在设备互联的链路上准确的限制允许透传的VLAN值，同时保证设备其他互联链路不存在此VLAN值，既能够很好避开VLAN成环的问题。（3）控制操作串联网络的人数。在进行网络测试或数据修改时，保证只有网络管理员能够修改串联网络的相应的数据，减少因为人为因素导致的网络故障的可能性。
五、BRAS业务测试的好处
客户使用的感知度成为网络维护好坏的评定标准。加强BRAS设备的业务测试工作，能够有效的提高网络可用性的监控。通过在线BRAS设备的业务测试，能够方便快捷并灵活的测试不同业务控制点、不同的BRAS设备、不同板卡以及不同的子接口和物理接口下的各种业务的使用情况，准确的发现故障点，为故障快速的处理提供了保障。
六、结束语
充分的利用现有的资源，加强网络维护工作，保证网络的稳定性、安全性、可用性，努力提高用户的感知度。
关键词：软件测试；系统测试；线索；压力测试；性能测试
中图分类号：TP39文献标识码：A文章编号：1007-9599 (2012) 05-0000-02
一、引言
软件测试作为软件质量保证的关键技术之一，其目的就是能够有效地发现软件中的错误或缺陷。系统测试是对完整集成后的系统进行测试的阶段，用来评价系统对具体需求规格说明的符合性，系统测试是在单元、组件和集成测试阶段之后进行的。主要针对软件系统和其他系统元素（及硬件、数据库和人机交互信息）组合构成完整的计算机应用系统中所有的元素配合是否合适以及整个系统的功能、性能、执行强度、安全性等是否达到规定标准而进行的测试。
二、系统测试概述
（一）系统测试概念
所谓系统测试是将通过集成测试的软件系统，作为计算机系统的一个重要组成部分，与计算机硬件、外设、某些支撑软件的系统等其他系统元素组合在一起所进行的测试，目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或矛盾的地方。
（二）系统测试前的准备工作
系统测试前的准备工作主要包括：对系统各种功能的描述；系统要求的数据处理及传输的速率；对系统性能的要求；对备份及修复的要求；对兼容性的描述；对配置的描述；对安全方面的要求等。
（三）系统测试的测试数据
系统测试所用的数据必须尽可能地像真实数据一样精确和有代表性。可以使用真实数据或者使用真实数据的一个复制，复制数据的质量、精度和数据量必须尽可能地代表真实的数据。
（四）系统测试与确认测试区别
确认测试始于集成测试的结束，那时已测试完单个构件，软件已组装成完整的软件包，且接口错误已被发现和改正。在确认测试时，传统软件与面向对象软件的差别已经消失，测试便集中于用户可见的动作和用户可识别的系统输出。
1.确认测试准则
软件确认是通过一系列表明已符合软件需求的测试而获得的。测试计划和规程都是用于确保满足所有的功能需求，具有所有的行为特征，达到所有的性能需求，文档是正确的、可用的。执行每个确认测试用例之后，存在下面两种可能条件之一：（1）功能或性能特征符合需求规约，因而被接受；（2）发现了与规约的偏差，创建缺陷列表。
2.配置评审
评审的目的是保证所有的软件配置元素已正确开发、编目，且具有支持软件生命周期的支持阶段的必要细节。
3.α测试与β测试
α测试是由最终用户在开发者的场所进行。软件在自然的环境下使用，开发者站在典型用户的后面观看，并记录错误和使用问题。α测试在受控的环境下进行。
β测试是最终用户场所执行。开发者通常不在场，因此，β测试是在不为开发者控制的环境下软件的现场应用。最终用户记录测试过程中遇见的所有问题(现实存在或想象的)，并将其定期地报告给开发者。接到β测试的问题报告之后，软件工程师进行修改，然后准备向最终用户软件产品。
二、系统级功能测试技术
（一）线索的概念
线索（thread）的概念很难定义。事实上，一些已经公开的定义都是矛盾、容易产生误导或错误的。可以把线索看作是一种不需要形式化定义的原始概念。以下是对线索的多种看法：一般使用的场景；系统级测试用例；激励/响应对；由系统级输入序列产生的行为；端口输入和输出事件的交替序列；系统状态机描述中的转换序列；对象消息和方法执行的交替序列；机器指令序列；源指令序列；MM-路径序列；原子系统功能序列。
（二）需求规约的基本构造元素
根据一组基本需求规约构造元素，即数据、行动、设备、事件和线索，来讨论系统测试。每个系统都可以使用这五种元素表示。
1.数据
主要包括：变量、数据结构、字段、记录、数据存储和文件、实体关系模型高层数据描述。
2.行动
以行动为中心建模仍然是需求规约的一种常见形式，这是因为有命令式程序设计语言以行动为中心性质的历史原因。行动有输入和输出，这些输入和输出既可以是数据，也可以是端口事件。行动还可以分解为低层活动，例如数据流图。
3.设备
每个系统都有端口设备，这些端口设备是系统级输入和输出（端口事件）的源和目的地。在技术上，端口是I/O设备接入系统的点。
4.事件
事件既有数据方面的一些特征，又有行动方面的一些特征。事件是发生在端口设备上的系统级输入（或输出）。可以是离散的，也可以是连续的（例如温度、高度或压力）。端口输入事件是物理到逻辑的转换，同样，端口输出事件是逻辑到物理的转换。
5.线索
因为要测试线索，因此测试人员通常不能在数据、事件和行动之间的交互中找出线索。线索本身出现在需求规约中的惟一地方，是使用快速原型法并结合场景记录器。
（三）线索测试的结构策略及功能策略
结构策略实际上是基于有限状态机的行为建模中的结构来寻找测试线索的。首先自底向上组织各层次的状态机，然后寻找线索覆盖每个状态机的节点和边，同时还要找出节点与边覆盖指标。
线索测试的功能策略
1.基于事件的线索测试
（1）端口输入事件覆盖指标
五个覆盖指标为覆盖端口输入事件提供了一组线索：
(1)PI1：每个端口输入事件发生。
(2)PI2：端口输入事件的常见序列发生。
(3)PI3：每个端口输入事件在所有“相关”数据语境中发生。
(4)PI4：对于给定语境，所有“不合适”的输入事件发生。
(5)Pl5：对于给定语境，所有可能的输入事件发生。
（2）端口输出事件覆盖指标
根据端口输出事件定义两种覆盖指标：
(1)PO1：每个端口输出事件发生。
(2)PO2：每个端口输出事件在每种原因下发生
2.基于端口的线索测试
基于端口的测试是基于事件测试的有用补充。
对于每个端口都要询问端口上会出现什么事件。然后根据每个端口的事件列表寻找使用输入端口和输出端口的线索。有些需求规约技术要求提供这种端口的事件列表。
设备和事件之间的多对多测试应该在两个方向上进行：基于事件的测试覆盖从事件到端口的一对多关系，反之，基于端口的测试覆盖从端口到事件的一对多关系。SATM系统不能使用这种测试，因为SATM不发生在多个端口上。
三、系统测试的主要内容
系统测试一般要完成以下几种测试：功能测试、性能测试、可靠性、稳定性测试、兼容性测试、恢复性测试、安全性测试、强度测试、面向用户支持方面的测试、其他限制条件的测试。下面就对常用的系统测试做一个介绍：
（一）压力测试
压力测试是指模拟巨大的工作负荷以查看或评估应用程序在峰值或超越最大负载使用情况下如何执行操作。压力测试有如下特点：可以测试系统的稳定性；一般需要对用户的使用情况进行模拟。压力测试的方法包括：并发测试法、增加量级法、重复测试法。
（二）性能测试
性能测试一般需进行：对软件计算的精度有要求时，设计测试用例；对软件有时间要求时，设计测试用例；测试为完成功能所处理的数据量；测试程序运行所占用的空间；测试对系统的负载潜力；测试配置项各部分的协调性；测试软件性能和硬件性能的集成；测试系统对并发事务和并发用户访问的处理能力。
（三）恢复性测试
多数基于计算机的系统必须从错误中恢复并在一定的时间内重新运行。恢复性测试是通过各种方式强制地让系统发生故障并验证其能适当恢复的一种系统测试。若恢复是自动的(由系统自身完成)，则对重新初始化、检查点机制、数据恢复和重新启动都要进行正确性评估。若恢复需要人工干预，则估算平均恢复时间(mean-time-to-repair，MTTR)以确定其是否在可接受的范围之内。
（四）安全性测试
安全性测试验证建立在系统内的保护机制是否能够实际保护系统不受非法入侵。系统的安全必须经受住正面的攻击，但是也必须能够经受住侧面和背后的攻击。在安全性测试过程中，测试者扮演试图攻击系统的角色。测试者可以试图通过外部手段获取密码；可以通过瓦解任何防守的定制软件来攻击系统；可以“制服”系统使其无法对别人提供服务；可以有目的地引发系统错误以期在其恢复过程中入侵系统；可以通过浏览非保密数据，从中找到进入系统的钥匙等等。
四、结语
系统测试有助于在其部署中客户发现缺陷之前，尽可能多滴发现缺陷，在系统测试期间要验证完整产品的行为，包括设计多个模块、程序和功能的测试，测试完整产品的行为是很关键的，因为很多人错误地认为经过单独测试的组件放到一起后仍能正常运行。
参考文献：
[1]薛冲冲,陈坚.软件测试研究[J].计算机系统应用,2011,2
[2]陶幸辉,宋志刚.软件系统测试类型及测试用例设计[J].科技经济市场,2011,6
[3]朱家云.浅析软件测试[J].信息系统工程,2011,4
[4王丽达.论软件系统的测试[J].经济研究导刊,2011,14
关键词：系统软件测试；测试；需求；分析
中图分类号：TP311
1 什么是测试需求
简单来说，测试需求就是确定在项目中需要测试什么。测试需求描述测试的目标，特别是描述了产品的质量需求，测试需求分析目的是帮助定义测试对象和测试范围，发现软件需求中不完善和不明确的地方并加以完善以节省测试时间的投入，便于软件需求基线化和跟踪业务需求的变更。
一条有用的测试需求是唯一的、精确的、有边界的、可测试的。例如：软件产品可能有这样一个测试需求“系统主要事务的响应时间能满足系统要求”。这就是一个不符合要求的测试需求，怎样的指标是“满足”？系统的要求又是什么都不清晰，测试就无法开展。
一个完整清晰的可测试的软件测试需求是这样的：在1G内存和1.73兆主频的计算机上在25个并发用户执行插入、更新和删除操作时端到端的响应时间在3秒时间内。符合标准的测试需求是存在一个明确的可预知的结果，可以通过某种方法对这个结果进行判断和验证
测试需求应覆盖已经定义的业务流程，功能及非功能方面的需求。
2 为什么要做测试需求分析
测试需求是测试计划的基础与依据，我们在测试活动中，首先需要明确测试需求（What），才能决定怎么测（How），测试时间（When），需要多少人（Who），测试的环境是什么（Where）。是衡量测试覆盖率的重要指标。
确立测试需求是为了保证测试质量与进度，测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。在软件工程项目中，存在一些普遍的现象例如：需求阶段的问题，到测试的最后阶段才被发现；开发、测试、市场等不同角色的人员对软件功能细节存在理解歧义。确立测试需求可以避免这些问题的产生。
3 什么时候开始做测试需求分析
软件生存期的各个阶段都可能产生错误。而软件需求分析、设计和实现阶段是软件的主要错误来源。因此一旦软件需求确定后，即可开始进行测试需求分析。
4 如何做测试需求分析
做测试需求分析有两个关键词，一个是“测试需求”，一个是“分析”，下面我从以下几个步骤来说明如何做测试需求的分析。
4.1 对软件需求说明书进行需求验证
一个良好的软件需求应当具有一下特点：（1）清晰性；（2）组织和完整性；（3）一致性；（4）可修改性；（5）可跟踪性；（6）可检验性；（7）接口：界面、接口的说明；（7）质量、性能属性；（8）可靠性；（9）软硬件；（10）特殊问题。
4.2 搜集和提取测试需求（包括隐性的需求）
测试需求并不等同于软件需求，它是从测试的角度出发并根据软件需求整理出一个测试列表，作为该软件的主要测试内容。提取测试需求要以软件需求说明书及规格说明书为依据，以业务功能为中心，深刻理解业务规则和隐式需求，通过与客户深入沟通，明确测试范围和质量目标，达到测试分析和设计全面、无遗漏。隐形需求包括：用户隐式的需求如业务规则；行业规范；编写人员的技术能力所限等。提取方法可通过列表的方式对软件开发需求进行梳理，先提取出所有的需求点。这些需求点可能存在重复和冗余，再根据项目的功能模块进行组织归类，删除重复的需求、细化测试粒度太大的需求、合并相关联的需求，最后根据业务规则及相关文档等，对测试需求进行检查和完善。测试需求主要通过以下途径来收集：（1）与待测软件相关的各种文档资料。如软件需求规格、Usecase、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。（2）与客户或系统分析员的沟通。（3）业务背景资料。如待测软件业务领域的行业标准及知识等。（4）正式与非正式的培训。（5）其他途径。
4.3 根据测试阶段和重点，整理测试需求
测试处于不同的阶段，测试的重点也是不同的，例如集成测试阶段主要是检验程序单元或部件的接口关系；系统测试阶段，重点是为了验证和确认系统是否达到了其原始目标，通过与系统的需求定义做比较，发现软件与系统定义不符合或与之矛盾的地方。因此确立测试阶段和重点，才能在测试需求分析时，做到方向正确、目标明确。除了需要确保要求实现的功能正确，还要考虑软件的特性。银行/财务软件更强调数据的精确性，网站强调服务器所能承受的压力，ERP强调业务流程，驱动程序强调软硬件的兼容性。在做测试分析时需要根据软件的特性来选取测试类型，并将其列入测试需求当中。关注测试的焦点。测试的焦点是指根据所测的功能点进行分析、分解，从而得出的着重于某一方面的测试，如界面、业务流、模块化、数据、输入域等。系统功能测试需求分类：（1）业务功能测试需求；（2）可靠性测试需求；（3）安全性测试需求；（4）易用性测试需求；（5）可移植性测试需求；（6）可维护性测试需求。
5 测试需求评审
测试需求的评审是质量保证的必须步骤，通过评审可保证测试需求获得相关干系人的认可，做到有据可依。测试需求评审的内容包括完整性审查和准确性审查。完整性审查是检查测试需求是否覆盖了所有的软件需求、以及软件需求的各项特征，关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束、行业标准等。同时还要关注系统隐含的用户需求。准确性审查是检查测试需求是否清晰、没有歧义、描述准确，是否能获得评审各发的一致理解，在测试需求之间以及与开发需求没有矛盾和冲突，每一项测试需求都可以作为设计测试用例的依据。
测试需求评审的形式没有固定的要求，有条件可以采用正式的小组会议形式进行评审，在评审之前确定好参会人员的各个角色和相关的责任，确保评审之前参会人员已经拿到了评审材料并有了足够的了解，评审结束时以签名及会议纪要的方式把评审结果通知相关单位及人员。此方式的优点是有计划有组织地进行，评审更加有效和权威，缺点是需要协调相关人员时间及会议场地等，在很多实际项目中有较大难度。测试需求评审还可以采取非正式的走查和轮查形式，将需要评审的内容发给相关人员，收集他们的意见，并把统一意见修改确立后的测试需求再发给相关评审人员进行确认。这种方式的优点是方便有效，缺点是少了多方人员的讨论和沟通。对于大型的重要项目，可能还会采取正式审查方式进行评审，包含了制定评审计划、组织会议、会后跟踪分析审查结果等。参与测试需求评审的人员至少要包含：项目经理、开发负责人、测试负责人、系统分析人员、相关开发和测试人员。测试需求评审通过以后，才可以跟进测试需求来制定测试计划及编写测试用例。
6 测试需求维护
在实际的软件工程中，软件需求的变更是很常见的，甚至频繁变更软件需求。如果一直使用初始的测试需求来指导我们的测试工作，必然造成测试的结果存在错误和差异。因此必须及时维护测试需求，适应实际工作的需要。在需求变化频繁的情况下，作为测试人员，最重要的就是要搞清楚以下几点：（1）哪些需求发生了变化；（2）这些需求变化后，对测试工作会产生哪些影响。包括会不会影响测试用例，如果影响，会对哪些用例产生影响。当发生较大改动时，还要明确是不是影响到了测试需求？（3）明确这些变化，会对自己的工作进度产生多大的影响。（4）对于必须更改的测试需求变化，要及时更新测试方案和用例。
1区域医疗领域大数据应用系统测试实现
1.1应用系统架构如图4所示，最底层是HBase集群，用于诊疗文档数据仓库，HMaster是HBase集群的管理节点。应用服务器层由若干台调阅应用服务器组成，分别注册到上层的若干台Nginx服务器中。Nginx层包含多台Nginx服务器，每台Nginx服务器下面挂接了若干台AppServer。负载均衡层由两台配置了LVS和Keepalive服务的负载均衡服务器组成，其中一台为主服务器，另外一台为备用服务器。
1.2测试环境基于区域医疗大数据应用系统的特点以及要求，搭建了如图5所示的测试环境。
1.3测试业务(1)基于云计算的健康信息调阅主要面向联网医院的医生，实现对其接诊患者健康档案信息的调阅。(2)基于云计算的智能提示服务基于居民健康信息为医生提供的提示、警示，如药物过敏、重点人群等各类警示信息以及重复检验/检查提示等。(3)网上预约服务通过网上预约及医院医生病人预约的方式实现病人就诊，确保在医疗资源分布不均的情况下，让病人得到更方便快捷的医疗服务。
1.4测试场景(1)场景一测试所用诊疗文档库的数据量：380万，脚本取样：1万；1万个工作站在1min之内共完成2000个交易；每次调阅操作的最长响应延时不超过1.5s；高峰时段可支撑500~800个并发用户请求。(2)场景二测试所用特征数据库中的数据量：380万，脚本取样：1万；1万个并发用户1min之内共完成10000个交易；每次交易最长的响应延时不应超过500ns。
1.5测试方法测试人员根据系统的特点，采用黑盒测试方法，通过自动化和手工结合的方式完成功能测试；使用LoadRunner完成性能压力测试[6]。功能测试通过手动和自动化工具Selenium相结合的方式进行，按照等价类、边界值、因果图、判定表等方法，主要验证待测试系统各个功能模块逻辑是否正确[7]。易用性测试通过手动方式检查区域医疗大数据软件系统使用的合理性和方便性等。在测试时，测试人员要多从用户体验的角度出发，检验是否符合大多数而不是个别用户的操作使用习惯。兼容性测试主要是通过手动的方式验证区域医疗大数据软件系统能否在特定的硬件平台上、不同的应用软件之间、不同的操作系统平台上、不同的网络环境中很好地运行。扩展性测试美国国家标准与技术研究院(NIST)给出的云计算权威定义：按需的自我服务，广泛的网络访问资源池，快速的弹性能力，可度量的服务。云存储是云计算的一个方面，因此弹性扩展能力对于云计算时代的区域医疗大数据系统尤为重要。扩展性测试，主要包括测试系统的弹性扩展能力(扩展与回缩)，以及扩展系统带来的性能影响，验证是否具有线性扩展能力。这部分测试也是以手动方式进行。安全性测试考虑到为保护区域医疗大数据应用系统关键核心业务的安全，需要从以下方面实施：保护信息系统安全，加强防止未授权的访问、使用、泄露、中断、修改或破坏；保护网络安全，需要防入侵检测、防病毒、密码、物理隔离等；保护数据安全，需要加强数据库的机密、完整、可备份和可恢复。因此，使用Appscan测试用具进行相关安全性漏洞扫描。压力测试主要是通过逐步增加系统负载，测试系统性能的变化，并最终确定什么负载条件下系统性能处于失效状态，并以此获得系统能提供的最大服务级别的测试，并验证大数据系统的性能指标要求。使用LoadRunner测试工具进行，LoadRunner是一种预测系统行为和性能的工业标准级负载测试工具。通过模拟上千万用户实施开发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个JavaEE系统的架构进行测试。通过使用LoadRunner，能最大限度地缩短测试时间、优化性能和加速应用系统周期。在不同的测试类型中，采用不同的测试方法。功能测试：采用手工和自动化相结合，针对不同的功能点，合理的使用边界值法、错误推测法、因果图法、判定表法等，回归测试80%的功能点由自动化测试工具来完成。性能测试：根据需求调研、制定合理的性能测试指标，使用性能测试工具进行测试，分析测试结果查找系统瓶颈，最终使产品的性能满足客户的需求。安全性测试、环境测试以及标准符合性测试都在不同程度进行功能和性能测试[8]。
2结语
引言
随着嵌入式系统硬件体系结构的变化，嵌入式系统的发展趋势向嵌入式系统高端，即嵌入式软件系统转移，具体体现在嵌入式操作系统趋于多样和应用软件日渐复杂。由于嵌入式系统软硬件功能界限模糊，研究如何进行系统测试和进行质量评估来保证嵌入式系统的产品质量具有重要意义。
首先，这里明确嵌入式系统的系统测试定义，是将开发的软件系统（包括嵌入式操作系统和嵌入式应用软件）、硬件系统和其它相关因素（如人员的操作、数据的获取等）综合起来，对整个产品进行的全面测试。嵌入式系统的系统测试比PC系统软件测试要困难得多，主要体现如下：
①测试软件功能依赖不需编码的硬件功能，快速定位软硬件错误困难；
②强壮性测试、可知性测试很难编码实现；
③交叉测试平台的测试用例、测试结果上载困难；
④基于消息系统测试的复杂性，包括线程、任务、子系统之间的交互，并发、容错和对时间的要求；
⑤性能测试、确定性能瓶颈困难；
⑥实施测试自动化技术困难。
1 测试方法
根据Goodenough和Gerhart提出的软件测试充分性准则可知，软件测试具有非复合性的特点，也就是说，即使以软件所有成分都进行了充分的测试，也并不意味着整个软件的测试已经充分。所以，即使通过了需求测试、设计测试、编码测试，并不意味着已经完全了充分的测试，还要进行软硬件全面测试，即系统测试。正确的系统测试方法能设计出良好的测试事例，而良好的测试事例是测试成功的关键。测试事例质量特性主要有以下几点。
*检验性：检测软件缺陷的有效性，是否能发现缺陷或至少可能发现缺陷。
*可仿效性：可以支持测试多项内容，减少测试事例的数量。
*开销：测试事例的执行、分析和调试是否经济。
*修改性：每次软件修改后对测试事例的维护成本。
测试方法不仅要保证测试事例具有发现缺陷的高可移植性，而且还要保证测试事例设计的经济有效。因此，在实际测试工作中，将嵌入式系统的测试方法分类如下：根据测试是否动态运行被测程序分为静态测试方法和动态测试方法；根据测试阶段分为需求测试方法、设计测试方法、编码测试（单元测试、集成测试）方法及系统测试方法；根据测试目的分为功能测试、性能测试、可靠性测试（容错性、可恢复性、成熟度测试*及信息安全保护等测试。参看表1嵌入式软件测试方法对照。其中“√”代表相关性。所有这些方法的具体定义这里不一一介绍。由于不同的嵌入式系统面向的应用不同，测试方法的侧重也很不相同。本文后面将对一个具体的便携式信息处理嵌入式系统（PDA、便携式翰林电子书）的系统测试方法详细说明。
表1 嵌入式软件测试方法及阶段对照表
测试方法分类
需求测试设计测试编码测试系统测试静态测试方式；基本思想Yourdon的结构化走通结构化审阅√√ √Fagan检查测试检查并评估√√ √动态测试方法；基本思想控制流测试语句测试 √√ 路径测试
√ 条件测试
√ 数据流测试数据定义引用
√√分域测试划分子域测试√√ √功能测试划分功能测试
√√随机测试不限定范围
√2 可靠性评估
可靠性是嵌入式系统最重要的质量指标。ISO9000国示质量标准（ISO/IEC 9126-1991）规定，软件产品的可靠性含义是：在规定的一段时间和条件下，软件能维持其性能水平的能力有关的一组属性，可用成熟性、容错性、易恢复性三个基本子特性来度量。根据我们在评估嵌入式系统中的成功经验，一般采取以下简单有效的评估方法（可以采用百分制或十分制）。
（1）成熟性度量
①错误发现率DDP（Defect Detection Percentage）。在测试中查找出来的错误越多，实际应用中出错的机会就越小，软件也就越成熟。
DDP=测试发现的错误数量/已知的全部错误数量
已知的全部错误数量是测试已发现的错误数量加上可能会发现的错误数量之和。
②测试覆盖率度量。测试的覆盖率，可以用测试项目的数量和内容进行度量。除此之外，如果测试软件的数量较大，还要考虑数据量。测试的覆盖率，可以根据表2所示在测试指标进行评价。通过检查这些指标达到的程度，就可以度量出测试内容的覆盖程度。
表2 测试覆盖程度表
测试覆盖项测试覆盖率指标测试描述测试结果界面覆盖符合需求（所有界面图标、信息区、状态区） 静态功能覆盖功能满足需求 动态功能覆盖所有功能的转换功能正确 正常测试覆盖所有硬件软件正常时处理 异常测试覆盖硬件或软件异常时处理（不允许的操作）测试结束判断表3 可信度测试表
测试功能甲乙丙丁平均最大值-最小值功能1
功能2
功能3
功能4
功能5
注意，对于最大值与最小值的差值超过5的情况，应该重新测试响应功能。
（2）容错性评估
容错性评估分为控制容错性评估、数据容错性评估、硬件故障恢复容错性评估：
容错性=以下各条款评分之和÷条款数
控制容错性度量
①对并发处理的控制能力；
②错误的可修正性和处理可继续进行能力。
数据容错性度量
①非法输入数据的容错；
②对相互冲突的要求和非法组合容错；
③输出数据是否合理容错。
硬件故障中恢复容错性度量
故障后恢复能力容错。
（3）易恢复性度量
与易恢复性紧密相关的测试是强度测试和健壮测试。强度测试又称为力度测或极限测试，主要测试系统对空间强度和时间强度的容忍极限；健壮测试又称异常测试，是很重要的可靠性测试项目。通过易恢复性测试，一方面使系统具有异常情况的抵抗能力，另一方面使系统测试质量可控制。
易恢复性=以下各条款评分之和÷条款数
①空间强度可恢复；
②时间强度可恢复；
③数据强度可恢复；
④异常通信可恢复；
⑤数据破坏可恢复；
⑥电池极限可恢复。
（4）测试可信度评估
测试可信度是对测试质量的有效评估，是保证质量的必要步骤。目前虽然很难有量化的指标，但我们采取积分的方式显示可信度。例如，请4个人员（甲、乙、丙、丁）对系统5个功能打一个从0（不信任）到10（完全信任）之间的分数，那么，可信度度量可以用表3进行计算。
3 测试实例
（1）电流测试
电流测试是嵌入式系统的系统测试中首先要进行的重要测试，也是最容易被忽视的测试。主要是测试系统的
工作电流、待机电流。人们一般把它当成与系统测试无关的硬件测试。但是对于嵌入式系统，软件与硬件不可能清晰地划分，硬件的性能直接影响软件的运行。实例1说明了电流测试对系统运行的影响及不可替代的作用。测试现象描述：进行同一厂商PDA系统测试，有几台PDA在名片子系统、行程子程序的操作过程中随机死机。
我们当时的错误分析定位是：①怀疑操作系统中断处理错误；②怀疑内存泄漏，堆栈溢出；③怀疑应用程序错误。
在软件开发人员为解决这个问题检查软件时，硬件开发人员提出应首先测试一下这几台机器的工作电流。结果发现，PDA的工作电流低于正常工作电流。加电容调整后随机死机问题消失。
由此例还可以看出，嵌入式系统测试的软硬件测试不可分性。绝对的将硬件测试和软件测试区分开来的测试思想是不正确的。我们在系统测试时的电流测试设计如表4。
表4 电流测试
测试电流项目测试结果（不同的产品对电流要求不同）备 注预期值实测值待机电流/mA
关机后电流测试启动电流/mA
开机瞬间电流测试工作电流/mA
正常工作电流测试（2）兼容性测试
考虑到嵌放式系统软硬件的开发成本高于通用PC系统，因此，提高软件对硬件的兼容及软件升级版本的兼容性极为重要。表5是便携林翰林电子书升级版本兼容性测试实例。
表5 兼容性测试
兼容性测试分类
硬件兼容性操作系统兼容性应用软件兼容性PC制书软件兼容性BIOS兼容测试
BIOSV1.0
BIOSV2.0
操作系统兼容测试
VOLF V.1.0
VOLF V.2.0
应用软件兼容测试
READER V.1.0
READER V.2.0
PC制书软件兼容测试
PCREADRE V1.
PCREADER V2.
实例2：现在的嵌入式系统的层次结构一般分为硬件层、BIOS层、操作系统层、应用系统层。有的还需要通用PC应用软件支持。因此，嵌入式系统的兼容性测试要考虑硬件兼容性、BIOS兼容性、操作系统兼容性，还需考虑与相应PC应用软件的兼容性。
