3、项目质量性质
　　项目质量要求一般，或项目为过渡项目，生命周期短；项目为临时项目时，可采用粗颗粒度用例。
　　项目质量要求高，客户或公司对质量的定位为第一位，品牌工程项目，采用细颗粒度用例。
　　难道不是所有的项目都是高质量高要求的么？当然不是。
　　不同和民族的人对质量的要求是不一样的：美国是够用好，德国是精益求精，中国是当场不挂行。
　　不同产业链位置的公司对质量要求是不一样的：公司做完美的产品，中级公司做性价比高的产品，底层公司做廉价的产品。
　　不同定位的公司对质量的要求是不一样的：在火车站门口的饭店吃的是客流量，在市区偏远地方的饭店吃的是回头客。
　　不同目的的单子对质量的要求是不一样的：做账拉回扣的虚项目，中标后无人使用，三年后设备升级，质量没有要求。做重点项目，质量要求苛刻等。
　　所以，肯定会有不同的项目质量性质。也自然有不同的测试策略和测试目的，顺序导出的是不同颗粒度的测试用例。
　　4、资源配置：
　　资源配置较少，无法实现测试用例的细化时，可以采用粗颗粒度的测试用例。
　　资源配置较多，可满足用例编写、评审、修订的交叉进行时，可采用细颗粒度。
　　举例：如果测试人员配置较少，一共三五个人，每人负责一个项目，彼此没有时间去做评审，甚至项目都存在临时增多的现象，无从谈起测试用例的细化，甚至粗颗粒度都较难实现，只能拉一个测试大纲出来。
　　或者测试团队有十多个人，但是项目是流水式过来的。需求、开发、测试是流水线模式处理大批量的项目，无法做到一个项目的全流程参与时，也很难展开测试用例评审、修订以致细化事宜。
　　5、需求变更：
　　需求变更较多时，建议采用粗颗粒度的用例，可较灵活的覆盖需求。经过一轮轮的评审，等需求基线化之后，在实际的滚动测试中，在逐步细化用例——根据项目实际情况。
　　需求变更较少时，或需求变更波及较小，不是系统设计框架的频繁改动——具体的标准需要不同行业产品的评估，可对应较大的细化测试用例变更量。
　　举例：一个需求，粗颗粒度的用例为100条，细颗粒度的用例为10000条。此需求变更，如果要修改粗颗粒度的用例，只需要修改10条；修改细颗粒度的用例，牵扯到细化的交叉逻辑，需要审阅2000条用例并可能修改1200条。
　　如果测试用例修改人非测试用例编写人，则修改时间还可能延长1.3倍。
　　6、项目对象：
　　如果项目/产品终面对的客户是特定人员、专业人员、技术人员、培训后的操作员，可以采用粗颗粒度的用例。
　　如果项目/产品终面对的客户是广义的使用群体、人民大众消费者，要采用细颗粒度的用例。
　　面向专业人员的项目/产品，测试倾向于正向测试，一些问题或使用方式在规定、需求之外，可以在培训或规范中指定操作模式，或凭借技术人员的功底来避免问题。
　　面向非专业人员的项目/产品，无法做到培训和操作约定，各种稀奇古怪的使用方法，操作习惯，所以更倾向于细颗粒度，覆盖负向和随机操作的测试用例。
　　7、测试团队素质：
　　团队个体素质较高，可适应粗犷、敏捷的风格时，可以采用粗颗粒度的用例。
　　团队处于成立初期或磨合期，需要细化的规则约定来指导时，采用细颗粒度的用例。
　　8、公司决策投入：
　　公司对测试工作的投入，对产品质量的要求，对行业节奏的把握。具体分析，可参考项目质量性质部分的论述。
　　测试用例粗细的另外一个概念：用例的文字描述粗细。
　　（旧文贴成）
　　文档分为好多种，在后面写测试用例的时候你们会遇到类似的颗粒度的问题。
　　第一类是写给自己，以及懂这个技术的，差不多水平的同事看的。这样只需要大致的描述核心关键点可以。
　　第二类是给技术一般的员工，但是有一定底子的人看的，这样基本的概念不用描述，整体步骤描述清楚可以。
　　第三类是给不懂技术，只会看图一步步操作的外行看的，这样要详细细致的描述基本概念，步步都截图，傻瓜式的对比参照的搞过去。
　　举个例子，使用ping 命令
　　第一类写法：如果网络不通，使用ping命令测试一下网络是否通畅。
　　第二类写法：如果网络不通，在cmd模式下，使用ping X.X.X.X 的命令格式，测试一下网络是否通畅。
　　第三类写法：如果网络不通，点击开始，选择运行，然后在运行框里输入cmd，然后在弹出框里面，使用ping X.X.X.X 的命令格式，如果显示Reply from X.x.x.x bytes=32 time=3ms TTL=64，是通畅，其他显示是不通畅。