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