软件测试之捉虫记-大容量Web应用性能测试与LoadRunner实战_第1页
软件测试之捉虫记-大容量Web应用性能测试与LoadRunner实战_第2页
软件测试之捉虫记-大容量Web应用性能测试与LoadRunner实战_第3页
软件测试之捉虫记-大容量Web应用性能测试与LoadRunner实战_第4页
软件测试之捉虫记-大容量Web应用性能测试与LoadRunner实战_第5页
已阅读5页,还剩14页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、第1章什么是软件测试安博测试空间技术中心:/btestingsky/提供在我国宋代,有一位叫宋慈的法医学家写了一本洗冤集录。在书中,他讲述了很多断案的经验,其中有一个用银针验毒的方法至今仍广为流传。比方在很多电视剧中,我们能经常看到皇帝在进膳的时候,由于害怕被人暗害,总要让可怜的太监或者宫女先用银筷子尝上几口饭菜,没有出现问题再正式用餐。这种用银针进行的试验就可以说是一种测试的雏形吧,银针充当了测试工具,而太监或者宫女就是古代的测试工程师。时光飞逝。随着科技的发展,我们生活周围有了越来越多的产品,它们在出厂销售前都要进行测试,不仅要保证功能完好,还要确保对使用者的伤害在允许范围内。因此在工厂里

2、,逐渐出现了这样一个部门,由它来负责检验产品,被称之为质量检验或者质量保证部。上个世纪中后期,软件出现了,它作为人们日常生活中天天都会使用的产品,同样也需要质量的保证。有一种误解:软件的质量问题并不那么重要,比方Windows等操作系统,各种桌面的应用软件,像IE浏览器,如果它出现了问题,程序会失去响应甚至严重的系统会蓝屏,那么只需要在任务管理器中将它删掉就可以了,最多重新启动电脑,一般都能够继续使用。这只是一方面,另一方面,有很多非常重要的软件在我们看不见的地方默默地运行着,如果它们出现了问题,影响就很大了。为了说明软件质量的重要性,这里举一个比较著名的软件质量造成的事故。1962年,美国的

3、航海家1号Mariner1火箭升空,由于控制火箭的软件出现问题,直接导致火箭升空后因偏离轨道而被迫引爆,造成当时1800万美元的损失。事后查明,是程序员在编写软件代码时,误写了其中一个公式的上标造成轨道计算失误的。第1篇 Web测试背景知识因此,软件公司也需要质量保证部门。我们把该部门的组成人员称为QA工程师,QA即QualityAssurance质量保证的简称。软件是否符合质量是通过测试来验证的,因此他们也被称为软件测试工程师。在本书中您即将遇到的各种行为,绝大多数都将是软件测试工程师在工作中所要实现和完成的。1.1 软件开发的基本知识对于每一位进入软件测试行业的新人来讲,公司的入职培训是一

4、个很好的学习时机。1.1.1 软件开发公司技术部门的基本结构可将软件测试部门类比于工厂车间的质量保证部门,那么显而易见,如果在工厂中要做好质量控制的工作,必须熟悉本厂生产的产品和流程。换句话来说,作为软件生产的参与者,了解被测试的软件也是非常重要的一件事情。这也正是经理要求小白在短期内尽快熟悉的内容。【什么是软件】中国大百科全书中对软件的定义是:软件是电脑系统中的程序和相关文件或文档的总称。软件是从英文Software翻译过来的名词,与硬件Hardware相对应。因此,软件开发公司就是制造这些程序和相关文件或文档的商业机构。一般来说,软件开发公司的技术部门由几个子部门或者角色组成:开发部门、测

5、试部门、部门经理或者项目经理,另外有的公司还有技术支持部门。对应于传统行业,分别相当于生产车间,质量控制部门,部门经理和售后服务部门。如表1-1列出了常见软件开发公司技术部门的不同职责。表1-1常见软件开发公司技术部门的角色分类部门职责软件开发部门开发软件:确定软件实现方法,编写软件程序代码软件测试部门测试软件:确定测试方法,编写自动测试软件的代码,手工测试软件,记录并跟踪软件Bug技术总监或项目经理在所属或其他部门之间沟通,协调项目或者开发测试进度,为成员提供各种资源技术支持部门软件开发完成后在客户处部署产品,并解决与反馈使用中出现的问题Web应用是一种特殊的软件。那么开发Web应用的网站与

6、一般的软件开发公司有什么不同呢?对于小白所处的商业网站来说,网站程序和相关文件或文档也可以称之为软件,其技术部门的结构也和软件开发公司基本类似,但是各部门日常工作的方式则有所不同。商业网站每天都要有很多页面的更新,每次更新后当时浏览网站的人立即可以看至1J;而软件开发公司一般一年或者几年推出一个产品,在产品没有上市的时间内,用户只能使用旧的版本。也就是说网站软件的变化要比软件开发公司频繁,网站软件的开发与用户使用处于同一时间段内。商业网站以服务器为核心,网站软件主要运行在服务器上;而软件开发公司的产品主要运行在用户的电脑上。【演唱会与专辑】商业网站与软件开发公司的运作模式有点类似于歌手开演唱会

7、和发专辑的区别。在演唱会上,歌手与观众的互动性更强,每一个细节的变化也都能被观众捕捉到;而歌手专辑则相当于软件产品的某个版本,是提前制作完成之后再上市销售的。1.1.2 软件危机小白在熟悉了技术部门的大致结构,网站与软件开发公司的区别之后,经理开始介绍和软件测试相关的背景知识。软件危机就是产生软件测试这一职业的重要推动力之一。从20世纪50年代以来,软件的规模越来越大,复杂性也越来越高,另外,在20世纪80年代,伴随着电脑的普及和应用需求的飞速增长,互联网开始蓬勃兴起。现在,现代人的生活已经越来越依赖各种各样的软件,软件不再是大学实验室里科学家的工具,而成为我们生活的一部分。从操作系统,比方每

8、一台个人电脑所安装的WindowsXP或者Vista系统,到小小的桌面程序一一一个简单的连连看小游戏,再到Google网站上可以编辑的在线文档工具,软件的开发、管理、维护的复杂性和高成本现象也日益突出,在某一段时期,暴露了很多问题。因此在20世纪,有人提出了“软件危机”的说法,来说明这种现象。【软件复杂性的类比】其实我们中国人是很容易理解软件复杂性的。一些在人口少的国家不成为问题的问题,放在十几亿人口的环境中,就会产生不大不小的麻烦,比方每年的春运一一需要火车票的人是如此之多,而火车的座位是固定数量的;需要回家的人的分布是如此之广,而火车站的位置也是固定的。依此类比,当软件的代码量越来越庞大,

9、要满足的需求越来越广泛时,出现局部的危机是很容易理解的。1.1.3 软件危机的几个表达随着软件越来越复杂,质量越来越难于控制,于是出现了所谓“软件危机”。具体而言,软件危机有以下几个表达。软件需求的增长无法快速得到满足。这一点在前文已经有所讲述。软件生产成本变高,价格越来越昂贵。软件的代码量增加,所投入的人工成本,也就是软件开发相关人员的成本也会增加,还要增加采用各种新技术的成本等。软件生产进度难于控制。软件的用户需求不容易定义。这一点也很重要:目前绝大多数的软件已经不止满足单一的需求,因此用户真正所需要的不一定能够完美地实现。软件质量不容易保证。这一点也是由软件复杂度的增加而增加。还是举春运

10、的例子,如果火车上人人都有座位,那么每个人的心情都会很好;但如果到处挤满了人,每位旅客回家的心情总会受到影响,从而影响对列车服务的评价。软件质量和用户的评价同样是相关的:经常造成死机、异常退出或者按钮单击后没有反应- # 第1章什么是软件测试的软件,很难说是质量好的软件。软件可维护性变差。软件同样是需要维护的:一方面是对于用户使用过程中的维护,这一功能由客户服务或者技术支持部门来完成;另一方面是对于软件本身代码和文件文档的维护,这一功能由开发部门或者测试部门来完成。随着软件的日益庞大,软件本身经历的修改越来越多,管理维护软件的各种版本变得日益困难。由于软件危机有这么多的影响和危害,所以促使人们

11、静下心来研究软件开发过程中的规律,这就产生了软件生命周期的概念。1.1.4 软件生命周期软件生命周期,英文为SoftwareLifecycle,就是软件开发、使用和消亡的过程,具体而言,包含软件需求分析、软件设计、软件实现与测试和软件发布、部署与维护这4个过程。在商业软件开发公司内部,人们往往遵循一定的软件生命周期模型,这样和被开发软件相关的所有人员都按照这个模型的标准或者步骤开展工作,统一行动,有助于提高生产效率,从而减少沟通和实施的成本,获得更大的商业利益。而对于软件生命周期的不同理解和划分,就形成了不同的软件生命周期模型。1.1.5 常见的软件生命周期模型目前来讲,主要的软件生命周期模型

12、有如下几种。Big-Bang:大爆炸模型。Waterfall:瀑布模型。Spiral:螺旋模型。CodeandFix:边做边改模型。由于本书并不是以软件工程为探讨内容,因此在这里只通过人们过河的类比来简单介绍一下前述这几种软件生命周期模型的特点。小学课本里有个寓言叫做“小马过河”,小马在过河前遇到了不同的小动物,它们对于河水深度的理解是不同的,会导致小马过河时的不同选择,参见图1-1。假设把待开发的软件产品比喻为小马面前横着的那条小河,那么开发软件的过程也就是过河的过程,那么如何过河就会有不同的结果。图1-1小马过河:对河深度的理解影响过河的方法1.1.6 直接冲过河去的大爆炸模型大爆炸这个名

13、称来自于天体物理有关宇宙形成方式的一种理论:宇宙是在亿万年前的大爆炸中诞生的。与此类似,软件开发公司把金钱、办公场地和人员全部投入到一个产品的开发当中,经过一段时间,产品出炉,这样的形式就是大爆炸模型。大爆炸模型的优点就是简单,没有很多的软件设计,对项目的管理也很少,目前不少小公司由于各方面的限制不得已或者不自觉地采用了这样的开发模型。但是它的优点也造成了它的缺点:开发出来的软件质量不可控制。在这样的模型中,由于没有周密的计划,软件测试往往是在产品即将上市的前夕才开始,在很多公司中甚至没有专职的测试工程师,由开发人员或者其他人员代劳,因此测试人员面对的产品与客户、使用者要面对的产品基本一致。从

14、前文所述可以得知,在这样的阶段发现Bug,返工修改代码的代价是非常大的。回到过河的比喻中来,大爆炸模型就相当于小马先退后几步,集中精力和能量,然后快速冲过去。这样的结果取决于河的宽度和深度。如果软件非常复杂,很可能过河的小马半途就淹死了,无法到达对岸。1.1.7 摸着石头过河的边做边改模型边做边改模型比起大爆炸模型来说进了一步。在开发软件产品的开始阶段,先有一个大概的设计,然后开始编码,测试,发现Bug,修改Bug这样的循环,直到整个产品的轮廓日渐清晰,最终完成产品。用一句俗话来描述,就是“摸着石头过河”的过程:先以河里的一些石头为支点,走入河道,再经过不断的试探和返回得到一条路线,最终到达目

15、的地。由此可见,边做边改模型中测试的参与要比大爆炸模型中要早得多,而且也重要得多。边做边改模型的优点就是适用于某些中小型项目的快速开发,软件产品的成果也会在最早的阶段显现出来:和在岸边冥思苦想如何过河的人相比,先站在河道里的石头上,总是让人看到更多的希望。【边做边改模型被较多采用】这种开发模型被大多数公司所采用,是大多数测试工程师在实际工作中最常遇到的开发模型之一。而且,它和最近几年很流行的敏捷开发也有一定的关系。1.1.8 制定周密过河计划的瀑布模型从现在开始,下面的这两个模型就不适合小马了,只有人和外星人才有这样的能力。如图1-2介绍了软件开发的瀑布模型,由于图中的箭头好似瀑布的水流,从上

16、至下,因此得名。图1-2瀑布模型示意图回到过河的例子中来,瀑布模型过河具备如下特点:过河前,首先花费大部分的时间对河进行详细的勘察,选择合适的下水点,选择合适的过河工具,制定详细的分步骤过河计划。一旦过河计划制定,将不会大更改,开始过河。在河中完全按照计划进行,无法返回起点。这也是为什么称此模型为瀑布的原因,瀑布是飞流直下三千尺,想从下面返回瀑布的顶端,何其难。在每步骤即将完成时,都会对这一步骤进行总结,如果进行下一步骤的条件不具备,将停留在原地,等待条件具备。瀑布模型看起来给人很专业的感觉,所以,对于软件开发人员有比较高的要求。要对待开发的软件或者要过的河有细致、全面、准确的了解。如果理解错

17、误,将导致计划失败,没有返回重来的时机。职业素质、职业纪律要比较高。软件开发人员要具备坚定执行计划的能力。这种要求也就产生了瀑布模型的缺点,那就是无法完美适应当今要求快速开发产品,想而占领市场的软件行业现状。因为制定详细的、理解完整的计划很难,聚合很多专业的开发人员有时候也很难,而市场对于软件更新换代的要求期限越来越短。为了适应变化,人们又提出了螺旋模型。1.1.9 计划赶得上变化的螺旋模型前文提到,为了适应计划和变化两方面的因素,螺旋模型被提出。螺旋模型的示意如图1-3所示。可以看到,它确实很类似一个螺旋。, 5 ,第1章什么是软件测试与边做边改模型类似,螺旋模型也具有循序渐进的特点,对软件

18、最终实现什么不一定有完全确定的理解,而是摸着石头先下水。但是在选择过河的每一个石头前经过了周密的计划和考虑,从这一点看,又类似瀑布模型。可见,螺旋模型实际上是边做边改模型和瀑布模型的有机结合。螺旋模型有如下4个步骤。1确定项目目标、可用资源、各种实现的方法,项目的各个阶段。2在某个阶段中,确认、解决当前阶段项目进展中出现的风险。3评估各种方法,开发、测试代码,实现当前阶图1-3螺旋模型示意图段的目标。4总结当前阶段,计划下阶段的目标和实现方法,重复第2步。在图1-3中螺旋线被两条直线划分成4个部分,分别是上述的4个步骤。在每一步骤中由于被直线切割会有多段曲线,每一段曲线就代表了在不同阶段中所进

19、行的相同某个步骤。【螺旋模型的优点】由此可见,螺旋模型是多次计划,边做边改,这样既保证了软件开发任务的清晰,也降低了开始一次计划,因为理解不完整或者市场变化后导致项目失败的可能性。1.1.10 4种模型的总结前文讲述了4种软件开发模型,那么在具体项目开发中采取哪一种最好呢?答案是它们各有利弊,需要灵活采用。这几种开发流程的优缺点比较如表1-2所示。表1-24种软件开发流程的优缺点开发流程分类优点缺点大爆炸模型简单,不用学习就会拍脑门的想法,产品质量无法保证。尽量防止使用边做边改模型快速得到可运行的版本计划有些缺乏,导致版本前后变化较大。可选择的模型之一瀑布模型计划周密,专业,按部就班实现相对难

20、于做到快速开发,以抢占市场。可选择的模型之一螺旋模型计划变化同时考虑可选择的模型之一当然,在几十年的软件开发过程中,人们还提出了很多其他的开发模型,不过,作为测试工程师,我们对这几种主流模型有所了解就可以了。进一步深入的内容并不是本书所讲述的范畴,读者可以参看软件工程的相关书籍。1.1.11 软件开发的几个阶段不管采用哪一种开发模型,按照时间顺序,所有的软件开发项目都要经历如下4个阶段。1项目启动阶段:了解客户需求、配置相关资源。2项目设计阶段:明确客户需求,确立软件开发、测试的方法。3项目执行阶段:开发与测试阶段。4项目竣工阶段:软件的上市、后期维护与技术支持。这一分类很好理解,下面再结合小

21、白的工作场景,进行展开介绍。1项目启动阶段。这一阶段一般技术人员参与较少,主要是市场部门,销售部门,技术总监、项目经理等角色的参与:项目成本是多大,开发人员有多少,测试人员有多少,完成时间在什么时候等。2项目设计阶段。这一阶段主要参与者就是需求分析人员、开发人员、项目经理和小白这样的测试人员了。主要目的是确定软件该如何做,做什么:开发人员利用何种技术开发,测试工程师该如何测试该软件,客户如何使用该软件等。这些问题都要确定,形成各自的开发文档、测试文档和需求文档等。3项目执行阶段。开发、测试以及对其的管理就是执行,这一阶段的参与者是开发人员、测试人员和项目经理。开发人员编写程序代码,进行单元测试

22、;测试人员编写测试代码、测试用例,进行功能测试等多种测试。项目经理控制进度,协调各种资源,与设计人员沟通等。4项目竣工阶段。当项目执行完毕的时候,依然要进行部署、软件光盘生产、客户支持、升级补丁包开发和测试等多项工作。这阶段主要的参与者是项目经理,少量的开发人员和测试人员,售后技术支持人员、客户服务人员等。1.1.12 软件发布的方式按照目前的软件发布方式,一般有RTMReadyToMarket,市场发布、RTWReadyToWeb,在网络上发布、RTOReadyToOperation,可以运营等多种方式。RTM方式需要在工厂进行光盘的复制生产,用户购买光盘后安装。大部分的操作系统和应用软件采

23、用这种方式的比较多。RTW方式需要在网络上提供下载链接,一般的软件升级包或者游戏软件采用这种方式的比较多。RTO方式则很简单,在服务器上部署软件产品,用户购买其中的某项或者多项服务即可,这是大部分网站或者在线游戏采用的方式。1.1.13 项目管理与甘特图前面提到软件项目的流程很重要,那么这种流程的控制一般是由项目经理来完成的,他或者她所从事的这个工作叫做项目管理。小白所在的技术部门一般一周都要开一个例会,在会上,开发部门、测试部门和项目经理都要对上一周各自所做的工作进行一番总结,安排下周将要做的工作。在这样的例会上,同事们经常会查看项目的进度图来进行讲解,他们把这样的进度图称为甘特图Gantt

24、Chart。如图1-4显示的是软件开发过程中常用的项目管理工具MicrosoftOfficeProject软件在这里是2003版本,最新为2007版本运行的界面,在其中我们可以清楚地看到软件生命周期中的各个子任务的时间分配,负责人员和项目进度的甘特图。El”由目/文件睛篇.可归四而川14X到 HH口 遇日日匕忙项目各子任券列表- 7 ar:勃常一乐Sf曰1间Z完前弓埼叠jRBJ-|givIIM|_日iii四国i1日i声21K号美调即眄UItitIflH州Hit柒仙pHfr.fi需中力所?工件闩我性常什5 ifta用面语上3工作M勒坤曲/5工作三勒百3工作日出卜1工叫日AMiflf0F格片EqW

25、日 200年W月”目 20g隼:月ik日 =3Pt.lz3 0 BD*J|壮目E”年川日击Trt帝司|F| 2C05.41:B 3.日M加 | 日用小H图1-4Project2003中的甘特图【甘特图的来历】甘特图的名称由发明者亨利劳伦斯甘特HenryLaurenceGantt,18611919而来。甘特早年从事的是电气工程师的职业,后来转而从事管理业界的咨询。甘特图是他在晚年发明的一种用于显示项目计划和进度的图表。在诞生的初期,甘特图就被誉为20世纪20年代的最重要发明之一,广泛应用于一系列的大工程之中。比方1931年前后修建的美国胡佛水坝如果你看过2007年的热门电影变形金刚,那么对关押威

26、震天的那个水坝应该有印象,它就是胡佛水坝。在软件开发领域,很多公司也应用甘特图这一工具来进行项目管理,比方著名的微软公司。1.2关于虫子的故事在熟悉了公司的结构、开发流程,参与了部门例会之后,小白要开始从事具体的软件测试工作了,对于他来说,这一领域陌生而令人兴奋。在刚上班的一周内,小白不断地听到周围的测试工程师高兴得喊道:“又发现Bug了!看着他们那兴奋的样子,小白也有点跃跃欲试,想赶紧在捉虫的战场上大展身手。那么,什么是Bug呢,它为什么这么重要,发现Bug为什么这样兴奋?第1章什么是软件测试1.2.1 虫子的来世今生在本章的序幕部分,我们已经了解了很多由于软件代码的问题使得事情失败的案例了

27、。它们有的后果真的很严重,甚至能够造成对生命的威胁。这肯定不是软件设计者和开发者想要到达的目标,因此,出现这样的情况可以说是软件的错误。细细的分起来,软件的错误有如下几个词语来描述:缺陷、偏差、错误、问题、事故、异常。在这一堆词语当中,除了偏差之外,其他的词语所造成的后果给人的感觉都相当严重。所谓偏差,就是软件在使用过程中,和软件设计说明productspecification所不一致的行为。那么为什么将这样的软件问题称为Bug呢?这里面还有一个故事。【史上第一个软件Bug该词的原意是“臭虫”或“虫子”。1947年9月9日,正值电脑刚刚被发明的时候,哈佛大学的某个电脑实验室正在做实验。由于当时

28、的原始电脑由很多庞大且昂贵的真空管组成,运行时会产生光和热,在下午15点45分的时候,一个飞蛾英文是Moth钻入了真空管内,导致整个电脑无法工作。当把这只小虫子从真空管中取出后,电脑又恢复正常。后来,虫子的泛称Bug这个名词就沿用下来,而那个被拍死的飞蛾也成为了历史上发现的第一个Bug。【Bug渗透到日常生活中】一般来说,拥有一定知识产权的产品的错误都能称之为Bug。这方面有一个我们比较熟悉的例子就是电影。影迷们经常议论某热门电影中出现了所谓的“穿帮”镜头,比方在描述古代武侠的影片中天空掠过一架飞机,主角刚刚是右脸有伤痕,过一会变成左脸等。这样的镜头也可以说是Bug,甚至还有专门的网站来记录这

29、些影迷的细心发现,比方:。1.2.2 软件Bug的5个要素前文笼统解释了软件Bug是软件的错误或者偏差。那么在具体的工作中,小白如何判断软件的行为是Bug呢?说来简单,根据软件设计阶段形成的功能说明书,英文为SpecificationDocument,一般简称Spec。对于具体的判断标准,经理介绍了如下5个要素:软件没有实现说明书中所列出的功能。软件出现了说明书中提到不应出现的事情。软件实现了说明书中没有提到的功能。软件没有实现说明书中没有提到但应该实现的功能。软件非常难于学习、使用,运转速度很慢,用户认为无法到达预期。为了充分理解上述5个要素,小白自己打开了Windows系统中最简单的一款软

30、件Notepad,也就是我们平时“不屑于”用到的记事本程序,开始了自己的思考。1 .软件没有实现说明书中所列出的功能对于“软件没有实现说明书中所列出的功能是Bug”这一点是比较好理解的。如果打开记事本软件,却无法在其中输入汉字,或者输入了文本,无法保存成文件,那么肯定是一个很重要的Bug。2 .软件出现了说明书中提到不应出现的事情对于第2点,“软件出现了说明书中提到不应出现的事情也是Bug,这一点和小白的性能测试工作有相对更紧密的关系。小白要测试的是公司的网站,它要求用户在浏览网站时显示页面尽可能地快,如果超出5秒钟则认为是不可接受的。这个“超出5秒钟”就是说明书中提到不应该出现的事情,实际出

31、现后肯定是一个Bug,需要开发人员找出哪里消耗了页面显示时间。在记事本程序中,如果程序保存文件时出现了程序崩溃Crash现象,即属于此类。3 .软件实现了说明书中没有提到的功能软件实现了说明书中没有提到的功能也是Bug这一点可能有点难于理解。一个软件,功能难道不是越多越强大吗?其实不尽然,实现额外的功能有如下几个缺点,如表1-3所示。表1-3软件实现说明书中未提到功能所带来的问题缺点说明代码量增大由于代码可能相互影响,因此这部分额外的功能可能对其他功能的实现造成影响,带入新的Bug增加额外的开发、测试时间在软件项目时间固定的情况下,导致投入到其他必备功能的开发测试时间减少,可能影响它们的完成质

32、量增加了成本,与软件的宣传不完全符合虽然用户对于增加功能一般不会有意见,但可能影响了公司的销售策略和市场定位4.软件没有实现说明书中没有提到但应该实现的功能小白一般是将网上找到的有用文档保存在随身携带的U盘中。这一次,他在测试记事本程序的时候,同样打算将文件保存在U盘上,可是由于连日来的文档太多了,优盘已经没有空间,记事本提示无法保存,同时系统托盘有提示说磁盘空间已满。在这种情况下记事本的行为,就属于实现了说明书中没有提到却应该实现的功能在磁盘满的情况下,给用户以提示。如果没有提示,不符合绝大部分用户的使用习惯,也是一个Bug。5.软件难于使用、性能差软件是拿来用的,再好的界面使用不方便也不会

33、产生多大效果。一个网站如果半天都打不开,很难想象还会有多少用户会访问它。因此这样的问题也是Bug,而且对于性能测试来说,这一个规则很重要。1.2.3发现虫子的危害既然软件Bug对产品造成了这么多的影响,那么发现它就显得非常重要了。业内人士都认为,在软件生命周期内的不同阶段发现Bug,所节省的成本是不同的,如图 1-5所示。图1-5软件生命周期内各阶段发现与改正Bug所需成本示意图从图中可以看出,在产品设计阶段发现Bug要比在产品维护阶段发现好得多,这是很好理解的。在需求分析阶段,对于用户需求的理解停留在需求文档中,对其中理解不正确的部分只需要修改文档即可以,基本不会产生什么成本。在软件设计阶段

34、,发现的Bug很多都是设计思想的缺陷。由于尚未开始编码,这样的Bug一般需要进行深入的讨论最终获得一种正确的结论,因此改正成本也不图。在软件编码阶段和测试阶段,代码通过开发人员和测试人员的努力在进行不断的完善,有关Bug的成本主要花费在项目内部的沟通与时间成本方面。但是一旦产品发布,在软件维护阶段发现的Bug,其修改成本会非常高昂:一是因为软件成为了系统,与开发阶段重点检查各模块功能相比更为复杂,寻找代码上的产生Bug根源更加困难。特别是,如果前期工作没有做好的话,甚至软件产品的结构都需要进行大修改;二是因为牵扯的部门明显增加,比方客户服务部门、产品部署部门、销售部门等都要参与,导致公司内部、

35、公司与客户之间的沟通成本急剧增加;第三点则是影响产品质量与公司的信誉、未来产品的销售。【千年虫的问题】在前几年,有一个著名的虫子把业内搅得不可开交,那就是千年虫问题,也叫做2000年问题。它是指在某些使用了电脑程序的智能系统比方一般的电脑系统以及自动控制芯片等中,由于其中的年份沿用早期的设计,只使用2位十进制数来表示,比方用80代表1980年,因此当系统进行或者涉及到跨世纪的日期处理运算比方计算1980年到2080年之间的日期时,就会出现错误的结果,从而引发各种各样的系统功能紊乱甚至系统崩溃。从千年虫的实际例子中也可以看出,不考虑硬件上的限制,如果当初在设计日期表示格式的时候能够想得更长远一些

36、,就完全可以防止这个虫子的发作,从而节省一大笔修改更新软件等的费用据未经证实的来自美国国际资料公司调查报告说明,光是1995年到1840亿美元。1998年,全球捉“千年虫”的开销就已经到达惊人的1.3软件测试的定义与分类前文花费了不少文字来讲述Bug的定义、危害和判断原则,本节将在更广的范围内介绍软件测试的定义与分类。1.3.1 软件测试的定义软件测试就是利用一定的方法对软件的质量或者使用性进行判断和评估的过程。这一定义获得了较广泛的认同。1.3.2 软件测试工程师的工作内容软件测试是由软件测试工程师来完成的,他们的主要工作内容则是:寻找软件中的Bug,并且是越早发现越好原因见节。确认Bug的

37、可重复性Repro以及Bug产生的步骤。确认Bug是否被解决Fixed。测试方法、测试计划、测试平台、测试代码、测试用例、测试文档、测试报告确实定、编写和执行。对于小白这样刚入职的新人来说,主要工作就是前3项以及测试用例的编写了。在节将讲述测试用例的知识。1.3.3 软件测试的分类软件测试可以有很多种分类,常见的有如下一些:黑盒测试Blackboxtesting;白盒测试Whiteboxtesting;功能性测试Functionaltesting;兼容性测试Compatibilitytesting;性能测试Performancetesting;安全测试Securitytesting;压力测试S

38、tresstesting。虽然看起来很多很复杂,但是目前,小白所要做的工作就是先熟悉这些名词,这样在阅读众多的技术文档时,了解这些名词属于软件测试的范畴就可以了。对于软件测试的两个核心,则有必要在第1章详细的介绍。这两个核心分别是测试用例和测试工程师,分别代表了软件测试的两个方面:工具和人。1.4软件测试的核心I:测试用例前文提到,测试用例代表了软件测试的工具方面,是它的核心之一。那么什么是测试用例,它又有哪些要点需要我们去掌握?1.4.1 什么是测试用例软件测试的核心行为就是针对要测试的软件设置测试用例。所谓测试用例,英文名为TestCase,是一个与程序部分行为以及输入、输出相关的描述或者

39、标识。【测试用例的IEEE定义】美国电气与电子工程师协会IEEE,TheInstituteofElectricalandElectronicsEngineers,它出台了一个标准的测试用例定义,即“测试用例是描述输入实际值和预期输出行为或者结果的文档,它同时也标识了测试过程结果与约束。”在实际工作中,花费测试工程师大部分时间的,都是与测试用例相关的。1.4.2 测试用例的几大要素一般来说,测试用例应该清楚地描述出对被测试软件发出什么数据或者条件,以及该输入所期望的结果。在小白这样的商业网站,测试部门规定测试用例应该具备如下几个要素。1 .标识符这一点虽然和测试用例的内容没有关系,但却是测试过程

40、中不可缺少的。比方,小白所在的部门每周都要开一次例会,向经理或者开发部门的同事说明当前整个产品的测试状态,有时候需要特别指出某个测试用例的内容,那么用一个简单的代号来代表这一测试用例是非常适合的,这个代号一般情况下都是一个正整数,比方1、88、437等这样。在小白所在的公司,测试用例是存放在一个数据库中的,代号也就自然地采用了数据库系统中的标识符字段类型。如果采用其他的方式存储测试用例,可以人工指定,只要保证标识符不重复就可以了。如图1-6显示了应用于真实测试场景的某测试用例文档,它实际上是一个OfficeWord文件,测试工程师即编写者在文件内容中手工指定了各个测试用例的标识符。 13 第1

41、章什么是软件测试图1-6测试用例的标识符2 .测试的内容测试内容可以说是测试用例最重要的部分,它一般指明了当前测试用例的运行目的,比方测试网页是否可以打开、单击按钮后是否能够显示正确的计算结果等。在很多情况下,测试内容与下个要点:输入的条件区别并不是很清楚。3 .输入的条件输入条件可以是操作步骤,也可以是输入的数据,还可以是系统运行环境的需求比方处于某种特别的操作系统环境内这一条件。图1-6中的各个测试用例,都详细地写明了每一步骤的具体操作。【复现步骤】对于被测试软件而言,不同的输入条件会导致不同的输出预期,因而可能出现的Bug表现并不一定相同。如果重复某些输入条件,总会导致某个Bug的出现,

42、那么就把这些输入条件称为Bug的复现步骤ReproStep。4 .输出的预期该项信息描述了在当前的输入条件下,预期的输出。比方计算器程序中十进制数字的2+3的输出应该等于5。假设输出预期与实际结果不同,则应该考虑为Bug的可能性有的时候,输出预期也会随项目的进度而变化,因此预期与实际不同并不意味着100%是Bug,此时需要与项目经理等相关人员进行协商。5 .测试环境信息这一部分的内容描述了该测试用例所适用的环境,比方操作系统的版本,所依赖硬件软件的版本、语言等。测试环境信息有时候也可以成为输入条件或者复现步骤的一部分,比方某个按钮只有在IE浏览器中才会出现、某个Bug只在IE浏览器中才会产生,

43、那么IE既是测试环境信息,也是输入条件和复现步骤。6 .与其他测试用例的依赖关系在测试某些软件的时候,比方MSN,如果登录这个测试用例都无法通过,那么剩下的发消息,发文件等测试用例也肯定继续进行除去直接调用接口的那些测试之外,这就是一种测试用例之间的依赖关系。合理地应用测试用例之间的依赖关系,能够提高测试效率,减少无谓的测试时间浪费。7 .测试用例需要被开发、审阅、使用、维护和保存这也是测试工作很重要的一部分。软件的说明书Spec可能会变化,因此测试用例需要变化,这就要求对测试用例进行增加、修改和删除。测试用例是文档,需要有固定的场所进行保存,一般是数据库或者文件。测试用例需要审阅,以到达预期

44、的效果和更高的工作效率重复的测试用例肯定会浪费测试工程师的时间。7.5 软件测试的核心II:测试工程师除了测试用例之外,软件测试的另一个核心,同时也更为关键,就是测试工程师了。这是因为,测试用例也是由测试工程师来编写的,受人的因素影响很大。可以说,人是决定软件成败的主要因素。本节将介绍测试工程师所必备的一些素质。7.5.1 测试工程师与软件质量保障有的时候我们在招聘广告上能够发现有些公司招聘测试人员的时候,列出的职位名称是软件质量保障工程师QA,qualityassurance,那么这两种称呼是否是代表同一种工作内容呢?答复是基本一样,但有细微不同。软件测试工程师的主要职责在于发现并确认Bug

45、的解决与否,而软件质量保障工程师则更进一步,在测试工程师的职责之外,还包括创建、维护为保障软件质量而确立的标准、规则与流程,比方软件配置管理SoftwareConfigurationManagement,又称SCM工程师等。【字面意义的理解】从字面意义上来看,测试工程师主要针对软件的已有Bug,类似体检部门;而软件质量保障工程师则不光针对已有Bug,还对预防Bug的产生提出建议,类似健康参谋。当然,在实际工作中,两者的区别并不是那么清晰的,在很多公司内部,他们所从事的工作内容是完全一致的。7.5.2 测试工程师应该具备的素质一个合格的测试工程师,应该具备如下专业素质:具备基本的数据结构,操作系

46、统等专业知识。这一点对于从事性能测试的人员来说更为重要。具备一定的程序开发经验。掌握一到两门语言对于进行自动测试是大有益处的,另外,具有程序开发经验,也更容易理解软件Bug的来龙去脉。这一到两门语言可以是某些高级语言,比方C#和VB.net,以及一种脚本语言,比方JavaScript、VBScript或者Python等的组合。软件使用经验丰富,对于软件的不正常行为敏感。这一点对于发现Bug是很有帮助的。同时,测试工程师还应该具备如下的性格特征。有好奇心,乐于探索软件功能,乐于尝试新的软件产品。乐于探索谜题,追根溯源。对于一个Bug,必须有追根溯源的精神,才能够发现它的特点,这个性格特征在判断Bug的产生原因,以及是否与其他Bug重复等日常的工作内容中都会展现。有耐心,不轻言放弃。测试工程师在工作中经常会试图复现一个

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论