現代軟體工程 第十四章 【品質保障】 練習與討論

標籤：style   使用   ar   strong   sp   問題   on   代碼   工作   

14.1 有些成功人士或公司認為不需要獨立的測試角色（Test），你怎麼看？

     就像很多事情一樣，不能把所有的事情說得太絕對了，舉個例子來說，大多數的軟體開發都是以小組的形式來進行的，每個人分配了一個模組，如果說每個人對自己的模組都進行一下測試，當然這樣的情況下可以不需要獨立的測試角色，編程的過程就是不斷對自己的程式排錯、測試來完成的，但是最後所有的模組整合成一個大的系統，這樣如果程式員只對自己的模組進行測試，是肯定不能滿足需求的，這時候就需要一個獨立的測試角色，對整個系統進行規模測試，在不知道內部編碼狀況的情況下進行測試，反饋給程式員，最後做出一個完整並滿足使用者需要的系統。

14.2 為什麼一些成功的公司不用測試人員

     看了一些資料，鄒老師也說了好多自己的觀點，我自己對這些不太瞭解，但是我閱讀的這些資料中，有一段話還是蠻認可的：Sriram Krishnan：“開發人員應該測試自己的代碼。沒什麼可說的。背後的道理並不重要。這包括單元測試，全覆蓋的自動化測試或手工測試或組合測試。如果你的開發人員不能/不願意或認為這“不歸我管”，那你需要更好的程式員。”

14.3 測試人員的職業發展

      看到這個問題，特意在網上搜了一些大家的看法，我也有一些感想。

      第一、  不斷改進測試策略，提高測試效率和品質改進測試策略需要掌握開發技術，但是技術僅僅是必要條件，更重要的能力，是能夠系統的規劃一件事情，分析工作中的問題，選擇最有效解決方案，最終和大家一起實現一個共同的改進目標。改進測試策略一般會考慮以下幾個方向：單元測試（白盒和灰盒）、自動化測試、效能測試、安全性測試、易用性測試等等。當然，具體的改進目標，要根據業務的不同，選擇合適的方向。

      第二、  能夠“吃”業務，控制業務的測試品質。測試人員吃掉一個業務以後，可以把測試工作完全交給另一個測試人員來做，同時，也能保證測試的品質。而要達成這個目標，關鍵就在於文檔。我們需要以業務為單位，完善測試案例、業務沉澱、測試設計、測試指令碼等文檔，並且，更重要的是，要把這些零散的文檔組織成一個系統的文檔體系。

      如果以後有可能從事測試工作，可能會對這個有更深入的瞭解。

14.4 如何衡量軟體工程的品質

    除了鄒老師說的那些，我認為還有以下：

   a)bug的嚴重層級--嚴重的bug會使使用者無法使用軟體更別說能接受這個產品了        

   b)測試案例的密度--用例密度直接影響bug的數量和嚴重層級

   c)客戶回函缺陷，即漏測

現代軟體工程 第十四章 【品質保障】 練習與討論