浅谈黑盒测试——6.测试的不可穷尽性-----a)代码覆盖率的局限性
6.测试的不可穷尽性6.1 什么样的测试才是穷尽的测试
对于穷尽的测试，有一些理解是这样的:
a) 穷尽“覆盖率”：测试每一行代码/每一个分支/每一个路径？
b) 测试员不在发现新的bug？
c) 测试计划完整地执行了？
穷尽的测试，真正的意思是，在测试完毕之后，测试员知道在系统里没有残留着任何未知的bug。因为如果有未知的bug，那么你可以通过做更多的测试来找到他们，你的测试也就还没有穷尽。
接下来针对上面的三种理解，做一个解释，
a) 穷尽“覆盖率”：测试每一行代码/每一个分支/每一个路径？
有人认为软件测试的完整程度可以简单地看做是代码的覆盖率。
那么，什么是覆盖率？
----对某一段代码或者代码的某一种属性做测试，其测试达到的程度被称为是覆盖率，比如对语句的覆盖，对分支或者条件的覆盖，等等
----把现有的测试与可能的执行的测试做比较，现有测试能够占总的可能执行的测试的多少比例作为计算覆盖率的方法
但是这种覆盖率的经典定义，对软件测试的穷尽性来说，还太简单了。他没有考虑到一些情况，比如
-----输入特定的某个值或者某组值
-----在编码中遗漏的代码
-----中断，以及其他并行操作的情况
Cem Kaner在他的著作“Software Negligence & Testing Coverage”里列举了101种这样的例子
举一个很简单的例子,有代码如下：
Input A//The program accept any integer into A and B
Input B
Print A/B
在这个例子中，我们可以轻易地让覆盖率达到100%。
我们令A=2 B=1，则覆盖了此程序所有语句，也覆盖了所有分支。
但是这样的测试并不完整，或者说并没有穷尽，那么我们遗漏了什么，程序中还存在什么bug呢？
很显然这里令B=0的时候，程序不可避免地会出错。也就是说这段程序里，遗漏了当B=0时需要如何处理的代码。前面提到过的，代码的遗漏，这种问题通过覆盖率根本无法发现。
计算并且追求实现高的覆盖率，是一种很好的方法来展示你距离穷尽的测试还有很大的距离。但是，如果你想她来确定你离穷尽的测试的距离究竟有多大，那么她并不是一种很好的工具。假如管理者一味地要求测试必须实现多少多少的覆盖率，反而会产生反效果，造就一大堆低效的测试用例。当测试员受到必须达到百分之多少的覆盖率的压力的时候，自然而然就会去选择编写那些容易提高覆盖率的测试用例，而不是去实现那些更能发现bug的测试用例。并且一旦你规定了百分之几，几乎没有人会在达到你的标准之后，再去做更多的测试。
浅谈黑盒测试——1.测试的基本问题http://bbs.51testing.com/thread-203447-1-1.html
浅谈黑盒测试——2.测试的目标http://bbs.51testing.com/thread-203453-1-1.html
浅谈黑盒测试——3.测试的策略http://bbs.51testing.com/thread-204300-1-1.html
浅谈黑盒测试——4.测试的依据http://bbs.51testing.com/thread-206539-1-1.html
浅谈黑盒测试——5.启发式方法http://bbs.51testing.com/thread-209119-1-1.html
浅谈黑盒测试——6.代码覆盖率的局限性http://bbs.51testing.com/thread-211605-1-1.html
本文内容翻译自Florida Institute of Technology的Cem Kaner和Satisfice Inc的James Bach组织的Black Box Software Testing课程
[ 本帖最后由 zhangting85 于 2010-6-9 08:22 编辑 ]
关于问题B
LZ，关于问题b，我很想听听您的分析，现在很迷茫。。。回复 2# 的帖子
有的，等下一期。。。 mk 基本上不可能穷尽，另外实际上时间上可能不允许，需要按优先级 本帖最后由 Jackc 于 2011-2-21 15:25 编辑计算并且追求实现高的覆盖率，是一种很好的方法来展示你距离穷尽的测试还有很大的距离。但是，如果你想她来确定你离穷尽的测试的距离究竟有多大，那么她并不是一种很好的工具。假如管理者一味地要求测试必须实现多少多少的覆盖率，反而会产生反效果，造就一大堆低效的测试用例。当测试员受到必须达到百分之多少的覆盖率的压力的时候，自然而然就会去选择编写那些容易提高覆盖率的测试用例，而不是去实现那些更能发现bug的测试用例。并且一旦你规定了百分之几，几乎没有人会在达到你的标准之后，再去做更多的测试。zhangting85 发表于 2010-5-24 10:18 http://bbs.51testing.com/images/common/back.gif
文章中关于覆盖率的这个评价我不赞同。
作者一方面在大量使用覆盖率评估测试质量（如，“计算并且追求实现高的覆盖率，是一种很好的方法来展示你距离穷尽的测试还有很大的距离”），一方面又否定覆盖率在测试质量评估中的地位（如，“如果你想她来确定你离穷尽的测试的距离究竟有多大，那么她并不是一种很好的工具”），稍感矛盾。
————————————————————
也许，作者其实是针对“假如管理者一味地要求测试必须实现多少多少的覆盖率”而言的。不过这个例子不太靠谱。大家都明白，实际测试质量的好坏，不是单靠一个指标就能评估的。从广义来说，无论太过于偏重哪个指标，都会导致评估结果产生致命的误差。所以，并非是某一个评估指标本身有问题或无价值，而是决策者的使用方法有问题而已。
————————————————————
而后面文章中，作者说的关于“覆盖率与bug发现率”的矛盾（如，“当测试员受到必须达到百分之多少的覆盖率的压力的时候，自然而然就会去选择编写那些容易提高覆盖率的测试用例，而不是去实现那些更能发现bug的测试用例。并且一旦你规定了百分之几，几乎没有人会在达到你的标准之后，再去做更多的测试。”）
我只能说，物尽其用，没有东西是万能的。我们的目标不是创造出完美的事物，而是设计出实用的事物。高覆盖率用例 & 高bug发现率用例，两者在测试活动中各有用处。
如覆盖率高的用例常用于：版本验收/功能主体测试/需求变更等，类似纪律严谨的步兵，主要任务是攻克测试主体的基本需求
而bug发现率高的用例则常用于：补充测试/随机测试等，类似天马行空的飞行兵，主要任务是高效的扩大战果，增加整个测试战役胜利的含金量
无论何时，覆盖率都是评估测试质量的重要指标之一。
————————————————————
欢迎大家讨论：） 文章中关于覆盖率的这个评价我不赞同。
作者一方面在大量使用覆盖率评估测试质量（如，“计算并且追求 ...
Jackc 发表于 2011-2-21 15:10 http://bbs.51testing.com/images/common/back.gif
文章中关于覆盖率的这个评价我不赞同。
作者一方面在大量使用覆盖率评估测试质量（如，“计算并且追求实现高的覆盖率，是一种很好的方法来展示你距离穷尽的测试还有很大的距离”），一方面又否定覆盖率在测试质量评估中的地位（如，“如果你想她来确定你离穷尽的测试的距离究竟有多大，那么她并不是一种很好的工具”），稍感矛盾。
————————————————————
##################
这个文章是我根据cem karner 的教程总结的，原作者的意思我想是这样的，前一句是说如果覆盖率低，那么离穷尽测试的距离一定很大，后一句是说，如果覆盖率高，离穷尽测试的距离并不一定很小。
换句话说，覆盖率低说明测的东西质量风险大，但覆盖率高不一定就说明测的东西质量风险小。
我想这个算是我翻译时引入的问题，整个文章距离“信”“达”“雅”的标准还差许多。
所以建议你还是看原文（原文是英语的视频，在youtube上搜索cem karner black box software testing应该就能找到了。）
##################
也许，作者其实是针对“假如管理者一味地要求测试必须实现多少多少的覆盖率”而言的。不过这个例子不太靠谱。大家都明白，实际测试质量的好坏，不是单靠一个指标就能评估的。从广义来说，无论太过于偏重哪个指标，都会导致评估结果产生致命的误差。所以，并非是某一个评估指标本身有问题或无价值，而是决策者的使用方法有问题而已。
————————————————————
###########
后面作者确实讲到这一点，因为这一节是讲测试的不可穷尽性时，老师为了让学生明白“覆盖率高不一定就离穷尽测试近”这一点，所以着重讲了只看这个指标的局限性。当然你说得是很正确的。关键在于这个指标的使用方式。
###########
而后面文章中，作者说的关于“覆盖率与bug发现率”的矛盾（如，“当测试员受到必须达到百分之多少的覆盖率的压力的时候，自然而然就会去选择编写那些容易提高覆盖率的测试用例，而不是去实现那些更能发现bug的测试用例。并且一旦你规定了百分之几，几乎没有人会在达到你的标准之后，再去做更多的测试。”）
我只能说，物尽其用，没有东西是万能的。我们的目标不是创造出完美的事物，而是设计出实用的事物。高覆盖率用例 & 高bug发现率用例，两者在测试活动中各有用处。
如覆盖率高的用例常用于：版本验收/功能主体测试/需求变更等，类似纪律严谨的步兵，主要任务是攻克测试主体的基本需求
而bug发现率高的用例则常用于：补充测试/随机测试等，类似天马行空的飞行兵，主要任务是高效的扩大战果，增加整个测试战役胜利的含金量
############
你说的我也非常赞同，不过和原作者的意思相去甚远。。。再次推荐看原教学视频。。
一方面，原作者cem karner 这里说的覆盖率是指代码的白盒测试覆盖率，不是指需求功能点的覆盖率，跟你所提到的需求覆盖率意思是大相径庭的。
另一方面，作者从管理的角度指出给定具体覆盖率指标的局限性，其实不是想说bug发现率和覆盖率之间的矛盾。而是说在追求覆盖率时容易走入的误区。
###########
无论何时，覆盖率都是评估测试质量的重要指标之一。
————————————————————
欢迎大家讨论：）
##############
最后，还有一个大环境的问题，原视频里面，作者举例，举的是有的公司要求90%覆盖率，有的要求80%覆盖率，会引起员工在做到90%或者80%之后不再继续测试的问题。
这在国内是难以想象的。
中国大多数企业的白盒测试代码覆盖率不能说是0吧，但对绝大多数项目而言也接近于0了。大环境上跟美国完全两样，所以不能生搬硬套。说实话在中国根本不用考虑代码覆盖率的问题，因为绝大部分公司压根不做白盒测试。
不过话说回来，看得出来原作者的意思是，不能用测试覆盖率这一个单一指标来评估测试的完成度或者说和“穷尽测试”的距离。如有疑问也可以去BBST的官网看看，或者加入BBST的邮件群组和老外讨论。说实话，我翻译到一半就意识到，这个课程对于国内的测试人来说其实没意义，起码要再过十年，再看这个课程才有意义。因为国内的测试压根没到这个层次。
这也是我懒得继续翻译的原因之一了。。
############## 回复 7# zhangting85
你说的很有道理，辩证地看待覆盖率是一直不变的真理，下来我会去看看那个视频，公司里看不了...
只是我依然有几点要说
1.虽然没看视频，但是我想cem karner 整篇教程应该会缺少一个应用环境的阐述。他的理论只适用于中大型软件开发。（老外的N多教程都有这个毛病，总认为一个理论能运用到所有环境...）
————————————————————————
2.其实在当前，代码覆盖测试与白盒测试的概念慢慢被融合，如今的代码测试并不只是字面意思，单纯地只测试代码。它还包括函数封装/应用，以及部分集成/系统测试。
大致分为：code 、API、function 三个部分。三者用于代码开发中的不同阶段和情况。
而这三部分的覆盖率要求也各不相同，code/API 要求的覆盖率极高，98%~100%可以经常看到。而相对function test，20%~80%也是常事。而cem karner 写这篇文章时，我相信他正是经历了code/API test 要求99%，甚至100%的环境，才发表了他自己的这些观点观点。而他的观点更趋向于：“测试的目的是发现bug”，所以他将太高的覆盖率作为一种资源浪费来看待。
而我更趋向于“测试通过评估产品质量，为产品的开发过程护航”（国内目前就这个行情，测试不是单纯的测试，还承担了很大程度的质量责任）
其实针对较简单的代码测试部分（code/API test），高覆盖率带来的浪费并不是我们关注重点。反而，为了更好的保证代码的check in 、版本的集成/释放，code/API test 有足够的价值要求更高的覆盖率。（当然，小型系统的开发也不适用这些理论）
所以，我与他出发点不同，其理论存在分歧很自然...
————————————————————————
3.再说说老外的测试培训文档。（八卦一下）
测试本来就是一门云里雾里的学问。最难的部分不是概念，而是“度”。
如，cem karner 认为，代码覆盖率低了不好，高了也不好，那么什么样的代码覆盖率才叫“好”？这就涉及代码覆盖率的实际度量问题。
很多老外写书的时候，总喜欢指出这些“度”是什么，在哪里，但是他们往往不会详细阐述如何分析“度”的相关数据，继而得出可行性方案。（当然，这是通病，其实国内也一样)
所以，老外的东西不见得都是精品。（呵呵，其实刚刚临时想到，如果用“易经”的片段来写一本测试书，岂不是显得更“高深”，哈哈......）
——————————————————————————
4.最后，说说白盒测试执行：
在国内，白盒测试普遍存在一个误区：“白盒测试必须使用工具”。
其实，白盒也有手工测试，其代表类型是“代码走查”
工具始终是手段，如何达到自己测试目的，不需要拘泥于书本，跳出书本的框框架架，也许就能看得更远.... 呵呵，学习了…… 讨论的很精彩…… 本帖最后由 zhangting85 于 2011-2-24 15:14 编辑
回复 8# Jackc
我想，测试人员工作的一个基本准则就是凡事都不能想当然。
请问，你报bug的时候能凭自己的猜测来报bug吗。建议你理解原作者的意思之后再发表意见。或者有哪部分不能理解的我们可以讨论。但是凭自己的猜测，来讨论原作者的局限性，这就不可取了。你都说你还没看视频，这样的猜测有意义吗。
你说的几点，
1.你猜测作者的教程没有具体应用环境的阐述
你的原文如下：
“1.虽然没看视频，但是我想cem karner 整篇教程应该会缺少一个应用环境的阐述。他的理论只适用于中大型软件开发。（老外的N多教程都有这个毛病，总认为一个理论能运用到所有环境...）”
#########
恰恰相反，他从一开始就强调环境问题。你可以看我翻译的测试策略部分，整个讨论就是从不同的应用环境开始的，并且贯穿整个教程。
#########
2.你说的第二点，又是想当然了
“写这篇文章时，我相信他正是经历了code/API test 要求99%，甚至100%的环境，才发表了他自己的这些观点观点。而他的观点更趋向于：“测试的目的是发现bug”，所以他将太高的覆盖率作为一种资源浪费来看待。”
##########
首先，他经历过什么样的环境和你猜测的他的观点“测试的目的是发现bug”两者没有因果关系。
然后，他这里讲的就是代码的覆盖率，而你把代码，接口和功能三个方面当做是覆盖率。这里的问题，并不是他不知道“接口和功能”的覆盖，而是“同一个词对于不同环境的人往往有不同的意义”。我们不能说谁的定义对谁的定义错。但是你要知道，他在讲A问题，你在讲B问题。你们在讲不同的问题，你们所谈论的问题的正确与否没有互相之间的直接关系。
第三，也是最重要的， 你猜测道：“而他的观点更趋向于：“测试的目的是发现bug”，所以他将太高的覆盖率作为一种资源浪费来看待。”我想任何一个测试人员都不应该把自己的猜测言之凿凿的当做真事儿这样说出来，你可以说: 我猜测xxxxxx。事实上你看完作者的视频就知道他有专门讲测试的目的，远远不仅仅是发现bug而已。比如，你在一个刚刚启动的项目中，你的测试目的可能是发现项目中隐藏的风险。再比如，你在做一个有着严格需求定义说明书的项目时，你的测试目的也不是发现更多的bug，而是确保程序按照需求定义说明书来运行。等等。这都是作者举过的例子。
看到这里，想必你已经明白了，凭猜测来做出讨论是没有意义的了。
##########
3.第三点仍然是同样的问题
你说“cem karner 认为，代码覆盖率低了不好，高了也不好”但是，这是一种曲解，作者原意是指定某个代码覆盖率作为测试设计执行的标准，这样做不好。而没有说代码覆盖率低了不好，高了也不好。
可不可以请你停止猜测呢。
############
4.第四点与原文无关，我也没什么想谈的，不过告诉你，code review这个东西，在这个教程里也有讲。
另外，不得不提醒你一下，这个教程是作者十年前的。十年前的教程至今仍然比国内水平领先很多年。
最后，各位在论坛学习的测试人员们，凡事切勿想当然，猜测是不能作准的。而作为一个测试人员，一旦你以猜测来报bug，报错了，你在开发人员心目中的声誉就会下降，最后你就会被贴上“只会瞎猜”的标签。 回复zhangting85
你说的很有道理，辩证地看待覆盖率是一直不变的真理，下来我会去看看那个视频，公司 ...
Jackc 发表于 2011-2-22 15:59 http://bbs.51testing.com/images/common/back.gif
作者列出过的测试可能的目标，如下，绝不仅仅是你猜测的“发现bug”。充分证明了猜测是靠不住的。
2.2测试的目标
不同的测试目标要求采用不同的测试策略，会执行不同的测试，编写不同的文档，以及得到不同的结果，一些可能的测试目标有：
l找到重要的bug，使他们得到修复
l评估产品的质量
l对是否发布产品的决策提供帮助
l阻止不成熟的产品被发布
l对预测和控制产品的支持成本提供帮助
l监测待测产品和其他产品的交互性
l解释如何安全地使用产品
l评估产品与实际需求的一致性
l证明产品符合某个特定的标准（如国际标准，国家标准等）
l确保测试的过程符合问责制标准
l减少产品可能引起的安全方面的诉讼风险
l帮助客户提高产品的质量和可测试性
l帮助客户改进他们的流程
l作为第三方检测产品 回复zhangting85
你说的很有道理，辩证地看待覆盖率是一直不变的真理，下来我会去看看那个视频，公司 ...
Jackc 发表于 2011-2-22 15:59 http://bbs.51testing.com/images/common/back.gif
以下是作者在测试策略问题时举过的不同环境的例子，可以说这个正是James bach和Cem karner的Context Driven Testing测试思想的核心（环境驱动测试），针对不同的上下文环境，测试的目标，策略，等等都是不能直接套用的。请你不要再在猜测的基础上做出不切实际的批判了，以免对读者进行误导。
3.2关于测试策略的一个思维试验
假设，你现在被要求测试某个程序里的一个计算功能模块，你可以想象成电子表格之类的。好的，现在这个程序是不确定的，假设有4个程序的这一类模块需要测试，如下：
1）一个电脑游戏中的计算功能模块
2）一个商业产品，你现在在这个产品开发流程的前期（开发刚开始不久）介入了这个产品，并且，现在你的项目经理要求你对这个模块做一个测试，以帮助她确定这个产品包含的风险，并且帮助她让她的程序员们明白，他们的工作的可靠性程度会产生的影响。
3）一个商业产品，你现在在这个产品开发流程的后期（产品即将正式发布）介入了这个产品，并且，现在你的项目经理要求你对这个模块做一个测试，以帮助她确定这个产品什么时候可以发布。
4）一个控制医疗器械的软件中的计算功能模块
继续，对这4个程序的计算模块，现在有以下问题
A）你的测试目标是什么？
B）你会怎样组织你的测试，以实现这个测试目标？
B-1）你对发现的bug有一个什么样的重视程度？为什么？
B-2）什么样的bug的重要性会比较高？为什么
B-3）你对你的工作所作的文档会细致到什么程度？为什么？
C）假设这个程序中有一个数字输入域，在需求文档上说明了，这个域必须能够接受一位的数字作为输入值，但是没有说明如果输入字母或者符号等等，系统会如何反应。那么你应该去测试输入字母或者符号的情况吗？假如，现在这个项目的时间非常非常的紧急呢？ 欢迎进一步讨论，但是请不要纯粹在自己的无根据的猜想上做出论断，这些猜测出来的东西没有讨论的意义。 呵呵，昨天回家看看了视频，才恍然大悟。发现去年偶然在新手区看到这个系列教程的链接，里面的内容不仅仅只有功能测试，还包括性能，质量控制等。当时还集中突击过这个系列的视频教程一段时间。可惜我并没有把它当做测试经验学习，仅仅是为了提高测试英语而已...
平心而论，这一套教程看做一个测试提纲而言，还挺不错的（我确实真心佩服这个系列的框架设计，基本覆盖了测试概念的各个方方面面，若以后弄个测试培训学校，还可以花心思去研究这个培训系列的结构）。
但是若想从中得到可用于实际测试的东西，仅仅就那几页只言片语，远远不够。
若说它如何如何高深，我确实看不出和国内各个培训机构组织的企业级测试培训有什么区别，它除了广度优势外，就忽悠程度而言，确实差不离，而其中所涉及的概念在国内测试中都有具体实现。其实，测试入国门的年头不短了，从21世纪初开始的国内IT业的大兴盛，到现在也是10年有余，所以，并不如LZ所想象的“国内测试水平差”。在测试域，我们和国外差的并不是概念运用，所有测试在国内都能做，少数公司引用的测试指标并不比国外低。论差别，是“人”（也可以叫做文化或流程，老外是就事论事，我们就认论事，仅此而已）。
——————————————————————————
我想，测试人员工作的一个基本准则就是凡事都不能想当然。
请问，你报bug的时候能凭自己的猜测来报bug吗。建议你理解原作者的意思之后再发表意见。或者有哪部分不能理解的我们可以讨论。但是凭自己的猜测，来讨论原作者的局限性，这就不可取了。你都说你还没看视频，这样的猜测有意义吗。
说说关于猜测与测试的联系。我不认为肆意的猜测对测试员有什么不好。相反，一个对任何事物抱有疑问，不断的提出各种猜测的测试员，才是好的测试员。天马行空的思维是优秀测试员必备的条件之一。若认为事物都都应有理可依，那又何来新测试点的发现呢。
再说说报bug这个问题，最简单的判断就是有据可依，如需求文档/审计概要啥的。这个貌似没啥说的。
还有一种bug，它是无据可依的，如易用性，这种bug，测试员是否应该report呢？当然，你可以说，这样的bug我们可以list依据，如同类产品比较/操作步骤统计表等。公司流程规范定义这些玩意属于可用依据，那么测试人员是否应该凭借自己的猜测，先报个bug看看？再根据这个bug的处理为以后的判断的做新的依据呢？所谓“投石问路”，就是需要猜测优先。
（其实，就这个观点，我觉得没什么好争议的，环境不同，大家实现目标的方式不同，谈不上是“假设优先”好还是“分析优先”好，在我看来，结果导向才是真的好呢，呵呵）
——————————————————————————
恰恰相反，他从一开始就强调环境问题。你可以看我翻译的测试策略部分，整个讨论就是从不同的应用环境开始的，并且贯穿整个教程。
这里有两个问题：
1.环境的概念。
环境的标准解释为：事物外部的客观存在。
如果该事物本身就是逻辑概念的话，则“环境”一词可理解为“概念存在的前提条件”，而这类前提条件极少是一个，通常是多个同时存在。
而，在“测试策略部分”，作者只提及了策略使用的一种环境因素，产品类型。而影响测试策略的仅只这一个因素？其他因素是作者不知而不写，还是说他也想偷偷懒？毕竟1,2十分钟内要描述清楚“测试策略选择”这个问题，本来就是不可能的，它的概念以及设计内容太过广泛了。
然而，我最不满意之处就是，作者做为一个测试知识丰富的人，却吝啬于将自己总结的测试涉及的“度”展现出来。如，他在此段落的最后补上各种影响策略的因素列表，又会耗去他多少宝贵的时间呢？
所以，就学习而言，这个真的算不上精品。
（再说明一次，测试的难点不是概念理论，而是“度”的控制）
2.环境的及时性
再说代码测试这里，作者在提及其覆盖率局限性时，是否阐述了应用环境？难道因为在遥远的上一章提及的几个测试类型就是此概念的环境？
显然不是嘛，代码覆盖率局限性的使用环境至少应该提及测试资源和目标约束，若资源充足，客户需求高，有必要限制覆盖率么?
————————————————————————————————————————————
首先，他经历过什么样的环境和你猜测的他的观点“测试的目的是发现bug”两者没有因果关系。
呃，我这两句话貌似不是你说的因果关系的意思，只是简单阐述了文章透露出来的信息而已。
第一句：“写这篇文章时，我相信他正是经历了code/API test 要求99%，甚至100%的环境，才发表了他自己的这些观点观点。
我猜测作者有实际的高覆盖率测试经验，所以才能在这里发表对高覆盖率的言论（这句话并不关心“他的观点是何”，只是简单阐述“经验体会来源与经历”这个客观逻辑而已，当然，严谨的说法应该是“我相信作者或他身边人......”）
第二句：“而他的观点更趋向于：“测试的目的是发现bug”，所以他将太高的覆盖率作为一种资源浪费来看待。”
这句话其实是本篇作者的核心之一，也是作者最看重的核心，若他不是站在“发现bug”这个立足点，又何来“那些更能发现bug的测试用例”会比“高覆盖率的测试用例”更优秀的观点呢？
（注：本文提及另一核心是他担心测试员在实现高覆盖率后出现不负责的情况。题外话，他这个也是猜测，所以，猜测是贯穿测试理论的....），
——————————————————————————————————————————
然后，他这里讲的就是代码的覆盖率，而你把代码，接口和功能三个方面当做是覆盖率。这里的问题，并不是他不知道“接口和功能”的覆盖，而是“同一个词对于不同环境的人往往有不同的意义”。我们不能说谁的定义对谁的定义错。但是你要知道，他在讲A问题，你在讲B问题。你们在讲不同的问题，你们所谈论的问题的正确与否没有互相之间的直接关系。
从本质来说，这确实是两个问题。我将例子的范围举得过大，同样犯了“大概念错误”。
（接下来讨论的部分，仅针对于国内大型公司。另，我们就不讨论Kaner的black box 怎么会有 code test这问题哈，确实某些名词的概念，文化差异还是有的）
我将范围缩小到Kaner的例子，即不大于单个函数的代码测试。
1.先说覆盖率的概念，Kaner列举了两种代码覆盖率定义：“测试每一行代码/每一个分支/每一个路径”“对某一段代码或者代码的某一种属性做测试，其测试达到的程度被称为是覆盖率，比如对语句的覆盖，对分支或者条件的覆盖，等等”。
Kaner认为这两种定义是相同的，都只涉及“行/条件/分支”三种测试类型。而假如第二种定义的“等等”包括容错/符号功能..若包括了Kaner所列举的101类型，那又是怎样的结果呢？所以，“行/条件/分支”只是代码覆盖率的基础方法，而不是完整方法。（还是那句话，猜测贯穿测试，Kaner在猜测，我也在猜测，只要身在测试，永远逃不掉猜测的命运）
2.还是得说说Kaner和我对于覆盖率的不同着眼点
Kaner从代码测试本质入手，即用例更高的覆盖率是为了发现bug，这是最基本的模型，也是覆盖率最基础的使用。（提出这点并不是我反对它）
我则试图从测试策略的角度来解释，即用例根据其实用目的的不同，而选择不同覆盖率的
当前，测试覆盖率是多元化的，它可以通过其用例的实际目的定义不同的覆盖率。
如，一段的代码设计，需要经过3个测试阶段
1）设计完成时，我们需要对其进行可测试性测试，这部分用例大多选择最基础的测试方法，即“行/条件/分支”。而对它们定义的覆盖率，也是基于覆盖了多少行，多少条件，多少分支来确定的。而它们的硬性指标往往很高，也就是之前说的98%
2）可测试性完成后，我们才会进入普通测试，而此阶段覆盖率的定义则变更为Kaner提到的理论，即以发现bug为主导。它的覆盖率较低，而Kaner整篇文章也只提及了此阶段测试，并未提及测试策略与测试用例的结合。
3）最后进行集成前，会再进行一次check in 测试，它又是在“行/条件/分支”范围内的一次高覆盖率测试。
————————————————————————————
第三，也是最重要的， 你猜测道：“而他的观点更趋向于：“测试的目的是发现bug”，所以他将太高的覆盖率作为一种资源浪费来看待。”我想任何一个测试人员都不应该把自己的猜测言之凿凿的当做真事儿这样说出来，你可以说: 我猜测xxxxxx。事实上你看完作者的视频就知道他有专门讲测试的目的，远远不仅仅是发现bug而已。比如，你在一个刚刚启动的项目中，你的测试目的可能是发现项目中隐藏的风险。再比如，你在做一个有着严格需求定义说明书的项目时，你的测试目的也不是发现更多的bug，而是确保程序按照需求定义说明书来运行。等等。这都是作者举过的例子。
这里你说到两个问题：
1.测试人员的猜测问题，我在上面各有几处解释，希望你有所体会猜测与测试的真正联系。
2.我的所有评论，仅针对于Kaner的此篇培训内容。真正的测试者没有一成不变的观点，犹如变色龙一般，环境一变，可能所有观点都会颠覆。
对于测试，没有完全正确的观点，只有符合环境的观点。
如你的例子，前提条件有“刚启动的项目”/“严格需求定义”等环境描述，若去掉这些，你认为最后的列举的理论还是正确的？
Kaner在这篇培训中，由于缺少大量必要环境的描述，确实存在疏漏，所以我指出。 本帖最后由 Jackc 于 2011-2-28 17:45 编辑
呵呵，昨天回家看看了视频，才恍然大悟。发现去年偶然在新手区看到这个系列教程的链接，里面的内容不仅仅只有功能测试，还包括性能，质量控制等。当时还集中突击过这个系列的视频教程一段时间。可惜我并没有把它当做测试经验学习，仅仅是为了提高测试英语而已...
平心而论，这一套教程看做一个测试提纲而言，还挺不错的（我确实真心佩服这个系列的框架设计，基本覆盖了测试概念的各个方方面面，若以后弄个测试培训学校，还可以花心思去研究这个培训系列的结构）。
但是若想从中得到可用于实际测试的东西，仅仅就那几页只言片语，远远不够。
若说它如何如何高深，我确实看不出和国内各个培训机构组织的企业级测试培训有什么区别，它除了广度优势外，就忽悠程度而言，确实差不离，而其中所涉及的概念在国内测试中都有具体实现。其实，测试入国门的年头不短了，从21世纪初开始的国内IT业的大兴盛，到现在也是10年有余，所以，并不如LZ所想象的“国内测试水平差”。在测试域，我们和国外差的并不是概念运用，所有测试在国内都能做，少数公司引用的测试指标并不比国外低。论差别，是“人”（也可以叫做文化或流程，老外是就事论事，我们就人论事，仅此而已）。
——————————————————————————
我想，测试人员工作的一个基本准则就是凡事都不能想当然。
请问，你报bug的时候能凭自己的猜测来报bug吗。建议你理解原作者的意思之后再发表意见。或者有哪部分不能理解的我们可以讨论。但是凭自己的猜测，来讨论原作者的局限性，这就不可取了。你都说你还没看视频，这样的猜测有意义吗。
说说关于猜测与测试的联系。我不认为肆意的猜测对测试员有什么不好。相反，一个对任何事物抱有疑问，不断的提出各种猜测的测试员，才是好的测试员。天马行空的思维是优秀测试员必备的条件之一。若认为事物都都应有理可依，那又何来新测试点的发现呢。
再说说报bug这个问题，最简单的判断就是有据可依，如需求文档/审计概要啥的。这个貌似没啥说的。
还有一种bug，它是无据可依的，如易用性，这种bug，测试员是否应该上报呢？当然，你可以说，这样的bug我们可以先列举依据出来，如同类产品比较/操作步骤统计表等。但是，若公司流程规范没有定义这些玩意为可用依据呢？那么测试人员是否应该凭借自己的猜测，先报个bug看看？再根据这个bug的处理为以后的判断的做新的依据呢？所谓“投石问路”，就是需要猜测优先。
（其实，就这个观点，我觉得没什么好争议的，环境不同，大家实现目标的方式不同，谈不上是“假设优先”好，还是“分析优先”好，在我看来，结果导向才是真的好呢，呵呵）
——————————————————————————
恰恰相反，他从一开始就强调环境问题。你可以看我翻译的测试策略部分，整个讨论就是从不同的应用环境开始的，并且贯穿整个教程。
这里有两个问题：
1.环境的概念。
环境的标准解释为：事物外部的客观存在。
如果该事物本身就是逻辑概念的话，则“环境”一词可理解为“概念存在的前提条件”，而这类前提条件极少是一个，通常是多个同时存在。
而，在“测试策略部分”，作者只提及了策略使用的一种环境因素，产品类型。而影响测试策略的仅只这一个因素？其他因素是作者不知而不写，还是说他也想偷偷懒？毕竟1,2十分钟内要描述清楚“测试策略选择”这个问题，本来就是不可能的，它的概念以及设计内容太过广泛了。
然而，我最不满意之处就是，作者做为一个测试知识丰富的人，却吝啬于将自己总结的测试涉及的“度”展现出来。如，他在此段落的最后补上各种影响策略的因素列表，又会耗去他多少宝贵的时间呢？
所以，就学习而言，这个真的算不上精品。
（再说明一次，测试的难点不是概念理论，而是“度”的控制）
2.环境的及时性
再说代码测试这里，作者在提及其覆盖率局限性时，是否阐述了应用环境？难道因为在遥远的上一章提及的几个测试类型就是此概念的环境？
显然不是嘛，代码覆盖率局限性的使用环境至少应该提及测试资源和目标约束，若资源充足，客户需求高，有必要限制覆盖率么?
————————————————————————————————————————————
首先，他经历过什么样的环境和你猜测的他的观点“测试的目的是发现bug”两者没有因果关系。
呃，我这两句话貌似不是你说的因果关系的意思，只是简单阐述了文章透露出来的信息而已。
第一句：“写这篇文章时，我相信他正是经历了code/API test 要求99%，甚至100%的环境，才发表了他自己的这些观点观点。
我猜测作者有实际的高覆盖率测试经验，所以才能在这里发表对高覆盖率的言论（这句话并不关心“他的观点是何”，只是简单阐述“经验体会来源与经历”这个客观逻辑而已，当然，严谨的说法应该是“我相信作者或他身边人......”）
第二句：“而他的观点更趋向于：“测试的目的是发现bug”，所以他将太高的覆盖率作为一种资源浪费来看待。”
这句话其实是本篇作者的核心之一，也是作者最看重的核心，若他不是站在“发现bug”这个立足点，又何来“那些更能发现bug的测试用例”会比“高覆盖率的测试用例”更优秀的观点呢？
（注：本文提及另一核心是他担心测试员在实现高覆盖率后出现不负责的情况。题外话，他这个也是猜测，所以，猜测是贯穿测试理论的....），
——————————————————————————————————————————
然后，他这里讲的就是代码的覆盖率，而你把代码，接口和功能三个方面当做是覆盖率。这里的问题，并不是他不知道“接口和功能”的覆盖，而是“同一个词对于不同环境的人往往有不同的意义”。我们不能说谁的定义对谁的定义错。但是你要知道，他在讲A问题，你在讲B问题。你们在讲不同的问题，你们所谈论的问题的正确与否没有互相之间的直接关系。
从本质来说，这确实是两个问题。我将例子的范围举得过大，同样犯了“大概念错误”。
（接下来讨论的部分，仅针对于国内大型公司。另，我们就不讨论Kaner的black box 怎么会有 code test这问题哈，确实某些名词的概念，文化差异还是有的）
我将范围缩小到Kaner的例子，即不大于单个函数的代码测试。
1.先说覆盖率的概念，Kaner列举了两种代码覆盖率定义：“测试每一行代码/每一个分支/每一个路径”“对某一段代码或者代码的某一种属性做测试，其测试达到的程度被称为是覆盖率，比如对语句的覆盖，对分支或者条件的覆盖，等等”。
Kaner认为这两种定义是相同的，都只涉及“行/条件/分支”三种测试类型。而假如第二种定义的“等等”包括容错/符号功能..若包括了Kaner所列举的101类型，那又是怎样的结果呢？所以，“行/条件/分支”只是代码覆盖率的基础方法，而不是完整方法。（还是那句话，猜测贯穿测试，Kaner在猜测，我也在猜测，只要身在测试，永远逃不掉猜测的命运）
2.还是得说说Kaner和我对于覆盖率的不同着眼点
Kaner从代码测试本质入手，即用例更高的覆盖率是为了发现bug，这是最基本的模型，也是覆盖率最基础的使用。（提出这点并不是我反对它）
我则试图从测试策略的角度来解释，即用例根据其实用目的的不同，而选择不同覆盖率的
当前，测试覆盖率是多元化的，它可以通过其用例的实际目的定义不同的覆盖率。
如，一段的代码设计，需要经过3个测试阶段
1）设计完成时，我们需要对其进行可测试性测试，这部分用例大多选择最基础的测试方法，即“行/条件/分支”。而对它们定义的覆盖率，也是基于覆盖了多少行，多少条件，多少分支来确定的。而它们的硬性指标往往很高，也就是之前说的98%
2）可测试性完成后，我们才会进入普通测试，而此阶段覆盖率的定义则变更为Kaner提到的理论，即以发现bug为主导。它的覆盖率较低，而Kaner整篇文章也只提及了此阶段测试，并未提及测试策略与测试用例的结合。
3）最后进行集成前，会再进行一次check in 测试，它又是在“行/条件/分支”范围内的一次高覆盖率测试。
————————————————————————————
第三，也是最重要的， 你猜测道：“而他的观点更趋向于：“测试的目的是发现bug”，所以他将太高的覆盖率作为一种资源浪费来看待。”我想任何一个测试人员都不应该把自己的猜测言之凿凿的当做真事儿这样说出来，你可以说: 我猜测xxxxxx。事实上你看完作者的视频就知道他有专门讲测试的目的，远远不仅仅是发现bug而已。比如，你在一个刚刚启动的项目中，你的测试目的可能是发现项目中隐藏的风险。再比如，你在做一个有着严格需求定义说明书的项目时，你的测试目的也不是发现更多的bug，而是确保程序按照需求定义说明书来运行。等等。这都是作者举过的例子。
这里你说到两个问题：
1.测试人员的猜测问题，我在上面各有几处解释，希望你有所体会猜测与测试的真正联系。
2.我的所有评论，仅针对于Kaner的此篇培训内容。真正的测试者没有一成不变的观点，犹如变色龙一般，环境一变，可能所有观点都会颠覆。
对于测试，没有完全正确的观点，只有符合环境的观点。
就如你的例子，前提条件有“刚启动的项目”/“严格需求定义”等环境描述，若去掉这些，你认为最后的列举的理论还是正确的？
Kaner在这篇培训中，由于缺少大量必要环境的描述，确实存在疏漏，所以我指出。 回复 16# Jackc
其实你认为的猜测与测试的真正联系未必就真的是真正的联系。时隔7个月，偶然回来逛逛，你可以看看下面给你回复，深入体会自己的不足：
你再次偷换概念引导读者误以为我的观点是猜测不重要，这说明你在偷换概念上相当的熟练，或者说明你的中文理解能力是有缺陷的，如果是后者，这反映出我国语文教育的不足。以下将从你认为找不到依据的bug开始解读这个问题。
对于易用性的bug，你在报bug的时候你认为是没有依据的猜测，但是下意识里，测试员会去找依据，同类产品的相似功能，本产品的相似功能，本产品的其他功能甚至没有计算机时实现这个功能的人工步骤，测试员本身对操作中用户体验的感受等等都是报bug的依据。假如是没有任何依据的瞎猜，这样的猜测没有任何意义。
你所谓的“先报个bug看看？再根据这个bug的处理为以后的判断的做新的依据呢”无非是把应该做的找依据的工作推给你的开发，你的测试经理，你的产品经理，你的项目经理。他们对你报的bug做判断需不需要去修复的时候，同样要找依据。或者你认为他们都是跟你一样凭脑袋想想，拍脑袋来考虑问题。好吧，作为一个底层测试员来说，可能你接触到的就是这样的，你只要把bug报上去就好了，改不改不是你的事儿了。
举个例子，假设你是网易的测试员，你在163上注册了个帐号，然后你报了一个易用性bug，你猜测这个注册太繁琐。
但是你有没有去咨询客服人员收到的投诉、求助电话里有多少是关于注册的，你有没有去做用户调查调查真正用户是否和你的想法一样，你有没有去比较新浪、雅虎的注册流程是否一样繁琐。不可否认猜测的重要性，但是猜测之后的工作更是体现测试员价值的部分。而不是简单地报上去，把这个后续的工作推给别人。说实话你指望谁来做这个工作？开发还是产品经理？项目经理？他们都有自己的工作。而这个工作显然是在搜集产品质量相关信息的测试工作的范畴之内。
科学研究的方法是，先猜测，作出假设，然后实验验证，再得出结论。而不是先猜测，然后不管三七二十一，直接得出结论。后者是官员的作法。这里，猜测必然是重要的，最重要的。但是猜测出来的东西呢，只能是如“哥德巴赫猜想”一样等待后人去验证的。（你要是等待开发和项目经理帮你验证，你就等一辈子吧）哥德巴赫不会说我猜测了一个东西，然后也不验证，直接用自己猜测出来的公式去推导新的结论。
另外，再说一遍，你对那个培训视频产生的看法，是由于你在特定的工作环境影响下使你得出的结论。如果你不能从客观全面的角度来讨论问题的话，不要言之凿凿的就认为自己说的一定是真理了，其实往往恰恰相反。
页:
[1]
