本文章已正式进入实战阶段，本文章主要会讲解接口测试中的一些接口概念，同时也会简单介绍一下即将要进行测试的项目，除此之外下方有系列文章的传送门，还在持续更新中，感兴趣的小伙伴也可以前往查看，话不多说，让我们一起看看吧~
系列文章： 系列文章【Python自动化测试1】遇见Python之美 系列文章【Python自动化测试2】Python安装配置及PyCharm基本使用 系列文章【Python自动化测试3】初识数据类型与基础语法 系列文章【Python自动化测试4】字符串知识总结 系列文章【Python自动化测试5】列表与元组知识总结 系列文章【Python自动化测试6】字典与集合知识总结 系列文章【Python自动化测试7】数据运算符知识合集 系列文章【Python自动化测试8】流程控制语句讲解 系列文章【Python自动化测试9】函数知识合集 系列文章10：【Python自动化测试10】文件基础操作 系列文章1【Python自动化测试11】模块、包与路径知识合集 系列文章1【Python自动化测试12】异常处理机制知识合集 系列文章1【Python自动化测试13】类、对象、属性与方法知识合集 系列文章1【Python自动化测试14】Python自动化测试基础与进阶练习题 系列文章1【Python自动化测试15】unittest测试框架的核心概念与作用 系列文章1【Python自动化测试16】测试用例数据分离 系列文章1【Python自动化测试17】openpyxl二次封装与数据驱动 系列文章1【Python自动化测试18】配置文件解析与实际应用 系列文章1【Python自动化测试19】日志系统logging讲解 系列文章20：【Python自动化测试20】接口自动化测试框架模型搭建
接口概念
项目简介
该项目是一个Web管理后台，有基础信息、用户操作、邮件管理、订单管理等多个模块，在项目实战中，尽可能以最简单、最高效的方式讲解到最深层次的内容，让大家能够充分理解该项目，以及如何使用实战所讲解的内容应用到自己公司或是私人项目当中。
该项目拥有一份详细的接口文档，文档中包括对应的请求头、请求体、请求方式、请求参数、成功示例反馈等内容，包括全后台的所有模块，均拥有对应详细的接口信息，在实践过程中，笔者会根据具体情况截、梳理、汇总，如下只展示其中一个接口作为示例
自动化测试流程讲解
全自动化测试流程
我们搭建框架很显然是为了进行自动化测试的，包括但不限于接口自动化、Web自动化、App自动化，UI自动化测试等等方式，有一部分和功能测试会比较相似，各个公司上可能也会存在差异，但大体不变，现在来介绍下自动化测试的流程：
'''
第一步：需求评审 -- 自动化测试同功能测试，第一步都需要进行需求评审，评审期间熟悉需求，找到需求缺陷，以此为需求分析做好铺垫
第二步：需求分析 -- 需求分析阶段主要是自动化测试人员单独对需求进行分析，进行需求拆解，详细理解需求，为测试用例的设计做好铺垫
第三步：接口文档 -- 熟悉需求后知道大概要负责的内容，在接口自动化测试阶段就需要了解接口文档，有哪些参数，请求头、请求体、请求方式、请求参数等
如果公司没有接口文档，通常去找开发询问，让开发给一份文档，如果还是无果，需要自己通过抓包的方式获取接口并梳理成文档
第四步：测试计划 -- 大致梳理你个人的测试计划，用例设计需要的时间，什么时候设计，预计什么时候能够测试通过，哪个环节是否采用自动化技术
考虑测试的优先级等，如果你是对应的测试负责，还需要考虑任务的人力分配等问题
第五步：计划评审 -- 当你梳理出一个计划后，还要与小组成员进行确认讨论，查看计划是否存在文档，是否有可改进的地方，关于小组成员是否对此有一些疑问
第六步：测试用例 -- 熟悉需求和接口文档后且拥有了测试计划，那么就到了测试用例的设计环节，设计接口自动化的测试用例
第七步：用例评审 -- 接口测试用例设计完成后进入用例评审阶段，确认测试用例中是否有遗漏，是否不规范，是否便于自动化的读取、使用等
第八步：用例执行 -- 通过接口自动化测试用例来进行代码的编写及梳理，在此期间可以搭建测试框架或在此之前已经拥有了一个框架执行即可
第九步：测试报告 -- 当执行完成测试用例后，即可输出对应的测试报告结论，同业务，包括质量情况、问题分布，
第十步：集成部署 -- 当测试框架搭建完成后并且能够顺利的执行测试用例，产出对应的测试报告时，考虑进行集成部署，通过定时任务，按周或按月冒烟执行
'''
测试金字塔
测试金字塔主要分为三个阶段，最底层是单元测试/组件测试，也就是代码相关的检查测试，但因国内敏捷开发以及测试能力的限制，故此在大多数的公司测试并不会进行单元测试，往往在此阶段是由开发进行自测完成。
金字塔的中间层是API方面的测试，也就是接口相关的测试，接口测试没有单元测试更加专业，但可以发现手工测试中无法发现的异常和问题。
最上层是用户界面上的测试，也可以理解为手工测试，手工测试仅能发现一些表层次问题，但大多数的需求仅通过表层的功能测试也能够防止绝大多数问题的产生，也是非常重要的一环，越靠近上层的测试，越能够接近业务层面的内容，也能够明显的反映出真实的需求。
不仅如此，越靠近金字塔的底端测试方式效率更高、缺陷更容易被定位、测试成本更低，而越靠近金字塔的顶端，则修复效率越慢，成本更高且缺陷更不容易被定位，这也是为什么测试需要尽早介入的原因。
什么样的项目适合进行自动化测试？
我们知道自动化测试能够提升工作效率，虽说如此，但什么情况下都适合做自动化吗？显然并不是的，只有符合下列条件的情况下，笔者认为更适合做自动化测试：
'''
符合下列条件，更适合做自动化测试工作：
1、需求文档，不会频繁变更需求 -- 在不变更需求的情况下，功能模块相对稳定，脚本编写后无需花费大量的时间修改及维护
2、研发和测试周期长，需要频繁进行回归测试、冒烟测试 -- 例如每周的模块进行冒烟测试，频繁的出现某一个运营活动
3、需要在多种平台上重复运行多个测试场景
4、某些测试项目的测试内容通过功能测试无法实现，或功能测试非常耗时
5、被测系统的开发较为规范，能够保证系统的可行性
'''
自动化测试工程师还要做功能测试吗？
有部分同学在面试自动化测试工程师之后负责人还会让他继续做功能测试，他也很奇怪，表示迷茫？自动化测试工程师还需要做功能测试吗？ 答案很明显是需要的，一个自动化的测试人员在进行自动化测试前必定是需要熟悉业务的，而熟悉业务的最佳方式就是先做一些功能测试或体验测试的内容，快速帮助自动化测试人员来熟悉业务，以便更好的测试。
好啦~以上就是本次文章分享的全部内容啦，你学会了吗？希望能给大家带来帮助哦！
文章为作者独立观点，不代表股票交易接口观点
股民评论