導讀，先從雲化說起，再談談雲化形態下，除了常規的功能測試，雲化的測試，還需要有幾個必須要get到的硬核指標，最後在分別詳解這些關鍵點硬核指標是什麼，和如何測試呢。這是個值得深思的問題，希望所有測試人都get 到這些，且比貼子說提到的做得更多，提煉出更多 check point。
先回顧一下雲化的掘起之大勢
當下oracle裁掉整個中國研發中心，正鬧得沸沸揚揚，一關鍵原因是，oracle受雲端計算等新興技術衝擊，自身業務成長乏力甚至下滑，所以更關注成本控制，從而進行戰略性人事調整，為雲端計算騰出更多資源；今天，阿里雲已超越微軟Azure，成為僅次於亞馬遜AWS的世界第二大雲端計算公司，10年前在百度和騰訊都不看好的情況下，馬雲認為雲端計算是未來，每年投入1億，不知道猴年馬月鹹魚翻身的情況下，馬雲就這樣投了王堅的阿里雲10年，最後真的把馬化騰說要1000年才做成的事給辦了！但是當時全中國沒有一家公司願意投入雲端計算這種“虛無縹緲”的事業中，最艱難的時候，80%的工程師因各種原因離開了阿里雲，十年前的王堅博士，在很多人眼中就是一個不折不扣的“騙子”。
早期雲廠商，主要提供的雲資源偏重於iaas 層，當前隨著雲端計算的深入發展，從iaas,到paas ,serverleess 加容器技術，已經成為雲廠商標配產品，雲化是一個不可逆轉的趨勢，已被大眾所接受，當然受一些非技術因素的限制或是一些歷史包袱的限制，混和雲，多雲和公有云一道將長期存在。越來越多的公司把服務放在雲端，小公司可能只是僅僅把服務搬到雲端（也就是把先前的本部署，搬到雲端）,實際上這是不真正的雲端計算，當然容災備份能力有質的提升，saas 廠商，或是大廠商，會在雲廠商的pass 平臺上，構建一個膠水層， 整合PAAS和SAAS形成自己的雲管理平臺，透明實現彈性計算，橫向擴充套件和視覺化運維監控等非功能性的管理需求。
雲化測試這些非功能性必測的硬核關鍵點必須get 到
這些非功能性硬核關鍵點和雲端計算的特性有著必然的關係，同時也和服務的可靠性，服務的計量和治理有著密切的關係。簡單來說你要保證你的雲服務的可靠性，可用性，可管理性，必須具有一些雲化後的非功能性指標，因為你業務功能再好用，不可靠，對使用者來說是沒有保障的，如下8個硬核點就是雲化的非功能指標，後續一節再分別講述，這些硬核點的的定義以及如何來測試這些點，特別是第1，第2，第3，這三個缺一不可，否則你的軟體只是搬到雲端，並不具備任何雲端計算的特性，也就是假雲。
第1彈性，也叫自動伸縮；
第2，服務無狀態；
第3 ，多租戶支援；
第4，故障轉移/隔離；
第5 ，服務限流保護；
第6 ，應用安全；
第7 ，呼叫鏈追蹤，
第8 ,視覺化服務治理（可觀測，可自動健康檢查，服務優雅關閉等）
用一個示例來說明8個硬核點以及測試方法或手段
下圖是一個在aws,建一個VPC 且通過VPN和本地服務組成一個混合雲的網路架構圖，
建立4個子網，分別用於部署：租戶註冊 Web程式、資料庫、進銷存 Web程式、進銷存 App程式；，為了實現高可用性，每種型別的子網按照可用區各建立a、b兩個。
租戶註冊成功後，呼叫CloudFormation介面，自動部署的雲進銷存業務系統。（實際是物理隔離）
再回到前述8個硬核指標
第1彈性，也叫自動伸縮
說起彈性，先從常說的雲伺服器，ecs 說起，它就是Elastic Compute Service的縮寫 ，是一種處理能力可彈性伸縮的計算伺服器，這是從IAAS （更偏硬體資源：CPU,記憶體，磁碟，網路）層來實現彈性，這解決了硬體或是底層資源的彈性;實際從提供雲服務的軟體層現來看，還要有軟體自身的彈性也就是saas或是paas層的彈性，例如，需要根據時間或是其他的策略(基於流量，或是硬體資源的特定基線)橫向擴充套件，如高峰期，掛號服務需要10個節點才能保證支撐高峰期的併發量，非高峰期，再減少掛號服務節點，騰出計算資源做其他事情。在雲上，實現叢集節點的擴充套件是很簡單的事，配置好擴充套件策略即可。測試的時候， 必須把彈性作為一個check point ,如何驗證，從前面其定義就能明白，這裡就不再重複了。現在問題來了，動態擴的服務，如何讓叢集感知，且可用呢，請看如下第2項
第2，服務無狀態；
接上一個問題，動態擴的服務，如何讓叢集感知，且可用呢?讓叢集感知有兩個辦法，一是服務在橫擴的時候，向ELB（負載均衡）動態註冊(如果擴充套件了節點，需要手動配配置並重啟負載均勻相關元件，這不叫彈性)，或是通過服務發現註冊元件來實現，這有很多成熟的技術，這裡就不多說明，重點是，新橫擴出來的服務，加到叢集后，要讓他能對處提供服務，這要求服務是無狀態的 ( 比如會話session ,或其他上下文，不依賴服務所在屬主容器，如tomcat ,jetty,weblogic ,iis等)，否則某個請求被路由到新擴的服務節點時，可能會為因為會話或上下文的問題，導致服務在業務上不可用。測試的時候， 必須把服務無狀態作為一個 check point，如果服務實現方，是通過在負載均衡上通過“ 黏住” 策略，來實現會話共享，的話，有一個大問題，當服務節點減少，或是某些服務節點掛掉時，之前這些服務節的服務的客戶端後續的請求，轉移到其他節點，session 就會丟失，通常做法是，把session或上文下外接在服務執行緒所在容器(tomcat ,jetty,weblogic ,iis等)之外，如memcache 中，redis 中。
如何驗證這個無服務的檢查點呢?假定是一個Web 程式，通過關閉單一節點，再重啟檢查，是否為同一個session。測試這個完全可以在非雲環境來驗證，用一個單單一節點來測試（非叢集模式），比如先登入，進入到某頁面，且準備做某個對session 有依賴的操作，這時，停下正要操作的功能，先停掉這個節點，然後重啟這個節點，，重啟後再在之前登入的頁面上，接著做這前的作操作，並沒有提示要重登入，或是session過期，操作成功，可以驗證；當然也可以用兩個節點來驗證(叢集模 式)，每個節點上，放兩個相面的頁面，在上面，列印出session id ,以及節點的名稱，先請求這頁面，記下列印的session id 及節點名，關掉任意一個節點，再重新整理這頁面，看看列印的session id 一樣不，如一樣，只是節點名變了，說明服務是無狀態的。還有其他方法，這裡只是拋磚引玉，提供一下思路。如純後臺API ,只要檢認證資訊是否過期，或是是否是同一個認證資訊。
第3 ，多租戶支援；
既然是雲上的服務，必須要求不同的客戶（租戶/單位/組織）都能使用，且互不影響，實現多租戶，通常有兩種隔離方式，邏輯隔離和物理隔離；邏輯隔離指，大家其用一套系統，只是在資料庫層在表中加一個欄位，資料所屬租戶；物理隔離，這每個租戶單獨部一套系統。測試的時候， 必須把多租戶支援作為一個 check point，測試方法，通過對隔離的闡述，自然就知道如驗證，支不支援多租戶，以及是以什麼方式隔離。上面示例中，租戶註冊成功後，呼叫CloudFormation介面，自動部署的雲進銷存業務系統，這實際是物理隔離。
第4，故障轉移/隔離；
雲服務，一定會有出故障的時候，為了保政故障產生的影響最小，必須有應對故障的策略，故障轉移也分兩個層面的，，一個是IAAS層的，一個是業務服務自身的故障轉移。如整個系統當機，或是有故障，利用映象，自動重新例項化一個例項，只是網路屬性未變，這是IAAS層面的,在PAAS看來，實際是和之前是無差別的，相當於，傳統方式下，快速啟用冗餘或備用的伺服器、系統、或者硬體接替它們工作；另一個是軟體層面，業務服務系統，在服務不可用時，支援的重試邏輯，同時支援重試，就要求保持冪等性（簡單說，對同一個資料做同一個操作，做一次和做N次，結果是一樣的），或對出錯的服務進行隔離，不隔離會引發雪蹦效應，或是採用服務降低的錯施。一句話，測試的時候， 必須把故障轉移/隔離作為一個 check point， IAAS層的轉移，只需向雲廠商確認即可，基本上雲廠商這層面都已實現，軟體方面的故障處理，需要根據隔離策略來執行相應的測試，細節具體根據具體應用再詳查，主要是不要漏過這個測試點。
第5 ，服務限流保護；
既然是公有云，面向的是所有你的客戶，某些情況下，訪問量會爆增，或是受到惡意的訪問攻擊，這時服務的可靠性，隱定性也必須得到保障，通過對併發訪問/請求進行限制或者一個時間視窗內的請求進行限速來保護系統，一旦達到限制速率則可以拒絕服務或者排隊等待，從而使服務不會引過多的訪問而崩潰,這就是限流。
測試方法，通過壓測，或是增加到併發量，到系統支援的極限後，系統有沒有因訪問量太大而崩潰。測試的時候， 必須把服務限流保護作為一個 check point
第6 ，應用安全；
服務放雲上，面向整個互連網，除了要應對惡意的攻擊，還要防止伺服器被劫持，還要保證資料安全，和授權內訪問等等，安全是一個很專業的一個方向，測試的時候， 也必須把安全作為一個 check point, 測試人員在這方面，只能做一些常規的安全測試，如SQL 注入，XSS跨站攻擊，敏感資訊是否明文傳輸， API的訪問是否要通過驗證,一些等存級別高的業務，還需要雙向認證,甚至實名認證等，其他的則需要請專業的安全公司進行全面的安全測試，他們能掃描出系統存在的安全漏洞和不安全的因素，並給出好的整改建議。
第7 ，呼叫鏈追蹤，
這要看服務是否是一個分散式應用，分散式應用中，系統存在互相呼叫的情況，形成一個 呼叫鏈，通常一個請求，會引發A元件，呼叫B,元件，B元件呼叫C ，C呼叫D，可能還有更長的呼叫鏈，實話說，呼叫鏈追蹤，有點偏向於運維，在測試時，分散式環境下，不借助呼叫鏈追蹤有些問題根本沒法定位，比如說，某個請求出錯了，實際是錯呼叫鏈的哪個節點上，或是某個功能很慢，慢在哪，不借助於呼叫鏈追蹤，你都沒辦法跟程式，就算讓研發自己打斷點，也要搞死人的，分散式加叢集，同一個服務，每次呼叫時，呼叫鏈都可能不一樣。上雲的應用，通常是分散式用，作為測試人員，也有必要把呼叫鏈追蹤作為一個 check point,才能在分散式場景下，提出定位更準，更專業的問題，而不只在BUG的表像上。開源呼叫鏈追蹤有zipkin,pinpoint，skywalking等。呼叫鏈跟蹤需要研發那邊來整合，測試這邊要get到這個點和會使用。下圖是昨天用zipkin 的一個截圖示例
第8 ,視覺化服務治理（可觀測，可自動健康檢查，服務優雅關閉等）
服務治理，也是偏運維的東東，他自身的定義，各位可以自行百度；在這裡，我只簡單場景上來說明，服務治理的大概意思，你的服務在雲上，可靠性要有保障，主要在於預防，不能抓瞎，真正問題發生了，就炸鍋了，需要通過視覺化的方式，觀測到服務的狀態，健康狀態，流量情況，響應速度，併發量，資源使用情況等，並根據於些，採用自動或半自動的方式啟動彈性擴充套件，或是採取隔離，熔斷等措施，以保障服務的可用性。在devOps 大行其道的當下，測試人員向運維多靠一點不是壞事，會給測試提供更多靈感和帶來更多測試手段。雲上的服務。服務優雅關閉，順帶提一下，要關閉某個服務時，正在服務中執行相關業務執行緒會同進被關掉，也就意味著這些業務操作肯定要失敗，與之相反服務優雅關閉,指在關閉前，他會拒絕新的進求進來，同時要完成當前的所有業務後，才關閉，有點像銀行的視窗，不接受業務了，但要把當前正辦理的業務處理完。測試人員以此作為一個 check point ，可用來驗證雲服務實現水平的高低，又能為服務的可靠性測試提代相關測試手段/方法，這個點也要get 到。
總結來說，就是測試雲上應用，除了業務功能自身的測試，還要測試上述提到的8個非業務功能硬核點，特別是前3點，是區分真雲，假雲最關鍵點；雲化絕對是不可你逆轉的趨勢，測試人的相關觀念也要以時具進，才能跟上發展的需要。當然個人水平有限，認知有限，論述後可能會存在偏頗之處，歡迎拍磚和補充。itest 測試技術團隊，一直關注測試新技術，新前沿，並以itest 開源管理測試軟體作為理念的落地實現，itest ,是一款匯聚10年經驗，流程驅動測試的開源的測試管理軟體，是我們測試人自己開發測試管理軟體，體現我們對測試的情懷，是最懂測試人的開源測試管理軟體新秀 ；Itest 開源團隊成員由來自對軟體測試有情懷，熱衷於開源，又熱心傳播分享我們測試理念的一群人組成。(流程驅動開源測試管理軟體新秀官網)
