軟件測試工程師的修煉之道(4)

同樣，像數據庫、操作系統、網絡協議、建模等等都屬于基礎技能的范疇?？赡軠y試人員在這些技能的掌握程度上沒有專業人士強，沒關系，因為這些技能最終是為測試專有技能所服務的，如此而已。當然，如果個人有興趣深入研究那是最好。筆者記得剛接觸Linux系統的時候拼命讀源碼，剛接觸網絡協議的時候厚厚幾本《TCP/IP詳解》放在床頭，可惜的是都沒堅持下來。

為什么說測試工程師轉崗容易？現在該明白了吧。

測試模式

瀑布開發、快速開發、迭代開發、敏捷開發等等等等，這么多開發模式聽著是不是犯暈？探討哪種模式更好其實是扯淡，就象探討是由“開明君主治理的封建制度國家”好，還是由“腐朽無能政府統治的民主制度國家”好一樣，均屬于哲學問題。同理，測試模式有V模型、X模型、H模型、前置模型，淘寶還提出了SPR模型以及最近正在探索的CCI模型，哪種更好？合適的就是最好的。

盡信書不如無書，這道理很多人都說懂，實際上呢？大多數人依然是照本宣科，死搬硬套。在大多數情況下，工程師應該盡量追求神似而不是形似，特別是奮戰在一線的工程師，要明白“將在外君命有所不受”的道理。在當前以結果為導向這種西式管理的氛圍下，更多的是要拿出讓各方面滿意的成績單。當然，也有部分人以此為借口逃避流程逃避制度，高舉敏捷大旗卻行偷懶之實。要知道能量守恒，在某方面偷懶在其它方面會付出更多，這樣做其實是把自身工作轉嫁到他人身上，比方說把自身應該完成的保證產品質量工作轉嫁給他人，這樣的人要招天譴。“適可而止”這四個字說起來簡單，真要做到非常難，需要大量的實踐經驗，這也是為什么測試工程師職業生命周期較長的原因。

筆者認為，在當下絕大多數項目團隊里，V模型足夠使用，或者在部分地方進行改良即可適應項目團隊工作的需要。要知道，經典是永遠不會過時的。那么在行政體系上呢？一個測試部門應該采用怎樣的組織結構？目前流行的是一分為二，一部分做技術支撐，另一部分做產品測試，還有極端的是測試人員只做測試技術支撐，產品測試交由開發人員自行完成。至于在產品測試里再細分單元測試、集成測試或功能測試、性能測試等角色，竊以為不需要，因為在廣義上，都是功能。測試要做的就是V&V，檢驗已實現的功能是否正確，檢驗是否正確實現了功能。

第三頁

測試工具

這里所說的工具是廣義上的，可以說各種各樣只要能輔助測試人員開展測試工作的工具都包含在內。

為什么Mercury（筆者還是習慣稱為mercury而不是hp）的產品能得到廣大測試工程師的認可？因為它滿足了測試工程師工作的需要。工具干嘛用的？輔助測試工作用的。筆者一直覺得Mercury的架構師真是不得了，產品設計的如此漂亮。什么是測試架構師？這就是。

測試工具有很多，這里不一一列舉了。每年國際上會評選年度最佳測試工具，有興趣的朋友可以多了解下，這算是測試工具的風向標。

有人曾經爭論什么才能稱之為測試工具，例如針對某一特定產品開發的一段測試代碼是否算是測試工具。筆者以為，從廣義上講是，但在通常所說的范圍下不是，因為它不具備通用性，它只能為特定產品服務。所以筆者常常告誡測試人員，第一不要總吹噓自己開發了多少測試工具，充其量那只能算是一段測試代碼；第二要理解測試工具的本質，開發了一堆工具結果根本不能有效提高測試質量、測試效率，無法幫助測試人員發現更多的缺陷，有意義嗎？

當然，有一點肯定沒錯，多試用不同種類的測試工具并研究其原理，如果能對其進行改進，那么恭喜，離專家又進了一步。

第三章能力修煉

修煉要素

以下列舉的十八要素僅供參考，這些要素并沒有優先級或前后順序，但有一點是必需確保的，那就是堅持，至少堅持一個月。如果能把全部要素堅持做一個月，筆者保證測試工程師自身能力會有大幅度提高。如果能堅持一年甚至更長時間直至養成習慣，那么恭喜，離牛人不遠了。

1、 每日至少抽出30分鐘關注測試行業新聞，包括各種業內動向，技術前沿等。推薦國內網站：51testing、ITPUB、Javaeye、infoq、博客園、Oracle中國用戶組……。

2、 每日寫一篇博文，200字左右，記錄當日工作完成情況及次日需完成工作，流水帳也可。

原文轉自：http://www.jianshu.com/p/0cde18be00ed