51Testing软件测试论坛

标题: 测试的定位 [打印本页]

作者: willyenillye 时间: 2012-12-28 11:34
标题: 测试的定位
其实这些话并非官方定义，而是我这些年来的经验总结，之所以发在这里，实在是因为找不到更好的板块，有些东西还是希望从新手阶段就认清楚，对以后的发展会有好处。

警告：以下内容有可能引起各位思维混乱，务必当作学术研究，头脑风暴，而不可当作金科玉律，否则死了不管埋。

测试人员经常会遇到这样的问题，尤其是在面试的时候：

软件测试的目的是什么？为什么要有软件测试？

我刚刚参加测试工作的时候就被问到这个问题，当时的回答是不知道，哈哈。

另一个让人很尴尬的问题是：当软件出了问题，经常会有人说，你们做测试的是干什么吃的？

本文力图让你明白，你没那么伟大，也没那么全能，我们都只是测试员而已。

去年跳槽，被一个测试经理面试，她先问的不是这个问题，而是：你如何保证产品质量？

我当时就头大了，本着负责的态度，只能从头讲起，从软件的本质，到软件生命周期，到开发模式，到各个阶段的质量保证，测试被抽象成一个小步骤。我讲完了，小姑娘听蒙了。

然后她继续按照模板问下一个问题，直到她问，软件测试的目的是什么？

我想了想，试着说帮助开发组提高产品质量？她说对啊，你如果早说不就明白了？

于是我也明白了，我和她对软件测试的认识根本不一样，以至于她认为很简单的一个问题，对于我来说非常的复杂。

很冗长的前言，但是很重要，这体现了通常对软件测试的认识与我的认识有多大的差别。

软件测试是什么？软件测试是质量保证体系的一部分。CMMI中对产品质量保证工作有两个过程，验证和确认，简称V&V。二者非常类似，在其实践和子实践中，使用两种方法，一个叫做软件测试，另一个叫做同行评审。

在瀑布式模型中，软件生命周期分为需求，设计，开发，测试，部署五大阶段。

于是你明白歧义在哪儿了，有两个软件测试，一个是测试组实施的软件测试活动，另一个是作为项目的一个阶段由整个项目组一起实施的软件测试。

这两个软件测试的目的截然不同，而正是由于这种模棱两可，致使很多人误解了软件测试。

好吧，分析也够冗长的。如果你足够耐心，我们可以继续往下写：

整个项目组一起实施的这个测试阶段，其目的就是保证产品质量符合需求规格和行业规格。这个过程是通过不断提高产品质量实现的，其中包括BUG修复，代码重构，调试，测试，评审，试运行等等。所以当初我遇到的那个让我尴尬的问题，提问者预设的答案就在这里。

可是还记的那个问题是什么么？“你如何保证产品质量？”

质量保证啊，在CMMI里我只能给她讲V&V的过程，贯穿项目始终啊，从投标阶段就开始的技术委员会评审，到上线后商业beta，哪能光靠一个小小的测试阶段啊？（还好明确了产品质量，否则连过程质量都讲，那他么就得面试个两三天）

而软件测试，不过是质量保证体系与生产体系的一个小小的交集，将这么大的任务交给测试组，俺们肩膀稚嫩，担当不起啊。

上面说了软件测试阶段的目的，那么，软件测试的目的是什么？

很多软件测试的书籍里都会谈到这个问题，标准答案出现在很多公司的面试题里：

为了找BUG

而就在刚刚我在本论坛下载的一个软件测试用例编写的指导文章里，也如此说：

一个好的测试用例能够发现从未发现的BUG

我最开始也是这么信的。可是随着我做的工作越来越多，我参与到编写标书，参与到需求分析，参与到系统设计，参与到代码开发，参与到与客户谈判，参与到项目验收，参与到项目管理，我发现，这说法简直就是蒙人。

这种说法对于一个初级测试员那是足够了，因为初级测试员就是用例执行者，对于他们来说，能够理解用例，执行用例，发现产品缺陷，已经完成了本职工作。

但是当我们这样思考：如果以发现产品缺陷为目的组织测试工作，那么测试阶段的准出标准是什么呢？

预计项目上线还有一个星期，系统Major级的bug尚未修复完成，每周仍然有3-5个产生，这个时候，是应当继续测试继续修改，还是果断结束测试过程，提前交付呢？

这是产品经理和项目经理头疼的事情。经过严格质量培训的测试经理永远会说，不。

可是实际情况经常是强行上线。

当你每次的意见都只能被忽略的时候，那只能说明你的意见没有价值，不断产生没有价值的意见，说明你的思维有问题。项目组并不需要只能提出毫无价值意见的人，所以我们必须反思，究竟哪儿出问题了。

那么项目经理的思维是什么样的？简单说，铁三角，质量进度成本。质量只是一个维度啊亲，如果产品无法按时上线，项目团队，产品团队都会受影响。有些问题在需求分析时就已经注定了，在测试阶段去修复是不可能完成的任务啊，单是成本就让人抓狂。

所以，作为一个测试经理的你，也只是找BUG而已么？

软件测试是质量体系与生产体系的交集，在生产团队中的测试团队，必须同时考虑生产和质量，而不是单纯的找BUG。如果只是找BUG，那么如果软件未来出现BUG，测试团队就应当为此负全责，你的职责就是找BUG，你居然没找到？

第三方测试经常做得如此僵硬，硬拖着产品不让上线，结果等出现BUG了，测试经理就开始绞尽脑汁去想借口，什么全面测试是不可能的啊，这个缺陷不在需求里啊等等等等。

没那个金刚钻，你早干嘛去了，揽这个瓷器活儿？

前面说了，测试阶段是整个项目团队合作，通过不断提高产品质量的方式保证产品质量。测试团队在这个过程中承担什么样的角色呢？

产品质量的评估者。Evaluation

我们只能做到评估，也只做评估。任何超出这个工作之外的事情我们做不了，也不应该做。测试团队应当对评估的质量负责，而非对产品质量负责。产品质量在开发交付的那一刻已经确定，测试团队无法对其质量做任何更改。

一个合格的测试经理，提交的合格的测试报告，应当是一次完整的评估。其中包括产品生产过程背景回顾，产品质量分析以及测试过程质量分析。

作为一个测试员，当他设计测试用例的时候，应尽可能对整体评估负责。用例优劣的评估标准并不是它能找到某个BUG，而是它以最小的冗余对需求实现了最大的覆盖。

否则你为了寻找缺陷设计了一大堆极限条件的用例，而让正常业务分支未能覆盖完全，这就是失职。测试成本是有限的，时间有限，工作量有限。对于随机测试来说，可能只要为了能找到bug，测试人员在头脑中设计出了各种极端用例，但对于一次软件测试活动的主体来说，必须保证产品整体在某个层次上是合格的。

为了论述这个观点，我用了如此之长的篇幅。而当你去面试的时候，往往对方不会给你这个机会。而且，老观点根深蒂固，你也未必能说服对方。所以，如果真的去赌了说了，我可不管埋。

作者: 赵佳乐SMILE 时间: 2012-12-28 11:51
好长好长不过这一点同感

预计项目上线还有一个星期，系统Major级的bug尚未修复完成，每周仍然有3-5个产生，这个时候，是应当继续测试继续修改，还是果断结束测试过程，提前交付呢？

这是产品经理和项目经理头疼的事情。经过严格质量培训的测试经理永远会说，不。

可是实际情况经常是强行上线。

作者: 赵佳乐SMILE 时间: 2012-12-28 11:52
不过我觉的每周3-5个好幸福啊我们每天5个

作者: 赵佳乐SMILE 时间: 2012-12-28 12:01
记得我刚进这个项目组的时候它所有的长度都没有限制然后写用例

我就问了一个前辈我说长度还要不要测啊它整个都没限制

前辈说当然要啊然后我傻呵呵的问为什么呢？答曰：安全

是啊如果我们不会安全性测试还不做这种极限测试我们怎么保证安全啊

作者: 愚人 时间: 2012-12-28 12:29
写了好长啊，慢慢看……

作者: 六月天 时间: 2012-12-28 13:27
写挺好的，“评估者”这个定义我个人比较同意。

作者: soul0412 时间: 2012-12-28 13:35
写的挺好的。。
让我更明确了一些。

作者: willyenillye 时间: 2012-12-28 15:02
回复 4# 赵佳乐SMILE

长度限制是一个方面，在业务流程面前，是次要的工作。如果你设计了300个用例，其中100是业务用例，200是类似长度限制的标准用例，然后你的时间只够你执行100个的，你要如何选择？

生产管理，就是如何让生产在有限的条件下产出最多的产品。测试管理，就是在有限的资源条件下产生尽可能全面准确的评估。

作者: piaomiaoheng 时间: 2012-12-29 00:21
楼主的想法是作为一个测试经理的思维。测试是作为一种风险评估。为产品的提供风险依据。由产品PDT经理决定是否可以发布。

作者: piaomiaoheng 时间: 2012-12-29 00:25
标题: 标题
测试本来就是一种风险评估。如果仅仅说是发现问题，只能你还停留在测试执行的阶段。并没有理解测试在产品中位置。

作者: fengerapple 时间: 2013-1-25 17:38
Thank you very much for sharing!The good man!The good life of peace!

作者: smile511 时间: 2013-11-20 13:17
赞同lz，如果测试只是单纯的找BUG，你会发现慢慢整个项目会被测试拖死，测试只是一个稍有点专业基础的用户，更多的应站在用户的角度对产品的做出评估

作者: shangwu2272 时间: 2013-11-22 11:37
太长了

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)