软件测试的理解

测试的角色 (Test) 要独立出来么 ?

独立出来的测试角色怎么才能发挥作用?

有些成功人士和成功的公司号称没必要有独立的测试角色 (Test), 你怎么看?

 

 

最近又看到一些关于开发人员要不要负责测试的讨论。 例如:

 

 http://www.aqee.net/on-testers-and-testing/

大多数的开发团队并不需要一个独立的测试角色。即使有一个，他的所有的开发时间比上所有的测试时间应该 >20:1。

[注: 这个翻译就有错误, 原文指 开发: 测试 的比例应该 > 20:1 ]

 

我正好在写相关的教案, 也来凑个热闹。

 

[这篇文章的一些事例来自于我曾经和现在的团队。 希望这些例子不足以影响相关人物和团队的伟大形象。   任何软件团队都会犯错误, 伟大的团队有勇气面对自己的错误并不断改进。]

 

 

首先, 明确两个概念:

软件测试 (Test)：运用定义好的流程，工具去验证软件能实现预先设计的功能和特性, 工作的流程和结果通常是可量化的, 例如, 测试用例, bugs, 代码覆盖率, MTTF, 软件效能的参数。 [注: 正因为流程和结果是可明确定义的, 可量化的,  很多测试工作可以自动化]

 

软件质量保证工作 (Quality Assurance)：软件团队的成员为了让软件达到事先定义的质量而进行的所有活动，包括测试工作。

 

对于这两个术语, 不同人有不同的定义,  有人认为它们是互通的, 在《现代软件工程》的上下文中我尽量使用上述的定义.

 

测试的角色 (Test) 要独立出来么 ?

回答:  首先,  我相信有分工是好事,  软件团队中应该有独立的测试 (Testing) 角色。所有人都可以参与QA 的工作 (报告bug 什么的),   但是最后要有一个角色对QA 这件事负责。 不但角色要独立，而且在最后软件发布的时候, 必须得到此角色的签字保证 （sign off）。我在微软参与的项目都是这样做的。

 

在开始论证之前,  先引用斯密特 ·亚当斯的 《国富论》 来暖场  (我没读过这本书,  直接从网上抄的)。

分工理论

亚当斯认为，分工的起源是由人的才能具有自然差异。… 假定个人乐于专业化及提高生产力，经由剩余产品之交换行为，促使个人增加财富，此等过程将扩大社会生产，促进社会繁荣，并达私利与公益之调和。 他列举制针业来说明。“如果他们各自独立工作，不专习一种特殊业务，那么他们不论是谁，绝对不能一日制造二十枚针，说不定一天连一枚也制造不出来。他们不但不能制出今日由适当分工合作而制成的数量的二百四十分之一，就连这数量的四千八百分之一，恐怕也制造不出来。”

 

分工促进劳动生产力的原因有三：第一，劳动者的技巧因专业而日进；第二，由一种工作转到另一种工作，通常需损失不少时间，有了分工，就可以免除这种损失；第三，许多简化劳动和缩减劳动的机械发明，只有在分工的基础上方才可能。

 

引用 <http://baike.baidu.com/view/53445.htm>

 

 

我们看团队形式的职业体育比赛, 各个位置的分工都很明确,  拿足球来说,  有专注进攻的, 有专注防守的,   但是在我的印象中,  那些伟大的前锋大多数只管一件事 -进攻。 亨利 （Thierry Henry）参加防守么? 

 

 

当然一些球赛也有没有分工的时候, 原因 有好几个:

事太小, 几个小孩踢个半场。

无知, 小孩们刚开始玩球。

人手不够,  一对一打篮球, 你要参与防守么?  沙滩排球，两人都是全攻全守。

 

如果你的软件团队做的事情和上面的情况类似, 那当然不必分工。你们做的很可能不是商用软件, 你的软件团队大概也不用受什么软件工程规律的束缚。 (参见: 软件工程概论).

 

任何产业产业成熟到一定阶段的时候, 独立的质量保证角色是不可避免的。团队内部有QA 角色, 团队外部也有独立的QA 角色。

 

拿药品和食品来做例子，  除了生产厂家自己的检测之外,  这些产品还要接受行业主管部门相关机构的检测和认可 (药品检验, 食品检验), 才能上市。 在出现争议的情况下, 还要第三方机构来进行测试或认证。

有人也许这样建议:  

这些药品都是药厂同一批工人一边制造一边测试出来的, 特别有保证!  不用测了,  赶紧吃了吧!  

也许还有人这样建议:

这个十字坡夫妻店的农家饭都是他们自己亲手做的, 很可信， 咱们今晚就去吃饭住一宿吧。

 

我们每天经常使用的电子产品,  从大彩电到电影插座,  也经历了很多团队内部的和外部的测试,  请随手拿过任何一个电器, 你会在背面看到密密麻麻的小字,  其中肯定有下列标记之一:

  

 

没有这些标记的产品电子产品, 市面上很少看到。  

 

在软件和互联网产业, 目前没有这些认证,  相反的,  倒是有“人肉认证” :

你想申请某个著名专业网站的账户或者邮箱, 但是又担心这个网站对用户信息的保护程度不够。有人说, 没关系的,  这个网站的创始人也用账户,  CTO , 总监什么的还经常发软件安全博客,   账户一定是非常安全的！  这里不存在独立的质量认证, 只能通过人肉 （创始人/CTO/总监）来认证产品的质量。  

 

其实这种认证未必安全…  （密码门事件） （明文密码事件）（邮箱密码漏洞）

 

如果有第三方的认证 “此网站对用户信息的保护程度是X级,  我们认证它不会明文存储用户密码… ” 我就放心了。 在第三方认证出现之前, 我希望团队内部至少有独立的QA 角色, 来确保软件的质量。否则我是不乐意使用这些软件/服务的。

 

[补充一句,  互联网服务的各种认证也在发展,  例如verisign 公司提供的各种认证。]

 

独立出来的质量保证角色怎么才能发挥作用?

有了独立的质保角色之后, 是不是万事大吉了?   未必,  分工意味着一件事要分给别人去工作。让别人做事, 并且依赖别人做出的结果,  这会出现一些问题。

 

问题：既然有专人负责, 那我就不用负责了!

生活中一个常见的歪理是,   既然有清洁工, 那我乱扔点儿垃圾算什么,  这才是他们工作啊!

 

尽管有专人负责QA 中的测试工作,  但是保证质量仍然是所有成员的职责。软件团队中的一些人往往在有意无意中忘记这一点。最常见的现象是开发人员写好一个功能之后,  迫不及待地宣布成功, 然后希望测试人员去发现所有问题。 如果问题在发布后才被发现,  开发人员会说 – 测试人员怎么搞的， 这种bug都没找出来!?

 

某项目的某功能有重要的改进,  这个改进经过研究员的研究， 开发人员的设计,  美工的美化,  两个开发人员的配合实现, 项目管理人员的督促,  测试人员的测试,  最后所有人都号称做好了,  上线了！  为此,  我约了某个目标用户给他做实地展示,  几天后,  大家都到齐了, 开始演示。开始进行的不错,  马上最重要的killer  feature  就会出来了 …   嗳,  预想的效果怎么还没出现呢?   再试试,  还没有?  各相关人员面面相觑,  大家小声说: 

“我不是把那个新模块给你了么？” 

“我就是照着那个接口实现的啊…”

“我不是已经交给那啥… ” 

“所有的bug 不是已经都搞定了么…”,

 

会议在尴尬中胜利结束了。

 

后来查问题的根源,  这个复杂的功能由于两个模块的接口在最后没有同步,  某重要的参数被忽略了,  这个功能中最出彩的部分压根就不可能工作!   那负责测试的角色怎么解释 "所有测试用例通过,  同意发布" 的呢?  

这还是开发人员引以自豪的 “杀手级功能”  (killer feature),  那其它普通的功能是什么命运呢?

回过头来, 我们可以问:

·         这件事真的要通过这么多环节么?   

·         测试人员真的知道最最关键的地方如何测试么?

·         在系统上线之后,  所有为这个功能感到自豪的人是否去实地测试过呢? 

 

 

一个开发人员应该负责下面“开发功能”右边的几个圆圈呢? 

 

 

问题: 盲目信任 “专业人士”扮演的角色

每个角色的水平不一样,  软件的质量往往受最差的角色的影响最大。我们团队要为某软件写一段英语介绍文字,  团队成员都是通过四六级英语考试的牛人,  可他们都很谦虚, 说要请一个专业的人士来写不可。于是求了一个专业人士 ,  求了好几次(专业人士很忙的),  在上市之前才得到专业的文案,  于是, copy/paste 几次之后,  软件就向全世界发布了.  

 

这个文案第一句就是热情洋溢的设问句： "have you ever think about ..."  随后还有几处非常明显的语法错误.  这个软件吸引了不少评论文章,  有旁观者说，  从介绍文字的几处典型中国式语法错误来看,  这个软件是由在中国的某分部搞出来的…

 

即使有专业人士扮演各种角色,  还得有专人独立地检查验证质量。

 

我们回头来看,  可以问两个问题:

·         这件事真的要专业人士来做么?

·         专业人士做完之后, 谁来负责测试?

 

问题: 为了自己角色而做绩效优化

分工之后, 每个角色为了自己的绩效而优化,  会出现局部最优, 而全局未必最优的情况。

 

我们团队的另一个wp7 的应用也要发布,   这次专业人士又出手了,  写了175 个英语单词的介绍, 极尽溢美之事,  而且找不到明显的语法问题!   这的确是一种局部最优了。 但是完全没考虑到用户在小小的手机屏幕上有多少耐心读完那么多形容词和状语从句。经过简化,  我们把它减少到 78 个词, 勉强能放进手机的两个屏幕。

 

如果要以 "产出" 来评价某个角色的绩效, 可以看看这个包装设计的视频:  

http://v.youku.com/v_show/id_XMzQ3NTUxOTU2.html

 

我们回头来看,  可以问:

·         这些事真的要交给和项目无关的专业人士来做? 

·         当我们给专业人士介绍需求的时候,  是否花了足够的时间让对方理解我们要的是什么? 

·         专业人士做完之后,  我们要做什么样的QA?  光保证没有明显的语法错就够了?

 

很多年前, 当COBOL 还是主流商用语言之一的时候,  我曾在一个在软件团队里负责测试工作。职责之一,  是写各种测试用例, 来保证系统的代码覆盖率到达80% 以上。 做过实际项目的工程师都知道, 程序里很多语句是用来处理种种异常情况的, 这些情况大多数情况下不会发生。 但是这些语句如果没有被覆盖的话, 这个模块的覆盖率就会下降, 我就达不到80% 的目标。 所以我花了很多时间构造各种奇怪的测试数据, 把程序中的那些犄角旮旯都尽可能覆盖掉。 至于这些犄角旮旯在实际中是否会发生, 对用户的影响如何, 程序是否应该这样设计, 我都不太关心。 只要覆盖率达到 80%, 老子的活就干完了!

 

我这几年做了不少内部的技术创新项目, 和许多技术牛人, 领域专家有愉快的合作。有几个项目在演示的时候得到好评, 于是我们就想把它变成实用的工具。这时，项目的重点从“演示酷技术”转变为 “解决实际问题”。 有时候最酷的技术未必解决了所有问题, 这时我自然就建议用其它技术去补充。 但是有些技术牛人反而不乐意了, 几经讨论， 我理解了原来有人想使用 “纯纯的”， “完全是我自己的” 技术! 至于实用不实用是次要的, 关键是要用 “我的”  技术！  

 

问题: 画地为牢的分工

在一个长期而复杂的项目中,  我要求所有新来的成员, 包括外包公司的新成员, 在加入团队的时候,  先找到系统当前100 个数据方面的问题, 并用内部工具修复。我认为这能有效地让新人了解系统的复杂性, 弱点, 和维护的流程。  外包公司的员工很爽快地答应了, 但是我们一些专家反而有不同意见。 专家认为, 外包公司的人是来做测试用例的设计,  所以不必做其它事情,  我们期望他们一上手就能设计出高质量的测试用例，不应该给他们那些低级的手工操作任务… 

理论上这都是非常有道理,   但是如果这些人如果没有亲力亲为地在这个项目中做一些具体事, 他们怎么能 “设计” 出高质量, 有实际意义的测试用例呢?

 

有时分工导致链条过长, 信息丢失。 一个开发者对自己写的程序有什么潜在问题还是很有感觉的,  有些问题可以用文字表述出来 (如果开发人员有耐心把文字写出来的话),  有些问题是一些预感…  现在都交给别人测试了, 那好, 让他们测吧, 我也懒得说了。

 

分工还可能会导致一个软件的灵魂被切碎分给各个 "角色"， 每个功能都做得很卖力, 但是整体就是不太行,  明显看出来是费了老大的劲给强行“集成”起来的。

 

 

问题: 无明确责任的分工

在我写第一本书的时候,   编辑部告诉我他们会对书稿进行初读, 二读, 三读 等流程,  每个环节要花几天时间。 作为出版界的外行,  我理解这些都是QA 的阶段,  等过了二读的时间,  我就发信去问，  负责二读的专业人士找到了什么问题了?  得到了语焉不详的回答…   一个问题都没找到?  但是从编辑部的回答来看,  二读不二读,  似乎没什么影响。 其实这本书的小问题还很多， 在出版之后,  都陆陆续续被读者报告了。

 

有时候出于种种考虑,  人们会把一些善良但是能力有限的同事安排在一些位置上, 扮演一些角色,   例如“二读”什么的。或者有些角色就是由一些人占据着, 但是大家对这个角色也没有什么明确的要求。这是许多问题的根源。

 

我们对这个角色有什么可以量化, 可以核查的责任要求? 

 

我们对“一本书的质量是X”的信心是 Y,  刚开始组稿的时候,  X 的取值范围非常大 （烂书… 一般 … 好书… 年度大卖 … 永恒经典）， 信心也比较低。   经过每个一个QA  环节， 我们都应该把X 的范围缩小,  把信心值 Y  提高。

例如:  二读之后,  找到了20 个严重问题, 100个小问题,  因此我们有更大的信心认为这本书是一本烂书 （如果不做改进的话）。

再入: 二读之后,  找到了 10 个小问题,  确信没有更严重的问题了。  因此我们有更大的信心认为这本书是一本好书。

。。。

 

把 “书” 换成 “软件”,  “二读”换成 “测试”, 同样道理。 

 

 

从上面举的例子可以看到, 分工之后, 的确会产生很多问题。 但是解决的方案是什么呢?  是取消分工, 让开发人员顺手做测试人员的事情,  顺便把项目管理, 美工,市场推广, 客服都干了?  显然不是。

 

注意我们提到了 “角色”, 角色是有人来扮演的，如果一人扮演了“开发”的角色,  又能够来扮演“测试”的独立角色, 当然很好 。 但是条件是她要以“独立”的心态测试， 而不是想: “这代码就是我写的,  哪会有什么错…”  而草草了事。

 

那么独立的测试角色怎么才能发挥最大作用?  从上面的坏现象中,  我们不难总结出来。 其实 MSF 原则都讲到了。

·         充分授权和信任（Empower team members）

·         各司其职，对项目共同负责（Establish clear accountability and shared responsibility）

 

 

有些成功人士和成功的公司号称没必要有独立的测试角色 (Test), 你怎么看?

我猜想和踢足球类似， 还是那几个原因: 

人太牛: 

不世出的天才,  例如高德纳写书的时候发现排版软件不好用, 就自己写了一个。 也没听说他为这个软件项目请了什么独立测试人员。对了,   他不读email 已经很多年，有秘书帮他处理这些事  - 这也是一种分工！

 

事太小:

 “我写了个小类库， 全部自己测试” 这当然不错。 

 

我以前的一个优秀实习生后来一个人尝试写一些 UI 的控件, 写得很高兴的时候说了一句 “我现在软件工程的原则都不管了…”为了玩得爽, 不妨打破束缚， 诸法皆空，挺好。

 

但是顺水推舟, 推广到所有情况,  从而得出 "程序员就应该自己测试，独立测试不必了" 这样的普适结论, 未免有点过。

 

人不够:

那就自己动手多做一些事情, 也挺好。就像前面提到的,  一个人扮演多个角色，只要能入戏就行。

 

条件特殊:

    近年来, 软件产业百舸争流, 鱼龙混杂, 在海里裸泳的弄潮儿也不少, 出现了种种类型的分工合作和开发模式。不在有些情况下(例如一窝蜂模式, 主治医师模式), 强力的dev 是可以搞定很多事情。运用之妙, 存乎一心.

 

引起网上讨论的两篇文章在这里:

http://sriramk.com/blog/2012/01/testing.html

中文翻译在: http://www.aqee.net/on-testers-and-testing/ 

 

http://www.quora.com/Is-it-true-that-Facebook-has-no-testers

其中打分最高的回答来自前雇员  (Evan Priestley),  他总结了Facebook 这个公司为什么貌似没有全职测试人员:

a.       全公司人员经常使用自己的软件产品!   (如果你开发的软件是航天飞行某控制模块, 你怎么能经常使用呢? )

b.      使用 log 来分析问题可能出在哪里。  (我们的一些程序员写程序都没有log,  那大家看什么呢? )

c.       利用用户的反馈和实时状态分析 (比较过去一小时和上周同一时间的数据来判断是否有bug).

d.      应用开发商给Facebook 报bug.   (开发商其实比较不爽,  但是 FB 有时就是无预警地修改 API,  你除了赶紧报 bug,   还能怎么着? )

e.      很多人自愿给Facebook 报bug,  这位贴主自称每月给他的前雇主报 13,000 个问题.  （没错, 是每月一万三千个! ）

f.        最后这位前雇员还加了一句:  还有一个原因是, Facebook 大体上也不需要搞出太高水平的软件。

 

当你的公司也能有 a) 到 e) 这样的文化, 流程,  开发商和给力的前员工,  而且你的软件“大体上也不要太高质量”你的确不需要什么全职测试人员! 

 

微软是怎么做的呢? 

就像  MSF 原则 讲的那样,  有分工，有合作。

微软开发测试主要有三种角色：

·         SDE: Software Design Engineer,  简称dev.

·         SDE/T:  Software Design Engineer in Test,  也写代码, 但是重点在测试。

·         STE: Software Test Engineer.

 

对于如何更有效地开发互联网应用, 微软 很多团队都做过不少探索。 例如一些团队尝试把SDE 和 SDE/T 合成一体。 每个人都负责开发/测试/发布这一整套流程，根据我的观察,  有好处， 也有额外的成本。

 

 

结束

一位网友说得好: 分工是社会和行业进化的结果。开发和测试其实是软件工程的两分支。不同的软件／服务需要不同方式和程度的测试。独立专业的测试等同于第三方代表客户对产品认证。

 

拉拉扯扯这么多话,  团队/个人/角色到底应该怎么办呢?  我认为,    

·         在初始阶段 （新项目,  团队进入一个新领域, 人员刚进入一个项目）,  每个团队成员都要尽量打通各个环节,  多负责， 把所有事情都搞懂,  培养通才。

·         当项目/产业发展到一定阶段 （进入阵地战的时候）,  要大力提倡分工合作,  培养专才。

·         把自己项目的架构和流程做好,  让所有人都能比较容易地进行 Quality Assurance 的工作。

·         培养“大家都要做QA,  专人负责量化的Test,  有条件多做测试自动化”的文化。

·         要明白自己项目的特点, 人员的特点, 产业的特点。   避免照搬别人的做法。不要听说某某伟大的系统的开发/测试比例是多少, 就哭着喊着也要同样的比例…

 

思考题:

分工之后,  每人负责一小块东西, 怎么能体现出个人的独特而巨大的价值呢?  例如, 你刚到一个出版社, 领导让你做 “二读” 这份工作；  或者你刚到一个软件公司,领导让你做  "测试"  这份工作, 你怎么能展现出你独特的价值呢?

 

你在某团队做测试，兢兢业业已经三年, 今天大家传说公司认为开发人员应该做测试, 所以不需要专职的测试人员了。 你怎么想? 你能否做到:

1. 明确列出过去三年你对团队的贡献? 除了“认真执行测试用例”之外,  你对团队整体的“质量保证”还有什么独特的贡献?
2. 有理有据地说明, 没有专职测试人员, 项目会有什么风险?
3. 这三年的经历在你的简历怎么写出来? 你比三年前更容易找到工作么

from：http://www.cnblogs.com/xinz/archive/2012/04/09/2439695.html

============================================================

 

1. 大多数的开发团队并不需要一个独立的测试角色。即使有一个，他的所有的开发时间比上所有的测试时间应该 >20:1。证据吗？光看看一些从古至今最成功的软件开发团队就知道了。不论是当今的Facebook，还是30年前最初的NT团队，很多伟大的产品都是出自没有或很少测试人员的团队。
2. 开发人员应该测试自己的代码。没什么可说的。背后的道理并不重要。这包括单元测试，全覆盖的自动化测试或手工测试或组合测试。如果你的开发人员不能/不愿意或认为这“不归我管”，那你需要更好的程序员。
3. 我有一些政治上不正确的话要说。一些大型的软件开发公司会从一些不能胜任开发工作的程序员中选择测试人员。我经历/听说过很多在面试开发人员过程中有人说“他/她做开发不行。也许可以做测试？”这导致了一个被广泛默认，但很少公开宣称的认识：做测试的不如做开发的聪明。正是由于这普遍的偏见，少数一些对质量和测试工作极具热情和天赋的人受到了不公平的待遇。我知道他们，因为我曾经和一些这样的人一起工作过。
4. 追求代码测试覆盖率是危险的。因为它很容易测量，它经常会变成真正目标的替代品——开发有质量的软件。如果你的开发团队把功夫都用在写愚蠢的测试，来覆盖每一个罕有能用到的代码路径——因为这些数据会出现在一些报告里——你有问题了。测试覆盖率只是我们用的的很多指标中的一个，你需要使用它，但并不是因为它以自然的数字呈现，它就能压倒其它指标。它成了古德哈特定律的牺牲品。
5. 我也曾看到有些公司里有独立的测试人员，他们写出非常好的测试代码。不幸的是，这被人们当成了一种常识，即使是在根本不需要这样的时候。
6. 正像测试覆盖率被过度使用，有些质量指标是被忽略轻视了。比如：过程中产生了多少技术支持邮件？自己是否在任何时候都在真正的使用自己的产品，检测里面的问题？分析从生产环境和客户安装那里产生的日志文件。所有的这些策略都在上面的Facebook的帖子里有提到过。
7. 技术领导的一个常见的减少测试队伍的体积的办法是做自动化测试。这是个巨大的错误。如果你有一个用户直接接触的产品，你绝对需要用人眼去测试它。如果你和微软Windows团队的人坐下来一起和咖啡，你会听到他们抱怨过度依赖自动化测试导致了Windows Vista大量的bug。这个错误说明的问题就是：你需要一个全职的测试人员来使用你的产品。

from：http://www.vaikan.com/on-testers-and-testing/