什么是测试用例的设计粒度？

   测试用例的设计粒度一直是个引起争论的话题，有主张详细到具体的操作步骤，也有主张写成测试要点即可。实际上测试用例的粒度主要考虑下面几个因素：
  复用情况：如果随着产品不停得升级，需要设计的详细些，追求一劳永逸，反之仅使用一两次，则没有必要设计的过于详细；
  项目进度：项目时间如果允许可以设计的详细些，反之则能执行即可；
  使用对象：测试用例如果供多人使用，尤其让后参加测试的工程师来执行，则需要设计的详细些。

    如何划分测试用例的粒度？

   我们是不太可能在一个测试用例包含所有测试需求的，因为众多的功能以及不同的路径组合将使这样一个测试用例像巨无霸一般，完全不具有可操作性。——除非您的软件所包含的功能真的又少又简单，不过如果真的有这么一个软件，恐怕也没有测试和发布的必要了。

    当然，这也并不是要您走向另一个极端，为需求中定义的每个特性或功能都提供一个甚至多个测试用例。这里的关键，是要寻找一个合适的度。推荐的方法是：关注有效功能。

    有效功能：就是指在被测应用所涉及的实际业务中，当用户在手工状态下进行工作时，整个业务流程中对用户来说，具有实际意义那些功能。这个功能的特征是当我们把这个功能单独从计算机软件还原到用户的原始手工状态时，它的完成可以作为用户实际业务的一个阶段性结束的标志，而不是一旦从这个业务流程中独立出来就失去了意义。而该业务完成后，可以为其他用户或业务提供所需要的信息。

    这里区分“有效功能”的关键有如下两个：

    1.这个功能是可以还原到用户原始的手工业务流程中去的。我们的计算机和软件，都是为了帮助用户解决手工业务中一些烦琐和低效的问题，而提出的一些忠实于原始工作方法或略有变通的解决方案，并不是要改变用户全部的业务流程。所以，应该从用户实际业务的角度来判断功能是否有效。

    2.这个功能是否可以标志着用户实际业务的一个阶段性结束？并且这项业务完成之后，被完成的业务实体是否可以交付给其他用户或业务以供完成下面的工作？

为了方便理解，我们可以先看一下下面的例子。

拿我们常见的财务软件来说，当添加一张会计凭证时，通常是需要填写会计科目，在使用计算机完成工作时，我们可以利用软件的功能，从很多备选科目中选择一个自己需要的科目，或者通过科目代码来输入科目。这项功能很有可能会作为一个特性要求出现在软件需求规格说明书中，那么这个科目的选择或输入是不是一个有效功能呢？让我们试着用上面规则来衡量一下。

首先，这个功能在用户手工业务处理过程中是存在的，不同的是这项功能是在用户填写凭证时，在自己的大脑中完成的——用户会根据需要，在自己记忆的科目中选择合适的填写上去，这项功能节省了用户在记忆大量会计科目时付出的额外劳动。我们可以认为这个功能是为用户原来的工作提供了一种简便的、变通的方法。

那么这项功能的完成对于用户来说意味着什么呢？我们从上面的描述中可以看到，用户希望软件提供的是可以添加一张完整的凭证这样的功能，而不仅仅是方便填写会计科目。填写会计科目只是用户在添加凭证时的一个步骤，单独把这个功能提取出来对用户来说没有任何实际意义。对于业务流程下游的用户，需要的也不仅仅只是一个会计科目的信息，而是一张包含了会计科目以及其他会计信息的完整的会计凭证，否则就无法进行下面的工作。这样看来，这个功能并不是一个有效的功能，我们可以把它最为需要测试的特性在测试需求中进行描述，却不应该作为一个单独的测试用例出现在我们的测试用例集中。而我们在测试用例中真正关注的，应该是添加会计凭证这个具有实际意义的功能。

另外，我们还需要关注如何将多个相互之间存在依赖关系的功能区分为单个的有效功能。例如，现在有A、B、C三个功能，其中B功能的开始必须依赖于A功能的完成，而且A功能如果出现不同的完成状态，B功能也会做出不同的反应；C功能对B功能的依赖也是如此。那么这时候，我们是否应当将三个相互依赖的功能包含在一个测试用例中呢？这样的做法也不是不可以，但是我们也可以先判断一下，这三个功能是否都是有效功能（您可以使用前面提到的方法来试着评判一下）？如果A、B、C都是独立的有效功能，那么我们可以从上面的描述中发现，它们之间存在的依赖性，可以理解为是一种状态或者说数据的依赖性。后一个功能关心的，是前一个功能最终提供给它的是什么样的“输入”，而不是前一个功能到底作了些什么。这样看来，我们完全可以将它们分别包含在几个独立的测试用例中，而在每个测试用例的开始，把不同的输入作为不同前置条件来描述。

    那么怎样才能把握好测试用例的设计粒度的尺度呢，这就需要在实践中不断的摸索总结经验了。