測試策略3999790493

　 The development of a test strategy is a multi-step process of analysis : 1. Analyze requirements.

　2. Assess risk.

　3. Define scope of testing.

　4. Determine test approach.

　5. Determine entry and exit criteria. 一個(gè)測試戰(zhàn)略的設(shè)計(jì)是一個(gè)多步調(diào)的闡發(fā)歷程：

　1. 闡發(fā)需求。

　2. 評(píng)估風(fēng)險(xiǎn)。

　3. 界說測試范疇。

　4. 確定測試要領(lǐng)。

　5. 確定進(jìn)入和退出條件。

　Once the requirements and risks of a project are well-understood, the next step in test planning is to determine the test strategy. The test strategy answers the following questions: Why are we testing? What do we plan to do? What do we plan not to do?

　只要項(xiàng)目的需求和風(fēng)險(xiǎn)被準(zhǔn)確理解，測試籌劃的下一步就是確定測試戰(zhàn)略。測試戰(zhàn)略解決下列問題：為什么我們要測試？我們要做些什么？我們籌劃不做些什么？

　Your test strategy must include a clear definition of the scope of your testing. Your scope may be determined in part by your team"s responsibility. A large development project may have multiple test teams working on it, each of which is responsible for a different aspect of the project. Even a small project has different levels of test, as described in the module Test Levels and Activities. Your scope includes the levels of test that you cover.

　你的測試戰(zhàn)略必須包羅你對(duì)測試范疇的一個(gè)明確界說。你的范疇可能部分取決于你團(tuán)隊(duì)的責(zé)任。在大型生長項(xiàng)目里，可能有多個(gè)測試團(tuán)隊(duì)同時(shí)事情，每一個(gè)

　 小組賣力項(xiàng)目的差別方面。像在測試階段和運(yùn)動(dòng)中描述的一樣，縱然是很小的項(xiàng)目，也有差別水平的測試。你的范疇包羅你賣力的范疇內(nèi)的測試階段。

　The scope of your testing is also affected by the scope and nature of the project itself. For example, the scope of testing may be smaller for a small service release to an existing product than for a new product.

　你的測試范疇也會(huì)因?yàn)轫?xiàng)目自己的范疇和性質(zhì)而受到影響。例如，對(duì)付一個(gè)新產(chǎn)物來說，一個(gè)準(zhǔn)許生產(chǎn)的產(chǎn)物中的一個(gè)小辦事的測試范疇更小。

　To determine the test approach, ask questions like these for each of the project features and attributes: ? What testing is planned for this feature or attribute?

　? What customer problem does this feature solve?

　? What announcement claims will we be making about this feature?

　? What automation will we used to develop the tests for this feature?

　要確定測試要領(lǐng)，為檢測項(xiàng)目的成果和屬性，必須提出下列問題，：

　1、為測試成果或?qū)傩�，要進(jìn)行怎么樣的測試？ 2 此成果解決客戶的哪些問題？

　3 針對(duì)這個(gè)特點(diǎn)，我們要做出怎樣的陳訴？

　4 我們將用什么自動(dòng)化東西或技能來進(jìn)行這項(xiàng)成果的測試？ To determine when to start and end testing, identify entry and exit criteria by answering the following questions:

　為了決定何時(shí)開始和結(jié)束測試，憑據(jù)下列問題的答案，確定進(jìn)入和退出條件：

　? During the development process, can the tests we"ve defined be executed in an effective and

　 efficient manner?

　? As the product continues to progress, when are we are finished?

　1 在開發(fā)歷程中，我們界說的測試能否以有效和高效的方法執(zhí)行？

　2 隨著產(chǎn)物的不絕生長，我們什么時(shí)候能夠完成？ In order for entry and exit criteria to be effective, they must have three common attributes. ? Entry and exit criteria must be meaningful.

　? Entry and exit criteria must be measurable.

　? Entry and exit criteria must be achievable.

　為了進(jìn)入和退出條件能夠生效，就必須有 3 個(gè)配合屬性。

　進(jìn)入和退出標(biāo)準(zhǔn)，必須是有意義的。

　進(jìn)入和退出標(biāo)準(zhǔn)，必須是可權(quán)衡的。

　進(jìn)入和退出標(biāo)準(zhǔn)，必須是可實(shí)現(xiàn)的。

　課程目標(biāo) After completing this lesson, you will be able to:

　Define the scope of testing

　Determine your test approach

　Determine when to start testing and when the testing is complete

　學(xué)完這一課后，你將能夠：

　界說測試范疇 確定你的測試要領(lǐng) 確定何時(shí)開始測試以及何時(shí)完成測試

　Throughout this course, you will have an opportunity to gain hands-on practice with various software test activities. We will use the following fictional scenario to provide context for our examples and exercises.

　 在整個(gè)歷程中，你將有時(shí)機(jī)得到種種軟件測試運(yùn)動(dòng)的實(shí)際操縱。我們將使用下面的虛構(gòu)場景，為我們的例子和練習(xí)提供場景。

　Project background The Arizona Weather Watcher group is a volunteer organization of professional and amateur weather watchers across Arizona. They hold biannual meetings to share ideas and observations.

　 項(xiàng)目配景

　亞利桑那州的氣候視察組是由亞利桑那州的專業(yè)和業(yè)余的氣候視察家志愿者組成的。他們一年舉行兩次聚會(huì)會(huì)議，來交換想法和意見。

　The Arizona Weather Data Project At the last meeting, it was determined that the group would attempt a long-standing goal. Since the group"s inception, there has been a strong desire to amass a continuously updated database of weather data for all of Arizona. The Weather Watchers have decided that, with the Internet providing easy access, the time is right to attempt this project.

　亞利桑那州的氣象資料項(xiàng)目

　上一次聚會(huì)會(huì)議確定了該小組將實(shí)驗(yàn)一個(gè)長期目標(biāo)。從小組創(chuàng)建以來，積聚所有亞利桑那州的天氣數(shù)據(jù)成為一個(gè)不絕更新的數(shù)據(jù)庫的強(qiáng)烈愿望及一直存在。天氣視察家決定，既然互聯(lián)網(wǎng)提供了方便，那么是時(shí)候?qū)嶒?yàn)這個(gè)項(xiàng)目了。

　The web tool they want to create will enable group members across Arizona to submit their local weather observations to a central database. This project is called the Arizona Weather Data Project. Many of the examples and exercises in this course refer to this background material. 他們想創(chuàng)建的網(wǎng)絡(luò)東西，可以使整個(gè)亞利桑那州小組的成員能夠提交本地天氣視察的數(shù)據(jù)到一其中央數(shù)據(jù)庫。這個(gè)項(xiàng)目就被稱為亞利桑那州氣象數(shù)據(jù)項(xiàng)目。

　許多這個(gè)課程中的例子和練習(xí)是指此配景。

　Throughout this module, you will be documenting your Test Plan for the Arizona Weather Data Project using the Rational Unified Process (IRUP) Master Test Plan Microsoft Word template available on the download page.

　在這個(gè)模塊的整個(gè)歷程中，你將利用在下載頁面下現(xiàn)成的 Rational 統(tǒng)一歷程（IRUP）Master Test Plan Microsoft Word 模板，記錄亞利桑那州氣象數(shù)據(jù)項(xiàng)目的測試籌劃。

　The Arizona Weather Data Project (AWDP) consists of a web-based tool that allows volunteers across Arizona to submit local weather observations. 亞利桑那州的天氣數(shù)據(jù)項(xiàng)目（AWDP）里有一個(gè)基于網(wǎng)絡(luò)的東西，使得漫衍在亞利桑那州的志愿者可以提交本地的氣象視察資料 。

　As you learned in Principles of Test Management, you can subdivide a test plan to better manage varying levels of detail and change. Since the Arizona Weather Data Project team is relatively small, you need to create only one test plan.

　正如你在測試治理原則中學(xué)到的，你可以細(xì)分測試籌劃，來更好地處理懲罰細(xì)節(jié)和水平的條理多樣性。由于亞利桑那州氣象數(shù)據(jù)項(xiàng)目團(tuán)隊(duì)比力小，你只需要?jiǎng)?chuàng)建一個(gè)測試籌劃。

　Sections of this module refer you to the section numbers and section titles from the IRUP Master Test Plan template. 這個(gè)模塊的部分，指的是 IRUP 主測試籌劃模板里的章節(jié)數(shù)和標(biāo)題 。

　 Developing a Test Strategy 制定 一個(gè)測試戰(zhàn)略 Once the requirements and risks of a project are well understood, the next step in test planning is to detemine the test strategy. The test strategy answers the following questions at a level that is useful to project managers, management, and members of your test teams:

　當(dāng)需求和項(xiàng)目的風(fēng)險(xiǎn)被充實(shí)理解后， 測試籌劃的下一步是確定測試戰(zhàn)略。在對(duì)付項(xiàng)目經(jīng)理，治理人員和你的團(tuán)隊(duì)人員是有用的水準(zhǔn)上，測試戰(zhàn)略答復(fù)了一下問題：

　Why are we testing?

　What do we plan to do and what do we plan not to do?

　How will we do our testing?

　The development of a test strategy is a multi-step process of analysis: 我們?yōu)槭裁礈y試？

　我們籌劃做什么以及不做什么？

　我們將如何做測試？

　一個(gè)測試戰(zhàn)略的形成是一個(gè)多步調(diào)的闡發(fā)歷程：

　Developing a Test Strategy, continued 制定一個(gè)測試戰(zhàn)略，續(xù)

　You already learned how to perform Step 1: Analyze Requirements. You learned how to evaluate functional requirements and nonfunctional requirements and how to develop use cases and use-case models. You learned how to refine bad requirements. You also learned how to perform Step 2: Assess Risk.

　你已經(jīng)學(xué)會(huì)了如何執(zhí)行第 1 步：需求闡發(fā)。你學(xué)過了如何評(píng)估成果需求和非成果需求，以及如何制定用例及用例模型。你也學(xué)過了如何改造不健全的需求。還學(xué)習(xí)了如何執(zhí)行第 2 步：評(píng)估風(fēng)險(xiǎn)。

　In this lesson, you will learn how to do steps 3 through 5 of developing a test strategy as follows:

　在這一課，你將學(xué)習(xí)創(chuàng)建一個(gè)測試戰(zhàn)略的第三個(gè)步調(diào)到第五個(gè)步調(diào)，如下所示：

　Step 3: Define the scope of testing

　Step 4: Determine your test approach

　Step 5: Determine when to start testing and when the testing is complete

　In test strategy development, the first (and in some projects the most important) step is to clarify the testing scope for the project.

　第 3 步：界說測試范疇 第 4 步：確定你的測試要領(lǐng) 第 5 步：確定何時(shí)開始測試和結(jié)束測試。

　 在創(chuàng)建測試戰(zhàn)略時(shí)，第一個(gè)（在一些項(xiàng)目中最重要的）步調(diào)是闡發(fā)項(xiàng)目的測試范疇。

　 Defining the Scope of Testing 界說測試范疇

　 You must clearly define the scope of your testing. Your scope may be determined in part by your team"s responsibility. A large development project may have multiple test teams working on it, each of which is responsible for a different aspect of the project. Even a small project has different levels of test, as described in the module Test Levels and Activities. Your scope includes the levels of test that you cover.

　你必須明確界說你的測試范疇。您的范疇可能部分取決于你的團(tuán)隊(duì)的責(zé)任。你的范疇可能部分取決于你團(tuán)隊(duì)的責(zé)任。在大型生長項(xiàng)目里，可能有多個(gè)測試團(tuán)隊(duì)同時(shí)事情，每一個(gè)小組賣力項(xiàng)目的差別方面。像在測試階段和運(yùn)動(dòng)中描述的一

　 樣，縱然是很小的項(xiàng)目，也有差別水平的測試。你的范疇包羅你賣力的范疇內(nèi)的測試階段。

　The scope of your testing is also affected by the nature of the project itself. For example, the scope of testing may be smaller for a small service release to an existing product than for a new product. Make testing scope decisions consciously. Decide which features or functions to test, which products or product combinations to test and which not to test. Be sure to use well-informed risk assessments to understand the risk relative to what you are not testing.

　 您的測試的范疇也受到項(xiàng)目自己性質(zhì)的影響。例如，對(duì)付一個(gè)新產(chǎn)物來說，一個(gè)已存在產(chǎn)物的一個(gè)小辦事的測試范疇可能會(huì)更小。清晰地決定測試范疇。決定測試哪些成果或特征， 哪些產(chǎn)物或產(chǎn)物組合進(jìn)行測試了，而哪些沒有進(jìn)行測試。對(duì)付與你沒有測試的部分相關(guān)的那些風(fēng)險(xiǎn)，一定要信息全面的了解和評(píng)估它們。

　7．Communicating Testing Scope Decision Communicate scoping decisions to the rest of the project team for their understanding, discussion, and agreement. While it may be easier to proceed quickly in cases in which you have immediate agreement, discussions often have the important side-effect of identifying unspoken assumptions that the project team may hold regarding testing. These discussions can also be helpful in identifying the role that project team members expect testing to play throughout the project lifecycle. Examples of questions to discuss include the following: 為了他們的理解，討論和贊成，要向項(xiàng)目組成員轉(zhuǎn)達(dá)與范疇有關(guān)的決定。在你們迅速告竣一致的情況下，可以比力容易的進(jìn)行，討論對(duì)付判定項(xiàng)目組關(guān)于測試可能持有的未說出的假設(shè)往往有重要的側(cè)面影響。這些討論也有助于確定項(xiàng)目小組成員在整個(gè)項(xiàng)目生命周期中期望包袱的腳色。討論的問題例子包羅以下內(nèi)容：

　? Will developers be expected to prove they have done a certain amount of unit testing before they can submit code?

　 ? Is the project manager expecting to supplement the test team with contractors or developers during times of schedule pressures?

　開發(fā)人員被期望能夠證明他們已經(jīng)做了一定量的單位測試，才可以提交代碼嗎？

　當(dāng)項(xiàng)目時(shí)間壓縮時(shí)，項(xiàng)目經(jīng)理希望給測試團(tuán)隊(duì)增補(bǔ)合約人大概開發(fā)人員嗎？ The process of communicating testing scope decisions sets appropriate expectations, in advance, for what testing and the test team can and cannot do for the project. These issues are best discussed in advance, rather than at the time of a crisis or conflict.

　 在通信測試范疇決定的歷程里設(shè)置適當(dāng)?shù)念A(yù)期，更進(jìn)一步，預(yù)期測試和測試團(tuán)隊(duì)對(duì)付這個(gè)項(xiàng)目，什么可以做什么不能夠做。這些問題最功德先討論，而不是直到危機(jī)或辯論的產(chǎn)生了才去討論。

　8. Identifying Scope: Test Levels and Focus Areas 確定范疇：測試階段和 重點(diǎn) 區(qū)域 You can categorize testing activities into levels, with each level focused on an aspect of the application or code. Each level is responsible for a set of focus areas; you need to analyze and assess these focus areas as part of determining the testing strategy. 您可以憑據(jù)每個(gè)階段對(duì)付應(yīng)用和代碼的偏重方面把測試運(yùn)動(dòng)分類成階段。每一階段賣力一系列重點(diǎn)領(lǐng)域，你需要把闡發(fā)和評(píng)估這些重點(diǎn)領(lǐng)域作為確定測試戰(zhàn)略的一部分。

　9 9

　Functional Verification Test Focus Areas 成果驗(yàn)證測試重點(diǎn)領(lǐng)域

　 The set of focus areas for Functional Verification Testing (FVT) are: 成果驗(yàn)證測試（ FVT ）的重點(diǎn)領(lǐng)域設(shè)置：

　10

　System Verification Test Focus Areas 系統(tǒng)驗(yàn)證測試重點(diǎn)領(lǐng)域

　The set of focus areas for System Verification Test (SVT) are: 系統(tǒng)驗(yàn)證測試（SVT）的重點(diǎn)領(lǐng)域設(shè)置：

　You"ll notice that some of the same focus areas appear for both FVT and SVT. The emphasis, however, is different in each case. Let"s look at the Regression focus area. The FVT team regression tests individual functions, such as login. The SVT team regression tests the system as a whole. For example, the SVT team might rerun load and stress tests.

　你會(huì)發(fā)明，同樣的一些重點(diǎn)領(lǐng)域會(huì)在 FVT 和 SVT 里同時(shí)出現(xiàn)。，但是重點(diǎn)是，在每種情況下是差別的。讓我們來看看回歸重點(diǎn)領(lǐng)域。FVT 事情組對(duì)個(gè)別成果進(jìn)行回歸測試，例如登錄成果。

　SVT 團(tuán)隊(duì)的回歸測試是測試整個(gè)系統(tǒng)。例如，SVT 的團(tuán)隊(duì)可能再次執(zhí)行的負(fù)載和壓力測試。

　11 ．

　Test Inclusions

　測試 包羅的 運(yùn)動(dòng)

　 Once you have determined the scope of your testing, you are ready to document the scope. Open the IIRUP Master Test Plan template you downloaded earlier in this module and review sections 1.2 and 4.

　Section 1.2: Scope Use this section to define the levels of test that you will perform, as well as the levels of test you will not perform. Be sure to review section 4 prior to completing section 1.2 to avoid duplicating information or presenting it in the wrong location.

　 Section 4: Overview of Planned Tests Use this section to document the features and attributes that you plan on testing. (We will document features that you do not plan on testing later in this lesson.)

　一旦你決定了你的測試范疇，您就可以記錄你的范疇。打開在本模塊中你早些時(shí)候已下載的 IIRUP 主測試籌劃模板，回顧第 1.2 和第 4 部分。

　 第 1.2 節(jié)：范疇

　利用本部分界說你將要執(zhí)行的測試階段，以及不執(zhí)行測試的階段。一定要事先溫習(xí)第 4 部分完成第 1.2 節(jié)，以制止重復(fù)信息或出現(xiàn)在錯(cuò)誤的位置。

　 第 4 部分：回顧測試籌劃 使用此部分記錄你籌劃測試的的成果和屬性。（在這一課的背面，我們將記錄你禁絕備測試的成果。）

　Section 4.1: Outline of Test Inclusions A good way to document test inclusions is to use the results of the risk analysis produced earlier in the planning process.

　For the AWDP Test Plan, you can use the table that you created in the Test Planning and Risk Analysis module almost directly. Add one column titled "Additional Information" to capture the logic behind the analysis. Use the new space to explain why a certain feature or attribute was given a particular impact level and likelihood so that a reviewer understands and can evaluate the assessment.

　Click on Test Inclusions for an example. 1 4.1 節(jié)：測試包羅運(yùn)動(dòng)的大綱 一個(gè)記錄測試運(yùn)動(dòng)的好步伐是利用之前在籌劃歷程中產(chǎn)生的風(fēng)險(xiǎn)闡發(fā)的結(jié)果。

　 對(duì)付 AWDP 測試籌劃，你險(xiǎn)些可以直接使用你在測試籌劃和風(fēng)險(xiǎn)闡發(fā)模塊中創(chuàng)建的表格。添加一名為“增補(bǔ)信息”的列，捕獲闡發(fā)背后的邏輯。使用這塊新

　 空間，來解釋為什么某些特征或?qū)傩员毁n與了特別的影響水平和可能性，以便審閱者能夠理解和評(píng)價(jià)評(píng)估。

　 點(diǎn)擊測試運(yùn)動(dòng)，舉一個(gè)例子。

　12．

　Test Exclusions 測試排除

　Section 4.2: Outline of Other Candidates for Potential Inclusion

　There may be some features or attributes that you suspect need to be tested but will require more investigation or insight. List those in this section using the same format as test inclusions, but use "Additional Information" as a place to document the reasons why this feature or attribute is considered under potential inclusion.

　第 第 4.2 節(jié)：其他候選的 潛在運(yùn)動(dòng)的 大綱

　可能有一些成果或?qū)傩�，你覺得可能需要進(jìn)行測試，但將需要更多的視察和了解。在本部分中使用與測試包羅運(yùn)動(dòng)相同的格式列出它們，但要使用“增補(bǔ)信息”一列記錄為什么此成果或?qū)傩员涣腥霛撛谶\(yùn)動(dòng)的原因。

　 Section 4.3: Outline of Test Exclusions These are features or attributes that you have determined have a low enough priority to accept the risk of not developing and executing tests. Use the "Additional Information" column for the justification to exclude this testing. For example, in the Arizona Weather Data Project application, there is a "Save Draft" option on the data submission form. A possible justification for not testing the "Save Draft" option is the fact that the form does not take very long to complete, and most users would finish entering their observations without the need to save their work along the way.

　Click on Test Exclusions for an example.

　 3 4.3 節(jié)：

　測試 排除大綱

　有些成果或?qū)傩�，你已�?jīng)確定它們具有足夠低的優(yōu)先度，可以不生長和執(zhí)行測試。使用“增補(bǔ)信息”的列解釋為什么不需要進(jìn)行測試。例如，在亞利桑那州氣象數(shù)據(jù)項(xiàng)目應(yīng)用中，有一 個(gè)“生存草稿”的資料提交表單選項(xiàng)。不對(duì) “生存草稿”進(jìn)行測試的公道理由是，該表不需要很長時(shí)間才華完成，并且大多數(shù)用戶無需一直生存他們的事情就可以完成視察數(shù)據(jù)的輸入。

　 點(diǎn)擊試驗(yàn)排除的一個(gè)例子。

　13

　Determining the Test Approach

　確定測試要領(lǐng)

　The next step in the process of defining your strategy is to determine your test approach. 確定戰(zhàn)略進(jìn)程的下一步是要確定你的測試要領(lǐng)

　14

　Determining the Test Approach, continued

　確定測試要領(lǐng)，繼承

　For effective testing, the challenge is to take the prioritized list of features and attributes that were developed based on risk mitigation and assess them against the list of test focus areas, making sure to cover all of the areas.

　為了有效的測試，面臨的挑戰(zhàn)是采取成果和屬性的優(yōu)先級(jí)列表，優(yōu)先級(jí)列表是基于風(fēng)險(xiǎn)緩解和對(duì)重點(diǎn)領(lǐng)域的測試評(píng)估，并且要確保涵蓋所有領(lǐng)域。

　Recall that the focus areas for Functional Verification Test are:

　? Mainline functions

　 ? Error conditions

　? Recovery

　? Basic usability

　? Accessibility

　? Global enablement

　? Vulnerability

　? Regression

　追念一下，在成果驗(yàn)證測試的重點(diǎn)領(lǐng)域是：

　 主線成果 錯(cuò)誤條件 規(guī)復(fù) 根本可用性 可用性 全球可用 漏洞 回歸 The focus areas for System Verification Test are:

　? Load and stress

　? Regression

　? Recovery

　? Migration

　? Usability

　? Serviceability

　? Functional completeness

　 ? Hardware and software interaction

　系統(tǒng)驗(yàn)證測試的重點(diǎn)領(lǐng)域是：

　 負(fù)載和壓力 回歸 規(guī)復(fù) 遷移 可用性 使用能力

　成果完整性 硬件和軟件的相互作用

　整理到這里

　Taking this approach allows you to concentrate the testing effort to deliver the most benefit. For each of the features and attributes, ask these questions to determine the test approach: ? What testing is planned for this feature or attribute? When answering this question make sure to ask it for each of the focus areas in your test level. For example, does this feature need to be tested for global enablement? Does this feature need to be stress tested? Is this a feature that is likely to be vulnerable to hackers?

　? What customer problem does this feature solve? This will help you decide where to focus the testing for this feature.

　? What announcement claims will you be making about this feature? This question will help ensure that you are verifying what marketing is saying.

　? Will this feature be verified by the execution of the regression tests only? If so, why?

　 ? What automation will be used to develop the tests for this feature? Remember that time and resource will have to be factored into the plan for designing/developing the automation and potentially learning new tools.

　You may want to add questions to this list that are specific to your environment. The important thing is to have a list so that you do not miss important considerations.

　采取這種要領(lǐng)可以讓您專注的測試事情，以提供最大的利益。對(duì)付成果和屬性，每年提出這些問題，以確定測試要領(lǐng)：

　 是什么樣的測試籌劃在此成果或?qū)傩裕看饛?fù)這個(gè)問題時(shí)，請(qǐng)務(wù)必請(qǐng)?jiān)谀�的測試級(jí)別的重點(diǎn)領(lǐng)域來進(jìn)行。例如，此成果需要為全球啟用測試？此成果需要的壓力測試？這是一個(gè)成果，很可能會(huì)受到黑客的打擊？

　客戶的哪些問題此成果解決？這將有助于您決定在那邊會(huì)合對(duì)這一成果的測試。

　通告要求什么，你又對(duì)這項(xiàng)成果？這個(gè)問題將有助于確保您正在核實(shí)營銷是說什么。

　此成果將被核實(shí)的回歸測試執(zhí)行罷了？如果是這樣，為什么？

　什么自動(dòng)化將用于開發(fā)此成果的測試？請(qǐng)記取，時(shí)間和資源將被納入籌劃之內(nèi)設(shè)計(jì)/開發(fā)的自動(dòng)化和潛在的學(xué)習(xí)新的東西。

　您可能需要添加到這個(gè)列表的問題是特定于您的情況。重要的是有一個(gè)列表，以便您不會(huì)錯(cuò)過重要的考慮因素。

　15 Different Test Levels, Different Test Strategies 差別的測試級(jí)別，差別的測試戰(zhàn)略

　The scope for your Arizona Weather Data Project (AWDP) Test Plan includes two different levels of test: Functional Verification Test (FVT) and System Verification Test (SVT). Different levels of test can require different test strategies.

　 Let"s look at an example for each of these levels: FVT and SVT. We will use features and attributes from the prioritized list that we developed in the Test Planning and Risk Analysis module. 您的亞利桑那州氣象數(shù)據(jù)項(xiàng)目（AWDP）測試籌劃的范疇包羅兩個(gè)差別條理的測試：成果驗(yàn)證測試（FVT）和系統(tǒng)驗(yàn)證測試（SVT）的。差別級(jí)別的測試可能需要差別的測試戰(zhàn)略。

　 讓我們來看看為各層級(jí)的例子：FVT 和 SVT。我們將使用優(yōu)先列表，我們?cè)跍y試籌劃和風(fēng)險(xiǎn)闡發(fā)模塊開發(fā)的成果和屬性。

　16 Example: Test Approach for the AWDP Login Feature 例如：測試的 AWDP 登錄成果的要領(lǐng) One of the high-priority line items for the AWDP is the "login" feature. The basic functionality of the login feature will be tested as part of FVT. You can use an outline like the one below to gather the information you need to document your test approach in your Master Test Plan. In this example, the answers to the questions What testing is planned for this feature or attribute? and What automation will be used to develop the tests for this feature? are captured under the heading Approach to Testing. The answer to the question What customer problem does this feature solve? under the heading Overview or Brief Description.

　Recall that your test approach should address situations that are specific to your environment. In this example, the fact that the authentication function is using services provided by another group is called out under the heading Assumptions/Issues Specific to this Feature.

　高優(yōu)先事項(xiàng) AWDP 行項(xiàng)目之一是“登錄”成果。在登錄成果的根本成果將受到考驗(yàn)，作為 FVT 的一部分。您可以使用類似下面這一收集需要的信息記錄你對(duì)你總

　 的測試要領(lǐng)測試籌劃綱領(lǐng)。

　 在這個(gè)例子中，對(duì)什么進(jìn)行測試，此成果或?qū)傩缘幕I劃問題的答案？和什么自動(dòng)化將用于開發(fā)此成果的測試？被捕獲的標(biāo)題下的測試要領(lǐng)。對(duì)這一問題的客戶的哪些問題不解決這一成果的答案？的標(biāo)題下概述或扼要說明。

　 追念一下，您的測試步伐應(yīng)處理懲罰的特殊情況對(duì)您的情況。在這個(gè)例子中，一個(gè)事實(shí)，即驗(yàn)證成果是由另一組使用所提供的辦事被稱為假設(shè)項(xiàng)下出/這一問題的具體特征。

　Feature Name: Login

　Lead Developer: Sue Lead Function Tester: Javier Lead System Tester: Thelma Overview or Brief Description: A user is required to log in using their registered userid (email address) and password. Approach to Testing: Develop a set of automated tests to test the ability to log in valid users that are registered. Drive error paths by logging in with invalid userids and passwords. Assumptions/Issues Specific to this Feature: Authentication using the userid and password is provided by an external service that will be called. It is assumed that this function already has been thoroughly tested and supported. We will not do vulnerability testing on entering userids and passwords.

　成果名稱：登錄

　 鉛開發(fā)商：蘇

　鉛成果測試儀：哈維爾

　鉛系統(tǒng)測試儀：塞爾瑪

　概述或扼要說明：用戶需要登錄使用其注冊(cè)用戶名（電子郵件地點(diǎn)）和密碼。

　 測試要領(lǐng)：制定了一套自動(dòng)化測試，測試的能力，有效用戶登錄注冊(cè)的。在使用無效的用戶id 和密碼記錄器的錯(cuò)誤路徑。

　 假設(shè)/這個(gè)問題的具體特征：身份驗(yàn)證使用用戶 ID 和密碼是由外部提供辦事，將被調(diào)用。據(jù)推測，這一職能已經(jīng)過徹底測試和支持。我們不會(huì)在進(jìn)入用戶 id 和密碼的漏洞測試。

　17 Exercise 1: Test Approach for Concurrent Users Feature 練習(xí) 1：測試要領(lǐng)為特征并發(fā)用戶 Another of the requirements for the AWDP system is that 1500 users can access the tool concurrently. This attribute will be tested as part of SVT. 在對(duì) AWDP 系統(tǒng)的要求另一個(gè)原因是，1500 用戶可以訪問該東西同時(shí)進(jìn)行。此屬性將被測試作為 SVT 的一部分。

　19

　Documenting the Test Approach 記錄的測試要領(lǐng) Section 5 of the IIRUP Master Test Plan provides you with a template for documenting your test approach. Section 5 includes these headings:

　 5.1 Measuring the Extent of Testing 5.2 Identifying and Justifying Tests 5.3 Conducting Tests

　The IIRUP template is just that, a template. Teams modify the template to suit their needs. For a small project, you may choose to document your test approach by line item or feature as shown in the screen capture.

　As you can imagine, this level of detail would quickly become cumbersome for a large project. A better approach for a large project is to manage this detail in a spreadsheet. In this case, the test plan includes a high level overview of the test approach with a reference to the more detailed spreadsheet. Creating feature or iteration test plans in addition to the Master Test Plan can also be very useful for a larger project.

　科 IIRUP 主測試籌劃 5 提供了一個(gè)模板，用于記錄您的測試要領(lǐng)。第 5 節(jié)包羅以下標(biāo)題：

　 5.1 測水平測試

　5.2 中說明和測試

　5.3 進(jìn)行測試

　該 IIRUP 模板的只是，一個(gè)模板。團(tuán)隊(duì)修改模板以適應(yīng)他們的需要。對(duì)付一個(gè)小項(xiàng)目，你可以選擇你的文件按項(xiàng)目測試要領(lǐng)或成果如屏幕捕獲所示。

　 你可以想象，這種詳細(xì)水平將迅速成為累贅一項(xiàng)龐大的工程。一個(gè)大型項(xiàng)目的更好的要領(lǐng)是，以治理電子表格這一細(xì)節(jié)。在這種情況下，測試籌劃包羅一個(gè)以電

　 子表格的更詳細(xì)的參考測試要領(lǐng)高條理的概述。創(chuàng)建成果或除主測試籌劃的迭代測試籌劃也可以是非常有用的一個(gè)較大項(xiàng)目。

　20 Determining Entry and Exit Criteria for Testing 確定進(jìn)出境查驗(yàn)標(biāo)準(zhǔn) As part of the test strategy, you determine when to start testing by identifying Entry Criteria and when the testing is complete by identifying Exit Criteria. 作為測試戰(zhàn)略的一部分，您決定何時(shí)首先確定入學(xué)標(biāo)準(zhǔn)和測試時(shí)，通過識(shí)別出口標(biāo)準(zhǔn)的完整測試。

　21 What do Entry and Exit Criteria do for You?

　Entry Criteria and Exit Criteria answer the following questions:

　? As a product moves through the development process, can the tests that we have defined for each level or iteration be executed in an effective and efficient manner?

　? How will we know when are we finished testing a particular level or iteration?

　In order for entry and exit criteria to be effective, they must have three common attributes:

　? Entry and exit criteria must be meaningful.

　o Each criterion should exist for a specific reason.

　o A cause and effect should be shown or implied.

　o They should aid in risk assessment.

　 ? Entry and exit criteria must be measurable.

　o If it cannot be measured, it is not useful.

　o It should never be subjective.

　o The status is calculated using empirical data.

　 ? Entry and exit criteria must be achievable.

　o The criteria must be realistic, not unobtainable.

　Never carry forward a criteria that has never been met; it dilutes the effectiveness of the other criteria. 入學(xué)標(biāo)準(zhǔn)和退出條件答復(fù)下列問題：

　 通過生長進(jìn)程中的產(chǎn)物移動(dòng)，我們可以為每個(gè)級(jí)別或迭代界說的測試執(zhí)行有效和高效的方法？

　 我們?nèi)绾沃�道我們完成測試某個(gè)特定水平或迭代？

　在進(jìn)入和退出條件才華有效，就必須有 3 個(gè)配合的屬性：

　 進(jìn)入和退出標(biāo)準(zhǔn)，必須是有意義的。

　每個(gè)標(biāo)準(zhǔn)應(yīng)該存在的具體原因。

　因果應(yīng)表明或體現(xiàn)。

　他們應(yīng)該資助風(fēng)險(xiǎn)評(píng)估。

　進(jìn)入和退出標(biāo)準(zhǔn)，必須是可權(quán)衡的。

　如果它不能權(quán)衡，它是沒有用的。

　它不應(yīng)該是主觀的。

　狀態(tài)為盤算經(jīng)驗(yàn)數(shù)據(jù)。

　 進(jìn)入和退出標(biāo)準(zhǔn)，必須是可以實(shí)現(xiàn)的。

　該標(biāo)準(zhǔn)必須是現(xiàn)實(shí)的，不是不能實(shí)現(xiàn)的。

　從來沒有發(fā)揚(yáng)一個(gè)從未到達(dá)的標(biāo)準(zhǔn)，它淡化了其他標(biāo)準(zhǔn)的效力。

　22 Determining Entry Criteria 確定入學(xué)標(biāo)準(zhǔn) When determining entry criteria, document what is required by a team to begin testing and proceed efficiently and effectively with a manageable amount of risk. The criteria should be discrete and easily measured. They should also be used to determine an acceptable amount of risk. For example, ask the question: If these criteria are not met, what could happen and what would the result be? Assign a risk assessment value to each criterion. Refine this value over time and is use it to identify productive recovery actions. When determining risk, it is important to total the individual risk assessment values to get a complete understanding of the entire situation. The risk determination is important because if an entry criterion is not met, it does not mean that the test organization stops working. 在確定入學(xué)標(biāo)準(zhǔn)，文件什么是需要一個(gè)團(tuán)隊(duì)開始測試和進(jìn)行有效的風(fēng)險(xiǎn)管控的有效。該標(biāo)準(zhǔn)應(yīng)是離散的和容易權(quán)衡。他們應(yīng)該也可以用來確定一個(gè)可擔(dān)當(dāng)?shù)娘L(fēng)險(xiǎn)金額。舉例來說，提出這個(gè)問題：

　 如果這些條件得不到滿足，會(huì)產(chǎn)生什么和什么結(jié)果呢？

　 指定一個(gè)風(fēng)險(xiǎn)評(píng)估值為每個(gè)標(biāo)準(zhǔn)。隨著時(shí)間改造此值，并用它來確定生產(chǎn)規(guī)復(fù)操縱。在確定風(fēng)險(xiǎn)，重要的是總的小我私家風(fēng)險(xiǎn)評(píng)估的代價(jià)得到了整個(gè)局勢的全面了解。風(fēng)險(xiǎn)的決心非常重要，因?yàn)槿绻�一個(gè)項(xiàng)目不切合標(biāo)準(zhǔn)的，但這并不意味著測試機(jī)構(gòu)停止事情。

　 Entry criteria being met is really a checkpoint that shows the overall status of a product. Higher levels of risk indicate that the testing may not be optimally effective, which increases the risk that targeted problems will escape to the field. For example, if some of the planned functionality is not delivered on schedule, the risk is increased as the amount of time available to test that functionality is reduced. The risk is increased further if testing of other planned functionality is dependent on the piece that is delayed. Once the team understands the objectives, you can ask the following question to start establishing good entry criteria: For entry criteria, what has to have happened so that we can begin, be effective and efficient, and proceed with a manageable amount of risk? 入 學(xué)條件得到滿足實(shí)在是一個(gè)查抄點(diǎn)，顯示了產(chǎn)物的整體狀態(tài)。風(fēng)險(xiǎn)水平較高的測試表明，就不能很好的效益，從而增加有針對(duì)性的風(fēng)險(xiǎn)問題，將逃往外地。例如，如 果籌劃中的某些成果不能如期交付的風(fēng)險(xiǎn)有所增加的時(shí)間來測試該成果數(shù)額淘汰。風(fēng)險(xiǎn)是進(jìn)一步增加，如果籌劃中的其他成果測試是在這片延遲依賴。

　 一旦球隊(duì)了解的目標(biāo)，可以提出以下的問題開始創(chuàng)建良好的入學(xué)標(biāo)準(zhǔn)：

　 入境標(biāo)準(zhǔn)，有什么事情，以便我們能夠開始，是有效的和有效率，并進(jìn)行風(fēng)險(xiǎn)治理的數(shù)額？

　23 Evaluating Ideas for Entry Criteria 評(píng)價(jià)理念的入學(xué)標(biāo)準(zhǔn) As the team brainstorms, list ideas for potential entry criteria. Assess each idea and make sure that it is meaningful, measurable, and achievable.

　 Example 1: A member of the team suggests that, as an entry criterion, "A specific set of variations defined in an earlier test level must run successfully."

　Make sure that you can defend why these variations must run and quantify the risk of continuing should any of them fail. Avoid ambiguous criteria such as "Function Test must be 80% complete." This criterion is ambiguous because it does not specify which 80% must be complete. Also, if there are a lot of tests, the failing 20% could impact your ability to make progress. It is better to specify which variations must execute successfully.

　隨著球隊(duì)的奇思妙想，為潛在的入學(xué)標(biāo)準(zhǔn)清單的想法。評(píng)估每個(gè)想法，并確保它是有意義的，可丈量的和可以實(shí)現(xiàn)的。

　 示例 1：對(duì)小組成員發(fā)起，作為項(xiàng)目的標(biāo)準(zhǔn)，“一個(gè)在早些時(shí)候測試級(jí)別的界說必須樂成運(yùn)行一套具體的變革。”

　請(qǐng) 確保您可以掩護(hù)這些變革的原因必須運(yùn)行和量化應(yīng)繼承他們?nèi)魏问�敗的風(fēng)險(xiǎn)。制止出現(xiàn)諸如“成果測試，必須完成 80％暗昧的標(biāo)準(zhǔn)。”這一標(biāo)準(zhǔn)是模糊的，因?yàn)樗?沒有具體說明，其中 80％必須是完整的。別的，如果有許多的測試，20％失敗的可能影響您的能力取得進(jìn)展。這是更好地指定的變革，必須樂成執(zhí)行。

　Example 2: A member of the team suggests that, as an entry criterion, "A specific set of tests, sometimes called an acceptance test, must be executed successfully."

　Make sure that you can defend each of the tests and can quantify the risk of continuing should a given test fail. Example 3: A member of the team suggests that, as an entry criterion, "The test plan must be reviewed and approved."

　Make sure that you can defend why the test plan must be approved, and can quantify the risk to the test if the plan is not approved.

　 例 2：對(duì)小組成員發(fā)起，作為項(xiàng)目的標(biāo)準(zhǔn)，“一組特定的測試，有時(shí)也被稱為的驗(yàn)收，必須執(zhí)行的樂成。”

　 確保您能保衛(wèi)每個(gè)測試和可量化的連續(xù)應(yīng)給定的測試失敗的風(fēng)險(xiǎn)。

　 例 3：對(duì)小組成員發(fā)起，作為入門標(biāo)準(zhǔn)“的測試籌劃必須經(jīng)過審查和批準(zhǔn)。”

　 請(qǐng)確保您可以掩護(hù)為什么測試籌劃必須得到批準(zhǔn)，可以量化的風(fēng)險(xiǎn)的考驗(yàn)，如果籌劃未獲批準(zhǔn)。

　24 Determining Exit Criteria

　 確定退出標(biāo)準(zhǔn) When determining exit criteria, identify what must be accomplished for the test effort to be complete for a particular test level or iteration. Agree up front with the project manager what needs to be done for the test effort to be complete. Remember that you must state the goals and objectives in measurable terms. Associate meeting your exit criteria with another aspect of the project. For example, associate the system test exit with a product ship decision or customer entry criteria. That will cause others outside of your team to feel a sense of urgency to ensure that your exit criteria are met. It will also help you to justify requests for help where needed. Once the team understands your testing objectives, you can ask the following question to start establishing good exit criteria: How do we know when we are done?

　 在確定退出標(biāo)準(zhǔn)，確定哪些必須為測試事情完成的針對(duì)特定測試級(jí)別或迭代完成。同意與項(xiàng)目經(jīng)理所需要做的測試事情完成前要完成。請(qǐng)記取，你必須明確的目標(biāo)和可丈量的目標(biāo)。

　 副訪問該項(xiàng)目的另一個(gè)方面，你的退出條件。例如，系統(tǒng)關(guān)聯(lián)的產(chǎn)物或客戶決定船舶入出境的標(biāo)準(zhǔn)測試。這將導(dǎo)致你的團(tuán)隊(duì)以外的其他人感觸一種緊迫感，以確保您退出條件得到滿足。它還將資助您在正當(dāng)理由需要資助的請(qǐng)求。

　 一旦球隊(duì)明白你的測試目標(biāo)，可以提出以下的問題開始創(chuàng)建良好的退出標(biāo)準(zhǔn)：

　 我們?cè)趺粗�道我們什么時(shí)候完成？

　25 Evaluating Ideas for Exit Criteria 評(píng)價(jià)標(biāo)準(zhǔn)的退出思路 As the team brainstorms, list ...

相關(guān)熱詞搜索：策略 測試