測試：接口和抓包測試

1.軟件開發的兩種結構

1.1、CS（Client/Server）：客戶端----服務器結構

 

 

　　C/S結構在技術上很成熟，它的主要特點是交互性強、具有安全的存取模式、網絡通信量低、響應速度快、利於處理大量數據。

　　CS 的優點：

• 能充分發揮客戶端PC的處理能力，很多工作可以在客戶端處理后再提交給服務器，所以CS客戶端響應速度快。

• 操作界面漂亮、形式多樣，可以充分滿足客戶自身的個性化要求。

• C/S結構的管理信息系統具有較強的事務處理能力，能實現復雜的業務流程。

• 安全性能可以很容易保證，C/S一般面向相對固定的用戶群，程序更加注重流程，它可以對權限進行多層次校驗，提供了更安全的存取模式，對信息安全的控制能力很強。一般高度機密的信息系統采用C/S結構適宜。

　　需要專門的客戶端安裝程序，分布功能弱，針對點多面廣且不具備網絡條件的用戶群體，不能夠實現快速部署安裝和配置。

• 兼容性差，對於不同的開發工具，具有較大的局限性。若采用不同工具，需要重新改寫程序。
• 開發、維護成本較高，需要具有一定專業水准的技術人員才能完成，發生一次升級，則所有客戶端的程序都需要改變。
• 用戶群固定。由於程序需要安裝才可使用，因此不適合面向一些不可知的用戶

1.2、BS（Browser/Server）：瀏覽器----服務器結構

 

 

　　是目前應用系統的發展方向。BS是伴隨着Internet技術的興起，對C/S架構的改進，為了區別於傳統的C/S 模式，特意稱為B/S模式。在這種結構下，通過W3瀏覽器來進入工作界面， BS的優缺點：

　　優點：

• 分布性強，客戶端零維護。只要有網絡、瀏覽器，可以隨時隨地進行查詢、瀏覽等業務處理。
• 業務擴展簡單方便，通過增加網頁即可增加服務器功能。

• 維護簡單方便，只需要改變網頁，即可實現所有用戶的同步更新。 

• 開發簡單，共享性強。

　　缺點：

• 個性化特點明顯降低，無法實現具有個性化的功能要求。 

• 在跨瀏覽器上，BS架構不盡如人意。

• 客戶端服務器端的交互是請求-響應模式，通常動態刷新頁面，響應速度明顯降低（Ajax可以一定程度上解決這個問題）。無法實現分頁顯示，給數據庫訪問造成較大的壓力。 

• 在速度和安全性上需要花費巨大的設計成本。

• 功能弱化，難以實現傳統模式下的特殊功能要求。

1.3、BS與CS優缺點對比

（面試題 / 筆試題）

　　CS響應速度快，安全性強，用戶體驗好，一般應用於局域網中，但是開發維護成本高，；BS可以實現跨平台，客戶端零維護，但是個性化能力低，響應速度較慢。所以有些單位日常辦公應用BS，在實際生產中使用CS結構。

2、HTTP 協議

2.1、什么是 http 協議：

　　HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。

　　HTTP是一個客戶端和服務器端請求和應答的標准

　　客戶端是終端用戶，服務器端是網站。

　　我們在瀏覽器的地址欄里輸入的網站地址叫做URL (Uniform Resource Locator，統一資源定位符)。就像每家每戶都有一個門牌地址一樣，每個網頁也都有一個Internet地址。當你在瀏覽器的地址框中輸入一個URL或是單擊一個超級鏈接時，URL就確定了要瀏覽的地址。瀏覽器通過超文本傳輸協議(HTTP)，將Web服務器上站點的網頁代碼提取出來，並翻譯成漂亮的網頁。

 

 HTTP之URL：

　　HTTP使用統一資源定位符（Uniform Resource Identifiers, URI）來傳輸數據和建立連接。URL是一種特殊類型的URI，包含了用於查找某個資源的足夠的信息

　　URL,全稱是UniformResourceLocator, 中文叫統一資源定位符,是互聯網上用來標識某一處資源的地址。以下面這個URL為例，介紹下普通URL的各部分組成：

http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

從上面的URL可以看出，一個完整的URL包括以下幾部分：

　　① 協議部分：該URL的協議部分為“http：”，這代表網頁使用的是HTTP協議。在Internet中可以使用多種協議，如HTTP，FTP等等本例中使用的是HTTP協議。在"HTTP"后面的“//”為分隔符

　　② 域名部分：該URL的域名部分為“www.aspxfans.com”。一個URL中，也可以使用IP地址作為域名使用

　　③ 端口部分：跟在域名后面的是端口，域名和端口之間使用“:”作為分隔符。端口不是一個URL必須的部分，如果省略端口部分，將采用默認端口

　　④ 虛擬目錄部分：從域名后的第一個“/”開始到最后一個“/”為止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。本例中的虛擬目錄是“/news/”

　　⑤ 文件名部分：從域名后的最后一個“/”開始到“？”為止，是文件名部分，如果沒有“?”,則是從域名后的最后一個“/”開始到“#”為止，是文件部分，如果沒有“？”和“#”，那么從域名后的最后一個“/”開始到結束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一個URL必須的部分，如果省略該部分，則使用默認的文件名

　　⑥ 錨部分：從“#”開始到最后，都是錨部分。本例中的錨部分是“name”。錨部分也不是一個URL必須的部分

　　⑦ 參數部分：從“？”開始到“#”為止之間的部分為參數部分，又稱搜索部分、查詢部分。本例中的參數部分為“boardID=5&ID=24618&page=1”。參數可以允許有多個參數，參數與參數之間用“&”作為分隔符。

2.2、HTTP1.0和HTTP1.1的區別

　　一個WEB站點每天可能要接收到上百萬的用戶請求，為了提高系統的效率，HTTP 1.0規定瀏覽器與服務器只保持短暫的連接，瀏覽器的每次請求都需要與服務器建立一個TCP連接，服務器完成請求處理后立即斷開TCP連接，服務器不跟蹤每個客戶也不記錄過去的請求。但是，這也造成了一些性能上的缺陷，例如，一個包含有許多圖像的網頁文件中並沒有包含真正的圖像數據內容，而只是指明了這些圖像的URL地址，當WEB瀏覽器訪問這個網頁文件時，瀏覽器首先要發出針對該網頁文件的請求，當瀏覽器解析WEB服務器返回的該網頁文檔中的HTML內容時，發現其中的<img>圖像標簽后，瀏覽器將根據<img>標簽中的src屬性所指定的URL地址再次向服務器發出下載圖像數據的請求。

顯然，訪問一個包含有許多圖像的網頁文件的整個過程包含了多次請求和響應，每次請求和響應都需要建立一個單獨的連接，每次連接只是傳輸一個文檔和圖像，上一次和下一次請求完全分離。即使圖像文件都很小，但是客戶端和服務器端每次建立和關閉連接卻是一個相對比較費時的過程，並且會嚴重影響客戶機和服務器的性能。當一個網頁文件中包含 Applet，JavaScript文件，CSS文件等內容時，也會出現類似上述的情況。

為了克服HTTP 1.0的這個缺陷，HTTP 1.1支持持久連接，在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲。一個包含有許多圖像的網頁文件的多個請求和應答可以在一個連接中傳輸，但每個單獨的網頁文件的請求和應答仍然需要使用各自的連接。HTTP 1.1還允許客戶端不用等待上一次請求結果返回，就可以發出下一次請求，但服務器端必須按照接收到客戶端請求的先后順序依次回送響應結果，以保證客戶端能夠區分出每次請求的響應內容，這樣也顯著地減少了整個下載過程所需要的時間。基於HTTP 1.1協議的客戶機與服務器的信息交換過程。

 

 

 

可見，HTTP 1.1在繼承了HTTP 1.0優點的基礎上，也克服了HTTP 1.0的性能問題。不僅如此，HTTP 1.1 還通過增加更多的請求頭和響應頭來改進和擴充HTTP 1.0 的功能。例如，由於 HTTP 1.0不支持Host請求頭字段，WEB瀏覽器無法使用主機頭名來明確表示要訪問服務器上的哪個WEB站點，這樣就無法使用WEB服務器在同一個IP地址和端口號上配置多個虛擬WEB站點。在HTTP 1.1中增加Host請求頭字段后，WEB瀏覽器可以使用主機頭名來明確表示要訪問服務器上的哪個WEB站點，這才實現了在一台WEB服務器上可以在同一個IP地址和端口號上使用不同的主機名來創建多個虛擬WEB站點。HTTP 1.1 的持續連接，也需要增加新的請求頭來幫助實現，例如，Connection 請求頭的值為Keep-Alive 時，客戶端通知服務器返回本次請求結果后保持連接；Connection 請求頭的值為close 時，客戶端通知服務器返回本次請求結果后關閉連接。 HTTP 1.1還提供了與身份認證、狀態管理和Cache緩存等機制相關的請求頭和響應頭。

2.3、http 請求

　　客戶端連上服務器后，向服務器請求某個web資源，稱之為客戶端向服務器發送了一個HTTP請求。

2.4、http 請求方式

GET / POST 請求的區別：（面試題）

　　① Get是不安全的，因為在傳輸過程，數據被放在請求的URL中；Post的所有操作對用戶來說都是不可見的。

　　② Get傳送的數據量較小，這主要是因為受URL長度限制；Post傳送的數據量較大，一般被默認為不受限制。

請求方式：

　　HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。

　　HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

　　GET 請求指定的頁面信息，並返回實體主體。

　　HEAD 類似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭

　　POST     向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。

　　PUT 從客戶端向服務器傳送的數據取代指定的文檔的內容。

　　DELETE 請求服務器刪除指定的頁面。

　　CONNECT HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。

　　OPTIONS 允許客戶端查看服務器的性能。

　　TRACE 回顯服務器收到的請求，主要用於測試或診斷。

2.5、常見的 http 請求：GET 和 POST

① GET 請求：

 

 ② POST 請求

　　http://127.0.0.1:1080/WebTours/index.htm

 

 區分那些是 GET 請求，那些是 POST 請求？

　　

（1）GET：在瀏覽器直接輸入URL、<a href=""> 、<form method="get" >

　　  POST： <form method="post" >

（2）GET請求數據位於請求行中 ，POST請求數據位於請求體中

　　  GET /day4/form.html?username=zhangsan HTTP/1.1

　　  POST /day4/form.html HTTP/1.1

　　　　...

　　  username=lisi

（3）GET請求數據在URL上顯示，所以有長度限制，通常是1kb =1024字節

（4）POST的安全性要比GET的安全性高。比如：通過GET提交數據，用戶名和密碼將明文出現在URL上，因為(1)登錄頁面有可能被瀏覽器緩存；(2)其他人查看瀏覽器的歷史紀錄，那么別人就可以拿到你的賬號和密碼了

2.6、GET 和 POST 的區別：

　　1、GET使用URL或Cookie傳參。而POST將數據放在BODY中。

　　2、GET的URL會有長度上的限制，2kb，則POST的數據則可以非常大。

　　3、POST比GET安全，因為數據在地址欄上不可見。

　　4、一般get請求用來獲取數據，post請求用來發送數據。

2.7、http請求—消息頭Request

客戶端發送一個HTTP請求到服務器的請求消息包括以下格式：

　　請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成。

請求行以一個方法符號開頭，以空格分開，后面跟着請求的URI和協議的版本

 

 

　　第一部分：請求行，第一行明了是post請求，以及http1.1版本。

　　第二部分：請求頭部，第二行至第六行。

　　第三部分：空行，第七行的空行。

　　第四部分：請求數據，第八行。

Accept: text/html,image/*      -- 瀏覽器接受的數據類型
Accept-Charset: ISO-8859-1     -- 瀏覽器接受的編碼格式
Accept-Encoding: gzip,compress  --瀏覽器接受的數據壓縮格式
Accept-Language: en-us,zh-     --瀏覽器接受的語言
Host: www.it315.org:80          --（必須的）當前請求訪問的目標地址（主機:端口）
If-Modified-Since: Tue, 11 Jul 2000 18:23:51 GMT  --瀏覽器最后的緩存時間
Referer: http://www.it315.org/index.jsp      -- 當前請求來自於哪里
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)  --瀏覽器類型
Cookie:name=eric                     -- 瀏覽器保存的cookie信息
Connection: close/Keep-Alive            -- 瀏覽器跟服務器連接狀態。close: 連接關閉
keep-alive：保存連接。
Date: Tue, 11 Jul 2000 18:23:51 GMT      -- 請求發出的時間

2.8、http響應

服務器接收並處理客戶端發過來的請求后會返回一個HTTP的響應消息

HTTP響應也由四個部分組成：狀態行、消息報頭、空行和響應正文。 

第一部分：狀態行，由HTTP協議版本號， 狀態碼， 狀態消息 三部分組成。

　　第一行為狀態行，（HTTP/1.1）表明HTTP版本為1.1版本，狀態碼為200，狀態消息為（ok）

第二部分：消息報頭，用來說明客戶端要使用的一些附加信息

　　第二行和第三行為消息報頭

　　Date:生成響應的日期和時間；Content-Type:指定了MIME類型的HTML(text/html),編碼類型是UTF-8

第三部分：空行，消息報頭后面的空行是必須的

第四部分：響應正文，服務器返回給客戶端的文本信息。

空行后面的html部分為響應正文。

服務器響應狀態碼 1.x - 5.x的詳細配置：https://blog.csdn.net/alice_tl/article/details/87186772

必須記憶的

200 - 請求成功，已經正常處理完畢
301 - 請求永久重定向，轉移到其它URL
302 - 請求臨時重定向
304 - 請求被重定向到客戶端本地緩存
400 - 客戶端請求存在語法錯誤
401 - 客戶端請求沒有經過授權
403 - 客戶端的請求被服務器拒絕，一般為客戶端沒有訪問權限
404 - 客戶端請求的URL在服務端不存在
500 - 服務端永久錯誤

2.9、http響應—常見響應頭

Location: http://www.it315.org/index.jsp   -表示重定向的地址，該頭和302的狀態碼一起使用
Server:apache tomcat                 ---表示服務器的類型
Content-Encoding: gzip                 -- 表示服務器發送給瀏覽器的數據壓縮類型
Content-Length: 80                    --表示服務器發送給瀏覽器的數據長度
Content-Language: zh-cn               --表示服務器支持的語言
Content-Type: text/html; charset=GB2312   --表示服務器發送給瀏覽器的數據類型及內容編碼
Last-Modified: Tue, 11 Jul 2000 18:23:51 GMT --表示服務器資源的最后修改時間
Refresh: 1;url=http://www.it315.org        --表示定時刷新
Content-Disposition: attachment; filename=aaa.zip --表示告訴瀏覽器以下載方式打開資源（下載文件時用到）
Transfer-Encoding: chunked
Set-Cookie:SS=Q0=5Lb_nQ; path=/search   --表示服務器發送給瀏覽器的cookie信息（會話管理用到）
Expires: -1                           --表示通知瀏覽器不進行緩存
Cache-Control: no-cache
Pragma: no-cache
Connection: close/Keep-Alive           --表示服務器和瀏覽器的連接狀態。close：關閉連接 keep-alive:保存連接

2.10、HTTP之狀態碼

狀態代碼有三位數字組成，第一個數字定義了響應的類別，共分五種類別:

1xx：指示信息--表示請求已接收，繼續處理
2xx：成功--表示請求已被成功接收、理解、接受
3xx：重定向--要完成請求必須進行更進一步的操作
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現
5xx：服務器端錯誤--服務器未能實現合法的請求

常見狀態碼：

200 OK                        //客戶端請求成功
400 Bad Request               //客戶端請求有語法錯誤，不能被服務器所理解
401 Unauthorized              //請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域一起使用 
403 Forbidden                 //服務器收到請求，但是拒絕提供服務
404 Not Found                 //請求資源不存在，eg：輸入了錯誤的URL
500 Internal Server Error     //服務器發生不可預期的錯誤
503 Server Unavailable        //服務器當前不能處理客戶端的請求，一段時間后可能恢復正常

更多狀態碼：http://www.runoob.com/http/http-status-codes.html

3、會話跟蹤技術

　　web程序是使用HTTP協議傳輸數據的。HTTP協議是無狀態的協議。一旦數據交換完畢，客戶端與服務器端的連接就會關閉，再次交換數據需要建立新的連接。這就意味着服務器無法從連接上跟蹤會話。

　　早期為了記錄用戶的狀態時，就在瀏覽器記錄用戶信息cookie機制，每次請求都會往服務器發送這些數據，這樣服務器就知道是誰在請求了，該對應返回什么樣的數據，但是久而久之，安全性就暴露出來了。

　　cookie是在本地的，在本地就會有人想着去修改cookie里面的數據，從而獲取別人的信息。於是就有新的處理辦法，改在服務器端記錄用戶信息。也就出現了session機制，一切用戶的身份由服務器掌控。這就是cookie機制和session機制的歷史。

在一個會話的多個請求中共享數據，這就是會話跟蹤技術。例如在一個會話中的請求如下：
請求銀行主頁；
請求登錄（請求參數是用戶名和密碼）；
請求轉賬（請求參數與轉賬相關的數據）；
請求信譽卡還款（請求參數與還款相關的數據）。
在這上會話中當前用戶信息必須在這個會話中共享的，因為登錄的是張三，
那么在轉賬和還款時一定是相對張三的轉賬和還款！這就說明我們必須在一個會話過程中有共享數據的能力。

4、保存會話的兩種技術

客戶端技術 Cookie

　　兩個經典應用場合：判定注冊用戶是否已經登錄網站，購物車。

服務端技術 Session

　　經典應用場合一般就是在Session中存儲了用戶的登錄信息，進而可以訪問一些需要權限才能訪問的頁面。

5、Cookie

5.1、Cookie概念

　　Cookie翻譯成中文是小甜點，小餅干的意思。在HTTP中它表示服務器送給客戶端瀏覽器的小甜點。其實Cookie就是一個鍵和一個值構成的，隨着服務器端的響應發送給客戶端瀏覽器。然后客戶端瀏覽器會把Cookie保存起來，當下一次再訪問服務器時把Cookie再發送給服務器。

　　Cookie是由服務器創建，然后通過響應發送給客戶端的一個鍵值對。客戶端會保存Cookie，並會標注出Cookie的來源（哪個服務器的Cookie）。當客戶端向服務器發出請求時會把所有這個服務器Cookie包含在請求中發送給服務器，這樣服務器就可以識別客戶端了！ 原理：https://www.zhihu.com/question/31079651

5.2、Cookie應用場景

記錄上次訪問時間    
記錄用戶名
顯示瀏覽記錄

5.3、Cookie原理分析

 

 

當瀏覽器進行網絡請求時,如果攜帶當前瀏覽器的cookie    
服務器打給瀏覽器
set-cookie:username=zhangsan;Exipres=Moday,具體時間
瀏覽器打給服務器
Cookie:username=zhangsan；
存儲到瀏覽器的文本中
username=zhangsan  169.254.xxx.xxx/day09_cookie/servlet    name        value      url

5.4、Cookie 使用細節

　　一個Cookie只能標識一種信息，它至少含有一個標識該信息的名稱（NAME）和設置值（VALUE）。

　　一個WEB站點可以給一個WEB瀏覽器發送多個Cookie，一個WEB瀏覽器也可以存儲多個WEB站點提供的Cookie。

　　（void setPath(java.lang.String uri) ：設置cookie的有效訪問路徑。有效路徑指的是cookie的有效路徑保存在哪里，那么瀏覽器在有效路徑下訪問服務器時就會帶着cookie信息，否則不帶cookie信息。

void setMaxAge(int expiry) ： 設置cookie的有效時間。

　　正整數：表示cookie數據保存瀏覽器的緩存目錄（硬盤中），數值表示保存的時間。

　　負整數：表示cookie數據保存瀏覽器的內存中。瀏覽器關閉cookie就丟失了！！

　　零：表示刪除同名的cookie數據

Cookie數據類型只能保存非中文字符串類型的。可以保存多個cookie，但是瀏覽器一般只允許存放300個Cookie，每個站點最多存放20個Cookie，每個Cookie的大小限制為4KB。

6、Session介紹

　　在WEB開發中，服務器可以為每個用戶瀏覽器創建一個會話對象（session對象），注意：一個瀏覽器獨占一個session對象(默認情況下)。因此，在需要保存用戶數據時，服務器程序可以把用戶數據寫到用戶瀏覽器獨占的session中，當用戶使用瀏覽器訪問其它程序時，其它程序可以從用戶的session中取出該用戶的數據，為用戶服務。

Session和Cookie的主要區別在於：
Cookie是把數據保存在瀏覽器端的內存中
Session把數據保存在服務器端的內存中
cookie與session的聯系：
當服務器端生成一個session時就會向客戶端發送一個cookie保存在客戶端，這個cookie保存的是session的sessionId。。這樣才能保證客戶端發起請求后客戶端已經登錄的用戶能夠與服務器端成千上萬的session中准確匹配到已經保存了該用戶信息的session，同時也能夠確保不同頁面之間傳值時的正確匹配。

7、接口測試

7.1、什么是接口

　　API接口是Application Programming Interface的簡稱，是一些預先定義的函數，包括接口地址、傳入參數和返回參數。

　　可以簡單理解為，當需要訪問某些數據，正常狀態下傳入合格參數，會收到該數據范圍內的返回參數。

　　場景：在美團旅游頻道，用戶選定時間、地點后搜索航班，后台會調用搜索接口傳入時間、地點等參數，接收航班類別、價格等參數，在前台頁面上進行排列展示。同理，下單時會調用生單接口確認是否成單，支付時會調用支付接口完成交易，自動修改訂單狀態。

7.2、什么是接口測試

　　接口測試主要用於外部系統與系統之間以及內部各個子系統之間的交互點，定義特定的交互點，然后通過這些交互點來，通過一些特殊的規則也就是協議，來進行數據之間的交互。

　　一般我們用的多的是HTTP協議的接口、WebService協議的接口，還有RPC（Remote Procedure Call Protocol）——遠程過程調用協議的接口

　　不管是哪種接口，其本質就是發送一個request，然后服務器響應后返回一個response，然后我們對response進行分析，這即是接口測試。

接口的分類：

　　1.webservice接口 　　2.http api接口

　　webService接口是走soap協議通過http傳輸，請求報文和返回報文都是xml格式的，我們在測試的時候都用通過工具才能進行調用，測試。

　　http api接口是走http協議，通過路徑來區分調用的方法，請求報文都是key-value形式的，返回報文一般都是json串，有get和post等方法，這也是最常用的兩種請求方式。

一個URL就是一個接口：接口大致會分為一下幾個部分：

 

 

 

請求協議：
http --- 普通的http請求
https --- 加密的http請求，傳輸數據更加安全
請求IP：就是指提供接口的系統所部署的服務器地址
請求端口：如果不填端口，默認是80，否則需要填寫端口號
接口路徑：指系統提供的接口在什么位置
接口參數：參數在接口路徑后，用“?”來表示路徑地址完了，剩下的都是參數了，用“&”來區分參數個數，

1.Charles的抓包  web/app
2.Charles的過濾   a.filter的過濾  
b.ctrl+f的過濾  對請求頭  響應體  等進行過濾
c.可以使用過濾url的方式
d.可以使用focus的方式過濾  只顯示已經選中的url其他的進行隱藏
3.斷點替換
4.弱網測試

7.3、為什么要做接口測試

　　隨着系統越來越多，以及復雜性越來越高，為了保證系統的獨立性，也為了使業務更加的獨立，系統間的交互，越來越多的使用接口，這時候，為了保證數據的傳輸的准確性，接口測試也應運而生了，數據的錯誤，有可能引起系統的重大BUG，

7.4、接口測試的重要性

1.越底層發現bug，它的修復成本是越低的。
2.前端隨便變，接口測好了，后端不用變，前后端是兩撥人開發的。
3.檢查系統的安全性、穩定性，前端傳參不可信，比如京東購物，前端價格不可能傳入-1元，但是通過接口可以傳入-1元。
4.如今的系統復雜度不斷上升，傳統的測試方法成本急劇增加且測試效率大幅下降，接口測試可以提供這種情況下的解決方案。
5. 接口測試相對容易實現自動化持續集成，且相對UI自動化也比較穩定，可以減少人工回歸測試人力成本與時間，縮短測試周期，支持后端快速發版需求。接口持續集成是為什么能低成本高收益的根源。

6. 現在很多系統前后端架構是分離的，從安全層面來說：
(1)、只依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前面實在太容易）， 需要后端同樣進行控制，在這種情況下就需要從接口層面進行驗證。
(2)、前后端傳輸、日志打印等信息是否加密傳輸也是需要驗證的，特別是涉及到用戶的隱私信息，如身份證，銀行卡等。

7.5、接口測試工作流程

准備階段（80%）
       拿到開發的接口文檔，並理解每個接口的參數及含義
       了解被測試系統的業務流程
        編寫接口測試用例
執行階段（10%）
       測試用例/測試場景執行
       測試數據/系統數據收集
分析階段（10%）
    數據匯總/日志分析
測試報告


測試報告：  1.功能性測試報告  【測試報告】
    2.接口測試報告    【測試報告】

7.6、接口測試用例編寫

 

 

 接口測試用例編寫要點

　　測試每個參數類型不合法的情況

　　測試每個參數取值范圍不合法的情況

　　測試參數為空的情況

　　測試參數前后台定義的一致性

　　測試每個參數的上下限（這里容易出致命的BUG，如果程序處理不當，可能導致崩潰）

　　測試每個參數取值不合理的情況（包括取的值不屬於自己，取值在這階段不會出現，取值超出了自己所擁有的數量或者范圍）

　　如果兩個請求有嚴格的先后順序，需要測試調轉順序的情況

　　自己和自己的交易、聊天等操作（這種特別容易遺漏）

7.7、接口文檔

我們做接口測試，需要開發提供接口文檔。最重要的有一下幾點：

1、被測接口的地址
2、接口參數，以及各個參數的說明
3、必要的http頭與http體 ( http頭是可以自定義的，可以用來校驗是否是自己人訪問 )
4、接口返回什么值，以及各個返回值的說明
5、接口是干什么的

7.8、測試部署工作

解壓tomcat

 

 

 

 

 

 

 

 

 7.9、接口測試：json

　　① 什么是json

　　　　Json是一種數據載體 互聯網本質就是數據傳輸，數據傳輸就需要數據載體。比如：頁面信息就是存儲在HTML這種數據載體中

 

 

 

 

 

 　　② 為什么使用json

FasterJSON
Gson
Json


Json傳輸數據效率更高，所以部分場景下使用HTML與XML
但是JSON語言描述不及標簽語言，所以部分場景下使用HTML與XML
如果傳遞少量數據，使用JSON

7.11、接口測試工具及原理

　　① 常見接口測試工具

• 典型商業工具：loadrunner,soapui

• 典型開源工具: jmeter

• 擴展插件：POSTMAN

　　② 實現原理

• 模擬客戶端對服務器進行多連接

• 單接口測試：1.測試接口通不通

　　　　　　　　　2.多場景接口測試

　　　　　　　　    3.對接口進行壓力測試 [多次請求實現並發]

7.12、接口測試工具Postman

使用postman按照接口文檔進行測試

　　① Get請求

 

 

 

 　　② Post請求

 

 8、接口抓包測試工具Charles/Fiddler

作用： 1.抓取網絡封包 （web/app）
   2.斷點替換  -- 請求斷點
              -- 響應斷點
   3.弱網測試
   4.過濾
   5.黑名單
Charles的原理：
    Charles是一款Http代理服務器和Http監視器，當移動端在無線網連接中按要求設置好代理服務器，使所有對網絡的請求都經過Charles客戶端來轉發時，Charles可以監控這個客戶端各個程序所有連接互聯網的Http通信。

　　① 安裝Charles客戶端

　　打開瀏覽器訪問Charles官網https://www.charlesproxy.com/，下載相應系統的Charles安裝包，然后一鍵安裝即可。

 

 　　② 傻瓜式安裝charles

　　③ 抓取移動設備發送的Http請求.

　　　　1、先將移動設備連接到Charles客戶端。首先在電腦中輸入cmd打開命令行窗口，輸入ipconfig查看本機連接無線網絡的IP地址，這個地址作為移動設備連接Charles客戶端的代理地址，

 

 　　　　2、打開Charles客戶端，點擊Proxy->Proxy Settings菜單，可以設置移動設備連接到Charles的端口（8888），這樣移動設備代理配置需要的ip地址和端口號都有了。 

 

 　　　　3、打開手機wifi，設置所連接的wifi的代理網絡；wifi代理設置為手動，代理的服務器ip填寫上一步驟中查看到的電腦ip，端口填寫上一步驟提到的charles的服務端口：

注意：移動設備配置之后，第一次通過手機訪問手機中的發送請求時，Charles會彈出提示框，提示有設備嘗試連接到Charles，是否允許，如果不允許的話，手機發送請求失敗，點擊Allow允許，這樣這個設備的IP地址就會添加到允許列表中，如果錯誤點擊了Deny可以重啟Charles會再此提示，或者通過Proxy->Access Control Settings手動添加地址，如果不想每個設備連接Charles都要點擊允許的話，可以添加0.0.0.0/0允許所有設備連接到Charles。

　　　　4、Charles是通過將自己設置成代理服務器來完成抓包的，勾選系統代理后，本地系統（如果通過瀏覽器發送請求）發送出去的請求都能被截取下來。因此，如果想只抓取手機APP發送的請求的話，可以不勾選WindowsProxy選項，這樣在測試時就不會被本機Http請求所干擾。

 

 　　　　5、如果想要抓取瀏覽器發送的請求包，勾選WindowsProxy選項之后還是抓取失敗，可能是瀏覽器沒有設置成使用系統的代理服務器，只要設置成使用系統的代理服務器，或者將瀏覽器的代理服務器設置成127.0.0.1:8888也可以成功。

　　④ 啟動手機，打開軟件，就可以進行聯網抓包測試

　　　　Charles提供兩種查看封包的頁簽，一個是Structure（結構），另一個是Sequence（序列），Structure用來將訪問請求按訪問的域名分類，Sequence用來將請求按訪問的時間排序。任何程序都可以在Charles中的Structure窗口中看到訪問的域名。

 

 

 

 

 

 　　⑤ 過濾不必要的網絡包

　　　　在抓取手機發送的請求時，有許多請求包是對圖片等不需要關注的資源的請求，我們只想對指定目錄服務器上發送的請求進行抓取，這時候就可以通過過濾網絡包的方式實現。有兩種實現方式：

　　　　1）選擇Proxy->Recording Settings菜單，然后在include欄添加需要抓取包的指定服務器請求協議、地址、端口號，也可以在exclude欄添加不抓取包的地址。

 

 

 

 　　　　在主界面的中部的 Filter 欄中填入需要過濾出來的關鍵字。例如我們的服務器的地址是：http://blog.csdn.net, 那么只需要在 Filter 欄中填入 csdn 即可。

 

 　　⑥ Charles抓包詳解

 

 

 

 

Filter ： 過濾，可以輸入關鍵字來快速篩選出 URL 中帶指定關鍵字的網絡請求

Overview ： 查看這次請求的詳細內容，例如耗時詳細列車了請求開始時間、結束時間，響應開始時間、結束時間，總耗時、DNS耗時、網絡延時等。

對於Size也詳細列出了請求頭大小、響應頭大小、壓縮比例等內容。 

URL：進行網絡請求的鏈接；

Status：當前狀態，complete表示請求完成；

Responce Code：返回碼。不同的接口，不同的請求結果，返回碼都不同；

Protocol：使用的協議；

Method：請求方式，如GET請求，POST請求等；

Kept Alive：判斷當前是否正在鏈接（活躍）；

Content-Type:發送的內容類型，如這里用的是XML文本，以UTF8的方式發送；

Client Address：客戶端的IP地址；

Remote Address：遠程服務器的IP；

Timing: 

Request Start Time：請求開始的時間；

Request End Time：請求結束的時間；

Response Start Time：返回開始的時間；

Response End Time : 返回結束的時間；

Duration : 總時間；

Size: 

Request Header ：請求的頭部大小；

Response Header：返回的頭部大小；

Request : 請求發送的大小；

Response：返回數據的大小；

Total：所有數據大小；

Request Compression : 請求壓縮；

Response Compression : 返回壓縮；

Request ： 查看請求內容（底下的Headers，Query String，Cookies，Raw。）

Headers：發送請求的頭部信息；

Query String : 發送參數列表；

Cookies： 瀏覽器緩存；

Raw：發送的原生數據，包括了頭部和參數；

Reponse : 查看響應內容

Headers：是返回的頭部信息；

Text：返回信息（除去頭部）后的文本；

Hex：返回信息的16進制表示；

XML：我返回的數據是XML。如果你返回的是JSON，這里就會顯示JSON；

XML Text：如果你返回JSON，這里會顯示JSON Text；

Raw：返回的所有原生數據，包括頭部；

Summary: 查看發送數據的一些簡要信息（主機，狀態碼，數據的類型，header和body大下，加載時間，總時間）

Chart: Summary中簡要信息以圖表形式展示

Notes: 其他信息

　　⑦ Charles常用的功能總結

　　　　https://blog.csdn.net/ty_hf/article/details/54575174

9、SoupUI測試

　　SoapUI是一個開源測試工具，通過soap/http來檢查、調用、實現Web Service的功能/負載/符合性測試。該工具既可作為一個單獨的測試軟件使用，也可利用插件集成到Eclipse，maven2.X，Netbeans 和intellij中使用。SoapUI Pro是SoapUI的商業非開源版本，實現的功能較開源的SoapUI更多。

　　SoapUI是一個自由和開放源碼的跨平台功能測試解決方案。通過一個易於使用的圖形界面和企業級功能，SoapUI讓您輕松，快速創建和執行自動化功能、回歸、合規和負載測試。在一個測試環境，SoapUI提供完整的測試覆蓋，並支持所有的標准協議和技術。

9.1、WebService

　　WebService是一種跨編程語言和跨操作系統平台的遠程調用技術。

　　所謂跨編程語言和跨操作平台，就是說服務端程序采用java編寫，客戶端程序則可以采用其他編程語言編寫，反之亦然！跨操作系統平台則是指服務端程序和客戶端程序可以在不同的操作系統上運行。

　　 所謂遠程調用，就是一台計算機a上 的一個程序可以調用到另外一台計算機b上的一個對象的方法，譬如，銀聯提供給商場的pos刷卡系統，商場的POS機轉賬調用的轉賬方法的代碼其實是跑在銀 行服務器上。再比如，amazon，天氣預報系統，淘寶網，校內網，百度等把自己的系統服務以webservice服務的形式暴露出來，讓第三方網站和程 序可以調用這些服務功能，這樣擴展了自己系統的市場占有率，往大的概念上吹，就是所謂的SOA應用。

　　 其實可以從多個角度來理解 WebService，從表面上看，WebService就是一個應用程序向外界暴露出一個能通過Web進行調用的API，也就是說能用編程的方法通過 Web來調用這個應用程序。我們把調用這個WebService的應用程序叫做客戶端，而把提供這個WebService的應用程序叫做服務端。從深層次 看，WebService是建立可互操作的分布式應用程序的新平台，是一個平台，是一套標准。它定義了應用程序如何在Web上實現互操作性，你可以用任何 你喜歡的語言，在任何你喜歡的平台上寫Web service ，只要我們可以通過Web service標准對這些服務進行查詢和訪問。

9.2、SOAP

　　WebService通過HTTP協議發送請求和接收結果時，發送的請求內容和結果內容都采用XML格式封裝，並增加了一些特定的HTTP消息頭，以說明 HTTP消息的內容格式，這些特定的HTTP消息頭和XML內容格式就是SOAP協議。SOAP提供了標准的RPC方法來調用Web Service。

　　SOAP協議 = HTTP協議 + XML數據格式

　　SOAP協議定義了SOAP消息的格式，SOAP協議是基於HTTP協議的，SOAP也是基於XML和XSD的，XML是SOAP的數據編碼方式。打個比 喻：HTTP就是普通公路，XML就是中間的綠色隔離帶和兩邊的防護欄，SOAP就是普通公路經過加隔離帶和防護欄改造過的高速公路。

9.3、WSDL

　　比我們去商店買東西，首先要知道商店里有什么東西可買，然后再來購買，商家的做法就是張貼廣告海報。 WebService也一樣，WebService客戶端要調用一個WebService服務，首先要有知道這個服務的地址在哪，以及這個服務里有什么方 法可以調用，所以，WebService務器端首先要通過一個WSDL文件來說明自己家里有啥服務可以對外調用，服務是什么（服務中有哪些方法，方法接受 的參數是什么，返回值是什么），服務的網絡地址用哪個url地址表示，服務通過什么方式來調用。

　　WSDL(Web Services Description Language)就是這樣一個基於XML的語言，用於描述Web Service及其函數、參數和返回值。它是WebService客戶端和服務器端都 能理解的標准格式。因為是基於XML的，所以WSDL既是機器可閱讀的，又是人可閱讀的，這將是一個很大的好處。一些最新的開發工具既能根據你的 Web service生成WSDL文檔，又能導入WSDL文檔，生成調用相應WebService的代理類代碼。

　　WSDL 文件保存在Web服務器上，通過一個url地址就可以訪問到它。客戶端要調用一個WebService服務之前，要知道該服務的WSDL文件的地址。 WebService服務提供商可以通過兩種方式來暴露它的WSDL文件地址：

9.4、SoupUI安裝

 

 傻瓜式安裝，然后進行破解

破解步驟：
安裝后，替換“..\SmartBear\soapUI-Pro-4.5.1\lib”下的 Protection-4.6.jar 文件；
運行程序bin\soapui-pro.bat，導入scz.key即可；
破解完成。

 

 　　① 安裝不能夠連接webservice問題解決

　　找到bin中vmoptions文件

 

9.5、創建webService測試

http://fy.webxml.com.cn/webservices/EnglishChinese.asmx
http://fy.webxml.com.cn/webservices/EnglishChinese.asmx?wsdl
免費的：https://blog.csdn.net/lgh1117/article/details/7770139

10、接口測試復習

10.1、一、常見接口：

　　1、webService接口：是走soap協議通過http傳輸，請求報文和返回報文都是xml格式的，我們在測試的時候都用通過工具才能進行調用，測試。可以使用的工具有SoapUI、jmeter、loadrunner等；

　　2、http api接口：是走http協議，通過路徑來區分調用的方法，請求報文都是key-value形式的，返回報文一般都是json串，有get和post等方法，這也是最常用的兩種請求方式。可以使用的工具有postman、RESTClient、jmeter、loadrunner等；

10.2、二、接口組成

接口都有那些部分組成：
　　1、接口說明
　　2、調用url
　　3、請求方法（get\post）
　　4、請求參數、參數類型、請求參數說明
　　5、返回參數說明
　　由接口文檔可知，接口至少應有請求地址、請求方法、請求參數（入參和出參）組成，部分接口有請求頭header。
　　標頭 (header)：是服務器以HTTP協議傳HTML資料到瀏覽器前所送出的字串，在標頭與 HTML 文件之間尚需空一行分隔，一般存放cookie、token等信息
　　有同學問我header和入參有什么關系？它們不都是發送到服務器的參數嗎？
　　首先，它們確實都是發送到服務器里的參數，但它們是有區別的，header里存放的參數一般存放的是一些校驗信息，比如cookie，它是為了校驗這個請求是否有權限請求服務器，如果有，它才能請求服務器，然后把請求地址連同入參一起發送到服務器，然后服務器會根據地址和入參來返回出參。也就是說，服務器是先接受header信息進行判斷該請求是否有權限請求，判斷有權限后，才會接受請求地址和入參的。

10.3、三、為什么要做接口測試：

　　大家都知道，接口其實就是前端頁面或APP等調用與后端做交互用的，所以好多人都會問，我功能測試都測好了，為什么還要測接口呢？OK，在回答這個問題之前，先舉個栗子：

　　比如測試用戶注冊功能，規定用戶名為6~18個字符，包含字母（區分大小寫）、數字、下划線。首先功能測試時肯定會對用戶名規則進行測試時，比如輸入20個字符、輸入特殊字符等，但這些可能只是在前端做了校驗，后端可能沒做校驗，如果有人通過抓包繞過前端校驗直接發送到后端怎么辦呢？試想一下，如果用戶名和密碼未在后端做校驗，而有人又繞過前端校驗的話，那用戶名和密碼不就可以隨便輸了嗎？如果是登錄可能會通過SQL注入等手段來隨意登錄，甚至可以獲取管理員權限，那這樣不是很恐怖？

　　所以，接口測試的必要性就體現出來了：

　　①、可以發現很多在頁面上操作發現不了的bug

　　②、檢查系統的異常處理能力 　　

　　③、檢查系統的安全性、穩定性 　　

　　④、前端隨便變，接口測好了，后端不用變

10.4、四、接口測試怎么測：

　在進行接口測試前，還需要了解：
　　1）、GET和POST請求：
　　如果是get請求的話，直接在瀏覽器里輸入就行了，只要在瀏覽器里面直接能請求到的，都是get請求，如果是post的請求的話，就不行了，就得借助工具來發送。
　　GET請求和POST請求的區別：
　　1、GET使用URL或Cookie傳參。而POST將數據放在BODY中。
　　2、GET的URL會有長度上的限制，則POST的數據則可以非常大。
　　3、POST比GET安全，因為數據在地址欄上不可見。
　　4、一般get請求用來獲取數據，post請求用來發送數據。
　　其實上面這幾點，只有最后一點說的是比較靠譜的，第一點post請求也可以把數據放到url里面，get請求其實也沒長度限制，post請求看起來參數是隱式的，稍微安全那么一些些，但是那只是對於小白用戶來說的，就算post請求，你通過抓包也是可以抓到參數的。所以上面這些面試的時候你說出來就行了。
　　2）、http狀態碼
　　每發出一個http請求之后，都會有一個響應，http本身會有一個狀態碼，來標示這個請求是否成功，常見的狀態碼有以下幾種：
　　1、200 2開頭的都表示這個請求發送成功，最常見的就是200，就代表這個請求是ok的，服務器也返回了。
　　2、300 3開頭的代表重定向，最常見的是302，把這個請求重定向到別的地方了，
　　3、400 400代表客戶端發送的請求有語法錯誤，401代表訪問的頁面沒有授權，403表示沒有權限訪問這個頁面，404代表沒有這個頁面
　　4、500 5開頭的代表服務器有異常，500代表服務器內部異常，504代表服務器端超時，沒返回結果
　　接下來再說接口測試怎么測：
　　1）、通用接口用例設計
　　①、通過性驗證：首先肯定要保證這個接口功能是好使的，也就是正常的通過性測試，按照接口文檔上的參數，正常傳入，是否可以返回正確的結果。
　　②、參數組合：現在有一個操作商品的接口，有個字段type，傳1的時候代表修改商品，商品id、商品名稱、價格有一個是必傳的，type傳2的時候是刪除商品，商品id是必傳的，這樣就要測參數組合了，type傳1的時候，只傳商品名稱能不能修改成功，id、名稱、價格都傳的時候能不能修改成功。
　　③、接口安全：
　　1、繞過驗證，比如說購買了一個商品，它的價格是300元，那我在提交訂單時候，我把這個商品的價格改成3元，后端有沒有做驗證，更狠點，我把錢改成-3，是不是我的余額還要增加？
　　2、繞過身份授權，比如說修改商品信息接口，那必須得是賣家才能修改，那我傳一個普通用戶，能不能修改成功，我傳一個其他的賣家能不能修改成功
　　3、參數是否加密，比如說我登陸的接口，用戶名和密碼是不是加密，如果不加密的話，別人攔截到你的請求，就能獲取到你的信息了，加密規則是否容易破解。
　　4、密碼安全規則，密碼的復雜程度校驗
　　④、異常驗證：
　　所謂異常驗證，也就是我不按照你接口文檔上的要求輸入參數，來驗證接口對異常情況的校驗。比如說必填的參數不填，輸入整數類型的，傳入字符串類型，長度是10的，傳11，總之就是你說怎么來，我就不怎么來，其實也就這三種，必傳非必傳、參數類型、入參長度。
　　2）、根據業務邏輯來設計用例
　　根據業務邏輯來設計的話，就是根據自己系統的業務來設計用例，這個每個公司的業務不一樣，就得具體的看自己公司的業務了，其實這也和功能測試設計用例是　　一樣的。
　　舉個例子，拿bbs來說，bbs的需求是這樣的：
　　1、登錄失敗5次，就需要等待15分鍾之后再登錄
　　2、新注冊的用戶需要過了實習期才能發帖
　　3、刪除帖子扣除積分
　　4、......
　　像這樣的你就要把這些測試點列出來，然后再去造數據測試對應的測試點。

10.5、五、用什么工具測

　　接口測試的工具很多，比如 postman、RESTClient、jmeter、loadrunner、SoapUI等，本人首推的測試工具是postman和jmeter