测试用例的粒度：每个测试用例所覆盖的测试范围或者期望结果的多少。

　　也谈测试用例的粒度

　　1.看项目Schedule：在项目时间紧张的情况下，往往留给测试人员的时间很有限，测试工作的重点是多测试，早发现问题，这时候我认为测试用例的粒度是可以放粗一些的，但是“粗”不代表随意，虽然可以放“粗”一些，但是要能明确测试要点，分清主次。而在项目时间宽裕的情况下，我还是希望能尽量将测试用例写细一些，因为在写测试用例的同时，也能加深对产品的理解。此外，测试用例的粒度写的细，也能为后期的测试执行提供很大的帮助，为后期确定测试退出提供一定的数据支撑。

　　2.看项目人员情况：在项目实施过程中，测试用例通常是由具有较丰富测试经验的人来负责并主导编写的。对于测试新人，测试用例往往对新人更快更好的理解产品并完成测试任务提供了非常大的帮助。因此，对于测试新人，希望测试用例粒度细点是可以理解并认可的。而对于测试老鸟，很多时候他们既是测试用例的编写者，同时也是测试用例的执行者，他们往往会有这样一种认知：既然测试用例都是我来执行，我为什么要写的那么细呢?我自己知道不可以了吗?编写测试用例只是从流程上保证项目质量的手段之一，只要我能将把好质量关，又何必苛求于测试用例的粗细?重要的是测试的思想，而不是测试用例的粗细，测试用例粒度写的太细会占用太多的时间，我为什么不把时间投入到如何提高测试效率等更有价值的事情上去?测试新人有测试新人的道理，而测试老鸟的认知也有其道理，因此，在一个项目组中，如果测试新人所占比例较大，对测试用例的粒度要求还是要尽可能细些，这样可以帮助新人更好的适应项目角色，而对测试老鸟来说，一起教总比一个个教来得更有效率。

　　3.看客户需求：有些客户，在验收产品的时候，会要求一并提供测试用例以及其执行情况，这种情况下，无论项目Schedule是否紧张，都需要按照客户的要求来完成，因为这也是一项需求。

　　4.看项目本身是否具有延续性：随着产品的多元化，产品的升级换代速度是很快的，换个UI，换个组织架构，或者重新包装一下是一个新的产品。这种情况下，总会有些功能模块是一致的，测试用例也是可以复用的。因此，对于一些具有延续性的项目，个人还是认为测试用例的粒度可以尽量细一些，这样有利于知识的传承。而对于那些一次性的项目，测试用例粒度稍微粗些也没关系，只要不影响项目质量好。

　　总的来说，个人认为测试用例的粒度并没有特定的标准，要依据项目实际情况而定。测试用例粒度当然是越细越好，但这仅是理想上的，实际上可操作性还是一个大大的问号。在实际执行中，要依据项目的实际情况和公司的相关制度而定，适用的才是好的，毕竟项目的质量好坏才是终的目标，如果因为纠结于过程而影响到终的结果恐怕不好了，过程是为了服务于结果，可不要陷入为了过程而过程的怪圈。

　　实际上测试用例的粒度主要考虑下面几个因素：

　　复用情况：如果随着产品不停得升级，需要设计的详细些，追求一劳永逸，反之仅使用一两次，则没有必要设计的过于详细;

　　项目进度：项目时间如果允许可以设计的详细些，反之则能执行即可;

　　使用对象：测试用例如果供多人使用，尤其让后参加测试的工程师来执行，则需要设计的详细些。

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

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

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

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

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

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

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

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

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

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

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

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

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