任务:实施测试
此任务描述了如何开发独立或协作测试。
规程:测试
用途

此任务的目的是:

  • 实施一个或多个测试工作产品,使得能通过实际执行来验证软件产品
  • 开发可与其他测试(作为更大型测试基础结构的一部分)联合执行的测试
关系
步骤
选择适当的实施技术
目的 确定用来实施测试的适当的技术。 

选择是适当的技术来实施测试。对于每项想要进行的测试,请考虑实施至少一个测试脚本。在某些情况下,给定测试的实施将跨越多个测试脚本。在其他情况下,单个测试脚本就能为多个测试提供实施。

实施测试的典型方法包括:以要遵循的脚本的形式编写一份文本描述(针对手动测试),以及基于脚本的编程语言的编程、捕获记录或生成(针对自动测试)。以下部分中将讨论各种方法。

对于大多数方法,我们建议您使用以下各种技术的混合,这样将能获得更有用的结果。 尽管您无需使用全部技术,但也不应限制自己只使用一种技术。

子主题:

手动测试脚本 至“选择实施技术”

许多测试最好手动进行,您应避免掉入尝试不适当地自动执行测试的陷阱。 可用性测试就是这样一个领域,在其中的许多情况下,手动测试是优于自动测试的解决方案。另外,需要验证软件系统的物理输出的精确性和质量的测试通常需要手动验证。作为一般的渐进做法,建议您开始特定目标测试项的第一批测试时,使用手动实施;此做法 使得测试员能了解目标项,能适应它的意外行为,并能应用人类的判断来确定接下来要执行的相应操作。

有时候,手动进行的测试将在随后自动执行并重复使用,以作为回归测试策略的一部分。 不过,请注意,对于可以通过其他方式手动进行的测试,没有必要也不值得自动执行每项这样的测试(甚至这样做也是不可能的)。自动化的确具有某些优势,例如测试执行的速度和精确性,详细测试结果的可视性和条理性,在创建和维护复杂测试方面也更有效率,但就像所有有用的工具一样,它不是能够满足您所有需求的解决方案。

自动化会带来一些劣势:在测试执行期间会缺少基本的人类判断和推理。当前可用的自动化解决方案完全没有人类所拥有的认知能力,甚至可以论证它们以后也不太可能拥有此能力。在手动测试的实施期间,可将人类推理应用到系统对激励的观察到的响应。当前自动化的测试技术及其支持工具通常具有有限的关注某些系统行为的实施的能力,并具有最基本的通过演绎推理来推断可能的问题的能力。

编程的测试脚本 至“选择实施技术”

可以证明,大多数使用自动测试的测试员实行的方法选择为:在其最纯的形式中,此实践是以与软件编程相同的方式执行,并使用与软件编程相同的一般原则。这样,用于软件编程的大多数方法和工具对于自动测试编程通常都是可接受和有用的。

通过使用标准的软件开发环境(例如 Microsoft Visual Studio 或 IBM Visual Age)或专门的自动测试开发环境(例如随 Rational Robot 提供的 IDE),测试员可自由地控制开发环境的特性和功能,以达到最好效果。

编程自动测试的消极面与编程本身作为一般技术消极面有关。为使编程生效,必须对相应的涉及考虑某个注意事项:否则,实施将可能失败。如果随着时间的推移,开发的软件可能由不同的人员进行修改(这也是通常的情况),那么在程序开发中应考虑采用常见的风格和形式,并确保其正确使用。可以论证,与此技术的误用相关的两个最重要方面为:

首先,存在这样的风险,即测试员将全神贯注于编程环境的特性中,耗费过多时间精雕细琢优美和精致的问题解决方法,而实际上这些方案可以通过更简单的方法完成。其结果是,测试员浪费宝贵的时间于本质上属于编程的任务,这对测试和评估目标测试项实际耗费的时间不利。避免犯此毛病需要训练和经验。

其次,存在这样的风险,用来实施测试的程序代码其自身就含有由于人员错误或倏忽而引进的错误。其中一些这样的错误将很容易在实施自动测试的天然过程中进行调试和纠正,而其他一些则不能。就像在目标测试项中错误可能难以检测一样,在自动测试软件中也可能同样难以检测到错误。而且,在用在自动测试实施中的算法是基于软件实施自身使用的有缺陷的算法的场合,可能会引进错误。 这会导致错误无法检测,而隐藏在自动测试的虚假安全背后,而测试表面上是成功执行的。只要可能,请在自动测试中使用各种不同的算法,以降低此风险。

记录或捕获的测试脚本 至“选择实施技术”

有许多测试自动化工具提供记录或捕获人与软件应用程序的交互,并生成基本的测试脚本。对于此,有许多不同的工具解决方案。大多数工具生成以某种形式的高级的通常可编辑的编程语言实施的测试脚本。最常见的设计工作在以下方式之一:

  • 基于拦截从客户端硬件外围输入设备(鼠标、键盘等等)发送到客户端操作系统的输入,捕获与客户端应用程序 UI 的交互。在一些解决方案中,这是通过拦截在操作系统和设备驱动程序之间交换的高级消息而完成的,这些消息以略具有含义的方式描述交互;在其他解决方案中,这是通过捕获低级消息而完成的,通常是基于鼠标坐标或按键弹起和按键下压事件之类基于时间的运动的级别。
  • 拦截在客户端应用程序和一个或多个服务器应用程序之间跨网络发送和接收的消息。这些消息的成功解释通常依赖于使用标准和公认的消息传递协议,例如 HTTPSQL 等等。一些工具还允许捕获“基本”通信协议,例如 TCP/IP,但处理这种性质的测试脚本可能会更复杂。

尽管这些技术通常对于被纳入自动测试方法的一部分是有用的,一些专业人员却感到这些技术具有局限性。其中一个主要问题是,一些工具只是捕获应用程序交互,并不执行任何其他任务。如果不在后续的脚本执行期间另外包含捕获和比较系统状态的观察点,那么基本 测试脚本不能视为具有完整形式的测试。如果情况如此,则初始记录随后将需要用其他定制程序代码进行补充,以在测试脚本内实施观察点。

多名作者已出版了关于此问题,以及其他与使用测试过程记录或捕获作为自动测试技术相关的问题的书籍和论文。要获得对这些问题的更深入理解,我们建议您查看由以下作者完成的工作(可在因特网上获取):James BachCem KanerBrian MarickBret Pettichord,以及 Lessons Learned in Software Testing [KAN01]一书中的相关内容。

生成的测试 至“选择实施技术”

一些更复杂的自动测试软件使得能基于生成算法实际生成测试的各个侧重面,或者是过程侧重面,或者是测试脚本的测试数据侧重面。此类自动化可以在测试工作中充当有用的部分,但其自身不应视为一个完整的方法。Rational TestFactory 工具和 Rational TestManager 数据池生成特性是此类技术的实施示例。

设置测试环境前置条件
目的 使环境处于正确的启动状态并就绪。 

设置测试环境,包含所有硬件、软件、工具和数据。 确保所有组件正常运作。 通常除了诸如将纸张装入打印机之类的任务以外,这还将涉及到某种形式的基本环境复位(例如复位windows 注册表和其他配置文件),将底层数据库复原到已知状态等等。 尽管一些任务能自动执行,但某些方面通常需要人员参与。

子主题:

(可选)测试的手动预评估 至“设置”

它尤其适用于自动测试脚本,有益于初始手动走查测试,以确认预期的先决条件可以满足。在走查期间,您应验证环境、软件和测试设计的完整性。走查在您使用交互式记录技术的场合相关性最大,在您编写测试脚本的场合相关性最小。目标是验证所有对于成功实施测试所必需的元素是否均存在。

如果已知软件足够可靠或成熟,您可以选择跳过此步骤,只要您认为手动走查解决的领域中发生问题的风险是相当低的。

确定并确认测试预测的适用性 至“设置”

确认您计划使用的测试预测是合适的。如果已经确定了它们,则您可以这样做了。

您应尝试通过备选方法来确认,选择的测试预测将提供精确和可靠的结果。例如,如果您计划使用通过应用程序的 UI 显示的字段来验证测试结果是否指示发生了数据库更新,则请考虑独立地查询后端数据库,以验证数据库中相应记录的状态。另外,您还可以忽略更新确认对话框中出现的结果,而是通过备选的前端函数或操作来查询记录,从而确认更新。

复位测试环境和工具 至“设置”

接下来您应将环境(包括支持工具)复原回其原始状态。如前面步骤所提及的那样,这通常除了诸如将纸张装入打印机之类的任务以外,这还将涉及到某种形式的基本操作环境复位,将底层数据库复原到已知状态等等。尽管一些复位任务能自动执行,但某些方面通常需要人员参与。

设置测试支持工具的实施选项,这些选项将根据工具的复杂度而有所不同。 如有可能,您应考虑为每个工具存储选项设置,以便能根据一个或多个预先确定的概要文件方便地重新装入它们。对于手动测试的情况,它将包括诸如对支持系统中的新的条目进行分区以记录结果,或者登录到问题和变更请求记录系统之类的任务。

对于自动测试实施工具的情况,可能要考虑许多不同的设置。如果不适当地设置这些选项,可能会减小生成的测试资产的有用性和价值。

实施测试
目的 实施一个或多个可重用的测试实施资产。 

通过使用测试构想列表或一个或多个选择的测试用例工件,开始实施测试。以赋予测试一个唯一可标识的名称开始(如果它尚没有名称),然后准备 IDE、捕获工具、电子表格或文档,以开始记录测试的特定步骤。完成以下子节直到实施测试所需要的次数。

请注意,对于某些特定测试或测试类型,清楚地记录对于进行测试必需的步骤可能价值不大。在某些风格的探索性测试 中,测试的重复不是预期的可交付件。对于非常简单的测试,在许多情况下,测试目的的简要描述就足以使其能被复制。

子主题:

实施导航操作 回到页首

编写、记录或生成必需的导航操作。通过选择适当的导航选择方法开始。对于当今大多数种类的系统,“鼠标”或其他定位设备是首选和主要的导航介质。例如,用于个人数字助理(PDA)定点和画线设备在概念上等同于鼠标。

次要导航方法通常是键盘交互方法。在大多数情况下,导航将由鼠标驱动操作和键盘驱动操作的组合构成。

在一些情况下,您将需要考虑声音激活感知、光线感知、视觉感知以及其他形式的感知。如果要允许从文件装入和处理音频和可视元素(而非动态捕获),那么自动测试可能更加麻烦,并可能需要向应用程序添加特殊测试接口扩展。

在一些情况下,您可能想要(或需要)使用多种导航方法执行相同的测试。您可以采取各种不同的方法来达到此目的,例如:自动执行使用其中某种方法的所有测试,而手动执行使用其他方法的测试中的全部或一部分;将测试的导航侧重面从体现特定测试特征的测试数据分开,提供并构建逻辑导航接口,该接口允许选择任一种方法来进行测试;简单地混合与匹配导航方法。

实施观察点 回到页首

在测试脚本中的每个应进行观察的点,使用适当的测试预测来捕获需要的信息。在许多情况下,从观察点获得的信息将需要记录和保留,以在后续的控制点期间进行引用。

如果这是自动测试,请决定观察到的信息应如何从测试脚本中报告。在大多数情况下,通常简单地在中央测试日志中记录相对于从测试脚本开始后的时间增量的观察即已合适,在其他情况下,特定的观察可以分开地输出为电子表格或数据文件,以用于更复杂的用途。

实施控制点 回到页首

在测试脚本中应进行控制决策的每个点,获取并评估适当的信息,以确定要遵循的控制流的正确分支。从先前观察点检索到的数据通常是控制点的输入。

在出现控制点,且制定了关于控制流中下一操作的决策的场合,我们建议您将输入值记录到控制点,以及在测试日志中选择的生成流。

解决测试实施中的错误 回到页首

在测试实施期间,您将可能引进测试实施本身中的错误。这些错误甚至可能是您从测试实施中省略的事物的结果,或者可能与您在测试环境中未能考虑到的事物有关。需要解决这些错误,然后才能认为测试已完全实施。标识您遇到的每个错误,并解决它们。

在使用编程语言的自动测试的情况下,这可能包含由于未声明的变量和函数,或者无效地使用这些函数而导致的编译错误。处理编译器或其他任何错误消息源显示的错误消息,直到测试脚本不含语法错误和其他基本实施错误。

请注意在测试的后续执行期间,可能会找到测试实施中的其他错误。最初这些可能显示为目标测试项中的故障 - 对于您确认故障实际在目标测试项中,而不在测试实施的某个侧重面的情况,分析这些测试故障需要您的勤勉。

建立外部数据集
目的 创建和维护外部地存储到测试脚本的数据,测试在执行期间会用到这些数据。 

在许多情况下,维护测试脚本外的测试数据会更合适。这样为测试脚本和测试数据维护提供了灵活性、简单性和安全性。外部数据集以如下方式向测试提供值:

  • 测试数据在测试脚本外可以不需要在测试脚本中使用硬编码引用。
  • 外部测试数据可以方便地进行修改,通常对测试脚本产生的影响最小
  • 稍加修改或无需修改测试脚本,测试数据就能方便地支持其他测试用例
  • 许多测试脚本可以共享外部测试数据
  • 测试脚本可以开发为使用外部测试数据,以控制测试脚本中的条件转移逻辑。
验证测试实施
目的 通过执行测试脚本,验证测试脚本的正确工作。 

尤其是在自动测试的情况下,您将可能需要耗费一些时间来在测试执行时稳定测试工作。完成了测试脚本的基本实施之后,应对它进行测试,以确保它适当地实施各个测试,且这些测试正确执行。

将测试环境恢复为已知状态 至“验证测试实施”

您又一次应将环境复原回其原始状态,在测试实施工作之后进行整理。 如前面步骤所提及的那样,这通常除了诸如将纸张装入打印机之类的任务以外,这还将涉及到某种形式的基本操作环境复位,将底层数据库复原到已知状态等等。尽管一些任务能自动执行,但某些方面通常需要人员参与。

设置工具并启动测试执行 至“验证测试实施”

尤其是在自动测试的情况下,支持工具内的设置应进行变更。其目标在于通过执行测试脚本,验证测试脚本的正确工作。

建议您执行此步骤时使用与用来实施测试脚本相同的工作版本。 这可以消除由于在后续工作版本中引进的错误而导致问题的可能性。

解决执行错误 至“验证测试实施”

有一种现象相当普遍,即一些完成的工作和在实施期间使用的方法需要进行一定程度的调整,以使测试能无人看管运行,尤其是涉及到 在多个测试环境配置下执行测试的情况下。

在测试自动化的情况下,请准备好花费一定时间进行检查,测试将在“容错度内运行”,并调整它们直到能可靠地工作,之后您才能声明测试已实施。尽管您可以推迟此步骤直到生命周期的后期(例如测试套件开发期间),但我们建议您 不要推迟,否则可能会以累积大量需要解决的故障而告终。

将测试环境恢复到已知状态
目的 将环境保留为您找到它时的方式,或保留为必需的状态,以实施接下来的测试。 

尽管此步骤可能看似琐碎,但它是一个重要的好习惯,形成该习惯可以有效地与团队中的其他测试员协作,尤其是对于共享实施环境的场合。建立一套程序来考虑系统状态的第二天性也是很重要的。

尽管在主要是手动的测试工作中,标识和修正环境复原问题常常很简单,但请记住自动测试容忍环境状态出现意外问题的能力要小得多。

维持可跟踪性关系
目的 使得能对跟踪的项执行影响分析和评估报告。 

通过使用在测试计划中概述的可跟踪性需求,按照需要更新可跟踪性关系。

评估和验证结果
目的 验证任务已恰当地完成,生成的工作产品是可以接受的。 

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

让那些将在他们的后续任务中使用您的工作作为输入的人员参加复审您的过渡工作。请在您还有时间针对他们的意见采取行动时让他们参与复审。您还应该针对关键输入工作产品评价您的工作,确保您已经充分、准确地提供或考虑了这些工作产品。让输入工作产品的作者以此为基础复审您的工作,这可能很有用。

请记住,RUP 是一个迭代的交付流程,并且在许多情况下工作产品是随着时间而演进的。 所以,没有必要完全形成在近期的后续工作中只部分使用或根本不用的工作产品,并且这样做在很多情况下会对生产效能产生负面影响。这是因为很可能在使用工作产品前,工作产品的使用环境会发生变化并且在创建工作产品时所作的假设也被证明是不正确的,从而导致返工以及随之而来的工时的浪费。

还要避免在展示内容本身价值损害方面耗费太多周期时间。在作为项目可交付件的展示很重要且具有经济价值的项目环境中,您可能想让行政人员或初级人员来处理工作产品,以改进其展示效果。



更多信息