测试的定位
其实这些话并非官方定义，而是我这些年来的经验总结，之所以发在这里，实在是因为找不到更好的板块，有些东西还是希望从新手阶段就认清楚，对以后的发展会有好处。警告：以下内容有可能引起各位思维混乱，务必当作学术研究，头脑风暴，而不可当作金科玉律，否则死了不管埋。
测试人员经常会遇到这样的问题，尤其是在面试的时候：
软件测试的目的是什么？为什么要有软件测试？
我刚刚参加测试工作的时候就被问到这个问题，当时的回答是不知道，哈哈。
另一个让人很尴尬的问题是：当软件出了问题，经常会有人说，你们做测试的是干什么吃的？
本文力图让你明白，你没那么伟大，也没那么全能，我们都只是测试员而已。
去年跳槽，被一个测试经理面试，她先问的不是这个问题，而是：你如何保证产品质量？
我当时就头大了，本着负责的态度，只能从头讲起，从软件的本质，到软件生命周期，到开发模式，到各个阶段的质量保证，测试被抽象成一个小步骤。我讲完了，小姑娘听蒙了。
然后她继续按照模板问下一个问题，直到她问，软件测试的目的是什么？
我想了想，试着说帮助开发组提高产品质量？她说对啊，你如果早说不就明白了？
于是我也明白了，我和她对软件测试的认识根本不一样，以至于她认为很简单的一个问题，对于我来说非常的复杂。
很冗长的前言，但是很重要，这体现了通常对软件测试的认识与我的认识有多大的差别。
软件测试是什么？软件测试是质量保证体系的一部分。CMMI中对产品质量保证工作有两个过程，验证和确认，简称V&V。二者非常类似，在其实践和子实践中，使用两种方法，一个叫做软件测试，另一个叫做同行评审。
在瀑布式模型中，软件生命周期分为需求，设计，开发，测试，部署五大阶段。
于是你明白歧义在哪儿了，有两个软件测试，一个是测试组实施的软件测试活动，另一个是作为项目的一个阶段由整个项目组一起实施的软件测试。
这两个软件测试的目的截然不同，而正是由于这种模棱两可，致使很多人误解了软件测试。
好吧，分析也够冗长的。如果你足够耐心，我们可以继续往下写：
整个项目组一起实施的这个测试阶段，其目的就是保证产品质量符合需求规格和行业规格。这个过程是通过不断提高产品质量实现的，其中包括BUG修复，代码重构，调试，测试，评审，试运行等等。所以当初我遇到的那个让我尴尬的问题，提问者预设的答案就在这里。
可是还记的那个问题是什么么？“你如何保证产品质量？”
质量保证啊，在CMMI里我只能给她讲V&V的过程，贯穿项目始终啊，从投标阶段就开始的技术委员会评审，到上线后商业beta，哪能光靠一个小小的测试阶段啊？（还好明确了产品质量，否则连过程质量都讲，那他么就得面试个两三天）
而软件测试，不过是质量保证体系与生产体系的一个小小的交集，将这么大的任务交给测试组，俺们肩膀稚嫩，担当不起啊。
上面说了软件测试阶段的目的，那么，软件测试的目的是什么？
很多软件测试的书籍里都会谈到这个问题，标准答案出现在很多公司的面试题里：
为了找BUG
而就在刚刚我在本论坛下载的一个软件测试用例编写的指导文章里，也如此说：
一个好的测试用例能够发现从未发现的BUG
我最开始也是这么信的。可是随着我做的工作越来越多，我参与到编写标书，参与到需求分析，参与到系统设计，参与到代码开发，参与到与客户谈判，参与到项目验收，参与到项目管理，我发现，这说法简直就是蒙人。
这种说法对于一个初级测试员那是足够了，因为初级测试员就是用例执行者，对于他们来说，能够理解用例，执行用例，发现产品缺陷，已经完成了本职工作。
但是当我们这样思考：如果以发现产品缺陷为目的组织测试工作，那么测试阶段的准出标准是什么呢？
预计项目上线还有一个星期，系统Major级的bug尚未修复完成，每周仍然有3-5个产生，这个时候，是应当继续测试继续修改，还是果断结束测试过程，提前交付呢？
这是产品经理和项目经理头疼的事情。经过严格质量培训的测试经理永远会说，不。
可是实际情况经常是强行上线。
当你每次的意见都只能被忽略的时候，那只能说明你的意见没有价值，不断产生没有价值的意见，说明你的思维有问题。项目组并不需要只能提出毫无价值意见的人，所以我们必须反思，究竟哪儿出问题了。
那么项目经理的思维是什么样的？简单说，铁三角，质量进度成本。质量只是一个维度啊亲，如果产品无法按时上线，项目团队，产品团队都会受影响。有些问题在需求分析时就已经注定了，在测试阶段去修复是不可能完成的任务啊，单是成本就让人抓狂。
所以，作为一个测试经理的你，也只是找BUG而已么？
软件测试是质量体系与生产体系的交集，在生产团队中的测试团队，必须同时考虑生产和质量，而不是单纯的找BUG。如果只是找BUG，那么如果软件未来出现BUG，测试团队就应当为此负全责，你的职责就是找BUG，你居然没找到？
第三方测试经常做得如此僵硬，硬拖着产品不让上线，结果等出现BUG了，测试经理就开始绞尽脑汁去想借口，什么全面测试是不可能的啊，这个缺陷不在需求里啊等等等等。
没那个金刚钻，你早干嘛去了，揽这个瓷器活儿？
前面说了，测试阶段是整个项目团队合作，通过不断提高产品质量的方式保证产品质量。测试团队在这个过程中承担什么样的角色呢？
产品质量的评估者。Evaluation
我们只能做到评估，也只做评估。任何超出这个工作之外的事情我们做不了，也不应该做。测试团队应当对评估的质量负责，而非对产品质量负责。产品质量在开发交付的那一刻已经确定，测试团队无法对其质量做任何更改。
一个合格的测试经理，提交的合格的测试报告，应当是一次完整的评估。其中包括产品生产过程背景回顾，产品质量分析以及测试过程质量分析。
作为一个测试员，当他设计测试用例的时候，应尽可能对整体评估负责。用例优劣的评估标准并不是它能找到某个BUG，而是它以最小的冗余对需求实现了最大的覆盖。
否则你为了寻找缺陷设计了一大堆极限条件的用例，而让正常业务分支未能覆盖完全，这就是失职。测试成本是有限的，时间有限，工作量有限。对于随机测试来说，可能只要为了能找到bug，测试人员在头脑中设计出了各种极端用例，但对于一次软件测试活动的主体来说，必须保证产品整体在某个层次上是合格的。
为了论述这个观点，我用了如此之长的篇幅。而当你去面试的时候，往往对方不会给你这个机会。而且，老观点根深蒂固，你也未必能说服对方。所以，如果真的去赌了说了，我可不管埋。 好长 好长 不过这一点同感
预计项目上线还有一个星期，系统Major级的bug尚未修复完成，每周仍然有3-5个产生，这个时候，是应当继续测试继续修改，还是果断结束测试过程，提前交付呢？
这是产品经理和项目经理头疼的事情。经过严格质量培训的测试经理永远会说，不。
可是实际情况经常是强行上线。 不过我觉的 每周3-5个好幸福啊 我们每天5个 记得我刚进这个项目组的时候 它所有的长度都没有限制 然后写用例
我就问了一个前辈 我说长度还要不要测啊 它整个都没限制
前辈说 当然要啊 然后我傻呵呵的问 为什么呢？ 答曰：安全
是啊 如果我们不会安全性测试还不做这种极限测试 我们怎么保证安全啊 写了好长啊，慢慢看…… 写挺好的，“评估者”这个定义我个人比较同意。 写的挺好的。。
让我更明确了一些。 回复 4# 赵佳乐SMILE
长度限制是一个方面，在业务流程面前，是次要的工作。如果你设计了300个用例，其中100是业务用例，200是类似长度限制的标准用例，然后你的时间只够你执行100个的，你要如何选择？
生产管理，就是如何让生产在有限的条件下产出最多的产品。测试管理，就是在有限的资源条件下产生尽可能全面准确的评估。 楼主的想法是作为一个测试经理的思维。测试是作为一种风险评估。为产品的提供风险依据。由产品PDT经理决定是否可以发布。
标题
测试本来就是一种风险评估。如果仅仅说是发现问题，只能你还停留在测试执行的阶段。并没有理解测试在产品中位置。 Thank you very much for sharing!The good man!The good life of peace! 赞同lz，如果测试只是单纯的找BUG，你会发现慢慢整个项目会被测试拖死，测试只是一个稍有点专业基础的用户，更多的应站在用户的角度对产品的做出评估 太长了
页:
[1]
