網際網路測試有什麼不一樣
阿新 • • 發佈：2018-12-27
最近一直有寫這樣一篇文章的想法，因為自己工作的變動，都是些零散的思路和想法，這裡稍作整理，貼出來。正好假期的時候有朋友問到這方面的話題，希望也是一個參考。 其實說實話，覺得自己不是很夠資格來寫這個，畢竟開始做網際網路測試的時間不長，很多方面還在摸索和catch up中。但是另一個方面，如果真都習以為常了反倒沒有對比的新鮮感了也不想寫了。再加之今天看到韓少的那篇寫給不一樣的自己，覺得把看法寫下來，哪怕若干時日之後覺得現在的看法很stupid也無妨，那就是代表進步了。沒有進步是最可怕的事情，不是嗎? 當然，這個不代表公司的一些做法，更不能代表很多公司，也不能代表不同人，純屬一個剛開始從事網際網路測試（但不是剛開始做測試）的人的一些個人觀察和思考。
網際網路公司裡面，測試vs開發的比例都很低，1:6，1:7都是很常見的，甚至更高，在這樣的配比的情況下，如果來保證質量？必須有更多的方法。比如 a. 開發人員的自測。 測試耗費更多時間很多時候是因為程式碼的質量不夠好，有很多bug，有很多討論，很多的拉程式碼的次數。所以提高開發提交的程式碼質量就是一個很重要的方面。有些公司是通過開發人員的強制的單元測試來保證的，有些是通過功能級別的自測來保證的。這些可以藉助一些資料來反映，比如同一個版本拉程式碼的次數，或者測試用例的通過率等等。 b. 產品或者運營人員的體驗。 很多網際網路的產品不像傳統軟體產品，不是一個產品經理來提所有的需求。產品，或者稱為產品經理，是一個團隊，每人負責一塊來提出需求。另外很多需求可能是來自於運營團隊，和business相關，或者是不同系統的打通。每個產品經理或者運營，需要在開發人員實現了相應的功能之後到體驗環境裡面來試用產品，就是所謂的體驗，看這些功能是不是他們想要的。這樣就可以在測試人員測試之前保證沒有明顯的需求理解的問題，避免浪費測試的人力和時間。 c. 釋出之前的評審。 不同的角色進來看對於一個已經測完的工作還有沒有問題，以及釋出的時候需要注意的問題，環境的問題，配置的問題，資料的問題等等。 上面的一些做法可能都有幫助，但是如何來推動，如果來檢驗都是需要流程和工具來支撐。 4. 有一些是免測試的 不是所有釋出到現網的東西都需要測試，有些改動是不需要測試的。這個沒有一定的標準，取決於具體釋出的情況，以及產品和團隊的成熟度等因素。比如一些臨時活動的頁面，一些小的圖片或者樣式的改動，一些小的修復等等。只需釋出完了之後到外網去驗證。 有哪些可以走免測，這其實是一個很複雜的問題，當然風險也是有的，但是因此而帶來的效率的提高也是很明顯。 5. 海量的使用者帶來的挑戰 其實有很多，這裡列舉幾個 a. 如何來保證或者驗證效能 傳統軟體的效能測試相對要單純一些，可以比較容易搭建一套環境，流量也比較容易模擬。而網際網路的一個產品可能有幾百上千臺甚至更多的伺服器，多地多層部署，受到各種因素的影響，比如廣告促銷活動，一下子流量可以衝到很高。所以這方面的做法也會有所不同，全量的模擬不太現實，而且如上面所說，釋出非常快，也沒有那麼多的時間去反覆的做效能測試。所以如何來做比較輕量級的效能測試也是一個很大的課題。 b. 瀏覽器的相容性。 使用者使用的瀏覽器種類可能非常多，包括大家都在罵的IE6，還有IE9的n種模式，版本更新速度火箭一般的Chrome和Firefox，以及很多種國產的瀏覽器。要一一覆蓋是一個很大的挑戰，其實不可能，但是產品團隊肯定希望測試能夠覆蓋更多。對於一些企業級的產品可以宣稱就支援很少的幾種，但是網際網路產品很難這樣做，那就等於放棄一些使用者。如何來設計策略？有沒有技術手段？ c. 一個小的改動引起的問題可以影響到無數的使用者，而且很多時候馬上會被發現，那個壓力還是非常大的。整個修復的過程也是帶電操作，沒有那麼多環境和時間來在內部慢慢調整，如何來保證修復的質量？ 6. 問題的修復 網際網路的產品相比傳統的產品的一個優勢或者說是特性就是問題的修復比較快，因為很快就可以影響到使用者，而不需要等使用者一個個去打hotfix或者patch，甚至安裝新版本。有很多時候，這種問題的發生到修復的時間很短，真是絕大部分使用者都沒有感知。有時候這個也會成為quick & dirty的一個藉口，不過一般都會把現網的問題列為一個考核的指標。而且有些問題不是小問題，會構成事故。其實對於這樣的產品，測試人員對於漏測的壓力就更大了。 7. 測試工具和技術選擇上的差別 大概是因為網際網路自身產品的一些特點，各大公司都在大量的使用開源的，以及內部開發的平臺和系統。相應的，測試方面用到的平臺和工具主要也是這兩種，要麼是開源的工具（也可能做一些改造），要麼是內部自己開發的工具。相比而言，傳統軟體行業更會去購買一些商業的測試工具，比如用於效能測試、覆蓋率或者程式碼檢查的工具，還有就是測試用例和缺陷的管理平臺。 目前我瞭解到的情況，國內幾大網際網路公司都是改造和自研的比較多，所以在簡歷裡面列一堆大的工具的使用經驗不一定有多大優勢。而對於新人來說需要花不少時間來學習和熟悉這些平臺。 ----------------------------------------- 變和不變的分割線 ------------------------------------ 以上列舉了一些相比傳統軟體行業的不同的地方吧，但是對測試人員來說，也有很多相同或者類似的地方。 1. 一樣的需要非常瞭解產品和業務 對於測試人員來說，如果不瞭解產品和業務，測試工作很難開展，因為連最基本的對錯（是不是bug）都很難判斷，當然除了一些明顯的錯誤，比如js出錯這樣的資訊，這種缺陷產品體驗的時候就能夠發現或者等到被使用者發現了。所以我們還是需要花很多的時間和精力來熟悉產品業務。從這個角度看，沒有很大的變化，只是換了一個不同的領域而已，這個差別是不同的產品帶來的，而不是因為傳統軟體或者網際網路的差別帶來的。 2. 一樣的需要了解產品的技術 這個其實和上面有點類似，測試人員需要去了解產品開發用到的技術，這對深度的測試，甚至和很多測試技術和工具的應用有很大的關於，比如效能分析，記憶體洩露的發現，覆蓋率的分析等等。不去學習和了解這些，很多工作沒有辦法開展。從方向上來看沒有變化，我們也要去學習和實踐這些東西才能更好的瞭解。但是具體的技術可能有所不同，比如網際網路web的產品可能會常用到JS，PHP, Java, C++等語言，還有各種web伺服器，cache，代理等等。 3. 具體的測試技術 上面說到了一些產品開發的技術，其實還有一塊是測試方面的技術，其實這一塊細化來看和傳統的軟體開發有很多相似甚至相同的地方。比如如果來做靜態程式碼的掃描、區域性的效能測試方法和工具、覆蓋率的工具、自動化的一些工具和框架、一些監控的工具等等。 從這個角度來看，技術的差異並沒有很大，當然網際網路有一些特別，比如很多基於web的系統、分散式的、多層的，會對工具提出一些要求，這個差別其實倒不是很大，因為很多傳統的伺服器軟體也是這樣。 4. 測試設計的方法 上面提到，因為產品釋出節奏的差異，使得整個流程必須更輕更快，但是針對於一個具體功能的測試的時候，用例的設計和執行上需要考慮的問題其實和傳統的沒有太大的差別。因為這個時候大家面臨的問題是一樣的，如何測這個軟體的這個功能。所以一些思路和方法還是能用得上。 綜合以上來看，區域性的差異反而比較小，但是涉及到大的形態和流程方面的差異就會比較大。 也可能正是因為這樣的原因，很多從傳統軟體到網際網路的人也很快就能夠融入並開始發揮作用，而且退回幾年來看，現在各大網際網路公司裡面的人大部分也都是來自於所謂的傳統軟體企業。 ---------------------------------- 其他的廢話 --------------------------------------------- 我相信不同的領域的發展速度和機會是不一樣的，這也是這幾年很多人投身到網際網路行業的原因之一，這個就好比經濟學上所謂的市場對於資源配置的驅動力一樣，很正常。但是另一個方面，會讓人有一種錯覺，以為換到一個快速發展的行業，自己立馬變強了。其實冷靜的來看，並不會如此，只是趕了個浪潮，真正的技術和能力不會因為你換了一個領域或者行業就變得強大或者高深了，要獲得這樣的提高一定是因為更多的學習，實踐和思考，以及和別人的交流而慢慢得到的。 上面提到了網際網路產品，其實有些時候，這是一個偽命題，因為在各大網際網路公司都有傳統軟體，比如騰訊百度阿里都有客戶端的產品，而且數量還不少，有些還有C/S架構的產品，國外的google也有chrome，picasa這種桌面的產品，facebook也出了IM客戶端。所以在很大程度上，還是非常的需要比如Windows GUI產品的開發和測試技術，伺服器類似企業級產品的方法和能力。當然，這些產品背後是連到網際網路的，所以也有差異的部分，但是沒有想象的那麼大。 另外一個問題，有些時候大家在借網際網路軟體這個名字來逃避一些東西，比如一些不嚴謹，或者混亂的地方，就全部歸結到這是網際網路的特性，這個是一個“度”的問題，要自己去分辨。 另一個問題，對於初入網際網路測試的人有什麼建議呢？下面這些也是自勉。 1. 正視這種差異帶來的改變，上面說的一些東西真的也是很大的不同，所以要積極的學習和了解。 2. 努力的去學習產品相關的知識，包括相關的開發技術，這樣才能更好的開展工作。 3. 要經常反思，之前在一個環境下對一個東西研究得很清楚了，但是換個環境之後可能老的經驗和知識並不完全適用。所以少說我們以前是怎麼樣的？ 絕不生搬硬套，而是瞭解了情況，理解了問題之後看哪些做法是可以借鑑的？區域性的借鑑可能更靠譜。 也正是因為這樣的原因，大家會發現學習的曲線很陡，而且會樂在其中。 好了，就先寫到這裡，希望過幾個月，會有更多更深刻的認識。