5．6案例六：軟件測試
   閱讀以下關于信息系統項目管理過程中項目質量管理方面問題的敘述，回答問題1至問題2。
5.6.1案例場景
    老王在中培信息技術有限公司(Z公司 )工作，被委派到了一個新的項目擔任項目經理，為客戶K公司開發用于支撐業務的信息系統。這是一個規模較小，復雜度較低的系統。由于市場競爭的原因，合同額很少。出于成本的考慮，公司分派給老王的人員并不多。為解決人力資源不足的問題，老王考慮，系統復雜度不高，可以一定程度上簡化測試工作。于是老王在項目中做了如下安排：
    (1)不進行單元測試和集成測試，僅進行系統測試。
    (2)不安排專門的資源開發系統測試用例。因為程序員熟悉自己開發模塊的業務，由程序員對自己開發的程序進行黑盒測試，對測試中發現的缺陷進行記錄并跟蹤，且立即修改。
    (3)在測試過程中，每三天定義為一個測試周期，統計每個測試周期每個模塊發現的缺陷數量。若連續兩個測試周期沒有發現的缺陷少于總缺陷的5%且發現缺陷的趨勢基本平穩，則認為測試工作基本完成。
    老王的理由如下：首先，隨著系統中缺陷的減少，程序員會有越來越多的時間進行測試，以發現系統缺陷。其次，當系統中的缺陷數量很少時，程序員發現的缺陷會變得越來越困難，總缺陷數幾乎不再增加，這時發現缺陷的趨勢變得很平穩，且發現的數量很少。
在測試階段，老王統計到的數據如表5-1所示。

    老王認為測試工作基本完成，決定進入系統發布階段。
 【問題1】(12分)
    請以300字內，逐一點評老王對測試工作進行的三點安排。
    【問題2】(13分)
    在人力資源有限的情況下，老王不可能找到專門的測試人員全程進行測試，那么老王應做哪些改進來提高測試工作的質量，試以300字內回答。
5.6.2案例分析
    該案例中描述的場景是很多軟件公司中常見的場景，由于市場的惡性競爭或是其他原因，開發的費用被一再壓縮。為了滿足成本的約束，項目經理忽視測試的工作，項目組成員在項目中身兼多職，從需求一直做到測試。系統缺乏完整的測試，甚至沒有測試就提交給客戶。雖然案例中沒有寫明，但結果已經可以想像，客戶為充滿問題的系統而惱火，即使項目談不上失敗也絕對談不上成功。
    人們常說：“再窮不能窮教育”，對于軟件項目而言就是“再省不能省測試”。軟件系統的技術復雜度相對較高，結果抽象，可以模式化的東西很少，開發過程也是一種探索的過程，在每一個步驟都會制造缺陷，這已經在無數的軟件系統開發中得到了驗證。成功的系統總是正視這種客觀情況，通過各種各樣的方法來提高質量，盡可能早地檢出系統中潛在的缺陷；失敗的項目則是回避，總是假設不會出現缺陷或缺陷很少，．任由錯誤擴大，最終肯定是缺陷的大爆發，開發人員疲于修正缺陷，同時再引入新的缺陷。
    在案例中，老王在人力資源不足和項目質量上進行了折中，進行角色復用，把開發和測試安排到一起，根據缺陷發現的趨勢來判斷測試是否可以結束，于是問題就出現了。
    對于軟件開發中的角色復用，專門的論述并不多見。我們在這里引用MSF中關于開發角色和角色合并的內容進行講解與分析。在微軟的項目管理框架一MSF中定義了軟件項目中的6種角色：
    (1)產品管理，負責產品的定義，如客戶代表、產品負責人、需求人員。
    (2)程序管理，按項目的約束進行交付，如項目經理、開發主管。
    (3)開發，根據規格說明書(需求規格說明書、設計說明書等)進行系統的構建，如系統設計人員、編碼人員。
    (4)測試，確定并找到系統中的質量問題，如測試人員。
    (5)用戶體驗，負責把握用戶在使用系統時的感受，例如，需求人員、界面設計人員、系統培訓人員。用戶體驗不同于產品管理，用戶體驗著重從用戶處獲得需求與反饋信息，而產品管理則注重于產品的定義，其定義的依據既包括用戶需求也包括產品路線圖等內容。
    (6)發布管理，負責系統的部署的穩定的運行，例如項目經理、系統管理員。
在MSF中給出了角色間合并的建議，如表5-2所示。

根據表5-2可以看出，開發人員雖然是程序的創造者，但不推薦和其他任一種角色合并。MSF是微軟總結了其多年的開發經驗整理出來的項目管理框架。也就是說，即使是在微軟這樣的公司，雖然每個人都有足夠的能力，但開發人員仍需要獨立出來，不能夠與測試混為一談。
    這一點也不難理解。首先開發人員與測試人員的技能側重點不同，開發人員側重于技術的細節，關注于系統實現所采用的技術和方法，更需要把握如何應用技術手段構建滿足規格說明書的系統；測試人員側重于技術的結果，關注于系統實現后的表現和效果，更需要把握實現的系統是否滿足規格說明書的要求。其次，開發人員與測試人員的目標不同，開發人員希望能夠構建出完全符合要求的系統；測試人員則需要在看似完全符合要求的系統中尋找缺陷和漏洞。因此，開發人員同測試人員的視角不同，開發人員總是傾向于構建后的系統是完美的，而測試人員則傾向于構建后的系統是有缺陷的。這種種不同，造成開發人員很難發現自己構建的系統中的缺陷，存在盲點，而測試人員更容易發現系統中的問題。
    再回到這個案例，不難發現，老王正是在這一點上犯了錯誤，把開發和測試結合到了一起，讓程序員測試自己開發的程序。
    在問題1中，要求對老王進行的測試安排進行點評，上面我們已經談到，第二點是肯定有問題，那么其余兩點呢？
    對于第一點來說，是完全可以的。雖然在嚴格的軟件開發模型中定義了單元測試、集成測試和系統測試，但在實際項目中完全可以根據項目情況進行裁減。如果系統復雜度不高，系統規模又比較小，我們可以考慮僅僅進行系統測試。不過在裁減過程中應該注意，單元測試相對集成測試更重要。集成測試可能會同系統測試部分重合，但單元測試相對獨立，可以發現一些極端情況下的問題和程序上的低級錯誤。在案例中，即使是程序員自己測試自己的程序，前三個測試周期中仍發現了不少缺陷，就是由缺少單元測試造成的，系統中還存在不少低級錯誤。
    對于第三點來說，根據缺陷發生的趨勢來判斷測試工作是否完成，是一種可行的方法。如果測試過程公正客觀，發現的缺陷具有代表性，以此為依據進行判斷是有效的。但反之，若測試過程不充分、不客觀，這種方法毫無意義，因此在案例中這種方法加劇了開發人員與測試人員合并的惡果。
    第二個問題也是項目中的常見問題。當人力資源有限時，我們應該如何在保證項目質量的前提下壓縮團隊規模。
    我們根據MSF中的角色合并建議來回答這個問題，見表5-2.表5-2中列出可以和測試角色合并的角色包括：產品管理、·用戶體驗和發布管理，在某些情況下，測試可以和程序管理相合并。
    除了角色合并外，還有一些方法，可以以較少的人力投入換取更高的項目質量。其中包括：
    (1)程序員間進行交叉測試，最好可以同其他項目組的程序員互換，讓程序員在互換中變更自己的角色。
    (2)在程序員自己發現的缺陷區域平穩后再提交給測試人員進行測試。這樣可以避免測試人員陷入低級錯誤中，減少其工作量。
5.6.3參考答案
    【問題1】(12分)
    (1)不進行單元測試和集成測試，僅進行系統測試。在低復雜度的小規模項目中，這種做法尚可，通過系統測試可以發現大多數系統中的缺陷。(4分)
    (2)不安排專門的資源開發系統測試用例，由程序員對自己開發的程序進行黑盒測試，并對測試中發現的缺陷進行記錄并跟蹤，由發現者立即修改。
    這種做法問題會造成很嚴重的問題。程序員是程序的創造者，是無法進行黑盒測試的。這種所謂的黑盒測試會造成測試的盲點，一些缺陷始終無法發現。(4分)
    (3)在測試過程中，每三天定義為一個測試周期，統計每個測試周期每個模塊發現的缺陷數量。若連續兩個測試周期沒有發現的缺陷少于總缺陷的5％，且發現缺陷的趨勢基本平穩，則認為測試工作基本完成。
    若有專門的測試人員，公平客觀地進行測試工作，這種判斷測試工作是否完成的方法是有道理的，可以保證絕大多數的缺陷都在測試中發現。(4分)
    【問題2】(13分)
    在人力資源有限的情況下，老王應做如下方面改進來提高測試工作的質量：
    (1)根據項目實際情況，由項目經理、需求人員或客戶業務代表進行測試。(7分)
    (2)采取程序員交叉測試的方法。(3分)
    (3)若情況允許，可以在程序員自己發現缺陷趨于平穩后，再提交給專門測試人員進行測試。(3分)