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

PA 2.2 Test Planning
PA 2.2 測試計劃
Purpose
目標
The purpose of “Test Planning” is to define a test approach based on the identified risks and the defined test
strategy, and to establish and maintain well-founded plans for performing and managing the testing activities.
測試計劃的目標是在已識別的風險和已定義的測試策略基礎上定義測試方法，並建立和維護有依據的計劃來執行和管理測試活動。
Introductory Notes
介紹性說明
After confirmation of the test assignment, an overall study is carried out regarding the product to be tested, the
project organization, the requirements, and the development process. As part of test planning, the test approach is
defined based on the outcome of a product risk assessment and derived from the test strategy. Depending on the
level and type of risks, it is decided which requirements of the product will be tested, to what degree, how and
when. The objective is to provide the best possible level and type of coverage to the parts of the system with the
highest risk level. Based on the test approach the work to be done is estimated and as a result the proposed test
approach is provided with clear cost. The product risks, test approach and estimates are defined in close cooperation
with the stakeholders. Testers should not take these decisions themselves. The test plan will either
confirm, or explain non-compliance, with the test strategy. Within test planning, the test deliverables that are to be
provided are identified, the resources that are needed are determined, and aspects relating to infrastructure are
defined. In addition, test project risks regarding testing are identified. As a result the test plan will define what
testing is required, when, how and by whom. Finally, the test plan document is developed and committed upon by
the stakeholders. The test plan provides the basis for performing and controlling the testing activities. The test plan
will usually need to be revised, using a formal change control process, as the project progresses to address
changes in the requirements and commitments, inaccurate estimates, corrective actions, and (test) process
changes.
在確認測試任務分配後，一個總體的學習要被執行，包括要測試的產品，項目組織，需求和開發過程。作爲測試計劃的一部分，來源於測試策略，並基於產品風

險評估，測試方法要被定義。根據不同的水平和風險類型，它決定哪些產品需求要測試，到什麼程度，如何以及何時。目的是給系統的最高風險級別提供最有可

能的級別和覆蓋類型。基於測試方法，已完成的工作要被評估，以此爲結果，要提供費用清晰的建議測試方法。產品風險，測試方法和評估被定義在相關人員的

緊密合作上。測試人員不應該自己做決定。測試計劃於測試策略一起，確認或者解釋不遵守部分。在測試計劃裏，將要提供的測試交付被明確，需要的資源被確

定，基礎設施的相關方面被定義。另外，測試計劃風險被明確。因此，測試計劃將會定義測試需要什麼，什麼時候測，如何測以及由誰來測。最後，測試計劃文

檔有相關人員制定和實施。測試計劃爲執行和控制測試活動提供了依據。測試計劃通常需要加以修訂，使用正式的變更控制流程，隨着項目的進展，以解決需求

和承諾的變更，不準確的估計，糾正措施的變化，以及（測試）過程中的變化。
Scope
範圍
The process area “Test Planning” involves performing a product risk assessment on the test object and defining a
differentiated test approach based on the risks identified. It also involved developing estimates for the testing to be
performed, establishing necessary commitments, and defining and maintaining the plan to perform and manage the
testing. A test plan is required for each identified test level. At TMMi level 2 test plans are typically developed per
test level.
測試計劃過程域包括執行測試對象的產品風險評估，在已確定風險基礎上定義不同的測試方法。它也包括將要執行的測試的開發評估，建立必要的承諾，定義和

維護計劃以執行和管理測試。測試計劃需要每個明確的測試級別。在2級TMMi，測試計劃被制定在在每個測試級別上。
Specific Goal and Practice Summary
具體目標和實踐綜述
SG1 Perform a product risk assessment
SP 1.1 Define product risk categories and parameters
SP 1.2 Identify product risks
SP 1.3 Analyze product risks
SG1 執行產品風險評估
SP 1.1 定義產品風險類別和參數
SP 1.2 確定產品風險
SP 1.3 分析產品風險
SG2 Establish a test approach
SP 2.1 Identify items and features to be tested
SP 2.2 Define the test approach
SP 2.3 Define entry criteria
SP 2.4 Define exit criteria
SP 2.5 Define suspension and resumption criteria
SG2 建立測試方法
SP 2.1 確定要測試的項目和功能
SP 2.2 定義測試方法
SP 2.3 定義進入標準
SP 2.4 定義退出標準
SP 2.5 定義中止和恢復標準
SG3 Establish test estimates
SP 3.1 Establish a top-level work breakdown structure
SP 3.2 Define test lifecycle
SP 3.3 Determine estimates of test effort and cost
SG3 建立測試評估
SP 3.1 建立高層工作分解結構
SP 3.2 定義測試生命週期
SP 3.3 確定測試投入和費用的評估
SG4 Develop a test plan
SP 4.1 Establish the test schedule
SP 4.2 Plan for test staffing
SP 4.3 Plan stakeholder involvement
SP 4.4 Identify test project risks
SP 4.5 Establish the test plan
SG4 制定測試計劃
SP 4.1 建立測試時間表
SP 4.2 測試人員計劃
SP 4.3 計劃相關人員參與
SP 4.4 識別測試項目風險
SP 4.5 建立測試計劃
SG5 Obtain commitment to the test plan
SP 5.1 Review test plan
SP 5.2 Reconcile work and resource levels
SP 5.3 Obtain test plan commitments
SG5 獲得測試計劃承諾
SP 5.1 評審測試計劃
SP 5.2 調和工作和資源水平
SP 5.3 獲得測試計劃承諾

Specific Practices by Goals
目標的具體實踐
SG 1 Perform Product Risk Assessment
SG 1 執行產品風險評估
A product risk assessment is performed to identify the critical areas for testing.
產品風險評估被執行來明確測試的關鍵區域
SP 1.1 Define product risk categories and parameters
SP 1.1 定義產品風險類別和參數
Product risk categories and parameters are defined that will be used during the risk assessment.
在風險評估期間使用的產品風險類別和參數被定義。
Typical work products
典型工作產品
1. Product risk categories lists
2. Product risk evaluation and prioritization criteria
1. 產品風險類別清單
2. 產品風險評估和優先級標準
Sub-practices
子實踐
1. Determine product risk categories
A reason for identifying product risk categories is to help in the future consolidation of the test tasks
into test types in the test plans.
Examples of product risk categories include the following:
? Functional risks
? Architectural risks
? Non-functional risks, e.g. usability, efficiency, portability, maintainability, reliability
? Change related risks, e.g. regression
1. 決定產品風險類別
明確產品風險類別的原因是在未來測試任務變化時幫助進入測試計劃的測試類型。
產品風險類別實例包括如下：
 功能性風險
 結構性風險
 非功能性風險，如可用性，有效性，可移植性，可維護性，可靠性
 變更相關的風險，如回退
2. Define consistent criteria for evaluating and quantifying the product risk likelihood and impact
levels
3. Define thresholds for each product risk level
2. 爲評估和測量產品風險可能性和影響水平定義一致的標準
3. 定義每個產品風險級別的闕值
Risk level is defined as the importance of a risk as defined by its characteristics impact and likelihood.
For each risk level, thresholds can be established to determine the acceptability or unacceptability of
product risk, prioritization of product risks, or trigger of management action.
風險級別根據風險的重要性，其特有影響和可能性來定義。對於每個風險級別，閾值被建立以確定產品風險的可接受或不可接受，產品風險的優先級，或管理行

爲的引發。
SP 1.2 Identify product risks
SP 1.2 明確產品風險
Product risks are identified and documented.
產品風險被明確和記錄。
Typical work products
典型工作產品
1. Identified product risks
1. 明確產品風險
Sub-practices
子實踐
1. Identify and select stakeholders that need to contribute to the risk assessment
2. Identify product risks using input from stakeholders and requirements documents
1. 識別並選擇參與風險評估的相關人員
2. 利用相關人員和需求文檔的輸入明確產品風險
Examples of product risk identification techniques include the following:
? Risk workshops
? Brainstorming
? Expert interviews
? Checklists
? Lessons learned
產品風險識別技術實例包括如下：
 風險研討會 腦力激盪 專家訪談 檢查清單 吸取的經驗教訓
3. Document the background and potential consequences of the risk
4. Identify the relevant stakeholders associated for each risk
5. Review the identified product risks against the test assignment
3. 記錄背景和潛在風險後果4. 確定每個風險級別的相關人員5. 審查測試任務已明確的產品風險
SP 1.3 Analyze product risks
SP 1.3 分析產品風險
Product risks are evaluated, categorized and prioritized using predefined categories and parameters.
利用預定義的類別和參數對產品風險進行評估，分類以及確定優先級。
Typical work products
1. Product risk list, with a category and priority assigned to each risk
典型工作產品
1. 產品風險清單，並附有分配到每級風險的類別和優先級
Sub-practices
子實踐
1. Analyze the identified products risks using the predefined parameters, e.g. likelihood and impact
2. Categorize and group product risks according to the defined risk categories
3. Prioritize the product risks for mitigation
4. Establish a horizontal traceability between products risks and requirements to ensure that the
source of product risks is documented
5. Generate a requirements / product risks traceability matrix
6. Review and obtain agreement with stakeholders on the completeness, category and priority level
of the product risks
7. Revise the product risks as appropriate
Examples of when product risks may need to be revised include the following:
? New or changing requirements
? Change of the software development approach
? Lessons learned on quality issues in the project
1. 利用預定義的參數，如可能性和影響，分析已明確的產品風險
2. 通過已定義的風險類別，對產品風險分類，分組
3. 優先考慮產品風險緩解
4. 在產品風險和需求之間建立橫向的追溯，以確定產品風險的源頭被記錄
5. 生成一個需求/產品風險的可追溯模型
6. 評審並獲得相關人員在產品風險的完整性，類別和優先級方面的一致同意
7. 適當的時候修訂產品風險
何時需要修訂產品風險包括如下：
 新建或者改變需求
 軟件開發方法改變
 項目中質量問題的經驗教訓