软件测试

软件测试概念

软件测试(英语:Software Testing),描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说,软件测试是一种实际输出与预期输出之间的审核或者比较过程。软件测试的经典定义是:在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。

软件测试的对象

程序、数据、文档。

测试的关键问题是如何选择测试用例。

测试设计员的职责是:设计测试用例和设计测试过程、脚本。

软件测试的步骤

1、测试需求分析阶段:阅读需求,理解需求,主要就是对业务的学习,分析需求点,参与需求评审会议
2、测试计划阶段:主要任务就是编写测试计划,参考软件需求规格说明书,项目总体计划,内容包括测试范围(来自需求文档),进度安排,人力物力的分配,整体测试策略的制定。风险评估与规避措施有一个制定。
3、测试设计阶段:主要是编写测试用例,会参考需求文档(原型图),概要设计,详细设计等文档,用例编写完成之后会进行评审。
4、测试执行阶段:搭建环境,执行冒烟测试(预测试)-然后进入正式测试,bug管理直到测试结束
5、测试评估阶段:出测试报告,确认是否可以上线

软件测试的目的

1)为了发现程序猿在开发中存在的代码以及逻辑错误
2)为了审核产品的完成是否符合用户的需求
3)为了提高客户的体验
4)为了交付更高质量的产品

软件测试方法(分类)

软件测试

1.从软件内部结构和具体实现的角度划分

(1)白盒测试:又称为结构测试或逻辑驱动测试,是一种按照程序内部逻辑结构和编码结构,设计测试数据并完成测试的一种测试方法。
(2)黑盒测试:又称为数据驱动测试,把测试对象当做看不见的黑盒,在完全不考虑程序内部结构和处理过程的情况下,测试者仅依据程序功能的需求规范考虑,确定测试用例和推断测试结果的正确性,它是站在使用软件或程序的角度,从输入数据与输出数据的对应关系出发进行的测试。
(3)灰盒测试:是一种综合测试法,它将“黑盒”测试与“白盒”测试结合在一起,是基于程序运行时的外部表现又结合内部逻辑结构来设计用例,执行程序并采集路径执行信息和外部用户接口结果的测试技术。

2.从是否执行代码角度

(1)静态测试:指不运行被测程序本身,仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。
(2)动态测试:是指通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率、正确性和健壮性等性能指标。

3.从软件开发的过程按阶段划分有

(1)单元测试:又称模块测试,是针对软件设计的最小单位----程序模块或功能模块,进行正确性检验的测试工作。其目的在于检验程序各模块是否存在各种差错,是否能正确地实现了其功能,满足其性能和接口要求。
(2)集成测试:又叫组装测试或联合,是单元测试的多级扩展,是在单元测试的基础上进行的一种有序测试。旨在检验软件单元之间的接口关系,以期望通过测试发现各软件单元接口之间存在的问题,最终把经过测试的单元组成符合设计要求的软件。
(3)确认测试:又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。
(4)系统测试:是为判断系统是否符合要求而对集成的软、硬件系统进行的测试活动、它是将已经集成好的软件系统,作为基于整个计算机系统的一个元素,与计算机硬件、外设、某些支持软件、人员、数据等其他系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列的组装测试和确认测试。
(5)验收测试:以用户为主的测试,软件开发人员和质量保证人员参加,由用户设计测试用例。不是对系统进行全覆盖测试,而是对核心业务流程进行测试。
(6)回归测试:是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
(7)α测试:α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可用性、可靠性、性能和支持)。尤其注重产品的界面和特色。α测试可以从软件产品编码结束之时开始,或在模块(子系统)测试完成之后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。α测试即为非正式验收测试。
(8)Beta测试:Beta测试是一种验收测试。所谓验收测试是软件产品完成了功能测试和系统测试之后,在产品发布之前所进行的软件测试活动,它是技术测试的最后一个阶段,通过了验收测试,产品就会进入发布阶段。验收测试一般根据产品规格说明书严格检查产品,逐行逐字地对照说明书上对软件产品所做出的各方面要求, 确保所开发的软件产品符合用户的各项要求。 通过综合测试之后,软件已完全组装起来,接口方面的错误也已排除,软件测试的最后一步——验收测试即可开始。验收测试应检查软件能否按合同要求进行工作,即是否满足软件需求说明书中的确认标准。

软件生命周期

概念:是指软件开发和测试全部过程、活动和任务的结构框架,是从可行性研究到需求分析、软件设计、编码、测试、发布后的维护过程。

软件测试生命周期的详细过程

一、问题定义。要求系统分析员与用户进行交流,弄清“用户需要计算机解决什么问题”然后提出关于“系统目标与范围的说明”,提交用户审查和确认。
二、可行性研究。一方面在于把待开发的系统的目标以明确的语言描述出来,另一方面从经济、技术、法律等多方面进行可行性分析。
三、需求分析。弄清用户对软件系统的全部需求,编写需求规格说明书和初步的用户手册,提交评审。
四、开发阶段。开发阶段由四个阶段组成:
1、概要设计
2、详细设计
3、实现:根据选定的程序设计语言完成源程序的编码。
4、测试
五、维护:维护包括四个方面
1、改正性维护:在软件交付使用后,由于开发测试时的不彻底、不完全、必然会有一部分隐藏的错误被带到运行阶段,这些隐藏的错误在某些特定的使用环境下就会暴露。
2、适应性维护:是为适应环境的变化而修改软件的活动。
3、完善性维护:是根据用户在使用过程中提出的一些建设性意见而进行的维护活动。
4、预防性维护:是为了进一步改善软件系统的可维护性和可靠性,并为以后的改进奠定基础。

软件生命周期模型:瀑布模型、迭代模型、原型模型、螺旋模型、增量模型、V模型、W模型。

瀑布型

软件测试
1、问题的定义及规划 :有软件开发方与需求方共同讨论,主要确定软件的开发目标及其可行性。
2、需求分析 :在确定开发可行性的情况下,对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段。同样的需求也是在整个软件开发过程中不断变化和深入的,因此我们必须制定需求变更计划来应付这种变化,以保护整个项目的顺利进行。
3、软件设计 :此阶段主要根据需求分析的结果,对整个软件系统进行设计,入系统框架设计,数据库设计等等。软件设计分为总体设计和详细设计。 好的软件设计将为软件程序编写打下良好的基础。
4、程序编码 :将软件设计的结果转换成计算机可运行的程序代码。在编码过程中必须要制定统一,符合标准的编写规范。以保证程序的可读性,易维护性,提高程序的运行效率。
5、软件测试 :在软件设计完成后要经过严密的测试,以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分为:单元测试、组装测试、系统测试三个阶段。测试方法主要有黑盒测试和白盒测试两种。在测试的过程中需要建立详细的测试计划并严格按照测试计划进行测试,以减少测试的随意性。
6、运营维护 :软件维护是软件生命周期中持续最长的阶段。 在软件开发完成并投入使用之后,由于多方面的原因,软件不能继续适应用户的要求。要延续软件的使用寿命,就必须对软件进行维护。软件的维护包括纠错性维护和改进维护两个方面。

瀑布型优缺点:

优点:

1)软件产品质量较高;
2)前置发现产品缺陷;
3)项目把控能力强;
4)项目扩展性和可维护性强;
5)责任划分明确。
项目流程按照流水线作业一样执行,且每个阶段责任人、任务、标准明确,同时也有明确的文档输出,使整个项目周期得到把控,也便于后期的扩展和维护。

缺点:

1)若需求复杂,人员能力要求较高;
2)投入人力集中,造成过多的闲置;
3)用户在系统稳定后介入,可能会出现与预想不符的情况;
4)每个阶段相对独立,信息不能及时同步;
5)项目风险延到后期开发阶段才能发现。
由于瀑布模型阶段分明、人员投入大,很多项目为了赶进度在前期需求不明确就开始开发,过于简化需求和设计阶段。如果是大型项目,很可能会出现大量的返工反而会影响进度。

迭代模型

迭代模型同瀑布模型一样,项目也会遵循需求->分析->设计->开发->测试->发布的流程,但不同的是,在前期需求分析阶段,会将所有的需求按照核心功能点-模块-关联模块进行拆分并分期实现,然后以迭代的形式逐步完善功能,在每一次迭代完成后系统都是可以交付的原型,往往第一次迭代都是产品最核心的功能。
软件测试

迭代模型的优缺点

优点:

1)在需求分析阶段就给出了相对完成的架构设计方案,便于后面迭代的扩展和完善;
2)第一阶段核心功能交互用户后,可以及早获取反馈结果,对后期的迭代起到指导作用;
3)人员分配灵活,前期不用投入很多人力;
4)在前期能够很好的控制风险,并且解决难度系数较低,影响范围也较小。

缺点:

1)对项目需求明晰度要求很高;
2)对整个项目周期要求较宽裕,政治任务需排除。

原型模型

原型模型一般在需求提出初期,用户迫切需要体验产品,开发人员根据核心功能需求快速实现的一款可以用来演示的产品,形成demo,可快速挖掘是否是用户真正想要的产品。但这种模型在整个软件项目周期内只可能存在于这期间,当用户了解了demo后决定是抛弃还是继续采用,抛弃相当于需求双方没有达成一致,可以再次采用原型模型输出给用户确认,若选择不抛弃继续采用,原型模型就会被抛弃,选择其他模型继续开发。
软件测试

原型模型的优缺点

优点:

1)快速了解用户真正想要实现的样子,整个项目可行性强。

缺点:

1)没有考虑软件的整体质量和长期的扩展和维护;
2)快速输出demo的方法不一定会真正采用;
3)只在用户需求目标模糊,急需看到效果的情况下使用。

螺旋模型

螺旋模型的显著特点就是强调风险,以风险驱动的方式完善项目。将瀑布模型和原型模型结合起来,在每一个阶段加入风险评估,以减少项目的风险。螺旋模型将项目划分为四个阶段:
1)制定计划:在需求分析阶段指定项目目标、整体架构,包括备选方案和相关约束条件。
2)风险分析:对于复杂的大型软件,需要输出多个原型模型,在针对每个原型模型进行风险分析,预估风险并规避风险。
3)实施工程:对最终确定的原型模型按照瀑布模型的流程进行。
4)用户评价。对最终输出的系统交由客户进行评价,并获取反馈结果。
软件测试

螺旋模型的优缺点

优点:

1)每个阶段都有用户参加,确保最终实现不偏离用户真正需求;
2)设计上具有灵活性,当不满足用户需求或风险大可以即使变更;
3)减少了整个开发测试的成本。

缺点:

1)对风险评估的经验和知识要求很高,需要有专业人员作出决断;
2)只适用于规模大、风险高的项目。

增量模型

增量迭代是统一软件开发过程(RUP)经常使用的一种软件开发模型,因此增量模型和迭代模型经常放在一起使用,其基本流程都一样,唯一不同的是在对需求进行拆分的时候划分标准不一样。拆分时将需求按照模块进行分类,以模块递增的方式逐步完善。
软件测试

增量模型的优缺点

优点:

1)能够在较短的时间内向用户提交可完成部分工作的产品;
2)逐步增加产品功能可以使用户有较充裕的时间学习适应新产品,从而减少一个全新的软件可能给客户组织带来的冲击。

缺点:

1)较难把每个新的增量构件集成到现有的软件体系结构中,而又不破坏原来已经开发出的产品。
2)增量模型本身是自相矛盾的,它一方面要求开发人员把软件当做一个整体,另一个方面又要求开发人员把软件构件序列,每个构件本质上都独立于另一个构件,除非开发人员有足够的技术能力协调好这一明显的矛盾,否则增量模型开发出来的产品可能并不能令人满意。

V模型

具体实现过程

1.需要分析:明确客户需要是什么,需要软件做成什么样子,有什么功能。
2.概要设计:主要是架构的实现,搭建架构,表述个模块功能、模块接口连接和数据传递的实现等项事物。
3.详细设计:各个模块进行深入分析,对各模块组合进行分析分,这阶段需要伪代码级别,已经把程序的具体实现功能,现象等描叙出来。其中需要包含数据库设计说明。
4.编码:按照详细设计好的模块功能表,编程人员编写出实际代码。
5.单位测试:软件中的最小可测试单元进行检查和验证(一般开发完成)
6.集成测试:在单元测试的基础上,将所有模块按照设计要求组装成为子系统或系统,进行集成测试。
7.系统测试:把软件系统搭建起来,按照软件规格说明书中所需求,测试软件性能功能等是否符合用户需求,在系统中运行是否存在漏洞。(测试用例来进行测试)
8.验收测试:用户根据需要说明书来做相应测试,以确实软件达到效果。
软件测试

V模型的优缺点

优点

1)缩短开发周期
2)提高开发效率

缺点

1)V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段,忽视了测试对需求分析,系统设计的验证,需求的满足情况一直到后期的验收测试才被验证。
2)解决的思路是,当一个软件开发的时候,研发人员和测试人员需要同时工作,测试在软件做需求分析的同时就会有测试用例的跟踪,这样,可以尽快找出程序错误和需求偏离,从而更高效的提高程序质量,最大可能的减少成本,同时满足用户的实际软件需求。

W模型

W模型有利于尽早地全面的发现问题。例如,需求分析完成后,测试人员就应该参与到对需求文档的验证和确认活动中,以尽早地找出缺陷所在。同时,对需求的测试也有利于及时了解项目难度和测试风险,及早制定应对措施,这将显著减少总体测试时间,加快项目进度。 但W模型也存在局限性。在W模型中,需求、设计、编码等活动被视为串行的,同时,测试和开发活动也保持着一种线性的前后关系,上一阶段完全结束,才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况,W模型并不能解除测试管理面临的困惑。
软件测试

优点:

1)测试的活动与软件开发同步进行
2)测试的对象不仅仅是程序,还包括需求和设计
3)尽早发现软件缺陷可降低软件开发的成本

缺点:

1)对有些项目,开发过程中根本没有文档产生,故W模型无法使用。
2)对于需求和设计的测试技术要求很高,实践起来很困难。

验收测试分类:

1.(alpha)测试:前期的用户测试(内部测试)
2.(beta)测试:后期用户测试,(大型游戏公测)