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

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

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

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

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