一般來說，服務端測試有兩種：一種是直接對WEB或者APP的服務端進行測試；另一種是對更後端的資料庫、快取系統、中介軟體、檔案系統等進行測試。
一、先來說第一種吧：直接對WEB或者APP的服務端進行測試。
一般來說，這種服務端的開發人員就是WEB／APP產品團隊的開發人員，當然，測試人員跟WEB／APP的前端測試人員也是一個團隊的。這種服務端就是為WEB／APP端提供一些後臺的介面，比如說，使用者個人資訊、交易記錄的讀取和儲存等，一般都是用HTTP介面的方式提供。這種後臺的測試從流程上來說是跟隨著WEB／APP產品的釋出節奏來的，在後端開發完成介面以後，測試人員就直接用TestNG＋HttpClient寫介面測試用例、或者用Postman等工具手工測試。如果專案緊張，一般會先用Postman等工具先手工測試，等版本釋出完以後，再用TestNG＋HttpClient把自動化用例補上去，或者用Python的Nose框架。

對於這種服務端後臺的測試人員，除了需要掌握上述的自動化測試技術之外，還有一個溝通、協調的工作，因為後臺的介面一般是同時提供給iOS／Android／WEB三個端，所以需要跟三端的測試人員協調測試進度、測試環境等事項。

如果遇到後端服務大的重構、或者是第一次上線預計有大流量的，那還需要對後端服務做一個性能測試，用JMeter／Grinder等工具編寫指令碼並進行壓測，看看後端服務能不能撐住大流量。有些版本效能風險小的，不必要每次都做效能測試，可以根據實際版本的情況具體分析。

二、第二種：對更後端的資料庫、快取系統、中介軟體、檔案系統等進行測試。
這種就類似於雲端計算等後端基礎服務的測試，對於一些大的公司，會有一個專門的團隊來開發這種後端基礎服務，這種服務當然也需要測試人員來保證質量。

這類服務一般都是通過HTTP介面的方式提供給剛才講的WEB／APP的後端使用，所以，第一個要做的也就是介面測試，也就是用Postman等工具做手工測試、用TestNG＋HttpClient或者Python的Nose框架做自動化測試。

不過，對於這類後端服務來說，介面只是暴露給外用的部分，內部邏輯通常是非常複雜的，所以，除了針對介面做測試之外，測試人員還需要細緻地瞭解這些服務端產品的技術框架及技術實現，需要了解到模組的級別，對於系統框架圖、時序圖等都有很好的理解。針對這些理解去設計用例，再跟開發一起討論如何實現用例。

如果這種基礎服務用了某一個開源軟體，那通常也需要測試人員能關注社群的進展，並把我們發現的Bug及解決方案等推到社群，為社群做貢獻。

除了介面測試之外，在我們公司，異常測試、穩定性測試、效能測試也是服務端測試必備的測試型別。
異常測試會模擬各種異常情況，比如硬體異常－機器掛掉的情況下能否啟動備機、硬碟掛掉的情況下是否會丟失資料；網路異常－網路忽然斷掉、或者網路流量變小的情況；系統異常－作業系統忽然掛掉的情況。這些極端的情況出現的時候，我們需要驗證資料有沒有丟、能不能儘快啟動備機對外提供服務、系統狀態有沒有異常等。我們會採用各種方式或者工具來模擬這些異常，比如用TrafficControl工具來控制網路流量。

穩定性測試，就是模擬系統在7*24的執行下會不會出問題，一般會用介面測試或者效能測試用例不斷地跑，在執行期間，我們會模擬各種情況，比如說負載的變化、系統的各種干擾等。可以用ChaosMonkey等工具來進行這類測試。

效能測試，其實細分起來會有各種型別，比如負載測試、壓力測試、配置測試、甚至還有線上壓測、容量規劃等。最常規的效能測試，一般是先規定一個系統需要承受的壓力，比如說，某一個系統，1個小時之內會有1W單的單子，那基於這個需求我們分析伺服器後端需要承受的壓力，分析出來以後，就寫效能測試指令碼，然後逐漸增加壓測的力度，直到超過這個預定的壓力。通常在這個測試過程中會發現各種問題，比如資料庫索引沒有建、執行緒池太小、系統異常等。需要解決了之後再加大壓力測試。也是用Grinder／JMeter等工具來進行效能測試，不過難的不是這些工具的使用，而是發現問題以後的定位。

對於這種後端服務的測試人員來說，技術上的要求是挺高的，需要有較好的程式設計能力，需要對資料庫、作業系統等機制有很好的瞭解才行。