軟件測試新人怎樣快速成長 軟件測試工程師
1、閱讀需求文檔，深入了解系統，磨刀不誤砍柴工，不要還沒弄清需求就開測了，（一個星期前，公司剛進一個新人，TD上查看了下他們發的 BUG，發現好幾個是需求不明確誤發的）心想：原來是這個系統啊，項目實訓的時候做過和這個類似的項目，于是就把實訓的系統需求硬生生的搬到當前系統來，這樣做的風險太大，因為每個系統的需求都不一樣，不能生搬硬套，打個比方：假設要你制造一輛轎車，你以前制造過普桑，就把你制造普桑的技術拿去制造林肯，這樣做顯然不合適。熟悉系統（一般公司都會有系統熟悉情況考核）所以請一定要認真的閱讀需求文檔（有的公司叫產品定義）
2、熟悉測試用例，這是測試執行的一個導向，要想快速高效率的執行用例，必須在熟悉系統的同時，熟悉用例，熟悉每條用例覆蓋的需求，這樣執行起來才能事半功倍
3、記住自己在工作中扮演的角色是測試而不是開發 。珍惜時間，避免不必要的浪費。作為一個測試新人來講，剛開始接觸項目，有很多時候發現BUG，只是知道它的表象特征，卻無法弄清這個缺陷是由什么引起的，這里就存在一個誤區，花過多的時間去尋找原因，因為受個人所學習知識和經驗上的限制，有的缺陷很難短時間內找到產生原因，與其這樣浪費時間，不如將BUG重現給開發看一下，讓開發找原因，那樣即不耽誤下面的測試也能在短時間內找出原因，從根本上解決BUG。
4、一旦發現缺陷，應立刻提交。有幾種情況：測試就像是一場優勝劣汰的戰斗，你的動作慢了，成果就是別人的了。
1）作為一個測試新人來講，測試的第一步，可能是從執行用例開始，而成功的用例（項目剛開始時）可以發現很多系統中存在的問題，同一條case里的不同STEP就可能發現多個BUG，那么對于這樣的情況，我們要做的是：發現就提交，不要等到所有STEP都執行完再提交。那樣說不定已經被別人提交了。
2）‘拋開’需求說明書（即不用看需求說明書，對需求也特別熟悉），以快取勝。假設你和同事同時發現了個BUG（雙方都不知道對方在提交），而你對需求不熟悉，不太確信是個BUG，然后又去翻需求，翻完回來再提交，結果這時候同事已經提交了，那么不好意思，你的BUG只能作CLOSED_Nbug處理了，如果一定要加上一個批注，那么將是，重復提交（測試新人，備注里不建議加測試建議（即怎樣修改可以避免此缺陷），因為有可能會對開發產生誤導）特別說明：1）速度和效率同時考慮，盡量別發錯BUG；2）公平競爭，還要考慮團隊合作，在別人的測試模塊發現BUG，建議告知對方提，與同事交流的時候，同事講到的缺陷，而缺陷管理工具中沒提，應該讓對方提交上去
5、新版本發布：
1）驗證FIXED缺陷，如果驗證通過了，把狀態改為CLOSED（關閉的時候一定要加個備注，（比如：某月某日某版本驗證通過。）對于開發修改了，但是與需求有出入的，且與測試經理確認可以這樣修改時，備注建議這樣寫：某月某日某版本驗證通過，修改為……），如果沒通過改為OPEN（同樣加個備注：某月某日某版本驗證未通過），這里存在一個誤區，有的人會把狀態改為REOPEN，如果是公司要求的，那無可厚非，如果沒有要求，建議改為OPEN，因為 REOPEN是已經確認修改并且該BUG已經改為CLOSED狀態后，才需要修改為REOPEN狀態的。（有很多公司是不允許出現REOPEN狀態的（針對開發），一旦出現，開發此模塊的程序員績效可能會被大打折扣，我現在所在的公司就是這樣的）
2）冒下煙確保主流程暢通，然后再進行功能測試，著重測試有修改的或者與所修改模塊有調用關系的模塊和發現BUG比較多的模塊（公司發布版本會郵件通知修改的模塊與修復的BUG），未改動的模塊建議做個流程測試。特別說明：主流程走不通，應立刻MSN給項目負責人（組長或經理，如果有本項目MSN群，直接在群里講就可以了）
版權聲明：原創作品，允許轉載，轉載時請務必以超鏈接形式標明文章原始出處 、作者信息和本聲明，否則將追究法律責任。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
