翻譯：測試成熟度模型集成（TMMi）（15）

SG 4 Develop a Test Plan
SG4 開發測試計劃
A test plan is established and maintained as the basis for managing testing and communication to
stakeholders.
測試計劃被建立和維護，作爲管理測試和與相關人員通訊的基礎。
SP 4.1 Establish the test schedule
SP 4.1 建立測試時間表
The test schedule with predefined stages of manageable size is established and maintained based on
the developed test estimate and defined test lifecycle.
在已開發的測試評估和已定義的測試生命週期基礎上，測試時間表和預定義的可管理大小的階段被建立和維護。
Typical work products
典型工作產品
1. Test schedule
1. 測試時間表
Sub-practices
1. Identify test scheduling constraints such as task duration, resources, and inputs needed
2. Identify test task dependencies
3. Define the test schedule (timing of testing activities, test lifecycle phases and test milestones)
4. Document assumptions made in defining the test schedule
5. Establish corrective action criteria for determining what constitutes a significant deviation from the
test plan and may require rescheduling.
子實踐
1. 確定測試時間表約束條件，如任務週期，資源，必要的輸入等
2. 確定測試任務依賴
3. 定義測試時間表（測試活動時間，測試生命週期階段和測試里程碑）
4. 在定義測試時間表時記錄假定條件
5. 建立矯正的行動標準，以決定什麼構成源自測試計劃的重大偏離，可能需要重新計劃
SP 4.2 Plan for test staffing
SP 4.2 測試人員計劃
Plan for necessary test staffing resources with the required knowledge and skills to perform the
testing.
計劃必要的擁有相關知識和技能的測試人力資源，以執行測試工作。
Typical work products
1. Staffing requirements
2. Inventory of skill needs
3. Staffing and new hire plan
4. Test training plan
典型工作產品
1. 所需人員編制
2. 所需技能的詳細清單
3. 新聘用人員編制和計劃
4. 測試培訓計劃
Sub-practices
1. Determine staffing requirements based on the work breakdown structure, test estimate and test
schedule
2. Identify knowledge and skills needed to perform the test tasks
3. Assess the knowledge and skills available
4. Select mechanisms for providing needed knowledge and skills
子實踐
1. 在工作分解結構，測試評估和測試時間表的基礎上決定人員編制
2. 確定所需的知識和技能，以執行測試任務
3. 評估現有的知識和技能
4. 提供必需知識和技能的選擇機制
Examples of mechanisms include the following:
? In-house training
? External training
? Coaching
? External skill acquisition
選擇機制的例子包括如下：
 內部培訓 外部培訓 教練 外部技能獲取
5. Incorporate selected mechanisms into the test plan
5. 把選擇機制合併到測試計劃中
SP 4.3 Plan stakeholder involvement
SP 4.3 計劃相關人員參與
Plan the involvement of identified stakeholders.
計劃已明確的相關人員參與
Stakeholders are identified from all phase of the test lifecycle by identifying the type of people and
functions needing, representation in testing activities and describing their relevance and the degree of
interaction for specific testing activities. A two-dimensional matrix with stakeholders along one axis
and testing activities along the other axis is convenient for accomplishing this identification.
相關人員被確定，從測試生命週期的所有階段，通過明確人員的類型和功能需要，在測試活動的表現，描述他們的關聯和與特定測試活動交互的深度
Typical work products
典型工作產品
1. Stakeholder involvement plan
1. 相關人員參與計劃
SP 4.4 Identify test project risks
SP 4.4 明確測試項目任務
The test project risks associated with testing are identified, analyzed and documented.
測試項目任務被確定，分析和存檔
Typical work products
1. Identified test project risks
2. Prioritized test project risk list
3. Test project risk contingencies
典型工作產品
1. 確定測試項目任務
2. 確定測試項目任務的優先次序
3. 測試項目風險應急
Sub-practices
1. Identify test project risks
子實踐
1. 確定測試項目風險
Examples of project risk identification techniques include the following:
? Brainstorming
? Expert interviews
? Checklists
項目風險辨認技術包括如下：
 腦力激盪 專家評審 檢查單
2. Analyze the identified test project risks in terms of likelihood and impact
3. Prioritize the analyzed test project risks
4. Review and obtain agreement with stakeholders on the completeness and priority level of the
documented test project risks
5. Define contingencies for the (high priority) test project risks
6. Revise the test project risks as appropriate
2. 分析已確定的測試項目風險，就可能性和影響而言
3. 確定已分析的項目風險的優先級
4. 對已存檔的測試項目風險的完整性和優先級進行評審並獲得相關人員的一致同意
5. 對（高優先級的）測試項目風險定義應急措施
6. 適當的時候修訂測試項目風險
Examples of when test project risks may need to be revised include:
? When new test project risks are identified
? When the likelihood of a test project risk changes
? When test project risks are retired
? When testing circumstances change significantly
何時需要修訂測試項目風險包括如下：
 當新的測試項目風險被定義時
 當測試項目風險可能改變時
 當測試項目風險被撤掉時
 當測試環境顯著改變時
SP 4.5 Establish the test plan
SP 4.5 建立測試計劃
The test plan is established and maintained as a basis for managing testing.
The results of previous practices are documented in an overall test plan, tying together the information
in a logical manner.
測試計劃被建立和維護，作爲管理測試的依據。
之前實踐的結果被記錄在總體的測試計劃中，用合乎邏輯的方式把這些信息捆綁在一起。
Typical work products
典型工作產品
1. Test Plan
1. 測試計劃
Examples of elements of a test plan include the following [after IEEE 829]:
? Test plan identifier
? An overall introduction
? Non-compliances to the test strategy and its rationale
? Items to be tested (including priority level) and not to be tested
? Features to be tested (including priority level) and not to be tested
? Test approach (e.g. test design techniques)
? Entry and exit criteria
? Suspension and resumption criteria
? Test milestones and work products
? Test lifecycle and tasks
? Environmental needs and requirements (including office environment)
? Staffing and training needs
? Stakeholder involvement
? Test estimate
? Test schedule
? Test project risks and contingencies
Refer to the “Test Environment” process area for information on environmental needs and
requirements.
測試元素包括如下（在IEEE 829之後）
 測試計劃標識
 總體介紹
 對測試策略的違背，並列出理由
 需要測試和不需要測試的條目（包含優先級）
 需要測試和不需要測試的功能（包含優先級）
 測試方法（如測試設計技術）
 進入和退出標準
 暫停和恢復標準
 測試里程碑和工作產品
 測試生命週期和任務
 環境的需要和要求（包括辦公環境） 人員配置和培訓需求 相關人員的參與 測試評估 測試時間表 測試項目風險和應急措施環境的需要和要求的信息請參考“測試環境”過程域。