Test use caseis to test theworkingcore. Stress testing is to work output ratio, which is the guiding ideology of the design of test cases.
The concept of test cases, as Aristotle discuss ethics in the "ethics" in an example: between the moral status means that excess and deficiency. Test case for, circulated on the Internet such a sentence: "Different agencies have different testing purposes; the same institutions may have different testing purposes, may be tested in different regions or different levels of tests on the same area."
Here lists all aspects of test case design to see different teams, different testing purposes, how to grasp the degree of test case design.
Graininess:
Particle size of thickness, with or without standard? What is thick? What is the fine?
1, a functional point divide?
Just to cover all the functional requirements for the rough?
Only forward cover all functional requirements (features, performance) as a crude?
Positive / negative to cover all functional requirements (features, performance) and forward demand cover performance of crude?
Positive / negative to cover all the needs for the fine? Cover package, covering compatibility, upgrade, installation, ease of use is fine?
2, STEP divide?
Each use case has a coarse STEP three? Fives? And ten is the fine? The above is fine?
To reflect the test design ideas?
Forward to using only coarse? Using only positive / negative for the crude? Consider scenarios fine? Consider the business logic is fine?
3, in order of magnitude?
One hundred? One thousand? Ten thousand?
4, the data cover?
Equivalence class is rough? Exhaustive is fine?
Each person, each organization determine the thickness of the test standards are not the same, there is no standard answer. So test the thickness of the particle size, the standard itself is a relative term.
Conventional attempts to represent diagrammatically the concept of particle thickness:
Coarse granularity test case, what fine characteristics?
Use Case Design Analysis:
Coarse-grained oriented macro, function points for positive large and integrity function modules, test cases reflect the design ideas; for fine-grained microstructure, the face of the positive / negative logic of a particular function points, reflect the details and the completeness of the test cases.
Executives face test:
Examples of the use of coarse particles can not be easily performed test novice, because many agreed ChengSu operation, a phenomenon, even jargon are unclear. Examples of the use of fine particles is relatively easy to test execution novice.
Coverage:
Coarse particles may be less than the degree of coverage of the fine particles (the fine particles of the coarse-grained coverage covers only part of all positive and negative whole positive, negative, or other) use cases; however, there is a possibility that the thickness of the use case both comprehensive coverage, but at different depths. Similar rain rainfall different, the meaning of crops (products) are different.
Maintainability:
There is no doubt, test cases and matching demand and maintain the test case itself is the focus of most of the team's work difficulty, coarse-grained and easy to maintain, easy to maintain and highly consistent demand; fine-grained use cases, the finer the more difficult to maintain, the maintenance cost is too large, especially the needs of the frequent changes will lead to unmaintainable.
Similar concepts, such as automated test session, GUI constantly changing due to similar script rewrite.
time:
Time coarse-grained structure and review shorter period for tight items; constructs fine particle size and longer write time period for loose mass or more inclined items.
Resources:
Coarse-grained uses less resources (manpower, review, conference rooms, etc.), for the same team or small team multi-project mode; fine-grained resource-intensive for large project teams or single mode.
risk:
There is no doubt, coarse-grained use cases risk of leakage is detected, there is a great risk the probability of leakage test, depending on the personal qualities of the tester; there are also fine-grained leakage test, but relatively more likely to be granted their own testers jump through the use case is not performed.
Fine-grained biggest risk is that patients with maintainability, or input-output ratio.
Test Example usingthe enumeration of the particle size of conventional application scenarios:
Particle size analysis of a number of test cases coarse and fine features of the above, then the routine test in terms of how particle size generally positioned thickness test it?
Following a single application environment to reflect.
Want to emphasize that sentence: the same institutions may have different testing purposes, may be tested in different regions or different levels of tests on the same region.
Single condition:
1, the time factor:
Time is short, tight item, review the preparation of Example with a shorter time, for coarse-grained use cases.
Longer project cycle, for fine-grained use cases.
比如规划六个月的项目，计划阶段和设计阶段有一个半月，测试前期进入，有足够的时间来进行人员培训、测试用例编写，需要细颗粒度。如果项目是一个月，测试准备时间只有五个工作日，那么可能在第三天就要完成第一轮的测试用例评审，建议以粗颗粒度为主，覆盖功能和体现思路。
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、公司决策投入：
公司对测试工作的投入，对产品质量的要求，对行业节奏的把握。具体分析，可参考项目质量性质部分的论述。
测试用例粗细的另外一个概念：用例的文字描述粗细。
文档分为好多种，在后面写测试用例的时候你们会遇到类似的颗粒度的问题。
第一类是写给自己，以及懂这个技术的，差不多水平的同事看的。这样只需要大致的描述核心关键点就可以。
第二类是给技术一般的员工，但是有一定底子的人看的，这样基本的概念就不用描述，整体步骤描述清楚就可以。
第三类是给不懂技术，只会看图一步步操作的外行看的，这样就要详细细致的描述基本概念，步步都截图，傻瓜式的对比参照的搞过去。
举个例子，使用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，就是通畅，其他显示就是不通畅。
So? This document is written for you to see who?
Above are recommended for a single external environment given. If the external environmental parameters more, and contradictory, such as multi-novice team, but the test project for the high quality requirements, and the project cycle is short, how to build a particle size of test cases, the need balancing test managers.
Test Case thickness: master the balance between quality and efficiency.