接口測試原理
測試系統組件間接口的一種測試。
接口測試主要用於檢測系統與系統之間以及內部各個子系統之間的交互點。測試的重點是檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。
接口測試要點
針對游戲，在接口測試時需要注意的地方：
重復請求已完成的數據。 ——快速獲得需要一定勞作才能獲得的獎勵。
更改請求狀態。——獲得當前不能獲得的東西或狀態。
更改UID（角色ID相關）。——移花接木。
更改ID，重復請求。——獲得了后，再次請求不應獲得的獎勵等。
驗證掉落。——掉落掉落表里沒有的物品。
更改數量為負數。——驗證是否處理負值。
並發請求實現。——並發會導致可能沒有做相應處理的返回。
測試手段和方法
無論哪種方法去實現測試，其原理是通過一定手段和途徑模擬客戶端向服務端發送請求，服務器接收請求后把對應的處理返回給客戶端，客戶端實現響應的一個過程。
利用工具測試：
Charles是基於HTTP傳輸的XML、AMF、HTML的測試工具。
WPE是基於Sockets傳輸的TCP、UDP的網絡封包編輯工具。
具體使用分析可參考：
http://wenku.baidu.com/view/2a790e61783e0912a2162a50.html
Loadrunner
Java + Fitnesse
具體使用分析可參考：
http://www.51testing.com/html/66/n-814766.html
手動測試方法。
測試依據：將客戶端發送的請求視為“不合法”操作。根據數據存儲原理，在處理存儲數據的時候，對數據庫數據進行修改，讓客戶端的數據請求“不合法”。即客戶端的一切都是假像。
手動測試會用到游戲客戶端，是從另一個角度去審視請求是否合法。
這里的測試方法涉及到，服務端、緩存、客戶端之間的數據交互，需要排除緩存數據對測試結果的影響。通常來說，客戶端發出的數據請求，先在緩存中尋找數據，如果緩存中沒有，就去數據庫取。在手動進行接口測試時，需要保證緩存數據和數據庫數據一致。否則，測試操作往往會得到“錯誤的”測試結果。
在網頁游戲測試過程中，如果某個數據有用到緩存機制，比如在未修改時，緩存數據=DB數據=2，客戶端呈現的數據=2；如果直接修改DB數據=0，不修改緩存數據，那么在使用1個數據時，會先使用緩存數據，使用一個后，緩存和DB交互會使得DB數據=-1，從而不能達到測試目的。
一般網頁游戲測試過程中，會提供清除緩存的途徑，使得修改DB數據后，清除緩存使得直接取DB的數據，達到測試結果的准確性。
在測試過程中，往往不會知道緩存數據是否和數據庫數據一致，但測試員一定要知道，什么數據是與緩存有關，什么數據是直接和數據庫打交道。
介紹下手動測試的方法：
修改數據庫數據。
進行測試操作時，需要注意修改數據庫數據時，客戶端要保持沒有請求發送（那樣返回的數據會刷新客戶端顯示，造成測試操作請求的“合法”）。例如修改數據后，不能再打開目標操作界面，打開操作界面會重新請求界面數據顯示；不能關閉客戶端再開啟。
示例1：測試數值判斷；比如物品價格=10幣，角色身上有100幣，修改數據的金錢數量=9幣，然后執行購買，這時通過購買判斷，正確的結果應該不能購買。
示例2：測試狀態判斷；比如完成一個任務A，沒有領取獎勵，這時數據任務狀態=完成未領取獎勵，修改數據庫該任務狀態=完成已領取獎勵，然后客戶端執行領取獎勵操作，這時通過領取條件判斷，正確的結果應該不能領取獎勵。
示例3：測試負值；比如在購買時，輸入負值（一般客戶端會限制負值輸入，但服務端的判斷必不可少），輸入負值后，執行購買，通過購買判斷，正確的結果應該不能購買。（不然就送錢出去了）
示例4：更改ID；比如A玩家已穿戴的裝備，修改數據庫使得裝備的userID=B，在客戶端A卸下穿戴的裝備，通過卸下判斷，正確結果應該是卸下不成功。（因為服務端認定這件裝備是B已穿戴的）
總結：通過示例，可以泛用這種測試手法到近似的地方。
程序提供工具。（測試員的幸福，具體原理是一樣，就不細說了）
接口測試的重要性
不借助工具進行接口測試，不能覆蓋到所有測試需求。因為工具可以完全繞過客戶端，對服務端發送測試目的性強的請求，以此來判斷程序邏輯是否有疏漏。
特別是並發請求的測試，單線程並發和多線程並發。這種情況不可能通過手工測試達到測試目的。
單線程並發，雖然手工測試可以覆蓋狀態判斷，但是同一時間多次請求，如果沒有相應的處理機制，也可能發生一勞多獲的漏洞。
多線程並發，有個示例可以說明其嚴重性：
一次BOSS戰中，BOSS快死了，假如HP=100。A、B2個玩家同時間殺到。A傷害>100，B傷害<100。悲劇發生了，A殺死了BOSS，B一刀下去BOSS沒死；更悲劇的在后面，A殺死了BOSS，擊殺獎勵發！A擊殺BOSS公告發！B的結果BOSS沒死，然后路人C一刀下去BOSS死了，C殺死了BOSS，擊殺獎勵再發！C擊殺BOSS公告發！——玩家就崩了~
還好，這種情況的發生往往需要巧合，發生后可以通過查看日志來分析產生原因。
接口方面產生的漏洞往往會導致刷物品、刷金錢、刷屬性。並發性的漏洞，往往很難發現和重現，如果不能及時發現和修復，會一直是一顆隱藏的炸彈。
一句話：在發生悲劇前找出並修復漏洞，這才是測試存在最直接的價值。
來源於:http://blog.sina.com.cn/s/blog_89998f670101kd16.html