软件测试技术指南(txt+pdf+epub+mobi电子书下载)


发布时间:2020-05-13 12:37:41

点击下载

作者:斛嘉乙,符永蔚,樊映川

出版社:机械工业出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

软件测试技术指南

软件测试技术指南试读:

前言

随着互联网的发展,软件的规模和复杂性都大幅度提升,用户对软件的要求也越来越多,除了软件的基本功能之外,软件的性能以及用户对隐私和敏感数据的安全性等方面用户也特别重视。

软件测试是软件整个研发过程中最重要的一个环节,同时也是软件质量保证最主要、最关键的手段之一,其理论知识和测试工具都在不断的革新。随着IT行业的不断发展,软件测试人才的需求也在不断增加,现软件测试工程师也已经成为了IT行业中一个热门的职位,其主要负责如功能测试、性能测试、自动化测试以及安全测试等。

本书由浅入深的介绍测试各领域的专业知识,可达到快速入门,短期提升,全面掌握的阅读目的。其中包含测试基础理论的全面解说,测试管理的各类方式,测试领域当下最流行的测试工具使用,测试最常用的脚本语言的技能掌握,还有Web项目和APP项目的测试方法和测试思路的拓展。

对于刚开始学习软件测试的零基础同学,还是想在测试道路上进阶的初中级测试工程师,相信这本书都能给大家一个学习思路的引导,从而稳步提升测试技能。

本书由腾尚时代信息科技有限公司创始团队斛嘉乙、符永蔚、樊映川编写,书中凝聚十多年的测试领域研究成果,以通俗易懂,易学实用为导向,使阅读本书如同真实工作体验,便于更快理解测试该如何进行以及使用相应的专业技能。

限于作者的经验和水平有限,书中难免有不足之处,恳请广大读者批评指正。如有疑问和建议可以发邮件,作者电子信箱8773465@qq.com。编者

序言——测试之所见

当前大多数人把软件测试理解为功能测试,他们认为只要理解测试理论,测试流程,再熟练测试用例设计的方法就可以了。所以很多接触这个行业的人,在工作一两年之后,就想着往性能测试、自动化测试方面发展,结果是越学越迷茫,真正的原因是很多人对测试的理解还不够。那么该如何做呢?

下面简述一下作者的看法。

首先测试需要发挥其主动性。因为最终的产品是给用户使用的。也就是说,测试从项目立项开始就需要更全面理解每个需求的意义是什么,关注前期的需求分析和讨论,参与需求的评审,这样可以根据产品需求合理的设计测试方案以及安排好测试时间。

其次就是测试用例的设计。测试用例是用来指导测试工作,也是测试人员必须要完成的工作。测试用例的设计可以从三个维度(业务、用户、方法)来考虑,此外需要对测试用例进行管理,通常写完测试用例后要进行评审,后期在执行中还要不断的更新测试用例。

接下来关注测试流程,注重项目进度的把控。通常这些是项目测试经理来管理,其实作为一个合格的测试人员也要协助领导进行流程的管理,同时对缺陷要进行跟踪管理。特别是针对遗留缺陷的分析以及可能存在的风险。

最后在项目上线后,需要对项目进行相应的总结。总结整个项目过程中遇到的问题有那些,如流程方面、技术方面等。这些问题解决的办法是什么,后续有什么可以借鉴的方案或改进的措施。

除了上述的一些看法,做为一个合格的测试人员还需要具备以下几方面的能力。

沟通能力,其主要体现在两方面。一方面是思路,主要指业务和技能方面,比如在工作中不管是与开发人员沟通,与客户沟通,还是与领导沟通,在沟通前要首先整理好自己的思路。另一方面是表达,主要是指说话的技巧,其实体现的就是情商,比如在测试中发现Bug后,有些人会直接说:“这个地方有Bug”,有些人则会委婉一点说:“这里执行时跟需求不一样,您过来看一下”。总之,不管是开发也好,还是测试也好,我们的工作目标是为了提供高质量的软件给用户,所以在实际工作中,需要尽最大可能理解对方,从而提高工作效率,也就是说要学会换位思考。

思维能力,其主要体现在两方面。一方面是逻辑思维,首先要清楚逻辑思维是一种确定的、有条理、有根据的思维;其次在工作中需要充分熟悉需求和业务,从专业的角度去思考问题。另一方面体现在发散思维,也就是探索性测试,比如在工作中可以天马行空的去设想用户的操作行为,使用最多的方法就是逆向思维。

学习能力,主要体现在两方面。一方面是技能方面。以一个Web系统来说,可能涉及的语言有C++、Java、.Net、PHP、Javascript、HTML等,还会涉及数据库服务器以及应用服务器等。从这点上看,就要求测试人员能够读懂多门语言。另一方面就是业务方面,从目前来看,软件几乎涉及所有的行业,包括银行、电商、物流以及政府的业务办理等,而软件的发展也越来越人性化,所以要求测试人员不断学习和理解不同行业、不同业务的规范和标准。

团队合作能力,现今软件越来越复杂,一个高质量的项目需要不同部门,不同职位的人相互协同实现,仅凭个人能力是不可能完成的。目前很多公司特别注重团队意识,经常不定期组织一些团队扩展活动,来增强团队之间的合作意识。作为测试工程师必需具备高度的团队合作精神,为保证软件产品的质量做出贡献。

最后,做为一名测试人员,还需要有责任心、信心、耐心。平台不同、定位不同,人生的价值就会截然不同,请做好您的职业规划。

时间一直在不断的做减法——且行且珍惜。斛嘉乙2018年9月于家中

第1章 软件测试理论

本章主要介绍软件的发展、软件生命周期以及较为流行的研发模型、软件缺陷等理论知识,从而引出软件测试活动的基础理论:测试目的、测试原则、测试模型、测试用例等,为后续学习内容作好准备。

学习目标:

■熟悉软件的生命周期

■熟悉常见的软件研发模型

■掌握软件缺陷以及等级的划分

■掌握软件测试的模型:V模型、W模型、H模型、X模型

■掌握软件测试的目的以及软件测试原则

■掌握测试用例的写作思路

1.1 软件概念

软件(Software)是一系列按照特定顺序组织的计算机数据和指令的集合。一般来讲,软件被划分为系统软件、应用软件和介于这两者之间的中间件。在国标中对软件的定义是与计算机系统操作有关的计算机程序、规程、规则以及可能有的文件、文档及数据等。

由此可见,软件并不只是包括可以在计算机(这里的计算机是指广义的计算机)上运行的电脑程序,与这些电脑程序相关的文档一般也被认为是软件的一部分。简单地说软件就是程序加文档的集合体。1.1.1 软件发展史

软件的发展大致经历了如下五个阶段:

1.第一阶段(1946年—1953年)

该阶段属于汇编时代,软件是用机器语言编写的,机器语言是内置在计算机电路中的指令,由0和1组成(二进制数字)。因此,只有少数专业人员能够为计算机编写程序,这就大大限制了计算机的推广和使用。

由于程序最终在计算机上执行时采用的都是机器语言,所以需要用一种称为汇编器的翻译程序,把用汇编语言编写的程序翻译成机器代码。编写汇编器的程序员简化了程序设计,是最初的系统程序员。

2.第二阶段(1954年—1964年)

该阶段软件开始使用高级程序设计语言简称高级语言(与之对应机器语言和汇编语言被称为低级语言)编写,高级语言的指令形式类似于自然语言和数学语言,不仅容易学习,方便编程,也提高了程序的可读性。

在1964年Dartmouth学院的凯梅尼(John Kemeny)和卡茨(Thomas Kurtz)发明了BASIC(Beginner’s All-purpose Symbolic Instruction Code)语言。高级语言的出现催生了在多台计算机上运行同一个程序的模式,每种高级语言都有配套的翻译程序(称为编译器),编译器可以把高级语言编写的语句翻译成等价的机器指令。系统程序员的角色变得更加明显,系统程序员编写诸如编译器这样的辅助工具,使用这些工具编写应用程序的人,称为应用程序员。

在汇编和编译时期,由于程序规模小,程序编写起来比较容易,也没有系统化的方法,对软件的开发过程更没有进行任何管理。这种个体化的软件开发环境使得软件设计往往只是在人们头脑中隐含进行的一个模糊过程,除了程序清单之外,没有其他文档资料。

3.第三阶段(1965年—1970年)

该阶段处于结构化程序设计理论,由于用集成电路取代了晶体管,处理器的运算速度得到了大幅度的提高。因此需要编写一种程序,使所有计算机资源处于计算机的控制中,这种程序就是操作系统。

1967年,塞缪尔(A.L.Samuel)发明了第一个下棋程序,开始了人工智能的研究。1968年荷兰计算机科学家狄杰斯特拉(Edsgar W.Dijkstra)发表了论文《GOTO语句的害处》,指出调试和修改程序的困难与程序中包含GOTO语句的数量成正比,从此,各种结构化程序设计理念逐渐确立起来。

20世纪60年代以来,计算机用于管理的数据规模更为庞大,应用越来越广泛,同时,用户对多种应用、多种语言互相覆盖的共享数据集合的要求越来越强烈。为解决多用户、多应用共享数据的需求,使数据为尽可能多的应用程序服务,出现了数据库技术以及统一管理数据的软件系统——数据库管理系统DBMS(Database Management System)。

随着计算机应用的日益普及,软件数量急剧膨胀,在计算机软件的开发和维护过程中出现了一系列严重问题,许多程序的个体化特性使得它们最终成为不可维护的,“软件危机”就这样开始出现了。1968年,北大西洋公约组织的计算机科学家在联邦德国召开国际会议,讨论软件危机问题,在这次会议上正式提出并使用了“软件工程”这个名词。

4.第四阶段(1971年—1989年)

该阶段属于结构化程序时代,20世纪70年代出现了结构化程序设计技术,Pascal语言和Modula-2语言都是采用结构化程序设计规则制定的,BASIC这种为第三代计算机设计的语言也被升级为具有结构化的版本。此外,在1973年,美国贝尔实验室的丹尼斯·里奇(D.M.Ritchie)设计出了一种新的语言,这就是灵活且功能强大的C语言。

此外,IBM PC开发的PC-DOS和为兼容机开发的MS-DOS都成了微型计算机的标准操作系统,更好用、更强大的操作系统被开发了出来。Macintosh机的操作系统引入了鼠标的概念和点击式的图形界面,彻底改变了人机交互的方式。

20世纪80年代,随着微电子和数字化声像技术的发展,在计算机应用程序中开始使用图像、声音等多媒体信息,出现了多媒体计算机。多媒体技术的发展使计算机的应用进入了一个新阶段。

这个时期出现了多用途的应用程序,这些应用程序面向没有任何计算机经验的用户。典型的应用程序是电子制表软件、文字处理软件和数据库管理软件。Lotus1-2-3是第一个商用电子制表软件,WordPerfect是第一个商用文字处理软件,dBase III是第一个实用的数据库管理软件。

5.第五阶段(1990年—至今)

该阶段软件中有三个著名事件:在计算机软件业具有主导地位的Microsoft公司的崛起、面向对象的程序设计方法的出现以及万维网(World Wide Web)的普及。(1)在这个时期,Microsoft公司的Windows操作系统在PC机市场占有显著优势,尽管WordPerfect仍在继续改进,但Microsoft公司的Word成了最常用的文字处理软件。20世纪90年代中期,Microsoft公司将文字处理软件Word、电子制表软件Excel、数据库管理软件Access和其他应用程序绑定在一个程序包中,称为办公自动化软件。(2)面向对象的程序设计方法最早是在20世纪70年代开始使用的,当时主要是用在Smalltalk语言中。20世纪90年代,面向对象的程序设计逐步代替了结构化程序设计,成为目前最流行的程序设计技术。面向对象程序设计尤其适用于规模较大、具有高度交互性、反映现实世界中动态内容的应用程序。其中Java、C++、C#等都是面向对象程序设计语言。(3)1990年,英国研究员提姆·柏纳李(Tim Berners-Lee)创建了一个全球Internet文档中心,并创建了一套技术规则和创建格式化文档的HTML语言,以及能让用户访问全世界站点上信息的浏览器,此时的浏览器还很不成熟,只能显示文本。

软件体系结构从集中式的主机模式转变为分布式的客户端/服务器模式(C/S,Client/Server的缩写)或浏览器/服务器模式(B/S,Brower/Server的缩写),专家系统和人工智能软件从实验室走出来进入了实际应用,完善的系统软件、丰富的系统开发工具和商品化的应用程序的大量出现以及通信技术和计算机网络的飞速发展,使得计算机进入了一个大发展的阶段。1.1.2 软件生命周期

生命周期(Life Cycle)的概念应用很广泛,简单说就是指一个对象的“生老病死”。对一个软件产品或软件系统而言也需要经历同样阶段,一般称为软件生命周期。软件生命周期大致分为六个阶段:如图1-1所示。图1-1 软件的生命周期

1.项目计划阶段

此阶段主要是确定软件开发的总体目标,通过市场调研并给出功能、性能、接口等方面的设想以及项目的可行性分析,同时对项目开发使用的资源、成本、进度做出评估,制定项目实施的计划(项目一级计划)。

2.需求分析阶段

需求俗称软件的主体,所以需求分析阶段作为一个非常重要的阶段,它由需求分析人员和用户共同对软件需要实现的各个功能进行详细的分析并给予确切的描述,并编写软件需求说明书(Software Requirements Specification,简称SRS)。

3.软件设计阶段

该阶段俗称软件的核心,主要是由系统分析组(架构师和系统分析人员)根据需求分析的结果,对整个软件进行系统架构的设计,编写概要设计说明书(High Level Design,简称HLD)。接下来由数据库设计员和开发人员根据需求说明书和概要设计说明书进行系统数据库设计以及编写详细设计说明书(Low Level Design,简称LLD)。

4.程序编码阶段

把软件设计的结果转换为计算机可运行的程序代码,使用RDBMS工具建立数据库。程序编码必须符合标准和编码规范,以保证程序的可读性、易维护性,保证程序运行的效率。

5.软件测试阶段

此阶段主要是测试人员来检测软件是否符合客户的需求,是否达到质量的要求。一般在软件设计完成后,项目开发人员构建测试版本,以便测试团队进行测试,整个测试过程大致分为:单元测试、集成测试、系统测试、验收测试。

6.运行与维护阶段

此阶段是软件生命周期中最长的阶段。在软件开发完成并正式投入使用后,可能有很多原因需要对软件进行修改,如软件错误、系统升级、增加功能、提高性能等。1.1.3 软件体系结构

近年来,随着计算机技术与网络技术突飞猛进的发展,现代企业遇到了巨大的机遇与挑战,为了最大限度地利用现代计算机及网络通信技术加强企业的信息管理,很多企业建立了管理信息系统(Management Information System,简称MIS)。一个完整的MIS应包括:辅助决策系统(Aided Decision Making System,简称ADMS)、工业控制系统(Industrial Control System,简称ICS)、办公自动化系统(Office Automation,简称OA)以及数据库、模型库、方法库、知识库和与上级机关及外界交换信息的接口。可以这样说,现代企业MIS不能没有Internet,但Internet的建立又必须依赖于MIS的体系结构和软硬件环境。

基于Web的MIS系统同传统的MIS技术有相似也有区别。相似之处在于技术的理念;区别之处在于技术的实现。传统的MIS系统的核心是C/S(客户端/服务器)结构,而基于Web的MIS系统的核心是B/S(浏览器/服务器)结构。

1.什么是C/S结构

C/S(Client/Server)结构即客户端/服务器结构。客户端通常可以理解为安装在PC、手机终端设备上的软件,是软件系统体系结构的一种。比如:QQ软件、手机APP等,C/S模式简单地讲就是基于企业内部网络的应用系统。与B/S(Browser/Server,浏览器/服务器)模式相比,C/S模式的应用系统最大的好处是不依赖企业外网环境,即无论企业是否能够上网,都不影响应用。

还有一类通信的软件,比如:百度云盘、迅雷下载等,也属于C/S结构。但是它们之间的数据传输不需要经过服务器处理业务,可以直接通过客户端进行传输,这种结构通常称为P2P(Peer to Peer)点对点结构。

P2P是可以简单的定义成通过直接交换来共享计算机资源和服务,而对等计算模型应用层形成的网络通常称为对等网络。对等网络,即对等计算机网络,是一种在对等者(Peer)之间分配任务和工作负载的分布式应用架构,是对等计算模型在应用层形成的一种组网或网络形式。

2.什么是B/S结构

B/S(Brower/Server)结构即浏览器/服务器结构。随着Internet技术的兴起,对C/S结构的一种变化或者改进的结构。在这种结构下,用户工作界面是通过浏览器来实现,极少部分事务通过逻辑在前端(Browser)实现,但是主要事务逻辑在服务器端(Server)实现,形成所谓三层3-tier结构。B/S是目前互联网中应用最为广泛的系统结构。B/S结构比起C/S结构有着很大的优越性,传统的MIS系统依赖于专门的操作环境,这意味着操作者的活动空间受到极大限制;而B/S结构则不需要专门的操作环境,在任何地方,只要能上网,就能够操作MIS系统,这其中的优劣差别是不言而喻的。

基于Web的MIS系统,弥补了传统MIS系统的不足,充分体现了现代网络时代的特点。随着网络技术的高速发展,因特网必将成为人类社会新的技术基石。基于Web的MIS系统必将成为网络时代的新一代管理信息系统,前景极为乐观。

3.什么是A/S结构

A/S(Application Serving)体系结构。A/S体系结构通过设置应用服务器,将关键性的业务软件集中安装并进行发布,客户端可完全在服务器上执行所需的应用。A/S结构利用ICA协议,将应用程序的逻辑从用户界面中分离开来,使得网络传输数据量很小,对网络带宽的要求低,平均每个用户仅占用10K左右,即使是通过电话线连接到Internet,也能保证多个用户同时工作,提供数据的实时访问和更新。

另外,应用服务器与后台数据库通常采用局域网连接,计算和查询所需的大量数据都是基于LAN传输,因此远程用户的网络性能非常理想。同时在A/S结构中,网络中传输的仅仅是通过用户界面以及操作动作更新信息,因此系统的安全性更好。

1.2 软件研发模型

软件研发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。合理使用研发模型可以提供软件研发效率,降低研发成本,提升软件质量。

常见的研发模型包括需求、设计、编码和测试等阶段,有时也包括维护阶段。软件开发模型能清晰、直观地表达软件开发全过程,明确规定了要完成的主要活动和任务,用来作为软件项目工作的基础。

目前比较流行的研发模型主要有:瀑布模型、快速原型模型、螺旋模型、RUP流程和敏捷模型。1.2.1 瀑布模型

1970年,温斯顿·罗伊斯(Winston Royce)提出了著名的瀑布模型。如图1-2所示。在早期,该模型应用的最为广泛,也是最容易理解和掌握的研发模型。图1-2 瀑布模型

瀑布模型最早是根据工业流水线演变过来的,它的核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划的六个基本活动,由上而下、相互衔接起来,如同瀑布流水,逐级下落。

在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。当前活动的工作结果需要进行验证,如果验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改,直到项目成功。

瀑布模型是属于线性过程,过于强调文档的作用,并要求每个阶段都要仔细验证,适合一些规模小,需求明确的项目研发。随着软件的发展,现软件的功能也越来越多,逻辑也变得越来越复杂,所以瀑布模型已不再适合现代的软件开发模式,几乎被业界抛弃,其主要问题在于:

1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。

2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险。

3)测试活动置后,导致早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果;导致测试人员的闲置,测试力度不够,不利于项目的研发。

4)瀑布模型最大问题是不能够适应用户需求的变化。1.2.2 快速原型模型

快速原型模型(Rapid Prototype Model)又称为原型模型。如图1-3所示。快速原型模型是在瀑布模型基础上演进的一种研发模型。原型模型弥补了瀑布模式不足的地方,相对瀑布模型而言,原型模型更关注用户需求的正确性,也符合人们开发软件的习惯。

快速原型模型需要迅速建造一个可以运行的软件原型,以便理解和澄清问题,使开发人员与用户达成共识,最终在确定的客户需求基础上开发客户满意的软件产品。该模型的主要思想就是通过向用户提供原型获取用户的反馈,使开发出的软件能够真正反映用户的需求。同时,原型模型采用逐步求精的方法来完善原型,使得原型能够“快速”开发,避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈做出快速的响应。

在工作中,很多公司把原型模型称为DEMO,即演示版,便于需求调研以及软件初期的设计。相对测试工程师而言,在实施测试活动中也可以参考DEMO进行测试设计。图1-3 原型模型1.2.3 螺旋模型

1988年,巴利·玻姆(Barry Boehm)正式发表了软件系统开发的螺旋模型。如图1-4所示。它将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。图1-4 螺旋模型

螺旋模型(Spiral Model)采用一种周期性的方法来进行系统开发。该模型是快速原型法,以进化的开发方式为中心,在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括制定计划、风险分析、实施工程和客户评估4个阶段,由这4个阶段进行迭代。软件开发过程每迭代一次,软件开发又上升了一个层次。螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制,它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险,直到所有的主要风险因素都被确定。

螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下活动:

1)制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件。

2)风险分析:分析评估所选方案,由风险专家识别和消除风险。

3)实施工程:实施软件开发和验证。

4)客户评估:评价开发工作,提出修正建议,制定下一步计划。

螺旋模型由风险驱动,强调风险分析,使得开发人员和用户对每个演化层出现的风险有所了解,继而做出应有的反应。因此特别适用于庞大、复杂并具有高风险的系统。对于这些系统,风险是软件开发不可忽视且潜在的不利因素,它可能在不同程度上损害软件开发过程,影响软件产品的质量。降低软件风险的目标是在造成危害之前,及时对风险进行识别及分析,决定采取何种对策,进而消除或减少风险的损害。

由于该模式成本过高,目前商业模式下几乎不采用该模型,但是该模式相关安全系数极高,目前用在军方应用比较多。1.2.4 RUP流程

RUP(Rational Unified Process),是由Rational公司(Rational公司已被IBM并购)推出的一种统一软件开发过程,以用例驱动和体系结构为核心的增量迭代的软件过程模式。如图1-5所示。目前也是比较流行的研发模型。图1-5 RUP流程

RUP有2个轴,横轴表示时间,是过程的生命周期,体现了开发过程的动态结构,主要用来描述软件的周期、阶段、迭代和里程碑;纵轴表示工作流,体现开发过程的静态结构,主要用来描述软件活动的工作流。

1.RUP的阶段划分

RUP中的软件生命周期在时间上被分解为四个顺序的阶段,分别是:初始化、细化、构造和发布。每个阶段结束于一个主要的里程碑(Milestones),每个阶段本质上是两个里程碑之间的时间跨度。下面简单介绍RUP的四个阶段:

1)初始化阶段:本阶段具有非常重要的意义,必须识别所有与系统交互的特性。在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。

2)细化阶段:分析问题领域,建立比较完善的体系结构基础,编制项目计划,规避项目中风险较大的元素。同时为项目建立支持环境,包括模板、准则等,并准备工具。

3)构造阶段:由开发人员对所有的构件和应用程序进行集成,并对所有的功能进行详细测试。从某种意义上说,构建阶段是一个制造过程,其重点放在管理资源及控制运作以优化成本、进度和质量。

4)发布阶段:发布阶段的重点是确保软件对最终用户是可用的。发布阶段可以跨越几次迭代,包括为发布做准备的产品测试,基于用户反馈的少量的调整。

2.RUP的核心工作流

RUP的9个核心工作流,它们分为6个核心过程工作流和3个核心支持工作流。下面简单介绍RUP的每个工作流:

1)业务建模(Business Modeling):主要描述了如何为新的目标组织开发一个构想,并基于这个构想在商业用例模型和商业对象模型中定义组织的过程,角色和责任。

2)需求(Requirement):主要的目标是描述系统应该做什么,并使开发人员和用户就这一描述达成共识。为了达到该目标,要对需要的功能和约束进行提取、组织和文档化;最重要的是理解系统所解决问题的定义和范围。

3)分析和设计(Analysis&Design):将需求转化成系统的设计,为系统开发一个健壮的结构并调整设计使其与实现环境相匹配,并优化其性能。其结果是一个设计模型和一个可迭代的分析模型。设计模型是源代码的抽象,它由设计类和一些描述组成。设计类被组织成具有良好接口的设计包和设计子系统,而描述主要体现了类的对象如何协同工作实现用例的过程。

4)实现(Implementation):将层次化的子系统形式定义代码的组织结构;以组件的形式(源文件、二进制文件、可执行文件)实现类和对象;将开发出的组件作为单元进行测试以及集成由单个开发者(或小组)所产生的结果,使其成为可执行的系统。

5)测试(Test):通过三维模型(可靠性、功能性和系统性能)进行测试。主要检测所有的需求是否已被正确,所有的组件是否被正确集成。RUP提出了迭代的方法,意味着在整个项目中进行测试,应尽可能早地发现缺陷,从根本上降低了修改缺陷的成本。

6)部署(Deployment):部署主要描述了那些与确保软件产品对最终用户具有可用性相关的活动,包括:软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下,还可能包括计划和进行Beta测试版、移植现有的软件和数据以及正式验收。

7)配置和变更管理(Configuration&Change Management):其描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体,并跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发以及自动化创建工程。同时也阐述了对产品修改原因、时间和人员审计记录。

8)项目管理(Project Management):平衡各种可能产生冲突的目标,管理风险,克服各种约束并成功交付使用户满意的产品。其目标包括:为项目的管理提供框架,为计划、人员配备、执行和监控项目提供实用的准则,为管理风险提供框架等。

9)环境管理(Environment Management):该工作流向软件开发组织提供软件开发环境,包括过程和工具,并集中于配置项目过程中所需要的活动,同样也支持开发项目规范的活动,提供了逐步介绍的指导手册并介绍了如何在组织中实现过程管理。1.2.5 敏捷模型

2001年是全球的软件行业最具有历史意义的一年。在这一年年初,“敏捷联盟”成立了,它是由美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者的聚会而成立的。

敏捷开发是以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。简单来说,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。敏捷开发宣言就是尽早的、持续的交付有价值的软件来使客户满意,如图1-6所示。图1-6 敏捷开发宣言

敏捷模型(Agile Model)的原则有以下几点:

1.快速迭代

传统项目一般大约半年发布一次版本。而在敏捷中采用小版本,其需求、开发和测试更加简单快速。

2.让测试人员和开发者参与需求讨论

需求讨论以研讨组的形式展开最有效率。研讨组,需要包括测试人员和开发者,这样可以更加轻松定义可测试的需求,将需求分组并确定优先级。同时,该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高,大家更活跃,参与感更强。

3.编写可测试的需求文档

开始就要用“用户故事”(User Story)的方法来编写需求文档。这种方法,可以让我们将注意力放在需求上,而不是解决方法和实施技术上。过早的提及技术实施方案,会降低对需求的注意力。

4.多沟通,尽量减少文档

任何项目中,沟通都是一个常见的问题。好的沟通,是敏捷开发的先决条件。越有经验,越会强调良好高效的沟通的重要性。

团队要确保日常的交流,面对面沟通比邮件效果强得多。

5.做好产品原型

建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档,但人人都会看图。

6.及早考虑测试

及早地考虑测试在敏捷开发中很重要。传统的软件开发,如果测试用例很晚才开始写,这将导致过晚发现需求中存在的问题,使得改进成本过高。较早地开始编写测试用例,当需求完成时,可以接受的测试用例也基本一块完成了。

1.3 软件测试基本概念

测试(Test)就是为检测特定的目标是否符合标准而采用专用的工具或者方法进行验证,并最终得出特定的结果。软件测试(Software Testing)伴随着软件的诞生而产生。对软件而言,软件测试就是在有限的时间内提高软件质量的保证,是软件开发过程中非常重要的一部分。1.3.1 软件测试发展

迄今为止,软件测试的发展一共经历了五个重要时期:

1.以调试为主

早在20世纪50年代,计算机刚诞生不久,只有科学家级别的人才会去编程,需求和程序本身也远远没有现在这么复杂多变,相当于编程人员承担需求分析、设计、开发、测试等所有工作,当然也不会有人去区分调试和测试。

然而有些比较严谨的科学家们已经在开始思考“怎么知道程序满足了需求?”这类问题了。

2.以证明为主

在1957年,在《软件测试发展》(作者Charles Baker)一书中强调了调试和测试区分:

1)调试(Debug),确保程序做了程序员想让它做的事情。

2)测试(Testing),确保程序解决了它该解决的问题。

这也是软件测试史上一个重要的里程碑,它标志软件测试终于自立门户了。

随着计算机应用的数量,成本和复杂性都大幅度提升,其经济风险也大大增加,测试就显得很有必要了,这个时期测试的主要目就是确认软件是满足需求的,也就是我们常说的“做了该做的事情”。

3.以破坏为主

在1979年,测试界的经典之作《软件测试之艺术》(作者C.J.Myers)一书中给出了软件测试的经典定义:测试是为发现错误而执行程序的过程。这个观点较之前证明为主的思路,是一个很大的进步。我们不仅要证明软件做了该做的事情,也要保证它没做不该做的事情,这会使测试更加全面,更容易发现问题。

在书中,Myers还指出两点:好的测试用例是发现迄今为止尚未发现的错误的测试用例;成功的测试执行是发现了至今为止尚未发现的错误的测试执行。相对于“程序测试就是证明程序中不存在错误的过程”而言,Myers的定义是对的,但定义的测试范围过窄。

4.以评估为主

在1983年,美国国家标准局提出了测试界很有名的两个名词:验证(Verification)和确认(Validation),也就是我们常说的V&V理论。

人们提出了在软件生命周期中使用分析、评审、测试来评估产品的理论。软件测试工程在这个时期得到了快速的发展:相继出现了测试经理、测试分析师等职称以及发表大量测试刊物,发布相关国际标准。

同时IEEE提出的软件工程标准术语中给软件测试定义是:“使用人工或自动手段来运行或测定某个软件系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。也就是这个时期人们开始关注工具对测试的影响。

5.以预防为主

预防为主是当下软件测试的主流思想之一。STEP(产品模型数据交互规范,Systematic Test and Evaluation Process,简称STEP)是最早的一个以预防为主的生命周期模型,STEP认为测试与开发是并行的,整个测试的生命周期也是由计划、分析、设计、开发、执行和维护组成,也就是说,测试不是在编码完成后才开始介入,而是贯穿于整个软件生命周期。1.3.2 软件测试目的

从上述测试的发展来看,软件测试的目的也有一个阶段性的变化,我们通过下图来分析一下软件测试目的的演进。如图1-7所示。图1-7 目的的演进

1.证明

保证软件产品是完整的并且可用或可被集成,同时需要尝试在非正常情况下的功能和特性是否可用,评估系统的风险承受能力。

2.检测

发现缺陷、错误和系统不足的地方,定义系统的能力和局限性,并提供相关的组件、工作产品和系统质量信息。

3.预防

提供预防和减少可能导致错误的信息,在过程中尽早地检测错误,确认问题和风险,并且提前确认解决这些问题和风险的途径。

软件测试目的往往包含如下内容:

1)测试并不仅是为了找出错误,而且要通过分析错误产生的原因和错误的发生趋势,帮助项目管理者发现当前软件开发过程中的缺陷,以便及时改进。

2)需要测试工程师设计出具有针对性的测试方法,以改善测试的有效性。

3)没有发现错误的测试也是有价值的,完整的测试是评估软件质量的一种方法。

综上来看软件测试目的是指尽可能早的发现软件中存在的缺陷并提高软件质量。1.3.3 软件测试原则

软件测试理论经过几十年的发展,在测试界提出了很多测试的基本原则,概括出以下8条软件测试基本原则。

1.所有的测试要追溯到用户的需求

在所有测试活动的过程中,测试人员都应该从客户的需求出发,想用户所想。正如我们所知,软件测试的目标就是验证产品开发的一致性和确认产品是否满足客户的需求,与之对应的任何产品质量特性都应追溯到用户需求。简单说就是一切从用户角度出发。

2.测试应尽早地介入

根据统计表明,在软件开发生命周期早期引入的错误占软件过程中出现所有错误(包括最终的缺陷)数量的50%~60%。此外,IBM的一份研究结果表明,缺陷存在放大的趋势。所以越是测试后期,为修复缺陷所付出的代价就会越大。因此,软件测试人员要尽早地且不断地进行软件测试,以提高软件质量,降低软件开发成本。

3.测试无法穷举

在整个测试过程中,测试人员无法考虑到所有可能输入值和它们的组合以及结合所有不同的测试前置条件;所以穷举测试是不可能的,当测试满足一定的出口准则时,测试就应当终止。因此,想要控制测试工作量,在测试成本、收益和风险之间求得平衡;需要通过风险分析、优先级分析以及软件质量模型和不同测试的方法来确定测试关注点,从而代替穷举测试,提高测试覆盖率。

4.避免开发者自测

测试工作需要严谨的作风、冷静的分析。心理学告诉我们,每个人都具有一种不愿否定自己工作的心理,这种状态导致测试自己程序的障碍。同时,程序员对需求规格说明的错误理解而引入的错误是很难被发现。因此,程序员应避免测试自己的程序,为达到最佳的效果,应由独立的测试小组、第三方来完成测试。

5.群集现象

Pareto Principle帕累托法则(二八定律)表明:80%的错误集中在20%的程序模块中。也就是说,测试所发现的大部分缺陷和软件运行失效是由少数程序模块引起的。因此,测试过程中要充分注意群集现象,对发现错误较多的程序段或者软件模块,应进行反复的深入的测试。

6.杀虫剂悖论

杀虫剂用得多了,害虫就有免疫力,杀虫剂就发挥不了效力。同样在测试中,如果测试用例被反复使用时,发现缺陷的能力就会越来越差。为了避免克服这种现象出现,测试用例需要进行定期评审和修改,不断增加新的不同的测试用例来测试软件或系统的不同部分,从而发现更多潜在的缺陷。作为专业的测试人员来说,要具有探索性思维和逆向思维。同理,测试方法也需要不断地变化。

7.不存在缺陷的谬论

通过测试可以减少软件中存在未被发现缺陷的可能性,但即使测试没有发现任何缺陷,也不能证明软件或系统是完全正确的。也就是说,测试只能证明软件存在缺陷,不能证明软件不存在缺陷。比如,不能满足用户期望的或用户不满意,也是一种缺陷。

8.测试活动依赖于测试背景

针对不同的测试背景,进行的测试活动也不同,测试策略和测试方法在选取上也有所不同。比如,银行产品和电商平台。在银行产品中要将安全放到首位;在电商平台中要把兼容性、性能放到首位。

在实际测试过程中,测试人员应该在测试原则指导下进行测试活动。软件测试原则有助于测试人员进行高质量的测试,尽早尽可能多的发现缺陷,并负责跟踪和分析软件中的问题,对存在的问题和不足提出质疑和改进,从而持续改进测试过程。

1.4 软件测试模型

软件测试根据不同的测试对象以及测试项目的背景可采用不同的测试模型实施测试活动。软件测试模型有:V模型、W模型、H模型、X模型、敏捷测试等。1.4.1 V模型

RAD(Rap Application Development,快速应用开发,简称RAD)是软件开发过程中的一个重要模型,由于其模型构图形似字母V,所以又称软件测试的V模型,它通过开发和测试同时进行的方式来缩短开发周期,提高开发效率,如图1-8所示。图1-8 V模型

V模型最典型的测试模型,最早由PaulRook在20世纪80年代后期提出。

V模型中的过程从左到右,描述了基本的开发过程和测试行为。V模型的价值在于它强调软件开发的协作和速度,反映测试活动和分析设计关系,将软件实现和验证有机结合起来。明确了测试过程中存在不同的级别,并清楚描述测试的各个阶段与开发过程的各个阶段之间的对应关系。

V模型存在一些局限性:该模型呈现线性的发展趋势,而且,它把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段,主要针对程序寻找错误,忽略了测试活动对需求分析、系统设计等活动的验证和确认。如果需求分析前期产生的错误,要到后期的验收测试才能发现。

V模型适用于项目比较小、周期比较短的项目。随着软件行业发展,业务规模的不断扩大,研发模型的不断改革,该模型已渐渐被淘汰。1.4.2 W模型

W模型是在V模型的基础上演变而来的,是由Evolutif公司提出,相对于V模型,W模型增加了软件开发各阶段中同步进行的验证和确认活动。W模型由两个V组成,分别代表开发和测试过程,它明确表明开发和测试的并行关系,如图1-9所示。图1-9 W模型

V&V理论,即验证(Verification)和确认(Validation),是在模型实施过程中进行的,具体地说,就是验证是否做了正确的事情和确认是否把事情做正确了。

1)验证:保证软件正确地实现了特定功能,验证是否满足软件生命周期过程中的标准和约定,判断每一个软件生命周期活动是否完成。

2)确认:保证所生产的软件可追溯到用户需求,确认过程是否满足系统需求,并解决了相应的问题。

W模型遵循了测试原则,要求测试活动从用户需求就介入,测试人员应该参与到对需求文档的验证和确认活动中,以尽早地找出缺陷所在。同时,对需求的测试也有利于及时了解项目难度和测试风险及早制定应对措施,这将显著减少总体测试时间,加快项目进度,有利于尽早地发现问题。

测试伴随着整个软件开发周期,W模型强调,被测对象不仅仅是程序,需求、设计以及每个阶段输出的文档同样需要测试,也就是说,测试与开发是同步进行的。但是W模型也存在局限性。在W模型中,需求、设计、编码等活动被视为串行的,同时,测试和开发活动也保持着一种线性的前后关系,上一阶段完全结束后,才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况,W模型并不能解除测试管理面临的困惑。

从W模型可以看出,完成所有的测试活动,对测试工程师的技能也有一定的要求。测试团队也相继出现了不同职能的测试工程师。1.4.3 H模型

H模型中,软件测试活动是完成独立的,它将测试准备和测试执行分离,有利于资源调配,降低成本,提高测试效率,充分体现测试过程的复杂性,如图1-10所示。图1-10 H模型

测试准备:包括测试需求分析、测试计划、测试设计、测试用例、测试验证等;

测试执行:包括测试运行、测试报告、缺陷分析、回归测试等。

H模型,贯穿于整个产品的生命周期,与其他流程并发地进行。简单说,就是软件测试活动要尽早准备,尽早执行,只要某个测试达到准备就绪点,就可以开展测试执行活动,并且不同的测试活动可按照某个次序先后进行,也可以反复进行。1.4.4 X模型

X模型的基本思想是由Marick提出的,Robin F.Goldsmith将其思想定义为X模型,如图1-11所示。图1-11 X模型

X模型中,左边描述的是针对单独程序片段所进行的相互分离的编码和测试,此后将进行频繁的交接,通过集成最终成为可执行的程序,然后再对这些可执行程序进行测试。在测试中,如果已通过集成测试的成品可以进行封装并提交给用户,也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。

X模型中提出一个重要的理念是探索性测试,这是不进行事先计划的特殊类型的测试,这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费,而且对测试员的熟练程度要求比较高。1.4.5 敏捷测试

敏捷测试(Agile Testing)也是测试的一种模型,它通过不断修正质量指标,正确建立测试策略,确认客户的有效需求来保证产品的质量。敏捷测试是遵循的一种测试实践就是强调从客户的角度,即从使用系统的用户角度来测试系统。

敏捷测试需要关注需求变更、产品设计、源代码设计等。通常情况下,需要全程参与敏捷开发团队的讨论评审活动,并参与决策制定等。在独立完成测试设计、测试分析、测试执行的同时,还要关注用户需求并进行有效沟通,从而协助敏捷流程,推动产品的快速开发。敏捷测试不仅测试软件本身,还包含了软件测试的过程和模式,测试除了针对软件的质量,还要保证整个软件开发过程是正确的是符合用户需求的。

敏捷测试的主旨是测试驱动开发,所以对测试人员的要求有以下两点:

1)理解敏捷的核心价值观(沟通,反馈,尊重、学习、分享)。

2)具备测试基本的技能,也可以擅长某个领域(如:探索性测试、白盒测试等)。

1.5 软件缺陷

软件缺陷(Defect),常常又被叫作Bug。所谓软件缺陷就是指计算机软件或程序中存在的某种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

在IEEE(Institute of Electrical and Electronics Engineers,简称IEEE,电气和电子工程师协会)中对缺陷有一个标准的定义如下:

1)从产品内部看,是指软件产品开发或维护过程中存在的错误、毛病等各种问题。

2)从产品外部看,是指系统所需要实现的某种功能的失效或违背。

早在1947年9月9日,Bug(英文译文“臭虫”或“虫子”)一词,由美国海军的编程员,编译器的发明者格蕾斯·哈珀(GraceHopper)提出,他发现计算机死机的问题,竟然是一只飞蛾导致的。她小心地用镊子将蛾子夹出来,用透明胶布帖到“事件记录本”中,并注明“第一个发现虫子的实例”。从此以后,人们将计算机的错误统称为Bug。1.5.1 软件为什么会引入缺陷

简单说,只要是人,就会犯错。根据数据统计,即使是一个优秀的程序员,在开发软件的过程中,如果不经过测试,代码中遗留的缺陷至少在每千行代码6个以上。

常见的导致软件中存在缺陷的根源主要有以下几点:

1.缺乏有效的沟通或者没有进行沟通

现在的软件不是一个人就可以完成的事,往往涉及多个人,甚至几十个。同时还需要跟不同部门进行沟通。如果沟通不到位,可能会导致软件无法集成,或者集成出来的软件无法满足用户的需求。

2.软件的复杂度

随着软件的发展,现在的软件变得越来越复杂,复杂度增加了,软件越容易出现错误。图形化界面、分布式的应用、数据通信、关系数据库、应用程序等,这些因素导致软件设计的复杂度增加。

3.程序员编程错误

编程的错误也是程序员经常会犯的错误,它包括语法错误、拼写错误以及逻辑设计的错误等。有很多问题可以通常由编译器直接找到,但是遗留下来的就必须通过严格的测试才可能发现。

4.需求的不断变更

在实际项目开发过程中,需求的变更是导致项目失败的最大杀手。对项目而言,需求的变更可能会引起重新设计,甚至会导致项目延期。但是不管是很小的变更还是较大的变更,由于项目中不同部分间可知和不可知的依赖关系,都有可能会引入新的错误;同时项目开发人员的积极性也会受到打击。

5.时间的压力

进度问题每一个从事过软件开发人员都会碰到的问题。在快速变化的商业环境下,为了更好地抢占市场,产品必须比竞争对手早一步把产品提供出来,于是就产生了不合理的进度安排,不断的加班加点最终导致大量的错误产生。

6.人员过于自信

在生活中,我们经常发现人们常说:这个很简单,没有问题等。往往一些问题就是出现在我们认为没有问题的时候。这个经常发生在一些资深的测试人员身上。1.5.2 缺陷种类

常见的缺陷种类的分为以下4种情况:

1.遗漏

遗漏是指规定或预期的需求未体现在产品中。造成该现象的原因,可能是需求调研和分析阶段,未将用户规格说明全部分析实现;还可能在后期实现阶段,未能将用户规格说明全面实现。

2.错误

错误是指需求是明确的,在实现阶段未将规格说明正确实现。造成该现象的原因,可能是在设计阶段产生了错误,也可能是在实现阶段编码引入的错误。

3.冗余

冗余是指需求规格说明并未涉及的需求被实现了。造成该现象的原因,可能是开发人员的画蛇添足,也可能是开发人员的代码复制复用导致的。

4.不满意

除了上述3种外,通常用户对产品的实现不满意也称为缺陷。简单说,现在产品越来越复杂,用户使用的要求也越来越多,只要用户对产品不满意,项目也算是一个失败的项目。

从上面几种情况分析,作为一名优秀的测试工程师,在测试的过程中必须要以用户的需求为基准,从需求角度出发进行测试。

1.6 测试用例

测试用例(Test Case):指对一项特定的软件产品测试任务的描述,体现测试方案、测试方法、测试策略和技术。其目的是将软件测试的行为转化为可管理的模式,同时测试用例也是将测试具体量化的方法之一。

测试用例是软件测试的核心,也是软件测试质量稳定的根本保障。不同的测试类型,测试用例也是不同的。1.6.1 测试用例的重要性

软件测试的重要性是毋庸置疑的,测试用例在整个测试活动中也是非常重要的,主要表现在以下几个方面:

1.避免程序漏测

现如今软件产品的功能越来越多,如何保证产品的质量可以满足用户的需求。主要是通把用户的每一个需求都通过测试用例来覆盖。如果需求发生变更,测试用例也要及时更新,这样可以避免在测试过程中将用户需求遗漏。

2.测试进度的把控

人们需求在不断地变化,市场也在不断变化。大多数公司的项目进度也会跟着用户的需求在变化,测试用例可以很好地把控项目测试进度。

3.一个度量指标

在项目结束后,还可以通过测试用来度量测试覆盖率是多少,测试合格率是多少等,它也是测试结束标准的一个度量指标。

4.分析缺陷的依据

通常在编写用例时,要规划好测试环境、所属模块以及测试数据等。当发现缺陷后,开发人员可以通过测试用例准确的定位和分析缺陷。

5.项目的管理成本

现在大多软件公司面临的一个严重的问题测试人员的流失。简单说,就是项目中测试人员流失,此时可以通过测试用例来辅助新员工进行测试,提高了新员工的测试效率,使新员工更快的去熟悉项目,降低了新员工的培训的成本。1.6.2 测试用例写作思路

测试用例作为测试工作的一个指导,那么测试人员如何编写一个好的测试用例呢?编写测试用例需要遵守5C原则(Correct准确、Clear清晰、Concise简洁、Complete完整、Con-sistent一致)。大多公司的测试用例通常包含用例编号、所属模块、用例标题、用例优先级、前提条件、测试数据、操作步骤、预期结果、用例状态等。

1.用例编号

用例编号是测试用例的唯一标识,主要用来识别该测试用例的目的。用例编号需要具有指引性和维护性,格式一般由字母、数字、下划线组成,具体格式如下:

产品名称_需求编号_用例类型_测试子项_数字编号

1)产品名称通常是指产品的简称:如客户管理系统简称CRM。

2)需求编号通常记录需求规格说明书中需求的编号。

3)用例类型描述测试所属的测试阶段:如单元测试UT、集成测试IT、系统测试ST、验收测试UAT等。

4)测试子项一般具体指被测试的需求点。

5)数字编号根据测试预估用例数来定,通常规则由001或0001

试读结束[说明:试读内容隐藏了图片]

下载完整电子书


相关推荐

最新文章


© 2020 txtepub下载