一、 項目管理概況
筆者參與的項目合同造價約九十多萬元，工期約9個月，分為七八的子模塊，通過迭代的方式進行開發。SQA、過程監控等獨立于項目組，測試人員、代碼編寫人員屬同一個項目組。主要測試人員在需求分析階段介入項目中。在項目的組織結構如下：
在項目開發過程中，主要配備了一個項目經理，兩名軟件經理以及一名測試經理。其中，測試經理獨立于軟件經理，隸屬于項目經理領導。這樣設置的好處，既能在一定程度上保證測試的獨立性，又不至于溝通成本、測試成本過大。眾所周知，測試附屬于開發，是難于保證軟件的質量。但測試獨立到何種程度則，比較難于把握。太獨立，會導致測試人員與開發人員的溝通成本增加，溝通都是文檔化，由于缺乏必要的口頭溝通，會導致變更無法及時傳遞，測試與開發常產生沖突。成本增加了，軟件質量反而下降了。
二、測試項目獎的確定及分配：
測試工作作為項目管理的一部分，不參與項目獎的分配是會導致測試人員心態的失衡，同樣無法保證軟件的質量。由于，不同的項目對測試技能、測試工作時間等的要求的不同，在這里就不探討測試人員與開發人員項目獎的比例，主要還是探討測試組中項目組在整個開發團隊中確定方式和時間以及分配方式。
1、測試組項目獎的確定：
測試組項目獎的確定一般在子模塊的需求分析結束后，根據形成的需求用例規約確定測試計劃，測試用例的設計、執行、評估所要耗費的時間、人力資源、所需測試技能后，由測試經理與項目經理、軟件經理協商測試組項目獎在整個子模塊中項目獎的比例，同時確定上下浮動的比例以及約束條件。
2、測試經理項目獎的確定
現在通常的項目管理方式是，項目經理確定各個軟件經理、測試經理所在項目獎的比例。然后由軟件經理確認所帶領的小組成員間項目獎的分配比例。因為軟件經理、測試經理的份額的多少會影響每個每個項目組成員的比例。而現在的分配方式，在一定程序上是不民主，不公平的，很容易出現長官意志，或者是憑私人關系而得到較高份額的項目獎，恣生腐敗現象。具體就測試經理而言，其工作表現，其下屬、平級關系的軟件經理以及上下級關系的項目經理都很清楚。因此，對測試經理項目獎在測試組中的比例由以下方式確定：
項目經理30%，軟件經理30%，測試經理20%，測試小組占20%;
舉例說，整個項目將有三萬元，測試組項目獎占10%，即三千元。其中，項目經理認為測試經理應得30%，軟件經理認為測試經理應得40%，測試經理認為自己應得50%，測試組成員認為測試經理應得30%。則測試經理能得到：3000*(30%*30%+40%*30%+50%*20%+30%*20%)=3000*0.37=1120元。
3、測試人員項目獎的確定;
80%根據測試時間、質量、經驗值通過一定的轉換后確定;10%測試用例設計及執行;10%由測試經理根據貢獻確定;
(1)80%項目獎的計算方法，如下表
任務 人員一 人員二
計劃時間(A)完成時間(B)質量(C)經驗系數(D)標準時間(E)計劃時間完成時間質量經驗系數標準時間
任務一108118.81080.80.85.63
任務二10120.919.7210120.90.87.78
任務三1081.11.110.651081.119.68
任務四101211.111.8810121110.8
小計41.05小計33.88
合計 74.94份額54.8%份額45.22%
說明：
1計劃時間根據需求用例規約頁數確定測試用例頁數來確定計劃時間，具體見附錄一;
2完成時間已日志上記錄為依據;
3質量有測試經理確定，范圍為0.8到1.2之間;
4經驗系數:有測試小組共同確定，在0.8到1.2之間;
5標準時間E=A*(1-(A-B)*0.05)*C*D;
6每月評定一次
(2) 10%測試用例設計及執行;
主要是測試用例的設計、執行以及用例對質量的保證，模塊的關聯，業務的熟悉，嚴重級別為高的比較及數量，有效缺陷數量
(3)10%由測試經理根據貢獻確定;
軟件經理、項目經理以及用戶對負責模塊的反映;被開發人員拒絕修改，但用戶反饋要修改的缺陷，使用測試工具對測試效率的提高或者對其他測試人員的幫助;
三、 測試小組與開發小組的約定：
1、缺陷的管理;
測試人員與開發人員以TD作為交流的依據，因此必須測試人員與開發人員必須每天瀏覽TD上的缺陷記錄，并根據優先級作為開發員修改的依據：
優先級開發工程師(修復)測試工程師(回歸測試)
高缺陷狀態為Open后，正常情況應在2個工作天內修改完成;如特殊情況，要在備注中注明原因，但也應在3個工作天內完成;在開發修改完成后，正常情況應在1個工作天內完成;如特殊情況，要在備注中注明原因，但也應在2個工作天內完成;
中缺陷狀態為Open后，正常情況應在5個工作天內修改完成;如特殊情況，要在備注中注明原因，但也應在8個工作天內完成;在開發修改完成后，正常情況應在2個工作天內完成;如特殊情況，要在備注中注明原因，但也應在5個工作天內完成;
低缺陷狀態為Open后，正常情況應在10個工作天內修改完成;如特殊情況，要在備注中注明原因，但也應在12個工作天內完成;在開發修改完成后，正常情況應在5個工作天內完成;如特殊情況，要在備注中注明原因，但也應在7個工作天內完成;
2、版本的管理：
模塊開發初期，兩周提交一次版本;
模塊開發中期：一周提交一次版本;
模塊開發后期：2到3天提交一次版本;
附件三：開發期的界定;
提交版本時必須提供本次版本中實現的需求，復雜操作必須提供簡單說明，存在約束的功能必須說明，并確定下次提交版本的時間;
提交版本前，必須確保類文件在VSS上是最新的，已check in 的，類文件必須是編譯正常的文件;要明確jar包的目錄，要引用的庫文件;
數據庫腳本需要更新時，必須明確提示，并盡可能提供不清空數據的替代方法;
3、需求變更及其他事項的處理：
當需求規約發生變更時，開發人員應及時用郵件通知相關的測試人員和測試經理，如需求變更多大時，應形成文檔提交;
4、小組內部驗收測試：
模塊開發后期，已確定無需改動后，由測試小組所有成員以及咨詢工程師參與測試，并由測試經理在咨詢工程師的協助下提交模塊質量級開發人員質量報告給技術經理和項目經理;
四、 測試小組約定
1、測試 http://www.csai.cn (單位為工作天/周)：
測試工程師測試經理
開發初期11
開發中期32
開發后期53
2、 會議：
項目例會后第二天召開小組會議，時間為1到2小時，包含內容為小組成員小結，新版本的對應的測試計劃，測試用例及預期執行時間;
每月召開小組會議，確定小組成員的考核;2到4個小時
每個季度召開會議，確定項目獎的分配建議，包項目經理批準;
3、測試方式：
實行交叉測試和集中測試相結合的方式進行，主要進行黑盒測試，以手工測試為主，在項目后期進行簡單的性能測試;
開發小組提交版本后，有專門負責相應模塊的測試工程師進行初步測試，在開發小組提交新版本前的一到兩天測試組所有成員進行集中測試，測試工程師必須提供測試用例的執行情況，模塊的關聯情況，簡單演示，并以此作為考核的依據;
4、測試用例：
測試用例不但可以保證軟件的質量，還會大大縮短，需求完成后的測試時間。因此，測試用例必須寫，而且是在模塊需求規約確定后，在開發第一次提交版本前完成。執行過程中，如有需求變更，測試用例規約也要更新;
五、 對開發人員的考核：
測試小組除了負責項目的質量外，還根據在測試過程中提出相應的數據，軟件經理考核開發人員的依據。主要是在提出以下三方面的數據：
1、模塊內部驗收測試
并由測試經理在咨詢工程師的協助下提交模塊質量級開發人員質量報告給技術經理和項目經理;
2、 缺陷上嚴重級別、狀態及優先級別的處理
類似缺陷出現的次數，拒絕修改缺陷而導致用戶對軟件質量的不滿，或者用戶要求修改等類似的內容。
3、 對測試的配合以及java類文件的編譯;
附錄一：計劃時間的簡單估計：
1、 計算需求文檔的頁數，得出系統測試用例的頁數：
2、 需求頁數：
系統測試用例頁數 ≈1：1(含數據)由系統測試用例頁數計算編寫系統測試用例時間; 編寫系統測試用例時間 ≈ 系統測試用例頁數×1小時
3、 計算執行系統測試用例時間
編寫系統用例用時：執行系統測試用時 ≈ 1：2*(執行次數);
如：需求有10頁，則測試用例約有10頁(含測試數據)，書寫測試用例的時間為20小時;
執行用例三次的時間為10*2**3=60小時
附件二：優先級的定義
高：導致測試無法繼續進行，必須立刻進行修復;對用戶產生很大影響，必須優先解決。
中：對用戶產生一定影響，可正常排隊解決。
低：對用戶產生輕微影響。
附件三：開發期的界定;
開發初期：子模塊完成需求調研、分析，形成用例規約;
開發中期：子模塊編碼開始到編碼完成主要的需求;
開發后期: 編碼優化工作的開始;
文章來源于領測軟件測試網 http://www.kjueaiud.com/
