用克隆提高生产率 克隆测试用例的意思是用一个测试用例塑造另一个测试用例。如果一个测试用例适合一个分步用例的需要，同时有很容易被取代的变量，那么该用例是一个很好的克隆候选者。例如，您可能有一个维护一个供应商数据库的测试。很多，但并非所有的步骤，也将适用于托运人数据库。当你通过需求或原型、策划知道该软件的功能以相同的方式工作，您可以克隆测试用例。用克隆方式编写它们并不意味着它们需要一起被测试。您可以象克隆测试用例一样克隆步骤。
文字处理和测试创作软件支持克隆功能，如“Save As”、“Copy”和“Replace。”校对这些用例非常重要，以确保所有原有的提述在克隆中被取代。您还可以在储存的文字和宏上节省时间，但不要试图以牺牲精度为代价使一个尺寸适合所有情况。环顾你的项目以获得克隆的机会，如其他人的用例、用户手册或桌面帮助教程。它们可能正在寻求和你交换测试用例。如果您是管理一个编写组，保持编写者目前的测试资料库，使他们能输送和分享用例。
矩阵也可以克隆，特别是如果组织安排一节是相同的。变量将在字段的名称和数值方面改变。再次，请务必校对新版本。
用测试管理软件提高生产率
软件设计成支持测试创作对编写测试用例是单纯的最大生产率的推进者。它在文字处理、数据库或电子表格软件方面具有这些优势：
● 使编写和概述更容易
● 帮助用例和步骤的克隆
● 易于添加、移动、删除用例和步骤
● 自动编号和重编号
● 易于遵循模板来打印测试
测试创作通常包含在现有的测试管理软件中，也可以定制编写。测试管理软件通常包含更多的功能，而不仅仅是测试创作。当您作为它们的代理而购买时，它们提供了大量的价格优惠。如果您正选购测试管理软件，它应该具有上面所列出的一切可用优点，同时附加了额外的功能：
● 以相同的格式输出测试
● 多用户
● 跟踪测试编写进展、测试进展
● 跟踪测试结果，或转向数据库或缺陷跟踪器
● 连接需求和/或创建覆盖矩阵
● 建立由用例组成的测试集
● 允许灵活的安全性
错误和挑战
七个最常见的测试用例的错误
在每一个编写者的工作中，测试用例缺陷将集中围绕在某些编写错误。如果您正在编写用例或管理编写者，不要等到找到这些错误集前所有用例都已做出。应该每隔一两天就审查用例，寻找使用例难以测试和维护的故障。你将发现的可能是，提高的机会集中在最常见的七个测试用例错误之一：
1. 制作用例太长
2. 不完整的、不正确、或不连贯的组织安排
3. 遗漏某一步
4. 命名的字段已改变或不再存在
5. 不清楚测试者或系统是否做出某活动
6. 不清楚通过或失败的结果是什么
7. 清理失败
为好的测试用例对应挑战
即使您使用最好的技术和标准，面对每一个测试编写工作，你还必须克服同样的挑战。让我们看看对于测试编写面临的共同挑战，并看到它们如何才能通过响应被管理，挽回了更好的质量。典型的挑战通常是强加于项目一级，而且必须在测试管理一级响应。如果它们强加于测试管理一级的编写者，编写者应做出响应。
挑战：需求变化
响应：
1. 最好的防范是被通知到。在编写用例前，在每一个状态上，找出需求变化最大的风险所在。战略上何种用例会和不会受变化的影响。首先写下那些不会的。
2. 建立以后你会返回来并填写的变量或“决定”。
3. 请务必使预算人知道修改已经写好的测试用例的成本。量化每个用例花费多少。
4. 让项目管理设定优先事项，哪些用例应当编写或修订。让他们看到你不能做所有的用例，并请他们来决定他们在哪里有最大的风险。
5. 发表未经修改的不完全正确的测试用例。让测试者标出什么已改变。安排更多的时间来测试每一个用例，加上维护测试时间。
挑战：安排变化
响应：
1. 如果测试的日期提前，让管理方参与测试用例将如何受到影响的选择。在不断变化的需求的挑战中，让他们选择他们想要什么风险。
2. 在工作人员必须作为生产力前，只有时间允许一至二周的训练，才能增加人员，同时只能是您有某人来指导和审查他们的工作。
3. 改变编写用例的顺序，使您首先写那些将优先被测试的。尽量保持用例领先于测试者。
4. 在只有一个目标和组织安排下，即需求正在被测试时，您可以减少测试用例。这不是象临时测试一样糟糕，但管理方应该知道结果并不如用例完成后那么可靠。安排更多的时间来测试这种测试用例，同时安排时间在测试后完成用例。
5. 提议让编写者做测试，并在他们测试时编写。安排更多的时间来测试和测试后完成编写。
挑战：人员更替
响应：
1. 新的人员需要了解目前测试项目的目标、时间安排和组织，如果可能的话，这些应该以书面形式表示。口头介绍会失于混乱。
2. 新的人员应集中于了解软件的业务使用，然后集中于需求和原型。他们可能会写更少的用例，但用例将是正确的。
3. 新的人员应参加有关标准的操作培训，用许多如何应用标准的实际例子。他们的工作首先应被仔细检查。
4. 尽量安排新的人员在一个良好的技术领域，该领域适合他们将要编写的用例。
测试用例资产
保护测试用例资产
保护测试用例价值的最重要的活动是维护它们，使它们可测试。它们应该在每一测试周期后被维护，因为测试者会象发现软件缺陷一样，发现用例的问题。当测试安排被建立时，时间应分配给测试分析员或编写者来修复用例，此时程序员在修复应用程序缺陷。如果它们没有被修复，测试者和编写者将浪费时间在下一周期，来搞清楚是测试用例还是软件的错误。
防止测试用例因缺少的版本和储存失败而丢失或损坏，整个的目的是使这些用例可重复使用。用例的配置管理（CM）应当由组织或项目来处理，而不是测试管理。如果组织不具备这种水平的过程成熟度，测试经理或测试的编写者需要提供这方面支持。无论是项目或测试经理都应该用下面的配置管理标准，来保护宝贵的测试用例资产：
● 命名和编号约定
● 格式，文件类型
● 版本
● 用例需要的测试对象，如资料库
● 只读存储
● 存取控制
● 异地备份
测试管理需要有一个所有测试用例的索引。如果CM不提供，就创建自己的索引。资料库可以对关键项目、软件、测试名称、编号、和需求检索。有一个全文检索功能将更好。
利用测试用例
测试用例作为开发资产已具有超越测试的生命。他们表示出用平白的英语编写软件如何工作的一个完整的图画。即使重点是破坏性的，他们也必须证明所有业务场景按需要工作。通常用例是写给测试者的，测试者是商业用户，所以用例使用真实的世界语言和条目。一套用例对于正在努力学习或出售软件的其他人具有巨大的价值：
● 商业用户
● 技术编写者
● 桌面帮助技术员
● 培训师
● 销售和市场人员
● 网站管理员
所有这些人看到软件取得成功会获得利益，所以也是潜在的测试人员。依靠组织，在测试编写者和这些组之间良好的意愿和开放的沟通下可以大大加快出品和发表的时间。
综述
教授良好的编写技术和建立测试用例标准的过程本身就是一个资产。这从来不是静态的，而必须是动态的教授、运用、审查、测量和改进。本文简要涵盖测试用例质量的过程和标准是什么，如何将其应用到各种测试用例中，如何利用它们来改善可测试性和生产率，如何解决对于测试用例质量的共同面临的挑战，以及如何保护测试用例资产。
