本文寫于2012.7.27

?

================================

?

前幾天在知乎（http://www.zhihu.com/question/20269633）上看到了這么一段，說“測試人員能達到的層次大概有這么幾個級別”：

1 開一個bug;

2 查找一些額外的資料如設計文檔和歷史，確定這是一個問題，然后給出詳細的bug重現步驟；

3 對重現步驟做一些精煉，確定能夠重現bug的最少步驟；可能的話，將重現步驟做自動化；

4 嘗試通過研究代碼確認問題所在；

5 嘗試給出一個fix；

6 對錯誤的原因進行分析，提出一些標準化的方法來檢測出類似的問題，比如stress，fuzzing等等；

7 能夠對標準化的測試流程定義對應的數據分析方法，可以保證開發和項目主管都能從中得到需要的信息來掌控質量狀況。

?

我數了一下自己的，基本上能做到1-3，自己實在是算不上個好測試。當然各方面原因也有，比如公司對軟件測試工程師的定義不一樣，對自己的要求也的確沒有那么高過。我覺得這七個層次是很不錯的標準了，對于想長期做測試的人來說可以拿來參考一下。看到這個帖子之后呢，就有了自我總結一下的念頭。

我也注意到，國內軟件行業，尤其是互聯網行業，非常重視自動化測試，從最開始的跑自動化測試、到讀腳本改腳本、再到自己整合開源工具寫一套腳本、再到自己直接開發自動化測試工具，是很多互聯網企業的測試正在熱衷的。不過自己所在的部門算是個傳統軟件行業，所以具體情況具體分析吧。

自己所在的team大約穩定在8-12人，長期組里會有1-2個實習生，負責的產品總計10個左右，項目周期基本是1天-6個月不等，每個項目的參與人數一般1個人-6個人不等。絕大部分產品我們完全沒有機會接觸到源碼，除了我現在手頭正在做的，因為老跟著開發加班和開發關系比較熟，代碼我也能讀到，不過自己沒追求，從來不去看>_<

整個team里除了一個lead主要做管理很少做項目，其他的人大約有1-2個會參與自動化測試相關的開發和維護，1-3個是不能獨立處理大的release項目需要跟著別人做項目，其他的人基本都有獨自做大項目和帶人做項目的能力和經驗。工作的主要內容基本就是對著用了很久的測試用例做手工測試，純黑盒。少部分時候會需要自己寫測試用例。和別的公司一樣，并不是太重視測試用例。

?

我總結一下自己從09年6月開始實習到現在這三年的一點經歷吧。

?

09年6月-10年6月 internship

第一個月是培訓期，對著三大本英文書學習產品。基本三周把三本書看完，每周一做一次presentation總結上周學到的內容，并且同事會提問，最后一周會做一些簡單的sample，比如產品的升級、功能的簡單回歸測試。

第二個月開始處理hotfix，流程大致是：根據相關的defect記錄，搭環境，重現問題，應用hotfix，確認問題被修復，跑automation regression。工作這三年我大致做了上百個hotfix，主要都是在實習期做的，畢業之后就不會安排這種活兒了，除非實在沒有level更低的人做or某個hotfix是是自己做過的別人沒經驗。

半年后開始跟著做大的release。大的release包含的內容比hotfix要多一些，最開始一般由level比較高的人寫new feature的測試用例，開發給了build之后交叉測試new feature，同時也安排人測defect（一般大的release都包含上個release到現在之間的所有的hotfix）。之后會有manual regression(對著超長超詳細的英文文檔做手工測試，覆蓋幾乎所有功能)、automation regression、compatibility（和相關的十多個產品在不同的os和database上之間的兼容性）。再之后基本就是install和doc review了。這幾個測試之間有一定的先后順序，比如install肯定是所有平臺的build都出了，所有測試基本都結束之后去做的，不過具體哪個階段做什么還是要看具體的情況，有時候項目快要結束了defect忽然開始爆發。

在沒有大的release的時候基本就在忙hotfix，也有閑著的時候，自己上上網看看書什么的。

?

10年7月-11年7月 graduate=level 0

畢業之后沒多久就開始做一個新出的很小的產品的測試，自己針對new feature和功能測試寫測試用例，沒有自動化測試，整個測試階段自己大致負責了一半，由一個比我高兩屆的MM來帶我。那個產品release之后到現在也沒有下一個版本，不過也沒有hotfix（意味著客戶這么久都沒有提bug）。

之間跟著做了些產品的release，這時候才基本熟悉了大的release的基本流程和步驟。11年4月開始花了兩個月在維護一套很老的silktest的腳本，覺得這套腳本設計的很好，覆蓋的功能很全，高內聚低耦合，之前為這套自動化測試腳本寫測試用例的人很牛。相反，覺得腳本本身倒不是什么特別難的東西。期間也用java調一些api去測一點性能，不算重點，但是比手工測試必然要有意思得多。

?

11年7月-12年3月 junior=level 1

開始在頭兒的指導下帶領倆實習生做大的release，期間遇到了一些問題，比如這次release的變動很大（數據庫結構變了），要測的覆蓋面會比較多，但是之前留下來的測試用例有一些問題，比如寫的極詳細，閱讀兩三頁的英文文檔要花半小時，操作卻只要可能幾分鐘，或者這么多年來產品更新之后，有些測試用例基本是無效的或者沒有意義的，但是一直沒有更新，也有部分測試用例寫得過于簡潔，以至于讀起來特別費勁，但是讀懂之后就容易得多。i所以每當一個測試階段結束之后開發給下一個版本的build之前，還要抓緊時間按照自己的理解去更新測試用例（有的地方甚至完全沒有測試用例），然后在下一階段交叉測試，然后再更新。這個項目做了大概三個月之后，因為開發遇到了困難，加上項目本身優先級不高，于是暫時擱置了。

這期間也是跟著做另外的產品的release，做離職同事的交接，學點東西。

?

12年4月-現在 senior=level 2

掛牌成了個senior engineer，4月開始做一個release，預計8月中旬結束。這次算是真正意義上的在進度壓力下去帶人做。lead一個項目的時候要考慮的事情比跟著別人做項目要多得多，至少會有一種“這是我自己帶出來的產品，我要對它的質量負責”的心態，就算要加班也是心甘情愿，不會有“跟著文檔做就行了不用動腦子想”的態度。同時要規劃整個測試階段的進度安排，根據人員的能力去安排任務，和他們溝通讓他們愿意更努力一些，去和開發溝通推動問題解決，等等。遇到了很多問題，犯了不少錯誤，在同事的指導下有的很快改了，有的產生了一些不良后果。這個過程中學到了很多東西，并不僅僅是技術上的。

?

?

如果繼續做軟件測試……

下一階段我會傾向于把精力放在自動化測試上，希望能有大段的時間專心弄一套東西出來，之前和lead聊過，他也挺有意向。有這個想法的原因有幾個，一方面當然是因為自動化測試的經歷能給自己當塊敲門磚啦，一方面是因為沒有項目的壓力做一些有意思的事情會讓上班變得“幸福”一些：）女生可能賺錢的壓力沒有男生那么大，我覺得在一個氛圍很open工作比較輕松的公司待著學了很多東西而且還有錢賺，比在氛圍很open學習比較輕松的學校待著學了很多東西可是還要付給學校一大筆錢要有意思點兒。

當然有時候的確會很累，下班了之后眼睛都是直的。有時候也會因為一些溝通的問題弄得自己很沮喪，有時候會擔心項目而自己跑去加班，有時候也會因為狀態不佳無心工作而效率低下，事后要么加班要么打雞血把進度給趕回來。畢竟bug是無限的，而時間和資源是有限的，所以在有限的時間內測了自己想到的能測的該測的各種東西之后，基本就只剩下上帝保佑產品到了客戶那邊可千萬不要出問題。反正到目前為止，我仍然是個很菜的小測試。。。

?

路漫漫其修遠兮，吾將上上下下左左右右ABBA而求索。

?

總結

以上是生活随笔為你收集整理的软件测试入门三年经验的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。