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

1、大的不同是互聯(lián)網(wǎng)的產(chǎn)品很多都是自己來部署和運營，用戶只要用一個瘦客戶端能使用。

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

縮小范圍到測試這個方面，需要考慮現(xiàn)網(wǎng)的問題。比如有下面的這些方面：

a、如何來監(jiān)控現(xiàn)網(wǎng)功能的可用性。

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

b、如何來發(fā)布功能到現(xiàn)網(wǎng)

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

c、如何來保證或者驗證測試環(huán)境和現(xiàn)網(wǎng)是同步的

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

2、互聯(lián)網(wǎng)產(chǎn)品的節(jié)奏都很快

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

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

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

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

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

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

a、開發(fā)人員的自測。

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

b、產(chǎn)品或者運營人員的體驗。

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

c、發(fā)布之前的評審。

不同的角色進來看對于一個已經(jīng)測完的工作還有沒有問題，以及發(fā)布的時候需要注意的問題，環(huán)境的問題，配置的問題，數(shù)據(jù)的問題等等。

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

4、有一些是免測試的

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

有哪些可以走免測，這其實是一個很復雜的問題，當然風險也是有的，但是因此而帶來的效率的提高也是很明顯。

5、海量的用戶帶來的挑戰(zhàn)

其實有很多，這里列舉幾個

a、如何來保證或者驗證性能

傳統(tǒng)軟件的性能測試相對要單純一些，可以比較容易搭建一套環(huán)境，流量也比較容易模擬。而互聯(lián)網(wǎng)的一個產(chǎn)品可能有幾百上千臺甚至更多的服務器，多地多層部署，受到各種因素的影響，比如廣告促銷活動，一下子流量可以沖到很高。所以這方面的做法也會有所不同，全量的模擬不太現(xiàn)實，而且如上面所說，發(fā)布非？欤矝]有那么多的時間去反復的做性能測試。所以如何來做比較輕量級的性能測試也是一個很大的課題。

b、瀏覽器的兼容性。

用戶使用的瀏覽器種類可能非常多，包括大家都在罵的IE6，還有IE9的n種模式，版本更新速度火箭一般的Chrome和Firefox，以及很多種國產(chǎn)的瀏覽器。要一一覆蓋是一個很大的挑戰(zhàn)，其實不可能，但是產(chǎn)品團隊肯定希望測試能夠覆蓋更多。對于一些企業(yè)級的產(chǎn)品可以宣稱支持很少的幾種，但是互聯(lián)網(wǎng)產(chǎn)品很難這樣做，那等于放棄一些用戶。如何來設計策略？有沒有技術手段？

c、一個小的改動引起的問題可以影響到無數(shù)的用戶，而且很多時候馬上會被發(fā)現(xiàn)，那個壓力還是非常大的。整個修復的過程也是帶電操作，沒有那么多環(huán)境和時間來在內(nèi)部慢慢調整，如何來保證修復的質量？

6、問題的修復

互聯(lián)網(wǎng)的產(chǎn)品相比傳統(tǒng)的產(chǎn)品的一個優(yōu)勢或者說是特性是問題的修復比較快，因為很快可以影響到用戶，而不需要等用戶一個個去打hotfix或者patch，甚至安裝新版本。有很多時候，這種問題的發(fā)生到修復的時間很短，真是絕大部分用戶都沒有感知。有時候這個也會成為quick & dirty的一個借口，不過一般都會把現(xiàn)網(wǎng)的問題列為一個考核的指標。而且有些問題不是小問題，會構成事故。其實對于這樣的產(chǎn)品，測試人員對于漏測的壓力更大了。

7、測試工具和技術選擇上的差別

大概是因為互聯(lián)網(wǎng)自身產(chǎn)品的一些特點，各大公司都在大量的使用開源的，以及內(nèi)部開發(fā)的平臺和系統(tǒng)。相應的，測試方面用到的平臺和工具主要也是這兩種，要么是開源的工具（也可能做一些改造），要么是內(nèi)部自己開發(fā)的工具。相比而言，傳統(tǒng)軟件行業(yè)更會去購買一些商業(yè)的測試工具，比如用于性能測試、覆蓋率或者代碼檢查的工具，還有是測試用例和缺陷的管理平臺。 目前我了解到的情況，國內(nèi)幾大互聯(lián)網(wǎng)公司都是改造和自研的比較多，所以在簡歷里面列一堆大的工具的使用經(jīng)驗不一定有多大優(yōu)勢。而對于新人來說需要花不少時間來學習和熟悉這些平臺。

以上列舉了一些相比傳統(tǒng)軟件行業(yè)的不同的地方吧，但是對測試人員來說，也有很多相同或者類似的地方。

1、一樣的需要非常了解產(chǎn)品和業(yè)務

對于測試人員來說，如果不了解產(chǎn)品和業(yè)務，測試工作很難開展，因為連基本的對錯（是不是bug）都很難判斷，當然除了一些明顯的錯誤，比如js出錯這樣的信息，這種缺陷產(chǎn)品體驗的時候能夠發(fā)現(xiàn)或者等到被用戶發(fā)現(xiàn)了。所以我們還是需要花很多的時間和精力來熟悉產(chǎn)品業(yè)務。從這個角度看，沒有很大的變化，只是換了一個不同的領域而已，這個差別是不同的產(chǎn)品帶來的，而不是因為傳統(tǒng)軟件或者互聯(lián)網(wǎng)的差別帶來的。

2、一樣的需要了解產(chǎn)品的技術

這個其實和上面有點類似，測試人員需要去了解產(chǎn)品開發(fā)用到的技術，這對深度的測試，甚至和很多測試技術和工具的應用有很大的關于，比如性能分析，內(nèi)存泄露的發(fā)現(xiàn)，覆蓋率的分析等等。不去學習和了解這些，很多工作沒有辦法開展。從方向上來看沒有變化，我們也要去學習和實踐這些東西才能更好的了解。但是具體的技術可能有所不同，比如互聯(lián)網(wǎng)web的產(chǎn)品可能會常用到JS，PHP， Java， C++等語言，還有各種web服務器，cache，代理等等。

3、具體的測試技術

上面說到了一些產(chǎn)品開發(fā)的技術，其實還有一塊是測試方面的技術，其實這一塊細化來看和傳統(tǒng)的軟件開發(fā)有很多相似甚至相同的地方。比如如果來做靜態(tài)代碼的掃描、局部的性能測試方法和工具、覆蓋率的工具、自動化的一些工具和框架、一些監(jiān)控的工具等等。

從這個角度來看，技術的差異并沒有很大，當然互聯(lián)網(wǎng)有一些特別，比如很多基于web的系統(tǒng)、分布式的、多層的，會對工具提出一些要求，這個差別其實倒不是很大，因為很多傳統(tǒng)的服務器軟件也是這樣。

4、測試設計的方法

上面提到，因為產(chǎn)品發(fā)布節(jié)奏的差異，使得整個流程必須更輕更快，但是針對于一個具體功能的測試的時候，用例的設計和執(zhí)行上需要考慮的問題其實和傳統(tǒng)的沒有太大的差別。因為這個時候大家面臨的問題是一樣的，如何測這個軟件的這個功能。所以一些思路和方法還是能用得上。

綜合以上來看，局部的差異反而比較小，但是涉及到大的形態(tài)和流程方面的差異會比較大。

也可能正是因為這樣的原因，很多從傳統(tǒng)軟件到互聯(lián)網(wǎng)的人也很快能夠融入并開始發(fā)揮作用，而且退回幾年來看，現(xiàn)在各大互聯(lián)網(wǎng)公司里面的人大部分也都是來自于所謂的傳統(tǒng)軟件企業(yè)。