測試計畫總是受到專案計畫影響而延期怎麼辦？
從我們團隊的經驗來看：專案計畫變化一般分為需求變化、資源變化、進度變化3種。
1、需求變化。這是最沒有辦法的。除了重新定義測試計畫外，似乎沒什麼可做的了。
在這種變化中，我認為最重要的測試主管的堅持，需要對需求重新分析，並要求足夠的資源與進度。
2、資源變化。經常出現的情況是資源被其他專案挪用或者臨時異常。
目前的措施是做好測試主管的備份，任何專案都安排1個2人小組負責，當然，測試主管只有1個。
在資源被其他專案挪用時，我要求任何專案都不能停止，至少由測試主管以天為單位跟蹤專案進度，直到專案真正close。
3、進度變化。這就需要看測試團隊負責人與測試負責人的溝通能力了。
如果進度要求提前時，如果測試主管無法改變（一般也無法改變），一定要做好風險管理與預警。
變化總比計畫快，我認為應對的措施只有兩條：
1、進度管理與實時分析。不要讓測試進度失去控制。在任何時候都要知道目前測試所處的階段，並針對目前的情況實時分析，考慮在現有情況下的下一步計畫。
不要等，等需求、等開發，多考慮現在我們能做什麼？
2、風險管理。作為測試負責人，在了解目前測試所處的階段的情況下，還需要實時跟蹤目前的專案風險。當臨時遇到發布要求時，能盡可能的提供目前的風險，作為與專案經理溝通的依據。
並在無法改變發布要求時能提前做好風險應對措施。
軟體測試過程中用到的風險分析知識
**：網路**作者：佚名時間：2009-09-04 tag：測試風險分析點選： 19
最近整理的一些軟體測試過程中用到的風險分析知識：
列出系統中潛在問題的列表，然後與關鍵涉眾一起給這個列表中的專案確定優先順序； ansi/iso 9126 標註 --- 在質量的六個特徵之中 ---- 功能，可靠性，可用性，效率，可維護性和可移植性（fruemp） --- 定義了質量的子特徵，根據每個子特徵測量系統的質量度量，最後將這些度量翻譯成一種質量評估的方法；發現的費用 （cost of exposure ， coe） --- 找出潛在的問題和它們產生的影響，然後評估當這個問題發生時對業務產生的費用，以及發生這個問題的可能性；失效模式與影響分析（fmea） --- 找出潛在的問題，了解他們的影響（對於顧客和使用者），然後對他們進行分類（採納涉眾的建議），按照嚴重性（對系統的衝擊），優先順序（對商業利益的衝擊）和發生的可能性（失敗的機率）。
3）向關鍵渉眾收集關於質量風險，與這些風險相關的失敗模式，這些失敗對於質量的影響以及風險的優先順序方面的意見。找出降低每種風險的推薦措施。（指導質量風險分析過程的測試人員很重要，不僅要有一定的質量分析技術的技能，還要有一定的管理技能，能夠解決衝突和不同意見，確保會議按照日程和時間表進行等才能。
此外，必須就有一定的信譽和高層領導的支援。）
4）在分析中報告在其他專案文件中找到的任何早起錯誤，例如不明確的需求或需求丟失，以及設計問題等等。（在測試開始之前發現潛在的錯誤非常關鍵，首先，分析能夠發現含糊的，不可測試的或無法達到的需求和設計缺陷等的例項。其次，除了發現問題之外，質量風險分析過程也能夠指出解決辦法。
第三，優先順序確定的過程是一種給程式設計組的提前通知，指出我們將會測試什麼。）
5）以文件形式記錄對應於所使用技術的質量風險。將這些文件在渉眾之間傳閱以得到批准。根據需要重複第 3 ， 4 ， 5 步，以最後確定質量風險，它們的優先順序以及推薦措施。
6）將質量風險分析文件檢入專案的資料庫或配置管理系統中，將這份文件置於變更控制之下。（建立乙個可追溯性的資料庫）
要全面考慮質量風險的**，質量風險不僅**於產品和系統本身，也與專案過程和組織環境有關。比如開發團隊的技能和經驗，修改 bug 的質量和需要的時間等，比如到達開發專案的末期，還有許多需求變更，不經增加了風險，也增加測試工作量，這時候就要選擇乙個回歸測試集，分析變更，決定伴隨著特殊變更、條件或缺陷修復的回歸測試的可能性，也應該 -- 用質量風險分析來選擇最重要的測試。
erp專案工程驗收中測試流程記錄
**：網路**作者：佚名時間：2009-04-23 tag：erp測試流程點選： 299
軟體測試是為了發現錯誤而執行程式的過程。它不僅是軟體開發階段的有機組成部分，而且在整個軟體工程(即軟體定義、設計和開發過程)中佔據相當大的比重。軟體測試是軟體質量保證的關鍵環節，直接影響著軟體的質量評估。
軟體測試不僅要講究策略，更要講究時效性。驗收測試作為軟體測試過程的最後乙個環節，對軟體質量、軟體的可交付性和軟體專案的實施週期起到"一錘定音"的作用。
1、erp驗收測試的現狀
驗收測試是一種有效性測試或合格性測試。它是以使用者為主，軟體開發人員、實施人員和質量保證人員共同參與的測試。erp(企業資源規劃)作為提高企業管理創新能力的有力工具，其定義、設計、開發、實施和應用的過程遵循一定的規律。
這些規律表現在軟體過程控制、質量保證和軟體測試等方面。驗收測試關係到erp能否成功驗收，能否平滑步入維護期，能否快速實現效益。erp驗收測試的全面性、效率性、科學性、規範性、徹底性在廣大製造業企業和erp軟體**商中還是乙個嶄新的話題。
當前很多人對erp驗收測試工作存在一些誤解：
(1)由於erp軟體的複雜性、規模性，人們可能更多地關注它多變的需求定義、個性化解決方案、定製化開發過程，卻輕視了專案的驗收工作。這些"只重視開題和過程，不重視結題和維護"的做法，最直接的後果就是，形成了乙個個延期工程或"爛尾"專案。
(2)erp實施工作做好了，使用者企業可以把系統跑起來了，文件移交了，客戶簽字了，還有什麼必要做驗收測試。這種誤解源於對驗收測試的目的、流程、方法和意義缺乏認識。
(3)驗收測試是使用者企業的事，與軟體服務提供商無關。事實上，只有兩者密切配合，才能提高測試效率。
(4)將驗收測試理解成給使用者做演示。驗收測試要講究策略，不是走走過場，而是有計畫有步驟的執行活動，要進行科學的用例設計。
(5)驗收測試就是驗證軟體的正確性。驗收測試和其他的測試一樣，既要驗證軟體的正確性，又要發現軟體錯誤。只不過，驗收測試是以確認軟體功能是否滿足需求為主。
2、erp驗收測試的流程及方法原則
軟體包括程式、資料和文件。erp驗收測試的物件應當含蓋這三個方面。驗收測試的主體要以使用者企業為主，erp軟體服務**商積極配合；或以第三方測試為主，使用者和軟體**商共同配合。
erp驗收測試的基本流程如下圖所示，軟體實施人員要適時配合和敦促使用者做好驗收測試的各項準備工作，按計畫按步驟執行驗收測試，形成規範的測試文件，客觀地分析和評估測試結果，並跟蹤不合格現象，對軟體問題要分級分類管理，必要時要進行回歸測試，確保所有問題能得到關閉，最終成功通過驗收。
在測試方法上，由於驗收階段的特殊性，一般以黑盒測試和配置複審為主，以自動化測試和特殊效能測試為輔，使用者、軟體開發實施人員和質量保證人員共同參與。
erp驗收測試要注意以下幾個原則問題：
(1)驗收測試始終要以雙方確認的erp需求規格說明和技術合同為準，確認各項需求是否得到滿足，各項合同條款是否得到貫徹執行。
(2)驗收測試和單元測試、整合測試不同，它是以驗證軟體的正確性為主，而不是以發現軟體錯誤為主。
(3)對驗收測試中發現的軟體錯誤要分級分類處理，直到通過驗收為止。
(4)驗收測試中的用例設計要具有全面性、多維性、效率性，能以最少的時間在最大程度上確認軟體的功能和效能是否滿足要求。
3、erp驗收測試的內容及用例設計
erp驗收測試的目的是確認系統是否滿足產品需求規格說明和技術合同的相關規定。通過實施預定的測試計畫和測試執行活動確認軟體的功能需求、效能需求和文件需求。erp是較複雜的大規模性軟體，其驗收測試應當涵蓋確認測試和系統測試兩個方面的內容。
具體包括以下測試內容：安裝測試、功能測試、介面測試、效能測試、文件測試、負載壓力測試、恢復測試、安全性測試、相容性測試等。下面結合erp驗收測試的具體內容，談談用例設計的注意事項。
(1)安裝測試
安裝測試的目的在於驗證軟體能否在不同的配置情況下完成安裝，並確認能否正常執行。erp安裝測試的用例設計要注意以下幾點：
第一，根據erp的可移植性，選擇不同作業系統。
第二，選擇不同層次的硬體配置和軟體配置，一般選用最低、中等和最高三種配置進行測試，驗證系統對軟硬體環境的依懶性。
第三，觀察erp安裝程式在軟硬體資源充足的情況下能否正常安裝，安裝過程中是否給予充足的提示，是否存在流氓軟體的一些弊病，安裝完成後能否正常執行，能否徹底刪除。
第四，在資源不充沛的情況下，如磁碟空間不夠、內容不足等，系統能否完成安裝，能否給予各種提示。
(2)功能測試
功能測試是驗收測試中的主要內容。erp功能測試要包含以下專案：單個模組的查詢、增加、刪除、修改、儲存等操作；資料的輸入與輸出；資料處理操作，如匯入、結轉等；基礎資料定義的精度；計算的準確性，如倉庫的歷史庫存、當前庫存、貨位庫存是否準確；資料共享能力；身份驗證和許可權管理；介面引數和系統控制引數；單據流轉情況；狀態控制，如系統是否對mps在執行mrp分解、工單下達、車間任務排程等操作前後的狀態做了標識，狀態的改變是否正確；報表的列印輸出；審批流程定義及各種審批、反審批操作；簡訊傳送及管理；崗位及部門業務的操作，如從請購管理、採購計畫到採購訂單管理，再到採購到貨管理；跨部門的業務操作，如從銷售訂單到主生產計畫，從車間領料到倉庫出庫等等。
erp功能測試的用例設計要注意以下幾點：
第一，測試專案的輸入域要全面。要有合法資料的輸入，也要有非法資料的輸入。如，在測試基礎資料的定義時，若規定是數字，則既要輸入數字進行測試，也要輸入字母、空格等非數字進行測試。
數字包含整數、負數、小數，因而還要輸入這些不同的數字驗證數字的精度。
第二，劃分等價類，提高測試效率。在考慮測試域全面性的基礎上，要劃分等價類，選擇有代表意義的少數用例進行測試，提高測試效率。如，若mrp記錄有"剛形成"、"已派工""正執行"、"已完成"四種狀態，系統只允許對剛形成的mrp記錄做區域性性修改或刪除操作，那麼在測試時，將mrp記錄劃分為四類，每種狀態對應一類，每類各選一條記錄作為測試用例即可。
第三，要適時利用邊界值進行測試。如"訂單預排"中一般要求預排的數量大於0，那麼測試資料可以分別為0，-1，1，10000000(乙個非常大的正數)。
第四，重複遞交相同的事務。
第五，不按照常規的順序執行功能操作。
第六，驗證實體關係，實體間的關係有三種：一對一，一對多，多對多。如，乙個mps對應多個mrp，乙個mrp對應多個車間任務。
第七，執行正常操作，觀察輸出結果的異常性。如，刪除某條記錄對排序的影響；執行審批後，單據的狀態是否改變。
(3)介面測試
erp介面要符合現行標準和使用者習慣。軟體企業可以形成自己的特色，但要確保整個軟體風格一致。介面測試要從友好性、易操作性、美觀性、布局合理、分類科學、標題描述準確等方面入手。
測試用例的設計要重點掌握以下幾點：
第一，背景和前景的顏色是否協調，顏色反差是否用得恰當。
第二，軟體得圖示、按鈕、對話方塊等外觀風格是否一致，美觀效果所要求的螢幕解析度。
第三，視窗元素的布局是否合理，並保持一致。
第四，各種字段標題的資訊描述是否準確。
第五，快捷鍵、按鈕、滑鼠等操作在軟體中是否一致。
第六，視窗及報表的顯示比例和格式是否能適應使用者的預期需求。
第七，誤操作引起的錯誤提示是否友好。
效能測試計畫 XX專案
目錄1.簡介 2 1.1 目的 2 1.2 定義 首字母縮寫詞和縮略語 2 1.3 範圍 2 1.4 參考文獻 2 2.測試準備 2 2.1 系統效能要求分析 2 2.2 測試資料準備 3 2.3 測試環境準備 3 2.4 測試工具選擇 3 3.測試策略 4 3.1 測試場景 4 3.1.1 測試場...
XX專案測試計畫
修訂歷史記錄 a 新增，m 修改，d 刪除 所需文件 軟體需求說明 文件中需包括 對測試物件 構件 應用程式 系統等 及其目標進行簡要說明。需要包括的資訊有 主要的功能和效能 測試物件的構架以及專案的簡史 目標 確定現有專案的資訊和應測試的軟體構件，確定測試範圍,包括測試物件中將接受測試或將不接受測...
科技專案管理系統測試計畫
測試計畫 1引言 3 1.1 編寫目的 3 1.2 專案背景 3 1.3 定義 3 1.4參考資料 4 2 任務概述 4 2.1 目標 4 2.2 執行環境 4 作業系統 4 資料庫 4 客戶端 5 網路及硬體 5 3 計畫 5 3.1 測試方案 5 3.2 測試專案 5 3.3 測試準備 6 4 ...