1.客戶端測試前端
用戶能夠看到的，使用界面的，web端，pc端，app，通常是在用戶的機器上去作web
2.服務端測試數據庫
服務端測試有兩種：一種是直接對WEB或者APP的服務端進行測試；另外一種是對更後端的數據庫、緩存系統、中間件、文件系統等進行測試。編程
（1）應用場景後端
這裏以銀行轉帳爲例。緩存
用戶A經過手機銀行往用戶B帳戶轉帳。
那麼客戶端這邊在輸入金額這一塊確定是須要作限制的，好比正數，小數點保留兩位等。
可是服務端可能並無作限制。
因此用戶能夠繞開客戶端界面，直接發送轉帳協議，把其中的金額改爲負數，這就致使用戶A的金額不減反增。服務器
（2）直接對WEB或者APP的服務端進行測試網絡
通常來講，這種服務端的開發人員就是WEB／APP產品團隊的開發人員，固然，測試人員跟WEB／APP的前端測試人員也是一個團隊的。這種服務端就是爲WEB／APP端提供一些後臺的接口，好比說，用戶我的信息、交易記錄的讀取和存儲等，通常都是用HTTP接口的方式提供。這種後臺的測試從流程上來講是跟隨着WEB／APP產品的發佈節奏來的，在後端開發完成接口之後，測試人員就直接用TestNG＋HttpClient寫接口測試用例、或者用Postman等工具手工測試。若是項目緊張，通常會先用Postman等工具先手工測試，等版本發佈完之後，再用TestNG＋HttpClient把自動化用例補上去，或者用Python的Nose框架。app
對於這種服務端後臺的測試人員，除了須要掌握上述的自動化測試技術以外，還有一個溝通、協調的工做，由於後臺的接口通常是同時提供給iOS／Android／WEB三個端，因此須要跟三端的測試人員協調測試進度、測試環境等事項。框架
若是遇到後端服務大的重構、或者是第一次上線預計有大流量的，那還須要對後端服務作一個性能測試，用JMeter／Grinder等工具編寫腳本並進行壓測，看看後端服務能不能撐住大流量。有些版本性能風險小的，沒必要要每次都作性能測試，能夠根據實際版本的狀況具體分析。
（3）對更後端的數據庫、緩存系統、中間件、文件系統等進行測試。
這種就相似於雲計算等後端基礎服務的測試，對於一些大的公司，會有一個專門的團隊來開發這種後端基礎服務，這種服務固然也須要測試人員來保證質量。
這類服務通常都是經過HTTP接口的方式提供給剛纔講的WEB／APP的後端使用，因此，第一個要作的也就是接口測試，也就是用Postman等工具作手工測試、用TestNG＋HttpClient或者Python的Nose框架作自動化測試。
不過，對於這類後端服務來講，接口只是暴露給外用的部分，內部邏輯一般是很是複雜的，因此，除了針對接口作測試以外，測試人員還須要細緻地瞭解這些服務端產品的技術框架及技術實現，須要瞭解到模塊的級別，對於系統框架圖、時序圖等都有很好的理解。針對這些理解去設計用例，再跟開發一塊兒討論如何實現用例。
若是這種基礎服務用了某一個開源軟件，那一般也須要測試人員能關注社區的進展，並把咱們發現的Bug及解決方案等推到社區，爲社區作貢獻。
除了接口測試以外，在咱們公司，異常測試、穩定性測試、性能測試也是服務端測試必備的測試類型。
異常測試會模擬各類異常狀況，好比硬件異常－機器掛掉的狀況下可否啓動備機、硬盤掛掉的狀況下是否會丟失數據；網絡異常－網絡突然斷掉、或者網絡流量變小的狀況；系統異常－操做系統突然掛掉的狀況。這些極端的狀況出現的時候，咱們須要驗證數據有沒有丟、能不能儘快啓動備機對外提供服務、系統狀態有沒有異常等。咱們會採用各類方式或者工具來模擬這些異常，好比用TrafficControl工具來控制網絡流量。
穩定性測試，就是模擬系統在7*24的運行下會不會出問題，通常會用接口測試或者性能測試用例不斷地跑，在運行期間，咱們會模擬各類狀況，好比說負載的變化、系統的各類干擾等。能夠用ChaosMonkey等工具來進行這類測試。
性能測試，其實細分起來會有各類類型，好比負載測試、壓力測試、配置測試、甚至還有線上壓測、容量規劃等。最常規的性能測試，通常是先規定一個系統須要承受的壓力，好比說，某一個系統，1個小時以內會有1W單的單子，那基於這個需求咱們分析服務器後端須要承受的壓力，分析出來之後，就寫性能測試腳本，而後逐漸增長壓測的力度，直到超過這個預約的壓力。一般在這個測試過程當中會發現各類問題，好比數據庫索引沒有建、線程池過小、系統異常等。須要解決了以後再加大壓力測試。也是用Grinder／JMeter等工具來進行性能測試，不過難的不是這些工具的使用，而是發現問題之後的定位。
對於這種後端服務的測試人員來講，技術上的要求是挺高的，須要有較好的編程能力，須要對數據庫、操做系統等機制有很好的瞭解才行。