導讀，先從雲化說起，再談談雲化形態下，除了常規的功能測試，雲化的測試，還需要有幾個必須要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 開源團隊成員由來自對軟件測試有情懷，熱衷於開源，又熱心傳播分享我們測試理念的一群人組成。(流程驅動開源測試管理軟件新秀官網)
