可用性测试的介绍？可用性测试脚本应包含哪些内容

可用性测试的介绍

可用性测试的概念是：让一群具有代表性的用户对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。该产品可能是一个网站，软件，或者其他任何产品，它可能尚未成型。测试可以是早期的纸上原型测试，也可以是后期成品的测试。在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.

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

可用性测试脚本应包含：

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

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

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

概述

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

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

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

可用性测试是一种操作性较强的迭代设计方法。关于迭代设计，还有一种说法叫“MVP“（Minimum Viable Product，最低可行产品），即快速推出产品，后续不断改进。
这能有效地降低产品研发周期，快速占领市场，快速获得客户反馈。
很多人对设计的误解，认为设计师都是些不食人间烟火，深夜案头苦思冥想闭门几个月最终憋出来一个惊世设计方案，而当灵感枯竭时则颓废懒散无所事事的人，
认为设计依赖于捉摸不定的灵感而无法进行项目时间管控。这种观点更多地认为设计就是临门一脚的结果。事实上，假如脱离了中场组织和调整，缺少了必要的控球倒脚，临门一脚往往无果而终。
设计更多是过程，沟通过程。可用性测试提供了这样一种简单直接的沟通方式。通过这种方式获得用户反馈，并以此为设计依据迅速调整产品功能乃至产品方向。
如能秉持这种设计即沟通的理念，自然不会将可用性测试仅仅看做是一种无奈之选。
小到一个图标的辨识，页面导航，功能使用，大到某项业务的办理，都可以拿来做可用性测试。
测试对象的选取也没有过多要求，任何不相关的同事，朋友，甚至路人都可以被请来参加你的可用性测试。除了专业度很高的比如业务处理等，一般性的操作对是否具有真正用户资质的要求并不高。
原因在于，可用性测试最大的作用是发现明显的可用性问题（不要怀疑设计师的水平，有太多设计失败案例是源于看起来简单愚蠢之极的错误），而这些问题多数跟专业无关，只跟常识有关。

具体操作也很简单，无需拘泥于测试地点，准备材料，等等，一张纸一枝笔足够矣。
这里操作关键的点在， 1. 场景代入，2. 观察和倾听。

场景代入是指让被试者知道大概的背景，比如这个软件功能是做什么的，谁会是使用者等，但不告诉具体如何操作（有点小白鼠的意思）。
观察，靠的不仅仅是眼睛，而是心。只有清楚自己要借助测试得到什么，才能不错过转瞬即逝的细节。这要求主试者本人对设计有较深的理解。
其他的工作则是为了确保可用性测试顺利进行。比如前期需要邀请，需要准备任务清单，提问清单，需要记录的设备工具，还有一点小意思。
但真正影响可用性测试质量的只取决于主试者自身的经验和水平。
链接：http://www.zhihu.com/question/20418124/answer/25583970
来源：知乎
-可用性测试