人机界面测试范文（精选8篇）
人机界面测试 第1篇
人机界面评价就是把构成人机界面的软、硬件系统按其界面形式、功能、性能、可使用性等方面与预定的标准进行比较, 对其做出评价。新一代的计算机用户, 在应用软件的可操作性以及软件操作的舒适性等方面对应用软件提出了更高的要求。并且, 人机界面的质量已成为一个大问题, 界面的操作是否简单、方便、自然直接关系到人们的工作效率。因此, 友好的人机界面设计评价与测试已经成为应用软件开发的重要组成部分[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.
人机界面测试 第2篇
窗口与窗口之间的调用情况；
窗口尺寸变化时窗口中控件能否自适应；
多个窗口同时打开和调用的情况；
窗口拖动是否正常；
主窗口和子窗口调用能否正常处理；
窗口能否根据浏览器大小进行缩放【双击浏览器、浏览器最大化、最小化和还原查看窗口的变化情况】；
窗口显示标题是否正确。
2.工具条测试主要测试内容如下：
工具条能否正常显示；
工具条能否隐藏；
可移动工具条在窗口中间位置其形状是否正确；
工具栏上工具按钮功能是否能正常实现；
工具按钮显示是否正确、友好、醒目易懂；
工具栏上的工具按钮是否有鼠标悬停提示；
工具栏上的工具按钮是否可以任意定制；
是否有输入框；
是否有个人用工具条；
是否有网站型工具条；
是否有专项型工具条；
是否有企业型工具条。
3.工具条测试主要测试内容如下：
输入正常的字母或数字；
输入已存在的文件的名称；
输入超长字符，例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入 256个字符，检查程序能否正确处理；
输入默认值，空白，空格；
若只允许输入字母，尝试输入数字；反之；尝试输入字母；
利用复制，粘贴等操作强制输入程序不允许的输入数据；
输入特殊字符集，例如，NUL及n等；
输入特殊字符集，例如，NUL及n等；
输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示；
输入非法数据；
输入默认值；
输入特殊字符集；
输入使缓冲区溢出的数据；
输入相同的文件名；
输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示。4.菜单测试主要测试内容如下：
菜单项是否符合需求，能否正常工作，是否与实际执行的内容一致；
菜单措辞是否准确；
菜单位置及顺序是否合理；
菜单图形布局是否一致；
下拉菜单是否根据选项含义进行分组；
菜单的热键、快捷键能否有效使用和重复；
帮助菜单的“关于”中应有版权和产品信息；
界面菜单公司信息和产品信息显示是否正确。5.页面布局测试主要测试内容如下：
页面布局是否根据分辨率大小自动调整；
页面长宽比例合理是否合适；
界面风格要一致；
背景色彩搭配要协调。6.图标测试主要测试内容如下：
是否符合表达习惯；
不同目标是否采用不同图标；
图标尺寸是否合适；
图标是否有标注，包括公司图标和产品图标。7.界面按钮测试主要测试内容如下：
按钮位置是否合适，是否有正常响应，是否有相应的匹配按钮如：按钮；
单选框和复选框按钮的测试；
功能按钮图标上或在鼠标经过时是否给予正确提示信息。8.时间控件测试主要测试内容如下：
时间年月日选择（开始时间不可大于结束时间）；
时间有效期；
时间年月日显示是否正确；
时间查询。
9.界面文字测试主要测试内容如下：
界面文字描述是否准确，无异议；
文字大小是否合适（一般9-12号）；
是否出现中英文混合；
界面文字是否可根据浏览器的编码方式自适应。10.界面信息提示测试主要测试内容如下：
提示信息是否具有可理解性的语言描述；
对重要、具有破坏性的操作命令是否有确认信息；
提示信息是否具有统一的标记和标准；
提示信息不易过长。
11.鼠标和快捷键测试主要测试内容如下：
是否支持滑轮；
鼠标点击右键是否显示菜单，取消右键是否隐藏；
无规则点动鼠标，查看界面的响应；
经过键盘或鼠标复制粘贴；
支持快捷键使用；
支持键盘自动浏览按钮（Tab键、Enter键）。
基于可用性测试的产品界面设计研究 第3篇
关键词： 可用性测试；空调遥控器；界面设计；研究
一、实验
所谓可用性测试是指邀请真实用户或者潜在用户使用产品或者产品的设计原型，对用户在使用过程中的行为进行观察、记录、测量和访谈，进而了解产品存在的问题和用户的需求，并以此作为改进产品的出发点[1]。因此对以下人群从进行可用性测试：（1）均使用过空调遥控器；（2）当前测试者使用空调遥控器品牌尽量多元化；（3）容易熟悉空调遥控器界面功能人群（年龄段为20-30岁，共计10名测试者，A组）和不容易熟悉空调遥控器界面功能人群（45-55岁，有2名测试者，B组）；（4）均未使用过测试载体空调遥控器。本测试共有12位测试者参与。测试采用了“指定任务条”的方式。所有测试者只完成一项任务。任务为调整空调出风的风向，任务设置考虑主要涉及了美的RNO2A/BG遥控器开关按键及风向按键界面，而不是更为深入的菜单按键结构和任务窗口按键界面。
测试相关数据采集情况见表1。
二、讨论分析
（一）菜单（MENU）的图标含义
在用户测试中反映出的用户困难，最集中体现在菜单图标的设计问题上。很多用户在寻找调整风向的按键时，常常按下的是遥控器中间写着调整的按键。但这一操作在该遥控器上是用于调整空调温度高低，而非调整风向的按键。于是新手用户必须花大量的精力去寻找调整风向的按键。然而其各个方向的调整指示是结合在同一个按键上的，置于遥控器的右下方。因此，菜单的图标语言功能几乎丧失，该图标的识别性仅限于熟练用户和半熟练用户，图标表达含义模糊是这次测试中体现的最大问题。
（二）菜单的功能图标排布合理性
该空调遥控器的菜单图标分布相对较散乱，按键之间的排布没有功能上的相关性，各个功能的按键越散乱，意味着用户判断所想要执行的功能属于哪个分区的时间就越长，然而，这些按键所代表的功能按键是否应该根据使用频率进行重新排布呢？这还需要进一步测试和斟酌。但肯定的是，这种功能图标排布需要优化和提高归纳的必要。
（三）按键的结构合理性
当用户找到了调整风向的按键时，根据上面的图标指示，新手用户因为按键图标面积的局限性使用完全不方便，这一操作增加了用户的疑惑。但事实上，这个功能按键很难操作成功。这说明美的RNO2A/BG遥控器在按键的结构设置上有欠考虑。
（四）反馈机制
有的用户认为使用了调整温度按键之后应该有相信的温度信息提示，但此款空调遥控器需要将模式调到制冷（雪花符号）或制热（太阳符号），才可以进行加减温度操作，空调才有温度降低或升高的反馈，对于用户习惯来说反馈信息完全不够。
（五）退出返回机制
在返回最初的空调打开遥控器屏幕状态时，有的用户为了得到此状态，直接按开关键进行重新开启。但此按键只具有开关空调的功能，并没有“返回”这一层涵义，而且长期如此操作，空调自身也将受到损伤。
（六）年龄层差异明显
A组年龄段用户平均耗时38.8s，B组用户则耗时147s。B组用户耗时远远多于A组用户，不论从测试结果还是从用户交流结果来说，空调遥控器调整风向功能对于年龄偏大的用户是一件趋于“困难”的功能，而年龄层偏小的A组用户则耗时少得多。从工业设计的角度出发，当前适合于老年人或年龄段偏大的用户群的空调遥控器设计非常稀缺。不同年龄层的用户所遭遇的可用性问题不尽相同，这种集体呈现的差异性与用户研究密切相关，并且也是工业设计所面临的新的研究领域：产品设计定位及其产品的可用性问题。
三、产品界面设计原则
通过以上对美的RNO2A/BG遥控器的界面设计分析以及对目前空调遥控器的市场调研分析，发现遥控器普遍存在着以下的问题：遥控器按键布局不够合理，遥控器操作面板设计的不是很合理，按键分类不太明显，遥控器外形有待改善。
（一）合理的按键布局
按键布局大体应该分为三个部分，分别是温度调整按键区，其次是常用功能键区，不常用功能区[2]。温度调整键应置于显示屏下方，便于使用者操作。其次常用功能键，开关键至关重要，应置于最中间且设计成圆形，人们对圆形的辨认率相对较高。不常用按键很少被人们使用，应置于遥控器最下面，可以降低操作过程的错误率。
（二）按键的特异性
选用圆形按键和椭圆形按键，是比较理想的按键形态，并且按键应设计的比遥控器主体高出一些，增强触觉感受。按键边缘应进行倒角处理可避免局部尖锐受力[3]。按键之间的间隔要以使用时不能触碰临键为原则。这里温度调整按钮采用倒角长方体，上面设置具有指示性的三角符号表示温度增加和降低。
遥控器的开关键最重要，因此将其设计成尺寸最大，颜色最明显，便于被识别，通常用作为停顿、开关指示性的红色，给人们视觉上的冲击。不常用按钮，如定时开关，风速等按键一般尺寸都较小，颜色也不突出。对于警示性按键，选用黄色，黄色名视性好，能唤起注意，能达到警告的作用，便于人们采取行动。
（三）遥控器整体造型
由于生产工艺的影响，且考虑到空调遥控器的使用频率，现在空调遥控器外观大同小异，且不符合人机工程学。现在空调遥控器整体造型更倾向于弧线形，更符合人手的尺寸和形态特征，抓握起来更舒适[4]。遥控器作为通用性产品，需要满足大多数人的需求，面向的设计用户是各种群体，还要兼顾手部残疾的人群[4]。
【参考文献】
[1]田蕴，毛斌，王馥琴.设计心理学[M].北京：电子工业出版社，2013（11）：66-70.
[2]董建明，傅利民.Gavriel Salven dy.人机交互：以用户为中心的设计和评估[M].北京：清华大学出版社，2003.
[3]张桥，孙志学.空调遥控器人机分析及设计[J].价值工程，2011， 30（16）：178-178.
[4]孙志学.产品创新设计理论及其应用[J].陕西理工学院学报，2006，22（04）：5-7.
人机界面测试 第4篇
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为总单入库界面的事件关系流图,由于交互关系很多,图中只画出了其中的一小部分,事件流图中,用
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.
人机界面测试 第5篇
>
据中国国防科技信息网报道 [据英国《简氏防务周刊》2012年3月8日报道] 俄罗斯陆军第5特种步兵旅士兵于2012年2月下旬在莫斯科郊外的Alabino军事基地进行了作战演习，测试了新型的C4ISR系统即Strelets系统，相当于西方的士兵系统。
Strelets系统重2.4千克，包括一个小型接收器和惯导系统来提供目标定位和蓝军部队跟踪数据。该系统能够在1.5千米范围内使用同时还能保持无线电联络，可使每个士兵充当中继站，以延长部署部队保持通信的距离范围。
医疗器械中的人机工程信息测试研究 第6篇
人机工程学是研究人与系统中其他因素之间的相互作用,以及应用相关理论、原理、数据和方法来设计,以达到优化人类和系统效能的学科[1]。人机工程学研究的主要目的是以人的生理、心理特征为依据,运用人体测量学、生理学、心理学、生物力学以及工程学等学科的研究方法和手段,通过揭示人、机、环境之间相互关系的规律,达到系统的最优化。
随着医疗器械在现代医学诊断和治疗中的作用日益加大,人们对此类关乎自己生活品质的设备也越来越关注。由于医疗器械不仅由人操作,同时还作用于人,于是在人机关系方面体现出了特殊性,使其本身的人机工程学质量和使用的安全性显得非常重要。虽然现代医疗器械的科技含量越来越高,但目前国内医疗器械产品大多还是仅仅停留在实现实用功能的层面上,对仪器的人机关系考虑较少,特别是产品的人性化、宜人性设计方面几乎可以说是空白,无法满足人机和谐的发展趋势。因此,人机工程信息的测试研究对于医疗器械的发展有着重要的学术意义和应用价值。
1 医疗器械的人机关系
一般的产品设计中研究人机关系主要是研究如何让使用者更为方便地使用产品,提高工作效率,并加强产品使用中的安全性,被作用对象一般是某一具体物件。而医疗器械产品中人的因素与一般产品的不同点是其具有双向的人机关系,无论是医疗器械产品的使用者还是被作用对象都是人,因此,这里所讲的人机关系更为复杂。
在医疗器械人机系统的研究中,许多基于人体测量数据、人机实验或作业分析结果等人机原则的设计与决策行为仍然缺乏理论依据。因此,医疗器械中人机信息的检测和应用不仅可以更好地将人的因素融入到设计中去,从根本上改善其性能,而且还能为医院设备管理提供一定的理论基础。
图1为医疗器械的人机系统。在此人机系统中,医疗器械是实现医疗功能和目的的主体,即所讲的机;人即医护人员和患者,患者是被作用对象,医护人员的主要作用是接受医疗器械的输出信息,并对医疗器械操作控制,输入信息[2]。本文所探讨的主要是操作者,也就是医护人员在使用不同的设备时所呈现出的部分心理和生理特征的变化,从而得到一些对仪器的选择、管理和改进的合理建议。
2 实验方法
在医疗器械的使用过程中,医护人员的各项生理和心理信息都在不断发生变化。本次实验中,我们首先选取了2台不同品牌但能实现同样功能的医疗设备,其设计的基本原理是相同的,但造型结构设计、人机交互界面设计和程序设计均有一定程度的不同。然后挑选2组使用人员分别操作这两台设备,所选取的两组操作者均为可熟练操作此类设备的医护人员,分别完成20个相同的指令,测试其完成的时间、操作中自觉调查的主观疲劳和临界闪光融合值这3项人机工程信息和不同环境中操作人员的脉搏周期变化,得到相应的数据,并将两组操作者的平均数据加以对比分析,从而对2台设备做出客观分析。
在整个过程中,我们把操作者的生理信息变化作为主要的研究对象。在使用传统的检测系统对操作者的生理状态进行检测时,由于检测设备对操作者的正常活动会产生干扰,因此必然会影响到检测结果的准确性。为此,我们将传感器检测系统设计的尽量简单,并选择对作业者拘束比较少的检测装置,以便将对使用者的干扰降到最低,尽可能地实现在线检测,从而使检测精度大大提高。生理信息中的脉搏使用夹在耳垂上的光电传感器进行测定,在使用过程中,使用者不仅要遭受身体疲劳还要承受很大的精神压力,并且精神压力比较突出。本实验用自觉调查表测定使用者的主观疲劳程度,以判断其精神疲劳程度;通过测定使用者的临界闪光融合值来判断其客观疲劳程度。
3 测试结果
3.1 完成时间
A、B两组操作者分别在两台仪器上进行20个相同的操作测试,将完成同样指令所需要的平均时间进行比较,测试结果如图2所示。由图2可知,B组操作者所用的时间明显少于A组操作者,可见B组操作者所使用的设备可能更容易使用,更符合医疗器械应急性很强的特殊要求。
3.2 主观疲劳程度
通过自觉调查表测定两组操作者的主观疲劳程度,测试结果如图3所示。A组操作者的疲劳程度增加较快,结合上一组数据可知,完成时间较短的操作者主观疲劳程度也较轻,整体趋势较为平稳。主观疲劳不仅和操作的便捷性有关,而且和设备的造型设计、色彩搭配等人机因素都有关系。
3.3 临界闪光融合值
临界闪光融合值主要测试的是操作者的客观疲劳程度,测试结果如图4所示。两组操作者的值均在不断降低,但下降的幅度不同,可以反映出不同的设计对操作者造成的疲劳程度是不同的,从而对医疗器械在设计上提出了更高的要求和更具体的改进方向。
3.4 脉搏周期的变化
由于医疗工作的特殊性,我们特意选择了在不同的环境中使用同样的仪器完成20个相同的指令,通过脉搏的波动情况说明工作环境对操作者的影响,测试结果如图5所示。在病房进行操作时,脉搏波动明显较大,说明此时操作人员的心理压力更大,也更容易引起疲劳。
4 结论
通过以上分析,可以得出如下结论:
(1)鉴于医疗器械的特殊性,设备应该由操作熟练的医护人员专人管理,尤其是应急性较强的设备更应如此,尽可能避免因为精神压力和疲劳引发的安全隐患,另外,对不熟练的人员应加强培训,以保证医疗器械在使用中的安全性。
(2)B组操作者使用的仪器无论从功能实现还是外形设计均具有一定优势,但不管哪一种仪器的设计,都要求在通常的使用时间里对操作人员造成的疲劳不能超过人体平均的承受能力。诸如主观疲劳、临界闪光融合值、脉搏等人机工程信息均会在使用过程中对使用者和被作用对象的安全性、舒适性等人的因素造成影响。
(3)不同的工作环境对操作者的影响较为明显,这不仅说明将医疗器械、医护人员、患者及病房环境作为一个整体系统进行研究的必要性,也对改善操作环境提出了更高更新的要求。
随着医疗器械的不断发展,不管是使用人员还是被作用者,都将更多地把注意力转向深层次的需求。人机工程信息的检测研究对于医疗器械的设计有着重要的学术意义和应用价值。通过本实验可以看到不同仪器对操作人员生理和心理所造成的影响,因此这样的研究在未来的医疗器械设计中将会占有重要地位,人机工程学的重要应用也会越来越受到重视,而且有可能成为医疗器械未来发展的一大动力和支撑。
摘要：利用生理传感器检测系统对医疗器械操作者的人体机能进行检测,并对所采集的数据进行分析,其结果可为医疗器械的人性化设计提供理论依据。
关键词：人机工程,医疗器械,信息测试
参考文献
[1]王继成.产品设计中的人机工程学[M].北京:化学工业出版社,2004.
双界面智能卡操作系统的设计与测试 第7篇
关键词：智能卡,COS,测试
1. 引言
智能卡 (smart card又称集成电路卡) 将一个集成电路芯片镶嵌于塑料基片中, 封装成卡的形式, 其外形与覆盖磁条的磁卡相似。
笔者在利用北京市嵌入式系统重点实验室生产的智能卡进行符合中国人民银行金融卡规范的BES COS开发过程中, 针对该款芯片的硬件特性进行了COS的设计与实现, 并根据规范设计了测试用例, 完成了测试。
2. 智能卡硬件概述
BES1332EF是一款基于8051的双界面智能卡芯片。非接触式接口支持ISO 14443 TYPE A协议, 接触式接口支持ISO/IEC7816 T=0协议。有8K的ROM, 32K的EFLASH, 1K的RAM, 硬件随机数发生器, CRC模块以及DES模块。
3. 智能卡操作系统
智能卡操作系统是一个专用系统, 和传统意义上的操作系统有很大的差别, 它更类似于一个监控程序。COS主要包含通信、命令解释、文件系统以及安全四个模块。
3.1 通信模块
传输管理器负责智能卡和接口设备之间的数据通信, 接收过程中要处理对输入数据的缓冲, 响应过程控制数据的发送。通信使用的协议是ISO7816-3所规定的T=0的异步半双工字符传输协议。当接口设备给卡上电之后, 首先由卡发送一个复位应答信息 (ATR) 给接口设备, 然后接口设备发送命令头来启动命令处理过程。传输管理器在正确地接收到命令后交给下一个功能模块进行处理, 最后还要把该命令的执行结果返回给接口设备。
3.2 命令解释模块
命令解释器对外部输入的每条命令做语法分析, 分析和检查命令参数是否正确, 然后根据命令参数的含义执行相应的功能模块。如果发现参数有错, 将从该模块直接返回错误信息。
3.3 文件系统
主控文件 (Master File, MF) 。主控文件是整个文件系统的根 (可看做根目录) , 每张卡有且只有一个主控文件。专用文件 (Dedicated File, DF) 。在MF下针对不同的应用建立起来的一种文件, 是位于MF之下的含有EF的一种文件结构 (可看做文件目录) , 它存储了某个应用的全部数据以及与应用操作相关的安全数据。基本文件 (Elementary File, EF) 。基本文件存储了各种应用的数据和管理信息, 它存在于MF和DF下。
3.4 安全模块
安全模块主要分成两个部分。第一部分就是用于数据加密、校验等的基础功能模块。包括随机数产生、3DES加密、MAC计算模块、CRC计算模块等。第二部分是文件的权限控制模块。在BES COS中, MF、DF和EF的文件头中保存着一个权限范围, 而系统在某一时刻都有着当前的权限值, 如果权限值在权限范围中, 则可以进行相应操作, 否则, 则需要外部认证等手段改变系统当前的权限值。
4. 智能卡的测试
4.1 测试环境
智能卡的测试主要分两个部分, 一是硬件测试, 二是软件测试。
从硬件测试的层面来说, 选取一个功能强的专用于测试读卡器是十分必要的。比如在IC卡的7816通信接口还没有完全实现的时候, 通过普通的读卡器对卡片进行操作, 返回值在读卡器这边是无法看到的, 因为大多数读卡器屏蔽了不符合7816的TPDU规定的数据, 而如果每次都用示波器观察硬件信号的话, 效率又比较低。所以应该尽量选择可以看到底层交互数据的读卡器。
从软件测试的层面来说, 选取一个对上层提供了友好的接口的读卡器也是十分必要的。例如我在开发BES COS时使用的读卡器Collis, 提供了与其配套的脚本开发环境Collis Conclusion, 可以方便的设置读卡器的电压, 频率, 等待超时时间等。还提供了设定期望返回值的功能。
4.2 测试脚本
测试脚本主要分为功能正确情况测试, 功能异常情况测试, 参数测试, 安全机制测试以及应用流程测试。
功能正确情况测试是指在输入的参数都合法, 执行的条件都具备, 所执行的命令应该可以正常执行的情况下, 检查所测命令是否能够正确执行涉及的功能步骤。功能异常情况测试是指在输入的参数都合法, 但执行的条件不具备, 检测COS是否都返回了相应的错误代码。参数测试是指, 固定所测命令参数P1、P2、Lc和数据与正确且不变的情况下, 利用穷举法便利每一个错误的CLA作为输入参数, 测试COS是否都能正确响应错误代码, 其他的参数测试同理。安全机制测试是指在操作一个基本文件时, 该文件可能有一个或者多个安全控制机制。应用流程测试, 是指将命令组合起来成为一个应用流程, 检测整个流程是否都能正确执行, 检测基本命令之间是否会有影响。
5. 结束语
目前COS已经通过了第三方的测试, 目前正在准备上金融卡检测中心的测试平台。COS开发中最大的困难就是调试不便, 直到后来在芯片中加入了OCI, 才可实现单步调试以及存储单元值的查看。COS的开发语言C/汇编也比较低级, 影响了开发的效率以及易维护性。相信随着IC卡成本的降低, 支持java语言的java卡会更加的普及。
参考文献
[1]王爱英, 智能卡技术, 北京:清华大学出版社, 2010.
人机界面测试 第8篇
图形用户界面 (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中进行。
