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包括以下幾部分：
1.協議部分：該URL的協議部分爲“http：”，這代表網頁使用的是HTTP協議。在Internet中可以使用多種協議，如HTTP，FTP等等本例中使用的是HTTP協議。在"HTTP"後面的“//”爲分隔符
2.域名部分：該URL的域名部分爲“www.aspxfans.com”。一個URL中，也可以使用IP地址作爲域名使用
3.端口部分：跟在域名後面的是端口，域名和端口之間使用“:”作爲分隔符。端口不是一個URL必須的部分，如果省略端口部分，將採用默認端口
4.虛擬目錄部分：從域名後的第一個“/”開始到最後一個“/”爲止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。本例中的虛擬目錄是“/news/”
5.文件名部分：從域名後的最後一個“/”開始到“？”爲止，是文件名部分，如果沒有“?”,則是從域名後的最後一個“/”開始到“#”爲止，是文件部分，如果沒有“？”和“#”，那麼從域名後的最後一個“/”開始到結束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一個URL必須的部分，如果省略該部分，則使用默認的文件名
6.錨部分：從“#”開始到最後，都是錨部分。本例中的錨部分是“name”。錨部分也不是一個URL必須的部分
7.參數部分：從“？”開始到“#”爲止之間的部分爲參數部分，又稱搜索部分、查詢部分。本例中的參數部分爲“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請求方式
請求方式：
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
1.1.1.GET請求
1.1.2.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部分爲響應正文。
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，否則需要填寫端口號
接口路徑：指系統提供的接口在什麼位置
接口參數：參數在接口路徑後，用“?”來表示路徑地址完了，剩下的都是參數了，用“&”來區分參數個數，
7.3.爲什麼要做接口測試
隨着系統越來越多，以及複雜性越來越高，爲了保證系統的獨立性，也爲了使業務更加的獨立，系統間的交互，越來越多的使用接口，這時候，爲了保證數據的傳輸的準確性，接口測試也應運而生了，數據的錯誤，有可能引起系統的重大BUG，
7.4.接口測試的重要性
1.越底層發現bug，它的修復成本是越低的。
2.前端隨便變，接口測好了，後端不用變，前後端是兩撥人開發的。
3.檢查系統的安全性、穩定性，前端傳參不可信，比如京東購物，前端價格不可能傳入-1元，但是通過接口可以傳入-1元。
4.如今的系統複雜度不斷上升，傳統的測試方法成本急劇增加且測試效率大幅下降，接口測試可以提供這種情況下的解決方案。
- 接口測試相對容易實現自動化持續集成，且相對UI自動化也比較穩定，可以減少人工迴歸測試人力成本與時間，縮短測試周期，支持後端快速發版需求。接口持續集成是爲什麼能低成本高收益的根源。
- 現在很多系統前後端架構是分離的，從安全層面來說：
(1)、只依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前面實在太容易）， 需要後端同樣進行控制，在這種情況下就需要從接口層面進行驗證。
(2)、前後端傳輸、日誌打印等信息是否加密傳輸也是需要驗證的，特別是涉及到用戶的隱私信息，如身份證，銀行卡等。
7.5.接口測試工作流程
準備階段（80%）
拿到開發的接口文檔，並理解每個接口的參數及含義
瞭解被測試系統的業務流程
編寫接口測試用例
執行階段（10%）
測試用例/測試場景執行
測試數據/系統數據收集
分析階段（10%）
數據彙總/日誌分析
測試報告
7.6.接口測試用例編寫
接口測試用例編寫要點
測試每個參數類型不合法的情況
測試每個參數取值範圍不合法的情況
測試參數爲空的情況
測試參數前後臺定義的一致性
測試每個參數的上下限（這裏容易出致命的BUG，如果程序處理不當，可能導致崩潰）
測試每個參數取值不合理的情況（包括取的值不屬於自己，取值在這階段不會出現，取值超出了自己所擁有的數量或者範圍）
如果兩個請求有嚴格的先後順序，需要測試調轉順序的情況
自己和自己的交易、聊天等操作（這種特別容易遺漏）
7.7.接口文檔
我們做接口測試，需要開發提供接口文檔。最重要的有一下幾點：
1.被測接口的地址
2.接口參數，以及各個參數的說明
3.必要的http頭與http體 ( http頭是可以自定義的，可以用來校驗是否是自己人訪問 )
4.接口返回什麼值，以及各個返回值的說明
5.接口是幹什麼的
7.8.測試部署工作
解壓tomcat
7.9.接口測試：json
1.1.3.什麼是json
Json是一種數據載體
互聯網本質就是數據傳輸，數據傳輸就需要數據載體。比如：頁面信息就是存儲在HTML這種數據載體中
1.1.4.爲什麼使用json
Json傳輸數據效率更高，所以部分場景下使用HTML與XML
但是JSON語言描述不及標籤語言，所以部分場景下使用HTML與XML
如果傳遞少量數據，使用JSON
7.10.接口測試工具及原理
1.1.5.常見接口測試工具
• 典型商業工具：loadrunner,soapui
• 典型開源工具: jmeter
• 擴展插件：POSTMAN
1.1.6.實現原理
• 模擬客戶端對服務器進行多連接
7.11.接口測試工具Postman
使用postman按照接口文檔進行測試
1.1.7.Get請求
1.1.8.Post請求