熟悉自动化测试工具（WEB类：QTP、selenium；App类：Appium、MonkeyRunner、UiAutomator等）方法者优先；
作者在此不阐述软件开发工程的基本概念，但是作者一定会强调，在自动化测试的开发过程中，一样需要通过严格的开发计划、版本管理、代码管理等一系列相关措施，兢兢业业地做好每一步工作，踏实地管理和控制好每一个环节。自动化测试脚本不是一次性的，而是需要长时间维护下去的，如果事先没有制定良好的测试方案，实施过程中不严格根据方案执行，开发完毕后又不做任何改进或提出各种优化方案等，那么你说
系统中的测试对象基本可以正常识别。一般来说，自动化测试的基本要求或者说自动化测试工具对系统的基本要求就是对象的识别，一个自动化测试工具的好坏评判最基本的标准就是，是否能够识别更多的系统控件以及对无法识别的控件能否提供各种解决方案或自定义开发各种控件的识别代码。，
1.1.3 自动化测试用例设计详解
通常，在项目的测试过程中，测试工程师都会首先获取测试需求，接着熟悉测试需求，等待测试计划产出后，编写和设计测试用例，一般测试工程师都会根据事先设计好的测试用例来验证实际结果是否符合预期，包括后期的回归测试。而自动化测试项目同样也有这样一个流程，需要自动化测试工程师首先分析测试需求，产出自动化测试计划，设计好自动化测试用例后才能开始进入后续的脚本设计开发阶段。那么，既然要写自动化测试用例，有些读者可能会问，不是有手工测试用例吗，为什么还要去完成自动化测试用例？为什么不能用手工用例来直接替代自动化测试用例呢？它们之间到底有什么区别呢？自动化测试用例的设计原则到底又是什么呢？在上一章节中，内容虽有涉及，但作者并没有作细化介绍，因为自动化测试用例设计是一个非常重要的环节，所以必须单独列为一个章节进行系统化的解析。
很多公司在实施自动化测试的过程中，往往会把所有的手工测试用例作为自动化测试用例，并且直接进行脚本的开发工作，甚至有些公司不写自动化测试用例，直接想当然地开发测试脚本，这些都是极其不规范的做法，甚至很有可能是导致最后自动化测试项目失败的最大原因。那么问题就来了，为什么不能使用手工测试用例完全替代自动化测试用例呢？有以下几点原因，同时也是自动化测试用例的设计原则。
● 原则1：自动化测试用例的范围往往是核心业务流程或者重复执行率较高的。