鉴于项目组以及整个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在测试环境中自由的跑起来！