用户界面测试范文

用户界面测试范文（精选10篇）

用户界面测试 第1篇

GUI(图形用户界面)应用程序已经越来越多地被应用于软件系统中,由于它的易用性,现在GUI程序几乎成为了软件开发的事实准则,“GUI几乎占据了一个应用程序60%的代码量”[1],很多对安全性有高要求的程序也采用GUI方式,使得GUI界面本身的安全性、正确性和鲁棒性成了影响整个应用程序性能的一个重要因素。因此GUI的测试显得尤为重要。

对于GUI应用程序的测试,国内外一些研究工作者已经取得了一些成果:如Atif M.Memon[2,3]等人先后提出了基于目标的测试用例生成方法以及采用人工智能规划自动产生GUI软件测试用例的方法(PATHS法);Marlon Vieira[4]等提出了基于统一建模语言(UML)模型的测试用例生成方法;北京航空航天大学的刘超根据交互软件的可能交互过程提出了基于程序交互流程图的测试用例生成策略[5]等,除了这些方法外,比较传统的测试具有交互性质的软件一般采用FSM(Finite State Machine)即有限状态机技术[6],对交互过程中程序可能处于的状态进行模拟,从而构造测试用例。这些测试方法和技术都是很有用的,但是它们大多是基于界面元素的黑盒测试,没有考虑GUI代码的覆盖率,所以测试不充分,另外,这些模型不能用于GUI测试的整个过程。

本文通过研究GUI软件的规格说明、GUI结构、GUI代码,构造了用于GUI测试的四种不同层次的GUI表示方法,分别为界面调用关系图、对象-事件分析图、事件关系流图以及事件程序控制流图,这些GUI表示方法可以关联测试过程各个阶段的技术。在本论文中,将介绍如何构造这些模型以及提出了基于这些模型的复合性测试用例生成方法。

1 GUI表示

从软件的规格说明、GUI结构、GUI代码中可以获得GUI表示方法,这些表示方法可以用于包括测试用例生成、测试覆盖评价、测试用例执行、测试结果预测、回归测试等各个阶段,并使各阶段的技术得到关联。

为了描述界面之间的调用返回关系,便于界面间的测试,构造了界面调用关系图;为了描述GUI的对象、对象属性、事件及定义事件有关信息,便于测试的执行,构造了对象-事件分析图;为了描述界面中事件之间的关系,便于界面内的测试,构造了事件关系流图;为了描述事件程序内部逻辑结构,便于提高底层代码覆盖率,构造了事件程序控制流图。

1.1 界面调用关系图

界面调用关系图表示的是界面之间的层级关系。在本文提出的测试方法中,把一个相对独立的功能作为一个测试单元,为每个测试单元内的界面生成界面调用关系图,图中的每个结点表示一个界面,一条从结点X到结点Y的边表示界面Y是通过执行界面X中的某个事件而被启动的。

为了描述界面之间的调用返回关系,我们需识别界面中的打开界面事件以及终止界面事件。打开界面事件是那些通过执行能启动新的界面的事件。终止界面事件是那些通过执行能终止当前界面返回原来界面的事件。

定义1 界面调用关系图是一个四元组<I,T,E,R>,I是此功能点内所有使用到的界面集合;T是当使用此功能时,最先启动的界面集合(一个或多个);E是有向边集合,是打开界面事件的集合,表示一个界面调用另一个界面;R是有向边集合,是终止返回界面事件的集合,表示终止当前界面返回另一个界面。

在“SD空运物流进口业务处理系统”中,入库作业子模块包括交接单查询界面W1、总单入库界面W2、分单入库界面W3以及分批明细界面W4。图1给出了这些界面之间的调用关系,其中I={W1, W2, W3, W4},T={W1},E={edit, goto_hawb, edit_hawb, batch_click1, batch_click2},R={cancel1, cancel2, cancel3}。

1.2 对象-事件分析图

对象-事件分析图用于描述图形用户界面信息,列出了界面内的控件对象、对象属性及其主要事件之间的对应关系,同时,定义了每个事件的触发条件、类型、前置条件、动作结果等。事件类型分为一般交互事件、打开界面事件及终止界面事件。

定义2 对象-事件分析图是三元组<W,E,R>,W是wi的集合,wi=(oi,P,V),表示控件对象oi及其属性集合P(P={p1,p2,…,pm})和属性值集合V(V={v1,v2,…,vn})。E是ej的集合,ej=(name,on,type,precondition,effect),name表示事件名、on表示事件的触发条件、type表示事件类型、precondition表示执行此事件前必须满足的前置条件、effect表示执行此事件后的动作结果。R表示控件对象与事件之间的对应关系,R={(wi,ej)} (i>0,j>0)。

图2给出了描述空运进口系统中总单入库界面的对象-事件分析图的部分信息。

1.3 事件关系流图

一个界面中的所有主要事件可以表示成一个事件关系流图。直观地说,一个事件关系流图代表了一个GUI界面中所有可能的事件交互及事件之间的控制关系、公共关联关系。

事件之间的交互关系,是通过研究软件设计书和GUI结构得到的。若事件是一般交互事件,则其下一个可执行事件可以是界面上任一个可用事件;若事件是打开界面事件,则其下一个可执行事件可以是被打开界面中的任一起始事件;若事件是终止界面事件,则其下一个可执行事件可以是被返回界面中的任一起始事件。

控制关联:指一事件代码凭借某种数据结构控制另一事件的运行。

公共关联:指一事件与另一事件共同操纵某一共享数据区域。

事件之间的关联关系除了从详细设计书及操作手册中说明的完成某一任务规定的操作路径中找出外,还需对事件代码加以研究,找出隐藏在代码中的关系。

定义3 界面I的一个事件关系流图是一个五元组<V,E,B,C,R>。

(1) V表示界面中所有主要事件的点的集合,V中每个点v表示在界面I中的一个事件。

(2) E ∈V * V,它是上述点之间的有向边的集合,表示事件之间的交互。一条边(vi,vj)∈ E,当且仅当事件vj紧跟在事件vi之后执行。

(3) B∈V,这些点表示当一个界面刚刚启动时,用户可用的这个界面中的事件集合。称为起始事件集合。

(4) C表示事件之间的控制关联,它是上述点之间的有向边的集合,线条出发点为控制事件,箭头指向为被控事件。一条边(vi,vj)∈C,当且仅当vi事件代码凭借某种数据结构控制事件vj的运行。

(5) R表示事件之间的公共关联,它是上述点之间的无向边的集合。一条边(vi,vj)∈R,当且仅当事件vi与事件vj共同操纵某一共享数据区域。

图3为总单入库界面的事件关系流图,由于交互关系很多,图中只画出了其中的一小部分,事件流图中,用$\underrightarrow{\text{C}}$表示事件之间的交互关系,用$\underrightarrow{\text{C}}$表示事件之间的控制关联,用$\underrightarrow{\text{R}}$表示事件之间的公共关联。

1.4 事件程序控制流图

为了在GUI测试中提高底层代码的覆盖率,根据每个事件的程序代码,画出能反映事件程序内部逻辑结构的程序控制流图,它包括程序内类方法之间的调用关系。利用它来评价测试用例的代码覆盖程度以及添加能提高代码覆盖率的测试用例。

图4给出了总单入库界面中submit_click事件的事件程序控制流图。

2 测试用例生成方法

定义4 一个GUI测试用例T是由初始状态和一个合法事件序列组成的状态事件序列对<S0, e1,e2, …,en>,S0是测试用例T执行之前必须达到的一个合法初始状态,e1,e2, …,en 是一个合法事件序列。

本文结合黑盒测试和白盒测试思想,提出了复合性测试用例生成方法,它由五个步骤组成,本方法在保证了功能覆盖的情况下,提高了底层代码的覆盖率。

步骤一:常用任务测试

采用文献[3]中的规划技术产生测试用例。测试设计者提供了常用任务的初始状态和终止状态的说明,规划系统为每个指定任务产生规划。每个产生的规划表示一个测试用例。

表1为文献[3]中的测试用例生成过程,先定义规划算子,再产生规划,而在本文中,把每个事件作为一个算子,而且它的前置条件和动作结果已经在界面的对象-事件分析图中定义,所以,在测试用例生成阶段,只有产生规划的过程(见表2)。

步骤二:边界及错误情况测试

对于事件关系流图中两类关联分别构造测试用例。对于控制关联,构造测试用例对控制变量的边界情况以及错误情况进行覆盖。对于公共关联,构造测试用例对公共变量或数据区域的边界值以及错误情况进行覆盖。用这些测试用例来检验程序在这些特殊情况下的工作情况,以模拟用户在不明了操作步骤情况下的误操作,查看程序是否有足够的容错能力。

例如:图3中的输入总运单号事件(Input_mawbSn)和提交事件(submit_click)之间的控制关联关系,它的边界情况及错误情况是总运单号输入有误或总运单号为空,为其构造的测试用例:Input_mawbSn,submit_click; submit_click。

步骤三:结构化覆盖

用结构化覆盖准则确定步骤一和步骤二产生的测试用例的结构化覆盖程度。没有测试到的事件序列可以用结构化测试方法产生测试用例测试。

本文中把结构化覆盖准则分为两类:界面间覆盖准则及界面内覆盖准则。

界面间覆盖准则:

(1)界面调用关系图覆盖准则:强调了界面之间的关系。

单边覆盖:界面关系图中所有属于E的边所对应的打开界面事件和所有属于R的边所对应的终止界面事件至少被执行一次。

往返边覆盖:一条表示调用关系的边和它对应的表示终止关系的边构成了往返边。打开界面事件和对应的终止界面事件构成的任意有序对至少有一个事件序列能包含它。

(2) 长度为n的事件序列覆盖准则。

界面之间长度为n的事件序列覆盖准则要求测试所有从一个界面中的事件开始结束于另一个界面中的长度为n的事件序列。

界面内覆盖准则:

(1) 事件覆盖:界面内的每一个事件至少被执行一次,即事件关系流图中每个结点至少被覆盖一次。

(2) 事件交互覆盖:检查界面中可能的两两事件之间的交互关系。这个准则要求当事件v 执行后,所有与v交互的事件至少被执行一次。即事件关系流图中每条有向边至少被覆盖一次。

(3) 长度为n的事件序列覆盖:某些情况下,事件在不同的上下文中执行时,其行为可能会有所变化。在这类情况下,只用事件覆盖和事件交互覆盖对于充分测试来说是不够的。事件v的上下文就是在事件v之前执行的事件序列。这个事件序列可能是无穷大的,为了在有穷的情况下应用,定义了长度为n的事件序列。

定义5 事件序列集合P满足长度为n事件序列覆盖,当且仅当P包含了所有长度为n的事件序列。

(4) 关联关系覆盖:对事件关系流图上的控制关联关系和公共关联关系进行覆盖,即对于控制关联,构造测试用例对控制变量的边界情况和错误情况进行覆盖;对于公共关联,构造测试用例对公共变量或数据区域的边界值以及错误情况进行覆盖。

步骤四:基本路径覆盖

根据基本路径覆盖准则,对前三步得到的测试用例进行扩充。对于每一条测试用例,利用控制流图,看能否对其扩充,使它变为多条测试用例,尽可能多地覆盖不同的基本路径。

基本路径覆盖准则:对于程序控制流图中的每一条简单路径,至少有一条测试用例对其覆盖。

例如:测试用例 Input_mawbSn, Input_position, Input_positionQuantity, submit_click;

利用submit_click事件程序控制流图扩充测试用例,使submit_click程序的三条基本路径被覆盖。则可变为如下三条测试用例:

(1) Input_mawbSn(输入错误的总运单号或者不输入), Input_position, Input_positionQuantity(=总件数-当前库位件数总和),click_submit;

(2) Input_mawbSn(输入正确的总运单号), Input_position, Input_positionQuantity(≠总件数-当前库位件数总和), click_submit;

(3) Input_mawbSn(输入正确的总运单号), Input_position, Input_positionQuantity(=总件数-当前库位件数总和), click_submit;。

步骤五

若扩充后测试用例还未能达到设定的基本路径覆盖阈值,选择新的测试用例对其覆盖。

3 测试实例与分析

利用“SD空运物流进出口业务处理系统”中的入库作业模块、出库作业模块两个测试单元作为实验对象,对于每个测试单元,分别估算利用PATHS系统、复合性测试用例生成方法产生的测试用例的不同覆盖率,如表3所示。

由表3可知,利用复合性测试用例生成方法生成的测试用例,其界面间、界面内以及程序内部逻辑的覆盖率都要比使用PATHS系统生成的测试用例的对应覆盖率高。

4 结束语

现在GUI程序占据日趋重要地位,但对这些系统的测试仍然存在形式化程度低、规范性差和缺乏客观测试评判标准的缺点。由测试人员根据设计书凭借经验设计的测试用例具有随机性大、错误检验能力低的缺点。而本文通过研究设计书和代码构造的四种不同层次的模型,对GUI进行了详细分析,基于它们产生的测试用例可以测试出更多类型的错误,甚至一些隐藏的可能导致系统崩溃的错误,不管对于GUI结构还是底层代码的覆盖率都比较高。与一般GUI测试相比,测试的充分性和准确性有了很大的提高。

摘要：通过研究GUI(图形用户界面)软件的规格说明、GUI结构、GUI代码,构造用于GUI测试的四种不同层次的GUI表示方法,该表示方法可以描述界面间关系的界面调用关系图、界面信息的对象-事件分析图、界面内事件间关系的事件关系流图以及程序内部逻辑结构的事件程序控制流图,在此基础上提出了基于这些模型的复合性测试用例生成方法,并用实例说明该方法的有效性。

关键词：软件测试,图形用户界面,测试用例生成,事件

参考文献

[1]Atif MMemon.GUI Testing:Pitfalls and process[J].IEEE Comput-er,2002,35(8):90- 91.

[2]Memon M,Pollack M E,M L.Soffa,Using a goal-driven approach togenerate test cases for GUIs[C].In Proceedings of the 21st Interna-tional Conference on Software Engineering,P,ACMPress,May1999:257 -266.

[3]Atif M Memon,Martha E Pollack,Mary L Soffa.Hierarchical GUI testcase generation using automated planning[J].IEEE Transactions onSoftware Engineering,2001,27(2):144- 155.

[4]Marlon Vieira,Johanne Leduc,Bill Hasling.Automating of GUI TestingUsing a Model-driven Approach[C].In Proceedings of AST’06,Shanghai,China 2006,23(6)9 -14.

[5]刘超.程序交互执行流程图及其测试覆盖准则[J].软件学报,1998,9(6):458 -463.

平台用户使用测试报告 第2篇

平台是2014年建成，2015年1月开始面向在市气象台投入试运行，经过半年的在业务中试运行，员能充分利用气象材料管理平台检索和发布服务材料，并能再日常气象服务中得到帮助，及时查看本地信息，目前该平台已为日常使用的主要平台之一。

平台软件是一个完整的气象服务管理系统，可以发布气象服务信息、存储并管理所有气象服务信息。该平台采用了Web的方式对各类气象业务进行全面地管理，用户界面十分友好，操作起来非常简便。从气象服务的发布使用和管理的流程出发，平台的功能包括发布气象服务材料的管理，对各种气象服务材料的浏览和检索、气象自动资料的实时显示系统、系统后台管理、气象材料统计、用户管理等主要功能。

用户在使用各自的用户名登录界面进行气象材料的浏览时，可以按照观测、预报、气象材料类型等多种分类方式来分层浏览各类丰富的气象材料。左边以树形目录显示各类气象材料，在显示气象材料列表时也可以按照材料的时间、类型进行过滤显示，极大地方便了用户对材料的浏览，同时用户也可以查看每个气象材料的属性信息，并对所需气象材料进行播放和下载，也可以运用气象材料插入到Office软件中。支持多类型气象材料，支持多文件格式。气象材料检索平台使我们能够通过多种途径检索到所需的气象材料，方便实用，在功能上几乎涵盖了气象材料管理的各个方面，满足气象材料建设、管理和应用等需要，是建立分布式气象材料管理环境的有效工具。

用户界面测试 第3篇

关键词 学术资源发现系统 用户体验 用户体验度量

分类号 G254.97

1 背景

近几年来，网络学术资源发现与获取系统（Resources Discovery and Delivery System，以下简称“发现系统”）被愈来愈多的图书馆及信息机构所采用。发现系统作为一种专业学术搜索服务，通过签署协议，收集各类学术文献信息，形成集中的元数据仓储，并为读者提供“一站式”学术搜索服务。全球较为知名发现系统有：ProQuest公司旗下Serials Solutions公司的Summon（简称Summon）、Exlibris公司的Primo和Primo Central（简称Primo）、EBSCO公司的EBSCO Discovery Service（简称EDS）、OCLC 的WorldCat Local（简称WCL）以及Innovative公司Encore Synergy，CALIS的“e读”、超星公司的“超星中文发现”等。

如何从众多的资源发现系统中选型和决策，业界同行对发现系统展开多方面的比较与研究。窦天芳等探讨发现系统的逻辑结构、核心功能、体系架构[1]，秦鸿等对系统的元数据、架构与功能、检索与界面、商务因素等进行了详尽的比较[2]，山东大学图书馆从用户功能性指标、网络技术、教学科研支撑等方面进行评估[3]。上述研究强调了发现系统的差异，但却忽视两个方面的因素。一方面，发现系统的整体共性越来越多，日益趋向于“同质化”；另一方面，已有的发现系统研究多从图书馆自身想法出发，忽视了发现系统的用户——读者。发现系统用户是广大读者，其年龄、学科背景、知识结构、所处环境等方面各不相同，因此用户对发现系统的感知与认知也不尽相同。在发现系统“同质化”的趋势背景下，发现系统的比较与选型应充分考虑“用户体验”这一因素，而不仅仅是专业馆员的内部分析。与此同时，读者用户体验参与，其多样性恰好弥补了专业馆员单一背景的不足。

基于此，笔者所在团队在日趋“同质化”的发现系统产品的评估与选型过程中，引进用户体验概念，并开展“发现系统的用户体验测试”，以期测试结果为选购决策提供有力支持，并在今后的引进过程中提出相应的改进意见。

2 用户体验

用户体验（User Experience）根据国际标准化组织（International Organization for Standardization）ISO9241-210的定义为“用户在使用或期望使用一个产品、系统、或者服务的感知和回应”。即用户在使用一个产品（设备、系统或服务）之前、使用中、使用后的全部感受，包括情感、情绪、认知、生理和心理反应、行为等各个方面。

一般来说，用户体验测试主要是借助定性和定量的方法，对用户使用产品时的个人生理、心理和行为等相关指标进行研究，揭示用户与产品之间交互的有效性、效率或满意度等。从被试选择角度，用户体验可分为两类：一类是用户评价（User-based Evaluation），有时也称用户测试；另一类是专家评价（Expert-based Evaluation）。用户测试即为用户提供一系列操作场景和任务让他们去完成，以发现产品（或业务）中的错误和缺失（经验数据：7个用户就可以找到80%以上的可用性问题）；专家评价由多个业内专家根据一些通用的可用性原则和自己的经验来发现系统内潜在的可用性问题（经验数据：5个专家能找到大约75%的可用性问题）[4]。

用户体验的测试与评价方法有情景调查、焦点小组、可用性度量、日志文件分析、问卷调查表等，以及基于用户行为和生理度量的方法，如眼动追踪评价、行为观察、脑电信号[5]。其中用户体验问卷调查表是一种费用少、管理人员和用户双方都能接受的方法，即问卷调查表由一系列可用于评价用户体验的具体问题组成，这些问题经过标准化和系统化处理，评估人员据此分析，找出并明白产品（系统或服务）中的优质部分、缺陷部分，以及有待提高的部分等方面。针对信息系统用户体验度量常用的问卷调查表有：John Broke编制的系统可用性量表（SUS）[6]，Jim Lewis编制的任务后评分用的情景后问卷（ASQ），计算机系统可用性问卷（CSUQ）[7]和研究后系统可用性问卷（PSSUQ）[8]。其中PSSUQ针对当面进行测试而设计，CSUQ则是针对邮件或在线测试而设计，二者非常类似，用于分析系统有效性（System Usefulness）、信息质量（Information Quality）、界面质量（Interface Quality）和总体性满意度（Overall Satisfaction）。

3 用户体验测试研究设计及数据处理

本研究采用用户体验+问卷调查方法，通过用户实际体验后填写调查问卷。笔者团队对收集到的数据利用SPSS 17.0版软件进行统计分析，并对数据进行归一化（Normalization）处理。

3.1 用户研究

根据所在机构特性，确定和描述将要使用发现系统主要用户的特征及行为特点。基于所在机构的性质与特点，发现系统的主要用户是大学本科二、三、四年级学生、一、二年级硕士（或博士）研究生，年龄约为18至28岁之间。他（她）们年轻，有一定的专业知识基础，熟练掌握计算机，了解并熟悉图书馆的功用及网络服务，且有一定的学业和科研压力，求知欲望强烈，需要通过检索和阅读扩展知识面，解决学习中遇到的问题。

发现系统的目标用户未包括所属机构的大学本科一年级新生和高年级研究生与教师。这是因为大学新生刚入校不久，未掌握基本的专业知识，有些甚至不了解图书馆的功用，不会使用OPAC或电子数据库，而高年级研究生及教师专注研究，长期只关注本领域的3～5种专业学术期刊或3～5位专家，较少关注基础性的学科知识检索。

3.2 变量测量及问卷设计

发现系统用户体验测试是对不同厂商的发现系统进行比较。按照用户体验进程一般是从感知到认知，再到情感体验[9]，测试重点是：（1）系统能力（System Capability），其可细化为响应速度、结果数量、元数据质量等；（2）信息质量（Information Quality），即检索结果排序是否符合用户的期望，用户关注的主题和内容在首页中的比例；（3）用户满意度（User Satisfaction），在使用过程中，用户感知的系统灵活性、便利性和整体性能。

调查问卷分为4个部分。第一部分针对系统能力；第二部分针对用户感知的信息质量；第三部分是用户满意度；第四部分需要用户投票选择偏好的发现系统，并简单陈述理由。问卷中有4道题采用二分式度量，其余的测试采用5点式Likert量表形式。

3.3 测试过程

本次用户体验选用三家知名厂商的发现系统进行互联网测试，分别以A系统、B系统、C系统代指；本次测试共有40名低年级研究生参加，分属19个学院，其中理工科背景的学生20人，医学专业学生4人，文科背景的学生16人。

参加被试人员各自准备6个检索词，分别输入3个不同的发现系统，每完成1次检索，即填写表格测试选项。被试人员在完成“系统能力”和“信息质量”测试后，再完成第三部分和第四部分。整个过程完成约为60分钟。

被试输入的检索词共有240个，其中中文检索词140个（重复3个），英文检索词97个（重复2个），中英文混合的检索词3个。

4 数据分析

4.1 系统能力

发现系统能力实际是用户在使用过程中度量系统的性能，其调查变量是发现系统的单次检索过程和结果。本文用“检索速度”“检索结果数量”“数据重复性”“显示的检索结果数据完整性”等四个指标来衡量发现能力。通过测试，我们发现A系统的各项调查变量较其他系统低（参见图1）；B 系统的数据清洗工作方面做得比较好；C系统在“检索速度”“检索结果数量”“显示的检索结果数据完整性”等3方面占优，但数据清洗工作不如A系统和B系统。

4.2 信息质量

发现系统信息质量实质是度量系统的检索结果能否符合用户（即检索者）的期望，帮助用户“发现”所需文献，而不是简单的关键词匹配结果。通过测试，我们发现A系统的各项调查变量较其他系统低（参见图2）；B系统在“检索者关注的主题在分面中呈现”方面占优，说明B系统在检索主题提取与筛选方面工作做得比较好；C系统在“检索结果页面中相关经典文献呈现”“检索者关注的内容在检索结果首页呈现的比例”等方面占优，说明C系统检索结果筛选和排序优于A系统和B系统，其“发现”效果更佳。信息质量调查变量的Cronbachα为0.65，属于中上信度。

4.3 用户满意度

发现系统的用户满意度测试是度量用户的情感接受。通过测试，B系统和C系统的用户满意度较A系统高（参见图3）。其中B系统在“检索结果分面灵活性”单项变量占优，说明B系统在检索主题聚类与识别方面做得比较好；C系统在“全文获取流程方便性”“发现系统整体性能”等方面领先，说明C系统在流程设计较好，较其他系统使用起来更为便利。需要指出的是，C系统检索结果中，与用户检索词有关的经典文献在页面中呈现的比例较高，这有助于用户学习过程中阅读学科经典文献，也有助于所在机构推广核心馆藏。用户满意度调查变量的Cronbachα为0.708，信度较高。

4.4 用户偏好及理由

测试的第四部分是被试者根据自己的用户体验和偏好进行选择。其中A系统得票4.5票，占比11.25%；B系统得票16.5票，占比41.25%；C系统得票19票，占比47.5%。另外，68.75%的文科背景被试人员选择了C系统，50%理科背景被试人员选择了B系统。

通过对用户体验和偏好选择理由的分析发现，用户比较看重的体验在于以下几个方面。（1）系统界面的友好度。页面整洁、操作简单、检索结果页面上显示比较全面（如作者、出版年、期、卷、馆藏位置等信息）的系统更令用户偏爱。（2）系统的检索速度。在信息化时代，用户总是希望在最短的时间内获得自己所需的信息，系统检索速度的快慢是影响用户偏好选择的重要原因之一，这也是大部分用户摒弃A系统的原因。（3）检索结果的相关度排序。在用户喜好理由中“检索结果相对精确”“准确率高”“相关度高”等出现的频率比较高。（4）文献重复率。用户更倾向于重复率低的系统。

5 结语

本文的用户体验测试结果表明，发现系统的用户满意度受系统的信息质量影响大，个别检索结果元数据重复并没有影响整体用户满意度；不同发现系统的元数据仓储在超过一定数量后，系统间的差异减弱；不同学科背景的被试人员偏好稍有不同，尽管还没有更多的数据来解释，但是也说明不能忽视发现系统的研究者和评估者的学科背景、个性需求和体验。本次用户测试体验证明将用户体验变成可以度量的行为和态度，在一定程度上能够反映不同厂商发现系统的优势与缺陷。

随着技术发展与进步，现有不同厂商的发现系统正在趋向“同质化”，因此资源发现系统的选型成为一项挑战性的工作。由于各个系统都有优缺点，图书馆不仅要考虑馆内各系统与资源的整合需求，还要考虑系统性能、数据质量、检索能力等综合因素，更重要的是开展各种用户体验测试，调查用户对资源发现系统的感知与功能期望，并将用户普遍反馈的功能期望作为评价的重要指标[10]。

在信息服务中，好的产品在注重服务内容和质量的同时，更要注重情感的愉悦和满足，确保产品工作起来顺畅，用户心情愉悦，不会感到无助和挫折。信息用户已不再满足于被动地接受信息服务机构的诱导和操纵，而是愿意主动地参与到信息服务之中。越来越的用户希望能够和信息服务机构一起，按照自身的需求获取满意的服务，通过创造性消费来体现他们独特的个性，使他们获取自我实现的新途径，从而获得更大的成就感和满足感。因此，提供学术信息检索“一站式”服务的发现系统也应满足读者的用户体验需求，不仅要在选型的初期进行用户体验测试，而且还要在确定选型以后的日常使用中也要邀请用户积极参与进来进行系统的测试与评估，及时掌握用户的使用状况和使用反馈意见，通过与发现系统厂商积极沟通和协作，不断完善和改进系统，使系统逐渐满足用户个性化需求。

参考文献：

[ 1 ] 窦天芳，姜爱蓉.资源发现系统功能分析及应用前景[J].图书情报工作，2012（7）：38-43.

[ 2 ] 秦鸿，钱国富，钟远薪.三种发现服务系统的比较研究[J].大学图书馆学报，2012（5）：5-11，17.

[ 3 ] 廖静.山东大学图书馆资源发现系统评估工作的摸索与实践[J].图书情报工作，2013（9）：52-57.

[ 4 ] 李仲侠，么遥，王灵芝.移动终端的用户体验研究[J].信息通信技术，2012（4）：12-17.

[ 5 ] Tullis T， Albert B. 用户体验度量[M].周荣刚，等，译.北京：机械工业出版社，2009：45-55.

[ 6 ] Broke J. SUS：A quick and dirty usability Scale[EB/

OL].[2015-04-15].http：//www.doc88.com/p-5748144

246297.html.

[ 7 ] Lewis J R.IBM computer usability satisfaction questionnaire：Psychometric evaluation and instructions for use[J].International Journal of Human-Computer Int-

eraction，1995，7（1）：57-78.

[ 8 ] Lewis J R. Psychometric evaluation of the post-study system usability questionnaire：The PSSUQ[C]. Santa Monica：Proceedings of the Human Factors Society 36th Annual Meeting，1992：1259-1263.

[ 9 ] 李皓，姜锦虎.网站使用中用户体验过程模型及实证研究[J].信息系统学报，2011（9）：55-65.

[10] 朱前东.国外资源发现系统评价策略研究[J].图书与情报，2014（4）：6-10.

王海花 兰州大学图书馆馆员。甘肃兰州，730000。

陆为国 兰州大学外事处副研究馆员。甘肃兰州，730000。

用户界面测试 第4篇

图形用户界面 (Graphical User Interface) 是指采用图形方式显示的计算机操作用户接口。随着人机交互理念的不断发展, 越来越多的程序开发建立在图形用户界面上。基于图形用户界面的程序开始逐步取代基于纯命令行操作的程序, 成为主流。苹果公司无疑是这方面的先驱之一, 1984年苹果公司发布了Macintosh。自那以后图形用户界面越来越流行。近几年来苹果公司发布的IPhone, IPad无疑使图形用户界面上了一个更高的层次。

与此同时, 由于图形用户界面的普及, 图形用户界面的测试也显得愈发的必要。一个好的图形用户界面测试可以使整个程序更安全, 更健壮。值得指出是:在程序维护阶段, 图形用户界面测试也同样重要。因为在这一阶段, 程序代码可能被大量的修改、重构, 而相当一部分代码是与图形用户界面相关的。为了避免意外的代码改变引入新的臭虫 (bug) , 一个好的图形用户界面测试也是非常有必要的

1 图形用户界面测试

随着图形用户界面技术的成熟, 现如今图形用户界面测试的过程中越来越客观。现阶段的图形用户界面测试主张把功能测试与界面测试分开, 这样做在降低耦合度的同时, 也降低了测试工作量, 功能测试主要是指验证系统是否实现了系统的业务需求, 旨在验证系统的业务实现能力。而图形用户界面测试主要关注图形用户界面组件是否符合规范或用户的操作习惯。需要测试人员在界面测试中注意的是图形用户界面的测试是不可能脱离功能而独立进行的:它是随着功能的实现, 一个一个窗口进行校验的, 也可以和功能测试一起测试。

图形用户界面测试一般可以分为两个部分:确认测试是指对用户操作界面的操作进行测试, 主要考虑的是输入数据的合法性。这里的合法性主要是指用户的输入数据是不是有效数据, 用户的非预期性操作是不是可以正确的处理等。这部分测试主要根据用例文档来设计测试用例, 形成测试文档后, 进行测试并编写测试报告。

功能相关测试指的是根据需求说明书或者功能说明书所涉及的功能进行测试。这期间, 随着一个个功能的实现, 各个功能的界面测试也可以随之进行。

2 FEST-Swing测试

FEST-Swing一个开源的, 免费的用于图形用户界面测试的JAVA类库。它提供了一系列易于使用的应用程序编程接口 (API) 供软件开发和软件测试人员使用。一个典型的FEST-Swing测试流程见图1所示。

2.1 确认测试

在确认测试过程中, 设计以下测试用例:1) 测试用户输入用户名字段时输入以非字母开头的用户名 (这里假设用例文档规定用户名必须以英文字母为首字母) ;2) 测试用户输入的电子邮件是否符合电子邮件的基本条件;3) 测试用户输入的用户名字段时输入了空格的结果;4) 测试用户输入用户名字段时输入的用户名超过允许的长度 (这里假设用例文档规定用户名长度不能超过8个字符) ;5) 测试用户输入的用户名字段时输入NULL等可能对后台有特殊意义的字符。

值得指出的是, 由于FEST-swing等用户图形界面测试工具只能对可以代码化的部分进行测试, 还有相当一部分需要手工测试, 比如当运行程序时, 光标应默认停留在第一个待输入的文本框中;或者Tab键可以使焦点按照业务逻辑的顺序在各个控件中切换。这些都是确认测试的一部分。

2.2 功能测试

在功能测试过程中, 设计以下测试用例:1) 测试输入用户名已经存在的情况——在提交后应返回提示信息该用户名已存在, 并返回提示用户重新输入用户名, 焦点停留在用户名的输入框;2) 测试输入电子邮件已经存在的情况——提交后应返回提示信息改邮箱已经被注册, 并返回提示用户重新输入信的邮箱, 焦点停留在电子邮件的输入框。由于这里的小程序比较简单, 所以这部分功能测试相对比较简单。

3 结论

可以看到, FEST-swing是一个非常简便的可用于图形用户界面测试的工具。它不仅能够用于确认测试过程中, 也能够用于功能测试过程中。它的存在能够有效降低图形用户界面测试的测试难度, 提高效率。

在以下情况下, 我们可以考虑使用FEST-swing进行GUI测试:1) 对于需要使用TestNG进行测试的案例, 推荐使用FEST-swing;2) 不介意在现有代码中加入“冗余”代码的测试案例。

在以下情况下, 不建议推荐使用FEST-swing进行GUI测试:1) 对代码的冗余度要求极高, 不希望存在“冗余”的代码。2) 运用自定义开发GUI控件的测试案例。由于FEST-swing只支持对标准的JDK所支持的控件进行测试, 所以自定义GUI控件的测试没有办法在FEST-swing中进行。

用户界面测试 第5篇

目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。

1：易用性：

按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。

易用性细则：

1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。

2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。

3):按功能将界面划分局域块，用Frame框括起来,并要有功能说明或标题。

4):界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。

5):界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。

6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。

7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab

8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。

9):可写控件检测到非法输入后应给出说明并能自动获得焦点。

10):Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。

11):复选框和选项框按选择几率的高底而先后排列。

12):复选框和选项框要有默认选项，并支持Tab选择。

13):选项数相同时多用选项框而不用下拉列表框。

14):界面空间较小时使用下拉框而不用选项框。

15):选项数叫少时使用选项框，相反使用下拉列表框。

16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。

2： 规范性：

通常界面设计都按Windows界面的规范来设计，即包含―菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单‖的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢。

规范性细则：

1):常用菜单要有命令快捷方式。

2):完成相同或相近功能的菜单用横线隔开放在同一位置。

3):菜单前的图标能直观的代表要完成的操作。

4):菜单深度一般要求最多控制在三层以内。

5):工具栏要求可以根据用户的要求自己选择定制。

6):相同或相近功能的工具栏放在一起。

7):工具栏中的每一个按钮要有及时提示信息。

8):一条工具栏的长度最长不能超出屏幕宽度。

9): 工具栏的图标能直观的代表要完成的操作。

10):系统常用的工具栏设置默认放置位置。

11):工具栏太多时可以考虑使用工具厢。

12):工具厢要具有可增减性，由用户自己根据需求定制。

13):工具厢的默认总宽度不要超过屏幕宽度的1/5。

14): 状态条要能显示用户切实需要的信息，常用的有：

目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提示。

15)：滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。

16)：状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。

17)：菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感。

18)：菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。

19):右键快捷菜单采用与菜单相同的准则。

3：帮助设施：

系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。

帮助设施细则：

1)：帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明，让人困惑)。

2)：打包新系统时，对作了修改的地方在帮助文档中要做相应的修改。

3)：操作时要提供及时调用系统帮助的功能。常用F1。

4)：在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。

5)：最好提供目前流行的联机帮助格式或HTML帮助格式。

6)：用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。

7)：如果没有提供书面的帮助文档的话，最好有打印帮助的功能。)：在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。

4：合理性：

屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。

合理性细则：

1)：父窗体或主窗体的中心位置应该在对角线焦点附近。

2)：子窗体位置应该在主窗体的左上角或正中。

3)：多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。

4)：重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。

5)：错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点位置。

6)：与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。

7)：对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。

8)：非法的输入或操作应有足够的提示说明。

9): 对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。

10):提示、警告、或错误说明应该清楚、明了、恰当。

5：美观与协调性：

界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。

美观与协调性细则：

1): 长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。

2): 布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。

3): 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。

4): 按钮的大小要与界面的大小和空间要协调。

5): 避免空旷的界面上放置很大的按钮。

6)：放置完控件后界面不应有很大的空缺位置。

7): 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。

8): 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。

9): 如果使用其他颜色，主色要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。

10): 大型系统常用的主色有“#E1E1E1”、“#EFEFEF”、“#C0C0C0”等。

11): 界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。

12): 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。

13)：对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。

14): 通常父窗体支持缩放时，子窗体没有必要缩放。

15)：如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。

6：菜单位置：

菜单是界面上最重要的元素，菜单位置按照按功能来组织。

菜单设测试细则：

1)：菜单通常采用―常用--主要--次要--工具--帮助‖的位置排列，符合流行的Windows风格。

2):常用的有―文件‖、―编辑‖，―查看‖等，几乎每个系统都有这些选项，当然要根据不同的系统有所取舍。

3):下拉菜单要根据菜单选项的含义进行分组，并切按照一定的规则进行排列，用横线隔开。

4): 一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。

5): 没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头，不常用的靠后放置；重要的放在开头，次要的放在后边。

6): 如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。

7): 菜单深度一般要求最多控制在三层以内。

8): 对常用的菜单要有快捷命令方式，组合原则见8。

9):对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式——即只有需要的菜单才显示——最好。

10)：菜单前的图标不宜太大，与字高保持一直最好。

11):主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。

12)：主菜单数目不应太多，最好为单排布置。

。7:独特性：

如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己

独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。

1):安装界面上应有单位介绍或产品介绍，并有自己的图标。

2):主界面，最好是大多数界面上要有公司图标。

3):登录界面上要有本产品的标志，同时包含公司图标。

4):帮助菜单的―关于‖中应有版权和产品信息。

5):公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。

8：快捷方式的组合在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些 在西文Windows及其应用软件中快捷键的使用大多是一致的。

菜单中：

1):面向事务的组合有:

Ctrl-D 删除 ；Ctrl-F 寻找 ；Ctrl –H替换；Ctrl-I 插入 ；Ctrl-N 新记录 ；Ctrl-S 保存 Ctrl-O 打开。

2)：列表:

Ctrl-R，Ctrl-G定位；Ctrl-Tab下一分页窗口或反序浏览同一页面控件。

3):编辑:

Ctrl-A全选；Ctrl-C 拷贝；Ctrl-V 粘贴；Ctrl-X 剪切；Ctrl-Z撤消操作；Ctrl-Y恢复操作。

4)文件操作:

Ctrl-P 打印；Ctrl-W 关闭。

5):系统菜单

Alt-A文件；Alt-E编辑；Alt-T工具；Alt－W窗口；Alt－H帮助。

6):MS Windows保留键:

Ctrl-Esc 任务列表 ；Ctrl-F4 关闭窗口； Alt-F4 结束应用；Alt-Tab 下一应用 ；Enter 缺省按钮/确认操作 ；Esc 取消按钮/取消操作 ；Shift-F1 上下文相关帮助。

按钮中：

可以根据系统需要而调节，以下只是常用的组合。

Alt-Y确定(是)；Alt-C取消；Alt-N 否；Alt-D删除；Alt-Q退出；Alt-A添加；Alt-E编辑；Alt-B浏览；Alt-R读；Alt-W写。

这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。

9:安全性考虑：

在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。

安全性细则：

1)：最重要的是排除可能会使应用非正常中止的错误。

2)：应当注意尽可能避免用户无意录入无效的数据。

3)：采用相关控件限制用户输入值的种类。

4)：当用户作出选择的可能性只有两个时,可以采用单选框。

5)：当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。

6)：当选项特别多时，可以采用列表框，下拉式列表框。

7)：在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。

8)：对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。

9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。

10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。

11)：对错误操作最好支持可逆性处理，如取消系列操作。

12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。

13):对可能造成等待时间较长的操作应该提供取消功能。

14)：特殊字符常有；;‘‖><,｀‗：―［‖｛、|｝］+=)-(_*&&^%$#@!~,.。?/还有空格。

15)：与系统采用的保留字符冲突的要加以限制。

16)：在读入用户所输入的信息时，根据需要选择是否去掉前后空格。

17)：有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。

10:多窗口的应用与系统资源：

设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。

1)： 在多窗口系统中，有些界面要求必须保持在最顶层，避免用户在打开多个窗口时，不停的切换甚至最小化其他窗口来显示该窗口。

2)：在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS系统资源。

3)：关闭所有窗体，系统退出后要释放所占的所有系统资源，除非是需要后台运行的系统。

人机界面设计的评价测试分析 第6篇

人机界面评价就是把构成人机界面的软、硬件系统按其界面形式、功能、性能、可使用性等方面与预定的标准进行比较, 对其做出评价。新一代的计算机用户, 在应用软件的可操作性以及软件操作的舒适性等方面对应用软件提出了更高的要求。并且, 人机界面的质量已成为一个大问题, 界面的操作是否简单、方便、自然直接关系到人们的工作效率。因此, 友好的人机界面设计评价与测试已经成为应用软件开发的重要组成部分[1]。

1 人机界面测试与评价的意义

每个软件在交付使用之前都要进行评价与测试。系统评估是指人们把构成的软件系统按其可使用性、功能、性能等方面与预定的标准进行比较, 以对所构造的系统作出评价。用户界面评估是指人们对在用户和计算机系统之间起桥梁作用的界面表现方式及人机交互效率进行评价, 以确定用户界面是否满足用户使用的要求[2]。

一个成功的计算机系统离不开一个成功的用户界面, 而成功的用户界面离不开对界面的评估。对用户界面的测试和评估可以起到以下作用:减少由于界面问题而引起的软件修改和改版问题;降低系统技术支持的费用, 缩短最终用户训练时间;帮助系统设计者更深刻地领会以“用户为中心”的设计原则;使软件产品的可用性增强, 用户易于使用;更有效地利用计算机系统资源;在界面测试与评价过程中形成的一些评价标准和设计原则对界面设计有直接的指导作用。

2 人机界面设计的评价指标

2.1 设计问题的诊断

诊断性评价是鉴别和划分具体问题的范围的一种系统化方法。它和效果评价的不同点在于它致力于具体设计决策产生的副作用。一般, 它们通过人机之间的交互对话来观察界面, 当对话突然中断或产生了一个没有预料的转折时, 则确认并调查交互时的错误。

2.2 设计功能的评价

第一类指标是通过对设计功能与用户需求的比较而评价其功能的。它通常由两条途径而实现, 一种是面向系统的, 另一种是面向用户的。前者是评价系统和界面的特性, 并将它们与用户的特性需求相匹配, 因此也可以称为特性方法。这两条途径实质上是分别将自顶向下、自底向上的方法与涉及界面的不同层次的设计相联系。后者采用用户使用系统和界面所能完成的任务以及该任务满足用户任务需求的程度来评价设计的功能, 因此也可以称为任务方法[3]。

上述的两条途径各有千秋, 但很明显, 任务方法比之特性方法更加强调以用户为中心。首先, 特性方法必须假定对于部分用户或评价人员已经事先掌握了有关设计可能选择的范围及可行性的知识, 而任务方法只需要假定他们熟悉将要执行的任务范围。其次, 任务方法有利于加强设计和评价的联系, 因为不论设计如何变化, 均可以在任何阶段针对当前的用户需求说明评价所出现的设计。另一方面, 特性方法是通过对用户提供设计选择的约束, 潜在地对用户自行实现用户需求的方式进行更加直接的控制。与其他两类指标相比, 第一类指标的评价需要和软件系统两者同时更多地参与评价。

2.3 设计效果的评价

第二类指标是鉴别界面设计对用户以及用户与系统的交互影响。在这里, 预期效果和意外效果都很重要, 前者指设计者根据设计的本质要求得到或期望得到的效果, 后者则可能是作为某一项特殊设计的代价而产生的, 或者是采用不同组合的设计特性的结果[4]。

大多数以用户为中心的评价, 无论是建立在可靠的理论基础之上, 并且在精心控制的步骤下测试, 还是来自于对某一功能的期望, 并进行非正式的测试, 它们都把效果的评价作为它们的指标。在界面设计的评价中, 尤其令人重视的主要效果是指用户方面需要多大的努力才能方便地运用系统的功能[5]。

3 人机界面的设计评价方法

3.1 实验评价法

对于一些较重要的方案环节, 有时要通过实验对方案进行评价, 这样试验评价法所得到的评价参数准确, 但代价较高。

3.2 虚拟仿真评价法

虚拟仿真评价法是一种重要的评价方法, 它允许在实施界面设计之前对它进行评价。一旦系统完成后再对它进行较大的修改是困难的, 要花费很多的人力、成本和时间。采用虚拟评价方法, 能够近早地修改设计, 也可以节省费用[6]。

3.3 经验性评价法

当方案不多, 问题不太复杂时, 可以根据评价者的经验, 采用简单的评价方法对方案作定性的粗略分析和评价。如采用淘汰法, 经过分析, 直接去除不能达到主要目标要求的方案或不相容的方案[7]。

3.4 数学分析类评价法

运用数学工具进行分析、推导和计算, 得到定量的评价参数的评价方法, 如名次记分法、评分法、技术经济法及模型评价法等。

4 结束语

由于受传统观念的影响, 很长一段时间里, 人机界面的评价测试一直不为软件开发人员所重视, 没有任何经济价值。本文介绍了人机界面设计测试的意义, 评价人机界面的指标, 以及人机界面的评价方法, 旨在为解决人机界面评价的相关问题提供良好的理论依据。

参考文献

[1]张海潘.软件工程导论[M].北京:清华大学出版社, 2000.

[2]廖福钊, 路友荣, 马云.军事信息系统需求工程现状与发展[J].指挥信息系统与技术, 2013 (5) :6-11.

[3]褚中苇, 魏东.交互设计在人机界面设计中的应用[J].艺术与设计, 2009:93-95.

[4]贾晓辉, 董智勇, 乐嘉锦.多通道人机界面设计及应用[J].计算机应用软件, 2008 (25) :121-122.

[5]李乐山.人机界面设计基础[M].西安:西安交通大学教材, 2002.

[6]夏敏燕, 王琦.以用户为中心的人机界面设计万法探讨[J].上海电机学院学报, 2008 (11) :201-202.

用户界面测试 第7篇

1 楼区选择及测点布置

1.1 选择楼区情况

选取供热效果不好的东湖三区作为测试点。东湖三区建筑形式主要为住宅, 其余建筑包括活动室、幼儿园、小学教学楼、泵房、车棚及办公楼, 总供热面积129 744.13 m2, 住宅125 519.3 m2。建筑年代和围护结构水平相差不大, 住宅建筑大都在1999年建成, 相配套的教学楼、办公楼等建筑大都在1998年建成。建筑墙体为普通的砖墙, 住宅最初建成时窗户均采用单层塑钢窗, 大部分住户已将窗户改为双层塑钢窗。

1.2 测点布置

通过对东湖三区各栋楼室温的分布以及楼内用户室温的分布情况, 依据建筑端部、中央、顶部等具有典型意义的用户进行温度测点布置。每个供热支路上选择1~2栋建筑进行测试, 东湖三区共选6栋住宅楼进行测试, 每栋住宅楼分别布置在总进户供回水管线、单元阀组间供回水管线、住户室内5个测点, 共30个温度测点, 见图1。

2 测试情况

2.1 建筑耗热量

根据流量、平均室温、平均供回水温度求得楼内供热量及散热器的总传热系数。

选取2月18—25日的测试结果作为计算采暖的运行时段, 该阶段室外平均温度-15.1℃。东湖三区各个栋楼的耗热量统计见图2。由图2可知, 三区住宅楼的耗热量主要集中在30~50 W/m2之间。

2.2 用户室内平均温度

经过数据整理, 去除无效和异常数据后, 三区测试建筑室内平均温度见图3。图3中虚线表示要求达到的室温 (18℃) , 可以看出, 三区测试建筑有4户室温未达标, 最低值为14.6℃。有16户室温达标甚至超过20℃, 最高23.8℃。

通过调研发现, 东湖三区建筑是按节能型住宅设计的, 而实际建筑物未达到节能墙体保温标准, 保温板厚度与墙体连接密实度均不达标。同时, 前后阳台面积未在计算热负荷内。因此, 散热器选型面积偏小, 且采用圆形翅片结构, 这是导致用户采暖效果不佳的一个主要因素。这些室温未达标的用户所在栋楼均位于各供热支路的中、远端, 并且这些用户基本都位于靠山墙侧。且又以底层用户情况最为严重, 如303-1-101和323-5-101住户。除了所处位置不利以外, 部分用户出于美观需要, 将客厅与阳台打通, 使得室内采暖面积增加, 也是导致室温偏低的原因。

2.3 过量供热损失率

用户室内温度达到18℃即为满足供热要求, 而用户室温超过18℃则为过量供热。过量供热损失率即为超过需求多供的热量与需求热量的比值, 由于耗热量与室内外温差成正比, 因此, 过量供热损失率越大, 系统热量损失越多。

数据统计时间为2012年12月29日—2013年2月25日, 此期间室外平均温度为-15.3℃, 根据测试可得出三区住宅建筑的最大过量供热率为16.9%。

2.4 室温垂直失调

用户室温的垂直失调表现为同一建筑、同一单元的相同房间室内温度分布不均匀。由于三区的建筑均采用上供下回的供热方式, 垂直失调表现为上层用户室温高, 下层用户室温低 (表1) 。

从表1可以看出各测试栋楼均存在垂直失调情况, 其中三区333号楼垂直失调情况最严重。201用户将阳台和客厅打通, 使得室内采暖面积增加, 室温偏低。由此可见, 阳台和客厅打通和用户自行更换暖气片都将加剧楼内垂直失调, 使得下层用户室温偏低。

2.5 围护结构对耗热量影响

为了找出围护结构散热的薄弱环节, 使用红外摄像仪对东湖三、四区住宅建筑的围护结构拍照, 并就围护结构散热的薄弱环节进行分析。红外拍摄时间为2013年3月1日, 当日的平均室外温度为-11.5℃。

2.5.1 窗体结构

东湖三区住宅建筑原使用单层塑钢窗, 目前大部分用户已经将单层塑钢窗更换为双层塑钢窗, 对两种类型的窗户进行红外拍照。测试结果对比如表2所示。

从表2的计算结果来看, 单层塑钢窗的单位面积耗热量[1]比双层塑钢窗分别高出2.4倍和2.1倍, 由此可见更换单层塑钢窗对于减少室内散热有着非常显著的作用。

2.5.2 墙体裂纹

墙体裂纹也会造成室内热量的流失。由于墙体传热系数相同, 耗热量与传热温差成正比, 裂纹墙体与周围正常墙体的耗热量对比如表3所示。

从表3的计算结果可以看出, 裂纹处周围墙体的温度比正常墙体的耗热量增加43.3%, 因此, 应及时修复有裂纹的墙体。

2.5.3 墙体结合处

调研中发现客厅阳台和卧室外墙的结合处散热情况较外墙严重。由于墙体传热系数相同, 耗热量与传热温差成正比, 结合处外墙与非结合处外墙的耗热量对比如表4所示。

从表4的计算结果可以看出, 外墙结合处墙体的耗热量比周围非结合处正常墙体的耗热量增加102.9%, 因此, 应重点对外墙结合处进行保温。

2.5.4 一楼外墙

调研中以317住宅楼4单元为例, 在室外平均气温-12℃时, 相同供、回水温度 (63℃/50℃) 下, 发现101 (室温16.4℃) 卧室的散热情况比201 (18.8℃) 卧室的散热情况严重。由于墙体传热系数相同, 耗热量与传热温差成正比, 选取一楼外墙与二楼外墙的耗热量对比如表5所示。

从表5的计算结果可以看出, 一楼外墙比二楼外墙的耗热量分别增加40.4%和53.9%, 因此, 应重点对一楼外墙进行保温。

2.5.5 楼板与山墙结合处、外窗周围墙体

调研中发现楼板与山墙结合处以及外窗四周墙体比周围外墙的散热情况严重。由于墙体传热系数相同, 耗热量与传热温差成正比, 楼板与山墙结合处以及窗户周围墙体的耗热量对比如表6所示。

从表6的计算结果可以看出, 楼板与山墙结合处比周围正常墙体耗热量增加66%, 窗户周围墙体比周围正常墙体耗热量增加74%, 因此, 应重点对楼板与山墙结合处以及窗户周围墙体进行保温。

2.5.6 阳台情况

调研中发现部分用户将客厅和阳台打通, 并将原本放在客厅的暖气片外挪至阳台, 这使得客厅采暖面积增加, 外墙的散热量明显增加。由于不同墙体传热系数步相同, 耗热量与传热温差成正比, 打通阳台和未打通阳台墙体的耗热量对比如表7所示。

从表7的计算结果可以看出, 打通阳台使得墙体耗热量增加63.3%, 因此, 对于目前未打通阳台的住户应建议维持现状。

3 结论及建议

1) 用户私改散热器:部分用户更换暖气片, 将客厅与阳台或厨房打通, 增加散热面积, 加剧了垂直失调, 使得下层用户室温偏低。应加强私改治理。

2) 墙体结构的影响:采用单层钢窗结构, 墙体未采用保温结构, 墙体存在裂缝以及墙体结合处保温差均能大量增加耗热量, 另外, 把山墙及一层的住户的墙体保温也对耗热量影响较大。建议将单层塑钢窗改造为双层塑钢窗, 对非保温墙体进行节能改造。

摘要：随着国家对节能环保要求的不断提高, 供热工作必须实施精细管理和技措挖潜, 努力实现节能降耗、经济供热的目标。为了更深入分析栋楼内各因素对供热损失的影响程度, 通过对建筑耗热量、过量供热损失率、保温损失、水温垂直失调等因素进行测试和计算分析, 总结同类型建筑耗热量指标, 通过实际数据对比, 找出造成供热效果差的原因, 进一步总结出可供同类型小区借鉴的经验, 为减少热用户热量损失提供可参考性建议。

关键词：东湖三区,过量供热损失率,单位面积,增耗热量

参考文献

用户界面测试 第8篇

1 最终用户如何看待综合布线系统的质量

有人认为：通了就行、能上网就行、现在能用就行、以后能支持千兆/万兆就行。有人认为：提交检测验收报告证明达到产品质量要求，确保今后扩容升级，并能持续保持高可靠性。

应该是：随着信息时代的快速发展，最终用户都开始注意和关注综合布线系统的质量问题，大到国家部委机关、大型企业、国家重大项目，小到家庭、小区，都在进行着综合布线系统的设计与安装。而大家追求的都是同一目标——即高速、流畅、安全的数据、语音以及视频传输环境，来满足日益高速发展的信息社会的要求。合格的综合布线系统可以为用户节约时间和成本，而且能为客户的系统运行提供可靠的网络保障，尽可能少的造成网络中断，避免业务损失。同时，能够节省大量维护费用，节省因故障诊断、修复造成的停工时间。另外合格的综合布线系统还可以为今后自身的扩容提供很好的基础条件。对于最终用户如何看待综合布线系统的质量，受访的用户代表均表示支持提交检测验收报告证明达到产品质量的观点，但是在实际中真的是这样吗?我们不好评价，但是我们还是希望所有的项目真的向正方所述的，这样就为以后的扩容升级打下基础，减少不必要的麻烦和不必要的开支。

2 保证措施

2.1 工程实施阶段

用户如何确保布线工程项目验收合格（自测、施工方测试或委托第三方测试），哪种检测方式可以保证质量最高，可操作性最好？

上海盛大网络发展有限公司数据中心架构师朱华：作为用户，首先需要施工方提供详细的检测报告，而且使用经过校对过的专业测试仪，这里需要着重说明的是：测试报告不仅仅是链路是否PASS，还包含波长、损耗、极限值以及测试方向和参考电平，每条链路都是一个单独的报告。用户方可以委托第三方抽测或者全测，来检验施工方的施工质量。

国家图书馆王平：首先由施工方出示测试报告，最终用户进行抽测来检测施工方的施工质量。

陕煤股份信息化项目部技术总监张新轩：建议选择独立的第三方测试机构来检测，因为独立、公正、公开的第三方测试更能保证布线系统的质量。随着布线工艺的发展，建设单位缺少相关专业的人才。为了保证项目的投资落到实处，同时也为了保证布线的实施能够完全按照国家标准规范执行，一般大型或超大型的综合布线项目都在信息化监理的协助下，选择具备测试能力的第三方机构。这样可以保证综合布线的质量达到预期目标，同时也为后期的信息化建设的开展做好坚实的基础。

某保险公司信息部沈先生：通过独立的第三方测试机构，可以对综合布线系统工程进行全面的测试验收，才能帮助用户了解网络各条链路的特性是否符合布线标准，进而确保网络布线工程质量，为网络架构奠定良好的基础，满足网络应用的要求。第三方测试机构是受用户方的委托，因此在可操作性方面也不会有不方便的地方，完全代表了用户方的利益。

如何选择测试验收标准和测试模型？

上海盛大网络发展有限公司数据中心架构师朱华：可以选用国家标准《综合布线系统工程验收规范》(GB 50312—2007)来作为项目测试验收标准。

国家图书馆王平：测试验收标准依据《综合布线系统工程验收规范》(GB 50312-2007);选用永久链路为测试模型。

陕煤股份信息化项目部技术总监张新轩：目前综合布线的标准主要依据以下国家标准和国际规范：《综合布线系统工程设计规范》(GB 50311-2007)、《综合布线系统工程验收规范》(GB 50312-2007)、《通信管道工程施工及验收规范》(GB 50314-2006)、《建筑与建筑群综合布线系统工程设计施工图集》(YDD 5082-99)、《商业建筑电信布线标准》(TIA/EIA 568)、《商业建筑电信布线安装标准》(TIA/EIA 569)。永久链路和信道通常是综合布线工程验收中采用最多的两种测试模型，以此来测试水平链路的性能。

某保险公司信息部沈先生：测试的验收标准采用GB 50312-007附录B综合布线系统工程电气测试方法及测试内容和附录C光纤链路测试方法;测试模型采用永久链路的方式来测试，因为永久链路的测试方式是最接近实际链路的一种方式，如果采用该种方式，其测试结果将是最真实的。

2.2 网络运行阶段

如何确保布线系统符合今后网络扩展与新业务应用的需求？

上海盛大网络发展有限公司数据中心架构师朱华：综合布线的设计基础应当是满足当前网络流量的要求以及当前网络拓扑结构，水平布线多设计为多模或单模光缆，因为光纤媒介的可扩展性很强，技术的发展速度很快，使用光电转换器件即可完成新业务的扩展。

国家图书馆王平：工程进行前提出我方布线要求，基本上会使用目前市场上最先进、最成熟的布线系统以达到今后网络扩展的需要。

陕煤股份信息化项目部技术总监张新轩：首先在综合布线设计阶段，就要严格的遵循国家规范，做好综合布线的设计架构，同时针对客户的未来需求，做一定的预留。尤其是主干线缆要保证一定的余量，以满足后期扩容的需求。虽然在初步实施会增加一些费用，但是与后期建设重新实施相比，费用会大幅度减小。

某保险公司信息部沈先生：首先布线工程需要满足国家或国际的测试验收标准，布线系统通常支持10年以上的周期，产品选择要有一定的前瞻性，以保证今后网络扩展与新业务应用的需求。

布线系统投产运行3～5年以后，如何为了升级扩容或达到高可靠性再认证传输性能？

上海盛大网络发展有限公司数据中心架构师朱华：3～5年，对于IT的发展应当说是一个不短的周期，两年前觉得超5类铜缆足够满足，然而在今天看来，6类线缆已经是绝对的主流，千兆发展至万兆，万兆又将很快成为主流，光进铜退，只有大量使用光纤传输的设计，才有可能保证网络升级扩容和传输性能的发展。

陕煤股份信息化项目部技术总监张新轩：根据《综合布线系统工程验收规范》(GB50312-2007)的要求，综合布线线缆进场后，应对相应线缆进行检测，然后结合测试情况，给出质量评价。

某保险公司信息部沈先生：可委托第三方认证测试机构来负责升级扩容或达到高可靠性再认证的测试工作。

如何保证布线各个子系统始终保持高可性？

上海盛大网络发展有限公司数据中心架构师朱华：减少变更、减少后期对综合布线的扰动，这是在综合布线设计建造完成后，子系统运行保持高可用性、高品质的前提保证，也是运维过程中切记的，当然要减少这样的扰动，还要看综合布线前期的规划以及设计的余量和兼容性。

陕煤股份信息化项目部技术总监张新轩：保障布线系统可靠性的方法应从规划设计阶段就开始引入质量保障方案，通过标准设计、适当冗余、标准选材、施工人员培训、规范施工、有效监理、认证测试、标准验收、文档管理等。选型测试和进货测试是保证质量的前提，大型项目尤其重视选型和进货质量，对其进行产品测试、元器件测试。

某保险公司信息部沈先生：首先保证整个布线工程竣工时系统测试时稳定可靠，标识全部正确无误，在后续的维护管理中，建立严格的系统维护管理流程，同步保持标识与记录文档的实时更新，这样可以保持各子系统始终保持高可性。

2.3 产品检测

进场测试能保证施工材料质量吗？如何确定抽测比例？

上海盛大网络发展有限公司数据中心架构师朱华：首先还是从品牌和采购的角度去保证材料的质量，如找国际、国内知名品牌或信誉较好的代理商。进场去控制材料的质量，从现场工程的角度不太现实，除非铜缆或者光缆的跳线，可以在进场前使用测试仪进行检测。

陕煤股份信息化项目部技术总监张新轩：进场测试可以保证施工材料符合建设要求，甚至严格的进场测试可以减少后期的验收测试的工作量。针对不同的产品类型，进行有针对性的测试，可以按照总数量5%的比例进行抽测，同时选择信道模式进行测试比较好。

某保险公司信息部沈先生：其一进场测试能保证施工材料的质量，只要对每批进场的施工材料按照国家标准GB 50312-2007中关于双绞线电缆和光纤的测试标准测试，就可以保证施工材料是合格的。

其二从本批量对绞电缆中的任意选取比例5%，最小抽测数量不得小于任意三盘，并各截出90m长度，加上工程中所选用的连接器件(模块)按永久链路测试模型进行抽样测试。光缆抽测也可以从本批量光缆中任意选取5%，测试方法通常可以使用可视故障定位仪进行连通性测试。

其三双绞线工程电气性能测试模型采用永久链路的方式来测试为好，光纤衰减性能测试模型采用方法B或称B模式来测试。

如何根据进场测试结果进行质量的评价？

上海盛大网络发展有限公司数据中心架构师朱华：一些知名综合布线品牌包装箱上有防伪编号，可以通过这些方式去进行质量的控制。综合布线施工部分的现场监理工作很重要，然后就是在施工完成后，交付使用前的测试，使用Fluke测试仪测试，所测链路都有报告。

陕煤股份信息化项目部技术总监张新轩：根据进场的测试结果，在使用合格的测试工具的前提条件下，如果测试能全部通过且产品的三证具备，我们就可以认为这批材料符合要求，视为合格产品。

某保险公司信息部沈先生：按相关标准抽测铜缆系统链路和光缆系统链路的测试结果都是合格的，则双绞线电缆的电气性能与光缆的光纤传输性也符合测试标准，那说明该批量双绞线和光缆的产品质量是符合厂家的出厂标准以及相应的国家、国际标准。

需要使用哪些测试工具？

上海盛大网络发展有限公司数据中心架构师朱华：较为常见的是Fluke系列的测试仪，可以检测铜缆、光缆，可存储千条链路测试报告。

陕煤股份信息化项目部技术总监张新轩：使用可视故障定位仪、光功率计、光纤测试光源、光损耗测试仪、光时域反射计。比如：福禄克测试仪、FiberMASTER光功率计、激光笔、酒精和药棉等其他辅助工具。

某保险公司信息部沈先生：Fluke DTX-1800电缆认证分析仪、光纤衰减测试仪或光时域反射仪(OTDR)、可视故障定位仪。

2.4 系统测试

根据工程概算和预算定额如何确定测试工时与费用？

上海盛大网络发展有限公司数据中心架构师朱华：在工程报价时，可以将综合布线的材料使用单价+人工费组合成综合单价，其中人工费包含施工费和测试费用，实际工程报价中，测试费用的人工量较大，但是很有必要的。

陕煤股份信息化项目部技术总监张新轩：一般按照信息点的点位数量来确定费用和工时，一般来说，一个熟练的技术工人在一天的测试工作量应该可以达到400个信息点，每个信息点位可以按照0.05～0.15元来进行收费。

某保险公司信息部沈先生：可参照《通信线路工程预算定额》来确定测试工时和费用。

如何保障全程施工的质量？监理部门如何参与检测工作？如何评判布线工程的总体合格率？

上海盛大网络发展有限公司数据中心架构师朱华：综合布线每个链路都需要单独的检测报告，合格率就是通过率，监理可以监督测试过程，并且按照3%的比例进行抽测，如发现问题，可适当提高抽检比例，目标是100%的合格。

陕煤股份信息化项目部技术总监张新轩：首先要做到建立合理的综合布线施工检查制度，在源头上杜绝各种材料、施工问题现象的存在。其次进场施工材料的三证检查，以及质量测试，重大项目的材料检查可以邀请第三方做材料的测试工作。再次在施工中做好阶段性的测试工作，避免因为施工水平的不到位，造成线路问题，同时做好成品保护工作。最后在项目移交前，严格按照国家规范，做好测试验收工作。监理单位在整个过程中，要做好旁站、抽测，协助业主单位完成第三方测试的选择和见证材料的验收工作。对于测试不通过的信息点或存在的问题，要做好整改工作，测试通过后，才能做项目的整体移交工作。

某保险公司信息部沈先生：第一是材料进场时，采取一定比例的双绞线电缆的工程电气性能测试及光纤衰减性能测试，并对两种测试进行随工检验测试，竣工测试时严格按照综合布线国家或国际标准进行验收，确保布线在全程施工的质量。

第二是监理部门在材料进场、随工检验和竣工验收时都参与检测工作，一般在进场测试时，监理可以在一旁监督测试的过程，是否符合国家或国际的标准;随工检测时监理部门可以单独测试工程电气性能及光纤衰减性能测试;最后竣工验收时，由业主、施工方和监理一起参与测试的验收。

第三是对绞电缆布线全部检测，无法修复的链路、信道或不合格的线对数量有一项超过被测总数的1%，则判为不合格，反之判为合格。光缆布线检测时，如果系统中有一条光纤信道无法修复，则判为不合格，反之判为合格。

检测指标达不到规范要求或测试不合格比例较高时，如何制定问题解决流程？

上海盛大网络发展有限公司数据中心架构师朱华：在实际工程案例中，我们会经常碰到这样的情况，尤其是大规模的综合布线，涉及到1万到2万个信息点以上，还是要重复前面的说法，施工方先要对每个链路都有检测报告，而后，用户可以委托第三方再次检测或部分抽检。现实中，我们会发现个别链路问题，常见的是6类铜缆模块卡接不好或是线路施工弯曲半径问题，或配线架处电缆捆扎过紧，导致个别线路拉力接触不好等，需要一个一个的检测，没有捷径可走，必须踏实的做完这些工作。

国家图书馆王平：按照要求进行整改，比如更换布线系统的网线或信息模块等。

陕煤股份信息化项目部技术总监张新轩：找出问题所在原因→制定针对不同原因的解决方法→通知监理单位、业主单位就综合布线中的问题做确认工作→开展施工、解决问题→实施单位自查自检→监理单位会同建设单位进行测试验收。

某保险公司信息部沈先生：如果委托第三方测试机构的测试结果指标达不到规范要求或测试不合格比例较高时，首先出正式的书面通知给弱电项目的总包方，再由总包方出书面通知给综合布线分包方，需要综合布线分包方重新整改的综合布线工程，待整改好后出书面通知给总包方和业主用户，然后由总包方和业主用户或委托第三方测试机构采取抽测的方式测试，如果测试结果合格，就可以判定该综合布线工程项目是合格的。

2.5 如何保证测试仪表的精度

上海盛大网络发展有限公司数据中心架构师朱华：使用知名品牌，如Fluke等，同时，在使用前需按照仪器使用说明进行仪器矫正。

国家图书馆王平：按照仪表厂商的维护要求定期进行校准，以其达到测试仪表的准确精度。

陕煤股份信息化项目部技术总监张新轩：

(1)对于测试仪表自身电路设计、元器件、制造工艺等因素造成的参数的差异，仪表厂家一般均提供现场校准模块，定期将此系统误差予以消除，同时厂家会提供仪器回厂校准服务，以其符合精度要求。

(2)对于测试适配器自身电路设计、元器件、制造工艺等因素造成的参数差异。应采用复杂的适配器设计，并通过制造工艺提高坚固性，在出厂前严格测试配对，通过现场校准，将测试仪与适配器一起进行校验，将误差彻底消除。

(3)对于测试仪表与适配器接口因磨损造成的参数变化：单独校准测试仪或适配器本身，显然无法对接口的影响予以消除，只有将两者装配在一起后检测，才能得到相关数据并将其进行补偿。

(4)对于测试接口磨损造成的参数变化：规定测试端口或插头的使用次数，超过后建议用户更换。通过现场校准(与仪器自身规定校准时间一致)，动态监测适配器及仪器跳线使用状态，而不规定具体测试次数。一旦发现接口或跳线不符合仪器精度要求，则立即告知用户，并拒绝继续测试，用户必须更换相应部件后才能继续工作。

某保险公司信息部沈先生：测试仪器必须在仪器精度校准期内，超过校准期需提供原厂精度校准证书(注：仪器校准期为1年)。且主要测试附件即永久链路适配器的测试点数应在厂商规定的精度保证范围内(即：≤5000点次)。

2.6 日常运维检测

日常维护阶段，高可靠性布线系统宜多长时间按照一定的信息点比例进行抽测，为什么？

上海盛大网络发展有限公司数据中心架构师朱华：高可靠性布线系统，正常情况下都是在不间断的工作，为什么要进行抽测，这些工作都应当是在交付使用前完成，后期应当是“少扰动为原则”，这不是数据中心的柴油发电后备系统，在绝大数情况下是不用，为了保证使用，经常启动试车，检测是否正常运转。

陕煤股份信息化项目部技术总监张新轩：一般来说一个月到三个月应该按照一定的比例进行信息点的抽测。因为环境、灰尘、老鼠以及人为因素的原因，可能会对前期的布线造成损害，所以为了保证信息的高可靠，会对信息点做一定比例的抽测。

某保险公司信息部沈先生：高可靠性布线系统宜按照一年一次，以信息点总数的1%比例来进行抽测，因为考虑到是高可靠性的布线系统，通过这样的比例抽测，可以及时地发现哪个信息点有问题。

需要检测哪些项目？

国家图书馆王平：如果需要检测，则按照《综合布线系统工程验收规范》(GB50312-2007)的要求来检测。

陕煤股份信息化项目部技术总监张新轩：日常维护可以做的事情很多，其中包括：

(1)清除机柜内外综合布线系统上的灰尘。

(2)检查机房内双绞线、面板、配线架、跳线上的标签，将脱落的标签补全，将粘连不牢的标签固定好，更换有损坏的标签。

(3)使用性能测试仪对铜缆信道和未使用的光纤信道进行抽检，测试方法为永久链路测试和所用跳线的性能测试，并与原始记录进行核对。

(4)电子配线架系统同样应进行抽样检查，检查可人为设置故障，检查实时报警的响应时间，同时，综合布线管理软件(含电子配线架中的软件)应对电子记录进行人工检查，检查范围包含施工记录和上次维护至今的日常记录。施工记录应检查其完整性，不应发生遗失或损坏。

日常维护工作的目的只有一个，将隐患消除在萌芽状态，只有这样，才能确保综合布线系统始终处于经久耐用的水平上。

某保险公司信息部沈先生：一般需要检测双绞线电缆的电气性能测试，包括连接图、长度、衰减、近端串音、近端串音功率和、衰减串音比、衰减串音比功率和、等电平远端串音、等电平远端串音功率和、回波损耗、传播时延、传播时延偏差、插入损耗等测试项目。

文档如何备案和更新？

上海盛大网络发展有限公司数据中心架构师朱华：所有的综合布线设计施工图纸、每个链路测试报告、综合布线端口对应表以及后期变更情况都应当归档，纸质和电子文档都需要，尤其是庞大的系统，这里包括智能大厦以及数据中心的综合布线系统。

国家图书馆王平：国家图书馆有专门的文档服务器，布线系统如有变化，随时在线更新文档。

陕煤股份信息化项目部技术总监张新轩：在测试阶段，测试结果可以方便的从测试仪上获得，该文档可以上传到电脑上存储备案，对于简单的测试数据，也可以打印备案。在日常运维检测过程中，如果发现有变动，可以将更新部分标识出来，并作说明，方便后期维护管理。对故障情况及时进行记录，记录手段包括文字及故障位置的照片。这些记录需长期保存，并定期进行统计和分析，确定综合布线系统的整改计划。整改完毕后，应按工程要求保留实施过程中所有的图纸、变更单、日志、检测报告、检测记录和相关文件，在有条件时，使用照片作为日志的基本内容。

某保险公司信息部沈先生：文档的备案一般就是竣工文档的备案，而且文档需要分成纸质和电子文档两种，这样的形式可以称为互为备份，在文档更新上，实际链路产生更改的话，必须在纸质和电子文档上同步更改，这样才能保证更改的信息与实际链路信息相符合，也便于后期的查阅。

3 结束语

用户界面测试 第9篇

Web系统以其广泛性、交互性和易用性等特点迅速风靡世界,且呈现出指数级的高度增长[1]。随着需求量应用领域的日渐扩大,当下针对基于Web的软件和系统的正确性、有效性也已相应提出了越来越高的质量要求,进而Web测试已经成为软件工程领域的重点研究课题[2,3,4]。Web系统应用如果能保证用户访问的安全可靠和快速准确,这就必将成为整个计算机软件系统发展中近期内可获取的又一重大突破[5,6,7]。如果在Web系统开发过程中的性能缺陷可以通过系统测试进行正确、及时的定位,既能减少系统的潜在风险, 而且还可为系统的优化、开发和原有系统的更新提供基础技术依据,同时更对系统的发展完善与长期使用具有至关重要的标志性意义。性能是决定Web应用程序成功与否的重要因素之一,从用户角度来说性能有时比功能更为重要。为了提高系统性能,Web性能测试则已成为Web应用性能研究问题的首要攻关步骤[8,9,10]。Zona一份研究报告的数据统计,页面的下载时间减少1秒,用户放弃率将从30% 下降到6% - 8% ; 而由于性能问题,超过34% 的用户没有从最初访问的网站购买商品,特别地其中有21% 的用户后来却从别的网站购买了商品。因此,要保证基于Web的系统达到预期的性能,开发过程必须进行性能测试。

本文从Web性能测试模型出发,通过研究用户访问特征,将用户访问中的思考时间、响应时间等因素融入到Web性能测试模型中,提高了Web性能测试的可靠性与准确性。

1基于用户访问特征的测试模型

1.1Web性能测试

性能测试的主要目的是为了维护系统的性能并找到有效的改善策略。在进行Web应用性能测试时,以下因素将成为影响性能测试的瓶颈: 真实环境与测试环境差异大,负载的不确定性,模拟真实环境困难和模拟真实用户行为困难等。

目前,主要用吞吐量、响应时间、资源利用率、并发用户数和TPS等来作为衡量Web系统性能的技术指标,即通过这些指标分析出系统性能的好坏。现有测试模型尽管考虑比较周到,但并没有从用户的实际行为出发,同时也缺少对用户的特征的精确分析。Web性能测试指标并不是各自独立地发挥作用,而是具有一种相互影响、相互依存的综合性效果作用。因此,充分考虑用户实际行为及对性能测试的影响即尤显必要。

1.2用户访问特征

差异性存在于万事万物之中,用户访问特征其实也是具体操作过程中差异性的体现。因其面向真实的用户,为此需要考虑不同用户的不同操作情况。Web性能测试通过获得机器不同情况下负载量化分析,由此而得到频率来展开研究。在性能测试的过程当中,只有虚拟用户行为特征更加接近真实情况,才能据此表示和反映出测试精度和可靠性。因此,Web性能测试的用户访问特征可从如下方面进行考虑: 思考时间、login Session、超时放弃浏览、动态网页、浏览页。

1.3融入用户访问特征

通过融入用户访问特征,将可使模型更能适应现实环境。结合用户访问特征———思考时间和超时放弃浏览,本文提出了新的测试模型。现对测试模型中的重要参数,展开如下论述。

( 1) 实际请求时间。在实际操作过程中,用户的请求不是连续不断的,而是有停顿思考下一步的时间,所以两者需要一同进行分析。实际的请求时间和事务平均相应时间具有直接关系,事务的平均相应时间越长,意味着实际的请求时间也不会短。实际请求时间超过了用户可以忍受的范围之内,用户可能会不想等待就在中途放弃了,这会直接导致Web访问的损失。在性能测试中通过添加真实的模拟思考时间,以此来完善原有性能测试模型的不足。思考时间还可以通过预测得到,基于对Web系统用户的信息收集,由此将开展后续分析、并建立模型。在实际的开发过程中用到的方法是剔除法和还原法,对已经得到的数据进行分析和鉴别, 并在分析和鉴别的过程中对用户的操作进行适当处理,最后得出预测思考时间。

( 2) 请求成功率。请求成功率指的就是Web服务器能够正确处理的请求数量和接收到的请求数量的比值,用来表示有效的请求次数。请求成功率不是一个性能指标的结果, 而是多个性能指标和性能参数共同作用下的现实结果。假如服务器几乎达到了饱和的状态,而在此基础上进一步增加并发用户的数目,将直接导致实际的请求时间随即增加,最终就使得系统处理请求出现失败。

( 3) 最佳并发用户数和最大用户并发数。系统的总体性能达到最优时可以得出系统的最佳并发用户数,此时系统资源也将获得充分利用,而且响应时间也即处于用户可接受的范围之内。系统的负载能力有限,当超过最大用户并发数的临界值时,用户的满意度即会明显降低,与之相伴相生的将就是放弃。

除了用户的访问特征外,影响Web系统的性能的因素仍有许多,比如用户的熟练程度,对同一操作不同的用户需要的时间也各不一样。需要指出的是,每个用户的思考时间对Web服务器造成的影响也必然不同,Web系统需要考虑的因素更应该将其包括进去。

综上,各种影响因素共同制约了Web系统的性能,本文着重用户访问特征,对比考虑用户时间和不考虑用户思考时间性能的优化情况,以此得到改进后的新模型。

2测试实例

本文使用的性能测试工具为LoadRunner,测试Web对象为LoadRunner自带的Web Tours飞机订票系统网站,测试中使用LoadRunner的Vu Gen发生器组件生成测试脚本,同时使用Controller设置测试场景并运行测试,最后使用Analysis组件分析测试结果。

测试目标为机票预定和机票查询时用户的并发访问能力,采用负载测试的方法,以得到系统的极限,由此确认服务器的负载可承受能力。实验测试需求如表1所示。

考虑到不同用户的思考时间上的各不相同,熟练用户的一般思考时间为3s,普通用户为5s,新用户多为15s。根据调查统计得出思考时间,如表2所示。

以下是虚拟用户数为40、80、150、250时考虑用户响应时间和不考虑用户响应时间的请求成功率对比,对比结果如图1所示。

由图1可知,当不考虑用户的实际思考时间( Think time = 0) ,系统的请求成功率保持一个很快的下降态势。但是, 当考虑用户的思考时间( Think time = 3) ,系统的请求成功率一直处在较为平稳理想的水平,这就说明思考时间对于系统的优化有着重要的控制作用,将使测试的系统更为正确,测试结果与实际情况更趋吻合。在一定的程度上,也减少了开发的成本。

以虚拟用户数达到40时为例,分析不考虑用户思考时间和考虑用户思考时间的系统优化情况,对比分析并得出结论如下:

( 1) 机票查询: 当虚拟用户为40,对比平均事务响应时间得出响应时间结果,具体如图2,图3所示。

由图2和图3可知,相同条件下,考虑用户的思考时间, 平均响应时间会偏低,用户集中操作相对减少,系统处理的数据单位时间内也会减轻负担,由此系统得到了优化。

( 2) 机票预订: 当虚拟用户为40时,根据每秒HTTP响应数的图进行对比,并得到最终效果。具体如图4,图5所示。

由图4和图5可知,相同条件下,考虑到用户的响应时间,用户访问不至于过分密集,并且不存在过分波动情况,请求数也趋于稳定,因而系统得到了优化。

3结束语

用户界面测试 第10篇

1 系统设计

该设计以Ubuntu为操作系统, 以SAMSUNG公司的S3C6410X为硬件平台核心控制芯片。校验装置以标准键盘、鼠标作为输入设备, 7英寸800*600分辨率的彩色LCD作为终端现实屏幕.系统界面的开发工具是Qt-4.7.3, Qt相对于其他界面开发工具, 具有跨平台、面向对象、丰富的API等优点, 界面调试可以在PC机上完成, 大大提高了开发效率.该界面系统以RS232通信方式与驱采模块连接, 实现对转辙机的操作与状态、数据采集。

2 通信实现

QT中并没有特定的串口控制类, 本设计通过第三方qextserialport类实现读写操作。Qext Serial Base类继承自QIODevice类, 它提供了操作串口所必需的一些变量和函数等, 而Posix_Qext Serial Port均继承自Qext Serial Base类, 并类添加了Linux平台下操作串口的一些功能。在本设计中使用Posix_Qext Serial Port类对象mycom定义串口, 包括串口读写方式、波特率、数据位、数据流控制等串口设置。

本设计采用信号与槽函数关联方式实现读串口缓冲区数据, 实现读写操作。其方法为设置定时器, 固定时间间隔后读取缓冲区数据。相关代码如下:

connect (read Timer, SIGNAL (timeout () ) , this, SLOT (read My Com () ) ) ;

读操作槽函数中, 读取串口缓冲区的所有数据给临时变量temp, 再对临时变量temp进行处理, 根据已定义的数据帧格式采集转辙机状态信息与转辙机动作数据。其读槽函数实现代码如下:

QByte Array temp = my Com->read All () ;

写操作槽函数中, 以ASCII码形式将行编辑框中的数据写入串口。其读槽函数实现代码如下:

本设计中通过串口读写操作, 建立界面系统与转辙机驱采模块的通信, 其通信帧主要分为状态帧与动作数据帧。界面系统向转辙机驱采模块发送状态/动作数据查询帧, 当转辙机驱采模块接收到状态/动作数据查询帧后采集转辙机状态/动作数据, 并以返回转辙机状态/动作数据数据帧。

3 界面的设计与实现

该界面系统主要包括2个部分:主页界面、曲线界面。系统开机后进入系统初始化状态即主页界面, 完成默认选择。由主页界面可通过按键选择可进入曲线界面, 由曲线界面可返回主页界面, 从而实现界面系统界面之间切换, 便于完成对各界面的操作。

3.1 主页界面的设计与实现

根据需求, 主页界面主要包括界面系统的配置选择部分、转辙机状态显示部分和控制部分。界面系统的配置选择部分包括转辙机机型选择、牵引转辙机数量选择和保护时间选择, 并且配置选定后将同步到曲线界面。

3.1.1 状态显示部分

QT提供QPainter类绘制从简单的直线到像饼图和弦这样的复杂形状。它也可以绘制排列的文本和像素映射。通常, 它在一个“自然的”坐标系统中绘制, 但是它也可以在视和世界转换中做到这些。使用QPainter绘制图形时, 首先使用QPainter类构造绘图工具, 然后定义绘制线、轮廓和文本颜色等, 最后设置所画图形参数再结束绘制。

QT提供paint Event (QPaint Event*) 函数实现图形的重绘, 其实现方法如下:

this->repaint () ;

界面系统与转辙机驱采模块通信过程中, 界面系统会向转辙机驱采模块发送状态查询数据帧, 转辙机驱采模块接收到该数据帧后处理接收到的数据帧, 然后由驱采模块采集转辙机状态数据并返回转辙机状态数据。界面显示系统接收到返回的状态数据帧后进行处理并实现图形重绘以显示转辙机状态。

3.1.2 转辙机控制部分

本设计采用信号与槽函数关联方式实现发送定操、反操和急停命令。在发送转辙机操作命令前需关闭状态数据帧的发送, 点击对应的操作按键。点击触发后, 槽函数实现发送对应的操作命令帧。其槽函数重要代码为:

第一行代码需停止转辙机状态查询帧发送;第二行开启发送反操命令帧定时器。由于操作多台转辙机, 故需要设定各台转辙机反操操作间隔时间DELAY, 以便在完成所操转辙机后间隔时间DELAY后操作下一台所操转辙机。其定时器槽函数重要代码如下:

代码第一行是发送反操操作数据帧;第二行是调用串口通信发送函数发送该数据帧。在发送转辙机操作数据后, 继续发送状态数据帧的发送, 驱采模块对接收到的数据帧进行处理, 转辙机进行动作, 并由转辙机驱采模块采集转辙机状态反馈给界面系统进行状态显示。

3.2 曲线界面

本设计中曲线界面用于显示转辙机动作过程中有效电流曲线、电压曲线和功率曲线。在转辙机动作后, 上位机发送要数据命令帧, 转辙机驱采模块接收到命令后返回转辙机动作数据。可根据需求, 选择所需曲线类型并显示。

QWt是一个基于Qt的扩展类库, 包含了大量用于工程开发编程的GUI部件和辅助工具。除了二维绘图控件类外, 它还提供了诸如刻度, 滑块, 转盘等控件类供开发使用。本设计中首先实例化一个Qwt Plot, 设置x轴坐标轴及其显示范围、y轴标轴及其显示范围其相关代码如下:

代码第一行设置了所画曲线X坐标轴的原点及坐标轴显示范围参数;代码第二行设置了所画曲线Y轴坐标轴的原点及坐标轴显示范围参数。

在设置完坐标轴后, 需设置画布背景, 也可添加滚轮缩放功能、鼠标拖动功能、添加网格等。在设置好曲线显示坐标轴及环境后, 通过界面系统和转辙机驱采模块采集转辙机有效动作数据并显示, 以采集转辙机动作数据。

在曲线显示界面设置有click () 触发信号与相关槽函数的要对应转辙机动作数据的按键, 当按下对应按键后, 触发对应的槽函数, 相关代码如下:

代码第一行为要转辙机动作数据帧;第二行是调用串口通信发送函数发送该数据帧。转辙机驱采模块接收该数据帧, 采集转辙机动作数据并反馈给界面系统。界面系统接收到转辙机动作数据并显示, 曲线显示相关代码如下:

曲线界面设置有对应动作要数据按键键, 当转辙机动作完成后, 可根据需求点点击要数据按键。转辙机驱采模块采集转转辙机动作数据, 并将数据传送至曲线界界面直观显示。

结语

该界面系统采用ubuntu操作系统, 具具有很好的移植性, 同时也具有很好的便便携性, 方便供平时转辙机的测试维修修使用。其功能能够即时显示道岔的定位位、反位、四开等状态, 同时可以通过与与转辙机驱采模块相连接以触屏按键方式式实现对转辙机定操、反操等驱动功能的的操控。界面系统可以曲线形式显示所需需转辙机动作数据, 可对转辙机性能进行行判断, 为道岔的维修提供依据。

参考文献

[1]李宇丽.基于ARM的嵌入式Linux系统的研究及应用[D].西安电子科技大学, 2007.

[2]谭永锋.嵌入式Linux移植与应用程序开发[D].长安大学, 2007.

[3]李艳民.基于Qt跨平台的人机交互界面的研究和应用[D].重庆大学, 2007.