? ? ? ?理解客戶(hù)端和服務(wù)端的通信過(guò)程與接口的結(jié)構(gòu)，對(duì)測(cè)試人員是非常重要的，理解了它就能知道怎么樣去定位前后端問(wèn)題，就能理解版本更新中為什么要后端先行，就知道以什么樣的方式去保障舊客戶(hù)端的兼容。這里，我們先來(lái)理解客戶(hù)端和服務(wù)端的通信過(guò)程。

? ? ? ?大多數(shù)的應(yīng)用程序/軟件無(wú)非是C/S架構(gòu)或B/S架構(gòu)的一種，不管C/S架構(gòu)還是B/S架構(gòu)，客戶(hù)端和服務(wù)端的通信過(guò)程都可以用以下示意圖表示。

? ? ? ?首先，用戶(hù)通過(guò)客戶(hù)端向服務(wù)器發(fā)起請(qǐng)求（對(duì)應(yīng)序號(hào)1的步驟），例如我們?cè)谑謾C(jī)登錄的過(guò)程中，在輸入手機(jī)號(hào)后，點(diǎn)擊獲取驗(yàn)證碼，就是客戶(hù)端向服務(wù)端發(fā)起請(qǐng)求。但在服務(wù)端接收到用戶(hù)發(fā)起的請(qǐng)求前，用戶(hù)提交的請(qǐng)求數(shù)據(jù)會(huì)先經(jīng)由API接口（API全稱(chēng)Application Program Interface，即應(yīng)用程序接口），API接口再將用戶(hù)的請(qǐng)求數(shù)據(jù)給到服務(wù)端運(yùn)算處理，服務(wù)端經(jīng)過(guò)運(yùn)算后，會(huì)對(duì)該用戶(hù)在數(shù)據(jù)庫(kù)中相關(guān)數(shù)據(jù)進(jìn)行“增刪改查”操作，然后把用戶(hù)所需要的數(shù)據(jù)從數(shù)據(jù)庫(kù)中取出來(lái)（例如正確的手機(jī)號(hào)驗(yàn)證碼），再通過(guò)API接口返回給客戶(hù)端，也即圖中第5、第6步的響應(yīng)過(guò)程。

? ? ? ?假如我們?nèi)ゲ蛷d吃飯，我們首先是通過(guò)服務(wù)員下單的，服務(wù)員再把我們點(diǎn)的菜通知給后廚，后廚炒好菜后再給服務(wù)員，然后服務(wù)員把菜給到我們。在餐廳點(diǎn)菜吃飯的過(guò)程中，我們就相當(dāng)于客戶(hù)端，服務(wù)員就相當(dāng)于API接口，后廚就相當(dāng)于服務(wù)端。

? ? ? ?理解了客戶(hù)端和服務(wù)端通信的這個(gè)過(guò)程，我們就能理解為什么在定位前后端問(wèn)題時(shí)，接口那么重要了。簡(jiǎn)單地講，當(dāng)軟件出現(xiàn)Bug后，假如Bug是在請(qǐng)求前或請(qǐng)求本身出現(xiàn)錯(cuò)誤，那大概率是前端問(wèn)題；假如客戶(hù)端提交的請(qǐng)求是正確的，但服務(wù)端的響應(yīng)結(jié)果是錯(cuò)誤的，那大概率就是后端問(wèn)題（注：通過(guò)接口的請(qǐng)求和響應(yīng)大概率可以定位出是前端問(wèn)題還是后端問(wèn)題，但具體情況還要具體分析，例如前端傳遞的請(qǐng)求query參數(shù)前端認(rèn)為是正確的，但后端其實(shí)沒(méi)有該請(qǐng)求參數(shù)，使用的是另外的參數(shù)名來(lái)實(shí)現(xiàn)對(duì)應(yīng)的功能，這種情況就是前端問(wèn)題了）。

? ? ? ?在理解C/S架構(gòu)、B/S架構(gòu)的基礎(chǔ)上，為了進(jìn)一步定位問(wèn)題，我們還需要理解接口的結(jié)構(gòu)。接口的請(qǐng)求示意圖如下圖所示。接口的結(jié)構(gòu)可以分為請(qǐng)求和響應(yīng)兩個(gè)維度來(lái)理解。

? ? ? ?接口的請(qǐng)求（Request）包括：（1）請(qǐng)求地址，請(qǐng)求地址又包括網(wǎng)絡(luò)協(xié)議（大多數(shù)是http或https）、baseUrl（服務(wù)器ip或域名，示意圖中是122.51.4.96，服務(wù)器ip或域名是接口共用的、相同的）、接口地址（每個(gè)接口單獨(dú)的地址，示意圖中是loginfortest）；（2）請(qǐng)求方式，常用的請(qǐng)求方法有POST（新增數(shù)據(jù)）、GET（獲取數(shù)據(jù)）、PUT（修改數(shù)據(jù)）、DELETE（刪除數(shù)據(jù)）、PATCH（修改某條數(shù)據(jù)的某個(gè)字段）等，示意圖中的請(qǐng)求方法是POST；（3）請(qǐng)求參數(shù)，也就常說(shuō)的query參數(shù)。一般GET接口中會(huì)有請(qǐng)求參數(shù)，請(qǐng)求參數(shù)是附在接口地址后面的，例如GET "http://122.51.4.96/goods/?p=2”其中“?p=2”就是請(qǐng)求參數(shù)；（4）請(qǐng)求頭，請(qǐng)求頭一般會(huì)存放cookie、token等授權(quán)信息以及定義接口傳輸數(shù)據(jù)的格式（一般是Json或Xml格式）；（5）請(qǐng)求體。一般是POST、PUT、PATCH等接口會(huì)有請(qǐng)求體，請(qǐng)求體的數(shù)據(jù)格式就是請(qǐng)求頭定義的數(shù)據(jù)格式，示意圖中請(qǐng)求數(shù)據(jù)格式是Json，請(qǐng)求數(shù)據(jù)是{“username”:"testking","password":"123456"}?？蛻?hù)端經(jīng)由接口發(fā)起請(qǐng)求后，服務(wù)端會(huì)對(duì)客戶(hù)端的請(qǐng)求進(jìn)行運(yùn)算處理并響應(yīng)（對(duì)應(yīng)示意圖中的7），響應(yīng)數(shù)據(jù)在接口的返回體中（Response），格式也是由請(qǐng)求頭定義的，示意圖中服務(wù)端返回的是Json格式的token。并且，我們可以通過(guò)響應(yīng)結(jié)果的狀態(tài)碼去判斷接口是否響應(yīng)成功。常見(jiàn)的響應(yīng)結(jié)果狀態(tài)碼有200（成功）、401（未授權(quán)）、500（服務(wù)端錯(cuò)誤）、404（沒(méi)有該接口）等。

? ? ? ? 以上就是接口的結(jié)構(gòu)啦，為了方便大家理解，強(qiáng)烈建議大家一定要用真正的接口中去實(shí)操。本文提供了一個(gè)實(shí)操的接口，http://122.51.4.96/loginfortest/，也就是示例中的接口，大家可以用postman這個(gè)工具去調(diào)用測(cè)試一下（注：該接口的請(qǐng)求體中，用戶(hù)名testking的密碼已經(jīng)修改了，雖然響應(yīng)結(jié)果是401，不是200，但不妨礙大家測(cè)試接口調(diào)用）。

? ? ? ?我們?cè)倩氐介_(kāi)頭的問(wèn)題，為什么版本更新要后端先行？怎么樣去保障各版本迭代中的舊客戶(hù)端的質(zhì)量？第一個(gè)問(wèn)題，為什么版本更新要后端先行？。我們知道，版本更新肯定是客戶(hù)端和服務(wù)端都有代碼修改的（廢話(huà)，不然還更新個(gè)啥）。對(duì)客戶(hù)端來(lái)講，只需關(guān)注服務(wù)端的接口就行了，版本更新就意味著接口的更新。但需要注意的是，盡管接口更新了，之前版本的舊接口是不變的或服務(wù)端代碼邏輯是兼容的，不然舊客戶(hù)端肯定會(huì)奔潰的（假設(shè)舊客戶(hù)端用戶(hù)到fortestlogin的接口，服務(wù)端更新后沒(méi)有了該接口，用戶(hù)手機(jī)上的舊客戶(hù)端能不奔潰嗎？）。當(dāng)前迭代版本測(cè)試通過(guò)后，我們知道最新的服務(wù)端既能兼容最新客戶(hù)端也能兼容舊客戶(hù)端，因此版本更新時(shí)，后端先行是不會(huì)有問(wèn)題的。相反，我們假設(shè)后端先不更新，客戶(hù)端先更新，這就極可能出現(xiàn)新客戶(hù)端所使用到的新接口，舊服務(wù)端沒(méi)有，這種情況客戶(hù)端肯定也是會(huì)奔潰的，版本更新中客戶(hù)端先更新是不可取的，要服務(wù)端先更新。

? ? ? ?第二個(gè)問(wèn)題，怎樣去保障各版本迭代中的舊客戶(hù)端的質(zhì)量？當(dāng)一個(gè)又一個(gè)迭代運(yùn)作起來(lái)后，客戶(hù)端也會(huì)在生產(chǎn)環(huán)境中發(fā)布一個(gè)又一個(gè)版本，我們不可能每個(gè)迭代在各個(gè)舊客戶(hù)端中手工測(cè)試去驗(yàn)證是否有bug、是否兼容舊客戶(hù)端。推薦的方法是通過(guò)接口自動(dòng)化來(lái)達(dá)到維護(hù)舊客戶(hù)端質(zhì)量的目的。理解了客戶(hù)端和服務(wù)端的通信以及接口，我們其實(shí)就知道，要保障舊客戶(hù)端的質(zhì)量，只要保障舊接口的質(zhì)量就行啦（當(dāng)然，舊客戶(hù)端和舊接口本身的Bug是另外一回事，屬于測(cè)試不周密導(dǎo)致的線(xiàn)上歷史Bug）。而要保障舊接口的質(zhì)量，參考的做法是通過(guò)接口自動(dòng)化來(lái)實(shí)現(xiàn)（我們同樣不可能去手工單點(diǎn)測(cè)試每個(gè)舊接口，如果這么做，就跟在各個(gè)舊客戶(hù)端上手工測(cè)試沒(méi)區(qū)別了），接口自動(dòng)化的實(shí)現(xiàn)方法很多，推薦的如Jemter+Ant+Jenkins + Git + 郵件服務(wù)器 API自動(dòng)化或Python + Requests + Jenkins + Git + 郵件服務(wù)器 API自動(dòng)化、httpRunner API自動(dòng)化。接口自動(dòng)化在此處不詳細(xì)展開(kāi)，同學(xué)可以自行網(wǎng)上查找資料學(xué)習(xí)或聯(lián)系博主交流。