自动化测试
与之前介绍的功能测试、性能测试不同，自动化测试其实指的是一种技术手段，而不是特指某一方面的测试内容。自动化与其他测试内容相结合都可以称之为自动化测试，例如可以自动化测试功能，自动化测试性能等。之所以采用自动化手段，是因为它能带来以下好处：
- 同时并发，大量执行。
- 流程固定，不易出错。
- 节省人手，重用性高。
所以也导致了想要使用自动化测试，需要有稳定的版本环境，固定的执行步骤，也就很难发现新的问题。
思考自动化测试方案前，首先要明确要测试的内容是基于什么层面的，如下图所示：
很多人觉得，越往下越需要懂得代码，那么测试难度会越大。其实恰恰相反，越往上自动化测试的成本其实越高，因为越往上流程越复杂，测试步骤的依赖性也就越强，通过现象定位问题的难度也就越大。一个基于UI层面的点击操作后，没有打开预期能够打开的界面，那么接下来的自动化用例很可能都会报错，而这个没能打开的原因有很多种可能性，可能只是延迟了，或者是有其他界面自动弹出遮蔽了按钮，又或者是按钮功能发生了变化。
在实际的工作当中，我做过的自动化测试内容包括有：
- CheckTable：自动化检查配置表填写内容的脚本。
- UIAutomator：基于移动端设备UI控件操控的自动化运行。兼容性云测主要也是用这种方式实现同时测试几百台设备的。
- DataCharts：读取测试数据，自动绘图分析，配合收集测试数据的工具使用。
- Instruments_Collector：自动化收集Instruments记录的iOS客户端性能数据。iOS客户端性能测试中也提到过了。
- Dstat_Collector：自动化收集在Linux上运行的服务端的性能数据。其实就是在dstat（点击github链接）的基础上做的二次开发。
- CheckCDN：监控外网CDN下载链接的访问是否正常，以及下载的文件配置内容是否正确。
当前，我所做的这些都是比较简单的，很多也都是在他人分享的方法基础上进行的扩展。但对于帮助新手理解和上手自动化测试相关的工作内容也许有一些借鉴作用，如果你是专职做自动化测试的，将来所做的肯定比这些要更为复杂和深远。
有关自动化的一些误解
自动化测试一定比手工测试效率高，甚至可以取代手工。
只从执行层面来说，自动化是比手工效率高。但测试不仅仅只是一个简单执行的过程，你还需要设计方案，规划步骤，确认结果，定位问题，沟通解决。而且自动化测试的效率高还依赖于一个前提，那就是产品比较稳定，执行过程中不会大量出错，否则自动化执行一步报一个错误，然后你再查看出错的现象，定位出错的原因，可能还不如你自己手工测试，至少你在执行过程中直接就看到了问题是如何发生的。而且自动化测试也无法发现新的问题，只能重复执行旧的逻辑，算不上多么灵活，所以主要用于监督式的『冒烟测试』。
相比传统软件，想要在游戏软件上实现自动化测试，显得更加的艰难。游戏的需求修改的十分频繁，而且除了少数团队，大部分游戏开发者并没有建立统一标准的开发规范，所以自动化识别的复杂度就高不少。还有就是游戏过程中各种突发性和意外性很多，即便是执行同一个过程，可能因为不同数据或随机运气的缘由，导致结果也不同，也就很难判断执行结果的对错。
自动化测试具备很高的技术含量，有利于将来的学习和发展。
首先，自动化测试其实并没有太高的技术含量，即便有，也是体现在自动化方案的设计和实现上，而不是具体的自动化测试行为本身。举个栗子，Appium是很有名的移动端自动化测试工具，但其实学会部署Appium，试着写基于UI的自动化脚本后，你会发现，自动化脚本也是单调重复的。所以有技术含量的不是Appium的自动化脚本，而是做出Appium这个工具本身。但如果要去做工具，简单的话还好，复杂的话就又是在重复造轮子，反而没有时间做好应该完成的测试工作。
其次，觉得有利于将来的学习和发展的重点其实不是自动化，而是为实现自动化所要具备的思维能力和编程水平。思维能力这个不好评价，但编程水平主要依赖于大量的练习。如果你确定要往技术方向深入发展，那么转岗做更多与程序开发相关的工作更有利于你实现这个目标，而测试对思维的重视程度要高于编程，也不一定非要通过做自动化测试才能提升思维。当然，如果懂得编程，就更有利于理解待测试的程序逻辑，也有助于提升思维，但绝对不想想象的那样，会做自动化测试就意味着比做功能测试要高级，更公平的评估方式还是看最终产生的工作价值。
除了上述说到的内容，自动化测试用例的通用性较差，维护成本比较高。因为自动化测试用例要与实际的逻辑流程关联，如果是基于UI的，可能更换一个按钮，突然弹个界面都会导致无法正常执行。未来自动化测试的方向很可能是与机器学习、大数据相结合，通过收集和模仿用户操作，可以强化执行行为，或者是增加探索测试的可能。
做自动化测试的思路
很多介绍做自动化测试的人，一上来就说要先学习什么自动化测试框架。从我个人观点上来说，并不建议这样做。一方面是前期缺少对工具的认知，很难直接跟自己的工作有效结合起来；另一方面则是没能建立起明确的目标和思路，下次换个内容或者换个方式，可能还是陷入迷惑。当然，也并不是说完全没有好处，学习现有的自动化测试框架，可以更降低前期摸索的成本，也更容易跟有相关经验的人交流。所以我的个人建议是：
- 首先，梳理自己的以往的工作内容，看看哪些是重复性强，但工作量大的执行过程，思考下能否总结出要点进行归纳，这些就是可能进行自动化的部分。
- 选择合适的工具，尝试将可以自动化的部分进行自动化。最简单的就是网上搜一下有没有人做过相同或相似的事情，用的什么工具和方法，然后学习模仿一下。
- 当实现一些自动化内容后，尽量保持使用，并在使用过程中发现和改善问题，并不断尝试将更多相关的内容逐步自动化。
- 如果你较难找到可以自动化的内容，那就多多留意一些行业内的技术讯息，看看哪些是有可能应用于自身工作的，这个时候再去了解和学习的目的也会更加明确。