测试用例颗粒度说明.doc

测试用例颗粒度说明 1. 颗粒度与测试的关系如果把测试用例设计得很细, 照顾到每一个数据输入、每一个条件、每一个环境、每一个路径, 那么测试用例的数量将是巨大的, 虽然风险很小很小, 但是测试效率会很低, 并且测试执行没有思考的空间,可能使测试执行人员变得呆板(除非全部测试自动化) ,不需要创造力、思考。测试用例设计很粗,测试效率可能比较高,测试人员有一个发挥的空间,使测试更有趣,但这依赖于个人的责任感和能力,风险大得多。 2. 颗粒度的大小取决与以下三点 1、“重要功能”、“特殊功能”颗粒密集度高,“通用功能”可以试用通用测试粒度,密集度应该可以大致界定。个人认为, 假如你非要为了一个字体的样式而写了一大长串的测试用例,那么这个颗粒度就毫无意义了。 2 、颗粒度的大小还取决与客户对“产品”的要求。测试有一个难题是测试的精度,或者说颗粒度的定义, 不要说一个程序, 就算是一个简单的登录都可以写出几乎无穷尽的测试用例, 所以你需要指明功能、性能需求, 使用环境等, 并说明对缺陷容忍的限度。才好依据最终的需求来定义测试的颗粒度,也才好写测试用例,总之,客户的要求越详细所得到的测试用例越准确。如果客户跟你说这个地方你必须仔仔细细的测试。那么我们在写测试用例的时候。这个颗粒度一定要小了。 3 、一般功能颗粒密集度可能会根据项目或是时间来确定。如果时间充裕颗粒度可以适当小。 4、粒度取决于测试的种类, 一般用验收测试, 是项目测试中颗粒度比较大。系统测试颗粒度相对较小。 3. 有效度量测试用例条件: 1 、颗粒度可以跟代码行数对应: 一般来说代码量越大,内部逻辑就越复杂,出现 bug 的的可能性也越高。对应的测试粒度也越小。 2 、测试团队内部对粒度达成一致,适当把握颗粒度: 明确测试用例编写的颗粒度,大家都有这种感觉,你写测试用例,你测试这个产品的时候,你十条测试用例就测试完了,有人写三十条, 你就觉得奇怪, 我觉得十条已经是局限了, 怎么你能写到三十条, 你去看他的用例,发现这也能算一条,这是组织内部测试用例颗粒度没有达成一致。 3 、颗粒度要适合业务的需要: 各公司测试用例设计的粒度不同,适合自己的需要,适合业务的需要即可,测试用例的数量统计方法,我觉得说明不了测试作得是否专业。 4、测试用例设计的覆盖率和有效性, 才是说明测试是否专业的依据之一: 对于进行工作量的统计还可以, 不过用例还是不能简单的以数量来看, 设计一个很简单的功能点的用例可能很容易, 可能一天能设计十个这样的用例, 但是对于一个相对复杂的功能, 可能一天才能准备两个用例,光靠数量是说明不了问题的。测试用例之度——系列之颗粒度测试用例是测试工作的核心。测试工作是讲究投入产出比的工作, 这也是测试用例设计的指导思想。测试用例有度的概念, 正如亚里士多德在《伦理学》中讨论道德为例: 道德意味着过与不及之间的状态。面向测试用例,网上流传着这么一句话: “不同的机构会有不同的测试目的; 相同的机构也可能有不同测试目的,可能是测试不同区域或是对同一区域的不同层次的测试”下面就列举测试用例设计的方方面面, 看不同的团队, 不同的测试目的, 如何把握测试用例设计之度。颗粒度: 颗粒度的粗细,有无标准?什么是粗?什么是细? 1 、以功能点划分? 仅仅覆盖所有的功能性需求为粗? 仅仅正向覆盖所有的功能需求(功能、性能)为粗? 正向/ 负向覆盖所有的功能需求(功能、性能)以及正向覆盖性能需求为粗? 正向/ 负向覆盖所有的需求为细?覆盖到产品包,涵盖兼容性、升级、安装、易用性为细? 2 、以 STEP 划分? 每条用例有一个 STEP 为粗,三?五?十为细?以上为细? 以测试设计思路的体现? 只采用正向为粗?只采用正/ 负向为粗?考虑应用场景为细?考虑业务逻辑为细? 3 、以数量级? 百条?千条?万条? 4 、以数据覆盖? 等价类是粗?穷举是细? 每个人、每个机构判定测试用例粗细的标准都不一样, 没有标准的答案。所以测试用例颗粒度的粗细,本身就是一个相对而言的标准。尝试用图示来表示颗粒度粗细的常规概念: 测试用例颗粒度粗、细的特点是什么? 用例设计分析: 粗颗粒度面向宏观, 面向正向的功能点、大的功能模块和整体性, 体现测试用例的设计思路; 细颗粒度面向微观,面对具体的一个个功能点的正向/ 负向逻辑,体现测试用例的细节和完备性。面对测试执行人员: 粗颗粒度用例不容易被测试新手执行, 因为很多约定成俗的操作、现象, 甚至行业术语都不清楚。细颗粒度用例相对较易被测试新手执行。覆盖度: 粗颗粒度覆盖度可能小于细颗粒度用例( 粗颗粒度只覆盖全部正向和部分负向, 细颗粒度覆盖全部正向、负向、其他等); 但还有一种可能性, 就是粗细用例均覆盖全面, 但是深度不同。类似下雨的降雨量不同,对农作物(