互聯網測試有什么不一樣

　　變和不變總是永恒的主題。先說說我看到的不一樣的地方。

　　1、最大的不同就是互聯網的產品很多都是自己來部署和運營，用戶只要用一個瘦客戶端就能使用。

　　這里的瘦客戶端是一個瀏覽器，一個App，或者一個需要安裝的client，但是核心的數據和業務邏輯主要在互聯網公司的機房里面，在IDC，在云端。這里和以前的C/S， B/S架構的企業系統的主要區別在于為多大范圍的人來服務以及誰來運營和運維這樣的系統。所以自然的，就多了很多的這方面的工作。

　　縮小范圍到測試這個方面，就需要考慮現網的問題。比如有下面的這些方面：

　　a、如何來監控現網功能的可用性。

　　這個需要和運維一起來做，但是運維針對的是比較通用的部分，比如機器的資源使用情況、流量和帶寬的情況，但是偏產品業務層面的，比如哪些功能是否可用，可能就需要業務測試人員來設計和開發自動化的系統來監控了。

　　b、如何來發布功能到現網

　　測試完了一般直接就發布了，所以不像傳統的軟件有那么長的測試周期，包括internal beta，external beta等過程，而且我了解到的情況，很多基于web的互聯網產品平均一天有多個發布，可大可小。所以發布可能就成了測試人員的工作，當然有相關的系統的支持。 這里還需要考慮的問題是常見的基于各種條件的灰度發布，先讓部分用戶用起來。發布完了之后還要做現網的驗證。

　　c、如何來保證或者驗證測試環境和現網是同步的

　　一旦是互聯網的這種模式，測試環境的問題就會變得比較突出，因為常常牽涉的系統比較多，有些和外部系統的接口可能很難以自己搭建或者用mock。另一方面如果保證測試環境是好的，到現網也是好的。需要相應的機制和工具來驗證和同步。

　　2、互聯網產品的節奏都很快

　　不像傳統的一個客戶端或者服務器的軟件產品，可能周期是半年，一年，甚至更長。這樣有比較充足的時間來做項目計劃，需求評審，然后是概要/詳細設計，進而有測試設計文檔，開大量的測試用例，然后有不同的測試cycle，同時也可以有很多的時間來準備測試環境和自動化測試。

　　就目前來看，互聯網的產品這樣做不太現實。這樣對測試人員也是很大的挑戰，可能看到一個需求過幾天就要開測了，用例是臨時開出來的，根本來不及自動化，也沒有很多的時間來做測試設計，然后測兩天這個功能就上線了。

　　不切身的感受很難體會到這種速度帶來的差異。所以如何在這么短的時間里面來保證測試的覆蓋度和質量，如果減少遺漏?

　　這是現實的問題，或者說是要求，有一些措施，但是其實也沒有很好的答案。

　　3、有更多的人參與到測試里面來

　　互聯網公司里面，測試vs開發的比例都很低，1：6，1：7都是很常見的，甚至更高，在這樣的配比的情況下，如果來保證質量?必須有更多的方法。比如：

　　a、開發人員的自測。

　　測試耗費更多時間很多時候是因為代碼的質量不夠好，有很多 bug，有很多討論，很多的拉代碼的次數。所以提高開發提交的代碼質量就是一個很重要的方面。有些公司是通過開發人員的強制的單元測試來保證的，有些是通過功能級別的自測來保證的。這些可以借助一些數據來反映，比如同一個版本拉代碼的次數，或者測試用例的通過率等等。

　　b、產品或者運營人員的體驗。

　　很多互聯網的產品不像傳統軟件產品，不是一個產品經理來提所有的需求。產品，或者稱為產品經理，是一個團隊，每人負責一塊來提出需求。另外很多需求可能是來自于運營團隊，和business相關，或者是不同系統的打通。每個產品經理或者運營，需要在開發人員實現了相應的功能之后到體驗環境里面來試用產品，就是所謂的體驗，看這些功能是不是他們想要的。這樣就可以在測試人員測試之前保證沒有明顯的需求理解的問題，避免浪費測試的人力和時間。

　　c、發布之前的評審。

　　不同的角色進來看對于一個已經測完的工作還有沒有問題，以及發布的時候需要注意的問題，環境的問題，配置的問題，數據的問題等等。

　　上面的一些做法可能都有幫助，但是如何來推動，如果來檢驗都是需要流程和工具來支撐。

　　4、有一些是免測試的

　　不是所有發布到現網的東西都需要測試，有些改動是不需要測試的。這個沒有一定的標準，取決于具體發布的情況，以及產品和團隊的成熟度等因素。比如一些臨時活動的頁面，一些小的圖片或者樣式的改動，一些小的修復等等。只需發布完了之后到外網去驗證。

原文轉自：http://www.uml.org.cn/Test/201106211.asp