测试用例颗粒度说明
软件评估颗粒度级别的简单例子
软件评估颗粒度级别的简单例子
（实用版）
目录
1.软件评估颗粒度级别的概念
2.软件评估颗粒度级别的简单例子
3.评估颗粒度级别的重要性
4.结论
正文
一、软件评估颗粒度级别的概念
软件评估颗粒度级别是指在软件测试过程中，测试用例所涵盖的功能范围和深度。
评估颗粒度级别通常分为以下几个层次：功能测试、界面测试、单元测试和集成测试。
其中，功能测试关注软件的功能是否符合需求，界面测试关注软件的界面布局和交互是否合理，单元测试关注软件的每个功能模块是否正常运行，集成测试关注软件的各个功能模块之间的协作是否流畅。
二、软件评估颗粒度级别的简单例子
以一个库存管理系统为例，假设需要修改一种类型箱子标签的打印格式。
涉及到的打印路径有以下四个：
1.海外制单 - 海外制单界面
2.海外制单 - 自动打印海外发货唛头（标签）
3.海外制单 - 批量打印海外发货唛头
4.海外制单 - 打印海外箱单（按箱）
这四个路径都可以打印同一个模板，但操作方式不同。
在设计测试用例时，需要考虑这四个路径的颗粒度级别。
三、评估颗粒度级别的重要性
评估颗粒度级别对于软件测试至关重要，可以确保测试用例全面覆盖软件的各个功能模块，提高测试的有效性。
合理的颗粒度级别可以降低测试的复杂度，提高测试效率。
同时，评估颗粒度级别有助于更好地安排测试资源，为软件的质量保驾护航。
四、结论
总之，软件评估颗粒度级别是在软件测试过程中，根据测试用例所涵盖的功能范围和深度进行评估的一种方法。
通过合理地选择颗粒度级别，可以提高软件测试的有效性和效率，确保软件质量。
测试颗粒度semi标准
测试颗粒度semi标准
"semi"标准是指将测试用例的颗粒度划分为三个级别：全路径级别、问题级别和操作级别。
1. 全路径级别：测试覆盖的是系统中的所有路径，即从系统的
起点到终点经过的所有路径。
这种级别的测试用例一般较少，但能够
全面地测试系统的功能和性能。
这些用例通常是基于系统需求和功能
规范编写的。
2. 问题级别：测试覆盖的是系统中的不同问题和错误。
这些问
题可以是功能上的错误、性能上的问题、安全性问题等。
这种级别的
测试用例一般较多，可以覆盖系统中的各种错误情况。
3. 操作级别：测试覆盖的是系统中的不同操作和功能。
这些操
作可以是用户界面上的点击、输入等，也可以是系统内部的功能和算法。
这种级别的测试用例较细粒度，可以测试系统中的每个具体操作。
通过将测试用例的颗粒度划分为这三个级别，可以针对不同的测
试目标进行测试，并确保测试的全面性和有效性。
也可以根据具体需
求和资源情况，灵活地选择不同级别的测试用例进行测试。
如何划分测试用例的粒度
我们是不太可能在一个测试用例包含所有测试需求的，因为众多的功能以及不同的路径组合将使这样一个测试用例像巨无霸一般，完全不具有可操作性。
——除非您的软件所包含的功能真的又少又简单，不过如果真的有这么一个软件，恐怕也没有测试和发布的必要了。
当然，这也并不是要您走向另一个极端，为需求中定义的每个特性或功能都提供一个甚至多个测试用例。
这里的关键，是要寻找一个合适的度。
有效功能：就是指在被测应用所涉及的实际业务中，当用户在手工状态下进行工作时，整个业务流程中对用户来说，具有实际意义那些功能。
这个功能的特征是当我们把这个功能单独从计算机软件还原到用户的原始手工状态时，它的完成可以作为用户实际业务的一个阶段性结束的标志，而不是一旦从这个业务流程中独立出来就失去了意义。
而该业务完成后，可以为其他用户或业务提供所需要的信息。
这里区分“有效功能”的关键有如下两个：1. 这个功能是可以还原到用户原始的手工业务流程中去的。
我们的计算机和软件，都是为了帮助用户解决手工业务中一些烦琐和低效的问题，而提出的一些忠实于原始工作方法或略有变通的解决方案，并不是要改变用户全部的业务流程。
所以，应该从用户实际业务的角度来判断功能是否有效。
2. 这个功能是否可以标志着用户实际业务的一个阶段性结束？并且这项业务完成之后，被完成的业务实体是否可以交付给其他用户或业务以供完成下面的工作？为了方便理解，我们可以先看一下下面的例子。
拿我们常见的财务软件来说，当添加一张会计凭证时，通常是需要填写会计科目，在使用计算机完成工作时，我们可以利用软件的功能，从很多备选科目中选择一个自己需要的科目，或者通过科目代码来输入科目。
这项功能很有可能会作为一个特性要求出现在软件需求规格说明书中，那么这个科目的选择或输入是不是一个有效功能呢？让我们试着用上面规则来衡量一下。
首先，这个功能在用户手工业务处理过程中是存在的，不同的是这项功能是在用户填写凭证时，在自己的大脑中完成的——用户会根据需要，在自己记忆的科目中选择合适的填写上去，这项功能节省了用户在记忆大量会计科目时付出的额外劳动。
如何设计简洁高效的自动化测试用例
如何设计简洁高效的自动化测试用例随着软件行业的不断发展，软件测试作为保证软件质量的重要手段变得越来越重要。
而自动化测试作为一种高效的测试方式，受到越来越多的推崇。
但是如何设计简洁高效的自动化测试用例确是一个值得思考的问题。
在设计自动化测试用例的时候，需要考虑以下几个因素：1.测试用例的粒度：测试用例的粒度可以分为三类：粗粒度、中等粒度和细粒度。
粗粒度的测试用例涵盖多个功能，对整个系统或模块进行全面的测试。
中等粒度的测试用例则把多个功能分成多个测试用例进行测试。
细粒度的测试用例对单个功能或一条路径进行测试。
测试用例的粒度需要根据具体情况进行选择，过于细粒度的测试用例虽然可以更好地覆盖代码，但是相应的维护就比较复杂；过于粗粒度的测试用例则可能会遗漏某些问题。
2.测试用例的设计：测试用例需要覆盖所有的场景和可能出现的异常情况，同时需要保证测试用例语义清晰、易于维护，在测试失败时容易定位问题。
此外，测试用例的设计需要注重测试效率和覆盖率之间的平衡，避免无效测试。
在测试用例设计中，可以使用等价类划分、边界值分析、决策表等方法来帮助测试用例覆盖到所有可能出现的场景和问题。
3.测试用例的执行：测试用例的执行需要尽可能地自动化，减少手工测试的工作量。
通过测试驱动开发、持续集成等方式来保证自动化测试的准确性和完整性，同时提高测试效率。
测试用例的执行还需要考虑测试用例的并发执行和并发度，通过合理的并发度来减少测试用例执行时间。
4.测试用例的维护：测试用例的维护需要保证测试用例的可读性和可维护性，同时避免测试用例的“复杂度陷阱”。
测试用例的维护也需要注重测试用例的历史信息和执行结果，及时更新测试用例的执行结果和测试数据。
综上所述，设计简洁高效的自动化测试用例需要考虑测试用例的粒度、设计、执行和维护等因素。
在测试用例的设计过程中，可以使用不同的方法来帮助测试用例更好地覆盖系统的场景和问题；在测试用例的执行过程中，需要使用测试驱动开发、持续集成等技术来保证测试的准确性和完整性；在测试用例的维护过程中，需要保证测试用例的可读性和可维护性，并及时更新测试用例的执行结果和测试数据。
测试颗粒度semi标准
测试颗粒度semi标准摘要：一、引言二、颗粒度的概念与重要性三、测试颗粒度的方法与步骤四、semi标准在颗粒度测试中的应用五、总结与展望正文：一、引言在当今科技飞速发展的时代，软件测试已成为保证软件质量的关键环节。
其中，颗粒度测试是软件测试的重要方面，它有助于发现系统中的潜在问题，确保系统的稳定性和可靠性。
本文将介绍颗粒度的概念、测试方法以及semi 标准在颗粒度测试中的应用，为广大测试人员提供实用的测试技巧。
二、颗粒度的概念与重要性颗粒度是指软件系统中功能模块之间的耦合程度。
高颗粒度意味着模块间相互依赖程度较低，便于维护和扩展。
颗粒度测试旨在检验功能模块之间的交互是否符合预期，确保系统在扩展和修改时不会产生负面影响。
颗粒度的重要性体现在以下几点：1.降低系统复杂度，提高可维护性；2.提高系统稳定性，降低缺陷风险；3.促进团队协作，提高开发效率；4.为后续功能迭代提供坚实基础。
三、测试颗粒度的方法与步骤1.分析系统需求，划分功能模块；2.编写模块间的接口文档，明确交互方式；3.设计测试用例，包括正常场景和异常场景；4.执行测试用例，记录测试结果；5.分析测试结果，排查问题根源；6.修复问题，迭代优化系统；7.验证优化后的系统，确保颗粒度满足要求。
四、semi标准在颗粒度测试中的应用semi（System Engineering Methodology for Integration）标准是一种系统集成方法，旨在提高软件系统的可集成性和稳定性。
在颗粒度测试中，semi标准可应用于以下方面：1.规范模块间接口设计，提高交互可靠性；2.指导测试用例设计，关注潜在风险；3.强化测试过程管理，确保测试质量；4.促进团队沟通，提高协作效率。
五、总结与展望本文从颗粒度的概念、重要性以及测试方法等方面进行了详细阐述，并介绍了semi标准在颗粒度测试中的应用。
希望通过本文，能为软件测试人员提供实用的颗粒度测试技巧，进一步提高软件质量。
测试用例的颗粒度划分
测试用例的颗粒度划分在软件测试中，测试用例的颗粒度划分是非常重要的，它直接影响到测试的覆盖率和效果。
一个好的测试用例应该能够尽可能地覆盖到软件的各个功能和边界情况，以确保软件的质量和稳定性。
而测试用例的颗粒度划分就是将软件的各个功能和边界情况拆分成一个个小的测试点，以便进行详细的测试。
一、整体功能测试用例的颗粒度划分整体功能测试用例是对软件的整体功能进行测试的，它是测试用例的最高颗粒度。
在整体功能测试用例中，可以包括软件的各个功能模块、功能点和交互操作等。
例如，在一个电商网站的整体功能测试用例中，可以包括用户登录、商品浏览、购物车管理、订单管理、支付功能等。
二、模块功能测试用例的颗粒度划分模块功能测试用例是对软件的各个模块进行测试的，它是测试用例的中等颗粒度。
在模块功能测试用例中，可以包括模块的各个功能点、输入输出和异常情况等。
例如，在一个电商网站的用户登录模块功能测试用例中，可以包括正确的用户名和密码登录、错误的用户名和密码登录、用户名为空登录等。
三、接口测试用例的颗粒度划分接口测试用例是对软件的各个接口进行测试的，它是测试用例的较小颗粒度。
在接口测试用例中，可以包括接口的输入输出、参数验证、异常情况等。
例如，在一个电商网站的支付接口测试用例中，可以包括正常支付、支付金额为空、支付密码错误等。
四、边界测试用例的颗粒度划分边界测试用例是对软件的边界情况进行测试的，它是测试用例的最小颗粒度。
在边界测试用例中，可以包括边界值、边界条件和边界情况等。
例如，在一个电商网站的商品库存管理功能的边界测试用例中，可以包括库存为0、库存为1、库存为最大值等。
五、异常测试用例的颗粒度划分异常测试用例是对软件的异常情况进行测试的，它是测试用例的较小颗粒度。
在异常测试用例中，可以包括各种异常情况和错误处理等。
例如，在一个电商网站的订单管理功能的异常测试用例中，可以包括订单不存在、订单已取消、订单已完成等。
六、性能测试用例的颗粒度划分性能测试用例是对软件的性能进行测试的，它是测试用例的较小颗粒度。
软件评估颗粒度级别的简单例子
软件评估颗粒度级别的简单例子摘要：I.引言- 介绍软件评估颗粒度级别的重要性II.颗粒度级别的定义和分类- 定义软件评估颗粒度级别- 介绍常见的颗粒度级别分类III.颗粒度级别与软件测试的关系- 颗粒度级别对软件测试的影响- 不同颗粒度级别下的软件测试策略IV.实际案例分析- 举例说明不同颗粒度级别的应用- 分析案例中软件测试的实施情况V.总结- 强调颗粒度级别在软件评估和测试中的重要性- 提出针对不同颗粒度级别的软件测试建议正文：软件评估颗粒度级别是软件开发和测试过程中一个重要的概念，它直接影响到软件的质量和稳定性。
颗粒度级别定义了软件测试的深度和广度，从而影响了软件的可靠性和健壮性。
本文将详细介绍软件评估颗粒度级别的定义和分类，探讨颗粒度级别与软件测试的关系，并通过实际案例分析，说明不同颗粒度级别下的软件测试策略。
首先，我们需要了解颗粒度级别的定义和分类。
颗粒度级别是指软件测试过程中，对软件功能的细分程度。
根据测试颗粒度级别的不同，可以将软件测试分为功能测试、模块测试、接口测试和单元测试等。
其中，功能测试是对整个软件系统进行测试，模块测试是对软件系统中的各个模块进行测试，接口测试是对模块之间的接口进行测试，单元测试是对软件系统中的最小可测试单元进行测试。
其次，颗粒度级别与软件测试有着密切的关系。
颗粒度级别决定了软件测试的深度和广度，进而影响到软件的质量和稳定性。
在软件测试过程中，我们需要根据颗粒度级别选择合适的测试策略。
例如，对于功能测试，我们需要对整个软件系统进行测试，确保各个模块之间的协同工作；对于模块测试，我们需要对软件系统中的各个模块进行测试，确保模块功能的正确实现；对于接口测试，我们需要对模块之间的接口进行测试，确保模块之间的数据传输正确无误；对于单元测试，我们需要对软件系统中的最小可测试单元进行测试，确保代码的正确性。
接下来，我们通过一个实际案例来分析不同颗粒度级别下的软件测试策略。
冒烟测试用例的粒度
冒烟测试用例的粒度引言概述：冒烟测试是软件测试中的一种重要方法，用于验证软件在最初阶段的基本功能和稳定性。
冒烟测试用例的粒度是指测试用例的细化程度。
合理的冒烟测试用例粒度可以提高测试效率和准确性。
本文将从五个大点阐述冒烟测试用例的粒度，每个大点包含3-5个小点详细阐述，最后进行总结。
正文内容：1. 冒烟测试用例的粒度对测试范围的确定有影响1.1 粗粒度的冒烟测试用例可以覆盖更广泛的功能模块- 通过选择关键的功能模块进行测试，可以快速验证整个软件的基本功能是否正常。
- 能够及早发现系统中的关键问题，提前预防可能的风险。
1.2 细粒度的冒烟测试用例可以更准确地定位问题- 通过细化测试用例，可以更精确地定位软件中出现的问题，加快问题的解决速度。
- 可以更好地发现隐藏的问题，提高软件的稳定性。
2. 冒烟测试用例的粒度对测试时间的影响2.1 粗粒度的冒烟测试用例可以缩短测试时间- 选择关键的功能模块进行测试，可以减少测试用例的数量，从而节省测试时间。
- 可以在软件开发的早期阶段快速验证软件的基本功能，提高测试效率。
2.2 细粒度的冒烟测试用例可能增加测试时间- 细化测试用例会增加测试的复杂度，可能需要更多的测试资源和时间。
- 需要更多的测试用例来覆盖各个细节，增加了测试的工作量。
3. 冒烟测试用例的粒度对测试结果的可靠性有影响3.1 粗粒度的冒烟测试用例可以快速判断软件的整体质量- 通过对关键功能模块的测试，可以快速了解软件的整体质量，判断是否满足基本需求。
- 可以提前发现系统中的严重问题，避免后续测试过程中的不必要工作。
3.2 细粒度的冒烟测试用例可以更准确地评估软件的质量- 细化测试用例可以更全面地覆盖软件的各个细节，提高测试结果的可靠性。
- 可以发现软件中的潜在问题，提供更准确的测试报告。
4. 冒烟测试用例的粒度对测试资源的利用有影响4.1 粗粒度的冒烟测试用例可以节省测试资源- 通过选择关键功能模块进行测试，可以减少测试用例的数量，节省测试资源。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
测试用例颗粒度说明1.颗粒度与测试的关系如果把测试用例设计得很细，照顾到每一个数据输入、每一个条件、每一个环境、每一个路径，那么测试用例的数量将是巨大的，虽然风险很小很小，但是测试效率会很低，并且测试执行没有思考的空间，可能使测试执行人员变得呆板（除非全部测试自动化），不需要创造力、思考。
测试用例设计很粗，测试效率可能比较高，测试人员有一个发挥的空间，使测试更有趣，但这依赖于个人的责任感和能力，风险大得多。
2.颗粒度的大小取决与以下三点1、“重要功能”、“特殊功能”颗粒密集度高，“通用功能”可以试用通用测试粒度，密集度应该可以大致界定。
个人认为，假如你非要为了一个字体的样式而写了一大长串的测试用例，那么这个颗粒度就毫无意义了。
2、颗粒度的大小还取决与客户对“产品”的要求。
测试有一个难题是测试的精度，或者说颗粒度的定义，不要说一个程序，就算是一个简单的登录都可以写出几乎无穷尽的测试用例，所以你需要指明功能、性能需求，使用环境等，并说明对缺陷容忍的限度。
才好依据最终的需求来定义测试的颗粒度，也才好写测试用例，总之，客户的要求越详细所得到的测试用例越准确。
如果客户跟你说这个地方你必须仔仔细细的测试。
那么我们在写测试用例的时候。
这个颗粒度一定要小了。
3、一般功能颗粒密集度可能会根据项目或是时间来确定。
如果时间充裕颗粒度可以适当小。
4、粒度取决于测试的种类，一般用验收测试,是项目测试中颗粒度比较大。
系统测试颗粒度相对较小。
3.有效度量测试用例条件：1、颗粒度可以跟代码行数对应：一般来说代码量越大，内部逻辑就越复杂，出现bug 的的可能性也越高。
对应的测试粒度也越小。
2、测试团队内部对粒度达成一致，适当把握颗粒度：明确测试用例编写的颗粒度，大家都有这种感觉，你写测试用例，你测试这个产品的时候，你十条测试用例就测试完了，有人写三十条，你就觉得奇怪，我觉得十条已经是局限了，怎么你能写到三十条，你去看他的用例，发现这也能算一条，这是组织内部测试用例颗粒度没有达成一致。
3、颗粒度要适合业务的需要：各公司测试用例设计的粒度不同，适合自己的需要，适合业务的需要即可，测试用例的数量统计方法，我觉得说明不了测试作得是否专业。
4、测试用例设计的覆盖率和有效性，才是说明测试是否专业的依据之一：对于进行工作量的统计还可以，不过用例还是不能简单的以数量来看，设计一个很简单的功能点的用例可能很容易，可能一天能设计十个这样的用例，但是对于一个相对复杂的功能，可能一天才能准备两个用例，光靠数量是说明不了问题的。
测试用例之度——系列之颗粒度测试用例是测试工作的核心。
测试工作是讲究投入产出比的工作，这也是测试用例设计的指导思想。
测试用例有度的概念，正如亚里士多德在《伦理学》中讨论道德为例：道德意味着过与不及之间的状态。
面向测试用例，网上流传着这么一句话：“不同的机构会有不同的测试目的；相同的机构也可能有不同测试目的，可能是测试不同区域或是对同一区域的不同层次的测试”下面就列举测试用例设计的方方面面，看不同的团队，不同的测试目的，如何把握测试用例设计之度。
颗粒度：颗粒度的粗细，有无标准？什么是粗？什么是细？1、以功能点划分？仅仅覆盖所有的功能性需求为粗？仅仅正向覆盖所有的功能需求（功能、性能）为粗？正向/负向覆盖所有的功能需求（功能、性能）以及正向覆盖性能需求为粗？正向/负向覆盖所有的需求为细？覆盖到产品包，涵盖兼容性、升级、安装、易用性为细？2、以STEP划分？每条用例有一个STEP为粗，三？五？十为细？以上为细？以测试设计思路的体现？只采用正向为粗？只采用正/负向为粗？考虑应用场景为细？考虑业务逻辑为细？3、以数量级？百条？千条？万条？4、以数据覆盖？等价类是粗？穷举是细？每个人、每个机构判定测试用例粗细的标准都不一样，没有标准的答案。
所以测试用例颗粒度的粗细，本身就是一个相对而言的标准。
尝试用图示来表示颗粒度粗细的常规概念：测试用例颗粒度粗、细的特点是什么？用例设计分析：粗颗粒度面向宏观，面向正向的功能点、大的功能模块和整体性，体现测试用例的设计思路；细颗粒度面向微观，面对具体的一个个功能点的正向/负向逻辑，体现测试用例的细节和完备性。
面对测试执行人员：粗颗粒度用例不容易被测试新手执行，因为很多约定成俗的操作、现象，甚至行业术语都不清楚。
细颗粒度用例相对较易被测试新手执行。
覆盖度：粗颗粒度覆盖度可能小于细颗粒度用例（粗颗粒度只覆盖全部正向和部分负向，细颗粒度覆盖全部正向、负向、其他等）；但还有一种可能性，就是粗细用例均覆盖全面，但是深度不同。
类似下雨的降雨量不同，对农作物（产品）的意义不同。
可维护性：毫无疑问，测试用例和需求的匹配，测试用例本身的维护是大多数团队的工作难点重点，粗颗粒度便于维护，方便和需求保持高度一致；细颗粒度用例，越细越不容易维护，维护成本过大，特别是需求频繁变更会导致不可维护。
类似的概念，比如自动化测试环节，GUI不停改变导致的脚本重写类似。
时间：粗颗粒度构架和评审的时间较短，适合周期较紧的项目；细颗粒度构建和编写的时间较长，适合周期宽松或更倾向于质量的项目。
资源：粗颗粒度占用资源较少（人力、评审、会议室等），适合小团队或同一团队多项目模式；细颗粒度占用资源较多，适合大团队或单一项目模式。
风险：毫无疑问，粗颗粒度用例的风险是漏测，存在很大概率漏测的风险，依赖于测试人员的个人素质；细颗粒度也存在漏测，不过相对更可能是测试人员自己的想当然跳过用例不执行。
细颗粒度用例最大的风险就是可维护性，或者投入产出比。
测试用例颗粒度常规应用场景的枚举：上面分析了很多测试用例颗粒度粗、细的特点，那么，常规的测试来讲，如何大致定位测试用例颗粒度的粗细呢？下面以单一的应用环境来体现。
还是要强调那句话：相同的机构也可能有不同测试目的，可能是测试不同区域或是对同一区域的不同层次的测试。
单一条件：1、时间因素：时间短、项目紧、编写用例评审时间较短时，适合粗颗粒度用例。
项目周期较长时，适合细颗粒度用例。
比如规划六个月的项目，计划阶段和设计阶段有一个半月，测试前期进入，有足够的时间来进行人员培训、测试用例编写，需要细颗粒度。
如果项目是一个月，测试准备时间只有五个工作日，那么可能在第三天就要完成第一轮的测试用例评审，建议以粗颗粒度为主，覆盖功能和体现思路。
2、项目人员：测试人员中熟手多，思路和基础技能扎实，或测试人员构成责任心高时，可以采用粗颗粒度用例。
测试人员新手多，需要再指导下进行基础测试工作，或责任心一般时，需采用细颗粒度用例。
测试人员熟手和新手的区别，大家一目了然。
在这里，特意把责任心作为测试用例编写粗细的一个判别标准。
实际上，测试人员的职业素质中，就有责任心一项，这种品质方面的要求因人而异——而且每个人都肯定对自己的责任心还自我感觉良好。
举个例子，比如安装测试：粗的写法：在微软的各种操作系统下进行遍历安装，确认setup安装成功。
——那么责任心好的人，可能会去翻阅规格书，确认setup支持的操作系统，再依次安装测试。
责任心一般的人，可能就想当然的认为visia这种过渡版本很少人用/server 2000 不是个人用户的菜，就直接跳过这两种系统。
所以面对责任心一般的人，就必须写成细的用例：安装测试：A、在window XP 的SP2 环境下安装；B、在xp的SP3 环境下安装；C、在win server 2000 下安装；……。
3、项目质量性质项目质量要求一般，或项目为过渡项目，生命周期短；项目为临时项目时，可采用粗颗粒度用例。
项目质量要求高，客户或公司对质量的定位为第一位，品牌工程项目，采用细颗粒度用例。
难道不是所有的项目都是高质量高要求的么？当然不是。
不同国家和民族的人对质量的要求是不一样的：美国是够用就好，德国是精益求精，中国是当场不挂就行。
不同产业链位置的公司对质量要求是不一样的：顶级公司做完美的产品，中级公司做性价比高的产品，底层公司做廉价的产品。
不同定位的公司对质量的要求是不一样的：在火车站门口的饭店吃的是客流量，在市区偏远地方的饭店吃的是回头客。
不同目的的单子对质量的要求是不一样的：做账拉回扣的虚项目，中标后无人使用，三年后设备升级，质量就没有要求。
做重点项目，质量要求苛刻等。
所以，肯定会有不同的项目质量性质。
也自然有不同的测试策略和测试目的，顺序导出的就是不同颗粒度的测试用例。
4、资源配置：资源配置较少，无法实现测试用例的细化时，可以采用粗颗粒度的测试用例。
资源配置较多，可满足用例编写、评审、修订的交叉进行时，可采用细颗粒度。
举例：如果测试人员配置较少，一共就三五个人，每人负责一个项目，彼此没有时间去做评审，甚至项目都存在临时增多的现象，就无从谈起测试用例的细化，甚至粗颗粒度都较难实现，只能拉一个测试大纲出来。
或者测试团队有十多个人，但是项目是流水式过来的。
需求、开发、测试是流水线模式处理大批量的项目，无法做到一个项目的全流程参与时，也很难展开测试用例评审、修订以致细化事宜。
5、需求变更：需求变更较多时，建议采用粗颗粒度的用例，可较灵活的覆盖需求。
经过一轮轮的评审，等需求基线化之后，在实际的滚动测试中，在逐步细化用例——根据项目实际情况。
需求变更较少时，或需求变更波及较小，不是系统设计框架的频繁改动——具体的标准需要不同行业产品的评估，可对应较大的细化测试用例变更量。
举例：一个需求，粗颗粒度的用例为100条，细颗粒度的用例为10000条。
此需求变更，如果要修改粗颗粒度的用例，只需要修改10条；修改细颗粒度的用例，牵扯到细化的交叉逻辑，需要审阅2000条用例并可能修改1200条。
如果测试用例修改人非测试用例编写人，则修改时间还可能延长1.3倍。
6、项目对象：如果项目/产品最终面对的客户是特定人员、专业人员、技术人员、培训后的操作员，可以采用粗颗粒度的用例。
如果项目/产品最终面对的客户是广义的使用群体、人民大众消费者，要采用细颗粒度的用例。
面向专业人员的项目/产品，测试倾向于正向测试，一些问题或使用方式在规定、需求之外，可以在培训或规范中指定操作模式，或凭借技术人员的功底来避免问题。
面向非专业人员的项目/产品，无法做到培训和操作约定，各种稀奇古怪的使用方法，操作习惯，所以更倾向于细颗粒度，覆盖负向和随机操作的测试用例。
7、测试团队素质：团队个体素质较高，可适应粗犷、敏捷的风格时，可以采用粗颗粒度的用例。
团队处于成立初期或磨合期，需要细化的规则约定来指导时，采用细颗粒度的用例。
8、公司决策投入：公司对测试工作的投入，对产品质量的要求，对行业节奏的把握。
具体分析，可参考项目质量性质部分的论述。
测试用例粗细的另外一个概念：用例的文字描述粗细。
（旧文贴成）文档分为好多种，在后面写测试用例的时候你们会遇到类似的颗粒度的问题。