閱讀以下關(guān)于信息系統(tǒng)項目管理過程中項目質(zhì)量管理方面問題的敘述，回答問題1至問題2。

    張工在信息技術(shù)有限公司(CSAI )工作，被委派到了一個新的項目擔任項目經(jīng)理，為客戶K公司開發(fā)用于支撐業(yè)務(wù)的信息系統(tǒng)。這是一個規(guī)模較小，復雜度較低的系統(tǒng)。由于市場競爭的原因，合同額很少。出于成本的考慮，公司分派給張工的人員并不多。為解決人力資源不足的問題，張工考慮，系統(tǒng)復雜度不高，可以一定程度上簡化測試工作。于是張工在項目中做了如下安排：

    (1)不進行單元測試和集成測試，僅進行系統(tǒng)測試。

    (2)不安排專門的資源開發(fā)系統(tǒng)測試用例。因為程序員熟悉自己開發(fā)模塊的業(yè)務(wù)，由程序員對自己開發(fā)的程序進行黑盒測試，對測試中發(fā)現(xiàn)的缺陷進行記錄并跟蹤，且立即修改。

    (3)在測試過程中，每三天定義為一個測試周期，統(tǒng)計每個測試周期每個模塊發(fā)現(xiàn)的缺陷數(shù)量。若連續(xù)兩個測試周期沒有發(fā)現(xiàn)的缺陷少于總?cè)毕莸?%且發(fā)現(xiàn)缺陷的趨勢基本平穩(wěn)，則認為測試工作基本完成。

    張工的理由如下：首先，隨著系統(tǒng)中缺陷的減少，程序員會有越來越多的時間進行測試，以發(fā)現(xiàn)系統(tǒng)缺陷。其次，當系統(tǒng)中的缺陷數(shù)量很少時，程序員發(fā)現(xiàn)的缺陷會變得越來越困難，總?cè)毕輸?shù)幾乎不再增加，這時發(fā)現(xiàn)缺陷的趨勢變得很平穩(wěn)，且發(fā)現(xiàn)的數(shù)量很少。

    在測試階段，張工統(tǒng)計到的數(shù)據(jù)如表5-1所示。

    張工認為測試工作基本完成，決定進入系統(tǒng)發(fā)布階段。

 【問題1】(12分)

    請以300字內(nèi)，逐一點評張工對測試工作進行的三點安排。

    【問題2】(13分)

    在人力資源有限的情況下，張工不可能找到專門的測試人員全程進行測試，那么張工應(yīng)做哪些改進來提高測試工作的質(zhì)量，試以300字內(nèi)回答。

    該案例中描述的場景是很多軟件公司中常見的場景，由于市場的惡性競爭或是其他原因，開發(fā)的費用被一再壓縮。為了滿足成本的約束，項目經(jīng)理忽視測試的工作，項目組成員在項目中身兼多職，從需求一直做到測試。系統(tǒng)缺乏完整的測試，甚至沒有測試就提交給客戶。雖然案例中沒有寫明，但結(jié)果已經(jīng)可以想像，客戶為充滿問題的系統(tǒng)而惱火，即使項目談不上失敗也絕對談不上成功。

    人們常說：“再窮不能窮教育”，對于軟件項目而言就是“再省不能省測試”。軟件系統(tǒng)的技術(shù)復雜度相對較高，結(jié)果抽象，可以模式化的東西很少，開發(fā)過程也是一種探索的過程，在每一個步驟都會制造缺陷，這已經(jīng)在無數(shù)的軟件系統(tǒng)開發(fā)中得到了驗證。成功的系統(tǒng)總是正視這種客觀情況，通過各種各樣的方法來提高質(zhì)量，盡可能早地檢出系統(tǒng)中潛在的缺陷；失敗的項目則是回避，總是假設(shè)不會出現(xiàn)缺陷或缺陷很少，．任由錯誤擴大，最終肯定是缺陷的大爆發(fā)，開發(fā)人員疲于修正缺陷，同時再引入新的缺陷。

    在案例中，張工在人力資源不足和項目質(zhì)量上進行了折中，進行角色復用，把開發(fā)和測試安排到一起，根據(jù)缺陷發(fā)現(xiàn)的趨勢來判斷測試是否可以結(jié)束，于是問題就出現(xiàn)了。

    對于軟件開發(fā)中的角色復用，專門的論述并不多見。我們在這里引用MSF中關(guān)于開發(fā)角色和角色合并的內(nèi)容進行講解與分析。在微軟的項目管理框架一MSF中定義了軟件項目中的6種角色：

    (1)產(chǎn)品管理，負責產(chǎn)品的定義，如客戶代表、產(chǎn)品負責人、需求人員。

    (2)程序管理，按項目的約束進行交付，如項目經(jīng)理、開發(fā)主管。

    (3)開發(fā)，根據(jù)規(guī)格說明書(需求規(guī)格說明書、設(shè)計說明書等)進行系統(tǒng)的構(gòu)建，如系統(tǒng)設(shè)計人員、編碼人員。

    (4)測試，確定并找到系統(tǒng)中的質(zhì)量問題，如測試人員。

    (5)用戶體驗，負責把握用戶在使用系統(tǒng)時的感受，例如，需求人員、界面設(shè)計人員、系統(tǒng)培訓人員。用戶體驗不同于產(chǎn)品管理，用戶體驗著重從用戶處獲得需求與反饋信息，而產(chǎn)品管理則注重于產(chǎn)品的定義，其定義的依據(jù)既包括用戶需求也包括產(chǎn)品路線圖等內(nèi)容。

    (6)發(fā)布管理，負責系統(tǒng)的部署的穩(wěn)定的運行，例如項目經(jīng)理、系統(tǒng)管理員。

    在MSF中給出了角色間合并的建議，如表5-2所示。

根據(jù)表5-2可以看出，開發(fā)人員雖然是程序的創(chuàng)造者，但不推薦和其他任一種角色合并。MSF是微軟總結(jié)了其多年的開發(fā)經(jīng)驗整理出來的項目管理框架。也就是說，即使是在微軟這樣的公司，雖然每個人都有足夠的能力，但開發(fā)人員仍需要獨立出來，不能夠與測試混為一談。

    這一點也不難理解。首先開發(fā)人員與測試人員的技能側(cè)重點不同，開發(fā)人員側(cè)重于技術(shù)的細節(jié)，關(guān)注于系統(tǒng)實現(xiàn)所采用的技術(shù)和方法，更需要把握如何應(yīng)用技術(shù)手段構(gòu)建滿足規(guī)格說明書的系統(tǒng)；測試人員側(cè)重于技術(shù)的結(jié)果，關(guān)注于系統(tǒng)實現(xiàn)后的表現(xiàn)和效果，更需要把握實現(xiàn)的系統(tǒng)是否滿足規(guī)格說明書的要求。其次，開發(fā)人員與測試人員的目標不同，開發(fā)人員希望能夠構(gòu)建出完全符合要求的系統(tǒng)；測試人員則需要在看似完全符合要求的系統(tǒng)中尋找缺陷和漏洞。因此，開發(fā)人員同測試人員的視角不同，開發(fā)人員總是傾向于構(gòu)建后的系統(tǒng)是完美的，而測試人員則傾向于構(gòu)建后的系統(tǒng)是有缺陷的。這種種不同，造成開發(fā)人員很難發(fā)現(xiàn)自己構(gòu)建的系統(tǒng)中的缺陷，存在盲點，而測試人員更容易發(fā)現(xiàn)系統(tǒng)中的問題。

    再回到這個案例，不難發(fā)現(xiàn)，張工正是在這一點上犯了錯誤，把開發(fā)和測試結(jié)合到了一起，讓程序員測試自己開發(fā)的程序。

    在問題1中，要求對張工進行的測試安排進行點評，上面我們已經(jīng)談到，第二點是肯定有問題，那么其余兩點呢？

    對于第一點來說，是完全可以的。雖然在嚴格的軟件開發(fā)模型中定義了單元測試、集成測試和系統(tǒng)測試，但在實際項目中完全可以根據(jù)項目情況進行裁減。如果系統(tǒng)復雜度不高，系統(tǒng)規(guī)模又比較小，我們可以考慮僅僅進行系統(tǒng)測試。不過在裁減過程中應(yīng)該注意，單元測試相對集成測試更重要。集成測試可能會同系統(tǒng)測試部分重合，但單元測試相對獨立，可以發(fā)現(xiàn)一些極端情況下的問題和程序上的低級錯誤。在案例中，即使是程序員自己測試自己的程序，前三個測試周期中仍發(fā)現(xiàn)了不少缺陷，就是由缺少單元測試造成的，系統(tǒng)中還存在不少低級錯誤。

    對于第三點來說，根據(jù)缺陷發(fā)生的趨勢來判斷測試工作是否完成，是一種可行的方法。如果測試過程公正客觀，發(fā)現(xiàn)的缺陷具有代表性，以此為依據(jù)進行判斷是有效的。但反之，若測試過程不充分、不客觀，這種方法毫無意義，因此在案例中這種方法加劇了開發(fā)人員與測試人員合并的惡果。

    第二個問題也是項目中的常見問題。當人力資源有限時，我們應(yīng)該如何在保證項目質(zhì)量的前提下壓縮團隊規(guī)模。

    我們根據(jù)MSF中的角色合并建議來回答這個問題，見表5-2.表5-2中列出可以和測試角色合并的角色包括：產(chǎn)品管理、·用戶體驗和發(fā)布管理，在某些情況下，測試可以和程序管理相合并。

    除了角色合并外，還有一些方法，可以以較少的人力投入換取更高的項目質(zhì)量。其中包括：

    (1)程序員間進行交叉測試，最好可以同其他項目組的程序員互換，讓程序員在互換中變更自己的角色。

    (2)在程序員自己發(fā)現(xiàn)的缺陷區(qū)域平穩(wěn)后再提交給測試人員進行測試。這樣可以避免測試人員陷入低級錯誤中，減少其工作量。

    【問題1】(12分)

    (1)不進行單元測試和集成測試，僅進行系統(tǒng)測試。在低復雜度的小規(guī)模項目中，這種做法尚可，通過系統(tǒng)測試可以發(fā)現(xiàn)大多數(shù)系統(tǒng)中的缺陷。(4分)

    (2)不安排專門的資源開發(fā)系統(tǒng)測試用例，由程序員對自己開發(fā)的程序進行黑盒測試，并對測試中發(fā)現(xiàn)的缺陷進行記錄并跟蹤，由發(fā)現(xiàn)者立即修改。

    這種做法問題會造成很嚴重的問題。程序員是程序的創(chuàng)造者，是無法進行黑盒測試的。這種所謂的黑盒測試會造成測試的盲點，一些缺陷始終無法發(fā)現(xiàn)。(4分)

    (3)在測試過程中，每三天定義為一個測試周期，統(tǒng)計每個測試周期每個模塊發(fā)現(xiàn)的缺陷數(shù)量。若連續(xù)兩個測試周期沒有發(fā)現(xiàn)的缺陷少于總?cè)毕莸?％，且發(fā)現(xiàn)缺陷的趨勢基本平穩(wěn)，則認為測試工作基本完成。

    若有專門的測試人員，公平客觀地進行測試工作，這種判斷測試工作是否完成的方法是有道理的，可以保證絕大多數(shù)的缺陷都在測試中發(fā)現(xiàn)。(4分)

    【問題2】(13分)

    在人力資源有限的情況下，張工應(yīng)做如下方面改進來提高測試工作的質(zhì)量：

    (1)根據(jù)項目實際情況，由項目經(jīng)理、需求人員或客戶業(yè)務(wù)代表進行測試。(7分)

    (2)采取程序員交叉測試的方法。(3分)

    (3)若情況允許，可以在程序員自己發(fā)現(xiàn)缺陷趨于平穩(wěn)后，再提交給專門測試人員進行測試。(3分)