1.看项目Schedule：在项目时间紧张的情况下，往往留给测试人员的时间很有限，测试工作的重点就是多测试，早发现问题，这时候我认为测试用例的粒度是可以放粗一些的，但是“粗”不代表随意，虽然可以放“粗”一些，但是要能明确测试要点，分清主次。而在项目时间宽裕的情况下，我还是希望能尽量将测试用例写细一些，因为在写测试用例的同时，也能加深对产品的理解。此外，测试用例的粒度写的细，也能为后期的测试执行提供很大的帮助，为后期确定测试退出提供一定的数据支撑。
2.看项目人员情况：在项目实施过程中，测试用例通常是由具有较丰富测试经验的人来负责并主导编写的。对于测试新人，测试用例往往对新人更快更好的理解产品并完成测试任务提供了非常大的帮助。因此，对于测试新人，希望测试用例粒度细点是可以理解并认可的。而对于测试老鸟，很多时候他们既是测试用例的编写者，同时也是测试用例的执行者，他们往往会有这样一种认知：既然测试用例都是我来执行，我为什么要写的那么细呢?我自己知道不就可以了吗?编写测试用例只是从流程上保证项目质量的手段之一，只要我能将把好质量关，又何必苛求于测试用例的粗细?重要的是测试的思想，而不是测试用例的粗细，测试用例粒度写的太细会占用太多的时间，我为什么不把时间投入到如何提高测试效率等更有价值的事情上去?测试新人有测试新人的道理，而测试老鸟的认知也有其道理，因此，在一个项目组中，如果测试新人所占比例较大，对测试用例的粒度要求还是要尽可能细些，这样可以帮助新人更好的适应项目角色，而对测试老鸟来说，一起教总比一个个教来得更有效率。
3.看客户需求：有些客户，在验收产品的时候，会要求一并提供测试用例以及其执行情况，这种情况下，无论项目Schedule是否紧张，都需要按照客户的要求来完成，因为这也是一项需求。
4.看项目本身是否具有延续性：随着产品的多元化，产品的升级换代速度是很快的，换个UI，换个组织架构，或者重新包装一下就是一个新的产品。这种情况下，总会有些功能模块是一致的，测试用例也是可以复用的。因此，对于一些具有延续性的项目，个人还是认为测试用例的粒度可以尽量细一些，这样有利于知识的传承。而对于那些一次性的项目，测试用例粒度稍微粗些也没关系，只要不影响项目质量就好。
总的来说，个人认为测试用例的粒度并没有特定的标准，要依据项目实际情况而定。测试用例粒度当然是越细越好，但这仅是理想上的，实际上可操作性还是一个大大的问号。在实际执行中，要依据项目的实际情况和公司的相关制度而定，适用的才是最好的，毕竟项目的质量好坏才是最终的目标，如果因为纠结于过程而影响到最终的结果恐怕就不好了，过程是为了服务于结果，可不要陷入为了过程而过程的怪圈。
文章来源于领测软件测试网 https://www.ltesting.net/
