Jeremy Ristau目前是VISTAPRINT的高级质量工程师，掌管网站可交付产品的质量并推销公司网页属性的性能。 他在确保重新架构项目及新功能的质量结果方面有超过5年的专业经验。 他对需求采集，测试文档和管理，及试验周期的优先回归测试有着浓厚的兴趣。

Harish Narayan目前是VISTAPRINT的技术董事，专注于将组织转换成一个灵活的技术功能。 他的工作职能是开发专业的、的技术，以及保证全企业流程和性能的改进。 他热衷于在组织里灌输一种质量文化，他已是包括电子商务，电信，金融服务在内的各种不同行业的可靠的贸易伙伴。 他也有战略规划，全球运营，项目管理，绩效管理，团队建设方面的经验，他已经成功地在各种合约中利用了这些经验。 他经常演讲和写文章，之前还曾为Testing Experience撰写过文章。

　　测试用例和测试资产通常随着时间而增长，在许多情况下，它们的增长没有得到很好的管理。我们认为，需要对测试用例的效率和效益进行管理，其方法与管理代码资产十分相似。
所以，你问过自己以下几个问题了吗？
●你希望尽量减少测试维护时间吗？
●你的测试集里的测试中有重复的设置步骤吗？
●全面彻底的改变对你的测试有不利影响吗？
●你的测试集过于零散/增长过快吗？
●你的测试集和测试下的系统之间不对齐吗？
　　如果其中的一个或多个问题你回答“是”，这篇文章会使你更加了解如何才能够更好地回答这些问题并管理测试用例资产。我们将在某些章节加上一些用例（斜体）作为例子来说明我们的测试用例架构设计方法如成功地在VISTAPRINT中被利用的。

　　背景及需要
　　VISTAPRINT一直通过以合理的价格提供专业的营销产品和服务给世界各地超过50万的微型企业，使它们让人印象深刻并拥有脱颖而出的机会。
　　我们是一个电子商务营销公司，拥有超过25个本地化的国际网站，每3周发布整个代码库将其投入生产。每个发布周期包括1周的需求审核，3周的开发，及 1周的全系统测试。这个5周的周期被2周覆盖，使我们能够每3周发布一个新产品。
　　我们当前的代码库中缺乏某些架构原则，比如关注点和服务导向的分离，所以大多数测试是通过一个完整环境的UI界面完成的。丰富的UI级自动化的存在会自动抄录手动操作。
　　自动化由测试编写质量工程师外的开发团队创建和管理。采用测试用例设计架构的想法来源于提高我们的测试管理流程的需求。
　　以前在组织中，内联步骤文档足够了，但是一旦开始运行大规模的测试脚本，我们会遇到问题。虽然许多测试想要执行完全一样的步骤，但是每个测试都有其独特的文档。
　　记录步骤的变化难以保持是一致且新的。这个过程是无效的且维护它的成本会不断增加。此外，起草新测试时，设置步骤的知识需要传播给每个人，以便更正记录。即使测试的创建者只是想达到让特性“通过”测试的目的，这也是必要的。这引起测试创建者和特性所有者之间很多不必要的来回交流。
　　我们提出三点以增加质量组织的测试资产集的质量和可扩展性。这三点如下，本文的重点是第三点：
1.优质的平台和工具——一个全面的平台，它拥有一个完整的与我们的自动化平台无缝协作测试管理系统。
2.优质的工程培训和技能提升——一个扩展组织的技能使之更擅长利用测试设计和相关的做法的程序。
3.可扩展性的测试设计增强——我们推广我们测试资产的重用和可扩展性的方法，本文的重点是不断向前推进。以这种方法，我们的测试案例设计现在专注于把某种软件架构和设计原则用到测试用例的创建和维护过程中。
这些原则包括：
●定义测试对象模型
●孤立的，可重用的构建模块和模板
●测试参数
●一个“从测试到软件”的映射

　　定义测试对象模型
　　传统上，一个测试，被认为是包括某种验证形式的一组执行步骤。但是，比起你看到的，测试对象还有更多。测试对象模型需要测试并剖析其组成部分：描述符，步骤和可连接的业务对象。
●描述符表示存在于所有测试中的数据集。包括标题，测试所有者，创建日期等。
●步骤表示如用户描述与系统的行为交互，功能验证也包含于此。
●可连接的业务对象是任何有用的外部对象。这包括自动化脚本，其中包含了执行正在测试中的底层系统的代码。