當乙個測試團隊發展到一定規模，各個專案進行測試的時候，都需要對活動進行管理，保證各個活動正常有序的進行，那麼該如何進行系統測試管理呢?大概歸納了一下，包括一下6個方面：
一、測試套件管理
測試套件包括：測試用例
、驅動和樁。特別地，自主開發
的專有測試工具也是測試套件。測試用例包括文字描述型測試用例、指令碼型測試用例和測試輸入、預期的輸出資料。所有這些測試套件的選擇使用都是按計畫，有步驟地進行的所有的測試套件都和被測軟體的版本有著密切的對應關係。
主要對測試套件進行這樣一些管理要求：
1) 驅動和樁以及自主開發的專用測試工具能在對應的測試版本情況下立即提取並正確執行;
2) 指令碼型測試用例能在對應的測試版本情況下立即提取並正確執行;
3) 用例集的執行狀態和執行結果;
4) 用例狀態和系統需求的對應關係等。
因此，測試套件應該是有版本的，能唯一標識的，執行狀態和結果是可報告和有追蹤性的
二、測試工具管理
建議按照四個步驟來進行：
1. 定義軟體測試工具
的需求：分析組織的能力和準備程度，定義組織的需求，定義成功的準則，建立軟體測試工具採用策略。
2. 評價和選擇軟體測試工具：評審軟體測試工具的工具市場，對測試工具進行評價和選擇。
3. 進行實施試點：決定試點特性，計畫試點，執行試點，評價試點，決定是否購買。
4. 推廣使用工具：定期評審，收集使用效果。
對於自製工具，經過歸檔後，可以參照上述四個步驟進行管理
三、系統測試活動管理
測試相關人員在專案生命週期的每個子週期或迭代中各個階段的測試活動分別如下：軟體測試
a) 立項階段
在專案啟動階段，開始測試前期準備，擬制初步的測試計畫
b)需求分析
階段
專案進入需求分析階段，測試團隊的工作開始全面展開，需要確定專案的範圍驗證，質量
要求定義，測試策略制訂，測試流程
剪裁，測試工具、測試環境
和裝置準備，測試風險識別。主要活動如下：
1、 對軟體需求的驗證：在軟體需求被系統人員分析完成後，測試團隊開始參與需求評審，對需求說明書進行驗證，主要關注點是：軟體需求的準確性，一致性，完整性，相關性，依賴性，可跟蹤性，可測試性，可理解性。以使軟體需求成為專案開發的基礎和測試計畫的起點。
2、 如果需要自主設計開發測試工具，還需進行測試工具的需求採集和分析。
3、 編寫《系統測試計畫》
c) 設計階段
1、 系統架構評審：在設計階段，測試團隊參與設計評審，了解設計架構，對軟體架構的可測試性提出意見。
2、 系統測試設計：根據系統需求
、系統方案和系統測試計畫編寫
系統測試方案
，並根據系統需求和系統測試方案編寫系統測試規程。
3、 系統測試開發
：根據系統測試規程進行測試用例
開發。
4、 如果需要自主設計開發測試工具
，進行方案設計。
d) 系統測試階段
當系統通過對內交付基線後，專案進入系統測試階段。系統測試是將軟體系統，作為整個系統的乙個元素，與硬體、某些支援系統元素結合在一起，在實際執行環境下，對系統進行一系列的測試活動。系統測試的目的是驗證系統的需求。
1、 系統測試執行：
2、 bug定級, 跟蹤和管理。在系統測試過程
中發現的問題以bug或者建議形式提交給軟體開發組，這些bug的級別需要給出定義。每個級別的bug定義見附錄a。
3、 測試度量
和分析活動。
4、 測試評價和總結
四、測試計畫管理
a) 測試計畫
測試計畫用於明確測試思路，指導測試活動，是成功執行和管理測試專案的保證，通過測試計畫可以提高可交流性，避免測試的隨意性。測試過程一定要按測試計畫來進行。
系統測試計畫分為兩級管理：系統測試計畫和系統測試方案。
由於要測試的內容可能涉及到軟體的需求和軟體的設計，因此必須及早開始測試計畫的編寫工作。不應在著手測試時，才開始考慮測試計畫。制定測試計畫需遵循以下原則：
1. 制定計畫的人應該是最了解專案和測試資源的人。測試計畫要經過專案組的評審，避免出現不合理的計畫。
2. 計畫安排要結合需求，執行優先順序要體現需求的優先順序。在同等優先順序的情況下，要先安排技術難度高的測試項，增加計畫的可調控性。
3. 測試乙個大的軟體專案，應該將進度表分為若干個里程碑。乙個里程碑之內的多個任務可以同步進行。
4. 制定的計畫應明確、可及、可度量、可追蹤。
5. 計畫表中必須留有緩衝時間，並將緩衝時間用到不確定的事情上。推薦微軟50% 緩衝規則。
6. 由於內外部因素可能需要對測試計畫進行調整，這時需要及時對測試計畫進行變更和維護
b) 系統測試計畫
系統測試計畫的內容應該包含以下幾大部分：測試範圍、策略、測試配置和環境、暫停和再啟動標準、進度、人力資源、風險和應對等。
系統測試計畫屬於專案計畫的乙個部分。專案計畫是在專案生命週期裡對專案資源、進度的乙個規劃，而測試計畫是對里程碑範圍內測試資源、活動、進度等的規劃。測試活動的啟動和暫停受控於專案進度計畫。
測試計畫也應該和專案計畫一起納入配置管理
，和專案計畫同步進行更新
c) 系統測試方案
因為系統測試往往是以版本迭代測試的方式開展，因此，針對每次測試，為了有效地規範測試執行的過程，所以還應當制定系統測試方案。一般來說，系統測試方案可以分為兩個層面：測試負責人層面和測試人員
層面，二者考慮的重點有所不同。
系統測試方案在評審通過後應歸檔管理，它是系統測試執行的依據，系統測試的執行活動應遵照該計畫執行。一般來說，參加系統測試方案評審的人員應包含但不限於以下人員：測試組組長，測試人員，測試申請中指定的本次系統測試的版本負責人。
五、測試風險管理
a) 測試風險和管理承諾
了解測試任務的風險有助於對潛伏的可能出現的問題事先作好思想上和資源上的準備，用以規避風險，把風險的影響降到最低。
測試風險可分為外部風險和內部風險：
外部風險就是導致測試實際情況和計畫不一致的外部因素。包括：需求
項變更，專案進度調整，提交測試工作產品的質量
不符合要求等。
內部風險就是測試團隊內的一些不確定因素。包括測試進度延誤，測試工程師
流失，測試工具
不到位等。
對風險的防範，高層的支援是很重要的，他能決定相關資源的保障，規避專案進度的失控情況，對需求項的更改也能起到控制作用。所以在測試管理
裡，風險管理和高層承諾都要考慮，高層管理的承諾其實也是一種風險。
b) 測試常見風險
測試常見風險：
1. 測試計畫過於樂觀;
2.開發
組沒能按計畫提交相應的測試工作產品;
3. 測試計畫要求的硬體和軟體裝置或資源未能滿足;
4. 測試工具的應用沒能達到預期深度;
5.測試人員
的流失，或因出差或休假造成的人力資源不足;
6. 過多的臨時任務;
7. 重要測試資料丟失等
測試計畫階段的典型風險有：
1、測試計畫經常是等到開發周期後期才開始實行，使得沒有時間有效的執行計畫;
2、測試計畫的組織者可能缺乏足夠的測試經驗;
3、測試的量度和複雜性可能太大，沒有自動化工具，很難計畫和控制
六、測試文件管理
專案測試計畫、測試方案
、測試規程會因專案開發活動的變更而變更，應置於適當的管理和控制之下，測試活動相關的工作產品的變更依據變更管理過程的原則實施。
測試規程作為組織測試活動的基礎和有形財富，應當得到有效地積累、維護和管理。可以選擇配置管理
工具如svn
或qualitycenter
。(主要採用qualitycenter管理測試規程)測試管理人員應確保測試方案中準備測試的條目都應有測試規程對應，測試報告中的測試記錄和bug記錄都對應於某條或某組測試規程，如果測試中發現的問題不能與某條測試規程對應，測試規程應及時得到補充和完善。通過度量
測試用例
在測試完成之後對應的結果或狀態(通過、失敗)以及當次測試使用的測試用例數來輔助判斷測試的結果。
使用 TestLink 進行測試管理
testlink 是sourceforge的開放源 專案之一。作為基於web的測試管理系統，testlink的主要功能包括 testlink的最新版本是1.6.2。在本文接下來的部分裡，作者將詳細地介紹使用testlink1.6.0來進行測試管理的完整過程。一 安裝啟動 2 將 testlink 安...
測試 管理系統 WMS TMS CMS WCS
聽分享 思考下面問題 自學能力 先自己查閱資料 自己弄明白 作為一名職業人，要有自學能力 解決問題的能力 與prm 專案經理 核對自己所了解資訊是否準確？課前分享講解自己了解形象，讓自己更清晰 熟悉了解知識，為就業增加薪資做準備 專案學習 wms tms cms wcs系統是什麼？上面系統中文名稱是...
如何進行公升級測試
什麼是公升級測試？比如說你們公司開發的產品現已經發布的是v1.0，由於被發現存在缺陷，這時就需開發patch或hot fix，並進行公升級測試，然後發布v1.1。公升級測試聽起來似乎挺平常的，但它其實也是軟體測試中比較重要的一部分，它通常包括以下內容 安裝測試 資料庫測試 應用測試 文件測試 安裝測...