计算并且追求实现高的覆盖率,是一种很好的方法来展示你距离穷尽的测试还有很大的距离。但是,如果你想她来确定你离穷尽的测试的距离究竟有多大,那么她并不是一种很好的工具。假如管理者一味地要求测试必须实现多少多少的覆盖率,反而会产生反效果,造就一大堆低效的测试用例。当测试员受到必须达到百分之多少的覆盖率的压力的时候,自然而然就会去选择编写那些容易提高覆盖率的测试用例,而不是去实现那些更能发现bug的测试用例。并且一旦你规定了百分之几,几乎没有人会在达到你的标准之后,再去做更多的测试。zhangting85 发表于 2010-5-24 10:18
我想,测试人员工作的一个基本准则就是凡事都不能想当然。
请问,你报bug的时候能凭自己的猜测来报bug吗。建议你理解原作者的意思之后再发表意见。或者有哪部分不能理解的我们可以讨论。但是凭自己的猜测,来讨论原作者的局限性,这就不可取了。你都说你还没看视频,这样的猜测有意义吗。
恰恰相反,他从一开始就强调环境问题。你可以看我翻译的测试策略部分,整个讨论就是从不同的应用环境开始的,并且贯穿整个教程。
首先,他经历过什么样的环境和你猜测的他的观点“测试的目的是发现bug”两者没有因果关系。
然后,他这里讲的就是代码的覆盖率,而你把代码,接口和功能三个方面当做是覆盖率。这里的问题,并不是他不知道“接口和功能”的覆盖,而是“同一个词对于不同环境的人往往有不同的意义”。我们不能说谁的定义对谁的定义错。但是你要知道,他在讲A问题,你在讲B问题。你们在讲不同的问题,你们所谈论的问题的正确与否没有互相之间的直接关系。
第三,也是最重要的, 你猜测道:“而他的观点更趋向于:“测试的目的是发现bug”,所以他将太高的覆盖率作为一种资源浪费来看待。”我想任何一个测试人员都不应该把自己的猜测言之凿凿的当做真事儿这样说出来,你可以说: 我猜测xxxxxx。事实上你看完作者的视频就知道他有专门讲测试的目的,远远不仅仅是发现bug而已。比如,你在一个刚刚启动的项目中,你的测试目的可能是发现项目中隐藏的风险。再比如,你在做一个有着严格需求定义说明书的项目时,你的测试目的也不是发现更多的bug,而是确保程序按照需求定义说明书来运行。等等。这都是作者举过的例子。
我想,测试人员工作的一个基本准则就是凡事都不能想当然。
请问,你报bug的时候能凭自己的猜测来报bug吗。建议你理解原作者的意思之后再发表意见。或者有哪部分不能理解的我们可以讨论。但是凭自己的猜测,来讨论原作者的局限性,这就不可取了。你都说你还没看视频,这样的猜测有意义吗。
恰恰相反,他从一开始就强调环境问题。你可以看我翻译的测试策略部分,整个讨论就是从不同的应用环境开始的,并且贯穿整个教程。
首先,他经历过什么样的环境和你猜测的他的观点“测试的目的是发现bug”两者没有因果关系。
然后,他这里讲的就是代码的覆盖率,而你把代码,接口和功能三个方面当做是覆盖率。这里的问题,并不是他不知道“接口和功能”的覆盖,而是“同一个词对于不同环境的人往往有不同的意义”。我们不能说谁的定义对谁的定义错。但是你要知道,他在讲A问题,你在讲B问题。你们在讲不同的问题,你们所谈论的问题的正确与否没有互相之间的直接关系。
第三,也是最重要的, 你猜测道:“而他的观点更趋向于:“测试的目的是发现bug”,所以他将太高的覆盖率作为一种资源浪费来看待。”我想任何一个测试人员都不应该把自己的猜测言之凿凿的当做真事儿这样说出来,你可以说: 我猜测xxxxxx。事实上你看完作者的视频就知道他有专门讲测试的目的,远远不仅仅是发现bug而已。比如,你在一个刚刚启动的项目中,你的测试目的可能是发现项目中隐藏的风险。再比如,你在做一个有着严格需求定义说明书的项目时,你的测试目的也不是发现更多的bug,而是确保程序按照需求定义说明书来运行。等等。这都是作者举过的例子。
欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) | Powered by Discuz! X3.2 |