测试策略3999790493.doc_第1页
测试策略3999790493.doc_第2页
测试策略3999790493.doc_第3页
测试策略3999790493.doc_第4页
测试策略3999790493.doc_第5页
已阅读5页,还剩28页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

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.一个测试策略的设计是一个多步骤的分析过程: 1. 分析需求。 2. 评估风险。 3. 定义测试范围。 4. 确定测试方法。 5. 确定进入和退出条件。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?只要项目的需求和风险被准确理解,测试计划的下一步就是确定测试策略。测试策略解决下列问题:为什么我们要测试?我们要做些什么?我们计划不做些什么?Your test strategy must include a clear definition of the scope of your testing. Your scope may be determined in part by your teams 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.你的测试策略必须包括你对测试范围的一个明确定义。你的范围可能部分取决于你团队的责任。在大型发展项目里,可能有多个测试团队同时工作,每一个小组负责项目的不同方面。像在测试阶段和活动中描述的一样,即使是很小的项目,也有不同程度的测试。你的范围包括你负责的范围内的测试阶段。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.你的测试范围也会因为项目本身的范围和性质而受到影响。例如,对于一个新产品来说,一个准许生产的产品中的一个小服务的测试范围更小。To determine the test approach, ask questions like these for each of the project features and attributes:l What testing is planned for this feature or attribute? l What customer problem does this feature solve? l What announcement claims will we be making about this feature? l What automation will we used to develop the tests for this feature? 要确定测试方法,为检测项目的功能和属性,必须提出下列问题,: 1、为测试功能或属性,要进行怎么样的测试?2此功能解决客户的哪些问题? 3针对这个特点,我们要做出怎样的报告? 4我们将用什么自动化工具或技术来进行这项功能的测试?To determine when to start and end testing, identify entry and exit criteria by answering the following questions: 为了决定何时开始和结束测试,根据下列问题的答案,确定进入和退出条件:l During the development process, can the tests weve defined be executed in an effective and efficient manner? l As the product continues to progress, when are we are finished? 1在开发过程中,我们定义的测试能否以有效和高效的方式执行? 2随着产品的不断发展,我们什么时候能够完成?In order for entry and exit criteria to be effective, they must have three common attributes.l Entry and exit criteria must be meaningful. l Entry and exit criteria must be measurable. l Entry and exit criteria must be achievable. 为了进入和退出条件能够生效,就必须有3个共同属性。 进入和退出标准,必须是有意义的。 进入和退出标准,必须是可衡量的。 进入和退出标准,必须是可实现的。课程目标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 学完这一课后,你将能够: 定义测试范围确定你的测试方法确定何时开始测试以及何时完成测试 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. 在整个过程中,你将有机会获得各种软件测试活动的实际操作。我们将使用下面的虚构场景,为我们的例子和练习提供场景。Project backgroundThe 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. 项目背景 亚利桑那州的气候观察组是由亚利桑那州的专业和业余的气候观察家志愿者组成的。他们一年举行两次会议,来交流想法和意见。 The Arizona Weather Data ProjectAt the last meeting, it was determined that the group would attempt a long-standing goal. Since the groups 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. 亚利桑那州的气象资料项目上一次会议确定了该小组将尝试一个长期目标。从小组成立以来,积聚所有亚利桑那州的天气数据成为一个不断更新的数据库的强烈愿望及一直存在。天气观察家决定,既然互联网提供了方便,那么是时候尝试这个项目了。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 thiscourse referto this background material.他们想创建的网络工具,可以使整个亚利桑那州小组的成员能够提交当地天气观测的数据到一个中央数据库。这个项目就被称为亚利桑那州气象数据项目。 许多这个课程中的例子和练习是指此背景。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. 在这个模块的整个过程中,你将利用在下载页面下现成的Rational统一过程(IRUP)Master Test Plan Microsoft Word模板,记录亚利桑那州气象数据项目的测试计划。The Arizona Weather Data Project (AWDP) consists of a web-based tool that allows volunteers across Arizona to submit local weather observations.亚利桑那州的天气数据项目(AWDP)里有一个基于网络的工具,使得分布在亚利桑那州的志愿者可以提交当地的气象观察资料。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. 正如你在测试管理原则中学到的,你可以细分测试计划,来更好地处理细节和程度的层次多样性。由于亚利桑那州气象数据项目团队比较小,你只需要创建一个测试计划。Sections of this module refer you to the section numbers and section titles from the IRUPMaster Test Plan template.这个模块的部分,指的是IRUP主测试计划模板里的章节数和标题。Developing a Test Strategy制定一个测试策略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: 当需求和项目的风险被充分理解后, 测试计划的下一步是确定测试策略。在对于项目经理,管理人员和你的团队人员是有用的水准上,测试策略回答了一下问题: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:我们为什么测试? 我们计划做什么以及不做什么? 我们将如何做测试? 一个测试策略的形成是一个多步骤的分析过程:Developing a Test Strategy,continued制定一个测试策略,续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. 你已经学会了如何执行第1步:需求分析。你学过了如何评估功能需求和非功能需求,以及如何制定用例及用例模型。你也学过了如何改进不健全的需求。还学习了如何执行第2步:评估风险。In this lesson, you will learn how to do steps 3 through 5 of developing a test strategy as follows: 在这一课,你将学习创建一个测试策略的第三个步骤到第五个步骤,如下所示: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步:确定你的测试方法第5步:确定何时开始测试和结束测试。 在创建测试策略时,第一个(在一些项目中最重要的)步骤是阐明项目的测试范围。 Defining the Scope of Testing定义测试范围 You must clearly define the scope of your testing. Your scope may be determined in part by your teams 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. 你必须明确定义你的测试范围。您的范围可能部分取决于你的团队的责任。你的范围可能部分取决于你团队的责任。在大型发展项目里,可能有多个测试团队同时工作,每一个小组负责项目的不同方面。像在测试阶段和活动中描述的一样,即使是很小的项目,也有不同程度的测试。你的范围包括你负责的范围内的测试阶段。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. 您的测试的范围也受到项目本身性质的影响。例如,对于一个新产品来说,一个已存在产品的一个小服务的测试范围可能会更小。清晰地决定测试范围。决定测试哪些功能或特征, 哪些产品或产品组合进行测试了,而哪些没有进行测试。对于与你没有测试的部分相关的那些风险,一定要信息全面的了解和评估它们。7Communicating Testing Scope DecisionCommunicate 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:为了他们的理解,讨论和赞成,要向项目组成员传达与范围有关的决定。在你们迅速达成一致的情况下,可以比较容易的进行,讨论对于鉴定项目组关于测试可能持有的未说出的假设往往有重要的侧面影响。这些讨论也有助于确定项目小组成员在整个项目生命周期中期望承担的角色。讨论的问题例子包括以下内容: 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? 开发人员被期望能够证明他们已经做了一定量的单元测试,才可以提交代码吗? 当项目时间压缩时,项目经理希望给测试团队补充合约人或者开发人员吗?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. 在通信测试范围决定的过程里设置适当的预期,更进一步,预期测试和测试团队对于这个项目,什么可以做什么不能够做。这些问题最好事先讨论,而不是直到危机或冲突的发生了才去讨论。 8. Identifying Scope: Test Levels and Focus Areas确定范围:测试阶段和重点区域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.您可以根据每个阶段对于应用和代码的侧重方面把测试活动分类成阶段。每一阶段负责一系列重点领域,你需要把分析和评估这些重点领域作为确定测试策略的一部分。9Functional Verification Test Focus Areas功能验证测试重点领域The set of focus areas for Functional Verification Testing (FVT) are:功能验证测试(FVT)的重点领域设置:10System Verification Test Focus Areas系统验证测试重点领域The set of focus areas for System Verification Test (SVT) are:系统验证测试(SVT)的重点领域设置:Youll notice that some of the same focus areas appear for both FVT and SVT. The emphasis, however, is different in each case. Lets 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.你会发现,同样的一些重点领域会在FVT和SVT里同时出现。,但是重点是,在每种情况下是不同的。让我们来看看回归重点领域。FVT工作组对个别功能进行回归测试,例如登录功能。 SVT团队的回归测试是测试整个系统。例如,SVT的团队可能再次执行的负载和压力测试。11 Test Inclusions测试包含的活动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 earlierin this module and review sections 1.2 and 4. Section 1.2: ScopeUse 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 TestsUse 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.)一旦你决定了你的测试范围,您就可以记录你的范围。打开在本模块中你早些时候已下载的IIRUP主测试计划模板,回顾第1.2和第4部分。 第1.2节:范围 利用本部分定义你将要执行的测试阶段,以及不执行测试的阶段。一定要事先复习第4部分完成第1.2节,以避免重复信息或出现在错误的位置。 第4部分:回顾测试计划使用此部分记录你计划测试的的功能和属性。(在这一课的后面,我们将记录你不准备测试的功能。) Section 4.1: Outline of Test InclusionsA 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 Inclusionsfor an example.4.1节:测试包含活动的大纲一个记录测试活动的好办法是利用之前在规划过程中产生的风险分析的结果。 对于AWDP测试计划,你几乎可以直接使用你在测试规划和风险分析模块中创建的表格。添加一名为“补充信息”的列,捕捉分析背后的逻辑。使用这块新空间,来解释为什么某些特征或属性被给予了特别的影响程度和可能性,以便审阅者能够理解和评价评估。 点击测试活动,举一个例子。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节:其他候选的潜在活动的大纲可能有一些功能或属性,你觉得可能需要进行测试,但将需要更多的调查和了解。在本部分中使用与测试包含活动相同的格式列出它们,但要使用“补充信息”一列记录为什么此功能或属性被列入潜在活动的原因。 Section 4.3: Outline of Test ExclusionsThese 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 anexample.4.3节:测试排除大纲有些功能或属性,你已经确定它们具有足够低的优先度,可以不发展和执行测试。使用“补充信息”的列解释为什么不需要进行测试。例如,在亚利桑那州气象数据项目应用中,有一 个“保存草稿”的资料提交表单选项。不对 “保存草稿”进行测试的合理理由是,该表不需要很长时间才能完成,而且大多数用户无需一直保存他们的工作就可以完成观察数据的输入。 点击试验排除的一个例子。13Determining the Test Approach确定测试方法The next step in the process of defining your strategy is to determine your test approach.确定策略进程的下一步是要确定你的测试方法14Determining the Test Approach, continued确定测试方法,继续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. 为了有效的测试,面临的挑战是采用功能和属性的优先级列表,优先级列表是基于风险缓解和对重点领域的测试评估,并且要确保涵盖所有领域。Recall that the focus areas for Functional Verification Test are: Mainline functions Error conditions Recovery Basic usability Accessibility Global enablement Vulnerability Regression回想一下,在功能验证测试的重点领域是: 主线功能错误条件恢复基本可用性可用性全球可用漏洞回归The focus areas for System Verification Test are: Load and stress Regression Recovery Migration Usability Serviceability Functional completeness Hardware and software interaction系统验证测试的重点领域是: 负载和压力回归恢复迁移可用性使用能力功能完整性硬件和软件的相互作用整理到这里Taking this approachallows 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. 采取这种方法可以让您专注的测试工作,以提供最大的利益。对于功能和属性,每年提出这些问题,以确定测试方法: 是什么样的测试计划在此功能或属性?回答这个问题时,请务必请在您的测试级别的重点领域来进行。例如,此功能需要为全球启用测试?此功能需要的压力测试?这是一个功能,很可能会受到黑客的攻击? 客户的哪些问题此功能解决?这将有助于您决定在何处集中对这一功能的测试。 公告要求什么,你又对这项功能?这个问题将有助于确保您正在核实营销是说什么。 此功能将被核实的回归测试执行而已?如果是这样,为什么? 什么自动化将用于开发此功能的测试?请记住,时间和资源将被纳入计划之内设计/开发的自动化和潜在的学习新的工具。 您可能需要添加到这个列表的问题是特定于您的环境。重要的是有一个列表,以便您不会错过重要的考虑因素。15Different Test Levels, Different Test Strategies不同的测试级别,不同的测试策略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. Lets 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.您的亚利桑那州气象数据项目(AWDP)测试计划的范围包括两个不同层次的测试:功能验证测试(FVT)和系统验证测试(SVT)的。不同级别的测试可能需要不同的测试策略。 让我们来看看为各层级的例子:FVT和SVT。我们将使用优先列表,我们在测试规划和风险分析模块开发的功能和属性。16Example: Test Approach for the AWDP Login Feature例如:测试的AWDP登录功能的方法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

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论