In software testing, test automation is the use of special software (separate from the software being tested) to control the execution of tests and the comparison of actual outcomes with predicted outcomes. Test automation can automate some repetitive but necessary tasks in a formalized testing process already in place, or perform additional testing that would be difficult to do manually. Test automation is critical for continuous delivery and continuous testing. —— wikipedia
维基上对自动化测试的定义简单来说，就是通过软件来替代人来执行测试用例，并得到测试结果的过程。当然，对于自动化测试来说，包含的范围十分大的，对于服务端接口与代码接口来说，通常采用非Ui自动化的测试方法，如：Unit Test、API Test等等；对于包含Ui元素的完整App、GUI程序来说，Ui自动化的测试方法有：mock、功能测试等等。
对于安卓自动化测试来说，功能测试是最基本也是最常用的方案，那么功能测试到底能做什么？有什么优点？以及如何做好功能测试？ MQC 团队推出系列文章，为大家讲解 Appium 技术干货以及 MQC 功能测试服务。
维基上对自动化测试的定义简单来说，就是通过软件来替代人来执行测试用例，并得到测试结果的过程。当然，对于自动化测试来说，包含的范围十分大的，对于服务端接口与代码接口来说，通常采用非Ui自动化的测试方法，如：Unit Test、API Test等等；对于包含Ui元素的完整App、GUI程序来说，Ui自动化的测试方法有：mock、功能测试等等。
功能测试如何帮助改善产品质量
对于大多数敏捷开发团队来说，要完成对一款大型产品各个方面进行全方面的测试是十分困难的。一方面，我们需要根据每次变更有针对性的测试重点模块，那么必然会遗漏对其它模块的测试；另一方面，很多模块的测试工作是机械性的，如回归测试、性能测试、机型适配等等，全部交给人工测试将大大增加人工成本。
功能测试可以将测试开发从繁琐的重复劳动中解放出来，把精力集中到重点模块，同时有余力设计编写完善的测试用例，并通过功能测试提高测试覆盖率，降低隐患。
功能测试的用例不是万能的
对于测试开发来说，追求100%的测试覆盖率是无可厚非的，但是事实上很多的测试工作是机器难以完成的，比如文字验证码识别。优先设计完成稳定模块的用例来保证今后功能不断回归的工作，之后再考虑时间成本、人力成本的前提下再去考虑更多复杂问题的用例设计。
另一方面，对于频繁发生变化的模块，用例也应当适应这种变化不停迭代，从而快速的在各个机型上进行功能验证。
功能测试无法发现新问题
我们在编写和调试用例的时候，或许能够发现一些功能性问题，而用例在进行回归后，发现问题的可能性就很低了。功能测试其实就是一个用例不断重复的过程，功能测试本身应当是一个“守护者”而非“探索者”，它可以帮助我们更加确定应用没有问题或者发现一些回归性的问题，而不是新问题。MQC 在探索问题的方向上自主研发了一款兼容性测试工具 Ripper，在达到高覆盖率的同时保证较高的 Bug 检出率，有兴趣的小伙伴欢迎试用 MQC 兼容性测试。
功能测试是需要成本的
我们通过功能测试用例来保证产品的质量，同时需要专业的工程师来保证用例的质量。设计开发一个合格的用例也是需要不断的调试、迭代与维护的，这就需要一个好的平台系统来帮助完成相关工作。MQC为开发者提供了完善的用例库管理功能，同时，为测试开发团队打造了专业的一站式测试协作平台，帮助团队进行应用管理、协同工作、任务分发、报告统计。
通过以上几点内容，相信大家对功能测试的概念已经有了一定的了解。MQC 在 Android 功能测试上选择使用了 Appium 测试框架，其开源社区较为活跃，兼容性好、功能丰富，相信能满足绝大部分功能测试的需求；在脚本开发方面，MQC 提供了在线真机录制、云端真机回放等多种服务，来帮助提高用例脚本的开发、调试效率；最后，平台提供了 App 用例管理、用例历史报告查看、编辑脚本、上传脚本等功能，帮助用户通过平台来完成功能测试的迭代维护需求。更多服务，欢迎来阿里云移动质量中心进行体验。
上文提到的移动测试产品详情，请见https://www.aliyun.com/product/mqc