×

可用性测试

可用性测试的实用性?可用性测试脚本应包含哪些内容

admin admin 发表于2022-09-02 16:37:07 浏览88 评论0

抢沙发发表评论

本文目录

可用性测试的实用性


无论使用正式的或非正式的设备你都可以做可用性测试。使用任何类型的设备,你都可以采用各种正式或非正式的方法。 使用下述任何一种设置,你都可以进行有效的可用性测试:
* 两室或三室的固定实验室,配备视听设备
* 会议室,用户的家或工作室,配备便携式录音设备
* 会议室,用户的家或工作室,没有录音设备也可以用人眼观察和笔记来代替
* 当用户在不同地点可以远程控制
因此,即使你没有或没法找到一个固定的实验室,你也应该进行可用性测试。不要说,“因为我们没有一个可用性实验室,所以我们没法做可用性测试。 只要去做!在任何空间你都可以完成。 看情况。一个典型的测试需要8至16个人(每用户组)。如果每个用户将花费一小时,就意味着每个用户组的测试需要一到两个工作日。 当你的项目处在: * 纸上原型或早期开发阶段 * 计划通过几轮测试整个开发 * 有相当一致的用户群 如果只要人帮忙找出严重问题,你可能只需要4到6人。 * 如果您有不同的潜在用户群组(例如医生、病人、研究人员),你需要所有这些群体的用户代表。如果你对用户的电脑操作或网络经验有要求,还需要包括经验较少的和经验较多的用户。 * 如果你要对你的产品或系统进行正式的定量测试,你将需要更多的人以获得统计上有意义的结果。对于诊断型的可用性测试,6至8个用户通常是不足以揭露产品的大部分问题的。 * 如果在网站开发过程中你一直在做迭代(重复)的可用性测试,就会有许多用户参加其中一个或另一个版本的网站测试。因此,尽管每个可用性测试只有少于10名的测试参予者,但在网站推出前你可能需要15到30人参加测试。
做可用性测试需要多少费用? 成本要看网站的大小,你的测试量,预期的用户类型数目,以及你期望这个测试正规到什么程度。 如果你已经有一个标准的测试程序和可用的材料设备,可用性测试将进行地很快很便宜。如果你或你的用户招聘公司拥有一个用户数据库,用于招募的时间就可以大量节约,因此,花费会更少。 应该考虑这些因素:
* 计划所用的时间:确定测试的主要问题,需要测试的用户类型,招聘的用户的筛选问卷以及测试场景。
* 招聘的花费:公司人员的时间,给招聘公司(通常是一个很好的选择)的花费,可用性专家需要花时间熟悉网站及其制作团队,设计相应的测试场景,如果你需要录制测试过程,还需要花费实验室或便携式摄录设备的租金。
* 团队观察用户(进行测试)花费的时间
* 付给测试参与者的报酬或礼物
* 分析视听资料,查找存在的问题以及推荐解决办法所用的时间
* 和开发人员讨论变动和修改方案,撰写调查结果和建议报告所用的时间。
记住,预算分析要包含多个可用性测试。打造一个网站(或产品)的可用性是一个反复迭代的过程。你会发现,用在在开发过程中几个小测试的预算比起在项目末期只做一个大型测试要有价值的多。网站可用性测试是为了实现跨形式的视觉一致性,包括测试屏幕分辨率改变时的显示,边距和列布局,表单的颜色和大小,标签使用的字体,按钮的大小,所使用的热踺或快捷键,使用的动画/图形,按钮等控件的标签,同一字段的文本框的长度,日期和时间字段的格式。


可用性测试脚本应包含哪些内容


可用性测试脚本应包含:

(1)连接速度测试。用户连接到电子商务网的速度与上网方式有关,他们或许是电话拨号,或是宽带上网。

(2)负载测试。负载测试是在某一负载级别下,检测电子商务系统的实际性能。也就是能允许多少个用户同时在线!可以通过相应的软件在一台客户机上模拟多个用户来测试负载。

(3)压力测试。压力测试是测试系统的限制和故障恢复能力,也就是测试电子商务系统会不会崩溃。

概述

更改目标软件时,需要对测试过程进行局部的可控制的变更。这将使得测试过程和测试脚本对目标软件的变化有更大的应变能力。例如,假设软件的登录部分已经改变。在遍历该登录部分的所有测试用例中,只有关于登录的测试过程和测试脚本需要进行改变。-可用性测试

测试脚本是针对一个测试过程的。一个测试过程往往需要众多的数据来测试。通过自动录制得到的脚本,所有的输入数据都是常数,是固定的。


可用性测试的介绍


可用性测试的概念是:让一群具有代表性的用户对产品进行典型操作,同时观察员和开发人员在一旁观察,聆听,做记录。该产品可能是一个网站,软件,或者其他任何产品,它可能尚未成型。测试可以是早期的纸上原型测试,也可以是后期成品的测试。在IS0-9241-11中对于可用性做出了明确的解释:Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.-可用性测试


可用性测试的注意事项


你测试的是产品,而不是使用者
对一些用户而言, 测试有负面的涵义。我们要努力确保他们不认为测试是针对他们。我们要让他们明白,他们正在帮助我们测试原型或网站。事实上,我们可以不使用“测试”这个术语。相反,我们是邀请参加者为我们提供帮助, 勇于尝试原型 。 当用户难以完成任务时,我们应该改变网站,而不是改变用户。同时我们还应该思考该网站能在多大程度上符合那些典型用户的的目标,而不是关注用户在这个任务做的多好。
更多地依靠用户的表现,而不是他们的偏好
通过测试我们可以测量到用户的表现,以及他们的偏好。用户的表现包括是否成功完成,所用时间,产生的错误等等。偏好包括用户自我报告的满意度和舒适度 。 一些设计人员认为,如果他们的设计能迎合用户的喜好,用户在该网站上就会有良好的表现。但证据并不支持这一点。事实上,用户的表现以及他们对产品的偏好并非一一对应。一项研究发现,约有百分之七十的用户同意表现和喜好有联系。也就是说,他们在喜爱的网站上表现良好,在不喜欢的网站上表现欠佳。 然而,还有相对比较大比例的人( 30 % )认为 ,用户的表现以及他们对产品的偏好并非一一对应。他们在不喜爱的网站上可能表现良好,在喜欢的网站上也可能表现不佳。 关于人们为什么会对自己表现欠佳的网站给出较高的评价有多种解释。他们可能会把表现不佳归结到自己,而不是网站。或者说,他们可能担心给一个较低的评价会伤害网站设计者,也就是我们的感情。或者说,他们可能并没有完成任务,却自认为成功完成了,他们并没有意识到问题所在。基于所有这些理由,我们建议你:更多地依靠用户的表现,而不是他们的偏好。
把你掌握的测试结果应用起来
可用性测试不仅仅是用于核对项目进度的一个里程碑,你要知道,当最后一个参与者完成任务的时候,可用性测试还没有结束。整个团队必须仔细研究结果,设定优先次序,基于结果对或者网站原型进行修改。
基于用户体验,找出问题的最佳解决方法
制造任何产品,包括大部分网站和软件,需要考虑许多不同的用户的工作方式、体验、问题以及需要。大多数项目,包括设计或修改网站,都要处理时间、预算和资源等方面的限制。平衡各个方面对大部分项目来说都是一个重大的挑战。 在你权衡利弊时,最好优先开发那些能使最多用户完成任务的网站或软件。有研究表明,产品推出后,用于支持失败客户的花费远远高于开发时对产品修正所付出的花费。 你需要认真考虑假定用户、使用场景以及可用性测试的结果,试图找出针对不同客户需求的理想解决方法。找不到最好的解决方法,用户就不能够顺畅地完成任务。有证据表明,即使用户延长使用时间在一个不太完美的产品界面完成任务,也远不及在一个更好的产品界面带来的成功感。-可用性测试


软件测试中什么是可用性测试


可用性测试的概念是:让一群具有代表性的用户对产品进行典型操作,同时观察员和开发人员在一旁观察,聆听,做记录。
可用性有五个指标,分别是易学性、易记性、容错性、交互效率和用户满意度。
可用性测试适于解决的问题:
 1) 确定测试产品的可用性水平
 2) 与预期目标、与竞争对手、与老版设计相比的可用性水平
 3) 比较不同方案,确定哪个方案更加可行
 4) 现测试产品的可用性问题
-可用性测试

网站的可用性测试 主要包括哪些方面


转载,非原创网站的测试包括:
一:性能测试
(1)连接速度测试。用户连接到电子商务网的速度与上网方式有关,他们或许是电话拨号,或是宽带上网!
(2)负载测试。负载测试是在某一负载级别下,检测电子商务系统的实际性能。
也就是能允许多少个用户同时在线!可以通过相应的软件在一台客户机上模拟多个用户来测试负载。
(3)压力测试。压力测试是测试系统的限制和故障恢复能力,也就是测试电子商务系统会不会崩溃!
二:安全性测试
它需要对电子商务的客户服务器应用程序、数据、服务器、网络、防火墙等进行测试!用相对应的软件进行测试!
{上面的测试是针对电子商务的,在电子商务书上找到的,那个测试一般普通的网站就是二方面。
1.基本测试
包括色彩的搭配,连接的正确性,导航的方便和正确,CSS应用的统一性
2.技术测试
网站的安全性(服务器安全,脚本安全),可能有的漏洞测试,攻击性测试,错误性测试。 }
网站的评估主要对以下方面:网站界面,产品展示,在线支付,在线客服,线下产品配送。更重要的是目标消费者可以很方便快捷的找到该网站,从而进行电子商务活动.让客户找到该电子商务网站。是否网站有一个搜索引擎!或是把自己的网站添加到一些大的分类目录上。再就是让目标客户记得你网站的名字(最终效果--品牌效果)并直接进去!个好的电子商务网站是看它是否经过搜索引擎优化了.
-可用性测试

可用性测试的测试的方法


所谓可用性评估,即是对软件“可用性”进行评估,检验其是否达到可用性标准。目前的可用性评估方法超过20种,按照参与可用性评估的人员划分,可以分为专家评估和用户评估;按照评估所处于的软件开发阶段,可以将可用性评估划分为形成性评估和总结性评估。形成性评估是指在软件开发或改进过程中,请用户对产品或原型进行测试,通过测试后收集的数据来改进产品或设计直至达到所要求的可用性目标。形成性评估的目标是发现尽可能多的可用性问题,通过修复可用性问题实现软件可用性的提高,总结性评估的目的是横向评估多个版本或者多个产品,输出评估数据进行对比。网站可用性测试包含的步骤有:定义明确的目标和目的,安装测试环境,选择合适的受众,进行测试和报告结果。-可用性测试


选择可用性测试的测试参与者时,应采用什么标准


从传统上讲,可用性测试的参与者是以人口统计学(demographic)标准来进行细分的。
在进行可用性测试的时候,为了保证测试的有效性,必须考虑诸多因素。主要的因素有:如何选择测试参与者需要多少参与者,研究比较多组数据还是单组数据,是否需要调整测试任务顺序。其中,如何选择测试参与者是保证测试有效性的首要条件。
在做可用性测试的时候,经常会有这一类的思考:如何保证被测人员的代表性,在实际操作中,一般我们会从下面4方面来做,
首先,我们会找那些使用过被测试产品的参与者。举例来说,我们需要测试魔兽金币购买流程,我们第一个筛选条件是要求有过魔兽金币购买经历。出于补充或者对比的需要,我们也会选择一些潜在的用户,如没有交易过,但是使用过相关产品,像魔兽资深玩家的参与者来参与测试。
-可用性测试

可用性测试常用的记录方式


不论是做哪个平台的可用性测试,比如PC端、移动端或者是WEB端的可用性测试,最最重要的就是要先理清楚一些基本问题。基本问题就是最经典的5W问题:
·为什么要进行这个测试(why)?测试可以验证一些设计中的疑惑,或者找出现有的界面、流程设计上的问题,具体问题要具体分析。
·什么时候在哪里做测试(when?where?)?时间一般是需要和测试者协调的;地点一般选择在安静的会议室即可,如果公司有专门的实验室那就最好不过了。
·谁要作为测试者(who)?这里可以在招募测试者会详细讨论,不过测试者一般是跟我们的persona接近的人,或者换个说法,测试者一般是我们的目标用户。
·我们要测试什么(what)?测试一些功能点,测试界面设计,测试流程设计,测试设计中有争议、有疑问的地方。
当然这些问题其实都不太难,但是这些都是至关重要的问题。如果没有经过这个步骤的思考,整个可用性测试做下来就会像无头苍蝇,没有一个总的指导。
3.测试前期准备
在想清楚以上的问题之后,需要为可用性测试做一些准备工作。主要工作有:①招募测试者; ②撰写测试脚本; ③制作测试原型。
这三个过程不分先后,条件允许的情况下(人力物力充足时)也可以同时进行。
3.1招募测试者
招募测试者算是可用性测试最重要的一个环节之一的,测试者是否合适直接关系到测试结果的好坏,测试结果直接关系到能否发现产品现有的问题。所以招募测试者是重中之重。理想的测试者是我们的目标用户,所以可用性测试要努力寻找到目标用户作为测试人员。寻找的途径如下:
a)最简便的,假如同事(非同部门)或者好友也是目标用户,可以选用同事或者好友作为测试人员。
b)其次,大型公司都会有自己的用户资料库,可以从这个库里面寻找到测试人员。
c)又或者说,委托第三方机构帮忙寻找测试人员也是允许的,不过效果可能不如自己寻找的。
d)当然,现在的应用一般都会有自己的微博、微信、官网或者论坛,这些是非常好的寻找测试者的渠道。我们可以推送招募测试者的公告,让用户填写一份调查之后,我们再筛选得到我们想要的测死者。公告中要注明奖励,一般为小礼品的奖励,保证对测试者有一定的吸引力,同时又不至于让他们会为了这个礼物对个人信息造假。其次,对于测试者,我们需要进行一个筛选【3】。首先需要用户填写必要的个人信息:比如姓名、电话(邮箱)、空闲时间;然后根据调查选择其他一些个人信息:性别、年龄、职业之后,最后留几道问卷题目进行筛选。
筛选的维度主要有:
·平台。如果测试的产品与平台有关,比如是Android或者iOS,需要在这里进行一个筛选。
·对产品的熟悉程度。比如我们想找一些初级用户和一些高级用户,可以选用“使用时间”这一项来衡量用户对产品的熟悉程度。
3.2撰写测试脚本
测试脚本的好坏直接关系到结果的好坏。在撰写测试脚本之前,我们需要先确定一些结果分析的维度。一般的维度有:a)任务完成度b)致命错误c)非致命错误d)完成任务的时间e)主观情绪f)偏好和建议。对于这些维度的解释具看第文章的最后一部分“测试结果统计分析”。
由于分析的维度会关系到脚本的问题,所以在确定分析维度之后,我们可以对功能点进行任务分析。把所有需要测试的功能点列出来,对每个功能点进行任务设计。对于任务而言,用户最主观的感受就是两个:界面和流程。所以测试脚本又可以从这两个维度去细分。
需要注意的是,可用性测试中,问只是其中的一部分,观察是另外一个重要的内容,所以测试脚本不仅仅要有问的问题,还有需要撰写工作人员观察的注意点。同时可以在撰写完测试脚本的同时,把总结大纲也写出来,方便后期总结的时候统一结果展示。
特别的,在设计的时候有疑惑的点,或者有争议的点,在可用性测试也可以得到较好的验证。
写完测试脚本之后,可以和利益相关者(项目经理、产品经理、开发等)讨论一下,请他们校验一下测试脚本。
-可用性测试

如何进行可用性测试和用户研究


可用性测试是一种操作性较强的迭代设计方法。关于迭代设计,还有一种说法叫“MVP“(Minimum Viable Product,最低可行产品),即快速推出产品,后续不断改进。
这能有效地降低产品研发周期,快速占领市场,快速获得客户反馈。
很多人对设计的误解,认为设计师都是些不食人间烟火,深夜案头苦思冥想闭门几个月最终憋出来一个惊世设计方案,而当灵感枯竭时则颓废懒散无所事事的人,
认为设计依赖于捉摸不定的灵感而无法进行项目时间管控。这种观点更多地认为设计就是临门一脚的结果。事实上,假如脱离了中场组织和调整,缺少了必要的控球倒脚,临门一脚往往无果而终。
设计更多是过程,沟通过程。可用性测试提供了这样一种简单直接的沟通方式。通过这种方式获得用户反馈,并以此为设计依据迅速调整产品功能乃至产品方向。
如能秉持这种设计即沟通的理念,自然不会将可用性测试仅仅看做是一种无奈之选。
小到一个图标的辨识,页面导航,功能使用,大到某项业务的办理,都可以拿来做可用性测试。
测试对象的选取也没有过多要求,任何不相关的同事,朋友,甚至路人都可以被请来参加你的可用性测试。除了专业度很高的比如业务处理等,一般性的操作对是否具有真正用户资质的要求并不高。
原因在于,可用性测试最大的作用是发现明显的可用性问题(不要怀疑设计师的水平,有太多设计失败案例是源于看起来简单愚蠢之极的错误),而这些问题多数跟专业无关,只跟常识有关。
具体操作也很简单,无需拘泥于测试地点,准备材料,等等,一张纸一枝笔足够矣。
这里操作关键的点在, 1. 场景代入,2. 观察和倾听。
场景代入是指让被试者知道大概的背景,比如这个软件功能是做什么的,谁会是使用者等,但不告诉具体如何操作(有点小白鼠的意思)。
观察,靠的不仅仅是眼睛,而是心。只有清楚自己要借助测试得到什么,才能不错过转瞬即逝的细节。这要求主试者本人对设计有较深的理解。
其他的工作则是为了确保可用性测试顺利进行。比如前期需要邀请,需要准备任务清单,提问清单,需要记录的设备工具,还有一点小意思。
但真正影响可用性测试质量的只取决于主试者自身的经验和水平。
链接:http://www.zhihu.com/question/20418124/answer/25583970
来源:知乎
-可用性测试