鉴于项目组以及整个Team的自动化测试现状，我在我们Team内部的一次Share会议上分享了我对于有效自动化测试策略的一些看法，可能观点相较于其他同事，比较极端，但是我的初衷其实是想给大家敲个警钟，不要小欲则安，浅尝辄止，我们应该保持对自动化，敏捷，以及持续集成的不断追求，在保证质量的同时提高效率。
因此对于什么样的自动化测试才是有效的，我强调首先第一点，我们要确保我们的自动化case对我们的项目有用
相信这一点，绝大多数人都是认同的，但是我这里把它又拎出来是因为，知道是一回事，但是有没有照着做又是另外一回事。要说做自动化，大家都做，都愿意做，但是我们做的真正对我们的项目有用嘛？下面是我罗列的三条标准：
● 要确信你的自动化case是有价值的，可以代替你的手动测试
自动化测试，尤其是功能性，基于User Story的case，多数是对手动case的Cover，也就是说代替手动case的。所以说我们必须确信我们的case是有价值的，可以代替我们去执行相应的手动case。至于什么是有价值的自动化case，我们相信应该是这样的：在一定的环境中执行过了自动化case，我们就相信，在这个环境中，我们没必要再进行同样的手动操作。
至于如何写出有价值的case，当然也有其策略和方法，这里不再提及。
● 在测试环境中的执行才更有价值的
上条说道，在一定的环境中去执行case，那这个一定的环境是什么样的环境呢？这里我的观点可能比较极端，我认为写case的环境，是我们的开发环境，并不是我们理想中的测试环境。
那什么才是测试环境呢？答案就是，我们自己定义的，并且专门用于测试的环境。这个环境的所有情形都是Expected，或者是可枚举的。比如说装什么系统，装什么相关软件，如何跑我们的case，这都应该是定义好的。这样的环境才是测试环境。
也许有人会对我这里定义的测试环境持反对意见，认为这样的环境并不是用户真实使用的环境，我们应该在更复杂的环境中去执行自动化测试，以期找到更多的bug。但是我认为自动化测试的目的就是做Regression Testing，以期有效的功能测试和版本控制。自动化测试并不能代替手动case，它应该是一个增量式的过程，我们不要期望让自动化发现更多的bug，而应该不断的添加，丰富各种自动化case，以及Bug Verification，以解放测试人员，让其更关注于测试本身。
● 能持续集成的运行了，才算我们的自动化测试跑起来了
这条算是锦上添花型的，持续集成是业界非常好的经验总结，不光适用于我们测试，实际上她应该是适用于整个项目的。要想做到持续集成我们有很多的开源工具可以选择，这条是大力提倡的。
第二点，我们要拥抱任何有意义的变化
这一点非常重要，这个是观念上的转变。很多时候，公司，领导花了大价钱，大精力，来让我们做自动化，而且我们也通过现有的，或者是买来的工具，也确实做了自动化。但是更多时候总会因为这样或者那样的原因，啥项目周期短啊，需求总是变动啊，导致我们的case这条挂了，那条跑不起来了，修了再修，最后测试人员也烦了，自然的，自动化case最终也束之高阁，日久生尘。
但是这里我仍然强调，我们要拥抱任何有意义的变化，这是观念上的转变。为了做出更好的产品，需求在变，代码也跟着变，我们的case在变，自动化case又有何理由不变呢？如果因为需求的变动导致我们自动化case挂了，我们应该高兴才是，因为我们的case成功的侦测到了这个变动，它是有价值的。换句话说，如果需求都变了，而我们的case还跑的好好的，那我可就要怀疑你的case到底有没有价值喽？！
拥抱任何有意义的变动，不是说创建稳定性好的自动化case就没有意义了。试想如果因为一个蚁穴，就导致我们的自动化大堤全线崩溃，那自动化的工作量可就如山高，如海深喽，那又谈何敏捷呢？！
第三点，至于如何做自动化，我想说，Just Coding！
虽然测试自动化可能并不如开发那么高深，但是我觉得我们不要自己潜意识当中就把自己限制的死死的，“我就是个测试，我肯定不如开发”，这样的观点是不对的。尤其现在公司推行的Scrum模式，其理想状态是不分DEV和QA的，大家都是敏捷模式的一员，工作甚至也是可以互相交换的。
当然，现阶段无可否认，DEV的开发水平会更高一些，但是对于我们QA，尤其是做开源领域比如Android的测试，做自动化的终极解决方案其实就是阅读产品代码，当我们读懂了开发代码，那写测试case就不是问题了。
Conclusion
所以我最终的的建议就是：Just Coding，Just Do It！只有真正去做了，你才会发现问题，才会想到去解决问题，才会想到要总结一些方法，然后让我们的Case在测试环境中自由的跑起来！