年薪30W的軟體測試“老司機”工作經驗

這幾天，新入職的小 MM提議“老司機”們把自己這些年的 工作經驗跟大家分享一下，讓新同學學習學習，利用空閒時間我整理了一些，可能不全，勉強看看，這也算是對自己這些年的工作總結。

 

 

 

01   階段劃分

 

1、單個模組功能測試時間相對較長，但每一個專案都應該有專門的整合測試階段，並且應該不止進行一輪。

    每一輪整合測試，應該都有自己的目的，比如第一輪整合測試，是根據整合測試要點驗證整體功能情況。

    第二輪整合測試是迴歸測試。

    第三輪整合測試是交叉測試。

    每個專案應進行幾輪整合測試，根據專案實際情況而定，而決定的因素多與工期、專案問題多少而定。

2、每個專案都應該有專項測試階段，比如介面測試、效能測試、異常測試等。（作為測試人員，應主動與專案組溝通，在本專案是否開展此項工作，最後應有書面溝通結果，最好是透過郵件確認）

 

02  測試過程文件輸出

 

1、專案需求評審後，或者專案已展開需求討論後，就應該與專案經理溝通並開始考慮測試的事情。

2、測試過程文件不能缺失，比如測試計劃、測試方案、測試用例、測試報告等，不能因為工期不夠而缺失某一部分測試文件的輸出，這樣只會給別人“你測試不夠專業”的感覺，並且不寫文件的效果並不一定比寫了文件的效果好。寫文件的目的不只是為了公司財富的積累，更多的是對自己測試思路的梳理，只有思路清晰了，測試過程才不會混亂，否則可能在測試過程中，自己首先就亂了，不知道從哪裡下手，哪裡結束。

3、 的每個階段都應該有輸出，比如計劃階段，輸出測試計劃、測試方案，執行階段輸出測試用例，系統測試結束後輸出測試報告等。整個測試過程都應該是在有條不紊的思路下開展下來的。

4、提前準備，比如測試計劃、測試方案、測試用例，能提前的，儘量提前做出來，否則到了測試執行階段，就會手忙腳亂，覺得：啊，我用例還沒寫，但開發已提交測試了，怎麼辦？先測吧，後面再來補用例。一般這種情況下，當時想的需要補充的用例，基本上都沒有補，到最後公司需要資料的時候，隨便胡亂湊，結果提交出去的資料不合格，公司很可能就會否定你這次的工作。

 

03  測試思考層面跨越

 

1、從我接觸的 人員來看，一般會從大局（整體）考慮，或者不計較個人負責或者其他人負責的人，目前來看發展得都挺不錯的。如果只是覺得把我的工作做好就可以了，其他不該我做的跟我沒關係，有這種想法的，職業發展一般都不會有太高的提升。

2、建議有一塊磚的思想，哪裡需要就可以往哪裡搬，能達到這種程度後，基本上團隊什麼事情都會想到你，那麼這個時候，你離發展的提升也就不遠了。

 

 

 

3、作為測試人員，需要避免只把自己當測試人員的思想，我們要站在更高的層面，就像我們屬於專案組，但同時又要高於專案組一樣，不能所有事情都是專案組說什麼就是什麼，一定要有自己的思想，覺得是對的就要堅持，最後都無法達成統一的需要尋求資源協助。當然，我們的想法有時候也可能會有錯的，那麼別人說的正確的意見我們也要採納，並不是 發現的所有問題都必須要解決。

 

04  溝 通

 

作為測試人員，學會溝通是我們的一門必修課。在下面幾個環節，我們需要深入思考，並積極發表自己的意見，以及與專案組的溝通。

1、需求評審時，多發表自己對需求、對產品的看法。

2、用例評審時，一定要思路清晰，有條不紊的評審用例，因為測試用例的評審是以我們為主導的。

3、測試過程中與開發確認問題時，需要積極溝通，協助開發定位問題。

4、與開發溝通時，儘量從這個問題對使用者的影響程度方面來說，這樣更具有說服力。

 

05  注 重 細 節

 

1、 過程中，每一個詞語的定義是否合適、每一個圖示的含義，都需要思考（比如專案中， **專案**工藝圖中，不同的顏色分別代表什麼含義，有沒有人去詢問過、上網查過、或者找設計的人瞭解過）。

2、文件的細節，作為測試人員，從專案開始到結束，會輸出很多測試文件，這些文件裡面，可能很多是從其他專案copy過來的，有的時間沒改、有的名字沒改、有的甚至連專案名稱都沒改…諸如此類的文件很多，凡是經過自己手寫出來的文件，一定要從頭到尾認真、仔細的讀兩遍，否則，就這一點，就可能對你的測試工作、測試能力打折。

 

06  測試技術的積累

 

1、不要老在開發面前表現自己的“小白”，時間久了，自己就可能真的會變成“小白”。

2、平時測試過程中，除了測試介面的功能之外，可以查一下資料庫，檢查資料是否寫入資料庫成功，如果自己把資料庫的資料再修改一下會怎麼樣。

3、前端測試的時候，多看看伺服器日誌資訊，很多時候前端操作的異常，透過伺服器錯誤日誌資訊可以找到問題原因，如果我們把問題原因告訴開發，將是開發比較高興的事情。

4、學會使用頁面分析或抓包工具，比如點選某個按鈕無反應的時候，我們可以透過IE瀏覽器的F12，或者fireFox的debug工具，檢視請求與響應。

5、當發現問題後，不要急著記錄問題，先自己確認問題，是否與瀏覽器、快取等有關係，確認問題後，最好還可以找到問題的根源。

總之，在測試過程中，要學會發現問題並分析問題，在測試過程中積累測試技術專業知識。