對於雲計算，可能不同的人有不同的看法，也有些人認爲這只是一個廠商們弄出來的buzz
word，是個噱頭而已。但是不管怎樣，如果你經常關注業界動態的話，你會發現除了那幾個衆所周知的服務外，還有很多的組織真刀真槍的行動起來了，有很多
發佈了自己的戰略、計劃、平臺和產品。僅僅是在國內，最近就有很多這樣那樣的雲計算平臺，想必大家也聽說了一些。最近正好有機會了解了其中的一個，藉着一
起review test design的機會，瞭解了一下架構和他們現有的測試方法，同時大家也一起感受到了這種新的類型的產品給測試所帶來的挑戰。
在這裏我就來談談我看到的一些方面。嚴格來講，這個不能籠統的稱爲雲計算時代的測試挑戰，因爲即使在這個時代，也還是有很多傳統的產品，也有很多現在就遇到的common的問題，我這裏說的可能更多的是針對PaaS, IaaS之類的產品。
雲計算的技術這兩年在經歷飛速的發展，比如以下幾個方面：
－虛擬化平臺，這個是很多基礎架構的基石。除了兩大商業巨頭之外，Xen的發展和應用也很迅速。
－分佈式存儲，包括分佈式文件系統。現在open source的項目也有很多，大的概念還是很相近的，比如Hadoop中的HDFS和Ceph, 理解了一個再看另一個要容易很多。
－任務的分發和控制系統，比如map reduce之類的系統，提供了應用級別的任務分發和控制。
－虛擬機的部署和控制。對於任何基於虛擬化來提供雲計算資源的系統而言，這一塊是少不了的。
－
監控和分析。雲計算的一個特點就是機器（物理的和虛擬的）和服務很多，而且可能出錯的點也很多，同時性能也常常是一個問題，所以如果監控資源的使用狀況和
健康狀況，及時的發現問題也是十分的重要。現在業界用得比較多的是Nagios和Ganglia等免費的工具，當然也有對應的商業版本。
－BOSS系統。如果你是一個雲計算服務的提供商和運營商，那麼這一塊也必不可少，包括基本的業務申請、狀態查詢和繳費管理的營業支撐系統。
相對於上面提到的開發技術的快速發展而言，測試技術相對要滯後不少，目前的測試方法還無法滿足上面的要求，主要的難點體現在以下幾個方面。
關於功能測試方面
1.
對於功能測試而言，除了和傳統測試一樣的問題之外，這樣的被測系統更加的複雜，很多測試必須要理解整個系統的運作才能開展，對QA的要求提高了。測試環境
的部署花的時間和代價更大，另一方面，很多的場景比較難以模擬，比如部分機器壞掉，存儲上的不同步問題。因爲這本身就是一個open
question，什麼叫部分壞掉，什麼叫不同步，需要像做性能測試一樣先去定義。
2. 對於自動化測試，傳統的測試工具和框架也不能滿足要求。細展開來有很多方面，這裏列舉兩個。一是自動的部署的問題，因爲虛擬機也是動態生成出來的，所以要有一個合適的機制把測試工具部署上去，並且有集中的控制。二是debug會變得比較的困難。
其實更大的挑戰來源於系統級別的測試，比如性能測試和穩定性測試。
性
能是這樣的系統的訴求之一，並且可能涉及到成本，所以是很核心的要求，但是有時候會發現大家對於穩定性的要求會更高，因爲穩定性的問題會導致整個系統不可
用，是災難性的，而性能這個時候變成了第二位的。當然，也很難說這樣的思路和做法就是對的，但是很多時候不得不make it works, then
make it better. 下面說說這方面的一些問題。
1. 測試環境
這
樣的系統一套部署下來可能需要幾十臺機器，所以搭建和維護這樣的一套環境也是一個很大的開銷，也使得這種測試不像我們平時測試一個獨立的軟件產品那樣，很
容易的獲取資源，搭建一個系統，然後可以很快的不斷調整。我們可以重新搭一套模擬的系統用於測試嗎，還是必須直接在生產系統上測試？這也是一個要結合實際
情況來考慮的問題。
2. 測試的部署
這個其實本質上也是測試工具的問題，傳統用到的產生流量和壓力的工具很多都是單機的，或者controller + agents的架構，但是放到這樣的平臺下不一定適用。因爲：
a. 能否產生足夠的流量？
b. 能否比較容易的部署，包括動態生成的虛擬機？
3. 數據和sample的產生
這個和工具有一定的關係，但是我還是想把它單獨列出來，因爲這是一個不一樣的挑戰，這個和系統的需求和應用有關。關於這一部分，做過性能測試的應該都比較清楚，問題和方法也比較類似，只是這裏有個規模的問題。
4. 監控
前
面也提到這個問題，或者換個角度就是如何知道有沒有出問題，哪裏出了問題。前面提到的一個業界廣爲使用的監控平臺也可以使用，但是可能還不夠，因爲那些默
認的都是從系統的層面來看有沒有問題。而最後跑的都是應用，有意義的也是應用，所以也需要從應用的角度來看問題。比如系統的資源應用到一定的程度後，應用
（比如web service）看到的響應時間很長，或者有很多的time out
error，甚至去不到正確的數據，這些如果只是監控機器有沒有掛掉，資源使用率是不是正常是很難看出來的。
引申來看，這個和前面兩點也有關係，如果我們從應用層面，而不是純粹的跑CPU和IO stress tool，就能發現這方面的問題。
從上面個人的體會你會發現，其實這些也不是全新的東西，只是老問題在新的環境下的展現，因爲某些方面被放大而使得問題凸顯。
下面我想從另外兩個角度來說說自己的一些看法，個人觀點。
對測試工具廠商而言，也是一種挑戰。
從
上面的分析和我的體會，我覺得對於這樣的系統，哪怕只是穩定性測試，需要的不只是一套工具，而是一種諮詢＋實施的整套服務，而傳統意義上，測試工具廠商們
提供的都是一個工具和簡單的培訓。比如提供Loadrunner，SilkPerformer等傳統的應用層測試工具的廠商，還有
Spirent，IXIA，BreakingPoint等以硬件設備爲主的廠商。他們的工具可以提供很多協議流量的模擬，但這只是一部分，如何部署，如何
擴展，如何監控，都不是單純靠這些工具能完成的。
另
一方面，他們也會面臨開源測試工具的挑戰。在雲計算系統快速發展的過程中，相應的測試工具也在跟着發展，就像JMeter和apache一起成長的故事一
樣。這樣的測試工具如果伴隨着雲計算的平臺一起成長，那麼在很多方面就會更加適合雲計算的特性，不如分佈式和可擴展，以及多個工具的松耦合。希望會有越來
越多的這樣的工具出現。
對測試人員的挑戰和機會
挑戰是需要更深入的瞭解系統的運作，否則根本無法進行測試。而且要測得比較深入的話，需要對相關的技術有一定深度的瞭解。以前也需要了解，但是在瞭解不多的情況下也可以進行測試，拿出看起來還可以的測試結果，但是對於雲計算的系統，如果不深入的瞭解根本沒法進行測試。
因爲很多時候需要的是一整套方案，一個project，包含資源的組織，測試項目的協調，而不是一個工具和一個設計文檔。
如果說到機會的話簡單來說那就是測試會變成一個更需要專業技能和更有value的工作。
最後我在想一個問題，在這樣的需要一整套方案的情況下，會不會有專業的測試服務作爲獨立的business model產生？國外其實不少，很多測試大牛們同時也在開公司，提供諮詢和測試服務。國內似乎目前還很少。