接口自动化

接口自动化

接口自动化

背景：

如果通过手工测试人员进行手动测试，不仅会浪费大量的人力、物力、资源等信息，而且对产品的测试程度相对来说比较低。因此，测试用例的自动化，即接口自动化（俗称：冒烟测试）显得尤为重要。

什么是接口自动化？

接口自动化，其基本原理就是：模拟前端向后台发送框架allure 报告生成库断言库 except超时重试库 tenacity

pytest的主要特性 —— fixture：

依赖注入的思想

fixture  scope：提供了多级缓存，每级缓存对应着不同的有效领域 。[ session,  moudle,  class,  function ]即：

session 对全局生效，即该 fixture 每次执行测试只会运行一次，用来生成全局的资源。（例如：添加集群或可用区等）moudle 对模块生效，每个模块执行一次class 对类生效，每个类执行一次function 对方法生效，每个用例执行一次

代码层次结构：

项目C - （主要功能：构造一个请求，将该请求发送到后台接口，并将响应的数据返回。通常情况下，我们不会修改其中的方法，除非开发修改了接口。该项目是和开发的接口一一对应的，承载了所有系统暴露出的接口。是与开发代码之间的唯一接口）项目B - （因为项目D的功能很单一，仅仅是实现发送请求和接收数据，因此在项目C中需要做很多的数据处理、超时重试、案例步骤关联等操作机制，这样做的目的是：使得测试用例开发起来相对来说比较简单，公共的方法都抽取出来，便于维护）项目A - 这个一个测试用例的实现模块，这里还细分为测试用例和配置层。测试用例都写在 xxx_test 文件中，包含用例的各个步骤；此外还有一类文件叫conftest，一些公共的fixture写在里面。项目D - 是一个公用的工具库，一些对系统后台的操作和对数据库的操作工具都在这里面。该项目D是独立的，不依赖于其他的工程。同时，它可以供其他多个工程使用，如果没有满足的工具，可以自己添加到项目D里面。

以小见大：

写用例首先要将用例的前置条件、执行过程、期望结果写到注释中；allure会根据注释直接在页面中生成报告，方便用例和错误的查找。同时在写用例的过程中也省去了来回切换，查看用例的过程，提高了工作的效率。拿到一个用例之后进行分析，分解出一个个步骤，这里的步骤正对应着allure.step，写的过程结构清晰，可读性好，而且报告中也会根据step来生成。有的时候多个用例会用到同一个方法，这种情况我们最好把公用的写到fixture中，fixture功能是非常强大的，这样可以大大节省了时间，提高效率。

番外——api代码常见问题总结【注意事项】：

可调试性

日志或者调试信息不清晰，无法告知问题原因；该记录日志的地方不记录日志，或者有日志但不打印异常，出问题不好查；断言不添加描述信息，不利于查问题和后期维护

维护性

函数参数、返回值无类型描述；或者类型描述不具体，没多少意义，例如：字典的类型描述应该要说明key和value的类型；易调整的、有测试需要的常量应该要提取为运行参数，例如：像外部配置的路径应该要作为运行参数，以方便打桩测试或者环境迁移；函数抽象与重用，例如：有时候需要某个接口里的一部分功能或者逻辑，有些人会倾向于把代码拷贝过来改改，这样久了就会有很多相似的代码。一般比较好的做法应该是把旧接口进行抽象，或者从旧接口里提取功能子集做为新接口

协程

网络IO需要协程化，避免阻塞主线程；磁盘IO需要协程化，避免阻塞主线程；内部用多线程、多进程实现的协程接口，要通过锁或者信号量限制并发

异常

异常考虑缺失 [json.dumps接口会抛出TypeError异常；json.loads接口会抛出JSONDecodeError异常]；异常捕获范围太粗，容易掩盖问题；异常导致的资源泄露

其他

异常分支要考虑好对全局的影响，必要时要填充默认值来防止错误扩散；对变量为None的可能没判断好就直接使用；内部实现暴露给用户

ps：感谢过程中小伙伴的指导，如果从菜鸟到老鸟是一段必经之路，我希望能够一直刻骨铭心。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。