可用性测试
传统的可用性测试包括以下步骤：设置甄别条件，发布招募邮件，安排测试日程，撰写测试脚本，实施测试，综合研究中的发现，建议设计方案。大规模的可用性测试可能耗时数月，是对时间、金钱和精力的巨大投资。
可用性专家经常遭遇的挑战之一，就是通过量化的结果展示可用性测试的价值。要说服一个顾客投资数万美元在可用性测试上，总是需要一些实实在在的数字，明明白白地告诉他投资回报会有多少。客户可能会说，“是的，可用性测试会告诉我网站有多糟糕，用户有多么讨厌填网站上的表单。那又怎样？”从客户的角度，真正的问题在于：我怎么知道它能帮助我达到商业目标——增加销售、降低成本还是提高转化率？仅仅强调提高用户满意度是远远不够的。
一份来自Forrester的报告标题为“需要降低成本，提高网站体验”列出了几条很容易量化的指标，很可靠地展示了可用性测试的好处。这些指标包括客户关于产品和网站的电话咨询更少，以及复杂问题的咨询时长更短。我们可以把这些指标的变化与网站用户界面的改进联系起来。然而，还是有许多其他因素可能导致这些指标的变化——诸如更好的产品促销，更好的支持文档，更好的内部沟通，或者是销售量减少。作为可用性专家，我们需要一个清晰的方式展示我们从可用性测试中了解到的东西，我们推荐的改进是怎样实现的，以及由于这些变化而带来的改善。
根据可用性测试建议进行优化所遭遇的挑战
在理想情况下，在精心设计的可用性研究之后，将会进行重新设计，而且可用性专家所建议的设计变化将全部实现。然而，真实的情况下，要实现理想的情况面临好几种困难。
首先，可用性测试通常是在网站已经实现了全部功能，而且，从客户角度看，已经是相对“不错”的了。客户之所以想要投资于可用性测试，是想要对当前网站进行一些短平快的修修补补。然而，通常，可用性测试发现的问题解决起来既不轻松也不快捷，这就导致发现的可用性问题不了了之。
其次，根据时间和预算，可用性测试涉及用户的数量有多有少。通常，参加测试的用户量相对一个大的客户群来说，只占非常小的比例。因此，客户通常会质疑结果的精确性。“测试中确实是有一两个人说有这个问题。但如果其他没来参加的人并不这么看呢？”这样的想法通常会让客户不能完全充分地利用测试结果。
第三，可用性测试本身就是定性的。你可能会获得一个发现“用户在此网页会觉得迷惑，不知道如何继续。”这告诉你当前设计有问题，但要把用户的话解读过来并且提供设计建议，这可就因人而异了。不同的可用性专家，在确认一个可用性问题上可能意见一致，但至于此设计应如何优化，就见仁见智了。
A/B测试和它的困难
A/B测试让你可以对比同一网页的两种不同版本。通常可以控制一个页面的流量，部分流到版本A，部分流到版本B，所以不同的客户将与不同的页面版本交互。在A/B测试中，你能够收集到诸如转化率等相关的KPI（关键表现指标），让你能对比两个版本的结果。像Amazon和Google这种大公司青睐A/B测试的原因很简单：让数据说话。转化率不会骗人。是版本A还是版本B表现更好——数字一目了然。
然而，要通过A/B测试达到真正的好结果也需要面对很多不同的困难。首先，你需要对不同的页面开发不同的设计选择。布局会不一样吗？要不要换张图片？是否用不同的字体？虽然想法很多，但关于如何提出一个最优选择还真没有什么放之四海而皆准的真理。如果布局A用图片B表现更好，但布局B用图片A表现更好呢？在有足够流量的情况下，你可以进行多变量测试来看看哪些元素结合起来表现最好。不过，你可能会遇到真正的窘境，也就是你所测试的所有选择都一样好或一样糟。这可能是因为你所测试的这些选择都不能让你发现对网页设计效率最有影响的因素，所以就算进行了A/B测试，也还是找不到最优的解决方案。
其次，在开发不同页面版本时，可能会缺少用户输入，因此设计可能没有用户需求的基础。版本B通常是由对一个页面上的多个元素的重新组合而生成。没有坚实的用户输入，这样的策略也只能产生一般化的解决方案。你可能会重复你在另一个场合或情境下的成功经验之后却得到完全相反的结论，因为测试的是完全不同的用户群，有着不同的动机，以及不同的交互模式。
最后，A/B测试本质上是量化的，因此缺少定性的洞察。虽然A/B测试通常接触到大批用户，但它所能提供的也就是两个不同版本之间的KPI。你可能得到好的结果，但你不清楚原因为何，以及用户为什么喜欢这个版本胜过其他。
可用性测试与A/B测试结合使用
这些方法在测试网页所遇到的固有问题，让我们考虑两种方法结合使用。这是一个完美的解决方案，两种方法珠联璧合。根据项目的目标，你可以用两种不同的做法来结合这些测试方法。如果A/B测试为主，你可以在准备A/B测试之前先进行小规模的可用性研究，以便能为A/B测试提供更好的设计选择，有着坚实的用户输入为基础。如果以可用性测试为主，你可以对来自可用性测试发现的新设计做一个或多个A/B测试，轻而易举地证明可用性测试的优势所在。我们通过创造性地使用这两种方法，取得了成功。
如何使用
按下面这些步骤来实施两种方法：
1.实施可用性测试来收集用户输入及定性的反馈。如果A/B测试为主，可用性测试就不必太正式，并且主题非常集中，聚焦于带有最重要变化的网页。跟少数目标用户谈一下他们对这个页面的反馈，能为你实现最优的设计提供很大的启发。
2.仔细过一遍从可用性测试得来的发现，并提出优秀的设计选择。关键是要把可用性测试的来的发现放在优先级最高的地方，并且聚焦于一次只改一页或一个区域。基于可用性测试对一个特定页面的发现，可能有多种改法；不管怎样，你需要在团队内部甚至与团队外人员进行讨论以便达成一致。关键是一次只聚焦一个区域。在一个页面上一次改太多东西，会让人很难衡量结果。
3.一旦团队达成一致，你可以画草图、线框图甚至设计可选版本，并且把它们推向A/B测试。你可以用预先定义好的KPI来比较结果。
4.密切关注两个选择版本的KPI，并且比较结果。
结果
如果你是基于可用性测试来产生A/B测试的备选网页设计，那这种方式就比传统的A/B测试更容易识别出哪些元素能增加转化率——传统的A/B测试通常采取的是猜猜看的做法。而且，因为A/B测试能够带来迅速的反馈，你也可以随时通过检验来确认你的可用性测试所提供的价值。因此，两种方法结合使用之后，都能更加有效，比单独实施更有效率得多。
总结一下前三天翻译的这一篇Shanshan Ma文章。
可用性测试最大的缺点是缺乏说服力，而A/B测试则是测完以后不知重点。两者结合则可以综合发挥两者的优势。作者在这两点已经说清楚了。但这种实施也并未必那么完美。
第一个问题在于，元素的重新组合方式实在太多，恐怕A/B测试也很难满足需求。
第二个问题，A/B测试涉及重新开发，有多少企业愿意付出A/B测试的代价。
第三个问题，A/B测试必须辅以密切且准确的后台监控数据。在技术停滞不前的时候，研究再与时俱进也没有用。
不过这三方面貌似都是A/B测试的弱点，貌似可用性测试并无弱点。所以用A/B测试给可用性测试增加点说服力应该还是可以的。
本文编译自fries418，原文链接。
译文出处：Shanshan Ma，转载请注明出外链接。
相关阅读
ab是一种用于测试Apache超文本传输协议（HTTP）服务器的工具。apache自带ab工具，可以测试apache、IIs、tomcat、nginx等服务器但是ab没
我曾经和来自不同开发机构的人探讨过关于他们如何管理软件开发，如何组织，他们遵循什么样的开发实践，以及什么样的开发实践真正有效。
设计是感性和理性的混合体。但在UX设计领域，我们更多依靠的还是理性。本文从产品的完整用户流：注册产品 — 首次使用 — 持续使用，分
siege是一款开源的压力测试工具，可以根据配置对一个WEB站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量
本篇文章作者分享了对有关内容及视觉可用性测试的几个问题的思考。前言最近项目中经常接触内容及视觉可用性测试，一开始有些懵圈，因