1、前言

進(jìn)入公司半年有余，接觸公司的開(kāi)發(fā)項目至今，對公司的情況有了更深的了解。在此提出一些建議，希望可以對部門(mén)組建測試團隊起到貢獻微薄之力。

1.1 開(kāi)發(fā)部現狀

目前開(kāi)發(fā)部完成或未完成的項目基本存在如下情況：

軟件交付遲遲不能按照計劃時(shí)間如期交付關(guān)閉；

大項目合同金額小，加之開(kāi)發(fā)部人力資源有限，導致項目不賺錢(qián)或賠錢(qián)；

需求隨著(zhù)開(kāi)發(fā)的深入不斷的新增或更改；

外包人員的開(kāi)發(fā)能力、對項目不夠負責的態(tài)度等問(wèn)題，不僅導致項目質(zhì)量的低下，間接導致后續交付的種種問(wèn)題；

測試團隊依舊沒(méi)有雛形，測試人員利用率低下或高投入低產(chǎn)出；

上述的幾個(gè)問(wèn)題體現出開(kāi)發(fā)部的人力資源、管理體系和組織機構不夠完善，仍需要管理階層花些心進(jìn)行規劃完善。

2、測試人員在軟件開(kāi)發(fā)各階段任務(wù)

表1：軟件測試流程

軟件測試流程如表1，包括測試計劃、測試設計、測試執行及測試總結，測試人員的主要任務(wù)：

盡早的發(fā)現問(wèn)題，盡可能的發(fā)現軟件程序、系統和產(chǎn)品的問(wèn)題；

針對問(wèn)題進(jìn)行分析、分類(lèi)總結和跟蹤；

督促開(kāi)發(fā)人員盡快解決程序中的缺陷；

幫助項目管理人員制定合理的開(kāi)發(fā)計劃；

幫助改善開(kāi)發(fā)流程、提高產(chǎn)品開(kāi)發(fā)效率；

2.1 設計

設計包括需求設計、概要設計和詳細設計，目前開(kāi)發(fā)部的需求設計似乎涵蓋了3種設計；測試人員在該階段需要做的就是：熟悉需求，對需求的熟悉程度應該高于一般的開(kāi)發(fā)人員；

2.1.1 現狀

深分開(kāi)發(fā)部二次開(kāi)發(fā)項目周期短，項目需求不盡相同，測試人員未參加需求調研和設計，很大程度上是個(gè)人對文檔的理解或同項目經(jīng)理、需求人員的確認。

影響：

1、對需求理解膚淺不夠深刻；

2、部分需求印象不深或毫無(wú)印象，導致需求遺漏；

3、刻意遵守文檔內容或開(kāi)發(fā)人員的設計，缺少個(gè)人觀(guān)點(diǎn)；

4、編寫(xiě)測試用例產(chǎn)生該覆蓋的需求沒(méi)有涉及，不用驗證的卻編寫(xiě)了測試用例；

2.1.2 建議

需求評審

需求設計人員完成軟件需求說(shuō)明書(shū)，要發(fā)給參與項目的每位同事進(jìn)行需求評審，參與評審的人員要列出需求說(shuō)明書(shū)中存在的問(wèn)題及疑問(wèn)；

需求評審會(huì )

需求評審會(huì )的目的是講解并解答評審人員針對需求說(shuō)明書(shū)所提出的問(wèn)題及疑問(wèn)，更改需求中的問(wèn)題，完善軟件需求說(shuō)明書(shū)，需求評審會(huì )也是加深需求理解的好途徑；

需求變更/新增

項目需求變更/新增，必須通知測試人員，更新需求說(shuō)明書(shū)要及時(shí)發(fā)布最新的版本。

注：設計階段可能包括項目開(kāi)發(fā)計劃，此階段要相應的出測試計劃；

2.2 編碼

編碼階段測試需要編寫(xiě)測試大綱、測試用例，根據項目具體情況，決定測試用例的詳細程度，但需求功能點(diǎn)必須全部覆蓋。

測試用例文檔由簡(jiǎn)介和測試用例兩部分組成。簡(jiǎn)介部分編制了測試目的、測試范圍、定義術(shù)語(yǔ)、參考文檔、概述等。測試用例部分逐一列示各測試用例。每個(gè)具體測試用例都將包括下列詳細信息：用例編號、用例名稱(chēng)、測試等級、入口準則、驗證步驟、期望結果（含判斷標準）、出口準則、注釋等。

測試用例是軟件測試的核心，測試用例需要完善的情況包括：

第一、在測試過(guò)程中發(fā)現設計測試用例時(shí)考慮不周，功能點(diǎn)缺失；

第二、軟件自身的新增功能以及軟件版本的更新（需求新增及變更），測試用例也必須配套修改更新。

第三、在軟件交付使用后反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成；

2.3 測試

測試的流程如表1所示，測試執行階段是一項重復勞動(dòng)，所以我們應該盡量避免無(wú)用功。那么測試計劃就顯得相當重要。

測試計劃是在軟件測試中最重要的步驟之一，它在軟件開(kāi)發(fā)的前期對軟件測試做出清晰，完整的計劃，不光對整個(gè)測試起到關(guān)鍵性的作用，而且對開(kāi)發(fā)人員的開(kāi)發(fā)工作，整個(gè)項目的規劃，項目經(jīng)理的審查都有輔助性作用。

測試計劃的目的包括：

（1）將需求和總體設計分解成可測試，應該測試，推遲測試和無(wú)法測試的范圍

（2）對每個(gè)范圍制訂測試的策略和方法

（3）制訂release和停止測試的標準

（4）準備測試所需要的環(huán)境

（5）確定測試風(fēng)險

（6）確定軟件測試目標

（7）確定測試所需要的資源其他相關(guān)信息

（8）制訂測試進(jìn)度和任務(wù)安排

2.3.1 現狀

目前開(kāi)發(fā)部測試人員測試計劃設計相對較少，也存在沒(méi)有測試計劃的情況，總體來(lái)說(shuō)開(kāi)發(fā)部現在的情況如下：

1）項目周期小，不需要測試人員參與；

2）一個(gè)測試人員應付一個(gè)項目；

3）測試人員對項目情況不夠了解，工作沒(méi)有主觀(guān)能動(dòng)性；

4）開(kāi)發(fā)的人員缺少軟件集成測試，不間斷的更新版本；

5）缺少測試文檔及缺陷管理體系；

2.3 建議

重視測試計劃的設計；

完善測試流程，制定測試標準；

需要增加測試人員，完善測試的梯隊；

2.4 交付

目前部門(mén)并沒(méi)有出具相應的測試報告或出局了相對簡(jiǎn)單的測試報告，測試報告是軟件測試重要的輸出文檔，一個(gè)完整的測試報告應該包括如表2，測試報告應該讓看到報告的人對項目測試情況一目了然。

表2：測試報告內容

3、測試團隊組建

3.1 測試機構

測試團隊的組成一般由測試組長(cháng)、資深測試工程師和初級測試工程師；

1）測試組長(cháng)：負責項目的管理、測試計劃、測試用例、任務(wù)安排等；

2）測試設計人員/資深測試工程師，產(chǎn)品設計規格說(shuō)明書(shū)的審查、測試用例的設計、技術(shù)難題的解決、培訓和指導、實(shí)際測試任務(wù)的執行；

3）一般（初級）測試工程師，執行測試用例和相關(guān)的測試任務(wù)。

4）需要的情況下可以設置專(zhuān)門(mén)的性能測試工程師；

圖1：測試梯隊

目前，公司希望幾個(gè)分散的測試人員組成一個(gè)測試團隊不太現實(shí)，且沒(méi)有測試的梯隊架構，這樣就會(huì )導致員工激情的減少。

3.2 測試團隊地位

圖1 三國鼎立

測試機構在組織中地位的確定事關(guān)測試機構執行測試任務(wù)的效力。測試機構的獨立是十分重要的。

目前，開(kāi)發(fā)部為項目組配備一個(gè)測試小組幾乎是不可能的，但是我們至少應該在整個(gè)研發(fā)部門(mén)成立獨立的測試小組，統一開(kāi)展測試任務(wù)的執行，同時(shí)為保證與不同的產(chǎn)品緊密銜接，應該實(shí)行責任測試工程師制度。

測試團隊應直接向研發(fā)部門(mén)的質(zhì)量總監負責，質(zhì)量總監在研發(fā)部門(mén)的地位應該等于或者高于開(kāi)發(fā)團隊的最高負責人，只有這樣才能保證測試機構的權威性。

3.3 規范執行

針對目前深分開(kāi)發(fā)部的情況，首先要做的是以下三個(gè)方面：

第一，建立缺陷管理信息系統，收集整理遺留的缺陷，報告相關(guān)數據；

第二，建立嚴格的版本管理制度，追蹤發(fā)布的每一個(gè)版本；開(kāi)發(fā)提供不斷修訂的版本，這樣導致了修復問(wèn)題的代價(jià)變得越來(lái)越大，因為每一次修改都很倉促，常常是解決了這個(gè)問(wèn)題，衍生出很多其他的問(wèn)題。解決這個(gè)問(wèn)題的關(guān)鍵是建立嚴格的版本管理，任何一個(gè)版本的發(fā)布都必須經(jīng)過(guò)測試小組全面的測試，同時(shí)詳細記錄每一個(gè)版本的信息。這些都與配置管理息息相關(guān)，所以測試體系的建設中還必須建立有效的配置管理。

提第三，高開(kāi)發(fā)人員的編碼質(zhì)量，建立嚴格的代碼評審制度，對于外包開(kāi)發(fā)人員，需要考核外包人員能力，最好有可以進(jìn)行代碼走讀能力的開(kāi)發(fā)人員；