云測試的兩種類型——云與性能測試
近年來，隨著云計算技術的發展和各種諸如AWS、GCP、阿里云等云平臺的日趨成熟，越來越多的的用戶選擇把系統搭建在云端，因此云測試的概念隨即產生。
云測試看字面意思就是關于云計算、云平臺的測試，而它大體又可以分成兩種類型：測試云(Test Cloud)和用云測試(TaaS)。 測試云，顧名思義測試的目標是云，測試者通過設計測試去保證云平臺本身和部署在云端的應用正確性。而用云測試是指利用搭建在云端的測試服務 -- TaaS (Test as a Service)來進行更高效的測試。云計算有著超大規模、虛擬化、高可靠性、高可伸縮性和按需服務等諸多優點，但平臺的特殊性也給測試帶來了新的挑戰和機遇，其中性能測試受其影響頗深，本文旨在針對云測試的兩種類型探討云與性能測試。
測試云
云環境***的特點就是能夠通過高伸縮性按需為用戶分配資源，也正是因為這個特點，我們對于基于云平臺的性能測試與普通系統性能測試的***的區別就是要考慮測試云服務的伸縮功能，因為云服務的伸縮功能可能存在以下風險：
- 云服務的auto scaling 不能執行
- Auto scaling會造成服務崩潰
- Scaling up時資源不足
因此我們設計的測試應該包含以下內容：
測試目標
- 確認auto scaling能夠根據所制定的策略執行
- 確認auto scaling能得到相應的資源
- 確認云服務的性能能夠滿足不同的壓力變化
測試方法
給云端系統一直施加壓力到性能邊界值后繼續加壓，隨后給系統減少壓力，觀察系統在邊界值前后的性能表現。
測試技術
- 利用load profile進行施壓
- 邊界值分析
- Process cycle test
測試步驟
- 給系統施加壓力，壓力不會超過性能邊界值
- 維持壓力一段時間，確保系統在壓力下的錯誤率在可接受范圍內
- 給系統施加更多的壓力，使系統超過性能邊界值，我們期望系統會自動scale up
- 系統scale up之后，我們期望response time會下降，但是不會觸發scale down
- 維持壓力一段時間，確保系統在scale up后一段時間內的的錯誤率在可接受范圍內
- 降低系統的壓力到性能scale up前的狀態，確保系統可以自動scale down
- 系統scale down之后，我們期望response time會有上升但不會重新引起scale up
期望結果
TaaS
在TaaS出現前，性能測試一般都是在本地的測試環境中通過幾臺電腦對被測環境加壓進行的，在這種模式下，測試環境的搭建和維護不僅要耗費大量資源，而且測試環境由于并不能完全模擬真實生產環境以至于測試結果存在一定的局限性。而云計算出現后，一些基于云端性能測試服務(CLT - Cloud Load Test)相比于本地的性能測試展現出了很多優點：
- CLT更簡單，大多數情況下, 云端的資源更好管理，環境更容易搭建，用戶只需設置簡單的一些參數或者提供簡單的測試腳本就能在云端執行測試。同時，很多CLT工具允許用戶把不同性能測試工具的自動化腳本如Gatling，Jmeter，Selenium直接移植使用，為用戶節省了二次開發時間。
- CLT工具可以提供更多的load generator，壓力測試中用戶通過在云端啟動load generator對被測系統進行施壓，因為在云端可以調用資源體量巨大，因此用戶可以完全模擬生產環境中可能面對的超大壓力。
- 測試成本低。CLT提供的測試服務是按照云端機器的運行時間進行收費。在沒有測試需求時，用戶并不用為機器的運行和維護買單，大大降低了用戶實施性能測試的成本，為一些沒有大型長期性能測試需求的企業節省了許多開支。
- CLT提供的測試硬件資源大多分布在全球不同區域，在進行性能測試時，用戶可以根據可能的實際情況選擇不同區域的機器定制化的為被測系統加壓，所得的測試結果由于更接近真實的網絡情況而更加準確。
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
