a/b测试
所谓 A/B 测试，简单来说，就是为同一个目标制定两个方案（比如两个页面），让一部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用情况，看哪个方案更符合设计目标。
一：基本概念网站设计中，我们经常会面临多个设计方案的选择，比如某个按钮是用红色还是用蓝色，是放左边还是放右边。传统的解决方法通常是集体讨论表决，或者由某位专家或领导来拍板。虽然传统解决办法多数情况下也是有效的，但A/B 测试（A/B Testing）可能是解决这类问题的一个更好的方法。
所谓 A/B 测试，简单来说，就是为同一个目标制定两个方案（比如两个页面），让一部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用情况，看哪个方案更符合设计目标。当然，在实际操作过程之中还有许多需要注意的细节。
A/B 测试最核心的思想，即：
多个方案并行测试；每个方案只有一个变量不同；以某种规则优胜劣汰。需要特别留意的是第 2 点，它暗示了 A/B 测试的应用范围，——必须是单变量。
另外，虽然 A/B 测试名字中只包含 A、B ，但并不是说它只能用于比较两个方案的好坏，事实上，你完全可以设计多个方案进行测试，比如ＡＢＣ测试，“A/B 测试”这个名字只是一个习惯的叫法。
回到网站设计，一般来说，每个设计方案应该大体上是相同的，只是某一个地方有所不同，比如某处排版、文案、图片、颜色等。然后对不同的用户展示不同的方案。
要注意，不同的用户在他的一次浏览过程中，看到的应该一直是同一个方案。比如他一开始看到的是 A 方案，则在此次会话中应该一直向他展示 A 方案，而不能一会儿让他看 A 方案，一会儿让他看 B 方案。
同时，还需要注意控制访问各个版本的人数，大多数情况下我们会希望将访问者平均分配到各个不同的版本上。要做到这些很简单，根据 cookie （比如 cookie 会话ID的最后一位数字）决定展示哪个版本就是一个不错的方法。
要实现 A/B 测试，我们需要做以下几个工作：
1、开发两个（或多个）不同的版本并部署；2、收集数据；3、分析数据，得出结果。
二：实践方法
从左到右，３条较粗的竖线代表了 A/B 测试中的３个关键角色：客户端（Client）、服务器（Server）、数据层（Data）。从上到下代表了３种访问形式：
无 A/B 测试的普通访问流程（Non AB test）基于后端分流的 A/B 测试访问流程（Back-end AB test）基于前端分流的 A/B 测试访问流程（Front-end AB test）。A/B 测试需要将多个不同的版本展现给不同的用户，即需要一个“分流”的环节。从上图中我们可以看到，分流可以在客户端做，也可以在服务器端做。
传统的 A/B 测试一般是在服务端分流的，即基于后端的 A/B 测试（Back-end AB test），当用户的请求到达服务器时，服务器根据一定的规则，给不同的用户返回不同的版本，同时记录数据的工作也在服务端完成。
基于后端的 A/B 测试技术实现上稍微简单一些，不过缺点是收集到的数据通常是比较宏观的PV（Page View）信息。虽然可以进行比较复杂的宏观行为分析，但要想知道用户在某个版本的页面上的具体行为往往就无能为力了。
基于前端的 A/B 测试则可以比较精确地记录下用户在页面上的每一个行为。它的特点是，利用前端 javaScript 方法，在客户端进行分流，同时，可以用 JavaScript 记录下用户的鼠标行为（甚至键盘行为，如果需要的话），直接发送到服务器记录。
下面，我将重点介绍一下我们在基于前端的 A/B 测试上的一些实践。
首先遇到的问题是如何分流的问题。对于大部分需求来说，我们希望各个版本的访问人数平均分配。可以根据某一个 Cookie ID 来划分用户，比如“123.180.140.*.1267882109577.3”，可以根据这个 Cookie ID 的最后一位（在本例中是“3”）来划分人群，比如单数的显示 A 版本，偶数的显示 B 版本。
正确展示对应的版本后，就要开始采集需要的数据了。当前版本有多少 PV （Page Views，访问量），如果需要记录这个数据的话，在正确版本加载完成之时就要发送一个打点信息。不过很多需求中，具体版本的 PV 的精确数值可能不是很重要，而且要收集这个信息需要多一次打点操作，所以一般情况下这个数据是可选的。
必须的数据是测试区域内用户的点击信息。当用户在测试区域点击了鼠标左键（无论这个点击是点击在链接、文字、图片还是空白处），我们就需要发送一条对应的打点信息到打点服务器。一般来说，这个打点信息至少需要包含以下数据：
当前 A/B 测试以及版本标识点击事件的位置点击时间戳（客户端时间）当前点中的URL（如果点在非超链接区域，此项为空）用户标识（比如 Cookie ID）用户浏览器信息三：应用例子用ＡＢ测试的核心思想分析下：
两个方案并行测试（符合）；每个方案只有一个变量不同（按钮的文案不同，符合）；以某种规则优胜劣汰（最终转化率的高低，符合）注意：有人认为按钮的点击率是最终的衡量指标，其实不是，有时候点击率提高了，但转化率反而会降低，所以这里最终转化率是衡量指标。
举个例子：你的按钮文案是“点击领一百元红包”，点击率自然会提高，但用户点击后发现并没有一百元，就走了，导致转化率下降。
言归正传，结果数据显示，A版本的转化率为5.8%，B版本的转化率为８.2%。在没做这个测试之前，你知道“加入学习”好还是“立即参加”好吗？
这几乎是一个完美的A/B测试案例：有明确的测试目标，清晰的衡量标准（订单转化率），以及完美的结果数字。
相关阅读
ab是一种用于测试Apache超文本传输协议（HTTP）服务器的工具。apache自带ab工具，可以测试apache、IIs、tomcat、nginx等服务器但是ab没
我曾经和来自不同开发机构的人探讨过关于他们如何管理软件开发，如何组织，他们遵循什么样的开发实践，以及什么样的开发实践真正有效。
siege是一款开源的压力测试工具，可以根据配置对一个WEB站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量
本篇文章作者分享了对有关内容及视觉可用性测试的几个问题的思考。前言最近项目中经常接触内容及视觉可用性测试，一开始有些懵圈，因
单元测试（Unit testing）是对最小的软件设计单元（模块或源程序单元）的验证工作。 在面向对象的设计（Object Oriented Design）里，最小单元