如果我們真的要用傳統軟件行業這個詞，那麽這是指需要用戶安裝客戶端的軟件，或者需要客戶的管理員在機房部署的軟件，無論是光盤還是硬件，或者是為客戶量身定制的系統。
變與不變永遠是永恒的主題。先說說我看到的不同地方。互聯網行業與傳統軟件的區別；
1.最大的不同是，很多互聯網產品都是自己部署和運營的，用戶用壹個瘦客戶端就可以使用。
這裏的瘦客戶端是壹個瀏覽器，壹個App，或者壹個需要安裝的客戶端，但是核心的數據和業務邏輯主要在互聯網公司的機房，在IDC，在雲端。在C/S之前，
基於B/S架構的企業系統的主要區別在於服務的人群範圍，以及誰來操作和維護這樣的系統。因此，自然地，這方面的工作就多了很多。
為了縮小測試的範圍，我們需要考慮生產環境。例如，有以下幾個方面:
A.如何監控生產環境功能的可用性？
這個需要和運維壹起做，但是運維針對的是更壹般的部分，比如機器的資源使用情況，流量，帶寬，但是偏於產品業務層面，比如有沒有功能可用。
業務測試人員需要設計和開發壹個自動化系統來監控。
B.如何將功能發布到官方運行環境(生產環境)
測試之後壹般會直接發布，所以沒有傳統軟件那麽長，包括內測、外測等過程，而我了解到的是很多基於它的互聯網產品平均壹天。
有多個版本，可大可小。所以發布可能會成為測試人員的工作，當然是在相關系統的支持下。這裏需要考慮的問題是基於各種條件的常用灰度釋放，讓部分用戶先使用。
發布後，需要驗證生產環境。
c .如何確保或驗證測試環境和生產環境是同步的？
壹旦互聯網處於這種模式，測試環境的問題會更加突出，因為涉及的系統很多，壹些與外部系統的接口可能很難自己搭建或者使用mock。另壹方面，如果測試環境好，生產環境也是好的。驗證和同步需要相應的機制和工具。
把範圍縮小到發展。應考慮互聯網的壹些特征，如以下幾個方面:
a如何快速定位，問題在於根據需求設計哪個模塊或哪些模塊，並給出解決方案。
壹般來說，新增加的功能或模塊更容易像傳統項目壹樣進行規劃、設計軟件、開發和測試。但是，如果是生產環境中的問題，您需要非常熟悉原始的業務和軟件架構，並且能夠快速定位問題所在的頁面和涉及的頁面。從壹個從傳統軟件轉行的互聯網工程師的角度來看，其實壹個web程序就是壹個軟件的集合。每個網頁都是壹個獨立的小程序。它們要麽是非常獨立的，只是通過壹個鏈接跳轉，要麽是壹組頁面組成壹個程序的集合，實現壹個特定的功能。畢竟多個dll是獨立存在的。因此，從傳統軟件工程師的角度來看，壹個web程序應該由壹個管理程序集合的概念來管理。具體怎麽做？首先，負責開發的技術人員分為三類，壹類是高級編碼人員，最好是原模塊開發人員。他們非常熟悉模塊的需求以及設計和實現架構，但他們只分析反饋CR的需求。屏蔽壹些不合理的修改意見，分析要修改的需求，設計修改方法，判斷修改涉及的範圍。第二種是中級編碼員，只和高級編碼員交流，執行他的設計思路。第三類是初級編碼員負責與高級編碼員溝通，了解修改範圍。做好開發人員對中間編碼器的修改自檢，完成相關文檔，並由高級編碼器審核。
b如何判斷開發的功能是可以的？
在高級編碼員的審核中，需要通過三類編碼員的文檔來確認編碼員的實現是否符合原設計。當然，設計的時候最好提前和第二類編碼員溝通。隨著團隊的不斷默契，可以是初級編碼員快速掌握業務邏輯和自測方法，同時熟悉開發人員使用的工具。成長，然後成為壹名中級程序員。同事的中級編碼員在實現設計的同時也在不斷成長，這樣才能勝任需求分析和軟件設計的工作，成為高級編碼員，這樣整個小團隊就很厲害了。這種方法類似於抗日名將戚繼光的鴛鴦陣，專門用來對付個人強，武功高的倭寇。
如何確保web程序在生產環境中的穩定性
減少發布次數是保證web程序穩定性最有效的措施，但如果是緊急問題，可以當天發布。例如，我們正在向美國提供技術支持。我們可以用中午作為測試截止時間，在中午2點測試通過的當天5點發布。如果2點失敗，則延期到第二天。
2.互聯網產品的節奏很快。
不像傳統的客戶端或服務器軟件產品，周期可能是半年，壹年甚至更長。這樣就有充足的時間做項目規劃，需求評審，然後是概要/詳細設計，然後是測試設計測試用例，然後是不同的測試周期，同時也有充足的時間準備測試環境和自動化測試。
目前互聯網產品這麽做不太現實。這對測試人員來說也是壹個很大的挑戰。可能看到壹個需求過幾天就要測試，用例臨時打開，沒有時間自動化，也沒有太多時間做測試設計。然後過兩天功能上線。沒有親身經歷，很難理解這種速度帶來的不同。那麽如何在這麽短的時間內保證測試的覆蓋面和質量，又如何減少疏漏呢？這是壹個現實的問題，或者說要求，有壹些措施，但是實際上並沒有很好的答案。
更多的人參加測試。
在互聯網公司，測試vs開發的比例很低，1:6和1:7很常見，甚至更高。這樣的比例下，如何保證質量？肯定有更多的方法。例如
A.開發者的自測。
測試需要更多的時間，因為代碼的質量不夠好。有很多很多討論，很多次拉代碼。所以提高開發提交的代碼質量是壹個非常重要的方面。有些公司通過開發做到這壹點。
人員的強制單元測試是有保證的，有些是通過功能級的自測來保證的。這些可以通過壹些數據來體現，比如同壹個版本的代碼被拉的次數，或者測試用例的通過率等等。
B.產品或操作員的經驗。
不像傳統的軟件產品，很多互聯網產品不是壹個產品經理提供的。產品，或者說產品經理，就是壹個團隊，每個人負責提出需求。另外，很多需求可能來自運營團隊，與業務有關，或者不同系統的開通。每個產品經理或運營人員都需要在開發者實現相應功能後，在體驗環境中試用產品，這就是所謂的體驗，看看這些功能是不是自己想要的。這樣可以保證測試人員在測試之前沒有明顯的需求理解問題，避免浪費測試的人力和時間。
C.發布前審查。
不同的角色進來看壹個測試過的作業有沒有問題，以及發布時需要註意的問題，環境問題，配置問題，數據問題等等。上面的壹些做法可能是有幫助的，但是如何推廣，如果經過測試，需要流程和工具來支持。
4.有些是免試的。
並不是所有發布到生產環境中的東西都需要測試，有些變化不需要測試。這個沒有壹定的標準，要看具體的發布情況以及產品和團隊的成熟度。比如壹些臨時的活動頁面，壹些小圖片或者風格的改變，壹些小的修復等等。發布後去外網驗證即可。
能避免什麽，其實是壹個很復雜的問題。當然有風險，但帶來的效率提升也是顯而易見的。
5.海量用戶帶來的挑戰
事實上，有很多，這裏有幾個:
A.如何保證或驗證性能
傳統軟件的性能測試相對簡單，更容易搭建環境，模擬流量。互聯網的壹個產品可能有上百臺甚至更多的服務器，部署在很多地方，很多層。由於各種因素，如廣告和促銷活動，流量可以壹下子沖到很高的水平。所以這方面的做法會有所不同，全模擬不太現實，而且如上所述，發布很快，沒有那麽多時間反復做性能測試。所以如何做壹個輕量級的性能測試也是壹個很大的話題。
B.瀏覽器兼容性。
用戶使用的瀏覽器可能有很多種，包括大家都在罵的IE6，版本更新速度火箭般的IE9、Chrome、Firefox的N種模式，還有很多國產瀏覽器。要全部覆蓋是壹個很大的挑戰，但這是不可能的，但產品團隊肯定希望測試能覆蓋更多。對於壹些企業產品，可以宣稱只支持少數產品，但互聯網產品很難做到，相當於放棄了壹部分用戶。如何設計策略？有什麽技術手段嗎？
C.如何在沒有輸入限制和任意操作的情況下，保證被改變事物的健壯性。
壹個小小的改動引起的問題，可以影響無數用戶，很多時候會馬上被發現。那壓力還是很大的。整個修復過程也是帶電操作，沒有那麽多環境和時間在裏面慢慢調整。如何保證維修質量？
6.解決問題
互聯網產品相對於傳統產品的壹個優勢或者說特點就是問題可以快速修復，因為用戶很快就可以受到影響，不需要等待用戶打補丁或者打補丁甚至安裝新版本。很多情況下，這個問題從發生到修復的時間很短，真的是大部分用戶都沒有察覺到。有時這也會很快&；骯臟的借口，但它通常是
生產環境問題被列為評價指標。而且有些問題不是小問題，可能會出事故。事實上，對於這類產品，測試人員錯過測試的壓力更大。
7.測試工具和技術選擇的差異
大概是因為互聯網產品的壹些特點，各大公司都在大量使用開源和內部開發的平臺和系統。相應的，測試中使用的平臺和工具主要是這兩種，要麽是開源工具(或者可能會做壹些修改)，要麽是內部開發的工具。相比之下，傳統軟件行業會購買壹些商業測試工具，比如用於性能測試、覆蓋或代碼檢查的工具，以及壹個測試用例及缺陷的管理平臺。
目前我了解到國內幾大互聯網公司都在轉型和自研，在簡歷中列舉大量使用大型工具的經驗不壹定有優勢。對於新人來說，需要花費大量的時間去學習和熟悉這些平臺。
以上列舉了壹些與傳統軟件行業相比的不同之處，但對於測試人員來說，互聯網行業與傳統軟件的相似之處在於:
1.同樣需要對產品和業務有很好的了解。
對於測試人員來說，如果不了解產品和業務，很難開展測試工作，因為連最基本的對錯(bug與否)都很難判斷。當然，除了壹些明顯的錯誤，比如js錯誤，這種缺陷產品是可以在體驗的時候發現的，或者直到被用戶發現。所以我們還是需要花大量的時間和精力去熟悉產品業務。從這個角度來說，沒有什麽大的變化，只是領域不同而已。這種差異是產品不同帶來的，而不是傳統軟件或者互聯網的差異。
2.同樣需要了解產品的技術。
這個其實和上面有點類似。測試人員需要了解產品開發中使用的技術，這與深入測試乃至很多測試技術和工具的應用非常相關，比如性能分析、內存泄漏發現、覆蓋分析等等。不學習和了解這壹點，很多工作就無法開展。方向上沒有變化，這些東西還要學習和實踐才能更好的理解。但是，具體技術可能會有所不同。比如Internet web的產品，可能普遍使用JS、PHP、Java、C++等語言，以及各種web服務器、緩存、代理等等。
3.特定測試技術
上面提到的產品開發的技術，其實還有壹塊測試技術。事實上，這壹塊的細化和傳統的軟件開發有很多相似甚至是相似之處。比如我們做靜態代碼掃描，本地性能測試方法和工具，覆蓋工具，自動化工具和框架，監控工具等等。
從這個角度來說，技術上並沒有太大的區別。當然，互聯網比較特殊，比如很多基於web的系統，分布式的，多層的，這些都會對工具提出壹些要求。這個區別其實不是很大，因為很多傳統的服務器軟件也是這樣的。
4.測試設計方法
如前所述，由於產品發布節奏的不同，整個過程必須更輕更快，但在測試壹個具體的功能時，用例的設計和實現需要考慮的問題，其實和傳統的並沒有太大的區別。因為這個時候大家都面臨著同樣的問題，如何測試這個軟件的這個功能。所以有些思路和方法還是可以用的。
整體來說，局部的差異比較小，但是涉及到大的形式和流程的差異會比較大。
也可能正是因為這個原因，很多從傳統軟件到互聯網的人很快就能融合並開始發揮作用，而幾年後，各大互聯網公司的人也大多來自所謂的傳統軟件公司。
我相信不同領域的發展速度和機會是不壹樣的，這也是近年來很多人投身互聯網行業的原因之壹。這就好比經濟學上所謂的市場對資源配置的驅動力，很正常。但另壹方面，人們會有壹種錯覺，覺得轉行到壹個快速發展的行業，自己馬上就變強了。其實平心靜氣，也不會這樣。只是壹波。真正的技能和能力不會因為妳換了壹個領域或行業而變得強大或深刻。要想得到這樣的提升，必須要因為更多的學習、練習和思考，以及與他人的交流而慢慢得到。
上面提到的互聯網產品，其實有的時候，這是壹個偽命題，因為各大互聯網公司都有傳統軟件，比如騰訊、百度、阿裏都有客戶端產品，而且數量相當多，有的還有C/S架構的產品。國外谷歌也有chrome、picasa等桌面產品，facebook也有IM客戶端。所以很大程度上還是非常需要GUI產品的開發和測試等技術，以及類似企業級產品的服務器的方法和能力。當然，這些產品都是聯網的，所以有壹些差異，但沒有想象中的那麽大。
另外壹個問題，有時候人們用互聯網軟件的名字來回避壹些事情，比如壹些不嚴謹或者混亂的地方，這都歸結於互聯網的特點。這是壹個“度”的問題，要自己區分。
另外壹個問題，妳對剛接觸互聯網測試的人有什麽建議？以下也是自我鼓勵。
1.正視這種差異帶來的變化。上面說的有些東西真的不壹樣，要積極學習了解。
2.努力學習產品相關的知識，包括相關的開發技術，從而更好的開展工作。
3.時刻反省。我以前在壹個環境下研究壹個東西很清楚，但是換個環境後舊的經驗和知識不壹定完全適用。所以我們就不要說以前的我們了。千萬不要生搬硬套，而是要了解情況，了解問題後看看有哪些做法可以借鑒。部分參考可能更可靠。