做接口测试的流程一般是怎么样的？

lsekfe

目前大多数的公司招聘测试，几乎都要求应聘者能够会接口测试，几乎成了一种趋势，大多数的要求是会主流的测试工具，如PostMan，Jmeter和SoupUi等工具，再高一个层次的，要求会HTTP的应用层协议和编程语言，也有对微服务的测试经验和接口测试框架设计能力的要求。不得不说，这是一个趋势，这源于开发模式的改变，另外一种情况是市场的变化不得不让企业在另外一个维度来思考问题，那就是“快”，快速的推出产品上线，快速的满足客户的要求等等，总之这一切的结果是不仅仅要快，而且产品的质量要好。这对测试来说是一个非常大的挑战，如何能够适应这个快的节奏，并且让产品上线后能够满足市场的要求。
　　所以很多的时候，测试要面对很多不合理的情况，比如上线时间是确定的，但是开发晚转测了，开发占用了测试的时间，但是测试不能占用上线的时间，不能上线，那就要求加班等等。当然这中间涉及很多的管理的问题，以及一个公司流程化的问题。或者说，是要求更快，还是更加重视客户的价值。大多数的时候，鱼和熊掌是不可兼得的，但是在这样的一个形式下，好像鱼和熊掌必须得兼得。所以就有了自动化的测试以及自动化的运维。
　　那么既然说到自动化的测试，UI的自动化测试不适合刚才说的这种快速发展的节奏，也无法满足条件。测试应该把更多的精力放在接口自动化测试中，以及各种微服务的测试中和契约测试中。对微服务的测试，测试要做到每个微服务内部的正确性（特别是业务逻辑和业务流程），以及每个微服务组件之间连接的正确性，或者更加通俗的说要测试到端到端流程的正确性和逻辑的正确性。
　　当然对于API的测试，本人在其它的文章中专门有说到接口测试的四个维度，但是我最推荐也是最看重的就是通过接口测试的技术来测试产品的业务逻辑和业务流程，那么如果把这些覆盖的测试点越来越多，对提升测试效率以及研发效率是非常重要的，作为IT的基础部门，首先是要保障的是产品的业务流程，如果我们通过接口测试的技术把产品的业务流程涉及的测试点覆盖到60%至80%之间，那么也就只有剩余的20%至40%的测试点需要手工的方式去验证，当然这个覆盖点还可以继续开展和延伸，接口测试的执行速度是非常快的，也就几分钟的结果出结果，意味着什么，意味着覆盖到的产品业务，几分钟就能够得出结论，得知这些覆盖到的产品质量的情况，这对集成测试，和UAT,ST以及生产环境的冒烟测试的帮助是非常大的。
　　设想这样一个场景，假设底层微服务修改了一个API，要求测试N个版本，并且必须是今天得出测试结论今天必须上线，如果不按照接口测试的方式，那么只能通过上层应用的产品来逐步的验证，N个版本把业务流程都测试一遍，问题是第一次测试业务流程感觉没什么，第二次，以及后面的第N次，人首先自己就感觉没多少意思，但是我们通过自动化测试技术的手段，只需要配置文件配置不同的版本执行就可以了，并且很快的出结果。当然，自动化不是万能的。
　　关于微服务，其实微服务它主要还是以应用层的协议HTTP等轻量级通信方式调用，这对我们做接口测试也是非常有利的，只是这涉及会涉及到异步调用以及其他的测试思路。契约测试更加看重的是服务见是否调用正确，以及服务者提供的功能是否满足别人的需求。
　　接口测试涉及的技术相对来说也是比较多，世界是复杂的，接口测试也是如此，理解它的本源，搞清楚它的内部原理，下来不管测试工具还是测试代码只是实现它的一种形式。建议可以看看《HTTP权威指南》，对HTTP的协议有非常详细并且很系统的介绍。