web可用性测试梳理----纸上谈兵版。

如果一个网站或后台系统，交互层N多问题（共五层：战略层、功能层、结构层、框架层、交互层，由下到上。），推动这事儿最适合的方式就是拿出有理有据的可用性测试数据放在老大面前说：改改吧，别为难用户了。。。

突然想起在新浪时候老大的签名：no data no talk。

话说这部分经验不足，只做记录和梳理。

好了说正题，web可用性测试这里重点说两种：A/B测试和多变量测试。

A/B测试：就如它的字面意思，有两个人版本，它们只有一处不同以及一个衡量成功与否的测量值。为了知道哪个版本更好，拿这两个版本同时进行测试。把网站的流量随机分到两个版本上，用决定数值（如转化率，跳出率等）来判断最终效果，最后选择那个成功的版本应用到实际中。

我们测什么？

这个是由你的产品目标决定的。比如你的目标是增加注册的成功率，那么你就应该针对这方面进行测试，找出你怀疑的对象，注册表单内容过多？错误提示不够友好？注册按钮不够显眼？比如我们怀疑是注册按钮的颜色影响了注册数量，就可以设置两个版本A是现有设计，B是新版设计，按钮颜色改为性感大猩红色，进行A/B测试。

A/B测试要注意什么？

1、A/B测试一定要同时进行，流量平均分给两个版本。2、不要过早的下结论。有一个概念叫“基于统计的可信度”，它决定了统计结果是否重要，是否有价值。3、不要长期打扰用户，尤其是你测试的是网站的核心业务时，尽量用新用户开刀，这样是避免影响老用户的使用，还有就是避免老用户基于习惯对A/B测试的影响。4、别让个人观点影响测试结果。

5、多次进行A/B测试，事实上很多例子表明A/B测试第一次很可能以失败告终。测试结果无法三种：没有结果，消极的结果和积极的结果。多次测试时为了把积极的结果累积起来，对网站来说才是整体的提高。

这方面的经典案例比如：“You should follow me on Twitter here.”这句你应该在推特关注我相比“我在推特上”，带来了高达173%的关注量。再比如下载按钮上加上“免费”二次，下载量相比原来的“下载”也是有大幅提升。

多变量测试：在多变量测试中，就是在一个页面上找出多个可能影响测试目标的因素。这些因素被组合在一起，从而形成多个不同的测试版本。

比如：影响一个应用下载因素有标题、文字、图片。那么要对这部分进行多变量测试就需要假设有这些值：标题1、标题2；文字1、文字2；图片1、图片2。

三个变量，每个变量有两个版本，这样组合在一起就有八个版本的页面。接下来要做的和A/B测试一样，将流量平均导给这八个页面看效果就可以了。

多变量测试要注意什么？

1、不要测试过多区域，每多一个区域，组合就增加一倍。2、预览所有组合。以为有的组合会产生冲突，甚至逻辑不合理。比如标题写着：限时促销5元下载，结果下载按钮上两个大字“免费”。。。3、评估需要的浏览量。因为多变量测试会有大量的流量分流，如果你的网站日活一两百，还不够分流呢测毛线。

多变量测试的经典案例：YouTube在2009年进行了一次大规模的多变量测试，一共有1024个版本（好有意义的数字），巨大的浏览量为这次测试提供了保障。

至于测试工具，比如Google website Optimizer等等，等我研究下再说吧。现在了解的太少。

话说回来，可用性测试我认为比较擅长解决交互层的问题，至于底层的，比如功能层的问题（功能设计），结构层（交互逻辑设计）等，就需要PM靠自己的产品逻辑来修正了。

这两天分享的都比较“器”，希望有时间，尽快总结下“道”。

得尽快睡了，再不睡就饿了。。。就这样。