质量管理 关于测试和测试人员

liuxue.gu@hotmail.com · 2012年04月10日 · 1 次阅读

本文的作者 Sriram Krishnan 是一名程序员,曾在 Yahoo 和微软工作过,开发过很多软件,曾被纽约时报报道,写过一本书,本文是他的一篇博客。

这些年来,我对测试工作、测试人员,以及整个软件质量管理体系形成了一些明确的观点。受一篇关于 Facebook 的测试的帖子的启发,我想把这些写下来,用以拿给人看。有些观点是有争议的。事实上,即使在交谈中稍微表现出这样的看法,都会招致人们的鄙视。

大多数的开发团队并不需要一个独立的测试角色。即使有一个,他的所有的开发时间比上所有的测试时间应该 >20:1。证据吗?光看看一些从古至今最成功的软件开发团队就知道了。不论是当今的 Facebook,还是 30 年前最初的 NT 团队,很多伟大的产品都是出自没有或很少测试人员的团队。

开发人员应该测试自己的代码。没什么可说的。背后的道理并不重要。这包括单元测试,全覆盖的自动化测试或手工测试或组合测试。如果你的开发人员不能/不愿意或认为这 “不归我管”,那你需要更好的程序员。

我有一些政治上不正确的话要说。一些大型的软件开发公司会从一些不能胜任开发工作的程序员中选择测试人员。我经历/听说过很多在面试开发人员过程中有人说 “他/她做开发不行。也许可以做测试?” 这导致了一个被广泛默认,但很少公开宣称的认识:做测试的不如做开发的聪明。正是由于这普遍的偏见,少数一些对质量和测试工作极具热情和天赋的人受到了不公平的待遇。我知道他们,因为我曾经和一些这样的人一起工作过。

追求代码测试覆盖率是危险的。因为它很容易测量,它经常会变成真正目标的替代品——开发有质量的软件。如果你的开发团队把功夫都用在写愚蠢的测试,来覆盖每一个罕有能用到的代码路径——因为这些数据会出现在一些报告里——你有问题了。测试覆盖率只是我们用的的很多指标中的一个,你需要使用它,但并不是因为它以自然的数字呈现,它就能压倒其它指标。它成了古德哈特定律的牺牲品。

我也曾看到有些公司里有独立的测试人员,他们写出非常好的测试代码。不幸的是,这被人们当成了一种常识,即使是在根本不需要这样的时候。

正像测试覆盖率被过度使用,有些质量指标是被忽略轻视了。比如:过程中产生了多少技术支持邮件?自己是否在任何时候都在真正的使用自己的产品,检测里面的问题?分析从生产环境和客户安装那里产生的日志文件。所有的这些策略都在上面的 Facebook 的帖子里有提到过。

技术领导的一个常见的减少测试队伍的体积的办法是做自动化测试。这是个巨大的错误。如果你有一个用户直接接触的产品,你绝对需要用人眼去测试它。如果你和微软 Windows 团队的人坐下来一起和咖啡,你会听到他们抱怨过度依赖自动化测试导致了 Windows Vista 大量的 bug。这个错误说明的问题就是:你需要一个全职的测试人员来使用你的产品。

[本文英文原文链接:On testers and testing ] http://sriramk.com/blog/2012/01/testing.html

我们需要专职的 QA 吗?

陈皓 转自:http://coolshell.cn/articles/6994.html 这个文章必然是有争议的,我在我的微博上讨论过很多次了,每次都是很有争议的。有不同的观点,有争论总是一件好事,这样可以引发大家的思考。所以,对于我的这篇博文,如果你赞同我的观点,我会感到高兴,如果你会去认真地深入思考,我也会高兴,如果你反对,没关系,可以讨论。

在此之前,我想说明一下我观点里的这个 “专职 QA” 是怎么定义的。

其是很多公司成立的专门做测试的技术人员,仅测试不开发。 这些 QA 对于软件开发技术并不熟悉,甚至不懂。 我经历过一些公司都有专职的 QA 团队(专职的测试人员),自从上个公司我的开发团队在一个项目上被 QA 部门搞得一团糟,我越来越怀疑专职 QA 存在在意义。我的观点不一定对,但请让我鲜明地表达一下——我觉得是不需要全职的 QA 的,甚至不需要 QA 这一专职角色或部门,因为,不懂开发的人必然做不好测试。就像不懂开发的研发经理必然管不好研发团队一样。我越来越觉得 Dev 应该应该是做测试最合适的人选,这必然是未来的趋势(因为我已经看到了中国程序员的进步,相比起 10 年前,今天的程序员已经是非常全面了,再来十年,必然证明我的观点是对的)。

在我正在展开说明之前,我想引用两篇文章:

两篇文章

一篇是 “On testers and testing”(中文翻译),本文的作者 Sriram Krishnan 是一名程序员,曾在 Yahoo 和微软工作过,开发过很多软件,曾被纽约时报报道,写过一本书,本文是他的一篇博客。他在文章中表达了这几个观点——

大多数的开发团队并不需要一个独立的测试角色。即使要有,那么所有的开发时间比上所有的测试时间应该 >20:1 的。。证据吗?光看看一些从古至今最成功的软件开发团队就知道了。不论是当今的 Facebook,还是 30 年前最初的 NT 团队,很多伟大的产品都是出自没有或很少测试人员的团队。

开发人员应该测试自己的代码。没什么可说的。背后的道理并不重要。这包括单元测试,全覆盖的自动化测试或手工测试或组合测试。如果你的开发人员不能/不愿意或认为这 “不归我管”,那你需要更好的程序员。

另一篇文章是邹欣的 “现代软件工程讲义 9 测试 QA 的角色和分工”,这是一篇很不错的文章。他在文章里提到了分工的必要性,比如第三方的鉴定机构,并且也指出了分工的一些问题,比如,画地为牢的分工,无明确责任的分工,等,这些问题直接命中了分工的要害。我隐约觉得,我和邹欣的很多观点是相同的,我们内容上是相同的,只是形式上还有分歧。另外,我的观点太鲜明了,从而容易导向极端的理解。

你看,我们都同意,Dev 要懂测试,QA 要懂开发,只不过分工不同,既然你中有我,我中有你,那就不要分彼此了,一起携手开发测试吧。(另外,我个人觉得不懂开发的测试人员不可能测试得好)

—- update 2012/04/13 0:28—- {

【《对《我们需要专职 QA 吗?》的回应》作者:@ 段念 - 段文韬 】

}

我的故事

我再说说我最糟糕的 QA 经历吧,这个公司的 QA 部门只做测试,他们的 leader 觉得所有的 test design 和 test 的过程都不需要 Dev 参与,他们是独立于 Dev 之外的部门,他们几乎不关心 Dev 的设计和实现,他们只关心能跑通他们自己设计的 test case。但是去执行 Test Case 的时候,又需要 Dev 的支持,尤其在环境设置,测试工具使用,确认是否是 bug 方面,全都在消耗着 Dev 的资源,最扯的是,他们对任何线上的问题不负责,反正出了问题由 Dev 加班搞定。

我有一次私自 review 他们的 test case 的时候,发现很多的 test case 这样写到 – “Expected Result:Make sure every thing is fine” ,WTF,什么叫 “Every thing is fine”?!而在 test case design 的时候,没有说明 test environment/configuration 是什么?没有说明 test data 在哪里?Test Case、Test Data、Test Configuration 都没有版本控制,还有很多 Test Case 设计得非常冗余(多个 Test Case 只测试了一个功能),不懂得分析 Function Point 就做 Test Design。另外,我不知道他们为什么那么热衷于设计一堆各式各样的 Negative Test Case,而有很多 Positive 的 Test Case 没有覆盖到。为什么呢,因为他们不知道开发和设计的细节,所以没有办法设计出 Effective 的 Test Case,只能从需求和表面上做黑盒。

在做性能测试的时候,需要 Dev 手把手的教怎么做性能测试,如何找到系统性能极限,如何测试系统的 latency,如何观察系统的负载(CPU,内存,网络带宽,磁盘和网卡 I/O,内存换页……)如何做 Soak Test,如何观察各个线程的资源使用情况,如何通过配置网络交换机来模拟各种网络错误,等等,等等。

测试做得也不认真,大量的 False Alarm,都是环境问题,比如:安装新版本后没有重启服务,没有使用新的配置文件,网络配置,等等,等等。

在项目快要上线前的一周,我又私自查看了一下他们的 Test Result,我看到 5 天的 Soak Test 的内存使用一直往上涨,很明显的内存泄露,这个情况发生在 2 个月前,但是一直都没有报告,我只好和我的程序员每天都加班到凌晨,赶在上线前解决了这个问题。但是,QA 部门的同学们就像没发生什么事似的,依然正常上下班。哎……

为什么会这样?我觉得有这么几点原因(和邹欣的观点一样)

给了 QA 全部测试的权力,但是没有给相应的责任, QA 没有体会过软件质量出问题后的痛苦(解决线上问题的压力),导致 QA 不会主动思考和改进。 QA 对 Dev 的开发过程和技术完全不了解,增加了很多 QA 和 Dev 的沟通。 QA 对软件项目的设计和实现要点不了解,导致了很多不有效的测试。 注:我无意在这里贬低 QA 的能力工作。只是我看到了 QA 因为没有参与开发的一些现实问题。

我的观点

邹欣对于分工出现的问题给出了两点解决方法:

充分授权和信任(Empower team members) 各司其职,对项目共同负责(Establish clear accountability and shared responsibility) 我的观点是,理论上正确,操作上太虚了。这就像我们国家喊的 “为人民服务” 的口号一样,没有具体的方法,根本无法落实。 我无意在这里贬低 QA 的工作,我也无意因为这个事走向另一个极端。但是,我在现在公司的经历,还有很多新兴公司的做法,我越来越觉得软件开发,真的不需要专职的 QA,更不需要只写代码不懂做测试的专职的 Dev。观点如下:

1)开发人员做测试更有效

开发人员本来就要测试自己写的软件,如果开发人员不懂测试,或是对测试不专业,那么这就不是一个专业的开发人员。 开发人员了解整个软件的设计和开发过程,开发人员是最清楚应该怎么测试的,这包括单元测试,功能测试,性能测试,回归测试,以及 Soak Test 等。 开发人员知道怎么测试是最有效的。开发人员知道所有的 function point,知道 fix 一个 bug 后,哪些测试要做回归和验证,哪些不需要。开发人员的技术能力知道怎么才能更好的做测试。 很多开发人员只喜欢写代码,不喜欢做测试,或是他们说,开发人员应该关注于开发,而不是测试。这个思路相当的错误。开发人员最应该关注的是软件质量,需要证明自己的开发成果的质量。开发人员如果都不知道怎么做测试,这个开发人员就是一个不合格的开发人员。

另外,我始终不明白,为什么不做开发的 QA 会比 Dev 在测试上更专业? 这一点都说不通啊。

2)减少沟通,扯皮,和推诿

想想下面的这些情况你是否似曾相识?

QA 做的测试计划,测试案例设计,测试结果,总是需要 Dev 来评审和检查。 QA 在做测试的过程中,总是需要 Dev 对其测试的环境,配置,过程做指导。 QA 总是会和 Dev 争吵某个问题是不是 BUG,争吵要不要解决。 无论发现什么样的问题,总是 Dev 去解决,QA 从不 fix 问题。 我们总是能听到,线上发生问题的时候,Dev 的抱怨 QA 这样的问题居然没测出来, QA 也总会抱怨 Dev 代码太差,一点也不懂测试,没怎么测就给 hand over 给 QA 了。 QA 总是会 push Dev,这个 bug 再不 fix,你就影响我的进度了。 等等,等等。 如果没有 QA,那么就没有这么多事了,DEV 自己的干出来的问题,自己处理,没什么好扯皮的。

而一方面,QA 说 Dev 不懂测试,另一方面 Dev 说 QA 不懂技术,而我们还要让他们隔离开来,各干各的,这一点都不利于把 Dev 和 QA 的代沟给填平了。要让 Dev 理解 QA,让 QA 理解 Dev,减少公说公有理,婆说婆有理的只站在自己立场上的沟通,只有一个方法,那就是让 Dev 来做测试,让 QA 来做开发。这样一样,大家都是程序员了。

3)吃自己的狗食

真的优秀的开发团队都是要吃自己狗食的。这句话的意思是——如果你不能切身体会到自己干的烂事,自己的痛苦,你就不会有想要去改进的动机。没有痛苦,就不会真正地去思考,没有真正的思考,就没有真正的进步。

在我现在的公司,程序员要干几乎有的事,从需求分析,设计,编码,集成,测试,部署,运维,OnCall,从头到尾,因为:

只有了解了测试的难度,你才明白怎么写出可测试的软件,怎么去做测试的自动化和测试系统。 只有自己真正去运维自己的系统,你才知道怎么在程序里写日志,做监控,做统计…… 只有自己去使用自己的系统,你才明白用户的反馈,用户的想法,和用户的需求。 所以,真正的工程师是能真正明白软件开发不单单只是 coding,还更要明白整个软件工程。只明白或是只喜欢 coding 的,那只是码农,不能称之为工程师。

4)其它问题

关于 SDET。全称是 Software Development Engineer on Test。像微软,Google, Amazon 都有这样的职位。但我不知道这样的职位在微软和 Google 的比例是多少,在 Amazon 是非常少的。那么像这样的懂开发的专职测试可以有吗?我的答案是可以有!但是,我在想,如果一个人懂开发,为什么只让其专职做测试呢?这样的程序员分工合理吗?把程序员分成两等公民有意义吗?试问有多少懂开发的程序员愿意只做测试开发呢?所以,SDET 在实际的操作中,更多的还是对开发不熟的测试人员。还是哪句话,不懂开发的人是做不好测试的。 如果你说 Dev 对测试不专业,不细心,不认真,那么我们同样也无法保证 QA 的专业,细心和认真。在 Dev 上可能出现的问题,在 QA 也也会一样出现。而出了问题 QA 不会来加班解决,还是开发人员自己解决。所以,如果 QA 不用来解决问题,那么,QA 怎么可能真正的细心和认真呢? 如果你说不要 QA 的话,Dev 人手会不够。你这样想一下,如果把你团队中现有的 QA 全部变成 Dev,然后,大家一起开发,一起测试,亲密无间,沟通方便,你会不会觉得这样会更有效?你有没有发现,在重大问题上,Dev 可以帮上 QA 的忙,但是 QA 帮不上 Dev 的忙。 第三方中立,你会说人总是测不好自己写的东西,因为有思维定式。没错,我同意。但是如果是 Dev 交叉测试呢?你可能会说开发人员会有开发人员的思维定式。那这只能说明开发人员还不成熟,他们还不合格。没关系,只要吃自己的狗食,痛苦了,就会负责的。 磨刀不误砍柴功。如果你开发的东西自己在用,那么自己就是自己天然的 QA,如果有别的团队也在用你开发的模块,那么,别的团队也就很自然地在帮你做测试了,而且是最真实的测试。 你可能会说吃狗食就是个笑话,因为如果是我,我把干烂的事,就离职走人了,让别人去吃我的狗食。这个在现实中的确会发生,也是很现实的。但是想一想,你为什么在一开始让他把事干烂了?另外,如果你的团队在设计评审和代码评审里没有把好关,让某人把事给干烂了,那么这个人的离职带来的问题还是这个团队来扛,于是整个团队都在吃自己的狗食,挺公平的。痛苦过一次,你的团队下次怎么干了,就不敢乱招人了,就不敢随意评审代码了,就不敢让人只做一块东西了。最终还是没有逃脱吃狗食的范畴。 关于系统集成测试。所谓集成测试,就是把多个开发团队开发的模块集中起来测试。因为开发人员可能无法看到全局,不了解别个团队的系统,所以需要有统管全局的专职的 QA 进行测试。对这个方面,我并不反对,在实际操作过程中,好像的确用专职的做集成测试的 QA 更有效一些。不过,这还是不能让我停止去思考两个问题,1) 如果开发人员看不到全局,他能开发出更好的软件吗?2)这个全职的做集成测试的 QA 难道不能是各个团队的骨干 Dev 来组成吗? 关于自动化测试。所谓自动化的意思是,这是一个机械的重复劳动。我想让测试人员思考一下,你是否在干这样的事?如果你正在干这样的事,那么,你要思考一下你的价值了。但凡是重复性比较高的机械性的劳动,总有一天都会被机器取代的。 关于线上测试。我们都知道,无论自己内测的怎么样,到了用户那边,总是会有一些测试不到的东西。所以,有些公司会整出个 UAT,用户验收测试。做产品的公司会叫 Beta 测试。无论怎么样,你总是要上生产线做真正测试的。对于互联网企业来说,生产线上测试有的在玩 A/B 测试,有的玩部分用户测试,比如,新上线的功能只有 10% 的用户可以访问得到,这样不会因为出问题让全部用户受到影响。做这种测试系统的人必然是开发人员。 好吧,我暂时写这么多,我会视大家的讨论再补充我的观点的。

—– update 2012/4/11—–

一些人觉得我是在泄私愤,我能够理解为什么我会被这样误解,但是没有关系,很多新东西新观点总是会被误解的,我坦然面对。请大家抛开这些情感因素,单纯的思考一下,没有专职 QA 的的团队架构是否有积极的意义在里面?

再补充一点,大家思考一下,QA 是保证质量的,但是很多 QA 是在做测试,软件质量是测试出来的吗?如果不从需求分析,软件设计,代码实现上做好控制,到测试的时候你还怎么保证质量呢?

(全文完)

对《我们需要专职 QA 吗?》的回应

作者:关河 转自:http://www.cnblogs.com/guanhe/archive/2012/04/12/response_to_do_we_need_qa.html

说实话,在我看来,左耳朵耗子的《我们需要专职的 QA 吗?》这篇文章的观点并不算过激。最多就是一篇从开发工程师的角度来商讨是否需要设立 “专门做测试的岗位”,让 “不熟悉或是不懂开发的人” 来做测试工作。如果这个问题摆在我的面前,在大多数情况下,我的答案可能和左耳朵耗子一样:“不需要”。 作为一个在测试行业工作了 10 多年的 “老人”,在这里赞同左耳朵耗子的观点似乎是对自己过去这么多年工作的否定,但实际上,正是因为有这么多年的经验,我才真正能够深刻的体会专职测试工程师在工作中的局限和不足。 为了避免本文引发类似 “混淆了 QA 和测试角色” 之类的毫无营养的评价,在下文中,我一概使用 “测试人员” 来指代从事 “专职测试” 工作的角色,那些喜欢拿 “QA 层次更高,是管过程的” 各位看管请自行绕道(顺便说一句,我在 google 的时候,是十分反感自己的团队被称作 QA 团队的,如果有人这样说,我一定会认真的纠正:“不,我们不是 QA,我们是测试工程师”,关于 google 有没有 QA,各位可以自行 google)。 “软件需要测试” 应该是不会有人反对的观点。问题是,设置专职的 “测试人员” 是否会比 “让开发做测试” 更能有效的做好测试。从 1998 年开始,在华为我开始了自己的测试生涯。关于为什么需要测试工程师,在我的测试工程师职业生涯中,听到得最多的是两种论调:其中之一是 “测试工程师需要的技能与开发工程师不同,测试工程师需要的是发现问题的能力”,另一种是 “开发人员无法保证产品质量,因此需要测试人员”。后一种论调其实是有很大的问题的,“开发人员无法保证质量” 不意味着测试人员就可以保证质量,在大多数企业中,说的不客气一点,“保证质量” 通常只是测试部门可以继续存在的表面上的理由而已。至于说到开发工程师与测试工程师所需技能的不同,这一点倒是存在的事实。在一个组织中,测试人员通常会花主要的精力去设计测试用例,评价覆盖度,尝试从不同的角度攻击应用,从表面上看,的确,测试和开发需要的技能很不同。 但是,我要问两个问题: 这些技能开发工程师不能具备吗? 设计测试用例,评价覆盖率这类工作是否真的需要专职的人员去做? 所谓的黑盒测试技术,有多大的难度?平心而论,一个智商正常的具有较好计算机基础的人,一个下午就能完全理解常用的黑盒测试技术,白盒测试技术也不会难到哪里去。只要开发工程师愿意,这些工作他们完全可以承担。只所以开发工程师没有承担这些任务,原因恐怕不是他们不能做,而是像在《我们需要专职的 QA 吗?》文章后的评论中某位做开发的仁兄说的那样:“如果有一个比较专业的 QA 来帮助我们,我们就能把自己的时间花在更有用的地方”。 社会分工的细化自然是提供效率的方式,但社会的发展并不只伴随着分工的细化,由于开发工具和开发基础的变化,分工的 “合并” 也是一个一直在持续的趋势。几年前,大多数公司都倾向于有单独分工的 “前端工程师” 和 “后端工程师”,但现在的趋势不也是在融合?至少,Facebook 就要求自己的工程师能同时承担前后端的任务,google 也是如此。测试工作和开发工作难道就不能融合?让开发人员做测试怎么就不行? 其实,《我们需要专职的 QA 吗?》中的不少观点我都非常赞同,鉴于左耳朵耗子已经写了这么大一篇,我就不再重复这些观点了,作为对这些观点的一些佐证,我来说说我自己经历过的几件事情。 故事 1 在 Google 中国的时候,我们团队负责的某个项目,开发工程师每天忙死忙活的加新功能,赶上线,整个团队的开发和 SET(Software Engineer in Test)都忙得不行。从传统的对测试工程师的角度来评价的话,这个团队唯一的一个 SET 工作得十分出色:她几乎能发现所有的缺陷,她几乎把自己所有的时间都投入到项目中去发现缺陷;她是整个开发团队最喜欢和最感激的人,因为 “没有她,这个产品简直不可能发布”。但是,这个产品在发布了一段时间后,每个 RC 的缺陷始终居高不下,这位尽职的 SET 几乎投入了全部时间和精力,仍然无法让这个产品的质量提高分毫。为什么?因为开发人员从来就没有意识到他们的代码有多烂!当有一个可以帮你发现所有错误的人的时候,我相信,你犯错的勇气一定会更大。这个问题最后是如何解决的?说起来很讽刺,解决这个问题的第一步就是让开发意识到 “你们需要自己为代码质量承担责任”,当这位 SET 改变工作方式,不再尝试把自己的业务时间全部投入来发现无尽的缺陷之后,开发人员立刻意识到自己遇到了大麻烦。然后,他们主动来找我商讨解决方案,当他们最终发现自己不得不改变自己的做法,自己来控制自己错误的时候,事情立刻开始好转。当他们的单元测试达到 40% 的覆盖率的时候,所有人都变得更轻松了。这位 SET 负责推动了单元测试,推动了为了让代码具有良好可测试性而进行的重构,设立了组织的代码提交规则(强制提交的新代码必须包含单元测试),然后,产品质量在接下来的一段时间内持续上升。 故事 2 Google 内部有一个 Test Certified 的认证,该认证是针对开发团队进行的。认证的主要要点都是基于单元测试覆盖率,基于持续集成建立的开发规则,自动化测试(以小测试为主)。这个认证分为 5 个级别,1 级最低,5 级最高。Test Certified 和 CMMI 一样有 5 个级别,可是出发点却大不相同。这个认证中涉及的全部事情都能(且主要是)由开发工程师搞定,越接近高的级别,需要的专职 SET 越少。(详细内容参见 James 最近出版的《How google test software》,虽然书中的观点有些和我不一致,但在 Test Certified 的描述上是完全没有问题的) 故事 3 最后一个故事是最近我遇到的一个测试工程师的故事。她从一开始就表明自己有很强的 “做自动化测试” 的意愿,因此,她所在的项目团队的技术负责人很高兴地给她分配了一些技术性的任务,包括使用工具监控应用的内存使用情况,找到一个方案能够方便的定位 crash 发生等等,谁知道这位测试工程师的第一反应是,“这难道不是开发工程师的活吗?”,在她看来,测试工程师完全不应该了解程序是如何工作的,所谓的自动化测试应该是 “使用某种手段把自己现在的手工劳动重复下去”。 专职测试人员是否毫无存在的必要?当然不是。至少,我们必须承认,在有些必须大量依靠 “体验” 进行测试的行业,如游戏行业中,专职的测试人员是有存在的必要的。但我想,在类似 google,facebook 这样的环境中(我猜测在左耳朵耗子所在的环境中也差不多),不能深刻理解开发和具有深入的开发技术的测试人员(SET)的确没太多价值。真诚的希望各位测试工程师在读左耳朵耗子的文章时,不要纠结于他的结论,而去看看他提到的问题,是不是真的切中了专职测试的痛处。至少对我来说,文章中提到的这些熟悉的问题每一个都能让我想起一些故事。 对于我从事了 10 多年的测试行业,即使我现在的角色有所变化,这个行业的每一个变动和变革都会让我关注。这种感情是不可能割舍的。所以,真诚的希望每一位测试的工作者,能够真正思考我们如何做的更好。测试和开发之间有更多配合,更多相亲相爱,把测试当成提高和推动质量的手段,不正应该是测试的方向吗?

明晰单元测试

作者:李云 原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。 http://yunli.blog.51cto.com/831344/832789

最近,身边的一位朋友因为需要在其单位与同事分享单元测试(Unit Test,UT)方面的知识,邀我对他所准备的 PPT 进行审阅。在审阅的过程中我发现,他在 PPT 中指出:“实际工作中,写好程序后对程序功能的调试就是一种单元测试”。由于我知道这位朋友并没有运用单元测试的经验,所以我问到:“你的这一认识是从哪里获得的?”,朋友答曰:“从网上搜来的”。无独有偶,这两天我在微博上看到了对单元测试相似的理解:“写好程序,编译完,跑一跑,看看写得对不对,这就是最简单的 UT 啊!”

对于我这混迹于软件行业超十载,且在工作中能经常娴熟运用单元测试的 “老鸟” 来说,看到这样的理解实在是 hold 不住了,觉得很有必要写一篇文章以正视听(希望后面的人能 “搜” 到这篇文章)。

之所以要做 “以正视听” 这件事,是因为我担心上面的解释让新人或没有单元测试经验的人产生一种幻觉 ——“哇,好赞诶,原来我每天都在做单元测试!” 这种幻觉带的后果,是这些人不去做真正的单元测试,且别人在说单元测试如何如何时,他却不知所云。

如果要用不会产生争议的文字解释单元测试,我想我不一定能写得比维基百科上的好(点击这里,或许参考我的《专业嵌入式软件开发》一书更好),那请允许我从特点的角度对之加以解释。首先,单元测试一定要写测试代码。测试代码并不会最终成为软件产品的一部分,测试代码通过实现各种不同测试用例的方式,检查被测代码(最终成为软件产品的一部分)的行为是否如程序员所希望的那样。读者不难想象,测试用例中需要构建大量被测代码所需的参数、环境等(体力活)。

其次,为了简化单元测试程序中测试用例的编写,单元测试一定需要使用一定的测试框架,比如 cxxtest、CppUnit、JUnit 等等。当然,使用自己设计的测试框架也是一种选择。

再次,单元测试通常(我本来想写成 “一定”,但又怕被指太绝对)需要通过获取代码覆盖报告这一形式以了解测试效果,来自开源社区的 gcov 和 lcov 相信被不少人所知。“代码覆盖” 是一个不小的 “炸弹”,乃至有的人会选择性地将其看成是 “形式主义”。对于有这样反应的人,我相信是因为他们吃过了 “代码覆盖” 这 “鸟” 的苦头,因为那帮丫领导将百分百的代码覆盖率当成了考核目标,结果可想而知。

代码覆盖报告的真正作用,是帮助程序员了解被测代码的哪些 “角落” 没有 “扫过”,从而指导测试用例的编写。如果一味地以百分百的代码覆盖率作为目标,这会让程序员承担巨大的工作压力。Parasoft(C++ Test 工具的开发商)的一份研究报告中指出,覆盖率超过大约 80% 时,团队所承担的工作压力就很重了,这一报告可作为制定具体覆盖率的参考。

另外,即使以百分百的代码覆盖率为实施目标,很遗憾,还是达不到完全保证代码质量的目的,因为测试用例是可以 “伪造” 的。在软件行业,不论有多么好的软件开发方法,都依赖于程序员的专业精神,否则其效果将大打折扣,这一点对于单元测试也不例外。与其追求百分百的覆盖率,强调测试用例的质量更具意义(OMG,如何保证测试用例的质量?)。还有,千万不要将单元测试当作是 “银弹”。

抱有 “我每天都在做单元测试” 幻想的程序员在幻想破灭以后,又会产生另一种错觉 —— “单元测试是测试人员的事”。我得对这类程序员说:“你不负责任”。程序员编写程序后验证其中没有任何缺陷是理所当然的事。什么?你没有遗留缺陷?怎么证明?单元测试!

当幻觉与错觉都远离我们以后,或许有的同仁会想:“单元测试就是一种测试!管它什么测试,目的都是为了保证软件质量的,那么在意其具体含义干吗呢?” 不,精确掌握各词的具体含义是为了我们能更高效地沟通!想一想,我们还有集成测试、系统测试,为什么要造出这些新词?

陈晔:致所有测试人员的信 http://site.douban.com/widget/notes/113383/note/203583809/

我两年多的测试生涯到头了。我想再这里总结一下点点滴滴。以及我也会说明我为什么选择离开。在中国有着很多很多的软件测试,很多迫于环境,迫于 leader,迫于很多原因,导致只是一个 “执行者”。以下只是我个人的一些经历。大家可以借鉴,也可吐槽,大家随意。 首先在测试的时候需要有一些心理暗示,其实未必是暗示,可能是给自己的一些自信。 第一:产品一定是有 bug 的。 无论你测试什么产品,一定是需要报有这样的心态。为什么?其实就如一句说的 “如果自己都不爱自己,那么就不要奢望别人来爱你”。如果连测试潜意识里面都觉得产品是没有 bug 的那么还能有谁认为产品是有 bug 的呢? 测试的历史上有两种验证方法,一种是测试是用来验证产品一定是没有 bug 的,一种是测试是用来验证产品是有 bug 的。无论哪种你都要有一种原则,要有一种信念。就如人生漫漫长路一样,我们必须坚信自己的梦想,坚信自己是能够成功的。那么才有可能,才有希望。当碰见挫折的时候,当迷茫的时候,才不会真的被打败。 一个新的 feature,一个刚刚 fix 的 bug,一个用户反馈,一个不起眼的问题。我们都需要坚信里面有缺陷的。没有任何一个产品,任何一个细节是完美的。 许多公司从上级到下属对于产品的质量根本没有概念,又或者对于质量不重视。在这种情况下,就需要测试产生力量,需要用各种事实依据去告诉公司,告诉大家这样一个产品质量的真想。国外的公司相对好点,国内有很多公司是需要有这种有责任感的测试存在。 第二,任何的 bug 都是能够 repro 的 无论你面对一个很小的功能测试,还是很复杂的场景化的测试,又或者说某个用户很简单明了的描述了一个问题。我们需要坚定不移的告诉自己,只要是一个 bug 就是有重现步骤的。 微软曾经有测试,一个问题的重现步骤长达 50 步。虽然可能不是最佳的步骤,但是依然对于解决问题起到了决定性的作用。 自然,在实际中很多情况下的确会碰见一下子找不到重现步骤的方法。找不到方法意味着什么?意味着你可以开 bug,dev 可以 fix 这个 bug。但是谁都不知道到底有没有真的修复这个问题。还可能因此出现很多 regression 的 bug。所以找到一个 bug 的 repro step 可以说是一个测试基本功也是体现价值的地方。 和第一点一样,只有你自己信念中去相信了,那么你才有可能成功。 第三,只相信自己看到的 在很多情况下,dev 或者同事会告诉测试 “这个功能很小,没有 bug 的”“简单测一下就好啦” 等等的话。我主张还是不要太相信任何一个人。 面对 bug,我们需要好好的理清问题的根源逻辑,在进行一个完全的测试之后告诉自己 “这个功能基本上不会有很大,或者很 block 用户的问题”;面对一个讨论,不要听到别人说什么就是什么,任何的决定都没有完全正确的。我们需要自己亲手去验证很多决定和设计,小到你可以 google,找出各种证据来证明某些事情。大到你可以进行用户数据搜集,很多企业不会去做。但是如果一个有 sense 的测试,我相信必须什么事情都亲手去实践去证明! 以上说了这么多,可能很多人觉得,这个还是测试么?ok,我认为真正的一个测试满足以上三点是远远不够的。以下是我认为一个有 sense 的测试,记住是有 sense 的测试需要做到的。 第一:探知精神 乐于学习 为什么我将这两个放在一起呢。两者密不可分。我所在公司是做 android 产品的。目前中国国内很多企业也是一样的问题,就是只是在乎自己的产品怎么样,并不会很关心你的发展。作为测试,必须有探知精神,必须乐于学习。比如你测试 A 平台的 B 产品,如果只是一味的测试,只是一味的报 bug。的确你会有进步,做任何一行你都会有进步,行行都能够出状元。但是几年光阴一过去,当别人或者自己问问自己,自己真的知道了多少?可能对于自己公司做的产品很了解之外,一无所知。那么这样对于自身发展又有什么好处呢? 探知,对于任何一个 design,任何一个 bug,任何一个细节都需要去探知。这样无论你做了多久,无论你是否做多少个项目都会依然有进步。时不时的问问自己,对于这个产品 feature 真的了解很透彻么?对于产品功能逻辑很清楚么?对于这个产品所在平台了解么?业内是不是主流的 tools 都清楚了呢?是不是自己已经没有了进步的余地了。这样自己会明了很多。 第二:责任 这点可能很多人会说,测试最基本的不就是责任么?没有责任怎么去做一个测试呢?是的,责任每个人都有,程度是不同的。你作为一个 tester,需要保证产品的质量。勿以 bug 小而不重视,本质上依然是不负责任的表现。 相反的,很多测试对于产品是负责了,对于自己却是不负责任的。因为他们只是一个傀儡,天天被人操控着。做这个做那个,我觉得这种是更加可悲的。 如果你作为一个 tester leader,那么你的责任不是去指挥别人做事情,不是去拍老板马屁。而是自己不要忘记进一步的学习,不要忘记对于任何的细节去了解。更不要忘记如果出了什么问题,自己勇于承担这个责任。真正的 leader 是什么?需要在流程以及技术上面有自己的 sense,需要不停的去完善项目流程,从而提高测试 team 的效率以及项目的效率。 第三:通过各种渠道找到 bug repro step bug 会从各个渠道发现。公司内部 bug bash 的时候,用户反馈的问题,自己找到的问题。老板发现的问题等等。这个时候能否找到 repro step 就是体现一个测试的价值所在了。 测试往往碰见的问题是这样的。突然发现一个问题,欣喜若狂!但是然后问问自己 “我刚刚做了什么”,基本上很多人都不知道。有的时候是有 log 可以取,但是 log 只是一个告诉开发如何 dev 去解决 bug 的。所以找出重现步骤才是王道。并非要时时刻刻保持警惕,可以有两个做法,一个就是自己在测试的时候留个心眼,养成时不时回忆自己做了哪些操作。一个就是养成一边测试一边记录 log 的方法,这个方法相对很保险,不过前提是自己需要有完全看得懂 log 的能力。 另外一类 bug 是从用户这里报出。用户一般是无知的,根本不会懂你产品的逻辑,可能描述出来的错误和真正的错误根本就是天差地别。这个时候就需要测试去按照经验以及各种方法去判断。判断出用户说的产品的真正的问题在哪里,然后使用各种方法(automation.etc)去模拟 bug 产生的环境。这样一来,bug 在修复的情况下能够在公司内部马上得到 confirm。这样无论是对于产品,用户,还是公司都是一种无限大的利益。 还有一类 bug 是公司同事报出的,或者是老板提出的。一般都是一句话 “这里有个很大的 bug”。木有任何细节,木有任何解释。 当然,总结一下来讲,一个测试就如同一个侦探,慢慢的寻找蛛丝马迹,慢慢的看到真相。能够找到这条路的人那么必然是一个有价值的测试。毋庸置疑。 第四:bug 定义 sense bug 到底是什么?是一种缺陷么?是的。那么测试产品 bug 这个行为是什么?我相信很多书本上面都没有定义过。 测试产品 bug 行为定义:是寻找产生 bug 过程的一种行为,是缩短人们用产品开始到产品发生 bug 的周期的一种行为。 所谓找出 bug,无非是一系列的操作序列造成了程序的缺陷或者崩溃。序列可能是几步,时间周期也可能是一年两年十年。那么测试产品 bug 不就是要在项目周期内尽量多的去寻找问题么?所以,其实本质就是,如果一个用户用一个产品十天才出现的一个 bug,那么测试就需要压缩这种时间,将其在很短的测试周期内发现这个缺陷。 方法有很多,模拟环境,使用各种已经有的 tools,使用各种 automation 进行测试,甚至自己写用户的一个环境等等。缩短用户发现 bug 的周期其实就是一种战斗,一场无止尽的斗争! 第五:UE UE,用户体验。很多人会说用户体验是 UI team 以及 UE team 的人需要了解的。但是往往这个 sense 对于测试是最最最为重要的。 所谓最高级的 bug,最有价值的 bug 就是贴近用户的使用习惯。但是如果一个测试没有 UE,那么你如何模拟用户操作?你用户是使用 windows 的,是用 mac 的,是用 android 的,是用 dvd 机的等等,而你一个都没有用过,你何以测试?你何以找到用户真正 care 的 bug?根本就是无稽之谈。 UE 的学习对于谁都是有利的,无论你是做什么产品的,你是什么职位上面的。UE 的学习是永无止境的。没有 UE 的测试只是 monkey test 罢了 第六也是最后一点:勇敢的去做 和第一点不同的是,测试这个职业在国内还是一个比较新的职业。很多测试本身都不知道测试到底是干什么的。更加不要说一些互联网产品的测试。很多领域根本就是没有被开发过。你要做的就是勇敢的去尝试。可能有一个 point,开始你的潜意识就觉得 level 太高,根本就是做不到的。但是你要去试试,不试试怎么知道不可能,勇于去做第一人。可能你做的事情就是别人没有做过的呢?要记住!你不去做总有人去做。我相信大家都希望自己成为第一人,而不是跟着别人的脚步再踏步踏。 目前只是想到这些,原本是想写工作回忆录的,却写成了这样一篇东西。真的惭愧。要不要写回忆录呢!纠结!!

段文韬:我们需要什么样的测试? 陈皓发表了《我们需要全职的 QA 吗?》后,一石激起千重浪,赞成者有之,激烈反对者有之;有人说文中对 QA 的定义不对,还有人说以偏概全…… 的确,在需不需要专职的 QA 角色这个问题上,很难用一个简单的 “需要” 或 “不需要” 来回答。前两天我写了一篇对该文的回应文章,但由于文章写就得比较仓促,很多观点来不及完整表述,因此,在 “真理越辩越明” 的原则下,在这篇文章中,我准备就 “我们需要什么样的测试” 这个问题说说我自己的看法。

首先要说明的是,这篇文章完全不是讨论 “我们是否需要专职 QA” 这个问题的,也不是讨论 “各种情况下 QA 或测试工程需要做什么”,而是从我自身对测试的认知和个人经验出发,说一说我对不同特点的产品需要的测试的看法。 本文讨论的前提是:“不同的产品需要不同的测试”。当我提到 “产品” 时,除了产品本身所对外展现的特性外,还会隐含地包含了该产品开发团队的状况。这篇文章没有把行业作为一个划分的维度,是因为我相信,即使在同一个行业中,也存在各种截然不同的产品。 测 试是为质量服务的,测试活动围绕质量进行。这个定义是我们今天讨论的出发点。ISO 9126 模型给出了一个多层次的质量模型定义,该定义包括了各个正交维度的质量属性,这些质量属性中既有面向用户的,也有面向开发的。但在实际的测试工作 中,一旦提到产品质量,大部分人更容易将其理解成 “用户质量”,也就是 “最终用户所能感受到的软件的质量(例如,软件的功能性、性能、安全性等等)”。 “用户质量” 是用户所能够直接感受到的产品的 “好坏”,也是用户是否愿意为产品付钱的主要原因。因此,在测试中重视 “用户质量” 是必然的。设想一下,如果 A 公司要为 B 客户开发一个软件,只要该软件最终能够达到 B 用户的要求,A 公司就能拿到钱,通常这也就意味着 A 公司 “成功的完成了该软件的开发”。从这个角 度来说,“用户质量” 就是软件开发是否成功的标准。 然 而,如果深入看待整个软件开发过程,事情就没有这么简单了。A 公司为客户 B 开发的软件并非是一锤子买卖,而是需要不断的维护和升级的,B 用户不断提出新的 需求,而这些新的需求都要被加入到软件中去。在这种情况下,从效益出发,A 公司就不能仅仅考虑最终的产出是否能够满足 B 客户的要求了,而是必须想办法保证 产品在持续演进的过程中始终保持好的可维护性和可测试性,这样 A 公司才能以较低的成本让这个产品持续成功。因此,如果不把软件开发看成一锤子买卖,而将该 软件的生命周期的维护过程考虑进去,我们就不得不关注 “用户质量” 之外的 “开发质量”,这里的 “开发质量” 就是指产品内在的,是否容易被修改、是否容易被 移植、是否容易被验证的特点。 1.“用户质量” 和 “开发质量” 就是我通常用来分析一个产品究竟需要什么样的测试的第一个因素。 在 这个维度下,我们可以很容易地理解,如果一个产品仅仅是 “一次性” 的产品(也即,开发后不再需要维护和持续演化),那么测试的重点一定就是 “用户质量”(只需要关心该产品是否在用户面前表现得够好就可以了); 代码是不是够烂,设计是不是不合理并不重要。而如果一个产品是需要持续演进较长时间的,那就必须关心代码和设计的质量(“开发质量”)。例如,一个采用付 费下载方式进行销售的小游戏,开发团队通常不会花太多的时间和精力在保证产品具有良好的 “开发质量” 上,而宁愿花更多的时间去调整外部的细节表现,音效, 图像上。

  1. 另一个直接决定了产品需要什么样的测试的纬度是 “产品对缺陷的容忍程度”。 测 试工程师有时候喜欢把 “零缺陷” 作为标榜测试工作的口号(我在很长一段时间内也是如此),但,仔细想想,如果发现一个缺陷的成本比让这个缺陷留在产品中带 来的损失更大,那是否还值得去发现这个缺陷?我想,从项目的角度来说,答案是不言而喻的。测试是一个资源权衡的活动,也是一个基于风险的活动,因此,产品 的缺陷带来的影响越小,影响越容易被消除(修复),这个缺陷的价值就越小,值得投入用来发现缺陷的资源也就越少。 拿 互联网产品和传统的桌面产品来比较,对桌面型产品来说,缺陷的修复成本足够高(只能通过软件召回或是发布补丁的方式),因此对缺陷的容忍度就低;而对于互 联网产品来说,由于其产品的修复成本足够低(对一个已知的缺陷,可能只需要花上几分钟到几十分钟就能完全修复了),因此相对而言,其对缺陷的容忍程度更高(当然,对于那些会导致用户数据损失或是带来其他不可逆破坏的缺陷,那又另当别论了),对互联网产品开发来说,及时识别缺陷(发现那些用户已经遇到的缺 陷),快速定位缺陷和快速修复缺陷的能力往往要比在系统测试阶段发现缺陷的能力更重要。而要能有强大的识别缺陷和定位缺陷的能力,就必须依靠产品内建的 “开发质量” 了。 再以医疗行业的某些软件为例,对涉及到医疗器械的控制软件(如自动注射器,心脏起搏器等),其对缺陷的容忍程度就非常低,原因很简单,因为这类缺陷可能带来的后果太严重。
  2. 第三个因素是 “有效的测试方式”。 对 互联网产品来说,最有效的测试方式也许并不是找一堆专职的测试工程师在公司内部尽可能地覆盖每一个功能细节,让真正的用户来对产品进行测试在很多情况下也 许是更好的选择。无论是 FB,Google 等公司提倡的 dog food(让全部员工来进行测试),还是在实际产品上进行的 a/b testing, 或是游戏公司通常喜欢采用的内测方式,都是典型的让用户参与测试的方法。另外,根据产品不同的特性,适合采用手工测试还是自动化测试的方式来进行测试也是 一个值得考虑的点。
  3. 第四个因素则是 “产品的开发团队所处的状况”,因此,对同一个组织来说,在组织发展的不同阶段,所需要的测试也是不同的。 “苦逼的团队是做不出有爱的产品的”,自然,“苦逼” 的团队也不可能达成好的测试。因为让每个人疲于奔命的是总也无法完成的任务和无止境的加班,恐怕都没有停下来思考如何改进的机会。 以 上就是我对 “什么样的产品需要什么样的测试” 这个问题的理解。在这四个因素的指导下,再回头来考虑不同软件产品的测试,就很容易理解为何不同的产品,不同 的企业会采用很不相同的测试方式。例如,FB 没有专职的测试工程师,因为通常意义上关注 “用户质量” 的测试工程师并不能在这个组织中发挥大的价值,只有对 开发有深入了解的开发工程师才能真正的在提高 “开发质量” 方面发挥作用。而对于许多国内的以 “做项目” 为主的软件企业来说,也就很好理解为什么他们只需要 “能像客户一样发现产品中的缺陷的” 的测试了。 参考: ISO 9126 质量模型:http://en.wikipedia.org/wiki/ISO/IEC_9126
需要 登录 后方可回复。