测试用例设计－－神话，现实和Soft Touch，造就非凡

Raluca Gagea在软件测试行业工作了5年，至今仍热爱着它。Raluca最初是在一个公司开发一个计费和客户服务平台中负责各种测试活动，她由此获得了测试经验。这引发了她对需求、测试分析、测试用例设计的兴趣。获得必要的信心和质量驱动的一组动作后，她开始在一家外包公司工作，在那她一直参与各种项目，现在已经聚集了测试服务元素的不少新经验。过去的一年，她在一家信用卡处理公司就职，她试着实施各种测试过程，包括亲身卷入许多测试阶段。一步一步地，她正迈进开发过程的测试管理角色。除了她项目的相关活动， Raluca也很乐意协助公司内部的一些研究组（一个是测试分析&设计组，一个是测试管理组）以及针对这些主题的其他培训活动。在这里，我们可以分享我们的经验，共同学习，并指导新领导者。

正文：

　　每推出一个产品，我就发现测试用例设计问题越来越具有挑战性，但我已经学会了如何区分神话与现实之间的差异。我曾经遇到的主要的神话都与测试用例的无益，难度，业务类型间的不兼容，测试人员的个人资料或开发进程相关。这就是神话。
　　不幸的是，我发现，与测试用例及需求的可跟踪性相关的一切，仅被视作被一个正式推出过程强制实行的强制性过程，但它不被认为像实际上那样有价值。这就导致了低效率，无知和“匆忙”测试。这就是现实。
　　本文中，我想和大家分享我关于可以使测试用例设计观念非凡的Soft Touch的意见。

何时适合开始考虑测试用例？
　　测试用例不仅仅是用来测试各种flow的一些句子。
　　测试用例是我们通过衡量需求覆盖范围及它们在开发过程中的每一点的状态推出产品时证明信心的方法——要求是否被足够多的测试用例覆盖，某一点上的测试执行状态是否像期望的或计划的那样。
　　有了这个重大的责任，测试用例需要我们的一点帮助，以便最终能够向我们证明正确的事情。
　　他们需要在我们第一次接触 “未来的产品”时就被考虑在内，而不是一切就绪时。这意味着我们必须用我们收集的每条信息联系他们。首先就看看第一次接触。
　　我们收到一些业务需求，也许不是最终需求，也许在我们与客户首次互动……

?他们是可测试的吗？
　　如果是的话，那么我们可以继续。如果不是，那么我们需要提出问题。
?他们是最终产品或业务的关键功能吗？
　　如果是的话，我们要看哪种需要的测试集？我们如何优先考虑他们？改变花在审查测试用例、执行它们、跟踪执行状态、然后恢复初始优先级上的精力的优先级的几率有多大？

?如何构造需求文档？
　　比方说，我们收到用例模型。我们的第一反应会是用最佳测试场景及备选流，最有可能还是使用拥有大量步骤的独立设计风格（这意味着每个测试用例可以单独被执行而不依赖于其它测试用例）去构建基于由行为驱动的功能流的测试用例。这并没有错，但我们仍然需要考虑一些其他因素，例如：
?对于对客户并不那么重要但其他场景运行却需要的关键功能，我们应该分别对待，用较高优先级而不是最佳测试场景加以标记。
?由一个行动者执行的每个功能流都有需要操作的必要中间层。这意味着我们需要考虑他们的测试——特殊测试用例集，或另一种设计风格或更详细的编写风格。这意味着我们一定要考虑一些技巧去选择最有代表性的测试用例——至少一些等价类划分及其边界值。
?测试用例中有终端到终端的flow可能意味着我们的测试用例有较高冗余度及如果初期常见的步骤之一不工作时阻挡整个执行的高风险。分裂功能组件中终端到终端的flow或许可以更好地工作。
?回归测试 - 在独立的测试用例上更容易做到，而不是在级联的测试用例上。
?我们可能想要或需要自动化flow的某些部分，因为他们中的一些不能进行自动化。这无疑表明了一个有时采用级联方式的详细的编写风格。考虑到终端到终端的flow的初始结构，我们一定会写出另一个可以进行自动化的测试用例——另一项工作，包含目前其他测试用例中的相同信息，再一次造成了冗余。
?有人考虑过非功能性的需求吗？他们最不可能被包含在我们刚刚收到的用例模型里，所以我们需要确保我们有一个他们的测试用例结构。

?我们有开发过程的细节吗？我们是时间固定的吗？
　　我们需要看一看需求，看看如何提供功能，我们是否可以再次使用一些最初创建的测试用例，我们是否可以从一开始就创建一个回归测试集并在开发产品的过程中改进它，这些问题在处理迭代过程中尤为重要，在敏捷开发流程中也是。
　　时间是产品开发的关键因素，因此，如果我们拥有的时间比所需时间少，我们应该考虑将由关键部分驱动的功能集上的测试用例（产品和项目风险都要考虑）分组，使用高水平的编写风格，级联终端到终端的flow，并使关键部分独立。
　　假设关于“接收第一套业务需求时做什么最好”我们已做了我们能做的，我们现在就对他们了解得更多了，比起第一印象有了不同的理解，我们必须切实开始设计和编写它们。
这是一个很好的时机，看看我们应该使用什么工具，并根据测试结构的测试需求评估其兼容性。
　　基本上，从测试用例设计角度来看，在选择测试管理工具时我们应该考虑几件事情：
?它应该有一个明确的测试集，测试用例和测试脚本结构。
?它应允许我们在某些点上可能需要的几乎每一种测试结构：sprints /迭代或其他测试阶段的组织，有许多配置层的分层组织。
?它应当提供用其他方式而非测试集来分组测试用例的可能性，如标签，关键字（用在需要时组织有效的临时测试执行周期）。
?它提供储存各种版本的测试用例的可能性，以及如果他们已被分配给测试执行时更新测试用例的可能性。
?它应该有其他可以服务测试员目标的可配置属性。
?它应该允许将被采用的先决条件或初步措施有一个明确划分。

　　我们谈谈接收业务需求的那一刻。当收到技术规范时，当测试执行获得批准时，当我们时间很紧时该怎么办？在这些时刻，谁在乎测试用例设计呢？理想情况下，我们应该关心它，否则跟踪执行比跟踪业务需求更困难。这就是测试“可理解的”业务需求与压力下时间紧急下的“不可理解的”技术需求的主要区别。尽管团队的一些成员可能最终执行一些像小机器人一类的技术测试用例，我们确知，至少有人分析了这些规范，分割它们，优先考虑他们，其他一些人至少会执行所有的场景一次。
　　强调测试用例设计并不仅仅涉及编写测试用例，我要说，所需测试结构的早期检测要考虑：测试用例的外观及其如何被创建的，花在测试准备上的精力，将被用于选择最具代表性测试的测试测试用例设计技术。这有助于我们为测试流创建基准。此外，这还使得设计如下测试用例更容易：
?由于需求的早期分析而使得检测出误差的概率更大的有效测试用例。
?由于正确识别要遵循的初始步骤，测试集组织和测试用例的设计风格而使之不冗余的测试用例。
?拥有由已辨识的需求和已分配的时间驱动的适当细节的测试用例。
?由于需求和测试用例间的早期相关性使其更容易在需求变化时或一些测试集不再工作并影响产品时识别受影响的区域更容易的可追踪的测试用例。

　　我知道似乎不止靠一个soft touch就可以造就非凡，但最重要的一条是要抛开神话，接受现实，并通过尽快在这个过程中考虑一切所需方面，造就非凡。

　　原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。