我最近在学习大话移动测试Appium部分，已经搭建好环境并且可以写简单的测试用例，但是不知道如何有效的用在工作中，工作中客户端测试还是手工测试，我想问一下您们在工作中自动化测试主要用在什么地方，怎么做的，谢谢

最近加我微信问Appium相关问题的同学有点多，说实在写完Appium那一章，我就鲜少接触Appium，我的工作中也基本用不到Appium，加上很多人加上微信招呼也不打，就直接抛一个大问题。我遇到这样的，脑袋就端的一下，然后拒绝回答。

但是今天这位同学的问题比较有代表性，加之他也比较礼貌，所以我就凭自己的经验来试着回答这个问题，有不对的地方请指正。

我把这位同学的问题拆成三个:

• 如何把一个工具有效地运用在工作中？
• 客户端测试中，手动测试和自动化测试怎么配比？
• 自动化测试主要用在哪些方面？

如何把一个工具有效地运用在工作中？

这个问题很大，我就拿Appium举例子。从选择工具开始，很多人手机里一堆app，真正用的没几个。UI自动化测试工具很多，如果不能很好的评估，对工具的研究反而会占去大量的时间，目前很多玩Appium的同学，花了大把时间在环境部署或者如何真机运行Appium上，反而到了真正要用Appium来写业务自动化时候，摸不到方向。

写移动应用自动化，目前Appium的确是较好的选择，Macaca也是不错的选择。但是这两个工具的学习成本都相当高。这也是移动互联网测试的一个特点，就是学习成本，想要在当下移动互联网环境下做好测试工作，对于移动应用的各种特性都要了如指掌，尤其是移动自动化，你需要清楚它背后运转的原理，才能更好运用工具。但是即便如此，我们依然不能把调研工具的工作作为大头，真正重要的是使用工具去辅助或者完成业务。

所以反过来，从业务出发，理清楚，哪些业务可以通过哪些工具完成哪些业务场景？你不能说我选了Appium，所以我想做UI自动化，而应该是我想使用自动化来覆盖一些稳定的业务场景，以此来缓解回归压力。然后再去考虑选择Appium还是Macaca，当然还要权衡自己的能力，比如你擅长Java，那么选择Java client，如果你擅长nodejs，那么Macaca是不错的方案。

选择了一个工具或者一个方案之后，就要避重就轻，别想着把Appium吃透，而是想着用Appium把业务自动化测试玩转。你也许会担心，这样对自动化不够理解，别担心，你在写自动化测试的时候，会反推这些东西的。比如，你觉得串行跑用例慢，你就会想到搭建grid，你发现Appium Server不稳定，你就会想办法加心跳，检测服务是否live，以便随时唤醒。总之，在业务场景中运用技术，会让技术更加接地气，也更加有成就感。

客户端测试中，手动测试和自动化测试怎么配比？

老实说，如果一个app全是自动化测试跑出来的，我敢保证质量肯定不高。首先需要明确一点，一个经过完整的需求宣讲，系分，测分，几轮手动测试出来的应用质量都不一定高到哪里去。

软件测试工作中，尤其是业务导向的软件，估计在未来很长一段时间内还将是手动为主，自动化为辅。这句话也许是错的，但是我敢说错的是手动为主，也许未来开发水平高到，写出来的app可以直接达到上线的标准，然后通过在线监控来反推app质量，或者其他的手段，但是自动化依然还会使辅助。想想看，我们生活中的自动化工具，什么时候反客为主了？

所以在客户端测试中，还是采用手动测试并没有什么问题。问题在于我们是否能利用自动化测试用户来减少手动测试的压力？比如容易穷举的代码分支用单元测试覆盖，稳定的接口用接口测试覆盖，客户端老版本，不变的路径，用ui自动化覆盖。这些才是应该花精力的地方。所以没有什么配比好坏的说法，别人公司的经验值在你公司也许就是shit。如果你的app一天一个样，你做什么自动化都是白瞎。

自动化测试主要用在哪些方面？

见上。同时在补充一点，自动化并不只有测试。当你做一件同质的事情做多了而且有些厌烦了，你就可以考虑使用下自动化了。不需要全自动化，半自动化足够了。