不知不覺已經從事軟件測試六年了，2006畢業到進入外包公司外包給微軟做軟件測試， 到現在加入著名的外企。六年的時間過得真快。 長期的測試工作也讓我對軟件測試有了比較深入的認識。

軟件測試人員應該居安思危

每當經濟不好，公司業績不好的時候，公司都可能進行裁員。 首先裁的就是測試人員。 因為測試人員的技術水平相對來說比較低，容易被替代，招起來也比較容易。 公司往往先拿測試人員開刀。

身為測試人員，雖然我們平常的工作大部分都比較安逸。 但是千萬不能溫水煮青蛙。 應該自強不息， 要像開發人員一樣， 不斷學習，提高自己的編程水平。這樣就算被裁也能很快找到新的工作。

測試人員應該比開發人員更熟悉業務需求

測試人員的水平主要體現在測試用例的設計上。 要設計出全面，覆蓋廣的測試用例，需要測試人員對自己所測試的項目的業務需求非常熟悉，甚至要比開發人員還要熟悉。

如果是測試銀行系統，通信行業，或者ERP軟件。 這些業務知識非常有用的，學習起來比較有激情。

要做到精通業務需求談何容易。

1. 要熟讀功能需求文檔， 任何有疑問的地方都要去和PM確認。

2. 把自己當成最終用戶， 經常使用自己所測試的軟件。模擬用戶的行為。

3. 熟記軟件的每個功能。

假如倒霉碰到一些又沒用，又繁瑣的軟件， 真的是不想去學習它的業務（出了這個公司就再也用不到的業務）

學會如何跟開發人員相處

測試人員必須跟開發人員密切合作， 所以跟開發人員搞好關系是相當重要的。

1. 和開發人員成為朋友。

熟悉了干啥都方便

2. 不要打擾開發人員

看到開發在聚精會神寫代碼的時候，千萬不要去打擾人家。 寫代碼需要集中精力，如果被打擾，就會中斷思考。

3. 集中問問題。

把需要問的問題都總結起來， 集中起來問開發，這樣能節省大量的時間。

4. 寫好Bug，不被開發人員煩。

如果開發人員看到一個Bug 描述不清楚，還無法重現，他肯定會罵測試人員。 所以測試人員一定要寫好Bug，描述精確，簡潔，沒有歧義，詳細簡潔的重現步驟，加截圖。

測試人員應該懂一些基本的編程

你的產品是用C# 開發的，那測試人員應該有C#的入門知識。 你測試web程序，你起碼要了解HTML，CSS， Javascript， Jquery吧，否則你測了一兩年web程序，都不知道這東西是怎么做的，悲劇了吧。

只有懂代碼你才能和開發人員交流，不被開發鄙視。

測試人員搭建開發環境

產品的代碼是最好的學習資料了，我們不能總跟在開發屁股后面做測試，不能老是等開發build一個版本后，我們就測試這個版本，開發check in了什么代碼，測試人員一點都不知道。偶爾我們應該了解下產品代碼是怎么設計的，了解下開發人員是如何修復bug的。說不定編程水平高了，還能幫開發做code review.

使用源代碼工具把產品代碼check out到本機。 經常看看代碼，經常看看開發修復bug時候提交的代碼。

寫文檔是測試人員的核心能力

我記得我以前的test lead說，之所以她能當lead， 是因為她很會寫文檔發郵件。 寫文檔需要總結歸納的能力，還要邏輯清晰。 她非常擅長分析幾十頁的Spec，寫出幾十頁的測試計劃。 她還非常擅長匯總測試報告。 每天將完整，清晰，漂亮的測試報告發給各個組， 讓公司所有的人都能清晰的看到測試組的工作。

在她的帶領下，我們總結出很多文檔，比如，”New hire checklist”， “on boarding traning”， 測試工具使用的文檔，等等。

寫多了博客后我發現我寫文檔能力提高了很多。

測試后期應該做兩天交叉測試

交叉測試，就是指兩個測試工程師，互相交換下測試的項目。 這樣做有很多好處。

1. 有利于找出bug， 測試工程師測久了自己的項目，容易形成眼盲。會對一些Bug熟視無睹。

2. 有利于知識和業務共享，避免人員離職，請假，造成無人測試的情況。

3. 測試思想不一樣，可以互相找出很多問題

測試人員的瓶頸

手動測試工作做個兩三年，基本上就能掌握測試需要的大部分知識，如果沒有爬到test lead的位置， 很多人就感覺到發展瓶頸了，每天重復測試，學不到東西，很快就會對測試工作失去激情。

學不到東西，技術水平低下，是測試這個行業最大的毛病。

如何突破瓶頸？ 我也不知道。

盡量實現自動化

一點要抽時間盡量把自己的測試工作實現自動化，可以節省測試的時間，提高自己的技術水平，也可以避免老是重復測試。

自動化測試VS手動測試

現在很多公司招測試的要求越來越高，很多好公司招senior QA，都要求5年工作經驗以上，掌握一門編程語言，有豐富的自動化測試經驗。當然自動化測試的待遇也會比手動測試好很多。

自動化是趨勢， 只會做手動測試的人，以后肯定會失去競爭力。

自動化測試的技術和開發用到的技術相差太遠

以前很多同事想由測試轉開發，現在幾年過去了，還是沒轉成，他們原先想利用自動化測試的技術積累，轉去做開發。哪知道自動化測試用到的技術跟開發用到的技術相比，實在是相差太遠。

測試轉開發？ 難

努力學習編碼，然后用于測試，才是正道

做測試最郁悶的是無法聽懂開發人員討論技術

有時候跟開發人員一起開會， 會議上開發人員都熱烈討論。 而我做為測試人員基本上聽不懂這群開發在說什么，根本插不上話。 很多會議我甚至都沒說過一句話。

優秀的測試人員非常稀少

想把測試做好非常不容易， 優秀的測試人員需要很廣的知識面，良好的溝通能力（不但要和開發人員和項目經理打交道，還要跟其他組的人交流）。 豐富的測試經驗，對測試工作有極大的熱情， 耐心。還需要測試人員有豐富的業務知識，還要會寫代碼。

代碼寫得好的人，肯定就不會做測試，而是做開發去了。

大部分的測試經理都是有開發背景的

我發現我的幾任上司都是由開發轉來做測試的。 他們都是有幾年的開發經驗，然后不知道什么原因轉行做測試經理了。他們既能開發又能測試，啥都會，能給手下的測試人員提供技術支持。

假如一個測試經理啥技術都不懂，對內hold不住手下的人，對外其他組的人不鳥你。

軟件測試的確非常枯燥，需要花費大量精力

不可否認測試工作需要耗費大量的精力，所以歐美才會把大量的測試職位外包給中國， 一遍又一遍的重復測試，不停地執行測試用例， 測得天昏地暗， 頭發暈。

我還記得我以前測試過一個程序的各個版本在Windows update中的升級， 先安裝老版本的程序，然后Windows update 重啟后看看有沒有升級，最后卸載。 然后又安裝，又卸載。最后測的差點吐血。

英語是測試人員的救命稻草

技術上已經不如開發了。 在英語上一定占有一些優勢。

同等的技術水平下，英語好的測試人員可以進外企，比一個英語不好的測試人員的待遇要高不少。

盡量少用UI自動化測試，多使用單元測試，接口測試

能找到bug的自動化測試，才是有用的，否則就是個噱頭

UI自動化測試比較不穩定，對于測試結果的分析也困難。 而且UI改動也大。 所以應該盡量多做一些底層的的自動化測試，比如ASP.NET MVC 中UI和邏輯分開了，針對邏輯的自動化測試就比較好做了。