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

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

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

　　版权声明：本文出自 SPASVO泽众软件测试网：http://www.spasvo.com/news/html/2014327150011.html

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