首先要先了解被測(cè)試的對(duì)象 ? ? ? ? ? ? ? ? ?架構(gòu)涩金、邏輯
要模擬并盡可能接近真實(shí)發(fā)生的事情，不管是客戶(hù)端暇仲、服務(wù)器還是中間件步做。模擬用戶(hù)行為，用戶(hù)數(shù)據(jù)奈附。
純接口測(cè)試模式：
restful協(xié)議測(cè)試基于 http的get post delete 等
webservice ?xml..
socket協(xié)議
Restful:大型的服務(wù)器都是分布式部署全度，其中有臺(tái)服務(wù)器是進(jìn)行負(fù)載均衡的，從外部用戶(hù)請(qǐng)求到負(fù)載均衡服務(wù)器均勻的分給之后的多臺(tái)分布式服務(wù)器斥滤。
一般分為四層将鸵，負(fù)載均衡服務(wù)器--應(yīng)用服務(wù)器（收到負(fù)載均衡服務(wù)器請(qǐng)求后進(jìn)行應(yīng)用處理，再請(qǐng)求下一層//web服務(wù)器：nginx apche tomcat等)--緩存層（大型服務(wù)器端重要的部分佑颇，可以提高訪問(wèn)速度;一般存儲(chǔ)在內(nèi)存 LruCache）--數(shù)據(jù)服務(wù)層（MySQL oracle 等）
測(cè)試時(shí)需要充分了解架構(gòu)顶掉。
服務(wù)器測(cè)試與UI測(cè)試相比較最大的區(qū)別是沒(méi)有界面。
使用接口測(cè)試工具發(fā)起請(qǐng)求挑胸。
http協(xié)議：
根據(jù)接口文檔進(jìn)行合法測(cè)試（屬于服務(wù)器端的功能測(cè)試）
服務(wù)器測(cè)試可以分為四個(gè)類(lèi)型：
功能測(cè)試（輸入的數(shù)據(jù)為服務(wù)器端設(shè)計(jì)規(guī)范中提到的合法數(shù)據(jù)輸入及返回）
容錯(cuò)性數(shù)據(jù)（輸入的數(shù)據(jù)都是錯(cuò)誤的痒筒，或大型服務(wù)架構(gòu)中部分服務(wù)宕機(jī)是否有影響）
性能測(cè)試（一般指負(fù)載和壓力；負(fù)載：在什么并發(fā)情況下能達(dá)到最優(yōu)性能；壓力測(cè)試：什么負(fù)載下服務(wù)會(huì)出現(xiàn)大量錯(cuò)誤）
????性能測(cè)試指標(biāo)：事務(wù)的平均處理時(shí)間簿透、每秒處理的事務(wù)個(gè)數(shù)
穩(wěn)定性測(cè)試：7*24小時(shí)運(yùn)行不會(huì)有內(nèi)存泄露等泄漏現(xiàn)象
服務(wù)器端測(cè)試顆粒度：
基于接口層做黑盒測(cè)試（黑盒移袍；發(fā)送和返回?cái)?shù)據(jù)驗(yàn)證，適合簡(jiǎn)單的接口系統(tǒng)：內(nèi)部邏輯相對(duì)簡(jiǎn)單萎战，請(qǐng)求數(shù)據(jù)類(lèi)型較少咐容，返回?cái)?shù)據(jù)較標(biāo)準(zhǔn)的）
基于邏輯黑盒
+白盒的灰盒測(cè)試（接口處理比較復(fù)雜的接口：很多太服務(wù)器進(jìn)行請(qǐng)求處理的情況（搜索引擎）；需要遍歷到所有服務(wù)器邏輯的分支或邏輯覆蓋）概要設(shè)計(jì)或詳細(xì)設(shè)計(jì)的true false的分支都覆蓋到
純白盒測(cè)試 需要基于代碼覆蓋率驗(yàn)證測(cè)試覆蓋度蚂维，一般覆蓋到70%的代碼 ? 投入精力高效率低
? ? 測(cè)試開(kāi)始前就要準(zhǔn)備戳粒，根據(jù)接口定義和服務(wù)實(shí)現(xiàn)進(jìn)行開(kāi)發(fā)
? ? 需要對(duì)通訊協(xié)議了解。
