理解http协议（客户端和服务端的通信过程与接口的结构），对测试人员是非常重要的，理解了它就能知道怎么样去定位前后端问题，就能理解版本更新中为什么要后端先行，就知道以什么样的方式去保障旧客户端的兼容。这里，我们先来理解客户端和服务端的通信过程。

       大多数的应用程序/软件无非是C/S架构或B/S架构的一种，不管C/S架构还是B/S架构，客户端和服务端的通信过程都可以用以下示意图表示。

       首先，用户通过客户端向服务器发起请求（对应序号1的步骤），例如我们在手机登录的过程中，在输入手机号后，点击获取验证码，就是客户端向服务端发起请求。但在服务端接收到用户发起的请求前，用户提交的请求数据会先经由API接口（API全称Application Program Interface，即应用程序接口），API接口再将用户的请求数据给到服务端运算处理，服务端经过运算后，会对该用户在数据库中相关数据进行“增删改查”操作，然后把用户所需要的数据从数据库中取出来（例如正确的手机号验证码），再通过API接口返回给客户端，也即图中第5、第6步的响应过程。

       假如我们去餐厅吃饭，我们首先是通过服务员下单的，服务员再把我们点的菜通知给后厨，后厨炒好菜后再给服务员，然后服务员把菜给到我们。在餐厅点菜吃饭的过程中，我们就相当于客户端，服务员就相当于API接口，后厨就相当于服务端。

       理解了客户端和服务端通信的这个过程，我们就能理解为什么在定位前后端问题时，接口那么重要了。简单地讲，当软件出现Bug后，假如Bug是在请求前或请求本身出现错误，那大概率是前端问题；假如客户端提交的请求是正确的，但服务端的响应结果是错误的，那大概率就是后端问题（注：通过接口的请求和响应大概率可以定位出是前端问题还是后端问题，但具体情况还要具体分析，例如前端传递的请求query参数前端认为是正确的，但后端其实没有该请求参数，使用的是另外的参数名来实现对应的功能，这种情况就是前端问题了）。

       在理解C/S架构、B/S架构的基础上，为了进一步定位问题，我们还需要理解接口的结构。接口的请求示意图如下图所示。接口的结构可以分为请求和响应两个维度来理解。

       接口的请求（Request）包括：（1）请求地址，请求地址又包括网络协议（大多数是http或https）、baseUrl（服务器ip或域名，示意图中是122.51.4.96，服务器ip或域名是接口共用的、相同的）、接口地址（每个接口单独的地址，示意图中是loginfortest）；（2）请求方式，常用的请求方法有POST（新增数据）、GET（获取数据）、PUT（修改数据）、DELETE（删除数据）、PATCH（修改某条数据的某个字段）等，示意图中的请求方法是POST；（3）请求参数，也就常说的query参数。一般GET接口中会有请求参数，请求参数是附在接口地址后面的，例如GET "http://122.51.4.96/goods/?p=2”其中“?p=2”就是请求参数；（4）请求头，请求头一般会存放cookie、token等授权信息以及定义接口传输数据的格式（一般是Json或Xml格式）；（5）请求体。一般是POST、PUT、PATCH等接口会有请求体，请求体的数据格式就是请求头定义的数据格式，示意图中请求数据格式是Json，请求数据是{“username”:"testking","password":"123456"}。客户端经由接口发起请求后，服务端会对客户端的请求进行运算处理并响应（对应示意图中的7），响应数据在接口的返回体中（Response），格式也是由请求头定义的，示意图中服务端返回的是Json格式的token。并且，我们可以通过响应结果的状态码去判断接口是否响应成功。常见的响应结果状态码有200（成功）、401（未授权）、500（服务端错误）、404（没有该接口）等。

        以上就是接口的结构啦，为了方便大家理解，强烈建议大家一定要用真正的接口中去实操。本文提供了一个实操的接口，http://122.51.4.96/loginfortest/，也就是示例中的接口，大家可以用postman这个工具去调用测试一下（注：该接口的请求体中，用户名testking的密码已经修改了，虽然响应结果是401，不是200，但不妨碍大家测试接口调用）。

       我们再回到开头的问题，为什么版本更新要后端先行？怎么样去保障各版本迭代中的旧客户端的质量？第一个问题，为什么版本更新要后端先行？。我们知道，版本更新肯定是客户端和服务端都有代码修改的（废话，不然还更新个啥）。对客户端来讲，只需关注服务端的接口就行了，版本更新就意味着接口的更新。但需要注意的是，尽管接口更新了，之前版本的旧接口是不变的或服务端代码逻辑是兼容的，不然旧客户端肯定会奔溃的（假设旧客户端用户到fortestlogin的接口，服务端更新后没有了该接口，用户手机上的旧客户端能不奔溃吗？）。当前迭代版本测试通过后，我们知道最新的服务端既能兼容最新客户端也能兼容旧客户端，因此版本更新时，后端先行是不会有问题的。相反，我们假设后端先不更新，客户端先更新，这就极可能出现新客户端所使用到的新接口，旧服务端没有，这种情况客户端肯定也是会奔溃的，版本更新中客户端先更新是不可取的，要服务端先更新。

       第二个问题，怎样去保障各版本迭代中的旧客户端的质量？当一个又一个迭代运作起来后，客户端也会在生产环境中发布一个又一个版本，我们不可能每个迭代在各个旧客户端中手工测试去验证是否有bug、是否兼容旧客户端。推荐的方法是通过接口自动化来达到维护旧客户端质量的目的。理解了客户端和服务端的通信以及接口，我们其实就知道，要保障旧客户端的质量，只要保障旧接口的质量就行啦（当然，旧客户端和旧接口本身的Bug是另外一回事，属于测试不周密导致的线上历史Bug）。而要保障旧接口的质量，参考的做法是通过接口自动化来实现（我们同样不可能去手工单点测试每个旧接口，如果这么做，就跟在各个旧客户端上手工测试没区别了），接口自动化的实现方法很多，推荐的如Jemter+Ant+Jenkins + Git + 邮件服务器 API自动化或Python + Requests + Jenkins + Git + 邮件服务器 API自动化、httpRunner API自动化。接口自动化在此处不详细展开，同学可以自行网上查找资料学习或联系博主交流。