任务:定义测试方法
此任务描述了如何确定将采用的测试策略和特定技术,并概述了测试自动化体系结构。
规程:测试
用途

此任务的目的是:

  • 确定将为实现所需测试而采用的每种特定技术
  • 概括每种技术的工作方式,包括它支持的测试类型
  • 为测试自动化系统定义一个候选体系结构
关系
角色主执行者: 其他执行者:
输入必需:
    可选:
      输出
        流程使用情况
        步骤
        检验测试激励因素和测试项
        目的: 考虑任务、测试激励因素和测试项对将要用于测试工作的方法的影响。 

        使用评估任务作为环境,检验迭代测试计划并研究已针对即将进行的测试工作确定的测试激励因素。可能有必要对激励因素来源进行进一步调查 - 通常迭代计划提供一种查找附加信息的方式。

        对于每个激励因素,考虑需要什么测试方法和相关联的技术来处理每个激励因素。还要检验迭代测试计划并研究测试项。每个目标测试项都应被视为与每个激励因素有关,而方法和技术则相应扩展。如果您找不到关于测试项的大量详细信息或不熟悉测试项,那么与开发人员讨论目标项可能很有帮助,通常是先与软件设计人员或开发团队主管讨论。

        着重确定令人满意地处理评估任务和激励因素所需的最少的一组技术。寻求一项技术可用于处理所需测试的多个方面的机会。请注意其他的那些似乎探索起来很有趣的可能技术,但要能够将它们确定为附加技术而不是基本技术。

        检验软件体系结构
        目的: 考虑软件体系结构对测试方法的影响。 

        研究软件体系结构以理解其要素(机制、主要视图等)。通常,软件体系结构文档提供注重于在考虑测试方法时使用的适度详细信息的优秀信息。为了澄清其信息,或在缺少文档的情况下,与开发人员讨论体系结构很有用,通常是直接与软件设计人员或开发团队的一个主管讨论。

        着重确定并讨论主要机制,并较好地了解系统的这些方面。体系结构的每种机制和主要特性都将可能给测试工作带来难题或约束。例如,一个分发式体系结构可能需要将测试团队组织为几个分队,每个分队都针对一个体系结构层。

        尽管在测试实施与执行策略中使用新方法通常可克服这些难题,但可能需要让开发团队修改软件来实现测试,如 任务:定义可测性元素所述。

        考虑测试方法的适当宽度和深度
        目的: 考虑测试方法在宽度和深度方面的完整性。 

        考虑现在对测试方法的需求所知的所有详细信息,最好返回并从一个较高的角度考虑该测试方法。测试方法有哪些事情应处理而没有处理?有应予以探究但在所记录的任何信息中都没有出现的问题吗?

        基于您的经验,复审测试方法的需求,以针对项目生命周期的这个阶段确定适当的宽度和深度。考虑将有助于展示更完整方法的其他需求。

        确定要复用的现有测试技术
        目的: 在适用的情况下,复用经过证明的现有测试技术或改编这些技术。 

        根据您自己的经验或其他可得到的经验,确定将满足测试方法需求或者经过改编后可满足这些需求的现有技术。

        确定其他技术
        目的: 确定提供全面而充分的测试方法所需的技术。 

        考虑“完整的”测试方法并不怎么有用 - 如果您有无限的时间和资源,总可以尝试其他技术。

        但是,测试方法的成熟度和全面性足以允许对感觉到的质量进行有用的评估,这是很重要的。对项目团队来说,这需要一种从多方面充分评估质量风险或以多维方式充分评估质量的方法,以恰当的置信度评估感觉到的质量。

        定义技术
        目的: 概括每种技术的工作方式,包括它支持的测试目标。 

        概括每种技术的工作方式。处理它支持的测试类型、目标和范围、实施方法、测试预测、评估方法以及自动化需要。

        在许多情况下,您会将一个项目的技术重用于下一个项目。在这种情况下,您可以仅引用该技术的普通定义或复制现有的定义并在适当情况下进行修订。

        对于每种现有的或必需的技术:

        定义对象和范围 回到页首

        许多技术将支持多种测试,所以在确定该技术将需要支持哪些测试时要动些脑筋。如果该技术是第一次定义,这将有助于确定所需工作的范围。

        在这种技术所代表的底层目标和价值观上要动些脑筋。

        描述实施方法 回到页首

        定义将如何实施该技术。简单地说明“我们在进行系统性能测试”是不够的,您需要认真地思考如何实现该目标。

        您希望使用的某些技术可能执行起来不太经济。简短地描述您将如何实施该技术,您将能够对所涉及的后勤和进一步执行该技术的实用性有整体的认识。

        确定适当的评估方法 回到页首

        确定您将如何观察和评估使用此技术实施每次测试的结果。 动脑思考一下您可进行哪些不同的测试预测,只有一个预测吗?还是有别的方法可以确定每次测试的结果?

        确定适当使用自动化 回到页首

        自动化在许多测试技术中可能有着重要的作用。在某些情况下,它可能没那么完善,仅提供对开展手动测试的支持。

        在如何最有效地实施、维护和管理涉及该技术的工作方面要动些脑筋。要解放思想 - 提高思考的宽度和深度,考虑尽可能多的可选项。

        确定适用的工具 回到页首

        确定要与这种测试技术配合使用的适当工具。使用确定使用自动化的前一步骤中的相同工作。

        记住,要考虑大量的工具类别;您的候选工具列表不应只包括测试执行自动化工具。除了使测试执行自动化的工具外,还要考虑将通过减少重复繁重的任务(例如测试数据管理、测试结果分析)而提高测试团队生产力的工具、事件工具以及变更请求报告工具等。

        概括测试自动化体系结构
        目的: 为测试自动化系统定义一个候选体系结构。 

        基于从类似系统或在类似的问题域中获得的经验,开始为测试自动化系统定义候选体系结构。

        建议您复审开发软件体系结构的相关信息,以帮助您完成此任务。

        定义测试资产配置管理策略
        目的: 考虑测试将对配置管理有何需求。 

        就像软件开发项目期间生成的许多其他工作产品一样,测试资产是配置管理和版本控制的候选对象。

        特定需求的复杂性的范围为从决定使用启用的基本备份和恢复服务,到完全支持在多个地点针对应用程序的不同版本并行开发自动化测试脚本。

        在配置管理的需求方面动些脑筋,并开始概括可能的、实现这些需求的后勤需要。

        调查可重用资产的可用性
        目的: 通过复用经证明的现有资产来减少风险和工时。 

        有时从头开始构建资产是有意义的,有时则没有意义。在创建新工作产品时尽量在完全“自定义”原则和确立呆板而官僚的管理政策之间寻求很好的平衡。

        经常会出现一种方法好于另一种方法的情况,您应该足够灵活地利用两种方法带来的好处。

        获取调查结果
        目的: 记录关于测试方法的重要信息。 

        根据许多因素(包括团队规模和组织文化),会有或好或坏的方法来记录您就测试方法所做出的决策。

        通常您需要考虑两类受众:管理团队想要阅读此信息以提供批准和知道该方法的后勤关连,测试团队想要使用测试方法作为执行工作的指导。努力查找一种适合这两种需要的适当介质:也许是使用项目内部网 Web 站点。

        评估和验证您的结果
        目的: 验证任务是否已恰当地完成并且生成的工作产品是否可接受。 

        既然您已完成了该工作,那么最好验证该工作是否有足够的价值,而且您并不是简单地消耗大量纸张。您应评估您的工作质量是否适当,是否完整得足以让其他团队成员觉得您的工作很有用,并随后将它们用作他们自己工作的输入源。在可能的情况下,请使用 RUP 中提供的核对表验证质量和完整性是否都“足够好”。

        让执行后续任务(要将您的工作作为输入)的人员参与复审您的过渡工作。请在您还有时间针对他们的意见采取行动时让他们参与复审。 您还应针对主要输入工作产品评估您的工作,以确保您已准确并充分地展示了它们。在这个基础上,再让输入工作产品的作者复审您的工作可能很有用。

        请记住,RUP 是一个迭代的交付流程,并且在许多情况下工作产品是随着时间而演进的。所以,通常没有必要完全形成在近期的后续工作中只部分使用或根本不用的工作产品,并且这通常会对生产效能产生负面影响。这是因为很可能在使用工作产品前,工作产品的使用环境会发生变化(并且已证明在创建工作产品时所作的假设不正确),从而带来工时的浪费和高成本的返工。还要避免在展示内容价值损害方面耗费太多周期时间。 在展示作为项目可交付工作产品很重要而且具有经济价值的项目环境中,您可能希望考虑使用管理资源来执行展示任务。



        更多信息