自动化测试相关注意事项及问题点汇总
1、WEB自动化测试框架是如何搭建的？
我们web自动化测试使用的技术栈是： Python+Selenium+Pytest+Parametrices+Excel+Allure+Jenkins 框架使用的是基于Excel的关键字驱动，将维护框架和使用框架分离开来进行自动化测试时，将元素定位表达式及要执行在操作写入excel即可，显著降低了自动化测试的落地难度。
主要功能：
- 内置常用关键字，实现关键字驱动测试，有升级为BDD潜力
- 自动的判断浏览器类型版本，并自动下载、启动合适的浏览器驱动
- 内置自动等待，避免正常情况下UI测试的出错情况
- 通过执行js的方式，实现特殊场景交互，如强制点击、强制输入、拖拽上传等
- 以字符串为核心断言策略，支持等于、包含、正则匹配、内容组合等多种断言方式
- 自动生成allure的测试报告，报告内置与excel内容一一对于匹配
- 支持并行测试和分布式测试文件架构： conf # 项目配置 data # 数据驱动测试文件 action.py # 关键字驱动封装case.py # 用例管理和封装data.py # 数据驱动封装pages # PO 封装 report # allure测试报告 tests # 存放 excel文件作为测试用例框架用法：
- 1）创建execl文件，每个sheet页看作一个TestSuite
- 2）在sheet页中申明测试用例，填写测试用例的名称
- 3）在单元格中填写步骤名、关键字、关键字参数，完成测试步骤
2、WEB自动化测试的价值在哪里？为什么要做WEB自动化测试？
Web自动化测试就是模拟手工测试人员来做功能测试。用机器的自动执行代替人的操作。主要用于产品的核心功能冒烟测试、回归测试。从系统最核心的功能开始做，再根据情况慢慢展开。 引用自动化测试之后，能代替大量繁琐的回归测试工作，把业务测试人员解放出来，既而让业务测试人 员把精力集中在复杂的业务功能模块上，自动化测试一般是对稳定下来的功能进行自动化，保证不会因为产品的更新导致之前稳定下来的功能出现BUG。
3、公司如何把WEB自动化测试在项目中开展起来？
1）项目组做自动化的可行性分析，包括自动化率能够实施到什么程度？主要考虑：
1.项目时间是否比较长，一般需要一年以上的项目或者长期的产品
2.需求会不会频繁变更
3.自动化脚本是否能够持续反复的使用。
2）项目组调研自动化工具的选择和demo演示，主要演示selenium和robotframework两种。如果有以往成熟的框架演示更好。
3） 逐渐在项目中实施自动化，发现问题并改善。主要包括：
1.编写自动化测试计划
2.提取或编写自动化测试用例
3.由leader编写自动化测试框架脚本
4.编写，调试并维护自动化测试脚本（代码规范以及根据分工编写相应的自动化测试脚本，自测没有问题之后提交到Git服务器）
5.Jenkins持续集成无人值守测试
6.后期维护脚本（主要是因为版本更新添加用例）
4） 把自动化流程化，规范化，文档化，自动化框架需要编写使用文档以及规范文档。
5） 生成定制的报告。继续完善框架。并推广到其他的项目
4、web自动化有多少case？覆盖率是多少？全部执行完需要多久？
1） WEB自动化用例个数根据功能测试用例数而定。自动化用例覆盖率一般为功能测试用例的30%左右
2） 所有WEB自动化用例执行完成大概30-60分钟左右。
5、web自动化测试用例如何设计？
WEB自动化测试用例是从手工测试用例中提取出来的，主要是冒烟用例和回归测试的用例。自动化测试用例的选取更加需要注重用例的严谨性，选择用例的时候遵循以下原则：
- 优先选取覆盖产品核心业务流程的用例；
- 选取的用例是需要重复执行或繁琐的验证功能，比如字段验证、提示信息验证；
- 优先选择正向的测试用例，反向用例一般情况复杂、数量多；
- 不要选择流程太复杂的用例（主流程除外）；
6、如何保证(提升)自动化测试的稳定性？
自动化测试稳定性主要表现在两个方面：一个是元素定位的稳定性，另一个是用例之间依赖稳定性： 元素定位稳定性问题：
(1) 尽量用相对路径的xpath表达式；
(2) 定位元素使用智能等待+显示等待的方式避免元素未加载完成问题；
(3) 脚本执行失败后加入重试机制，提升用例的稳定性；
(4) 用例执行结束后对测试场景进行还原，避免影响其他用例的执行；
(5) 尽量保证单独的测试环境，避免其他的测试同步进行；
用例之间依赖稳定性问题：
用例与用例之间尽量避免依赖，用例尽量可以独立执行；让每条用例都从一个共同的页面开始执行，比如首页，这就需要在测试框架中采用后置处理的方式使每条用例执行完成后都回到首页。
7、自动化测试发现BUG多吗？
不多，因为WEB自动化的用例就是之前项目组已经测试过的基本功能，然后再进行自动化脚本的编写和 执行，它主要是保证已经测试通过的功能在新版本更新后不会因为新增的功能而导致原来的基本功能产 生错误。
8、什么是PO模式？为什么要使用它？ PO模式，全称为Page Object Model ，简称PO，是页面对象模式。意思是把一个页面当做一个对象， 页面的元素就是对象的属性，页面的操作就是对象的行为（方法），PO模式一般使用三层架构，分别为：基础封装层BasePage，PO页面对象层，TestCase测试用例层。 使用PO模式可以使我们的测试用例更简单，更清晰，很多时候我们可以在页面对象中封装很多业务操作方法，测试脚本只需要调用相关方法就可以。另一个就是如果有页面元素发生改变，我们只需要去修改这个页面对象的元素定位和相关方法就可以 了，不需要修改其它脚本。增加代码的可维护性。
9、对数据驱动和关键字驱动的理解？
数据驱动是从某个数据文件(例如Excel文件、Csv文件、YAML文件等)中读取输入、输出的测试数据，然后通过数据驱动方法（ddt，parameterize等）传入自动化测试脚本中。在整个过程中，自动化测试脚本实现数据的读取、测试状态的改变、结果的判断等，从而实现数据和代码分离，这种方式叫数据驱动。
关键字驱动是从面向对象的思路出发，同样的业务逻辑会编写成一个函数作为关键字来被不同的测试脚 本所调用。当所有的业务逻辑测试都可以被写好的函数所组合完成时，就是关键字驱动框架。这个时候 测试用例的开发就变成了测试数据和关键字的组合，并把这种组合工作简化为所有人都很熟悉的表格填写任务，从而最终达到一个由数据和关键字驱动整个测试的效果。
10、在自动化测试过程中主要用到了哪些Python 库？碰到过哪些异常？
web自动化测试： webdriver，WebDriverWait，By，os,xlrd，xlwt，unittest/pytest，time，logging， HTMLTestRunner等。
接口自动化测试： requests，time，logging，json，csv，jsonpath，pyyaml，re，unittest/pytest，allure 常见的异常有以下： NoSuchElementException： 没有如此元素异常
NoSuchAttributeException ： 没有如此属性异常
NoSuchFrameException ： 没有如此frame异常
ElementNotSelectableException ：元素不能选择异常
ElementNotVisibleException ：元素不可见异常
Element not visible at this point ：在当前点元素不可见
TimeoutException ： 超时异常；
11、接口测试的过程中发现过哪些bug?多吗？（或者说：接口测试有没有测试出什么问题？）
接口测试中发现的bug，大多都是接口没按约定返回结果，参数为空，参数长度或类型校验、参数边界 值、代码逻辑、数据错误、或没有返回合理的错误提示等方面的问题。
(1) 一般在前后端联调阶段执行接口测试发现的 bug 会很多（之前开发写代码的时候，所有的ajax 数据都不是后端返回的真实数据，而是我们自己通过接口mock模拟的假数据，当前端的代码编写完毕， 后端的接口也已经写好之后，我们就需要把mock数据去掉，尝试使用后端提供的数据，进行前后端联 调，这个过程我们就把它称之为前后端的接口联调。） 前后端联调接口Bug案例： 比如1：查询列表页接口，前端想分页，Mock就写了三条测试数据，调用后端接口时分页有问题？ 比如2：前端访问的mock数据时没有考虑鉴权。访问真实的后端接口时没有权限。
(2) 然后在接口冒烟测试、回归测试阶段执行接口测试的时候，bug就不多。 常规接口Bug案例： 比如1：新增促销活动接口，满减金额为空也能保存成功，原因是后端代码没有对满减金额参数做空值判 断。 比如2：活动列表接口，查询出来的活动数据少了第一条，原因是SQL中limit条件传入起始序号是1而不 是0 比如3：更新活动接口，接口提示更新成功，但是数据库中的update_time字段没有更新成最新时间，原 因是开发忘记更新这个字段 比如4：比如说下订单接口，商品的价格参数是300元，那我在提交订单时候，我把这个商品的价格改成 3元，后端并没有做验证，更狠点，我把钱改成-3，我的余额还增加了？ 接口鉴权Bug案例： 比如1：比如说修改商品信息接口，只有卖家权限才能修改，我传一个普通用户也可以修改成功，我传一 个其他卖家用户也能修改成功。 比如2：之前有个退保接口，下游系统加了身份证证件有效期校验，导致被测系统接口调用跑不通，通过 自动化发现的问题，并及时去评估到对被测系统的影响。
