讀《微軟的軟體測試之道》有感（上）

標籤：style   http   ar   os   sp   strong   on   問題   bs   

　　在這個電子書漫天飛的年代，我居然仍然喜歡讀紙書，喜歡一邊讀一遍聞書的味道，就像品嘗一頓美味的大餐一樣。最近得了一本《微軟的軟體測試之道》，啃了一段時間了，每次重新拿起來看就覺得裡面的內容忘得一乾二淨了，想起之前有位領導總是教導我們：“要不斷總結，要累積，這樣才會進步！”之前每次聽這話都覺得煩，後來工作久了才知道總結有多重要，如今為了記住這本書的內容，我決定寫個讀後感，想到哪裡寫到哪裡。

　　第一部分：

　　第一章《微軟的軟體工程》

　　第二章《微軟的軟體測試工程師》

　　第三章《工程生命週期》

　　看完就想說一句：哦，原來大公司是這個樣子的。接來下還是講講我們自己吧，任職於一家小公司，感覺團隊就像一支遊擊隊，可能用抗戰片裡面的義勇軍來形容更貼切些，生源比較複雜，有組織，有自己的戰鬥模式，但紀律性略差，儘管“組織上”派了很多人來“改造”，但實施起來困難重重，最後都是半路夭折。公司每年都會根據項目情況進行團隊重組，提倡人員複用，也因為這樣我參與了多個產品的測試工作，經曆了從產品投標立項到發布驗收的所有過程，這讓人聽起來有些複雜，一個測試工程師需要經曆這麼多嗎，我開始的時候也很排斥這種模式，後來慢慢就想通了，正是因為經曆了這麼多才讓自己有機會學習到更多，工作不應該是僅僅局限於一片地區，要不斷地擴充自己的知識面，經曆的越多你會發現自己缺的越多，而在這個過程中會有收穫的驚喜，不多解釋了，大家都懂得。

　　測試的職業發展，我們總會看到兩個選擇：一個是技術方向，一個是管理方向。其實對於新人來說不必太糾結於這個問題，因為當你工作的一定程度的時候，自然就做出了選擇，個人覺得工作不需要違心，人只有按著自己喜歡的方向走，才能充分發揮自己的優勢。書中講到了測試職種的多種發展道路，對於迷茫者來說是一個不錯的提示，層級主要是根據技術深度、技術廣度和影響力範圍來區分的，影響力的範圍從一個狹窄定義的產品功能擴充到一個系列產品的功能、一個完整的產品，影響力可以基於測試的各個方面延伸，也可以基於一個方面的技術領域縱向延伸。我的感想是，學無止境，測試也一樣，學到的越多，技術水平越高，你才會有能力維護自己的地位，地位越高，你的影響力就越大。

　　工程生命週期，作者以做飯為例講述了一個過程方法：通過協調各種資源，根據情況靈活調整。是按部就班還是靈活機動，都各有好處，並不是一個軟體開發模式適用於所有的產品，不同的產品需要不同的方式來實現，儘管在實際操作中會有很多變化，但很多過程方法在實踐中已經廣泛應用，而且也在實踐過程中進行顯著的實驗和創新。傳統的軟體工程模型有瀑布模式、螺旋模式、敏捷開發。除了第二種，其他兩種我都經曆過，目前一直都是敏捷開發。品質改進是定義了工作目標，指定和執行計畫以達到目標，檢查並確定是否實現了預期的結果，如果沒有實現預期的結果，就要修改工作規程以完成計劃。Deming迴圈（或PDCA迴圈）就是描述上述過程的一種方法，該流程實現能保證產品品質滿足期望。之前也閱讀過《軟體測試與持續品質改進》、《持續整合，提高軟體的品質和降低風險》等品質相關的書籍，公司的領導一直提倡流程改進，項目組也進行了多種嘗試，並將戴明迴圈進行實踐，且取得了一定的效果。我的總結就一句話：A good process is a process that results in good software.

 

讀《微軟的軟體測試之道》有感（上）