测试用例和测试资产通常随着时间而增长，在许多情况下，它们的增长没有得到很好的管理。我们认为，需要对测试用例的效率和效益进行管理，其方法与管理代码资产十分相似。
所以，你问过自己以下几个问题了吗？
●你希望尽量减少测试维护时间吗？
●你的测试集里的测试中有重复的设置步骤吗？
●全面彻底的改变对你的测试有不利影响吗？
●你的测试集过于零散/增长过快吗？
●你的测试集和测试下的系统之间不对齐吗？
如果其中的一个或多个问题你回答“是”，这篇文章会使你更加了解如何才能够更好地回答这些问题并管理测试用例资产。我们将在某些章节加上一些用例（斜体）作为例子来说明我们的测试用例架构设计方法如成功地在VISTAPRINT中被利用的。
背景及需要
VISTAPRINT一直通过以合理的价格提供专业的营销产品和服务给世界各地超过50万的微型企业，使它们让人印象深刻并拥有脱颖而出的机会。
我们是一个电子商务营销公司，拥有超过25个本地化的国际网站，每3周发布整个代码库将其投入生产。每个发布周期包括1周的需求审核，3周的开发，及 1周的全[url=]系统测试[/url]。这个5周的周期被2周覆盖，使我们能够每3周发布一个新产品。
我们当前的代码库中缺乏某些架构原则，比如关注点和服务导向的分离，所以大多数测试是通过一个完整环境的UI界面完成的。丰富的UI级自动化的存在会自动抄录手动操作。
自动化由测试编写质量工程师外的开发团队创建和管理。采用测试用例设计架构的想法来源于提高我们的测试管理流程的需求。
以前在组织中，内联步骤文档就足够了，但是一旦开始运行大规模的测试脚本，我们就会遇到问题。虽然许多测试想要执行完全一样的步骤，但是每个测试都有其独特的文档。
记录步骤的变化难以保持是一致且最新的。这个过程是无效的且维护它的成本会不断增加。此外，起草新测试时，设置步骤的知识需要传播给每个人，以便更正记录。即使测试的创建者只是想达到让特性“通过”测试的目的，这也是必要的。这引起测试创建者和特性所有者之间很多不必要的来回交流。
我们提出三点以增加质量组织的测试资产集的质量和可扩展性。这三点如下，本文的重点是第三点：
1.优质的平台和工具——一个全面的平台，它拥有一个完整的与我们的自动化平台无缝协作测试管理系统。
2.优质的工程培训和技能提升——一个扩展组织的技能使之更擅长利用测试设计和相关的做法的程序。
3.可扩展性的测试设计增强——我们推广我们测试资产的重用和可扩展性的方法，本文的重点是不断向前推进。以这种方法，我们的测试案例设计现在专注于把某种软件架构和设计原则用到测试用例的创建和维护过程中。
这些原则包括：
●定义测试对象模型
●孤立的，可重用的构建模块和模板
●测试参数
●一个“从测试到软件”的映射
定义测试对象模型
传统上，一个测试，被认为是包括某种验证形式的一组执行步骤。但是，比起你看到的，测试对象还有更多。测试对象模型需要测试并剖析其组成部分：描述符，步骤和可连接的业务对象。
●描述符表示存在于所有测试中的数据集。包括标题，测试所有者，创建日期等。
●步骤表示如用户描述与系统的行为交互，功能验证也包含于此。
●可连接的业务对象是任何有用的外部对象。这包括自动化脚本，其中包含了执行正在测试中的底层系统的代码。
一定要保持行为与代码实现分开以减少测试步骤的脆弱性，自动化脚本应该处理人类可读的功能说明和代码级别实现界面之间的转换。
图1 测试对象模型
步骤框进一步细分为不同的步骤类型。 步骤类型为执行时测试中所发生的一切提供了更高的可视性，引发大量的智能分类大故障。
设置步骤是用来准备和验证系统在正确的状态开始测试功能特性。正因如此，这些步骤中的任何可见问题都将阻止测试，测试将会被标记为“关闭”。 执行和验证的步骤是真正行使正被测试的特性的步骤。 这个空间的任何问题都必须进行调查，并把测试标记为“失败”。 最后，还有一些在测试后将系统恢复到已知状态的清理步骤。这里的问题可能意味着后续测试的假故障（如果系统并不与它本应该的一致），所以一个“警告”被放在测试上了。
图2 步骤类型和状态
我们已经看到步骤类型的好处主要在大量的自动化测试领域，因为它们减少了调查故障的时间。 用手工测试的话，测试工程师执行测试时可以瞬间就作出这个决定。
孤立的，可重复使用的构建模块和模板
因为超过50的测试员和1万的测试与测试下的同一系统交互，所以在我们的测试中有大量的步骤重复，大多是关于测试设置的。我们需要一种方法来增加系统功能的可用性，但同时也能限制这些功能交互的各个领域。我们通过引进构建模块和模板实现这一目标。
●构建模块是在一项功能上进行的（潜在参数驱动的）个体行动，应该包含必要的逻辑步骤以便与指定功能交互。一个模块的范围是灵活的，只需要和测试套件认为必要的那么多模块就行。一个模块可以被分解成更小的模块，随后需求上升以增加一个功能交互性的灵活性。
●模板是连接在一起通过应用程序来创建流的构建模块的有序集合。功能交互不应该在模板里，而应在他们称作模块的里面。模板可以一个嵌一个，使最少步骤的测试下的系统得以充分交互。
图3 构建块和模板
采用这些就把隔离引入了我们的集合中，并缩减了系统变换时脚本和文档改变所需的时间。由于现在一个调用就包含许多嵌套的步骤，测试用例的创建时间已被最小化了。如果被调用的内容已被自动化，那么自动化时间也减少了。书面测试步骤保证了精确度，因为任何测试员都可以为该功能从业外调用步骤，但他们调用的项是由业内专家创建的。这就使得可以从测试员吸取业内知识并用于测试集系统。
说明：
像大多数电子商务公司一样，我们的网站有用户登录功能，且许多网站功能（管理购物篮中的物品，结账等）都需要先登录。还有许多专为确认这些功能是否有用的测试工作，并且所有的都必须登录操作。一组“登录”构建模块被组成一个模板，该模板附带所有这些功能测试。只有一个脚本是需要在数百个测试中自动登录，最大限度地减少编程时间，并在我们的登录行为改变时阻止测试集变化。如果一个行为确实发生了变化，我们可以更新“登录”模板，所有使用此模板的测试都随之改变。这样的实现和重用导致我们无需额外费力去更新和维护就能大规模地缩放我们的测试集。
测试参数
参数是测试中的变量，它们允许特定的数据点在测试设计完成后分别被输入。一些VISTAPRINT充分利用的参数包含了：环境（ DEV ，TEST等），浏览器（IE9，Chrome等），及篮子物品（名片，明信片等）。目前我们测试库中的参数总数超过了700 ！使用参数构建模块和模板引起自动调用测试接续它们。这扩展了测试下我们大部分系统的功能集使所有调用测试都免费了。测试设计者利用行业知识确定应使用哪些参数来确保适当的覆盖范围。参数可以使测试用相同的一般步骤但以不同的方式进行配置。定义广泛变量以在之后的阶段配置值使得许多数据驱动场景下表现为一个单一测试。这对测试管理有帮助并能有效地提高覆盖率。实际上这也使我们的测试变得可升级。参数也可以内置到相应的自动操作中以进行数据操作，而不必直接更新脚本。这使我们能够从一个测试脚本获得更多的价值及更快的自动化周转时间。我们目前大约有2000个自动化测试，目前几乎生成了8600个独特的自动化场景。每个自动化脚本约30分钟，累积起来就已经超过了3000小时！虽然参数可以存在于几乎所有事物周围，但知道什么时候使用正确的参数就可以大大提高每个测试配置的价值。仅仅因为一个变量存在并不意味着它就有价值。决定必须根据具体情况来做，且还需要深入了解被测试的功能的专业知识。
说明：
我们的一个用例模型是确保客户能够成功在我们的网站下名片订单。为此，我们必须打开浏览器，导向一个运行环境和区域，并详述送货地址和付款信息。所有这些项目（还有更多）已被参数化，获得了更多可扩展性。我们支持10种浏览器，3种运行环境和26个区域;这一个测试现在只要一个自动化脚本就可以处理所有780种可能的组合。
“测试到软件”的映射
我们的技术部（与内部团队合作）开发了整个代码库的一个3层组件分类框架。这需要超过17万行代码并将之划分为约500个组件。质量工程部采用了这种分类系统作为我们测试案例部的等级制度。我们的测试可按测试范围的基础归于任何等级的分类。测试分类使所有权能被分配给测试组，建模组和模板组。当测试设计人员对内容或执行特定的测试有疑问时，这就给了他们一个明确的方向，都是免费的。许多其他进程映射到这个分类，以及包括我们的工作管理的JIRA票。这就能通过像基于风险的优先级机制快速优先拥有不同软件组件的测试，。
说明：
下面左侧是VISTAPRINT软件分类的样品，右侧是相应的测试等级结构。测试存储在对应于测试检验范围的目录里。这种分类法渗透于我们整个功能的工具集（ JIRA ，Subversion等），使我们能够根据特定需求映射目标测试集并确定覆盖面的差距和目标。
当关于我们的质量风险分析和我们的风险优先级时，这个映射为我们提供了一套确定和策划有效测试的“正确”集的最佳方式用于发布和项目。
图4 技术分类和测试计划的映射
结论
在VISTAPRINT中 ，我们已发现了使用这些测试用例“建筑设计”原则的很多价值。引进构建模块，模板和参数已经减少了我们的测试设计，创建和维护的时间，且显著减少了我们测试库中的零散重复。多亏了孤立特征交互的大量重用，系统更改对我们的测试集的影响比起以前的方法，已经少得多了。利用我们的软件组件分类为我们组织提供了我们测试集和测试下的系统之间长期需要的对齐方式。更深远地，它已经把我们的测试集连接工票，让我们能够基于代码变化针对回归测试来运行。测试对象模型可以使整个测试信息库中的内容更加一致，对于快速智能的造成失败的分类也一样。
我们将继续探索这个领域及其可产生的更多利益。
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) | Powered by Discuz! X3.2 |