测试同学应该清楚，测试可以分为手工测试和自动化测试。按照经验和目前的测试理论，自动化测试还无法完全代替手工测试，但是可以代替稳定模块的回归测试。
自动化测试容易依赖模块的稳定度，随着版本迭代，旧版本的自动化用例可能会失效，这增加了自动化测试维护的工作量，也逐渐打击了自动化测试开发者的积极性。导致有些团队放弃自动化测试，甚至有些团队根本没考虑引入自动化。但是，随着项目越来越大，如果不逐渐积累自动化用例，回归时需要的人力需求就会逐渐增多，如果又不愿意拉长项目周期，就会造成测试不完全，埋下 bug，诱发线上事故。
什么样的项目/模块适合引入自动化？
功能稳定是必须的，极端一点，如果这个功能下个版本说不定都会被砍掉，那实在是犯不着做自动化。稍微不那么极端一点，功能会经常迭代/优化，对于测试脚本的影响，体现在接口变化、参数变化、UI 变化。较小的变化，简单维护还可以接受。如果大量的变化，每个大版本都要花很多时间维护，那就要考虑是否值得做自动化。
一个测试组的分工，可以有按职责分，测试负责人，测试人员，测试开发人员；也可以按模块分，测试模块 A，模块 B 的；可以按端分，测试 iOS 的，测试安卓的。当然这些分工标准也可以是混合的。见过一些项目组，只按模块分，模块 A 的 QA 要测试这个模块各端的表现；也有些项目组，比如我们，是按端 + 模块分，首先分 iOS 和安卓组，然后再按模块分；也听说一些项目组，会独立拿出一部分人员做自动化，当然这部分人要先熟悉业务。如果你不是专职做自动化的，那就说明你要兼顾版本测试以及自动化测试。这种情况下，版本测试的重要性会远远大于自动化，自动化任务就要安排在版本间隙，比如提测前，你写完了测试用例，完成了用例评审、需求确认等项目工作，你才会去完成下自动化的工作。当然如果排期合理，不变态紧凑，那还是可以有时间去完成的，而且在回归过程中，可以跑自动化，来验证你的测试代码。
我的自动化测试实践主要是应用于回归，除此之外，还应用于，比如打包、或是一些测试流程。初心，也是这些操作繁琐、稳定、可以实现，因而实现了自动化。完成之后，确实大大提高了效率，时间和经历上都得到了节约。
今天就谈这么多，如果你是新手，其实只要你有兴趣，都可以尝试。如果你是老鸟，其实只要对于功能稳定的模块都可以考虑是否有实现的可能和必要，相信有还是比没有强。