《软件测试基础》PPT课件.ppt

第2章软件测试基础,HelloEveryone,主讲人：许刚电话：13673990036QQ：1411069655,本章要点,软件测试的定义软件测试的对象验证与确认的含义和区别软件测试的分类软件测试过程模型测试驱动开发的思想软件测试的原则软件测试文档的作用和分类,前言,本章的目的在于介绍关于软件测试的基本概念、原则及软件测试文档，以及目前流行的测试驱动开发方法。这些内容是学习后续章节的基础。,2.1.1软件测试的定义和对象1软件测试定义1979年，GlenfordJ.Myers在其著作软件测试的艺术对软件测试定义为：“测试是为了发现错误而执行的一个程序或系统的过程”，这个定义不管是在早期还是当今，都有着相当大的影响。1983年，BillHetzel在软件测试完全指南中指出：“测试是以评价一个程序或系统属性为目标的任何一种活动，测试是对软件质量的度量”。这个定义是对GlenfordJ.Myers定义的很好的补充，至今仍被引用。1983年IEEE对软件测试下的定义是：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”，软件测试不再被认为是一个一次性的、只属于开发后期的活动，而应与软件的整个开发流程融为一体。,2.1软件测试的概念,2.1.1软件测试的定义和对象,2软件测试的对象不仅包括程序，需求分析和设计工作等也应被列为测试的对象。,2.1.2验证与确认(V&V),V&V：验证(Verification)和确认(Validation)，是软件测试领域十分有影响的概念。1验证即检验软件是否实现了预先定义的功能和其他特性，即判断软件开发每一阶段的活动是否已成功地完成，各开发阶段形成的软件配置是否保持一致。2确认也可理解为有效性确认。目的在于判断交付使用的软件可追溯到用户的需求。确认作用是检验软件产品功能及其他特性的有效性。,2.1.2验证与确认(V&V),3验证和确认的关系从表面上看，对验证和确认的描述十分类似。它们的区别在哪里呢？以下是Boehm对V&V中两者的解释。Verification：Arewebuildingtheproductright(我们在正确地构造软件吗)?Validation：Arewebuildingtherightproduct(我们在构造正确的软件吗)?,2.1.2验证与确认(V&V),虽然定义中同样都含有“正确”，但确认定义中的“正确”级别更高，它要求开发出来的软件对用户是真正有效的，能满足用户所有的最终需求，而这些需求中有些可能是潜在的。而验证定义中的“正确”只能说明软件开发的各阶段实现了既定的要求，但这些既定要求本身可能存在问题。,2.1.2验证与确认(V&V),验证和确认都属于测试活动。可以认为：验证+确认=测试验证和确认是不同级别的测试活动。,2.2.1按开发阶段分类按开发阶段，软件测试可以划分为：单元测试集成测试确认测试系统测试验收测试,2.2软件测试分类,2.2.1按开发阶段分类,1单元测试单元测试（UnitTesting）又称模块测试是针对软件设计中的最小单位程序模块，进行正确性检验的测试。目的在于：发现程序模块内部可能存在的各种错误，检查各模块是否实现了详细设计说明中的模块功能、性能、接口以及设计约束等方面的要求。,2.2.1按开发阶段分类,2集成测试集成测试（IntegratedTesting）也称为组装测试。在单元测试的基础上，将所有程序模块按照概要设计要求组装成一个系统。目的在于：发现并排除在模块连接过程中可能出现的问题，最终构成符合概要设计要求的软件系统。,2.2.1按开发阶段分类,3确认测试确认测试（ValidationTesting）又称为有效性测试。目的是：检查已实现的软件系统是否满足了需求规格说明书中规定的各种需求，以及软件配置是否完全、正确。,2.2.1按开发阶段分类,4系统测试系统测试（SystemTesting）将通过确认测试的软件，作为整个计算机系统的一个元素，在实际运行环境下或模拟系统运行环境下，测试其与系统中其他元素（硬件、外设、网络、系统软件、支持平台等）能否正确地配置、连接，并满足用户需求。目的是：通过与系统的需求定义作比较,发现软件与系统的定义不符合的地方。,2.2.1按开发阶段分类,5验收测试验收测试（AcceptanceTesting）即按项目任务书或合同、供需双方约定的验收依据文档对整个系统进行测试与评审，以决定是否接收软件系统。以用户为主的测试，但软件开发人员和SQA（即SQA人员）也应参加。,2.2.2按测试实施组织分类,按照实施测试的组织，可将测试分为：测试测试第三方测试。,2.2.2按测试实施组织分类,1测试测试（AlphaTesting）属于开发方进行的测试，指软件开发方组织公司内部人员模拟各类用户对即将交付的软件产品（称为版本）进行的测试。测试的关键在于尽可能逼真地模拟软件的实际运行环境，并尽最大努力涵盖所有可能的用户操作方式。测试的目的是评价软件产品的FLURPS(Function、Localization、Usability、Reliability、Performance、Support），即功能、局域化、可使用性、可靠性、性能和支持，尤其注重产品的界面和特色。经过测试调整的软件产品称为版本。,2.2.2按测试实施组织分类,2测试测试（BetaTesting）是用户进行的测试，但通常不等同于验收测试，即决定是否接收软件并不是测试的目的。测试的目的在于帮助开发方在正式发布软件产品前对其进行最后的改进。测试一般在测试之后进行，是由大量用户在实际操作环境下对软件的版本进行的测试。开发方根据用户的错误报告，在正式发布软件产品之前对之进行一系列改进。测试主要衡量产品的FLURPS，着重于产品的支持性，包括文档、客户培训和支持产品生产能力。,补充知识,RC(release.candidate)：发行候选版本和beta版最大的差别在于beta阶段会一直加入新的功能，但是到了RC版本，几乎就不会加入新的功能了，而是着重于除错！RC1就代表发行侯选第一版。,补充知识,RTM(release.to.manufacturing)正式在零售商店上架前，需要一段时间来压片，包装、配销，所以程序代码必须在正式发行前一段时间就要完成，这个完成的程序代码叫做final.code。程序代码开发完成之后，要将母片送到工厂大量压片，这个版本就叫做RTM版。所以说，RTM版的程序码一定和正式版一样。但是和正式版也有不一样的地方：例如正式版中的OEM不能升级安装，升级版要全新安装的话会检查旧版操作系统光盘等，这些就是RTM和正式版不同的地方，但是它们的主要程序代码都是一样的。严格的说这种版本还是属于fpp零售版，需要激活的那种。,补充知识,retailfullpackagedproduct(fpp)：零售版就是在各大软件店看到有漂亮包装的那种。可以升级安装，也可以全新安装。但是需要激活，机器配置更换了还要通知微软，是比较痛苦的东西。,补充知识,OEMOEM是（OriginalEquipmentManufacture，原始设备制造商）的缩写，它是指一种“代工生产”方式，其含义是：品牌拥有者不直接生产产品，而是利用自己掌握的“关键核心技术”，负责设计和开发、控制销售“渠道”，具体的加工任务交给别的企业去做的方式。之后将所订产品低价买断，并直接贴上自己的品牌商标。这种方式是在电子产业大量发展起来以后才在世界范围内逐步形成的一种普遍现象，戴尔、惠普、IBM等国际上的主要大企业均采用这种方式。,补充知识,VOL(volumelicensingfororganizations)：团体批量许可证（大量采购授权合约）。可能有人会认为这个不是VLO么？其实VOL是取了volume的前3个字母而已，不是3个词的字母缩写。比如英文wxppro的VOL版本的光盘卷标就是wxpvol_en，其中wx表示是windowsxp，p是professional（vol没有home版本），VOL表明是团体批量许可证版本，en是表明是英语。获得途径主要是集团购买，某些msdn用户也可以得到。这种版本根据购买数量等又细分为“开放式许可证”、“选择式许可证”、“企业协议”、“学术教育许可证”等以下5种版本：openlicenseselectlicenseenterpriseagreemententerprisesubionagreementacademicvolumelicensing,补充知识,VLK：volumelicensing(product)keys，即VLK，它所指的只是一个key（密匙），仅仅是一个为证明产品合法化、以及安装所使用的key，因为根据VOL计划规定，VOL产品是不需要激活的！或者说，VLK不是指一种版本，而是指这种版本在部署（deploy）过程中所需要的key，而需要VLK这种key的版本应该叫做VOL！只不过在实际中，没有必要强调这种叫法、称呼的准确性，加之很多人的VOL版本光盘是通过企业的选择式许可证、企业协议等方式得到的等等原因，所以才会有很多人叫他为“选择版”等等。,2.2.2按测试实施组织分类,3第三方测试是由不同于开发方和用户方的组织进行测试。通常模拟用户的真实操作环境，对软件进行确认测试。有利于客观、公正地测试、评价软件。,2.2.3按测试策略分类,根据测试实施的策略不同，软件测试可分为：白盒测试黑盒测试灰盒测试,2.2.3按测试策略分类,1白盒测试白盒测试（White-boxTesting）又称为结构测试或逻辑驱动测试。“白盒”可理解为程序装在一个透明的盒子里，所以盒子内的程序对测试人员是可见的。测试人员清楚地了解程序内部逻辑结构和处理过程，检查程序内部结构和路径是否达到了预期的设计要求。,2.2.3按测试策略分类,2黑盒测试黑盒测试（Black-boxTesting）又称为功能测试或数据驱动测试。“黑盒”可理解为程序装在一个漆黑的盒子里，盒子内的程序对测试人员是不可见的。测试人员在已知软件应具有的功能基础之上，完全不考虑程序内部逻辑结构和过程，在程序接口处进行测试，检查在需求规格说明书中规定的预期功能能否正常实现。,2.2.3按测试策略分类,3灰盒测试灰盒测试（Gray-boxTesting）是一种介于白盒测试和黑盒测试之间的测试。它基于程序运行的外部表现同时又结合程序内部逻辑结构来设计测试用例，执行程序并采集程序路径执行信息和外部用户接口结果。集成测试阶段采用的测试策略近似于灰盒测试。,2.2.4按测试执行方式分类,根据软件测试的执行方式，软件测试可分为静态测试（StaticTesting）和动态测试(DynamicTesting)。静态测试不实际执行程序，可利用人工手段及静态测试工具来完成对程序的静态测试。主要目的是检查软件的表示和描述是否一致。动态测试实际运行测试用例，以发现软件中的错误。依据黑盒方法设计的测试是动态测试，白盒方法设计的测试则包括静态测试和动态测试两种类型。,2.2.5其他测试方法和技术,在实际应用中，还有许多具体的测试类型，它们往往是为实现某特定目标而进行的测试。,1回归测试回归测试（RegressionTesting）是为了验证对软件引入修改的正确性及其影响而进行的测试。软件开发的各个阶段都会进行多次回归测试。,2.2.5其他测试方法和技术,2迭代测试是从迭代的开发模式中延伸出的。在每个迭代周期中，测试工作由两方面组成：对当前迭代周期产品的增量测试。对原先迭代周期已完成功能的回归测试。迭代开发模式继承了瀑布开发模式的优点：全面、计划性强和易于管理。更为重要的是，迭代开发模式将测试工作分布到每个迭代周期中，使测试工作提前进行，以尽早地发现软件中的缺陷，从而降低软件开发的风险和成本。,2.2.5其他测试方法和技术,2.2.5其他测试方法和技术,3功能测试功能测试（FunctionalTesting）也称为行为测试(BehavioralTesting)其根据产品特征、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。,2.2.5其他测试方法和技术,4性能测试性能测试（PerformanceTesting）是评价一个产品或组件与性能需求是否符合的测试，包括负载（压力）测试、强度测试、容量测试、疲劳测试等类型。,2.2.5其他测试方法和技术,5安全性测试安全性测试（SecurityTesting）的目的在于检测软件系统对非法侵入的防范能力。理论上讲，只要拥有足够多的时间和资源，任何系统都是可以侵入的。,2.2.5其他测试方法和技术,6可靠性测试可靠性测试（ReliabilityTesting）的目的是测算在一定的环境下，系统能正常工作的概率。通常，用平均无故障时间（MeanTimebetweenFailures，MTBF）即两次失效之间的平均操作时间来衡量系统的可靠性。,2.2.5其他测试方法和技术,7兼容性测试（配置测试）兼容性测试(CompatibilityTesting)有时也被称为配置测试（ConfigurationTesting），但两者含义略有不同。配置测试是为了保证软件在其相关的硬件上能够正常运行。兼容性测试则主要是测试软件能否与不同的软件协作运行。,2.2.5其他测试方法和技术,8可移植性测试可移植性测试（PortabilityTesting）的目的在于验证软件能否被移植到指定的硬件或软件平台上。,2.2.5其他测试方法和技术,9冒烟测试冒烟测试（SmokeTesting）的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。执行者是版本编译人员。不能由测试小组独立来建立，应该是通过联合的方式，至少是在与开发人员达成一致的情况下建立的。目标是显示稳定性，而不是发现错误。必须在系统测试环境中进行冒烟测试。,2.2.5其他测试方法和技术,10用户界面测试用户界面测试（UserInterfaceTesting）的目的在于测试用户界面的风格是否满足客户要求，包括用户友好性、人性化、易操作性等测试。,2.2.5其他测试方法和技术,11随机测试随机测试（AdHocTesting）是没有书面测试用例的测试，主要是依据测试人员的经验对软件进行功能和性能抽查。随机测试是根据测试文档执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式。,2.2.5其他测试方法和技术,12引导测试引导测试（PilotTesting）是在软件开发中验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中，引导测试通常是客户检查软件测试公司测试能力的一种形式，只有通过了客户特定的引导测试，软件测试公司才能接受客户真实软件项目的软件测试。,2.2.5其他测试方法和技术,13本地化测试本地化测试（LocalizationTesting）的对象是软件的本地化版本，测试目的在于测试特定目标区域设置的软件本地化质量。本地化测试的内容主要是软件本地化后的界面布局和软件翻译的语言质量，包含软件、文档和联机帮助等部分。,测试过程的质量将直接影响测试实施的效果。软件测试过程和软件开发过程一样，都应遵循软件工程的原理。,2.3软件测试过程,2.3.1软件测试过程模型,随着测试过程管理的发展，测试人员通过大量的实践总结出了很多很好的测试过程模型。这些模型将测试活动进行了抽象，并与开发活动进行了有机的结合，是测试过程管理的重要参考依据。,1模型反映了测试活动与分析设计活动的关系，如图所示。V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；确认测试和验收测试追溯软件需求规格说明书进行测试，确认软件的实现是否满足用户需要或合同的要求。局限性：仅把测试作为在编码之后的一个阶段，主要是针对程序进行的寻找错误的活动，对软件设计、需求分析等活动的测试要到后期才能完成。使修复错误的代价大大增加，不利于提高软件开发的测试的效率。,2.3.1软件测试过程模型,2.3.1软件测试过程模型,2W模型为弥补V模型的不足，W模型出现了。W模型相对于V模型，增加了软件各开发阶段中应同步进行的验证和确认活动。如图所示，W模型由两个V字型模型组成，分别代表测试与开发过程。从图可明显看出测试与开发的并行关系，也就是说，测试与开发是紧密结合的。,2.3.1软件测试过程模型,W模型强调：测试伴随着软件开发的各阶段，测试的对象不仅仅是程序，需求分析、设计等同样要测试。测试与开发是同步进行的。W模型有利于尽早地、全面地进行测试，以发现软件中存在的问题。W模型也有利于全过程地测试。W模型存在局限性。在W模型中，需求分析、设计、编码等活动被视为串行的，同时，测试和开发活动之间也是线性的关系，某开发活动完全结束后才可以正式开始进行测试，这样就无法支持迭代、自发性及变更调整。,2.3.1软件测试过程模型,3H模型V模型和W模型都把软件的开发过程中的需求分析、设计、编码等活动视为串行的，而这并不现实。故与各开发阶段相对应的测试之间也不可能保持严格的次序关系。同时，各层次的测试（单元测试、集成测试、系统测试）也存在反复触发、迭代和增量关系。,2.3.1软件测试过程模型,为解决以上问题，H模型被提出。它将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来，如图所示。图表示的仅为整个软件生产周期中某个层次上的一次测试。图中标注的其他流程可以是任意的开发流程，也可以是非开发流程，如SQA流程，甚至是测试流程自身。只要测试准备活动完成，达到了测试就绪点，就可执行测试工作。,2.3.1软件测试过程模型,4其他模型除上述几种常见模型外，业界还流传着其他模型，例如X模型、前置测试模型等。,2.3.1软件测试过程模型,2.3.2测试过程的实施策略,1测试过程模型选取策略任何测试模型都不是万能的，应针对具体的开发项目灵活选择测试过程模型，尽可能地利用各种模型对项目中有实用价值的方面，不能为使用模型而使用模型。一般说来，在实际的测试活动中，可以以W模型为框架，及早地、全面地开展测试，同时灵活运用H模型独立测试的思想，将测试和开发过程紧密结合，在达到恰当的测试就绪点时执行独立的测试工作，测试工作应是可迭代的。,2测试过程管理理念测试过程管理理念是从无数的测试实践中提炼出来的，能指导测试人员成功地策划和开展测试过程，对于测试人员是不可或缺的精神财富。(1)尽早测试是从W模型中抽象出来的理念。测试与开发是并行的，在开发的早期需求分析阶段就应开展测试。易于制定出完善的测试计划和方案，提高软件测试及开发的效率,规避测试中存在的风险。尽早开展测试执行工作，有利于测试人员尽早地发现软件中的缺陷，大大降低了错误修复的成本。,2.3.2测试过程的实施策略,(2)全面测试软件是程序、数据和文档的集合，因而软件测试不仅仅是对程序的测试，还应包括对软件副产品的全面测试，这是W模型中的重要理念。大量实践表明，软件中的大部分错误不是在编码阶段而是在编码之前的需求分析和设计中造成的。,2.3.2测试过程的实施策略,“全面测试”的含义：第一，对软件的所有阶段性产品进行全面的测试，包括需求分析文档、设计文档、程序代码、用户文档等。第二，软件开发人员及测试人员（有时还包括用户）全面参与到测试工作中，例如对需求的验证和确认活动，就需要开发人员、测试人员及用户的共同参与。,2.3.2测试过程的实施策略,(3)全过程测试W模型中体现的另一个测试理念就是“全过程测试”。W模型的双V字形象地表明了软件开发与软件测试的紧密结合。,2.3.2测试过程的实施策略,“全过程测试”的含义：测试人员要充分关注开发过程，对开发过程的各种变更及时做出响应。测试人员要对测试的全过程进行跟踪，及时了解测试过程信息，调整测试策略，持续改进测试过程。,2.3.2测试过程的实施策略,(4)独立的、迭代的测试是H模型倡导的理念。大多数的开发都存在着需求分析、设计、编码等活动的迭代，故对应的测试工作也是可迭代的。测试应成为一个独立的流程，只要测试准备工作完成，达到了相应的测试就绪点，就可执行测试。“独立的、迭代的测试”有利于应对开发过程复杂多变的情况，使得测试工作更加灵活，与开发活动也结合得更紧密，因而“独立的、迭代的测试”也非常有利于全过程测试。,2.3.2测试过程的实施策略,2.4.1测试驱动开发的概念测试驱动开发（Test-DrivenDevelopment，TDD）是极限编程（eXtremeProgramming，XP）的一个重要组成部分。基本思路就是通过测试来推动整个开发的进行。也就是在明确要实现某个功能的开发后，首先思考如何对这个功能进行测试，并完成测试代码的编写，接着编写相关的代码满足这些测试用例。然后循环添加其他功能，直到完成全部功能的开发。,2.4测试驱动开发,2.4.1测试驱动开发的概念,测试驱动开发的基本步骤：明确当前要完成的功能点（所有功能点记录在测试列表中）。快速完成针对此功能的测试用例编写。编译测试代码，结果为通不过。编写对应的功能代码。测试代码编译通过。对代码进行重构，并保证全部测试代码运行通过。循环完成所有功能的开发。,2.4.2测试驱动开发的优点,考虑实施TDD的最初目的：更好地适应需求及需求变更。简化开发过程。缩短开发周期。,TDD的优点还包括：项目进度可预测。而传统方式很难知道什么时候编码工作结束。大部分时间代码处在高质量状态，100时间里成果是可见的。提供了全面正确地认识代码和利用代码的机会。为利用已有成果的人提供Sample，无论是要利用源代码，还是重用组件。系统可以与详尽的测试集一起发布，从而对软件将来版本的扩展提供方便。将设计、编码、测试融为一体。开发小组间降低了交流成本，提高了相互信赖程度。由于能清晰、无二义地描述对代码的需求，减少了文档对代码需求描述不清而引入Bug的可能。在预先设计和紧急设计之间建立一种平衡点，避免了过度设计。有利于发现比传统测试方式更多的Bug。使IDE的调试功能失去意义，避免了令人头痛的调试。,2.4.2测试驱动开发的优点,2.4.3测试驱动开发的原则,测试隔离。专注于当前工作。防止过度设计。及时补充测试列表。先写断言（Assertion）。及时重构。,2.4.4关于测试驱动开发的一些讨论,是写测试代码还是写测试文档何时停止编写测试用例何时设计为一个特性编写测试用例还是作为一个类编写测试用例何时应将全部测试都运行一遍什么场合不适合运用TDD,推荐一本书,2.5软件测试的原则,应尽早地、全面地、全过程地、独立地开展测试活动。所有的测试标准应建立在满足用户需求的基础上。程序员应避免检查自己的程序。设计测试用例时，应该考虑合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，以检验软件在各种可能的情况下能否正常工作。要充分注意测试中错误的集中发生现象，这和程序员的编程习惯有很大关系。对测试中发现的错误应当有一个确认的过程，严重的错误可以召开评审会进行讨论和分析。制定严格的测试计划并执行之，杜绝测试的随意性，不要希望在极短的时间内完成一个高水平的测试。充分重视回归测试。妥善保存一切测试文档。,2.6软件测试文档,2.6.1软件测试文档概述软件测试贯穿于开发的全过程，是一项复杂的工作。应当把测试也作为一个项目，对其进行有效的计划管理。软件测试文档(SoftwareTestDocumentation)为测试项目的组织、规划和管理提供了架构。软件测试文档主要包括测试计划、测试设计、测试用例、测试规程、测试事件报告、测试总结报告等。标准化的测试文档所规定的内容可以作为对测试过程完备性的对照检查表，有助于提高测试过程中的每个阶段的能见度，极大地提高测试工作的可管理性。,2.6.2计算机软件测试文件编制规范(GB/T9386-1988)简介,引用标准关键术语定义规范的主要内容对规范的实施,2.6.3规范GB/T9386-1988中的内容要求,测试计划测试设计说明测试用例说明测试规程说明测试项传递报告测试日志测试事件报告测试总结报告,2.7小结,本章阐述了软件测试的一系列基本概念、原则，还介绍了软件测试文档的作用、分类及编写规范，是学习后续章节的基础。首先介绍了软件测试的定义、对象及著名的V&V，接着从不同角度介绍了软件测试的分类，讨论了几个重要的软件测试过程模型，并阐述了测试过程管理的若干理念以及测试驱动开发的思想和原则，指出了软件测试的若干原则，最后介绍了软件测试文档的作用、分类及编写规范。,谢谢大家,