一、自动化测试存在的真正意义：
主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工作中解脱出来。它的主要目的在于验证问题，而不是发现问题。所以对于自动化的设计，主要集中在功能正确性方面。
目前自动化测试阶段定位在冒烟测试和回归测试。冒烟测试执行的是主体功能点的用例，回归测试执行全部或部分的测试用例。
二、自动化测试用例的设计原则：
1、一个脚本是一个完整的场景，从用户登陆操作到用户退出系统关闭浏览器。
2、一个脚本只验证一个功能点，不要试图用户登陆系统后把所有的功能都进行验证再退出系统
3、尽量只做功能中正向逻辑的验证，不要考虑太多逆向逻辑的验证，逆向逻辑的情况很多（例如错误的登录账号有很多情况），验证一方面比较复杂，需要编写大量的脚本，另一方面自动化脚本本身比较脆弱，很多非正常的逻辑的验证能力不强。（我们尽量遵循用户正常使用原则编写脚本即可）
4、脚本之间不要产生关联性，也就是说编写的每一个脚本都是独立的，不能依赖或影响其他脚本。
5、如果对数据进行了修改，需要对数据进行还原。
6、在整个脚本中只对验证点进行验证，不要对整个脚本每一步都做验证。
三、用例选择注意事项：
1、不是所有的手工用例都要转为自动化测试用例。
2、考虑到脚本开发的成本，不要选择流程太复杂的用例。
3、选择的用例最好可以构建成场景。例如一个功能模块，分n 个用例，这n 个用例使用同一个场景。这样的好处在于方便构建关键字测试模型。
4、选择的用例可以带有目的性，例如这部分用例是用例做冒烟测试，那部分是回归测试等，当然，会存在重叠的关系。
5、选取的用例可以是你认为是重复执行，很繁琐的部分，例如字段验证，提示信息验证这类。这部分适用回归测试。
6、选取的用例可以是主体流程，这部分适用冒烟测试。
7、测试用例需要更多的关注功能逻辑的实现，而不必纠结某些字段的限制。
8、自动化测试也可以用来做配置检查，数据库检查。这些可能超越了手工用例，但是也算用例拓展的一部分。项目负责人可以有选择地增加。
9、如果平时在手工测试时，需要构造一些复杂数据，或重复一些简单机械式动作，可以让自动化脚本来帮你。
四、自动化测试用例转型原则
1、当前的测试用例前置配置信息要写清楚。
2、每一个步骤都要衔接好，错了，脚本要抛出异常。
3、每一个步骤要做什么，验证什么要写清楚，写具体。有时一个检查点，你只需看一眼，但是脚本要写一堆代码去验证，这样的做法是不可行的。
4、用例之间不要有关联性，自动化测试开发同样是软件开发工程，脚本编写同样提倡高内聚低耦合的理念。
5、不是每一个步骤都需要验证点。
6、别在多个地方重复相同的验证。脚本很忙！我没空。当然，除非有必要。
7、开门记得要关门，配置信息要回归原点，否则脚本要迷路。