第1章 朝阳中的软件测试

迎阅读本书的第1章,本章将以对软测除非特别说明,本书提到的软测是“软件测试”的简称。行业有特别影响的专业书籍及网络资源的变化为背景,介绍十多年来测试行业的快速发展及软测工作是做什么的,其核心又是什么。随着信息产业的蓬勃发展,如今软件已渗透到我们工作、生活的方方面面,软件到处都是,它不可能完美无缺,Bug无处不有。由于软件漏洞或缺陷而引发的事故经常发生,软件测试这个把握软件质量最后一个关卡的工作日益受到业界的重视,测试行业由此也风生水起,已展现出朝阳行业的端倪。如何把握测试工作,在测试行业中赢得一席之地,本章后两节分享了如何把握各阶段测试工作的一些见解,同时也浓缩地介绍了测试基础知识的精华,以期对初学者能指点迷津。

1.1 关于软件测试

朝阳冉冉升起,万物生光辉,好一幅灿烂的朝阳图景,令人神往。你可知,国内的软测行业正如图中的朝阳,正朝着美好前景蓬勃发展……

1.1.1 书中一角到书山一角的跨越

1997年的早春,笔者加入了X公司的软件研发部,当时,软件测试是做什么的都还搞不懂,却被老板安排到测试员的岗位。虽然在大学里修过张海藩的《软件工程》,但记得软件测试只是其中的一个章节,如图1-1(左)所示,对其中的细节也不是特别有印象。为了把工作做好,第一天工作结束后就到书店找关于这方面的书。找遍了书店,结果根本没有这方面的书。问问其他同学、朋友也基本上没人知道软件测试到底是做什么的。

图1-1 软测知识体系的跨越

十多年过去了,如今到任意一个相对有一定规模的科技书店,带着“软件测试”这个关键词,一定能找到一系列的软件测试类图书。软件测试只是软件工程书中一角的现象再也不会回来了,软测知识体系的形成已有了质的跨越,如图1-1所示。

但是,我们国内的软件测试行业,还处于初步发展阶段。由美国Glenford J.Myers等著的在业界鼎鼎有名的《软件测试的艺术》一书,其第一版早在1979年就出版了,而那时我们国家的计算机发展还处于实验室的研究阶段。换句话说,早在30年前,国外一些专家的认识就已经很深刻了,积累了丰富的实战经验,各方面技术配套应用齐全,走在专业技术发展的前沿。从另一个角度看,我们国内的软测行业要走的路还很长,目前我们已从十多年前的萌芽阶段过渡到了初步发展阶段,特别是近年来随着软件产业的发展,已到了软件测试不往前发展都难的境况。

1.1.2 捉虫子与挖金矿

有一种职业,它以捉虫子为主要目的,但并不是捉什么动物身上的寄生虫,也不是捉什么植物身上的虱虫,而是专捉隐藏于软件中的臭虫,这便是软件测试。对于软件测试的工作,著名软件测试专家、清华大学教授郑人杰说:“软件测试工作是对质量的把关,其中包含技术及管理等方面的工作,工作相对稳定,对年龄没有限制。而且随着项目经验的不断增长和对行业背景的深入了解,会越老越吃香。”

如今在互联网上,输入“软件测试工程师职业发展”关键词,用百度或谷歌搜索一下,会看到“国家紧缺IT人才”、“软件测试人才缺口30万”、“软件测试黄金职业”,等等,尽是吸引人眼球的强有力的词汇。受国际金融海啸的影响,2008年国内外很多大公司利润大幅度下滑,华尔街不断传来让人难以置信的消息,雷曼兄弟投资银行宣布破产,花旗、通用、IBM、微软这些跨国巨头公司纷纷裁员,以缩减开支,类似的负面网络新闻就像雪片般漫天飞舞。然而就在这金融海啸席卷全球每一角落的环境下,国内的软测行业却独树一帜,招聘需求依然灿烂有加。

一方面是人才的紧缺,另一方面是企业用人的急需。市场上的资源供不应求,且存在较大的缺口,一个合格的软件测试工程师难求,更何况一个资深的将领级人才。软件测试人才俨然成了职场的香饽饽。很多公司亮出年薪10万、20万元仍招不到合适的人,正可谓求贤若渴,这是网上活跃的新闻。这也说明了软测行业不往前发展都难,软测职业,已成为职场的新宠。

有道是“风景这边独好!”近年来,网上进行的悬赏捉虫活动越来越多。常常一上网,就跳出某某企业邀请你参加有奖捉虫活动的消息,如图1-2所示的内容就是其中之一。

图1-2 公开悬赏寻找Bug海报图

捉一条虫子奖几百元、几千元不等,多劳多得,软测工作犹如挖金子的行当。金子真有那么容易挖吗?这使笔者想起了大家都熟悉的黄金矿工网络游戏,如图1-3所示。

图1-3 挖金矿游戏

矿中的金子,有大金子、小金子,它们的含金量是不同的,还有钻石,级别就更高了。要挖到不同含金量的金子,挣到更多的钱,顺利闯关,是需要考虑不同的攻关策略的。例如,挖到石头尽快炸掉,以赢得时间。一轮完毕,可用少量的金币购买幸运草、大力水、石头收藏夹等工具,使它们在接下来的一场攻关中能助你一臂之力。黄金矿工双人版,是双人游戏,犹如团队的工作,相互之间密切配合很重要。比如钻石的含金量是比较多的,但它通常藏于乱石之中,在有限的时间内,仅靠一个人的力量来完成挖钻石的工作是不太可能的,这时两人可以先合力把石头挖掉,再由一人挖钻石。这是一种更快地获得钻石的方法或策略设计,也叫计谋。同样的道理,以捉虫为核心目的的软件测试工作,如果设计得好,可使你捉到大虫(严重以上BugBug:原意是“臭虫”或“虫子”,是指电脑系统的硬件、软件中存在的错误。)、罕虫(极端条件下发生的Bug),让你在软件测试中大显身手,成为捉虫高手。

如图1-4所示,软件中存在不同类别的Bug,隐藏得越深越难以发现。

图1-4 Bug的分布深度与发现的难易程度关系示意图

1.2 Bug就在我们身边

在1.1节中,我们了解到国内软测行业在近些年来的发展变化。这个职业是做什么的,它的发展前景如何,也可从中找到答案。那么,为什么说它是朝阳中的行业,它的背景又是什么,通过本节的介绍,不仅可以回答这些问题,而且可理解这个行业存在的必然性及重要意义。

随着信息技术的日益发展,特别是在最近十几年,通信与互联网的迅速崛起,人们的生活已发生了翻天覆地的变化。多年前很流行的一句话“不懂电脑的人是文盲”,如今在很大程度上已成为事实。网购、网游、网上交友、网上开店、网上银行等,每一个主题都异常活跃,现代人的生活已离开不网络。我们在享受着信息化高速公路带来的高品质生活的同时,却也不时会遭遇“黑客”的攻击。如今,没被“病毒”黑过的电脑已是物以稀为贵了。电脑被黑,是因为操作系统或运行其上的应用软件存在漏洞,此漏洞就是设计的缺陷,其中有一部分是软件中存在Bug。网络软件最常见的是存在安全性的问题,但就问题而言,其他类型的软件,如通信设备、医疗仪器、航空飞机等其中内置的嵌入式软件系统,同样存在软件漏洞。

信息交流如此发达的今天,软件可以说无处不在,软件是由人设计的,没有100%完美的软件,所以说“只要有软件在,Bug就会存在”。本节接下来与大家一起分享几个著名的软件质量事故,它们实实在在地发生在我们生活的周围,小到影响我们的日常生活,大到影响国家安全。

小贴士:

软件的Bug和漏洞区别:

Bug是错误,程序设计中的错误;漏洞是设计的系统中可以被黑客利用的部分,这其中有一部分是程序错误Bug造成的,一部分是设计的缺陷。漏洞是外圆,Bug是内圆,外圆包括内圆,两者之间重叠于内圆。

1.2.1 惠普100款笔记本软件曝严重漏洞

2007年12月19日,据媒体报道,惠普日前发布了一款补丁程序,修复了100款笔记本电脑所预装的“惠普信息中心”软件存在的一个重大漏洞。该漏洞是由赛门铁克安全人员发现的。据安全人员称,该漏洞存在于惠普笔记本(包括康柏品牌)所预装的“惠普信息中心(HP Info Center)”软件的ActiveX控件中。利用HPInfoDLL.dll这个ActiveX控件存在的设计漏洞,黑客可以在惠普笔记本上远程执行代码或远程修改注册表进行恶意攻击,这些恶意攻击包括安装恶意软件、修改注册表信息,以便对受害电脑进行更加复杂的攻击,并从受害电脑中盗取敏感数据。

为了以最快速度控制这个漏洞的爆发,惠普公司先发布了一个补丁程序进行救急,但此补丁程序禁用了“信息中心”一键启动的快捷功能。因此只能说是一种临时的解决方案,是牺牲用户的一个功能来控制黑客的攻击,方案本身会给用户的日常使用带来不便。接下来要完成完整的解决方案即补丁程序的升级,惠普公司本身将消耗大笔的开支,最重要的是给用户带来的损失及声誉影响,是不可估量的。并且在漏洞被发现之前,许多用户已经遭受的损失及其后续影响也是惠普公司需要面对的。

1.2.2 奥运门票销售系统被迫关闭

备受国人关注的奥运门票第二阶段销售工作,虽然于2007年10月30日上午9时正式启动,但是整个过程却并没有外界预期的那样顺利。系统启动工作大概一小时之后,由于访问流量大大超出售票系统的正常负荷,3个门票销售渠道开始无法正常处理票务信息。经过抢修,系统在当日下午5时恢复正常运行,但仍旧出现不稳定的情况。北京奥组委票务中心只好临时召开紧急会议,决定于当日下午6时关闭售票系统。

究竟是什么原因使得奥运门票销售系统瘫痪被迫停止使用?由于第二阶段的售票采用先到先得的原则,在10月30日上午9时刚过,也就是系统刚正式启动时,便有数以万计的抢票大军通过不同的渠道涌入奥运票务系统,抢购门票。据统计,在9时至10时之间,官方票务网站的访问量高达800万次,是系统预设每小时100万次访问量的8倍。这一时段,从3个渠道提交到票务系统的门票订单高达20万张,远远超出了系统预设的票务处理能力,从而造成了网络拥堵、售票速度慢和无法登录票务系统的情况。在众人的购票热情面前,仅有每小时15万张处理能力的票务系统正常运作了不到一小时,就彻底宣告瘫痪。据票务中心相关负责人介绍,从技术角度分析,整个奥运票务网络的带宽并没有出现问题,造成系统故障的主要原因是系统后台的数据库处理能力不足,无法承受大流量的访问。

为了解决此软件设计上的缺陷,奥运票务系统进行了大规模的扩容升级,并承诺系统于12月10日重新开放。与此同时,第二阶段的门票销售政策也只好进行调整,将“先到先得”的售票政策调整为“抽签得票制”。

1.2.3 美F-22机群系统瘫痪,软件质量威胁国家安全

2008年4月14日,有媒体报道,近日,美国空军声称,12架“猛禽”在执行从夏威夷飞往日本的任务中,当途经国际日期变更线时,飞机上的全球定位系统纷纷失灵,多个电脑系统发生崩溃,多次重启均失败。飞行员们再也无法正确辨识战机的位置、飞行高度和速度,随时面临着“折戟沉沙”的厄运。他们不得不掉头返航,幸运的是,当天天气非常好,能见度很高,给“猛禽”加油的KC-135型加油机也可以引导它们安全降落,最终顺利返回了夏威夷的希卡姆空军基地。

事情究竟是怎么回事呢?“猛禽”到达希卡姆机场几小时后,问题就真相大白了,有人在电脑系统编码中犯了一个错误,从而引发了一系列问题。美国空军退役少将史皮尔德称,对于那些“猛禽”战斗机飞行员来说,他们很幸运,因为如果在实战中发生这一问题,他们可能会被击落。并且这个小小的软件错误,将可能成为扭转整个战局的关键点,使美国陷入短时不利的战争局面。不到48小时,颜面大失的“猛禽”的承建商——洛·马公司就寄来了新的系统软件,使之后的飞行任务得以顺利完成,但此次事件还是给各国敲响了软件质量控制的“警钟”。

以上3个软件质量事故,从软件测试的角度分析,是软件测试工作的疏漏。无论它们是属于安全性问题,还是压力负载,或者系统功能等不同类型的软件缺陷,由于测试人员没有及时发现它们,所以未能避免事故的发生。

1.3 把握测试岗位

读者朋友,通过前面的介绍,如果你是一个业外人士,是不是已经跃跃欲试了,很想知道进入测试领域有哪些要求,自己是否合适从事软件测试工作,那么请读“1.3.1测试入门”。它将为你揭开“软件测试”大军基本装备的神秘面纱,告诉你合格的测试工程师是什么样的。如果你已经是一名软件测试工程师,首先,恭喜你!但是我们要对自己有更高的要求,才能取得更大的进步。成为一名优秀的测试工程师,是一个不错的选择,在测试的职业生涯中,无论日后是从事测试管理还是测试技术的工作,它绝对是一个含金量极高的砝码。优秀测试有哪些要求,如何才能成为一名优秀测试工程师,请看“1.3.2优秀测试”,它将为你支招。如果你已是一名能独当一面的业务测试骨干,抑或是某一方面测试技术的大师,再或是在测试项目管理上的佼佼者,如何超越自己,往更高处发展,成为某一测试领域的专家或带头人,建议看“1.3.3卓越测试”,相信会对你有所启发。

如果把对测试岗位能力的把握程度分为3个阶梯,根据其难易程度,其发展趋势可看成如图1-5所示的“金三角”。

图1-5 测试岗位能力把握程度“金三角”

图中,每一个台阶都是一个跨越,每一个跨越都需付出代价,特别是要做到卓越测试,更需付出艰苦的努力,才能成就卓有成效的跨越。图中的人员比例是一个经验值,并不绝对。

事在人为,愿每一个测试朋友都心有目标,不断攀登高峰,成就测试的未来。

1.3.1 测试入门

首先,软件测试是一项技术性工作,在跨入测试这个大门之前,需对软测的基本知识有所掌握,1.4节是单独为这方面知识进行的简要介绍,已熟悉这方面知识的朋友可跳过。当然,如果你足够幸运,不知道软件测试是做什么的,却有机会在软件测试岗位工作,在软测人才如此缺乏的今天,也不是不可能的。比如加入测试执行行列,做一个测试执行人员(运行软件,按他人已设计好的测试用例一条条执行,给出测试结果),但是你很快会发现,由于自己基础知识的缺乏,工作起来很困难,更不用说往下发展。正如古人所说“强扭的瓜不甜”,如何把苦瓜变成甜瓜,关键要看你自己(这个瓜就是你自己)。

在步入测试岗位后,对于任何新人都一样,首先需考虑的是如何做一个合格的测试工程师,这是最基本的,也是最重要的。俗话说“万事起头难”,初来乍到刚做测试时,有这种感受是正常的。下面就从测试技术和测试素质两方面进行总结分享,希望对迷茫中的你有所指引。

1.技术方面

● 测试设计能力:能够对项目的需求进行分析,提取测试需求、设计测试方案与用例。在不少公司里,测试执行与测试设计是分开的,做测试执行工作的人员只能算是测试员。测试工程师是一个通称,但戴上了“工程师”的帽子更显得专业,对于测试工程师的要求当然也更高。根据从事测试业务的领域不同,测试工程师也有不同的叫法,如性能测试工程师、自动化测试工程师、安全性测试工程师等。无论是哪方面的测试,对于工程师来说,“设计”两个字至关重要,测试工作的展开必须围绕这两个字打开思路,发挥潜能,向优秀测试迈进。测试设计能力,需要软件测试专业知识、行业产品业务知识及其他关联的系统知识做支撑。

小贴士:

“工程师”定义:工程师是把数学与自然科学知识用于实际目的,如设计、建造结构并加以操作的人(Someone who applies a knowledge of math and natural science to practical ends, such as the design, construction and operation of structures)。

● 代码分析:能理解设计文档,包括概要设计、详细设计,并读懂代码,适当的时候从设计原理出发,补充系统测试用例设计,或对测试程序设计进行必要的专项测试,如进行压力测试、负载测试、内存泄漏分析等。曾经有从事测试工作的朋友说:“目前测试界,采用黑盒功能测试方法的居多,两眼一摸黑,什么都不知道,有时被开发人员忽悠了还挺感激的。我们不能太黑了,要突破黑箱操作,就是要看代码”。

● 文档编写:当今是电子信息化时代,我们工作的输出最后都以电子文档的形式体现,常见的包括测试计划、测试方案、测试用例、测试代码、测试报告、测试总结。一次,有一位软件研发总监说:“很多软件开发人员都怕写设计文档,这是一个不争的事实,但现在一些刚毕业不久的学生写的文档,简直让你大跌眼镜,连语句都不通顺,更不知如何断句,句子没有标点符号、错别字多,有些同音字出现在逻辑性及严谨性都要求很高的技术设计类文档中,真让人哭笑不得,却又苦不堪言”。无论是开发还是测试,文档的编写是必修的基本功之一,现在网上的学习资料很多,此处推荐一本可以系统学习的书籍《软件文档编写》(高等教育出版社出版)。

2.素质方面

关于软件测试工程师素质特点的文章,在测试专业网站,以及很多书籍上大家可能经常看到。作为一名合格的测试工程师,有哪些基本的关键要求,结合工作中常遇到的问题做如下总结。

● 热爱测试:俗话说“做一行爱一行,三百六十行,行行出状元”,这些道理大家都懂,可是在实际工作中,常听到的是“人在江湖,身不由已”,“身在曹营,心在汉”。如果是这样认为的话,即使你的能力再好,也发挥不出来,更谈不上主动去想,去做测试方法的创新、改进,最终只好南辕北辙,悻悻离开。

● 诚实:这是所有素质中最基本、最重要、最需坚持的原则。用例的执行是测试工作的必做任务,测试的最终结果也需通过用例的执行来体现。用例的执行,就是按照用例的描述在软件上执行操作,判断实际输出与用例中的预期输出是否一致;测试通过写PASS,测试失败写FAIL,没有执行的用例记录为NT(No Test),好像简单得就像1+1=2。但事与愿违,工作中常会出现一些投机取巧的“不测分子”,想当然地认为程序的输出如预期,不去实际操作软件,就置该条用例的执行结果为PASS。后来有一天,其他测试人员发现这个用例其实是FAIL,“不测分子”却还狡辩在自己当时测试的版本上是通过的,这种劣习是绝对要不得的。

● 耐心与毅力:也可理解为不懈的努力、坚持,在对一轮又一轮成百上千条的测试用例进行版本回归测试时,测试人尤其需要具备这一素质。在版本不稳定时,都是人工手动执行,决定了测试工作是一个重复性很高的工作。没有足够的耐心与毅力,就会出现偷工减料,未执行的测试用例置为PASS等情况,敷衍了事,应付工作,当然这也与一个人的责任心密切相关。

● 细心:不单指细心地发现软件的一些细节上的问题,如界面排版没对齐、字符串显示不全。这里更多是指在做测试计划的决策、测试设计等测试的核心设计工作时,需特别考虑周密,细致、深入地理解需求与设计,考虑测试的充分性。很多从测试人员手中逃出去的Bug,是因为没有设计这样的用例。

● 善沟通:这是讲沟通能力,主要指专职测试人员与开发人员、需求人员之间的交流。测试人员发现的问题提交到Bug库后,常会出现开发人员不能重现或看不太明白,这个看似描述不清的Bug,也是一种交流的方式。沟通是双方的,当出现测试人员认为是问题,但开发人员认为不是时,测试人员需善于表达自己的观点,且立场坚定,最好说服开发人员修改,或启动需求人员参与进行三方讨论等。

● 学习能力:知其然,也要知其所以然,测试执行人员与测试设计人员的一个重要区别就在这里,测试执行人员只按用例执行,通常不清楚为什么要这样设计用例;而测试设计人员,如果做不到这一点,会只停留在软件表面上的应用,造成测试遗漏。

● 怀疑精神:指对软件中存在问题的敏感性,对于能否发现Bug显得很重要,这个敏感性说的就是对软件的一种怀疑精神。往往,软件测试人员看到一个界面或一个数据输出不正确,但由于不能马上重现,被开发人员说一通不可能后,很多人就相信了开发人员,认为自己看错了,最后选择了放弃跟踪。很明显对自己没信心,没有足够的怀疑精神,一些Bug就这样在自己的眼皮底下悄悄地溜走了。

前面这些特点是对合格的测试工程师提出的要求,那么在做好一名合格的测试工程师后,很多人自然会想到如何做一名优秀的测试工程师,在技术或管理上要有哪些突破。下节就为大家介绍优秀测试的要求及特点。

1.3.2 优秀测试

上学时,对学习优秀的认识,就是每学期结束时评上“三好学生”。参加工作后,公司每年年终总结时都会进行评优评先进的表彰大会。三好学生也好,优秀员工也罢,站在耀眼光环笼罩下的颁奖台上领奖的确是件让他人羡慕,也让自己备感自豪的事。那么,优秀测试是指什么呢?评优时每个公司的衡量标准会不同,但有一点可以肯定,他或她一定在某些方面取得了突出的成绩。下面是在优秀测试人员身上常见到的闪光点。

● 精通业务:不仅能驾驭好测试流程中各环节的工作,还能超出岗位要求,发现隐含需求问题,并给需求提出有建设性的改进意见。在某个行业领域从事测试几年后,熟悉需求、精通业务,这样的测试人员常是需求设计部门求之不得的人才。

● 精通测试技术:测试技术上的高手,发现内存泄漏、软件性能方面的严重Bug,让开发人员折服。版本发布后指定必须由你来测试,只有经过你的确认,版本才能发布。

● 创造性:有自己的思想,并能在工作中发挥出来;热衷于改进测试流程,主动在工作中不断尝试新方法,研究新技术。

● 富有探索精神:有强烈的求知欲,不耻下问,爱较真,常会抓住软件的不良迹象,发现一堆Bug给开发人员。

● 分析定位问题:发现问题后,还能分析问题,甚至告诉开发人员问题出在哪里,如何更改,有哪些影响。

优秀测试人员的这些素质,有些是可以在后天通过一段时间的自身努力达到的,如业务知识、测试技术、分析定位问题的能力。而探索精神,并不是一个人通过一天两天,甚至通过一年两年的学习就可养成的,它是一个人对各方面知识、认知、习惯培养等多方面综合素质的表现。这类测试人员常常喜欢对问题刨根问底,爱质疑(甚至有时被某些开发人员鄙视为异类、变态),而正是由于这个被视为“毛病”的品质,使得很多设计上的缺陷都逃不掉他们的火眼金睛。探索,敢于探索,使他们更有自己的想法。对问题的日积月累,慢慢地形成了自己的一套想法、看法。量变带来质变,自然而然就会带来创造性的思维,创造性的成果也就体现在工作中了。探索精神是创造性思维的前身,下面的小故事,正好说明了这个道理。

【牛顿与苹果的故事】

传说1665年秋季的一个下午,牛顿坐在自家院中的苹果树下正冥思苦想行星绕日运动的原因,这时,一个苹果落下,正巧落在牛顿的脚边。这是一个发现的瞬间,其实这次苹果下落与以往无数次苹果下落并没有什么不同。几千年来谁都觉得是理所当然的事,但却引发了牛顿的一些疑问,为什么这个苹果要垂直向下落到地面上?为什么它不斜着下落或飞到天上,而是始终朝着地心的方向?为了释疑,他进行了深入地研究,后来提出了令世人惊叹的“万有引力”定律。正是刨根问底、热爱思考、敢于探索的精神成就了牛顿的伟大!

1.3.3 卓越测试

卓越,从字面理解就是杰出、非常优秀,比优秀做得更好,就像学校里跳级的学生一样出类拔萃。如何从优秀到卓越,借用美国知名作家勒纳夫妇合著的《从优秀到卓越》一书中的一段话:对优秀的跳高运动员来说,尽管他们的成绩已经非常出色,但他们还是需要不断“提高自己面前的横杆”,以求每次都能跳得更高一点。这就是实现了“从优秀到卓越”。

那么,对于测试,如何从优秀测试到卓越测试呢?其实道理一样,就是“不断提高自己面前的横杆”。这样说好像很空,在实际操作时,这个横杆有时可能并不是有形的东西,比如当一个优秀的测试工程师,无论测试技术或业务知识都很突出,是不是已达到卓越,已没有发展的空间了?卓越测试确实那么难还有其他原因,为什么能达到卓越测试的人凤毛麟角?卓越测试人才,他们都有哪些特点?下面进行介绍。

● 测试事业:把测试当成自己的事业,对测试工作特别热情,富有激情,这种激情常能感染团队中的其他成员,一直朝着积极向上的方向前进。很多优秀的测试人才,在做了几年后,发觉前路已亮起了红灯,出现了发展的瓶颈。无论是从技术上还是管理上都难于进阶,于是很多人选择了退出,转行做开发、做需求、做销售、做生意等。甚至还有不少测试人员,可能从来都没有想过把测试工作当成自己的事业来做,也没想过其实自己有潜力可以做得比现在更好。

● 测试指挥官:培养及带领一批测试精兵强将,上刀山,下火海,在软件问题的救火场景中常见到他们的身影,高质量突出地完成一个个项目的测试。

● 分享与传递:卓越测试人员是可遇而不可求的,好像他们有测试DNA,除了他们自身有很好的问题敏感度,能找到真正的问题外,他们还乐于把资源、知识、经验分享并传递给团队中的其他成员,推动团队的共同成长。

● 专业技术的带头人:某一技术方面的专家、带头人,敢于尝试新方法、新技术,进行变革创新,突破瓶颈,取得认可。

● 引领未来:身处一角,眼观世界,把握市场,洞察未来,结合当下,前瞻思考,构建测试的未来,是测试团队中的指路明灯。

下面,我们来分享微软这个世界顶级软件开发公司的卓越测试团队的工作模式。

【微软卓越测试团队】

微软在2003年创造了卓越工程(EE)团队,团队的宗旨除了技术培训外,还有发现和分享整个公司的工程最佳做法。团队作为一个整体包含了所有的工程领域,卓越测试团队便是代表测试领域的其中一个团队。卓越测试团队认为微软的每一个测试人员(包括从新员工到副总裁)都是他们的客户,团队的主要任务可以概括为共享、帮助、交流。共享包括共享做法、工具和经验,他们每年举行20 多场测试讲座,交流有效的测试方法。帮助是指帮助测试相关人员解决问题,或许有些问题他们本身不能解决,但他们可以通过与其他团队的联系来解决问题,卓越测试团队担任着促进者和专家的角色。交流指向所有测试成员,沟通交流他们所知道的和所发现的信息。他们还预测微软测试工程师未来的需求,并积极主动地确定关于未来软件测试的长远规划,给测试领域指引方向和指导需要做的工作。更详细的介绍见《微软的软件测试之道》一书。

1.4 测试基础简要

如果你打算介入测试领域或者你是测试新手,那么本节的的内容会很适合你,包括常接触到的基本概念、常用方法的介绍。

1.4.1 软件测试基本概念

通常对软件测试的定义有以下两种描述。

定义一:软件测试是为了发现程序中的错误而执行程序的过程。

定义二:软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例(即输入数据及其预期输出结果),并利用这些测试用例运行程序,以及发现错误的过程,即执行测试步骤。

测试方案:阐述对于某一特定的测试点如何去测试的思路,也就是阐述用什么方法、如何去测试问题。

测试用例:所谓测试用例是为特定目的而设计的一组测试输入、执行条件和预期输出,测试用例是执行测试的最小实体。另外,设计的测试用例应具有步骤清晰、操作性强的特点。一个好的测试用例是发现了迄今为止尚未发现的错误的用例。

测试执行:根据事先设计好的测试用例而执行程序的过程。这个过程需要根据用例执行的输入数据,判断执行程序后的输出结果是否正确。

缺陷:我们常说到的Bug(严格意义上来说,缺陷不等于Bug,详见第9章小知识“Bug与Defect的区别”),对软件缺陷的定义有以下5条描述:

● 软件未达到产品说明书中已经标明的功能。

● 软件出现产品说明书中指明了不会出现的错误。

● 软件未达到产品说明书中虽未指出但应当达到的目标。

● 软件功能超出了产品说明书中指明的范围。

● 软件测试人员认为软件难以理解、不易使用,或者最终用户认为该软件使用效果不佳。

1.4.2 软件测试目的

表面上看,软件测试的目的是要证明程序有故障存在,并且要尽可能多、尽可能早地发现程序中的错误。实际上,暴露问题不是软件测试的最终目的,发现问题是为了解决问题,只有解决了问题,软件的质量才有提高,才达到了测试的最终目标。

正如前面所说的“软件测试是为了发现程序中的错误而执行程序的过程”,正确认识这一点很重要。因为不同的测试目标,会设计不同的测试用例。如果目标是发现程序中的错误,则设计测试用例时就会考虑用各种方法设计出最能暴露错误的测试用例。反之,就会设计一些证明程序是正确的用例去执行。

1.4.3 软件测试策略

对一个项目进行测试,在做测试计划时,必须考虑清楚对本项目要采取哪些测试的策略,也就是说你将采用什么手段或方法进行测试。

在软件开发的生命周期中,可划分不同的开发阶段,如常用的软件开发V模型,如图1-6所示。对应开发的不同阶段,软件测试也分为不同的单元测试、集成测试、系统测试及验收测试。

图1-6 软件开发V模型

但是,通常需根据项目的进展及要求的具体情况,可采用迭代式的开发模式、敏捷开发模式等,各阶段也可并肩地进行。

单元测试:又叫模块测试,是软件开发各阶段中最低一级的测试活动。通常由程序编写人员自己完成,目的是检验程序的最小单位(模块)有无错误。针对编写的源代码,采用各种白盒测试技术进行,如语句覆盖、判定覆盖、条件覆盖、条件组合覆盖等方法。在面向过程的结构化程序中,如C程序,其测试的对象一般是函数。在面向对象的程序中,如C++,单元测试的对象可以是类,也可以是类的成员函数。

单元测试主要针对以下5个方面进行测试:

● 模块接口。

● 模块局部数据结构。

● 重要的执行通路。

● 出错处理检测。

● 边界条件测试。

由于一个模块仅完成某一方面的功能,因此在软件系统中,一个模块不可能独立存在,模块与模块之间必然存在相互的联系。在进行单元测试时,需要根据具体情况来设计驱动模块和桩模块,与被测试模块一起构成测试环境。

集成测试:在单元测试之后,把通过单元测试的模块,按照设计的要求组装起来进行测试,主要目标是发现与接口有关的问题。

集成测试模块组装的方法分为非增量式和增量式两种。非增量式是指先分别测试每个模块,然后把所有模块按设计要求放在一起组装成所要测试的程序。增量式是把下一个要测试的模块同已经测试好的模块结合起来进行测试,测试完成后,再把下一个待测试模块结合进来测试,这样每次增加一个模块,直到把所有模块都测试完成为止。

系统测试:把软件、硬件及系统其他组成部分集成在一起,模拟最终用户的使用环境,站在用户的立场进行的综合性测试。目的是保证系统各组成部分能够协调工作,系统的性能达到产品规格的要求。

验收测试:根据软件需求说明书的规定,对软件产品进行评估,以确定其是否满足软件需求的过程。经过确认测试后,应对软件给出结论性评价,即合格或者不合格。如果软件的功能、性能及其他方面的要求都满足软件需求规格说明的规定,则视为合格的软件,反之则视为不合格,给出缺陷清单并提交到开发部门。

1.4.4 软件测试方法

1.静态测试和动态测试

按照软件测试是否执行程序而言,软件测试通常可分为静态测试和动态测试两大类。

1)静态测试

静态测试的主要特征是不实际运行被测试软件,主要目的是对软件的编程风格、结构等方面进行评估。

静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工根据编码规范进行检查,通过分析代码结构来检测程序的正确性,也可借助软件工具自动进行,如PC-Lint便是一款不错的代码静态检查工具。进行静态测试的人员必须熟悉程序的结构、参数定义等,还需要测试人员对产品知识有一定程度的认识。这样不仅能发现程序正确性方面的问题,还能站在用户的角度分析发现程序的实现是否合理。

静态测试能发现逻辑设计和编码错误方面的大部分问题,但代码中仍会有隐藏的故障无法通过静态测试来发现。静态测试的结果不能作为最终结果,还必须通过动态测试进行详细地分析及验证。

2)动态测试

动态测试与静态测试正好相反,必须真正地运行被测试程序,通过输入测试用例,对运行过程中的输入、输出数据进行分析,从而得出测试结论。

动态测试包括功能测试、覆盖率分析、性能分析、内存分析等。功能测试可采用手工测试,视具体情况也可采用自动化测试的方法。覆盖率、性能、内存的分析上常要借助其他软件测试工具,或者自行编码以实现测试的目的。

静态测试和动态测试是相辅相成的,通过静态测试可以比较细致地对代码进行检查,通过动态测试则可以对软件运行的结果得出明确的结论,具有较强的确定性。

2.黑盒测试和白盒测试

如果按照测试时是否考虑程序的内部结构实现来分,软件测试可分为白盒测试和黑盒测试。

黑盒测试(Black-box Testing),又叫功能测试,是根据软件规格说明书的要求,运行并验证程序是否满足用户的需求,是一种从用户立场出发的测试。这种方法把被测试程序当做一个黑盒子,不考虑程序内部的逻辑结构和特性,通过输入测试数据,根据需求来判断输出是否正确。黑盒测试一般被用来确认软件功能的正确性和可操作性。

白盒测试(White-box Testing),又称为结构测试,是通过分析程序内部的逻辑结构,针对特定条件和循环设计测试用例,对程序的逻辑路径进行测试。要求测试者对软件的结构和代码相当熟悉,测试的目的是尽量覆盖程序的每一个分支,在程序的不同点检测“程序的状态”以判定其实际情况是否和预期一致。

这两种测试方法的出发点是完全不同的,反映了测试思路的两个方面。两种方法各有侧重,不能替代。黑盒测试的优点是效率高和实用性强,缺点在于测试往往是不完全和不充分的;白盒测试的优点在于能够对程序内部的特定部位进行覆盖测试,缺点是无法测出程序未实现的功能。

总之,黑盒测试和白盒测试各有自己的优、缺点,测试的效果是相辅相成的。工作人员在规划测试方案时,需要将黑盒测试与白盒测试结合起来,才能把软件测试得更充分、更有可靠性。

1.4.5 软件测试流程

软件测试贯穿于软件开发的整个生命周期中,在不同的阶段可采用不同的测试方法。但不管是单元测试、集成测试、系统测试都可以按下面的流程进行:

(1)编写测试计划。

(2)设计测试方案。

(3)设计测试用例。

(4)执行测试。

(5)故障跟踪。

(6)输出测试报告。

(7)测试总结(分析)。

如图1-7所示,是一个没有考虑其他分支、迭代情况的软件测试环节流程图。

图1-7 软件测试流程简图

一般情况下,软件测试在工程实践中经常实施的有单元测试、集成测试、系统测试。系统测试,人们又常把它称为功能测试,这其实是不全面的,但也有一定的道理。因为系统测试主要的工作是功能测试,就是根据软件的规格说明书验证软件是否满足用户的需求。但除了测试功能之外,系统测试还必须验证系统的性能是否满足用户的需求,所以系统测试是不完全等同于功能测试的。