自动化项目前期准备工作及测试用例的选取，在编写自动化测试用例过程中应该遵守的原则？--web用例的稳定性和效率如何提高：

1、自动化前期准备工作：

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

2、选取项目周期长，历史功能稳定；在这样的情况下筛选用例来做自动化，从功能用例中选，如已经选取 200 个用例

3、如果做结构，需要了解项目接口的特征，选取部分接口实际操作下

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

4、根据以上矿建选型：代码 还是 工具

　　代码：Python的接口、web、APP

　　工具：postman、jmeter  。。

5、做自动化的目的：

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

2、 框架编写

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

• Common（译：靠门特）：--公共封装
  • basepage（译：掰斯配置）：封装基本关键字，任何一个页面操作都可以实时捕获异常/输出操作日志/失败截图
    • 在 PO 模式当中, 我们做到了 页面对象 与 测试用例 的 分离，但在页面对象编写时，我们仍然还有优化的空间。页面对象有一些共同的基本操作 ，可以封装起来，并可以在基本操作当中加上 日志 和 异常截图 的处理。比如说我们在查找元素时，都需要等待，在PO模式当中, 需要都写上 等待和查找元素，那么就可以将其封装起来，包括其它的一些比如：文本获取、元素属性获取、鼠标操作、窗口切换、iframe切换、 alert弹框关闭、 文件上传、下拉框选择.....

    • 当脚本运行的过程中，出现了用例失败，我们希望可以通过 日志和截图 来分析失败的原因，selenium 并没有主动生成日志和截图，所以需要在代码中加上，使用 webdriver 的 save_ screenshot 方法来截图，日志和截图会记录自动化用例的执行过程，并且，在用例的任何一个步骤出现了异常都会记录异常信息并生成相应的截图。当然为了更美观地跟allure集成，自然也需要将以异常截图展示在 allure 报告中，以下就是 basepage.py 的部分内容:

• • constants（译：康斯ten四）：-----目录路径的
  • handle_config（译：憨豆.康飞个）：----对配置文件的读写
  • handle_logger（译：憨豆.老根）：----封装的处理日志类
  • upload_file（译：阿婆楼的.饭欧）：封装的文件上传类

• 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/，谢谢！！*******