1、自动化前期筹备事情：

1、先熟悉业务，项目配景，项目现状，测试目前存在的问题

2、拔取项目周期长，历史成果不变；在这样的情况下筛选用例来做自动化，从成果用例中选，如已经拔取 200 个用例

3、如果做布局，需要了解项目接口的特征，拔取部分接口实际操纵下

　　了解接口的鉴权方法，数据格局 xml、json，是http还是https 请求

4、按照以上矿建选型：代码 还是 工具

　　代码：Python的接口、web、APP

　　工具：postman、jmeter  。。

5、做自动化的目的：

　　解决问题：进行回归测试，笼罩哪些模块、涉及哪些模块、要到达什么要求

2、 框架编写

PO模式（涉及分层设计思想）

PageLocators （译：配置 老k特） -- 封装页面的元素定位

PageObjects（译：配置奥播债可特） -- 封装的页面类、页面的行为

TestCases （译：太死特 k死一死） -- 测试用例（=页面东西 + 测试数据）

TestDatas （译：太死特 得特死） -- 单独打点测试数据

编写自动化测试用例--使用PO思想：https://www.cnblogs.com/shouhu/p/12233225.html

3、自动化用例编写

用Excel 写出自动化用例，想清楚用例的每一部分是什么，如何实现，如何能够保证用例多次运行不受影响

包孕：模块 + 子成果 + 用例名 + 前置 + 操纵法式 + 预期功效 + 输入数据 + 优先级

自动化用例设计原则/拔取

1、不是所有的手工用例都要转为自动化测试用例。

2、考虑到脚本开发的本钱，不要选择流程太庞大的用例。如果有须要，可以考虑把流程拆分成多个用例来实现脚本。

3、选择的用例最好可以构建成场景。例如，一个成果模块，分多个用例，多个用例使用同一个场景。

4、选择的用例可以带有目的性。例如，这部分是用例做冒烟测试（主流程正常场景），那部分用例是做回归测试（主流程+异常场景）等，固然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有改削用例来适应脚本和需求。

5、拔取的用例可以是你认为是反复执行，很啰嗦的部分。例如，字段验证、提示信息验证这类，这部分适用于回归测试。

6、拔取的用例可以是主体流程，这部分适用于冒烟测试。

7、自动化测试也可以用来做配置查抄、数据库查抄。这些可能逾越了手工用例，但也算用例拓展的一部分，项目卖力人可以有选择地增加。

8、平时在手工测试时，如果需要结构一些庞大的数据或反复一些简单的机械式行动，则报告自动化脚本，让它来帮你，或许你的效率会因此而得到提高

在编写自动化测试用例过程中应该遵守以下几点原则：

1、一个用例为一个完整的场景，从用户登录系统到最终退出并封锁浏览器。

2、一个用例只验证一个成果点，不要试图在用户登录系统后把所有的成果都验证一遍。

3、尽量少的编写逆向逻辑用例。一方面因为逆向逻辑的用例很多（例如，手号输错有几十种情况）；另一方面自动化脚本自己对照脆弱，对付庞大的逆向逻辑用例实现麻烦且容易堕落。

4、用例与用例之间尽量制止孕育产生依赖。

5、一条用例完成测试之后需要对测试场景进行还原，以免影响其它用例的执行。--数据清理

当前用例执行完成后，在删除垃圾数据

运维去删

测试组长来删

不需要所有的用例 转成自动化，

业务不庞大、简单、反复操纵、字段校验，来写自动化用例　　

考虑：web用例的不变性和效率如何提高：

前置条件中，适当的使用接口

元素定位，使用相对定位/更灵活的定位方法

期待方法：

期待写的好欠好，忘记了期待，缺掉了期待，使用的是强制期待时间不够等等，城市影响不变性和效率----智能期待/强制期待　　

自动化用例不宜过于庞大，一个用例只校验一个成果

*******请大家尊重原创，，如要转载，请注明来由：转载自：https://www.cnblogs.com/shouhu/，感谢！！******* 

如果有一个项目我们怎么进行前期筹备事情及测试用例的拔取，在编写自动化测试用例过程中应该遵守以下几点原则？--web用例的不变性和效率如何提高：