51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 3008|回复: 12
打印 上一主题 下一主题

[原创] 测试的定位

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2012-12-28 11:34:07 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
其实这些话并非官方定义,而是我这些年来的经验总结,之所以发在这里,实在是因为找不到更好的板块,有些东西还是希望从新手阶段就认清楚,对以后的发展会有好处。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

为了找BUG

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

产品质量的评估者。Evaluation

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

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

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

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

为了论述这个观点,我用了如此之长的篇幅。而当你去面试的时候,往往对方不会给你这个机会。而且,老观点根深蒂固,你也未必能说服对方。所以,如果真的去赌了说了,我可不管埋。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

  • TA的每日心情
    开心
    7 天前
  • 签到天数: 1197 天

    连续签到: 2 天

    [LV.10]测试总司令

    2#
    发表于 2012-12-28 11:51:21 | 只看该作者
    好长 好长 不过这一点同感

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

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

    可是实际情况经常是强行上线。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    7 天前
  • 签到天数: 1197 天

    连续签到: 2 天

    [LV.10]测试总司令

    3#
    发表于 2012-12-28 11:52:38 | 只看该作者
    不过我觉的 每周3-5个好幸福啊 我们每天5个
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    7 天前
  • 签到天数: 1197 天

    连续签到: 2 天

    [LV.10]测试总司令

    4#
    发表于 2012-12-28 12:01:20 | 只看该作者
    记得我刚进这个项目组的时候 它所有的长度都没有限制 然后写用例

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

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

    是啊 如果我们不会安全性测试还不做这种极限测试 我们怎么保证安全啊
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2012-12-28 12:29:45 | 只看该作者
    写了好长啊,慢慢看……
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2012-12-28 13:27:10 | 只看该作者
    写挺好的,“评估者”这个定义我个人比较同意。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2012-12-28 13:35:34 | 只看该作者
    写的挺好的。。
    让我更明确了一些。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
     楼主| 发表于 2012-12-28 15:02:52 | 只看该作者
    回复 4# 赵佳乐SMILE

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

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

    使用道具 举报

    该用户从未签到

    9#
    发表于 2012-12-29 00:21:16 | 只看该作者
    楼主的想法是作为一个测试经理的思维。测试是作为一种风险评估。为产品的提供风险依据。由产品PDT经理决定是否可以发布。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2012-12-29 00:25:27 | 只看该作者

    标题

    测试本来就是一种风险评估。如果仅仅说是发现问题,只能你还停留在测试执行的阶段。并没有理解测试在产品中位置。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2013-1-25 17:38:16 | 只看该作者
    Thank you very much for sharing!The good man!The good life of peace!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2013-11-20 13:17:19 | 只看该作者
    赞同lz,如果测试只是单纯的找BUG,你会发现慢慢整个项目会被测试拖死,测试只是一个稍有点专业基础的用户,更多的应站在用户的角度对产品的做出评估
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2013-11-22 11:37:05 | 只看该作者
    太长了
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-5-6 08:14 , Processed in 0.075644 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表