一、Android App API接口測試
1.如何學好Android App API接口測試
postman可以用來實現API接口自動化測試，但是也有弊端，無法實現接口測試數據的參數化，為了達到接口測試數據的參數化，可以通過python腳本應用DDT的框架來實現。
2.什么是API
下面是用圖來說明客戶端和服務端“發送請求--接受請求”的過程
3.抓包神器Fiddler簡介
使用Fiddler的兩個場景，1：客戶端對服務端返回數據的容錯；2：服務端對異常請求數據的處理。
以下是需要做的准備和要掌握的知識點
4.Fiddler抓包原理解析
打開tools-->Fiddler Options--Https/Connections，分別按下圖勾選：
配置好了之后，File-->exit退出Fiddler再重新啟動。
Fiddler 是以代理web服務器的形式工作的，它使用代理地址:127.0.0.1，端口:8888。當Fiddler退出的時候它會自動注銷，這樣就不會影響別的程序。不過如果Fiddler非正常退出，這時候因為Fiddler沒有自動注銷，會造成網頁無法訪問。解決的辦法是重新啟動下Fiddler。Fiddler原理圖：
5.Fiddler修改客戶端發出的請求
Fiddler設置斷點修改Request有兩種方式：1.通過工具欄設置斷點；2.通過命令設置斷點。
方式1：通過工具欄設置斷點。
Rules-->Automatic Breakpoints-->Before Requests；設置之后，Fiddler會攔截到所有發送給服務器的請求。
接下來要做的演示是：1.打開谷歌（www.google.com.hk），輸入查詢詞“mook”；2.點擊搜索；Fiddler要完成的任務是在瀏覽器發送查詢詞“mook”給服務器之前，把查詢詞修改為“test”。從下圖可以看到此時發出的請求被Fiddler攔截了，接下來點擊session，點擊下圖框中的“Run to Completion”。
如圖2，會新彈出一個session，修改此session下"WebForms"中的“mook”為“test”；然后再點擊“Run to Completion”，到此請求已經執行完成了，搜索關鍵詞已經由“mook”變為“test
”，可以通過查看當前瀏覽器的效果（圖3）驗證是否成功。
另外，可以看到用這種方式會攔截所有的請求，而我們所需要測試的站點只是“www.google.com.hk”，想要做到只測試某個站點，可以采用第二種方式：通過命令設置斷點。
方式2：通過命令設置斷點。
在命令行中輸入“bpu www.google.com.hk”，回車（如圖4），然后可以看到在底部出現如圖5框中的信息，這時就做到了只針對“www.google.com.hk”站點進行攔截（可以打開一個其他的網址查看，其他的網址是可以成功訪問的）。以上可以看出，通過命令設置斷點可以做到針對某個站點進行攔截，也就是方式2的好處所在。當想要撤除斷點時，可以在命令行中輸入“bpu”，回車，來完成撤除。
6.Fiddler修改服務器端返回的內容
Fiddler設置斷點修改Response有3種方式：1.通過工具欄設置斷點；2.通過命令設置斷點；3.AutoResponse設置。
方式1：通過工具欄設置斷點。
Rules-->Automatic Breakpoints-->After Responses；設置之后，Fiddler會攔截到所有服務器返回的響應。
接下來要做的演示是：1.打開谷歌（www.google.com.hk），輸入查詢詞“mook test”；2.點擊搜索；Fiddler要完成的任務是在服務器發出響應之后把查詢詞修改為“test”。從下圖可以看到此時返回的響應被Fiddler攔截了，接下來點擊session，點擊下圖框中的“Run to Completion”。
此時瀏覽器中的tittle已經變成了“test”，說明剛才的修改已經生效了。
方式2：.通過命令設置斷點。
在命令行中輸入“bpafter www.google.com.hk”，回車。然后在瀏覽器中執行搜索“mook test”，點擊session，刪除服務器返回的所有內容，輸入“mook test”，點擊下圖框中的“Run to Completion”，此時再查看瀏覽器，返回的所有內容就是“mook test”。當想要撤除斷點時，可以在命令行中輸入“bpafter”，回車，來完成撤除。
方式3：AutoResponse設置
在瀏覽器中輸入“mook test”並搜索，完成正常的搜索過程；點擊session，按下圖所示，選中AutoResponder並勾選下方三個選項，然后點擊“Add Rule”選擇匹配方式，這里默認是“EXACT...”精確匹配，如果兩個請求完全相同，那么這個規則生效，由於此次請求內的內容很長（如圖6所示），就可能會出現“兩次不匹配的情況”，解決的辦法是選擇模糊匹配（正則表達式）的方式，修改的規則是正則表達式的內容可以唯一匹配要攔截的請求，這里修改為“regex:(?inx)^https://www.google.com.hk/serah?.+”，因為所有session中只有我們要攔截的session才包含正則表達式中的內容，“.+”的作用是連接多個符號（如圖7），然后選擇返回狀態“404_Plain.dat”，然后點擊“Save”。
此時刷新瀏覽器，可以看到如圖8所示的結果，證明本次的攔截成功了。
這是Fiddler提供的默認的返回內容，如果想自定義返回內容該怎么辦呢？如圖9，選擇“Find a file”，選擇一個實現編輯好的文件（txt，如圖10），然后點擊“Save”。
此時刷新瀏覽器，可以看到如圖11所示的結果，證明本次的攔截成功了。
通過以上3種方式，我們就可以測試當服務器返回異常數據時，客戶端的穩定性。
7.Fiddler實現會話的過濾、對比及請求的編解碼
7.1，會話的過濾
在瀏覽器中執行多次請求，session區域會有大量的請求，如果想過濾出“www.baidu.com”的請求，可以通過圖12所示的方式來完成。
7.2，會話的對比
Ctrl鍵選中兩個session，右鍵選擇如下圖中的“Compare”，對比的結果如圖13所示，用“標紅”、“標黃”的方式來表明兩個session的差異。
7.3，請求的編解碼
選擇一個sesion，點擊Tools-->TextWizard，彈出如下圖14的窗口，其中‘...Decode’是解碼，‘...INcode’是編碼，圖中將發送的請求中的“mook+test”解碼為“mook test”，而“mook test”正是我們所搜索的內容。
8.Fiddler實現Host的配置
方法：Tools->HOSTS，按下圖15勾選，並點擊藍色鏈接，就可以在窗口中設置host了。
9.Fiddler構造HTTP GET請求
舉例：構造一個在www.google.com.hk中搜索“mook”的請求；步驟：1.在瀏覽器中搜索“mook”，2.在回話中找到這個請求的session，復制圖16中綠色框中的請求的頭部信息（header），3.如圖17，請求區域選擇“Copmoser”，把紅色框中的內容復制到綠色框中（注意去掉尾部的協議“HTTP/1.1”），4.修改綠色框中url的關鍵字，5.點擊棕色框中的“Execute”按鈕；至此完成了本次HTTP GET請求的構造。
10.Fiddler構造HTTP POST請求
舉例：構造如圖18中登陸的一次post請求。步驟：1.復制圖19中的header信息，2.切換到“Copmoser”，粘貼到綠色框中，然后把圖20中的紅色框內容剪切到“Request Body”中，修改header中的內容，最終如圖21所示，點擊“Execute”按鈕，結果如圖22所示，證明我們成功的構造了一次post請求。
很多時候，需要修改post請求中的參數，可以在“Copmoser”中的“Request Body”內修改。
11.Fiddler抓取手機上的網絡數據包
設置環境：1.配置Fiddler允許監聽https，2.配置Fiddler允許遠程連接，3.手機端設置代理服務。
Fiddler上的設置如前文中“4.Fiddler抓包原理解析”，手機上的設置如圖23，其中“代理服務器主機名”為fiddler所在電腦的ip地址，“代理服務器端口”為8888。經過這樣的設置之后，手機上所有訪問網絡的請求都會轉發到fiddler，然后再由fiddler轉發給后端服務。
上文中提到的客戶端為pc瀏覽器時Fiddler的應用，在客戶端為手機app時也同樣適用。
接下來演示一下如何使用“AutoResponder”來修改服務器返回給app端的內容，通過這樣的修改可以模擬各種異常數據返回給app端，從而驗證app端的容錯情況。步驟：1.選擇一個session，在服務端返回的Response中找到一個在app上可以明顯被看到的內容，如圖24中的“談姐弟戀的，原來都是這樣的女人”，2.點擊圖24中的綠框，彈出編輯窗口，修改“談姐弟戀的，原來都是這樣的女人”為“談姐弟戀的，原來都是這樣的人”（如圖25），保存txt文檔。3.切換到“AutoResponder”，再次選中圖24中的session，選擇模糊匹配規則，並把步驟2中保存的txt文檔導入到如圖26中的綠色框中，點擊svae，4.清除所有session，退出APP，再重新啟動，此時我們可以看到之前修改過的返回內容已經生效了。
那么，使用fiddler抓取手機包有哪些優點呢？
1.無需root權限；2.Android&IOS都適用；3.操作簡單、界面清晰。
12.為什么使用PostMan做API接口測試
既然已經有很好用的fiddler工具了，為什么還需要用PostMan呢？因為在做API接口測試時，會遇到以下的問題：
1.后端服務的提測時間要早於客戶端，很難去構造測試需要的請求；2.很難用客戶端模擬異常請求；3.Fiddler的Composer無法實現自動化驗證。
而PostMan能夠彌補以上的問題，那么PostMan能夠應用於哪些產品呢？PostMan的適用范圍：1.PC；2.WAP（無線）；3.APP。
13.PostMan測試HTTP GET請求
步驟:1.啟動app,通過fiddler獲取一個get請求（如圖28），2.啟動postman，在fiddler中選中步驟1中的session，右鍵copy出url，3.copy出header部分，點擊Send。
如圖30，得到了本次請求的返回值，這樣我們就可以在發送請求后對返回值進行校驗；步驟:1.選中Request區域的Test，再選擇右側驗證方法中紅色框住的“Response body:contains string”（驗證返回值中是否包含哪些內容），把返回值中的數據copy到綠色框中（兩個參數間用&&連接），點擊Send，如圖31，Response區域的Test中新增了一個Pass記錄，說明本次對返回值的校驗通過了。以上也就是對Request設置檢查點。如果想在回歸測試的時候再次執行這次請求的話，可以把這次請求保存到Cellection中（如圖32）。
自動執行一個Cellection中的所有Request
方法：1.如圖33，點擊Cellection上的“箭頭”，點擊“Run”；2.如圖35，彈出一個新的窗口，在新的窗口中點擊“Start Test”，此時就會自動執行Cellection中的所有請求，另外，還可以設置執行Cellection的循環測試和延時。這就是postman帶來的好處：可以收集請求，在需要的時候可以批量的的執行請求。
14.PostMan測試HTTP POST請求
步驟:1.啟動app,通過fiddler獲取一個post請求（如圖35），2.啟動postman，在fiddler中選中步驟1中的session，右鍵copy出url，3.copy出header部分(如圖36)，4.post請求和get請求的最大區別就在於post請求中包含body，在fiddler請求區“Inspectors”中找到“webForms”，把“body”中的內容也逐一復制到postman的請求區的body中（注意選擇第二個選項“x-www-form-urlencoded”），至此一個post請求就構造完成了；點擊Send。
同樣的，也可以對post請求的返回值進行驗證；如圖39，postman返回數據選擇“Raw”，校驗方法和結果同get請求，就不多介紹了。
15.數據驅動DDT實現API接口自動化測試簡介
以上，我們認識到postman會在回歸測試當中幫我們節省很多的人力，那既然postman這么好用，為什么我們還要把數據驅動應用在API接口測試中呢？這是由於我們測試的內容是API接口，在測試的過程中需要輸入大量的參數和不同的數據值，如果使用postman去完成的話，需要不斷地構造各種請求，而構造各種請求的過程其實是很耗時的，如果我們把這一個過程就腳本的方式去實現的話，會變得更加簡單高效。
既然決定要通過腳本的方式去實現，首先就需要選擇一種技術去支持我們來完成這樣的實現。使用Python requests模塊來實現腳本的自動化，之后我們就可以寫出HTTP GET/POST請求的腳本，並且利用DDT將腳本實現參數化。
16.Python requsts測試HTTP中的GET、POST請求
代碼構成;1.首先代碼中引入requests模塊和unittest框架；2.TestCase中用字典的形式配置herder、cookies和get/post請求部分。
17.數據驅動DDT實現API接口自動化測試實戰
以上我們已經實現了get、post腳本，下面來把兩條腳本實現參數化，那么如何參數化呢？使用數據驅動的方式。
代碼構成;1.引入ddt模塊；2.ddt.ddt修飾TestCase；3.ddt.data設置不同的參數集合；4.測試類中引入參數化的device_id；5.修改請求中的device_id。
如圖46，4次執行的結果都pass了，一般情況下，device_id是“空”時，服務器應該返回一個定義好的狀態碼。也就是說本次測試發現了一個服務器對非法數據處理的設計缺陷。
