先说常规A/B test有哪些原则：

1，必须有个明确目标，且已知有数据可检测对比：

例如，两个活动banner，在较长期的活动中，可以A/B 测试，"同样时间内，单位数字UV 下，哪个banner的点击率更高（不管实际下单率等数据）"。

如果目标不明确，且不清楚直接或间接的数据——极有可能上下A/B test后，依旧不能有充分的数据依据，来支撑论点。

2，A/B test 是策略层面，而不应是战略层面

3，A/B 一定要考虑开发成本和敏捷度

H5较native app，更易实现快速发布、快速修正，比较适合校准方案；但iOS，动辄30天左右的发布周期，在做A/B test，你不是要玩死人嘛。

然后是你说的『A/B test』局限，可能有：

1，对于A/Btest 本身，增加设计成本和开发成本：不是小公司或业务初期可以玩的；

2，该方法本身就是『控制变量法』，控制某些条件不变，调动某些条件变动，来检测『哪种策略好』——但现实环境是复杂的，能保证检测数据的纯洁性，且均已做好埋点，难度也不小；

3，A/B test，得到的数据，也会受到『测试期较短』、『测试不够深入』等质疑——似乎也不能过分依赖测试数据；

—————————扩展———————————

A/B test 都是方法论，在寻找当前最优的策略；基于这个目的，也有其他创新的玩法，未必非A/B test不可：

1，滴滴打车-顺风车模块-乘客发布行程：

顺风车刚开始时，即使调研充分、流程无可挑剔，也会存在『理想与现实』的差距。

滴滴的做法是，针对乘客『行程偏好』做成H5页面，即可以自由调整用户的录入信息、也降低了版本发布的频率（只是需要后端，做好数据兼容性和提供前端切换方案的标识），就是极大提高方案的适应性；

附图（滴滴打车-顺风车-乘客发布行程）