都說互聯網測試，到底互聯網測試和平常的有什么不一樣

　　最近一直有寫這樣一篇文章的想法，因為自己工作的變動，都是些零散的思路和想法，這里稍作整理，貼出來。正好假期的時候有朋友問到這方面的話題，希望也是一個參考。

　　其實說實話，覺得自己不是很夠資格來寫這個，畢竟開始做互聯網測試的時間不長，很多方面還在摸索和catch up中。但是另一個方面，如果真都習以為常了反倒沒有對比的新鮮感了也不想寫了。再加之今天看到韓少的那篇寫給不一樣的自己，覺得把看法寫下來，哪怕若干時日之后覺得現在的看法很stupid也無妨，那就是代表進步了。沒有進步是最可怕的事情，不是嗎?

　　當然，這個不代表公司的一些做法，更不能代表很多公司，也不能代表不同人，純屬一個剛開始從事互聯網測試(但不是剛開始做測試)的人的一些個人觀察和思考。

　　互聯網行業的人有意無意的把非互聯網的軟件都稱為傳統軟件，也就是說我們這種都是從“傳統”行業，好吧，傳統軟件行業轉過來的。也許在有些人眼里這個帶有一些自詡的成分，當然更多人是為了區分。就像我們做IT的把其他比較實體的行業稱為傳統行業一樣，似乎有某種優越感。這里不爭論這些稱謂，意義不大，有沒有價值讓市場去決定。如果把一件事情說得玄乎，那么主要有兩種可能，沒有搞明白，或者裝高深。這兩種都不太好，所以還不如看看到底有什么不同。

　　如果真要用傳統軟件行業這個詞，那么這里是指的那種需要用戶去安裝客戶端，或者需要客戶的管理員在機房去部署的那種軟件，放在光盤里也好，放到硬件里一起賣也好，又或者是為某客戶量身訂做的一套系統。

　　------------------------------- 廢話的分割線 ------------------------------

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原文轉自：http://blog.csdn.net/superqa/article/details/7430619