网站测试，Web性能测试与可用性测试

网站测试，Web性能测试与可用性测试（共11篇）

篇1：网站测试，Web性能测试与可用性测试

Web性能测试

(1)连接速度测试

用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网，当下载一个程序时，用户可以等待较长的时间。但如果仅仅访问一个页面就不会这样，如果Web系统响应时间太长(例如超过5秒钟)，用户就会因没有耐心等待而离开。另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登录了。而且，连接速度太慢，还可能引起数据丢失，使用户浏览不到本来的页面。

(2)负载测试

负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如，Web应用系统能允许多少个用户同时在线?如果超过了这个数量.会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?

(3)压力测试

压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃，

web可用性测试

(1)导航测试

导航实际上是给访问者提供了一个类似地图的东西，让访问者更快捷的找到需要的东西。它描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如，按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题.可以决定一个Web应用系统是否易于导航：导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?

(2)图形测试

在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面

的效果。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮

等。图形测试的内容有以下几个方面。

①要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。

②验证所有页面字体的风格是否一致。

③背景颜色应该与字体颜色和前景颜色相搭配。

④图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩.

篇2：网站测试，Web性能测试与可用性测试

本文介绍三种可用性测试方法，可能很多朋友已经知道，不过对于网站设计师来说可用性测试时十分重要的，所以再次整理出来供分享。

我们先说下为什么可用性测试如此重要。

首先可用性测试可以发现你网站的潜在问题，通过可用性测试获得的反馈数据，可以了解一个用户在你网站中做了什么，以及用户如何看待和理解你的网站。

此外优秀的可用性性网站可以增强用户的互动性，用户也更愿意将网站分享给其他人。对于电子商务网站来说，可用性可以增加网站转化率。

总之可用性可以增加你网站的附属价值，而如何对网站进行可用性测试则是本文将重点谈到的内容

三种可用性测试方法

可用性测试的方法其实有很多(大概有20多种)，而且在不断发展，不过本文将主要介绍的三种方法是最常用的可用性测试方法。对于任何网站来说几乎都需要使用。

单一的可用性测试

单一的可用性测试时最简单的测试方法，主要是测试网站的程序，导航结构，布局等的使用是否正常，

也就是保证网站的所有功能和页面都能正常访问和使用。

A/B可用性测试

A/B可用性测试是将A和B两个网页之间的用户使用情况进行对比，一般这两个网页都是相关的，比如更换网页上的某个按钮夜色，导航条选项，文字内容等。然后将更改过的网页与未更改的网页进行可用性测试对比，看看用户对于更改后的使用情况区别。

一般A/B测试就是为了调整网页上的局部元素而做的细节测试。下图是使用A/B测试两个搜索引擎的用户使用习惯，图中的许多圆点就是用户视觉关注点。

偏好可用性测试

下图是一个偏好可用性测试案例，两张图片并列，从用户视觉停留上来发现用户更喜欢哪张图片，通过偏好可用性测试可以了解哪些新共更能或元素更吸引用户。从而对网页进行调整。

可用性测试的目的都是为了发现问题，对于一般设计师来说不一定需要很多人参与才能做可用性测试，找几个朋友或者2~3也可以做测试。

篇3：Web项目性能测试的分析与实践

关键词：性能测试,测试脚本,负载模型,loadrunner

1 Web项目性能测试过程

标准的Web项目性能测试过程，包括确定性能测试需求、开发性能测试脚本、定义性能测试负载模型、执行性能测试和形成性能测试报告。

1.1 确定性能测试需求

科学定义Web项目性能测试需求，对一个成功的性能测试非常重要。通常，Web项目的性能测试需求分为基于在线用户的性能测试需求和基于吞吐量的性能测试需求两种描述方法。

1.2 开发性能测试脚本

在确定Web项目性能测试需求后，就要根据性能测试需求中确定的功能开发性能测试脚本。

1.3 定义性能测试负载模型

性能测试负载模型定义了测试工具如何向Web项目提交请求，包括向Web项目发送请求的虚拟用户数，以及发送请求的速度和频率。

1.4 执行性能测试

执行性能测试是指通过多次运行性能测试负载模型，获得系统的性能数据。在执行过程中，需利用测试工具、操作系统、系统软件提供的资源监控手段对资源进行监控和分析，帮助发现资源瓶颈，并在系统层面进行优化。同时，还需对应用进行性能分析，帮助定位应用代码中的性能问题，切实解决系统的性能问题[1]。性能测试项目的最后阶段就是向相关人员提交性能测试报告，汇报性能测试结果。

2 实例说明

下面以某个单位的《项目月报管理系统》的性能测试为例进行实例说明。

本系统的主要用户为项目管理员、项目经理、部门领导以及公司领导，用户量在600以内;涉及的业务为公司项目管理、周报和月报录入、数据的统计查询操作;此系统的可用周期为3年。根据以上的特点，此系统的性能测试用例主要从以下几个方面设计。

2.1 项目管理

本部分的功能主要是对项目信息的输入与修改操作，这其中也会涉及数据库的查询。由于修改操作的执行过程分为对数据库的查询与修改两个部分，因此，这一部分的测试主要放在插入与查询数据库部分。可以参与项目管理的用户为项目管理员，约100人，产生较大并发压力的可能性并不是很大。根据这部分功能的操作频率、数据量和使用用户的范围，项目基本信息管理将作为一个性能点用例，此过程还包括计划书上传和合同对应关系两部分，并发量在30个，就能满足用户的需求。

...................................................................

2.2 周报与月报管理

本部分的功能主要是项目管理员每月填写月报和PM每周填写周报两个功能。最终体现在对数据库的插入与修改操作，这其中也会涉及数据库的查询，由于修改操作的执行过程分为对数据库的查询与修改两个部分，因此，这一部分的测试主要放在插入与查询数据库部分。可参与这部分功能的用户为项目管理员和PM，公司内部的项目管理员的数量大约在100人，PM则在400人，周报与月报的录入是本部分的主要性能点，而周报并发量在50个，月报并发量在30个时，就能满足用户的使用需求。

2.3 综合查询

本部分功能主要是对项目管理、月报管理和周报管理的录入信息进行查询统计，涉及的数据库操作就是查询操作。根据日常业务特点，这一部分的主要性能点为项目查询、月报查询、周报查询。这一部分的用户除了项目管理员和PM，还有财务人员，部分领导和公司领导等人员，用户量在600以内，并发量在50个，就能满足用户的使用需求。

2.4 测试说明

2.4.1 用例1：添加项目

用例描述：针对项目管理功能，测试多个项目管理员并发执行创建项目的响应时间。

停止测试条件：当响应时间超过30秒，或者错误超过10%时，或者产生明显的功能性异常，停止本用例在此数据量基本条件下的测试。参数配置：

(1)数据库(oracle):buffer cache:585M、share pool:205M。

(2)tomcat:minProcessors=″30″maxProcessors=″200″acceptCount=″100″。

测试工具及配置：

loadrunner：添加对服务器cpu和内存的监控，忽略thinktime，用户加载使用run until completion方式。

操作过程及测试数据：

(1)使用loadrunner脚本模拟不同项目管理员帐户创建项目，项目类别均为软件集成和事业部级R&D，表单中项目编号要唯一，项目名称与项目编号同名，行业为本项目管理员所在行业，行业可相同，项目区域可相同，开发所在地可相同，核心业务方向可相同，项目pm为本项目管理员所在部门的pm，项目pm可相同，开发周期可相同，计划起止时间可相同，项目启动时间可相同，验收完成时间可相同，预算可相同，选择分包项目或提前执行项目，备注可相同。

(2)点击提交，记录提交项目的响应时间。

(3)创建合同对应关系，项目编号必须唯一，合同名可相同，点击提交，记录合同对应关系响应时间。

(4)上传任务书和计划书，使用统一的测试Excel文件，点击提交，记录上传任务书和计划书的响应时间。

结果分析：

从数据指标(如表1、表2、表3)显示，系统能够满足这部分三个应用功能的并发要求，30个用户下最大的响应时间不到16秒，响应时间随着用户量与数据量的增大而增加，其中文档的提交功能受数据量的影响较小;但是，如果持续进行并发访问，系统响应速度会不断下降，并发用户量越大(30个用户时性能很不稳定)，这种现象越明显，直到系统停止响应，重启系统后恢复正常，由此判断应用系统的稳定性存在问题[2]。

2.4.2 用例2：项目查询

用例描述：针对综合查询的项目查询功能，测试多个用户并发执行查询项目的响应时间。本用例分返回1条记录和100条记录两种情况。

停止测试条件：当响应时间超过30秒，或者错误超过10%时，或者产生明显的功能性异常，停止本用例在此数据量基本条件下的测试。

参数配置：(同用例1)。测试工具及配置：

(1)loadrunner：添加对服务器cpu和内存的监控，忽略thinktime，用户加载使用run until completion方式。

(2)普通计时器。

操作过程及测试数据。

(1)配置显示所有的列。

(2)添加项目查询页中常用的查询条件，包括所属行业、项目区域、项目编号、所属PM、项目类别、行政部门、开发状态、开发阶段、项目启动时间、计划结束时间、结束时间。

(3)点击查询，记录结果为1条和100条的响应时间。

(4)当显示查询结果时，用普通计时器记录查询结果为1条和100条的响应时间。

结果分析：

从数据指标(如表4、表5、表6)显示，对于项目查询功能系统最大能够满足30个并发用户的需求，在2007年的数据量下只能满足20个并发需求;如果持续进行并发访问，系统响应速度会不断下降，并发用户量越大这种现象越明显，直到系统停止响应，重启系统后恢复正常，由此判断应用系统的稳定性存在问题。查询结果数据的送显时间随查询结果数据量的增大而增加，与并发访问量无关，从送显时间看，不会影响用户的使用。

3 系统综合评价

从测试结果数据看，系统性能表现较好，基本能够满足2006年以前20个并发用户的访问需求(数据库中约3000个项目)，即用例1添加操作的响应时间小于10秒，用例2查询操作的响应时间小于20秒。但是，如果按照目前数据增长趋势，系统在2006年之后不能很好的满足用户需要(数据库中5000个项目);通过测试发现，在模拟2007年数据情况下，系统查询功能和性能下降较快，如在2007年数据量下，单个PM用户进入项目列表界面时需要50秒的时间[3]。

在整个的测试过程中应用服务器的CPU平均利用率保持在30%以下，而数据库服务器的CPU平均利用率较高，在20个并发查询操作时达到80%～90%，说明本应用查询时对数据库服务器的操作较多，对CPU的性能要求较高;同时，数据库和中间服务器的内存使用均在100M～400M左右，并且没有出现较大的波动，说明本应用对内存资源使用较为平稳。

4 结束语

Web项目性能测试项目成功的关键不在于性能测试工具，而在于有效的性能测试分析方法和实践。只有切实掌握性能测试需求分析方法，获取性能测试实践经验，才能保证一个Web项目性能测试的成功。

参考文献

[1]赖利锋,刘强.Web应用程序的一种功能自动化测试模型与实现[J].上海:计算机工程,2006,32(17):123-125.

[2]李康荣,贾迪,张瑶.基于Web系统测试的应用研究[J].成都:中国测试技术,2006,32(6):114-116.

篇4：网站测试，Web性能测试与可用性测试

关键词 Web应用软件 计算机 测试 分析

中图分类号：TP31 文献标识码：A

软件测试的根本目的在于找出问题并以此为基础进行修正完善，Web应用软件性能优势也存在测试难题，只有对发展情况充分了解，才能以此为基础进行深入思考与研究。

1测试的目的

随着计算机应用范围扩大，其应用软件的质量对更多领域具有关键影响，任何细微差错都有可能对社会、经济、生活造成大规模损害。而软件测试是保证软件质量的有效手段，因此也成为开发中必不可少的环节。数据显示，当前软件开发过程中，测试环节投入已占整体的40%左右。

Web应用以不需安装、不受限于硬件平台等优势迅猛发展，已逐渐成为计算机应用的主流，但也由于其异构、并发、分布、不依赖于平台等特点，问题复杂性与可控难度随之加剧，Web应用测试与分析具有更强的现实意义。

基于以上，Web应用测试的主要目的在于：保证其功能的正确性、对浏览器的兼容性、性能的优良性，从而确保在实际应用中的安全与可用。其根本目的是找出应用中的错误。

2现阶段关于Web应用软件的测试与分析

基于Web应用软件的自身特性，测试内容设定需更严谨。现阶段基于传统软件测试基础已发展出针对Web软件应用的测试技术与工具，但测试方法尚不成熟。

2.1内容

基于Web应用的复杂性，对其测试与分析的内容也需更加细致、全面。从其特点与要求出发，对Web应用软件的测试与分析的内容主要包括：功能、性能、安全性、可用性、兼容性、接口。其中涉及界面、覆盖性、配置、链接、表单、Cookie、设计语言、数据库、回归、任务与业务逻辑、响应速度、负载能力、压力恢复能力等多方面测试内容。

2.2方法

采取适当的测试方法是完成测试目标、提高测试成效的必备条件。软件测试的方法主要可分为静态测试、动态测试两方面，静态测试主要针对文档与源程序进行检测与分析，在不运行软件的情况下发现应用的逻辑与编码错误；动态测试主要包括白盒测试、黑盒测试、灰盒测试，是在运行软件的前提下测试软件执行效果，对其正确性、安全性与可用性进行判断。其中白盒测试与黑盒测试的测试角度各有偏向并且较为极端，而灰盒测试介于二者之间，对高层设计、环境、操作等均有涉及，特别适用于Web应用的测试。

为保证测试严谨性可按测试周期将测试分为四个环节：单元测试、集成测试、系统测试、验收测试。

此外，选用合适的测试模型能够为软件测试效率提供帮助。常用的软件测试模型有V模型、W模型、H模型、X模型、前置测试模型等，各模型具有自身特性与适用方向，并对其它模型的漏洞具有修正性，因此，适用测试模型的关键在于模型的选择与搭配。

3思考与建议

Web应用软件的功能性能优势是基于其体系结构的特性而建立起来的，因此对其的测试与分析也应在传统软件测试体系基础上更具针对性。

3.1特性与难点

区别于传统软件，Web应用软件体系结构复杂、层次多，这也是Web程序易出错的主要原因。另一方面，Web应用的使用环境多样、复合技术多、兼容性要求高，是造成其测试难的主要原因。与此同时，用户量大、运行实时性要求高是其最主要的特性与要求。基于此，对于Web的测试需要符合其实际特性，并跟上发展节奏，否则测试体系的不成熟将成为制约Web应用软件发展的因素。

3.2关于现阶段研究方法的思考

现阶段对Web应用测试已有一定的理论与实践基础，其技术与工具能够支持测试工作，但其中存在较多漏洞，因此现阶段对其研究的重点应集中于以下方面：（1）对现有技术与工具的漏洞进行针对性修正，按层级、周期、面向对象进行分层分析与试验；（2）针对Web应用的测试体系的搭建与完善。

3.3关于性能测试的建议

基于以上观点，从性能测试方面提出建议，以期为Web测试体系优化提供参考。

在性能测试中通常采用的主要手段是压力测试，良好的性能测试需在提供压力的基础上对后台进行监测，并快速分析数据，从而找出被测系统的临界值。基于对此的试验与思考，需从以下几方面深入研究：（1）服务器端资源资源监控问题；（2）测试工具的开发。主要实现手段可通过：脚本语言的掌握、测试工具的使用程度、测试手段的丰富等方面。

4结语

测试与研究对Web应用软件的质量具有重要意义，是其发展的保障。基于对当前状态的论述与总结，本文对Web应用软件测试与研究的重点提出观点，并从性能测试环节给出一定建议。文章并非对具体技术与工具进行研究，而是以给出思路为主，以期对后续具体试验及开发工作起到参考与指引作用。

（作者学号：1330514）

参考文献

[1] 郭华杰.灰盒测试方法研究.天津大学，2006（02）.

[2] 路晓丽.Web应用测试技术研究.西北大学，2009（06）.

篇5：网站测试，Web性能测试与可用性测试

N-Stalker Free Version

N-Stalker Web 应用程序安全免费版本能够为您的 Web 应用程序清除该环境中大量常见的漏洞，包括跨站脚本(XSS)、SQL 注入(SQL injection)、缓存溢出(Buffer Overflow)、参数篡改 (Parameter Tampering)等等。

Netsparker Community Edition

Netsparker Community Edition 是一款 SQL 注入扫描工具，是Netsparker的社区免费版本，提供了基本的漏洞检测功能。使用友好，灵活。

Websecurify

Websecurify 是一款开源的跨平台网站安全检查工具，能够帮助你精确的检测 Web 应用程序安全问题，

Wapiti

Wapiti 是 Web 应用程序漏洞检查工具。它具有“暗箱操作”扫描，即它不关心 Web 应用程序的源代码，但它会扫描网页的部署，寻找使其能够注入数据的脚本和格式。

Skipfish

Skipfish 是 Google 公司发布的一款自动 Web 安全扫描程序，以降低用户的在线安全威胁。和 Nikto 和 Nessus 等其他开源扫描工具有相似的功能。

Exploit-Me

Exploit-Me 是一套 Firefox 的 Web 应用程序安全测试工具，轻量，易于使用。

OWASP WebScarab Project

WebScarab 一个用来分析使用HTTP和HTTPS协议的应用程序框架，通过记录它检测到的会话内容(请求和应答)来帮助安全专家发现潜在的程序漏洞。

X5s

篇6：网站测试，Web性能测试与可用性测试

《网站评价、测试、与发布》教学设计

（一）概述

学科：初中信息技术 年级：八年级（下）

课题的来源：《初中信息技术》（大连理工大学出版社），八年级（下），第二单元，第十四课：“网站开播了-网站评价、测试与发布”。所需课时：1课时

学习的内容：评价一个网站的基本标准；测试网站；申请免费主页空间，了解常用的网站上传软件；上传网站，并通过网址浏览；学会使用网上论坛进行交流推广。

这节课的价值及重要性：自主探究、知识迁移，利用DREAMWEAVER强大功能，处理实际生活中的信息。

（二）教学目标分析（学习目标分析）

知识目标：评价一个网站的基本标准，如何更具有吸引力；测试网站；申请免费主页空间，了解常用的网站上传软件；上传网站，并浏览；学会使用网上论坛进行交流推广。

能力目标：培养学生创造能力，提高学生自主学习、探讨能力、知识迁移能力、评价能力、网络综合应用能力。

情感目标：良好的学习习惯的养成，积极的态度 啊，负起责任，拿起你手中的鼠标，开始奋斗吧„

（三）网站发布

探究：使用DREAMWEAVER自身功能实现网站的上传

任务：①设置“远程信息”的相关参数，并测试连接服务器，千万别急于上传！同学们尝试一下设置“远程信息”。

探究：同学们联想一下还有没有其他的方法上传网站呢？（打开远程信息窗口）FTP（浏览器访问）法

上传软件法：CUTEFTP，WS-FTP„ 网上邻居法？U盘法？„

②区别整站上传和单个网页上传，并强调小组合作分工做网站时的上传方法，模块化制作原理的介绍，我们已经在潜移默化间使用了现今很流行的设计思维。同学们尝试上传自己修改过的网页 ③网址的分析及访问。

介绍熟悉的网址，并分析它所存放在服务器的位置。通过推理分析出自己网站的网址，并将首页地址描述出来。

同学们猜想自己小组的网址，尝试通过网址来访问自己小组的网站，即验证有效性。学生谈谈你所理解的三个词语： ①上传 ②主页空间 ③网址

注：网站发布的本质就是把本地硬盘制作好的网站文件传送到WEB服务器上。

（四）小组间网站的互评及自评

教师将学生小组制作并已经修改上传过了的网站进行列表整理，并发起投票贴。学生登陆论坛进行投票和互评回复，并对自己的网站进行自评总结。

篇7：可用性测试的权衡之道（二）

五.发现问题：真的 VS 假的

判断发现问题的真假，初看上去似乎不是个困难。多数或全部参与者都遇到的问题毫无疑问是明显的可用性问题。或许有人会建议，根据参与者中发现该问题的人数比例来判断：比例高是真问题，比例低是假问题。前半句话可以接受，后半句话则有待商榷。

虽然可用性测试是相对严谨的用户研究方法，但是其对无关变量控制的严格程度和真正的心理学实验还是有一定的差距;并且心理学实验对每组参与者数量的最低要求是30人，这样得出的结论(数量比例)才具有推论至一般的意义。而可用性测试一般才8人左右的参与人数(尽管招募的参与者在质的方面非常具有代表性)，但却无法把可用性测试中出现的所有数量比例简单推论至一般。8个参与者中有1人发现某个问题，不代表现实中出现同样问题的真实用户只有12.5%，更不代表这个问题不是真正的/严重的可用性问题。

问题的真假除了根据问题出现的次数比例，还有很重要的考虑点是：用户“错误行为”背后的认知/思考方式是否合乎逻辑?

这里顺便借用一下诺曼《设计心理学》里谈到的理论：概念模型――系统表象――心理模型。概念模型可认为是产品设计人员对产品的设计思想;系统表象可认为是产品展现出的交互界面;而心理模型则是用户按照既往经验对如何操作该产品的设想。从这个角度来认识，可用性问题则是“概念模型、系统表象、心理模型”三者的不吻合或矛盾。

通过分析用户行为背后的认知是否符合逻辑，来判断发现的问题的真假，主要体现在以下几点：

1.“概念模型、系统表象”的不一致

产品设计人员突然发现，界面的交互形式根本没有反映出他原先的设计思想!

2.“系统表象、心理模型”的不一致

(1)用户的思维方式受已有的同类产品的影响，并内化接受，而新产品的“系统表象”和已有同类产品并不一致。

(2)用户在日常生活经验中形成了许多并不科学地通俗理解世界的方式(比如通俗物理学、通俗心理学)，但产品设计人员没有意识到用户在以这样一种“自认正确”的错误方式来理解和使用产品。

如果发现的可用性问题属于以上情况，那么即使只有一个参与者碰到，它也非常可能是一个真正的可用性问题。

例如：让用户登录购彩网站，查看自己上次购彩结果。大多数用户点击【个人中心】去查看，有2个用户点击【开奖公告】去查看，发现只有开奖号码，没有任何购彩结果信息后，再去点击【个人中心】。仅2个人出现了稍微的偏差，而且很快就找到了正确的页面，这貌似应该不算什么问题，

但若追究其行为背后的逻辑，并与其他用户的反馈(“我上次买的号码没有直接显示出来?”“这里看不到开奖的号码啊?”)联系起来，可以判断用户的心理模型和产品的系统表象不一致。用户希望能同时对照着开奖号码和自己买的号码很方便地核对，而网站却割裂两部分放在不同的页面，因此需要将这2个用户碰到的问题当作真正的可用性问题来对待。

六.研究方法：定性 VS 定量

可用性测试，很多时候被认为是一种定性研究方法;但也有人说它是一种定量研究方法。究竟是怎么回事呢?

个人认为，可用性测试实质上结合了定性和定量两种方法的特点，到底哪种成分更多，要看你的使用目的以及细节上如何操作。

定量研究的思路是基于对一定数量样本的测量，以将研究所得的结论推广至总体。除了强调样本的代表性，还对样本的数量有具体的要求，同时会考虑抽样误差、置信度、置信区间的度量。并且定量研究过程中非常注重对某些自变量操控、及无关变量的控制。

而定性研究重视对主观意义的理解(如背后隐藏的原因)，采用解释建构的方法，比如访谈法等。

平时工作中以“形成式可用性”测试为主，即便它稍微偏向于定性研究，但在允许的范围内，我个人还是尽可能地遵循着定量研究的方法去实施。这样整个测试过程的严谨性能得到保证，结论的客观程度相对更高(近几个世纪来，量化研究一直是科学研究的主要范式，也正是这个原因)。具体做法如下：

1.在任务的设置上：因为参与者可能存在差别较大的亚群体，不可能要求完成完全相同的任务。但必定会设置大部分基本的、都需要完成的公共任务，再针对不同亚群体设置少量的特殊任务。在后期统计分析的时候，基本的公共任务则可以进行数量化的统计，并横向比较。

2.在测试过程中：关注参与者完成任务时的相关行为，用数字来记录(以0、0.5、1分别表示失败、帮助/提示下成功、成功)。主试尽量少地言语及体态姿势的干扰，只在必要时进行适当地言语交流。

3.在报告呈现：对任务完成情况(效率、完成率)统计呈现，对不同任务的完成情况进行比较，对亚群体间的任务完成情况进行比较，对所有可用性问题按数量化指标进行排序等。或者比较迭代前后独特问题的频次是否减少，以及严重程度高的等级里面可用性问题数量的变化情况。

4.测试过后，我们通常还会收集用户自我报告式的数据，作为“感知可用性”的一个总体反映。

(1)推荐使用系统可用性量表(SUS)，因为有研究表明SUS在少量样本时即可产生较为一致的评分结果。

(2)为减少用户在填写这些量表时的反应心向，不要求填写任何个人信息，且主试最好暂时回避。

篇8：地方财经门户网站可用性测试

关键词：可用性,地方财经门户网站,可用性测试

一、引言

地方财经门户网站作为财经门户网站的未来发展热点之一, 其发展日益受到网民的关注, 针对地方财经门户网站存在的定位不明确, 用户访问效率低下、界面不友好等可用性问题, 用户体验差的现状, 本文将运用可用性测试对地方财经门户网站进行实证研究。

二、地方财经门户网站可用性测试

财经门户网站, 是指通向财经综合性互联网信息资源并提供财经信息服务的应用系统 (1) 。它主要向财经用户提供财经信息、财经数据、各类应用系统服务。

地方财经门户网站, 主要提供地方综合财经信息并提供相关网络信息服务的财经门户网站, 其特点是“服务地方”。

网站可用性测试 (web usability testing) 是使用科学的测试方法来对用户使用网站导航、在网站上完成若干任务等方面进行测试, 测试者观察其行为并作记录, 进行分析得出网站的使用简便性 (2) 。

(一) 测试目的与方法

本次测试的目的是通过对选择的5个地方财经门户网站进行可用性测试, 找出目前财经门户网站可能存在的可用性问题并提出相应改进意见。

在20世纪90年代Instone提出情景式评估法, 他认为情景式评估法可以用于网站的可用性测试, 有助于网站提高交互能力。情景式评估法需要创设情境, 设定访问任务, 选择实验者扮演网站用户访问被测试的网站, 在执行过程中找到影响任务实现的问题。

(二) 选择测试对象

本文选择了湖北金融网、河南金融网、山东财经网、山西金融网、江西金融网五个地方财经门户网站进行可用性评估。

(三) 财经门户网站可用性评价指标

本文运用德尔菲法Delphi确定财经门户网站的可用性评价指标分别为内容质量指标、易用性指标、定制服务指标、效率性指标、情感因素指标。

(四) 设置实验情景和安排任务

第一步:设置实验情景

(1) 甲:24岁, 男, 某大学金融专业大二学生, 活泼外向, 爱好读书。经常利用课余时间打工, 半年积攒了5000元。他希望通过财经网站个人理财栏目了解专家意见、理财案例。

(2) 乙:35岁, 女, 工作于广州某贸易企业, 由于工作很忙, 她打算先上网了解最新房产新闻信息, 购房产生的相关税费及贷款利息再决定是否购买。

(3) 丙:40岁, 男, 经营一家网店, 由于没有固定收入, 他打算先通过财经网站理财频道了解保险的具体内容, 希望未来能获得一定的保障。

第二步:选取实验人员和实验培训

本研究参与者主要是信息技术学院2013级在校学生, 共3个教学班, 人数150人。实验培训内容主要是可用性评价指标及评分标准。

第三步:分组并根据设计情景完成任务清单

为了使实验过程不受外界各类因素的影响, 整个实验过程被统一安排在学校电脑配置一致的210机房。将150名实验人员随机分成10大组, 每大组30人, 每个大组分为3个小组, 每个小组10人, 3个小组通过抽签选择甲、乙、丙的角色。每个小组都安排一名现场工作人员, 以随时解决突发问题。

第四步:组织实验人员填写财经门户网站可用性评估问卷

在所有小组人员完成任务后, 工作人员发放财经门户网站可用性评估问卷, 要求实验人员依据问卷中的可用性评价指标, 对选取的网站进行打分。强调评分方式, 要求实验者进一步熟悉可用性量表, 分数越高表示可用性问题越严重。

(五) 问卷回收和整理

工作人员将回收的有效问卷进行整理并将数据输入Excel进行数值统计, 计算每个网站各指标的平均分值。回收有效样本97份。

根据, 计算结果为山东财经网2.15分、江西金融网2.56分、河南金融网2.24分、山西金融网2.35分、湖北金融网2.58分。

(六) 测试结果分析

实验评分结果表明测试的5个网站的可用性水平存在显著差异, 其中山东财经网的可用性问题较少, 得分较低, 而湖北金融网存在可用性问题较多也较严重, 得分最高。

同时统计员已完成记录的网站可用性问题的归纳汇总, 发现地方财经门户网站目前主要存在以下方面的可用性问题。

(1) 网站定位不清晰, 主题不突出, 信息时效性差, 更有与网站主题不相符合的内容;有的网站栏目没有实际内容, 网站缺乏帮助信息来指导用户;网站内容知识含量不足。

(2) 网站主页上视频较少、页面单调, 有些网页和视频很难打开, 出错率高;网站布局复杂, 信息分类不细, 文字密集, 页面拥挤;导航系统设置不符合用户的使用习惯。

(3) 有的网站没有社区功能, 交互功能差, 访问者无法发表意见、进行学习和交流;建立社区的网站又无法实现其功能, 点击微博、QQ图标等按钮无法进入相应页面;网站功能较少, 没有相关的软件系统支持, 不能实现在线理财, 在线投资。

(4) 有的网站界面设计毫无特点, 没有自己的风格, 网站Logo和网站口号无法激发用户的兴趣;无特色栏目、独家专访、个性化设置, 无法吸引用户。

二、解决方案

(一) 加强对用户需求的研究

用户的需求是多样化的, 网站建设者应结合财经门户网站生命周期各个阶段的任务和要求对用户需求展开调查, 网站开发者应该做定期问卷调查, 动态地了解用户需求变化并能及时调整网站内容。

(二) 加强财经门户网站信息服务

只有不断提高网站内容质量, 注重内容的时效性, 及时更新, 才能保证用户能在第一时间获取最有价值的财经信息, 从而实现投资理财成功。

(三) 加强财经门户网站定制服务

用户需求呈现多样化, 碎片化, 长尾效应日益明显。实力和规模不够大的财经网站通过为不同用户提供不同服务争取到用户;网站为用户提供在线交流沟通、根据用户需求增减网站栏目频道, 增加个性化栏目, 增强网站的黏性。

(四) 增强网站对用户的吸引力

网站的页面风格和布局、网站人性化的设计使用户对网站充满好感。网站建设者需要了解回访者的回访原因, 然后努力提升网站的吸引力。

三、结语

地方财经门户网站在可用性方面存在定位不明确、用户体验差、访问效率低下、信息更新不及时等问题, 地方财经门户网站若要获得生存和发展的机会必须尽快解决自身可用性问题, 为地方民众提供优质的财经信息服务。

参考文献

[1]张胜利.三大门户网站商业竞争及盈利前景分析[D].武汉:华中科技大学, 2007:5-10.

篇9：织机送经机构的性能测试与评价

关键词：虚拟仪器；送经机构；织机；模糊理论

送经机构是根据织物纬密的大小，在织造阶段按时稳定的供应具有张力的经纱，其是织机机构中得重要运动机构，其能够保证织机稳定连续的进行织造生产。在织机运行阶段，衡量送经机构性能优劣的主要标志是确定其能否在织造过程中保证织轴能够始终输出均衡稳定的经纱张力。同时，诵经机构性能也会影响织物的质量，一些织疵的出现与其有直接的关系，如长片段送经不匀会造成长短码疵点。因此，对于织机送经机构性能测试于评价，对织造质量的提升具有一定的益处。

当前，对于送经机构测试和评价方法在应用中都存在弊端，如利用传统的测试及评价方法，由于记录仪的限制，不能够对送经量进行长时间的准确现实，测试数据的不足，在一定程度上也限制了评价方法的发展。本文所研究的性能测试及评价方法，采用的时虚拟仪器测试技术，其基于LabVIEW开发平台上。

1、系统的组成

在图1中，可以比较直观的看到利用虚拟一起技术的测试系统组成框图，其中利用差动变压器来作位移传感器，利用电压值对织机主轴一转内的送经量进行量化，其中RO4讯号源于组合滤波器作为系统的信号调理器，其可以对差动变压器输出的电压进行调理，并调理成稳定的0-5v的直流电压。霍尔传感器于主轴上的磁缸能够组成一个非接触式接近开关，其所发出的0～5v的脉冲电压能够作为送经量采样的触发信号。数据采集卡所使用的时PCI-6024E多功能数据采集卡，是由美国NI公司生产制造，采样的速率为200kS/s，其中包含A/D通道8个以及D/A通道2个。在本测试系统中共采用了两个A/D转换通道，分别接收来自织机主轴0度时霍尔传感器发的采样触发脉冲和对应送经量的标准的0～5V的直流电压。

2、测试数据及处理

本文所测试机台的织制品种60/2*JC30，120*75，63“，1/1。实测日本津田驹ZA209i的车速为555.18转/分，实测国产YC-XX型织机车速为559.88转/分。分别对上述两种机型300纬的送经量进行测试，并且为消除测量异常点的因星光，对ZA209i机台的7个异常点和YC-XX机台的4个异常点进行了清除，以下是对所获得数据的处理：

2.1 累积送经量

在测试中，我们发现，YC-XX织机的平均送经量0.3619mm/纬；ZA209i织机的平均送经量0.3507mm/纬。在图2、图3中，分别对两种织机型号送经量累积曲线予以直观的表达，其中没纬送经量的序号在横坐标中可以直观的表示，而每纬送经量累积值（单位为毫米）在纵坐标中有所体现。从表中可以看出两种型号织机累积送经量为一条直线，这说明织机送经量机构工作比较稳定，送经量基本保持为恒定值。

2.2 送经量测试曲线

以每纬送经量的序号为横坐标，各纬送经量值（单位为毫米）为纵坐标作曲线，可以得到送经量测试曲线图（如图4及图5），从图中可以直观、清楚的看出依次各纬送经量的差异情况。

3、性能评价

3.1评价指数

我们假设织机每纬送经量的实测样本值为X1，X2，…，Xn，而工艺要求的送经量为Lj，则评价送经机构性能优劣的指标应与送经量实测样本值的平均值及标准差有关。为了能定量评价送经机构的性能，我们引入一个称为“性能评价指数”的统计量LH：

其中，λ1、λ2为权重系数（ ），一般可取λ1=λ2=0.5； 为样本均值。

根据织机送经机构的性能评价指数定义可知，其值越大说明送经机构的性能越优。

经计算，ZA209i及YC-XX两台织机送经量样本实测值均值分别为0.3507 mm/纬、0.3619mm/纬，而样本标准差分别为0.0055、0.0042。测试机台的织物成布纬密Pw=295根/10厘米，经纱对成布的缩率aj%=12.39%，得工艺要求送经量Lj=0.3869。令λ1=λ2=0.5，则

ZA209i：LH=104.7212

YC425：LH=133.6364

由以上性能评价指数可知，YC-XX织机送经机构性能稍略高于ZA209i织机。

3.2 相近度

根据美国California大学的L.A.Zadeh教授著名的“互克性原理”，一旦系统的复杂性超过一个阈值，复杂性和精确性将互相排斥。由于织机送经系统的复杂性，我们尝试采用模糊数学的方法来评价送经机构，以期获得较好结果。

我们假设织机送经量X1、X2、…、Xn属于正态模糊分布，其隶属函数为

根据模糊数学理论可知，衡量两个模糊集合之间的相似程度，可以采用模糊距离或贴近度来度量。为了评价两台织机送经机构性能的差异，便于进行对比分析，引入相近度指标。在此定义送经机构相近度为模糊集合的格贴近度：

其中， 内积：

外积：

设ZA209i及YC-XX两台织机送经量隶属函数分别为：

其中，μ1、μ2分别为两台织机送经量样本均值，σ1、σ2分别为两台织机送经量样本标准差。

根据定义，计算出ZA209i及YC-XX两台织机送经机构性能的相近度为

图8中的粗实线的顶点表示两正态模糊集合的格贴近度，可见相近度为0表示两台织机送经机构性能完全不同，相近度为1表示两台织机送经机构性能完全相同。本例相近度为0.5135，说明ZA209i及YC-XX两台织机送经机构性能的相近程度相当大。

4、结束语

通过实际测试以及对所获得的测试数据处理，可以得出以下结论：

（1）对送经量进行测试，可以比较方便的计算出送经机构的评价指数和相近度指数，进而能够定量评价出织机送经机构的性能，这种测定方法适用于开发新机时，对其性能进行对比分析与评价；

（2）基于虚拟仪器测试技术，所测试的数据可以以.xls的文件格式存入计算机硬盘中，该文件格式可用Excel软件打开，方便对数据的处理，保证评价的直观性和准确性；

（3）从统计学角度，利用性能评价指数能够对送经机构的性能优劣的定量差别进行表明。从模糊数学的角度，相近度能够表明送经机构性能的相近程度；

（4）综合分析，利用送经机构的性能评价指数和相近度指数这两项指标，不仅能对两台送经机构性能的优劣进行定量评价，而且也能够对两台送经机构性能的差异程度进行估算。

参考文献：

[1] 黄洪钟，机械设计模糊优化原理及应用[M].第一版，北京：科学出版社，1997.

[2] 雷振山，LabVIEW 7 Express 实用技术教程[M].第一版，北京：：中国铁道出版社，2004.

[3] 陈元甫，机织工艺与设备（下册）[M].北京：纺织工业出版社，1984.

篇10：web测试心得

1、注册和登录模块的测试

在测试该部分时，给我印象最深的就是：

1)注册成功，但登陆失败：注册时，密码设置为一些特殊的符号，比如：空格、%等，但登录时，失败。

后来经开发人反映出现这样的问题，原因是：在登录模块，对密码设置了一些限定。

2)登录时，没区分大小写，就是说，用小写字母注册的，登录时，用相应的大写字母登录也能成功。

出现问题的原因：登录时，没用MD5加密进行验证

2、购物车的测试

1)测试产品能否放入购物车中

2)当某种产品有购物数量限制时，超过这一数值，能否也能放入购物车中

3)购物车中的购物限制是否正确

3、支付流程测试

1)购物车中的产品能否正常支付

2)当支付完成，不等页面跳转，直接关闭浏览器，数据传递是否正确

3)当支付完成，等待页面跳转，跳转到得页面是否正确

4、网站某个模块间的数据传递是否正确

当网站某个模块涉及的数据传递比较多而且比较复杂时，一定要搞清楚数据是怎么传递的，因为这是最容易出现bug的地方。比如：下拉菜单的数据没有传递过来，或传递过来了，但不正确，这时就要静下心来，慢慢滤清思考，耐心去测试。

篇11：可用性测试的权衡之道交互设计

可用性测试中的原则同样如此，需要根据目的、资源、环境的不同，灵活把握、权衡取舍，而非一味恪守某一个或某几个原则，也许这才是可用性从业人员经验重要性的体现。

一．任务设置：精细 VS 宽泛

制定的任务过于精细，一般原则上是反对的。理由很清楚，如果你的任务精细到一步一步“引导”用户进行操作，那太不符合用户现实中的使用情境，平时没有人在旁边“引导”用户的每一步操作；而且过于控制用户的操作步骤，用户缺乏真实使用时的灵活性。

是不是我们设置的任务只能是宽泛的，不能细化呢？这就必须根据研究的目的来做抉择。如果产品处在设计的初期，我们需要关注一些宏大的问题（如：网站的整体架构、导航和分类的合理性、页面的逻辑关系），此时就需要通过宽泛而有弹性的任务，来查找宏观层面的问题。如果产品的设计已经非常完善，开始进行细节的修改迭代，此时就需要通过设置相对具体的任务来查找特定的细节问题（如：对某个命名的理解、按钮的使用、链接的点击、表单的填写）。按照《Don’t make me think》一书的观点：一般用户使用互联网产品时满足于能用就行，不会寻求最好的使用方法；只扫描网页，不会仔细阅读。所以，如果完全宽泛有弹性地设置任务，虽然更吻合实际使用情况，但是很可能用户直接跳过你想考察的细节。

实际工作中，由于时间和资源的限制，无法做到每个产品从设计初期到上线前后进行多次可用性测试。可能在一次的可用性测试中即需要同时关注宏观方面和细节上的问题。此时，还是需要和产品经理、交互设计师反复沟通，确认测试的主要目的，同时通过对任务设置精细程度的权衡把握，使次要目的也尽量得以满足。

不过，即便是想考察细节的任务，也要尽量避免“直接指导操作”式的语言描述方式，这样能让任务与真实使用情境不会相距太远。例如：想考察豆瓣读书页面【想要】按钮是否能被看到、是否具备可点击感。下面列出两种表述方式，以作对比：

A.请找到您喜欢的那本书，并在该页面点击【想要】。（×）

B.请找到您喜欢的那本书，并在该页面对其作个标记。（√）

二．任务数量：多VS少

任务数量的多少与可用性测试考察范围有关，与任务的精细程度也有关。如果对网站全站进行考察和只对其中某个页面、某个操作流程进行考察，所需的任务数量自然不一样。在同样的考察范围下，如果任务设置得越精细，所需任务数量也就越多。

Lindgaard和Chattratichart的研究发现任务数量与发现可用性问题比例存在显著的相关关系（r=0.82，p<0.01）。为了尽可能多地发现可用性问题，我们就尽量多地设置任务给用户吗？

此时要考虑任务数量过多可能带来的弊端：学习效应和疲劳效应，尤其是靠后的任务更可能会受影响。心理学实验中处理此问题的方法是顺序平衡，抵消影响。但是可用性测试中设置的场景和任务存在特定的先后次序，不适合采用顺序平衡的方法。基于我们的经验，还是通过对测试的任务数量进行控制，确保正式测试环节最多不超过1小时，加上前后的欢迎语、访谈、问答等，整个过程不超过1.5小时。

此外，任务数量的多少还会间接影响到测试所需参与者数量的多少。

三．用户人数：5个足够VS 5个不够

Nielsen的研究发现，5个用户可以发现80%以上的可用性问题。这个结论得到许多人的推崇，因此称之为“魔法数字5”。这个结论的来源依据是每个用户平均可以发现30%的可用性问题，且假设所有问题都有同等被发现的概率。不过，当设置的任务数量过多，且任务的精细程度和难度多种多样时，这个前提有可能不成立。

Lindgaard和Chattratichart（2007）的研究发现测试用户数量与发现的可用性问题比例并不存在显著的相关关系。这个结论似乎又支持我们选择少量用户进行测试即可。

其实，在用户招募阶段，比用户数量更需要重视是用户的代表性的问题。能否招募到有代表性的用户将直接影响可用性测试的成败。如测试一个医疗软件产品，招募到医护人员和患者作为测试用户，那5个用户可能就足够了；但如果只招募到医学实习生来测试，就必须超过5个以上的用户（即便这样，也未必能推论到整个产品的用户群）。

由此看来，招募用户的人数和任务的数量、精细程度、用户的代表性也是息息相关的。参考Tom Tullis（）和本人经验：当可用性测试范围限定在一定的范围（20个任务内、或30个网页之内），且招募到很强代表性的用户，那么5个足够了。如果存在着差别较大的亚群体，争取做到每个亚群组有5个左右的代表性的用户（当然，目标用户的特征及分类应该是在可用性测试之前的用户调研阶段就解决的问题）；一次测试最多不会超过12个用户。

四．用户表现：行为VS言语

在可用性测试中强调对用户操作行为的关注，是毋庸置疑的。因为：

1.用户的行为指标更明确、具体、客观，易观察和记录。

2.如果完全把关注点放在用户的操作行为上，那么就无需跟用户进行多余的（指导语之外的）语言交流。类似于心理学研究规范，对实验或测试中的指导语进行统一，对一切无关变量（包括主试的语言、体态表情）进行控制，以减少对研究过程的干扰。

3.即便你直接询问用户某些问题，也极可能得到错误的答案。30年前Richard Nisbett和Timothy Wilson的实验、2年前Peter Johansson在《science》的文章，都证实了某些情况下人们无法解释清楚自己行为的真正原因。另外，用户还可能揣摩主试的喜好，回答他们认为主试期望的答案。

因此，有必要强调在可用性测试过程中关注的重点永远应该是用户的操作行为，而且尽量减少任何无关变量的干扰。但这个原则被有些人引申到极端，认为只有观察用户的操作行为才有意义，其他信息都是无需关注的，甚至轻率地怀疑用户的话都是不可信的。

可用性测试的主要目的虽然是发现问题，但也需要了解问题背后的原因，而仅仅依靠观察用户的操作行为是无法获悉所有问题背后的原因的，此时，我们就希望用户能采用“出声思维法”，出声思维就是集中于如何与产品进行交互的意识流。如果测试中的氛围比较平等、自然、融洽，用户又特别愿意表达，那么用户就会在进行任务操作同时，表达他们想做什么、打算如何做、背后的原因是什么。此时，不仅是操作行为、用户表达出来的想法和原因、以及语言中透露出的疑惑、失望、不满、惊讶、犹豫等情绪同样是需要我们加以关注的。但是，有些用户比较内向，不善于主动表达自己的想法，此时就需要主试跟他进行简单的交流，以引导用户说出背后的原因（注：不是引导用户说出你期望得到答案）。

所以，在实际的可用性测试，基本应该以关注用户的行为为主，少量、适时地进行询问交流也是需要的。但这个度如何把握呢？

1.当用户出现犹豫、惊讶、任务失败（过程节点上出现自然而然地稍微中断/暂停）的时候才进行简单的询问。

2.询问采用一般疑问句的句式，重复用户刚才的行为表现（要具体客观）：“你刚才没有……，是吗？”——虽然没有直接问“为什么”，但暗示了希望听到他进一步的解释。

3.如果用户没有自己主动说出原因，可以“顺便”问一下“为什么？”或通过身体前倾、目光注视等非语言方式来暗示用户你希望能听到更多内容。若用户很快、坚定地说出原因，则该理由的可信度较高；如果用户犹豫、或难以说出原因，就不要继续追问。

除了上述的语言、情绪、行为都需要得到关注，还有一种特殊情况是需要听懂用户“没有说的”语言。例如，我们预计网站的某二级导航标签和一级导航标签存在分类逻辑上的不合理；但用户在测试中，导航相关的操作步骤进行得很流畅，用户也什么都没说。这通常表明用户认为这些是理所当然的、不影响操作的——此时你需要听懂用户“没有说的”语言。如果你简单粗暴地打断用户并询问：“你觉得这两个导航标签如何？”，则变成了一种诱导性地提问。

总结一下关于此部分内容的实践应用：

1.用户的操作行为永远是可用性测试的重点。

2.鼓励用户采用“出声思维法”。

3.适时、少量地向用户提问，禁止对同一个问题反复追问“为什么”。

4.采用真正地“倾听”技术保持和用户的交流状态，而非通过过多的话语。

5.开放、不预设立场地观察、倾听用户“没有说的”语言。

在可用性测试中考虑需要遵循的原则时，一定要理解它的适用条件，以及它和其它原则之间的互相影响，并结合本次用户研究的目的、资源、环境综合考虑，以尽可能形成一个最优方案。由于博文长度所限，先总结这么多，在下次的文章中会继续总结其它几方面的原则。

继续讨论可用性测试中各种原则的灵活运用和注意事项，

五．发现问题：真的 VS 假的

判断发现问题的真假，初看上去似乎不是个困难。多数或全部参与者都遇到的问题毫无疑问是明显的可用性问题。或许有人会建议，根据参与者中发现该问题的人数比例来判断：比例高是真问题，比例低是假问题。前半句话可以接受，后半句话则有待商榷。

虽然可用性测试是相对严谨的用户研究方法，但是其对无关变量控制的严格程度和真正的心理学实验还是有一定的差距；并且心理学实验对每组参与者数量的最低要求是30人，这样得出的结论（数量比例）才具有推论至一般的意义。而可用性测试一般才8人左右的参与人数（尽管招募的参与者在质的方面非常具有代表性），但却无法把可用性测试中出现的所有数量比例简单推论至一般。8个参与者中有1人发现某个问题，不代表现实中出现同样问题的真实用户只有12.5%，更不代表这个问题不是真正的/严重的可用性问题。

问题的真假除了根据问题出现的次数比例，还有很重要的考虑点是：用户“错误行为”背后的认知/思考方式是否合乎逻辑？

这里顺便借用一下诺曼《设计心理学》里谈到的理论：概念模型——系统表象——心理模型。概念模型可认为是产品设计人员对产品的设计思想；系统表象可认为是产品展现出的交互界面；而心理模型则是用户按照既往经验对如何操作该产品的设想。从这个角度来认识，可用性问题则是“概念模型、系统表象、心理模型”三者的不吻合或矛盾。

通过分析用户行为背后的认知是否符合逻辑，来判断发现的问题的真假，主要体现在以下几点：

1.“概念模型、系统表象”的不一致

产品设计人员突然发现，界面的交互形式根本没有反映出他原先的设计思想！

2.“系统表象、心理模型”的不一致

（1）用户的思维方式受已有的同类产品的影响，并内化接受，而新产品的“系统表象”和已有同类产品并不一致。

（2）用户在日常生活经验中形成了许多并不科学地通俗理解世界的方式（比如通俗物理学、通俗心理学），但产品设计人员没有意识到用户在以这样一种“自认正确”的错误方式来理解和使用产品。

如果发现的可用性问题属于以上情况，那么即使只有一个参与者碰到，它也非常可能是一个真正的可用性问题。

例如：让用户登录购彩网站，查看自己上次购彩结果。大多数用户点击【个人中心】去查看，有2个用户点击【开奖公告】去查看，发现只有开奖号码，没有任何购彩结果信息后，再去点击【个人中心】。仅2个人出现了稍微的偏差，而且很快就找到了正确的页面，这貌似应该不算什么问题。

但若追究其行为背后的逻辑，并与其他用户的反馈（“我上次买的号码没有直接显示出来？”“这里看不到开奖的号码啊？”）联系起来，可以判断用户的心理模型和产品的系统表象不一致。用户希望能同时对照着开奖号码和自己买的号码很方便地核对，而网站却割裂两部分放在不同的页面，因此需要将这2个用户碰到的问题当作真正的可用性问题来对待。

六．研究方法：定性 VS 定量

可用性测试，很多时候被认为是一种定性研究方法；但也有人说它是一种定量研究方法。究竟是怎么回事呢？

个人认为，可用性测试实质上结合了定性和定量两种方法的特点，到底哪种成分更多，要看你的使用目的以及细节上如何操作。

定量研究的思路是基于对一定数量样本的测量，以将研究所得的结论推广至总体。除了强调样本的代表性，还对样本的数量有具体的要求，同时会考虑抽样误差、置信度、置信区间的度量。并且定量研究过程中非常注重对某些自变量操控、及无关变量的控制。

而定性研究重视对主观意义的理解（如背后隐藏的原因），采用解释建构的方法，比如访谈法等。

平时工作中以“形成式可用性”测试为主，即便它稍微偏向于定性研究，但在允许的范围内，我个人还是尽可能地遵循着定量研究的方法去实施。这样整个测试过程的严谨性能得到保证，结论的客观程度相对更高（近几个世纪来，量化研究一直是科学研究的主要范式，也正是这个原因）。具体做法如下：

1.在任务的设置上：因为参与者可能存在差别较大的亚群体，不可能要求完成完全相同的任务。但必定会设置大部分基本的、都需要完成的公共任务，再针对不同亚群体设置少量的特殊任务。在后期统计分析的时候，基本的公共任务则可以进行数量化的统计，并横向比较。

2.在测试过程中：关注参与者完成任务时的相关行为，用数字来记录（以0、0.5、1分别表示失败、帮助/提示下成功、成功）。主试尽量少地言语及体态姿势的干扰，只在必要时进行适当地言语交流。

3.在报告呈现：对任务完成情况（效率、完成率）统计呈现，对不同任务的完成情况进行比较，对亚群体间的任务完成情况进行比较，对所有可用性问题按数量化指标进行排序等。或者比较迭代前后独特问题的频次是否减少，以及严重程度高的等级里面可用性问题数量的变化情况。

4.测试过后，我们通常还会收集用户自我报告式的数据，作为“感知可用性”的一个总体反映。

（1）推荐使用系统可用性量表（SUS），因为有研究表明SUS在少量样本时即可产生较为一致的评分结果。

（2）为减少用户在填写这些量表时的反应心向，不要求填写任何个人信息，且主试最好暂时回避。

（3）只统计分析所有参与者SUS量表总分的平均值，切勿再拆分比较亚群体之间的差异，因为即便信效度再高的量表，当样本量极小时都会变得很不靠谱！

七．问题优先级：单指标 VS 多指标

除了在可用性测试过程中，最终报告也必须体现出量化、客观地特点。例如，报告发现的可用性问题的列表，我也会以量化的方式排列出问题的优先级别。

这样做的好处在于：首先，发现的可用性问题肯定有一些比另一些更严重；其次，考虑到产品和设计人员的精力和资源总是有限的，必须帮助他们梳理出最亟需整改的问题。站在别人的角度考虑问题，这样他们才能更“友好地”接受我们的报告。

可用性问题列表的排序，涉及到采用单指标还是多指标、以及指标分为几级的问题。

先就量化的客观性而言，“出现频率”指标是最客观、最易量化的；而其它三个指标都需分析人员的主观判断。

就指标的代表意义而言，“严重程度”、“出现频率”与用户体验最相关，与用研人员的职责也最相关。另两个指标可能更多地是产品人员的职责。

就指标的价值而言，多个指标的综合显然比单一指标更有价值。

基于上述考虑，实际工作中我会选择“严重程度”和“出现频率”两个指标的综合，作为可用性问题的优先级指标。“严重程度”分为3级，而不是5级（分析人员主观判断时，3级指标的误差率要低于5级指标）；“出现频率”采用计算的具体数值，而非4级分类。这两个指标合并时，采用1：1的权重，具体公式为：

问题优先级=严重程度的级别+出现频率的具体值×3

八．报告呈现：优点 VS 问题 VS 建议

当产品设计人员辛辛苦苦做出的产品却被你报告上罗列的各种问题批评得一无是处时，即便理智上认可你的成果，情感上也很难接受。因此报告中列出哪怕一条最重要的优点，也会让产品设计人员感到欣慰、感受到你中立的态度，增加对报告的接纳程度。列出优点的另一个好处是，在测试中被参与者多次自发提及的优点确实带给用户某种惊喜；当你在报告中再次强调时，可以避免在后期迭代开发中丢失掉原本的优点。

问题的列举肯定是报告中非常重要的部分，但切勿罗列出清单就草草了事，因为：

1.某个（些）问题和另一个（些）问题是有关联的，但是报告中的问题列表部分却割裂了这些联系。

2.产品设计人员无法一直参与旁听/观察可用性测试的过程，导致对报告中文字描述的问题缺乏感性认识。

3.只提问题却不提供解决方案，就不是“建设性地提问”！

因此，我们需要在可用性测试报告的后半部分提出针对重要问题的解决方案。其目标并非是强迫产品设计人员一定要采纳我们提出方案，而是：（1）把一些相关问题联系起来看，（2）加深报告阅读者对于问题的感性认识和背后原因的理解，（3）使整个报告的思路更清晰、完整，（4）我们还可学到一些交互设计和产品的知识。