流量较低网站该如何进行AB测试
AB测试是一种能有效优化网站用户体验，提高转化率的好方法，但这种方法仍然存在一些缺陷。往往在我们进行AB测试的时候，都需要较多的用户数量来支撑，所以也让很多朋友形成了一种错误的想法：流量低的网站是没法进行AB测试的。
诚然，网站的流量会对AB测试的效率造成较大的影响，但事实上网站流量较低的时候也有办法做出具有统计意义的AB测试。
以下大家介绍几张比较常见的优化方法：
1.把实验版本和控制版本的差异扩大
在我们进行实验设计的地方，我们可以把实验版本和控制版本的差异扩大，尽量让我们的用户能留意到这些地方。同时版本间差异的扩大也有助于扩大转化率之间的差异。根据统计学的样本公式计算，在同样的统计效力和显著性条件下，当转化率的差异越大，所需要的样本量就越少。
举个实际例子：
假设现在有这样一个实验：原本转化率为10%，测试版本转化率差异为10%（既测试版本转化率为9%或11%），要求实验具有80%的统计效力以及95%的显著性，在这样的条件下，需要28626名用户才能让这个实验达到统计学上的显著。但当测试版本转化率差异为30%（既实验版本转化率为7%或13%）的时候，仅需3258名用户就能让实验达到统计学上的显著。
2降低统计效力和显著性的标准
从统计学上说，降低统计效力和显著性的标准都可以有效减少实验所需要的样本量。可能有很多朋友会担心这样出来的结果是否准确。事实上，严格的统计标准往往是针对学术研究而言的，对于大多数商业性的研究，适当的把标准放松是正常的。我们建议可以把显著性标准设置为80%，统计效力设置70%。
举个实际例子：
假设在实验当中，原版本转化率为10%，控制版本转化差异为20%（既转化率8或12%），在95%显著性，80%统计效力的要求下需要7246名用户，而在80%显著性，70%统计效力的要求下，仅需4322名用户即可。
3.避免同时测试多个版本和元素
在我们测试的时候，我们往往希望能测试更多的版本（更多的版本意味着越可能找到更优的版本），也喜欢在一个页面当中同时修改很多的元素。但随着版本的增加，实验所需的样本量同样会增加，因为在一定统计条件下，就单个版本而言，所需要的样本是恒定的。实验的版本应该根据网站的流量调整。同时在一个页面中修改多个元素，也会削弱统计解释的说服力。
4.测试多个页面中的共同元素
在进行实验设计的时候，我们可以针对那些同时存在于多个页面的元素进行测试，比较常见的例如导航栏，购物车按钮，登录按钮，注册按钮。然后我们通过对实验进行URL匹配，把所有拥有这些元素的相关页面都加入实验。但在采用这种方法的时候应该注意：加入实验的页面间需有较强的一致性，例如A商品的详情页和B商品的详情页等，而不能把商品详情页页面和首页放在一起。
最好我们建议大家，除非网站的流量非常高，否则的话AB测试最好能持续2周左右的时间，这样才能平衡时间因素所带来的变异。同时这段时间也能让较低流量的网站积累到足够的用户数参与到实验当中。
Posted in:AB测试可以广泛的运用到网络推广当中
稿源：aidai.com
在做网络推广的时候，我们可能会同时想到很多种不同的方案，如果你想要知道哪一种方式是最有效果的，AB测试就是最好的方法。
所谓的AB测试，就是用不同的方法布置某一工作，然后通过效果的对比分析，找到最高效的方法。这样的对比分析是可以广泛的运用到网络推广的多个领域的。现在电商业界都把转化率看成是重之之重，而通过AB测试的方法，经过不断的调整，可以大幅提升网站的转化率。这段时间，笔者接手了一个网站，也是将AB测试很好的运用了一番，在下面这么一些方面我是有用到AB测试的。
1、sem的广告词的选取
无论是做什么搜索引擎的cpc推广，广告词都是最重要的。一个好的广告词，更加能够吸引用户的注意，得到更多的点击，甚至你可以花更少的点击单价，得到更高的流量。而在选取广告词的时候，我就用了AB测试的方法，因为我并不能够完全的理解用户喜欢看的广告语是怎么样的，通过AB的测试，我才能够直观的看出，用户到底对什么样的广告词较为感冒。
而且在这点上面做AB测试是非常简单的，现在所有的搜索引擎付费推广的后台里面，都支持多个广告创意，这个功能实际上就是让我们做AB测试用的。我们只需要将自己想要做对比测试的广告创意添加到其中，然后查看各自的点击情况即可。
上图是百度付费推广后台的创意添加示例。
2、edm营销的主题和内容的策划
edm也就是邮件营销，是现在最常用的一种营销推广手段，而一份成功的邮件发出去，是需要在策划上面下很的功夫的，主题的选取，内容的策划都非常的重要。这个时候当然就需要进行AB对比测试了。
首先是主题的选取。主题非常重要，一个好的主题，是edm营销的第一步，如果你的主题无法引起用户的注意力，那么你这份邮件就等同垃圾邮件了。做主题测试的时候，我们可以分别针对同等数量的邮箱，发送不同主题的邮件，然后看这2次邮件发送出去的打开率和点击率怎么样。这样来找出这些邮箱用户的品味和习性，进而优化edm的主题，增加每次edm发送带来的转化率。（下图是2个不同主题邮件的打开和点击对比图）
其次是内容的策划。做内容策划的AB测试，主要是看2次邮件发送出去之后，分别带来的转化情况，同时也要看改邮件的页面点击情况，这样你就可以知道，这些用户他们喜欢什么样的内容，喜欢什么样的排版方式。
从主题到内容都进行优化，这样的edm发出去一定会是带来高转化的。
3、短信营销的内容规划
短信是除了edm外，又一个非常有效的营销手段。相比edm，短信要来的更简单，不需要做太多的准备工作，唯一要做的就是规划好短信的内容，然后吸引用户登录网站购买商品。
虽然短信要准备的工作不多，但是短信的内容规划是最难的，因为你的内容一定要有一定的推动力，要让用户产生一种要登录你的网站的冲动才行。AB测试在这里也能起到很好的作用。
上面说的这3个营销推广渠道只是笔者现在有在做AB测试的地方，当然在网络推广的过程中还有很多地方都可以通过这个手段进行对比分析。通过AB测试，可以更快，更有效的找到那些更好的推广方式。
AB测试，在做网络推广的时候，可以广泛的使用。（文章由http://www.aidai.com/原创投稿。）
有好的文章希望站长之家帮助分享推广，猛戳这里
本网页浏览已超过3分钟，点击关闭或灰色背景，即可回到网页AB测试初学者的四个技巧_深圳软件测试培训
AB测试初学者的四个技巧
发布：深圳软件测试培训班
来源：深圳软件测试培训机构
这篇关于自动化测试的文章，可能和你看到的大多数自动化的文章有所不同。我不是一位专职的自动化测试工程师，没有开发过自动化的工具或者框架，用的自动化的工具也不多，也没有做过开发，所以我讲不出那些现在很多人很看重的“很深”的东西。我也不想去讲某个流行的自动化的工具要怎么使用什么的，我觉得这些东西并不是我的，而且也是可以很容易获取的。
那么在自动化这个很大的领域来说，我是什么呢？ 我是自动化技术的使用者，要在团队中做自动化，还是脚本的编写者、管理者和运行者。 我想大多数测试朋友和我做的事情是一样的把。我想在这篇文章中，给大家分享一下我这些年实践自动化的经历很有意思的一篇文章。想一想你最喜欢吃的饭菜，如果接下来一年你每天都这么吃，然后每天也都喝同样的酒精饮料呢？日复一日，会有什么感觉？但你对潜在客户和订阅者日常使用的邮件和落地页元素都是这样呀。
如果你的业务的启动和点击率停滞了，这就是你应该对邮件和落地页进行更改的时候。即使是那些已经改进的，依然会有优化空间。A/B测试是优化营销邮件和落地页效果的答案。
没有改变的心态是很可怕的一件事。你能为邮件和落地页添加多种多样的功能，而不必担心会对你的品牌效果产生负面影响，方法是用A/B测试来进行安全的增量更改，以确保客户参与进来并进一步缩短购买周期。
这篇文章将向你介绍应该测试的不同邮件和落地页元素，A/B测试的一些最佳实践以及测试发现对于指导行动的重要性。你会看到为什么采用正确的测试策略能让转化率提高300%。
不熟悉A/B测试也没关系，因为它的工作原理就像它看起来这样A/B。你应该为需要测试的元素创建A、B两个版本（比如红色按钮对比蓝色按钮），然后用指标衡量每个变量是否成功。
1）常见测试元素
这通常是要测试的邮件副本中最重要的元素。无论内容质量如何，主题行都会决定电子邮件是否被打开。测试不同类型的主题，来确定那个点击率最高。比如优惠对比双关或歧义，搞笑的主题对比有紧迫感的主题。
标题是另一个需要不断测试的重要元素。跟主题类似，标题会成为决定落地页成败的决定性因素。假设主题很好，能让订阅者打开邮件，那么标题对于提高点击率来说至关重要。
号召性用语（CTA）
你的业务应该尝试以不同的方式呈现号召性用语，这意味着可能要更改使用的词语，调整大小和颜色，并测试将CTA按钮放在邮件或目标网页的不同地方。
不管你信不信，只提供折扣或促销已经不足以吸引他们的注意力，因为随着互联网的发展，越来越多的人意识到免费或折扣的东西肯定不够好。
你应该在营销中测试不同的措辞，以了解哪些优惠对订阅者最有吸引力。比如，你可以测试某个百分比的优惠跟特定美元的优惠那个点击率更高。
你的业务应该测试不同的邮件模板，以了解那个触发器的效果最高。可以测试订阅者喜欢单列还是双列主题，或者一个颜色模板跟另一个颜色模板等。
在哪里放置图片，用什么图片，以及图片能在邮件营销中发挥多大作用。运行不同的测试，来找到那个能触发最佳性能指标。一张图片里有人物形象，另一张图片里只有产品可能是你需要测试的一个例子。
你应该已经看到A/B测试能提供其他营销研究方法不能带来的好处，这种定量方法可以衡量访客的行为模式，并提供必要见解，以提出可复制的实施更有效的邮件和落地页解决方案。
2）增量变化
事实上，大多数网页没有流量问题，但有转化问题，一般来说，转化率在1-3%。那么你到底做了哪些努力才能让97%的访客对你提供的努力不感兴趣？
增量变化可能是你了解潜在客户以及最佳交互方式究竟是什么的第一步。
运行A/B测试时，确保你的业务正在进行渐进式更改。换句话说，一次只测试一个元素的一个变化。比如，如果你想查看你的CTA按钮颜色如何影响点击率，那么你的版本A应该保持不变，版本B跟A的唯一区别应该只是颜色不同。
这里不存在一石二鸟。尝试同时测试多个不同元素的影响会让你确定那个元素触发更改的能力变复杂。
如果你尝试同时测量CTA，标题和版式的影响，并发现点击率有所提高，你会不清楚究竟是那些元素带来了提升。
如果你不知道元素改变对邮件产生的影响，那么这些元素更改未来可能会导致意外减少的时候又该怎么应对呢？
3）时间价值
你的公司应该使用A/B测试来确定发送电子邮件的最佳时间。GetResponse发现26.63%电子邮件的打开都发生在邮件发送后的一小时内。因而，在正确的时间发送电子邮件无比重要。
要根据你的业务和订阅者确定发送最佳时间，而不是其他公司的最佳实践，因为用户参与的最佳时间跟行业和目标市场有关。
幸运的是，营销自动化软件通常会根据你之前发送的邮件的打开和点击活动对发送邮件的最佳时间提出建议。
很多企业害怕A/B测试，因为他们认为在测试不同元素的过程中，可能会失去前景。实际上，使用A/B测试能在不伤害当前点击率和打开率的情况下确定到达订阅者的最佳时间。
你可以对一小部分订阅者使用A/B测试，并用你的样本调查结果预测这些结果将如何影响整个订阅列表的转化。例如，你可以在安排好的时间向10%的订阅者发送版本A，然后在另一时间段向另外的10%发送版本B的营销邮件。
一旦确定了那个时间能触发更好的效果，你就可以用获胜版本的发送时间把邮件发给其余的80%订阅者。
4）实施解决方案
只有22％的企业对其目前的转换率感到满意。这可能是由于企业没有运行A/B测试，企业没有运行足够的A/B测试，或企业没有正确地对他们通过测试获得的发现采取行动。
不要削减A/B测试时间。确保它们运行足够长的时间，通常可以通过足够大以具有统计意义的样本来计算（大多数测试工具可以报告这一点）。
一旦对A/B测试获得的结果充满信心，就应该对发现采取行动。为了避免将来再次测试相同内容，你需要把结果整理到资料夹或电子表格里。此外，对调查结果的梳理能让你以后更容易利用其中的个别解决方案。
假设你发现落地页上的人物图片比产品图片更能提高点击率，除了保证继续使用人物图片，这个发现还可以用到营销内容的其他元素里，比如广告或网站首页，找出这是否依然有效的唯一方法是再次测试。
你将开始看到不同元素模式将如何影响营销邮件表现，然后可以用这些模式更好的了解订阅者，并在将来继续提供令人信服的营销邮件。
希望以上内容对你有所帮助！达内教育12大高端课程，囊括行业最热门技术，跟新速度快，更贴近企业需求。全国首家先就业后付款培训机构，工作后再分期支付学费。还等啥子呦？达内助你登上人生的转折点，一次改变命运的机会！（更多内容请点击：深圳软件测试培训），特别是那些不是那么成功的经历，希望能够给你带来一些思考和共鸣。
我的自动化历程
初次接触自动化测试
初次接触自动化测试：我发现光靠工具和热情是做不好自动化测试的。
我是自动化测试的簇拥者。记得刚做测试那会，一听到“自动化测试”这个概念，就觉得好神奇，当时就把“手头的工作都自动化了”。我能把这些内容都自动化，不是我厉害，而是新员工手里的工作不多，又很简单，而且当时公司已经研发了一些自动化平台，我的这些自动化测试的原理就是捕捉到一个windows的窗口然后往里面发送字符串，连测试结果都还不能做到自动检查，还要自己去看日志或者截屏。尽管做得非常粗糙，这也极大的鼓励了我，我每天跑着这样的脚本乐此不疲，想象着下一步这些脚本会变得很智能。
接下来我就开始向公司的自动化测试前辈（本部门、外部门）学习，自己开始搞自动化。这时我又换了个产品，新的leader当时并不赞同做自动化（现在非常能够理解他当时为什么不赞成做自动化），我很沮丧，但我想公司已经有了现成的自动化测试的平台和工具了，我只要学会了用这个工具，自己就可以写脚本了，自动化测试不就做起来了嘛，不就是个工具吗，能有多难呢。于是我决定加班来学习脚本语言和学习使用工具。我的进展不错，但很快我就开始感到，自动化测试并不像我想象的那么美：
· 一个非常简单的功能，写好再调通，花费的时间并不少。别人5分钟就能做好的事情，我要花1个小时。
· 脚本执行时一旦发现问题，排查起来花费的时间也不少。一般来说跑出问题了，我会再反复跑几次，先确认是不是真的有问题，再加各种打印或者等待来运行脚本定位问题（别笑，当时真的是这样的）。 我还记得当时我对这个问题，是这样安慰自己的，没事，自动化的优势是体现在反复执行上的。但是很快我就发现：
· 界面、环境稍微有点变化，脚本就不能用了。这点让我感到反复执行好像也不是那么好使，有点崩溃。
· 由于我们的产品经常会定制，版本的分支也很多，我发现如何把这些脚本管理起来，便于在不同的测试场景下测试也是个问题。
这两个问题让我有些崩溃，大家都说的自动化测试反复执行是强项，为什么到我这里就不灵了呢。
我开始意识到， 自动化测试不是靠一个工具，然后靠一腔热情加个班就可以完成的事情。 除了工具，如何设计函数，如何检查脚本的运行结果，如何做版本管理等等每一件事情的工作量都不小，需要有策略有规划，一步步的来完成。当然，如果你只是想写几个脚本玩玩除外。
第二次进行自动化测试
第二次进行自动化测试：没有做好自动化的准备，盲目追求自动化率。
第一次的自动化测试就这样以失败告终了。但我也成长为了一名测试基层小leader，有了些可以“做主”的小权利。我认真总结了上次的经验，显然问题主要出在没有规划和设计自动化上，我想只要我做好了规划，加强设计，再做一次自动化一定行，于是我决定和我的小伙伴一起，再来做一次自动化。
当时我所在的公司的做事方式是做事情必须要有个目标，要写个承诺，年底还会拿这个承诺来考核你。所以我开始思考自动化测试的目标。我发现无论是公司内部还是公司外部，只要说到自动化，都是说定位于回归测试，好吧，既然大家都这样说，那一定有大家的道理，那我的自动化目标也是定位在回归测试自动化好了。另外既然是一个团队都来做自动化，肯定要从简单的地方开始入手，这样我们的自动化的目标就变成了从简单的回归测试开始自动化，完成100%的回归测试。
这个目标看起来似乎没有任何毛病，但具体执行起来的时候，在“简单的内容先自动化”的思想的指导下，我们做了很多测试边界的脚本。（什么叫测试边界值的脚本呢。比如一个接口的配置是允许输入（1，5），边界值就是0，1，5，6，边界值的脚本就是测试数据为0、1、5、6的脚本）。
由于我们的目标是要100%的回归测试，但我们当时并没有一个标准的回归测试用例集。那些简单的边界值脚本就自然而然的都成为了回归测试用例集。后来项目压力压下来，做自动化的时间变少了，为了达到自动化率的目标，我们甚至发展到把一个测试边界的脚本，拆成多个脚本（比如上面那个例子，测试数据为0、1、5、6，本来一个脚本就可以测试完，我们却偏要写4个脚本），这样，我们“很聪明”的达到了自动化测试的目标。
但这样的自动化，我们自己都不不太想去运行，因为我们自己心里清楚，这样的脚本，运行不运行又有多大的意义呢。
这次经历让我对自动化测试有了新的思考：
· 自动化的脚本要开发哪些内容，不应该在自动化开发的时候才来决定，而应该是事先就确定好了的。换句话说，测试用例是自动化的基础， 有明确的测试用例才能保证自动化测试的内容符合预期目标。
· 没有考虑项目进度会影响到自动化测试这个风险，也没有考虑自动化实现时会不会有什么问题或困难，就轻易承诺100%的自动化率， 盲目追求自动化率，使得最后大家花精力开发出来的自动化脚本没有太大的作用。
归根到底，还是没有做好自动化的准备。
我们在做自动化测试的时候，很容易只是盯着自动化，仅从自动化这个方面去思考，把自动化当成了一种很高级的测试，去设计自动化的框架，组织等，却忽 视了自动化测试的本质——自动化测试就是一种测试执行的方式。我们在手工测试时要如何准备测试执行，自动化测试的时候也需要考虑 。
第三次自动化测试
第三次自动化测试：自动化脚本的误判。
第二次测试就这样也算是失败了（反正脚本几乎是都废了）。有了这两次的失败经验，俗话说事不过三，所以我准备再来一场。
这时团队的测试能力已经有了长足的提升，我们已经有了一些测试用例，为了做好自动化测试，我专门组织大家把需要自动化测试的用例筛选出来了。既然目标是回归测试，用例的筛选标准也很明确，就是那些基础的，需要手工反复执行的用例。
然后我又对这些用例逐个进行了分析，把当前的自动化测试技术暂时不能支持的用例也标记出来了，告诉大家不用担心，这些用例可以下一次再执行，我们就算是要追求100%的回归测试率，也是我们真正应该执行的，并且现在可以自动化测试的那些用例。
我还记得当时我们的自动化测试平台也升了次级了，平台也更稳定了，提供的功能也更多了，大家的干劲也很足，所谓天时地利人和，我对这次的自动化测试实践充满信心。
很快，脚本被一批批的开发出来了，之前不能自动化的测试的用例也随着自动化测试技术的突破而变得可以自动化了，一切都在向着好的方向发展。但很快我们就发现新的问题出现了，自动化脚本结果出现了误判！
什么叫自动化脚本的误判呢，就是自动化脚本在自动化平台上显示的结果和真实的结果不一致。比如脚本A在自动测试报告中显示的结果为PASS，但实际的功能却有可能有问题。在自动化测试报告中显示的结果为失败，但实际可能却是受到环境的影响造成的，功能却没有问题。
换句话说，我们无法相信自动化测试的结果。
这真是要把人折磨死的节奏啊。
我们想了很多办法，比如每一轮自动化测试，同一个脚本都反复执行几次（如执行5次），然后设置一个脚本执行失败的“容错值”（比如设置容错值为2，即执行5次这个脚本，脚本失败只要不超过2次就都算通过，OMG这个想法也真是见招拆招，见洞补洞，丧心病狂啊）。想办法保存所有的测试执行记录，然后再手工再从测试记录里面去抽检一定比例的测试脚本的执行结果，看抽检的结果和脚本运行结果的差异，再以此来决定脚本出现误判的概率（OMG，我都服了我们小组的惊人的数学功底，但这真的是完全跑偏了好吗）…….
其实这些问题，归根到底就是脚本的check部分写得有问题 。
如果我们把自动化测试比作一个机器人。让自动化测试来模拟执行某个功能并不难，这就像是机器人的手一样。 难的是机器人的“脑子”，如何让自动化脚本来聪明的确认脚本的执行结果就变得非常重要，这才是自动化测试真正的难点 。
希望以上内容对你有所帮助！达内教育12大高端课程，囊括行业最热门技术，跟新速度快，更贴近企业需求。全国首家先就业后付款培训机构，工作后再分期支付学费。还等啥子呦？达内助你登上人生的转折点，一次改变命运的机会！（更多内容请点击：深圳软件测试培训）
马上预约三天免费体验课
怕钱不够？就业挣钱后再付学费; &&&&
怕学不会？
真正0基础入学，120天精通;&&&&
担心就业？
7万家雇主企业，名企内部就业
本文与大家分享的是:软件测试培训后主要做什么工作？软件测试，在专业上区分，也是有所区分的，分黑盒和白盒测试两种，白盒测试一般在一些大的软件工程项目里面使用得到。
相信每一位想学测试的朋友都有这样的问题：学软件测试有前途吗？软件测试就业前景怎么样，今天下年就来与大家分享一下注射两个问题。
能力的提高过程既是人才培养的过程，也是团队不断成长的过程。尽管在不专门关注的情况下，个人能力和团队能力也会不断地成长和提高，为此，建议应该从如下几个方面注重能力的提高。
软件测试工作来说，所需专业知识可分为基础工作知识和专门工作知识两类。那么刚入门的新手如何提高软件测试的能力，下面小编就来与大家分享一下。
Copyright (C)
Tedu.cn All Rights Reserved 京ICP备号-56 版权所有
选择城市和中心
达内北京亦庄大学生实训基地
达内北京网络营销中心
达内北京会计中心流量复制 /AB 测试/协程
在实际开发中经常涉及到项目的升级，而该升级不能简单的上线就完事了，需要验证该升级是否兼容老的上线，因此可能需要并行运行两个项目一段时间进行数据比对和校验，待没问题后再进行上线。这其实就需要进行流量复制，把流量复制到其他服务器上，一种方式是使用如 tcpcopy 引流；另外我们还可以使用 nginx 的 HttpLuaModule 模块中的 ngx.location.capture_multi 进行并发执行来模拟复制。
构造两个服务
location /test1 {
keepalive_timeout 60s;
keepalive_requests 1000;
content_by_lua '
ngx.print("test1 : ", ngx.req.get_uri_args()["a"])
ngx.log(ngx.ERR, "request test1")
location /test2 {
keepalive_timeout 60s;
keepalive_requests 1000;
content_by_lua '
ngx.print("test2 : ", ngx.req.get_uri_args()["a"])
ngx.log(ngx.ERR, "request test2")
通过 ngx.location.capture_multi 调用
location /test {
lua_socket_connect_timeout 3s;
lua_socket_send_timeout 3s;
lua_socket_read_timeout 3s;
lua_socket_pool_size 100;
lua_socket_keepalive_timeout 60s;
lua_socket_buffer_size 8k;
content_by_lua '
local res1, res2 = ngx.location.capture_multi{
{ "/test1", { args = ngx.req.get_uri_args() } },
{ "/test2", { args = ngx.req.get_uri_args()} },
if res1.status == ngx.HTTP_OK then
ngx.print(res1.body)
if res2.status ~= ngx.HTTP_OK then
--记录错误
此处可以根据需求设置相应的超时时间和长连接连接池等；ngx.location.capture 底层通过cosocket 实现，而其支持 Lua 中的协程，通过它可以以同步的方式写非阻塞的代码实现。
此处要考虑记录失败的情况，对失败的数据进行重放还是放弃根据自己业务做处理。
AB 测试即多版本测试，有时候我们开发了新版本需要灰度测试，即让一部分人看到新版，一部分人看到老版，然后通过访问数据决定是否切换到新版。比如可以通过根据区域、用户等信息进行切版本。
比如京东商城有一个 cookie 叫做__jda，该 cookie 是在用户访问网站时种下的，因此我们可以拿到这个 cookie，根据这个 cookie 进行版本选择。
比如两次清空 cookie 访问发现第二个数字串是变化的，即我们可以根据第二个数字串进行判断。
判断规则可以比较多的选择，比如通过尾号；要切 30% 的流量到新版，可以通过选择尾号为 1，3,5 的切到新版，其余的还停留在老版。
使用 map 选择版本
map $cookie___jda $ab_key {
~^\d+\.\d+(?P&k&(1|3|5))\.
使用 map 映射规则，即如果是到新版则等于 &1&，到老版等于 “0”； 然后我们就可以通过 ngx.var.ab_key 获取到该数据。
location /abtest1 {
if ($ab_key = "1") {
echo_location /test1 ngx.var.
if ($ab_key = "0") {
echo_location /test2 ngx.var.
此处也可以使用 proxy_pass 到不同版本的服务器上
location /abtest2 {
if ($ab_key = "1") {
rewrite ^ /test1
proxy_pass http://backend1;
rewrite ^ /test2
proxy_pass http://backend2;
直接在 Lua 中使用 lua-resty-cookie 获取该 Cookie 进行解析
首先下载 lua-resty-cookie
cd /usr/example/lualib/resty/
wget https://raw.githubusercontent.com/cloudflare/lua-resty-cookie/master/lib/resty/cookie.lua
location /abtest3 {
content_by_lua '
local ck = require("resty.cookie")
local cookie = ck:new()
local ab_key = "0"
local jda = cookie:get("__jda")
if jda then
local v = ngx.re.match(jda, [[^\d+\.\d+(1|3|5)\.]])
ab_key = "1"
if ab_key == "1" then
ngx.exec("/test1", ngx.var.args)
ngx.print(ngx.location.capture("/test2", {args = ngx.req.get_uri_args()}).body)
获取 cookie，然后使用 ngx.re.match 进行规则的匹配，最后使用 ngx.exec 或者 ngx.location.capture 进行处理。此处同时使用 ngx.exec 和ngx.location.capture 目的是为了演示，此外没有对 ngx.location.capture 进行异常处理。
Lua 中没有线程和异步编程编程的概念，对于并发执行提供了协程的概念，个人认为协程是在A运行中发现自己忙则把 CPU 使用权让出来给B使用，最后 A 能从中断位置继续执行，本地还是单线程，CPU 独占的；因此如果写网络程序需要配合非阻塞 I/O 来实现。
ngx_lua 模块对协程做了封装，我们可以直接调用 ngx.thread API 使用，虽然称其为“轻量级线程”，但其本质还是 Lua 协程。 该 API 必须配合该 ngx_lua 模块提供的非阻塞 I/O API 一起使用，比如我们之前使用的 ngx.location.capture_multi 和 lua-resty-redis、lua-resty-mysql 等基于 cosocket 实现的都是支持的。
通过 Lua 协程我们可以并发的调用多个接口，然后谁先执行成功谁先返回，类似于 BigPipe 模型。
依赖的 API
location /api1 {
echo_sleep 3;
echo api1 : $arg_a;
location /api2 {
echo_sleep 3;
echo api2 : $arg_a;
我们使用 echo_sleep 等待 3 秒。
location /serial {
content_by_lua '
local t1 = ngx.now()
local res1 = ngx.location.capture("/api1", {args = ngx.req.get_uri_args()})
local res2 = ngx.location.capture("/api2", {args = ngx.req.get_uri_args()})
local t2 = ngx.now()
ngx.print(res1.body, "&br/&", res2.body, "&br/&", tostring(t2-t1))
即一个个的调用，总的执行时间在6秒以上，比如访问 http://192.168.1.2/serial?a=22
ngx.location.capture_multi 实现
location /concurrency1 {
content_by_lua '
local t1 = ngx.now()
local res1,res2 = ngx.location.capture_multi({
{"/api1", {args = ngx.req.get_uri_args()}},
{"/api2", {args = ngx.req.get_uri_args()}}
local t2 = ngx.now()
ngx.print(res1.body, "&br/&", res2.body, "&br/&", tostring(t2-t1))
直接使用 ngx.location.capture_multi 来实现，比如访问 http://192.168.1.2/concurrency1?a=22
协程 API 实现
location /concurrency2 {
content_by_lua '
local t1 = ngx.now()
local function capture(uri, args)
return ngx.location.capture(uri, args)
local thread1 = ngx.thread.spawn(capture, "/api1", {args = ngx.req.get_uri_args()})
local thread2 = ngx.thread.spawn(capture, "/api2", {args = ngx.req.get_uri_args()})
local ok1, res1 = ngx.thread.wait(thread1)
local ok2, res2 = ngx.thread.wait(thread2)
local t2 = ngx.now()
ngx.print(res1.body, "&br/&", res2.body, "&br/&", tostring(t2-t1))
使用 ngx.thread.spawn 创建一个轻量级线程，然后使用 ngx.thread.wait 等待该线程的执行成功。比如访问 http://192.168.1.2/concurrency2?a=22
其有点类似于 Java 中的线程池执行模型，但不同于线程池，其每次只执行一个函数，遇到 IO 等待则让出 CPU 让下一个执行。我们可以通过下面的方式实现任意一个成功即返回，之前的是等待所有执行成功才返回。
ok, res = ngx.thread.wait(thread1, thread2)