pytest接口自动化（三）—— 优秀的脚本规范

　　上一篇 给大家讲了单接口脚本和多接口脚本，这一篇给大家讲讲个人对接口自动化的一些理解和看法。

　　从整个软件自动化测试来说，接口自动化从公司规模，测试效率，测试成本，可执行性，稳定性等来说，都是任何一个公司的测试人员首选的测试方式。接着我们来详细的说下。

　　对于任何一个公司（软件类）来说，测试部门都是一个不能直接创建利益的部门，所以在公司的运营上，测试部门能省则省，最近这些年测试部门才被重视起来。尽管这样，每一个公司还是希望在测试部门甚至在整研发部门上提高效率，节省成本。那么自动化，CICD自动打包部署等就是最好的选择。

　　对于任何一个软件来说，UI可变，功能可变，前端的载体可变，研发团队人员可变，唯一不怎么会变动的就是接口，就算功能没了，接口也会保留，这是因为需要兼容以前的版本，通常是保留的。再者，对于接口来说，只有地址、参数和调用方式（国际通用）。以上的这些都可以说明一点，接口从本质上说是相对稳定的，也说明接口具备了自动化的一个先天的优势。

　　那么测试效率从何说起呢，再没有接口自动化的时候，我们会使用jemete, soupUI, httprequest，或是浏览器的代码检查模式去接口我们的接口是否调用成功，参数是否完整。相同的接口，测试人员都要投入时间去填写地址，填写参数，选择调用方式，有一环出现问题，都会影响接口的测试。别个几个接口测试测试，问题不大，当一个很大的系统设计到上百个接口时，测试的效率就非常的低了，而且出现的漏测，误测的概率就很高。当使用接口自动化后，最大的问题就是前期编写接口测试脚本，调试脚本。一旦这部分的工作完成，那后面的接口测试工作将会非常的顺利，每一个版本只要在每个阶段在对应的环境上批量执行下接口自动化的脚本命令，就能得到想要的结果。接口越多的系统，接口自动化提升的效率就很大，人力成本就会降的越低。

　　可执行性，由于接口的稳定，各个版本对于接口的改动的工作量小，接口自动化脚本从设计、编写、调试优化完成后，后面的工作基本就是执行批跑命令和一些简单的调整。出现的问题基本都是很容易定位的，比如:  接口出现大批量报错失败，那一定是服务器宕机了或者网络出现了问题；出现个别接口报错，那基本是新的需求对此接口做了变动，增加或减少了参数。

　　从以上的结论，我们就可以得出为什么接口自动化从公司规模、测试效率、测试成本、可执行、稳定性等来说，都是任何一个公司的测试人员首选的自动化测试方式。当然了，接口自动化脚本与脚本之间也是有很大的区别的，一个规范的，优秀的脚本，可以大大的缩短执行的时间，减少调整的成本。

　　那么，什么是规范的，优秀的脚本？

　　1.  一定是有一个非常清晰，明确的目录结构，什么脚本放什么文件都是固定的。而不是每个人都有自己的想法，随意的创建专属的脚本文件夹；

　　2.  使用频率高、通用的脚本，模块一定要封装成可调用的方法存放在专门的文件夹中；

　　3.  任何使用频繁的数据，会多次使用的数据、Code，一定要存放在专门的文件中并参数化；只有使用一次或极少量的数据才可以放在用例脚本中;

　　4.  实际接口用例脚本中

　　　 ⑴  脚本执行前后，必须要对脚本中使用的数据、网络、数据库等做恢复，确保此脚本执行不会影响到其他的脚本执行，做到有始有终。setup、teardown的概念。

　　 　⑵  测试用例中的脚本，应该是简单易懂，一个步骤对应一个脚本，重要的步骤应该有对应的注释。

　　　 ⑶  测试用例的脚本中，应该尽量少的使用常量、if ... else的判断语句，每一个测试用例的脚本所要检测的结果应该都是明确的。

　　　 ⑷  每一个测试用例的脚本都应该是独立的，不会影响到其他用例脚本的执行或是脚本的批量执行。当然接口自动化，通过使用fixture中scope参数来控制。尽量不要使用pytest-ordering来设置每个用例的　　执行顺序。

　　　 ⑸  测试用例脚本的命名，参数的命名应已实际接口的名称、参数的名称来命名，这样会很直观，也便于查找。

　　　 ⑹  一个接口自动化脚本内应该有通过的脚本、重要参数的枚举、返回异常的code及对应的message的检查。可以在一个class类中，使用多个def来解决，每一个def表示该接口的一个场景。这些场景建议在写此接口时，就编写完，调试完成。为什么这么说，因为人都有惰性，往往说后面会补的，基本上都会因为其他的测试任何的原因而遗忘。