软件测试基础知识及流程.ppt

软件测试 基础知识培训,（内部文件请勿外漏）仅限于培训使用，随着公司的发展将不断修订 若与公司制度有冲突的，则以公司的制度为准,什么是软件测试,使用人工或者自动手段来运行或测试某个系统的过程 目的在于检验它是否满足规定的需求、弄清预期结果与实际结果之间的差别,软件测试目的,测试是为了发现系统中的错误而执行程序的过程 好的测试方案在于尽可能发现迄今为止尚未发现的错误 成功的测试是发现了至今为止尚未发现的错误的测试,软件测试目的,测试并不仅仅是为了找出错误.通过分析错误产生的原因和错误的发生趋势,可以帮助项目管理者发现当前软件开发过程中的缺陷,以便及时改进 这种分析也能帮助测试人员设计出有针对性的测试方法,改善测试的效率和有效性； 没有发现错误的测试也是有价值的,完整的测试是评定软件质量的一种方法,软件测试原则,所有的软件测试都应追溯到用户需求 应当把“尽早地和不断地进行软件测试”作为软件测试人的座右铭 完全测试是不可能的，测试需要终止 测试无法显示系统所有潜在的缺陷,软件测试原则,充分注意测试中的群集现象 程序员应避免检查自己的程序 尽量避免测试的随意性，应从工程的角度理解软件测试，它是有组织、有计划、有步骤的活动,软件测试对象,程序 数据 文档 过程 硬件 网络,软件测试关键词,单元测试 集成测试 系统测试 确认测试 验收测试 白盒测试 黑盒测试 灰盒测试,单元测试,单元测试又称模块测试 是针对软件设计的最小单元程序模块进行正确性检验的测试工作 其目的在于检查每个程序单元能否实 现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的错误,集成测试,集成测试，也叫组装测试或联合测试 在单元测试的基础上，将所有模块按照设计要求）如根据结构图组装成为子系统或系统，进行集成测试 集成测试是检验程序单元和部件的接口关系 实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现,系统测试,系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方 系统测试的任务是近可能彻底的检查出程序中的错误，提高软件系统的可靠性，其目的是检验系统“做得怎样？“,确认测试,确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是确认测试的任务，即软件的功能和性能如同用户所合理期待的那样 确认测试又称有效性测试。有效性测试是在模拟的环境下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定，它包含的信息就是软件确认测试的基础,验收测试,系统开发生命周期方法论的一个阶段，这时相关的用户和或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试 这是管理性和防御性控制的测试过程,白盒测试,白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作 是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致,黑盒测试,黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用 在测试地，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息 黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试,灰盒测试,灰盒测试，确实是介于白盒测试与黑盒测试之间的测试 灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法,软件过程模型（了解）,瀑布模型 原型模型 螺旋模型 增量模型 喷泉模型 统一过程（RUP）,瀑布模型,瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开 将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落 从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来,瀑布模型图,原型模型,先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的 原型模型通过向用户提供原型获取用户的反馈，使开发出的软件能够真正反映用户的需求。同时，原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应。相对瀑布模型而言，原型模型更符合人们开发软件的习惯，使目前较流行的一种实用软件生存期模型,原型模型图,螺旋模型,1988年，BarryBoehm正式发表了软件系统开发的“螺旋模型“，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。 螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动： （1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件； （2）风险分析：分析评估所选方案，考虑如何识别和消除风险； （3）实施工程：实施软件开发和验证； （4）客户评估：评价开发工作，提出修正建议，制定下一步计划。,螺旋模型图,增量模型,增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量” 当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布 客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品,增量模型图,喷泉模型,喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目 该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性 软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分 无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限，由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系，从而可以较为容易地实现活动的迭代和无间隙，使其开发自然地包括复用,喷泉模型图,统一过程模型,RUP（Rational Unified Process，统一软件开发过程，统一软件过程)是一个面向对象且基于网络的程序开发方法论 根据Rational(Rational Rose和统一建模语言的开发者)的说法，好像一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针，模版以及事例支持 RUP和类似的产品-例如面向对象的软件过程（OOSP），以及OPEN Process都是理解性的软件工程工具-把开发中面向过程的方面（例如定义的阶段，技术和实践）和其他开发的组件（例如文档，模型，手册以及代码等等）整合在一个统一的框架内,统一过程模型（RUP）图,测试模型,V模型 W模型 H模型 X模型,V模型图,W模型图,H模型图,在整个生产周期中某个层次上的一次测试“微循环”。图中的其他流程图可以是任意开发流程。例如，设计流程和编码流程。也可以是其他非开发流程，例如，SQA流程，甚至是测试流程本身。只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了,X模型,X模型是由Marick提出的 X模型描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交换，通过集成最终合成为可执行的程序 X模型是一种探索测试模型,X模型图,测试策略,测试信息流 分析设计阶段 需求说明书评测 概要设计说明书评测 详细设计说明书评测 软件编码规范评测 开发阶段 单元测试 集成测试 确认测试 系统测试 验收测试 软件验证和确认过程,天讯天网测试过程,测试流程图 需求分析 测试计划 测试设计 测试环境搭建 测试执行 测试记录,测试流程图,需求分析,需求分析是软件测试的一个重要环节，一般而言，需求分析包括软件功能需求分析、测试环境需求分析、测试资源需求分析等。其中最基本的是软件功能需求分析，测一款软件首先要知道软件能实现哪些功能以及是怎样实现的。比如绿网天下包括记录查询、软件限制、网址限制等功能。那我们就应该知道软件是怎样来实现这些功能的，为了实现这些功能需要哪些测试设备以及如何搭建相应测试环境等，否则测试就无从谈起 做测试需求分析的依据有软件需求文档、软件规格书以及开发人员的设计文档等。,测试计划,测试计划一般由测试负责人来编写。测试计划的依据主要是项目开发计划和测试需求分析结果而制定 测试计划一般包括以下一些方面：测试背景、项目涉及人员、测试依据、测试资源、测试策略、测试日程、还要包括测试计划编写的日期、作者等信息，计划越详细越好 计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照原有计划开展。如在软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。所以，这些就要求测试负责人能够从宏观上来调控了,测试设计,测试设计主要包括测试用例编写和测试场景设计两方面 测试场景设计主要也就是测试环境问题 测试用例文档由简介和测试用例两部分组成。简介部分编制测试目的、测试范围、定义术语以及测试背景等。测试用例部分逐一列示各测试用例，测试用例应当包括测试标识、测试用例名称、目标、测试条件、测试设置、输入数据要求、步骤、以及预期的结果等,测试环境搭建,不同软件产品对测试环境有着不同的要求。如C/S及B/S架构相关的软件产品，那么对不同操作系统，如windows系列、unix、linux甚至苹果OS等，这些测试环境都是必须的 为了测试一款软件，我们可能根据不同的需求点要使用很多不同的测试环境。有些测试环境我们是可以搭建的，有些环境我们无法搭建或者搭建成本很高。不管如何，我们的目标是测试软件问题，保证软件质量。测试环境问题，还是根据具体产品以及开发者的实际情况而采取最经济的方式,测试执行,测试执行过程又可以分为以下阶段： 单元测试集成测试系统测试出厂测试，其中每个阶段还有回归测试 从测试的角度而言，测试执行包括一个量和度的问题。也就是测试范围和测试程度的问题。比如一个版本需要测试哪些方面？每个方面要测试到什么程度？ 从管理的角度而言，在有限的时间内，在人员有限甚至短缺的情况下，要考虑如何分工，如何合理地利用资源来开展测试。,测试记录1,缺陷记录总的说来包括两方面：由谁提交和缺陷描述。 一般而言，缺陷都是谁测试谁提交。在缺陷的描述上，至少要包括以下一些方面内容：序号、标题、预置条件、操作步骤、预期结果、实际结果、注释、严重程度、概率、版本、测试者、测试日期；以上是描述一个Bug时通常所要描述的内容，当然在实际提交bug时可以根据实际情况进行补充，如附上图片、log文件等,测试记录2,另外，一个版本软件测试完毕，还要根据测试情况出份测试报告，这也是所要经过的一个环节 缺陷管理：缺陷管理方面，目前我们公司采取缺陷管理工具Bugfree进行管理、 Bugfree地址： 54/Login.php,软件测试国家标准,GB/T 9386-1988 计算机软件测试文件编制规范 GB/T 15532-1995 计算机软件单元测试规范 GB/T 17544-1998 信息技术 软件包 质量要求和测试 GB/T 16260.1-2003 软件工程 产品质量第1部份，质量模型 GB/T 16260.2-200X软件工程 产品质量第2部份，外部度量 GB/T 16260.3-200X软件工程 产品质量第3部份，内部度量 GB/T 16260.4-200X软件工程 产品质量第4部份，使用质量度量 GB/T 18905.1-2002软件工程 产品质量第1部份，概述 GB/T 18905.2-2002软件工程 产品质量第2部份，策划和管理 GB/T 18905.3-2002软件工程 产品质量第3部份，开发者用的过程 GB/T 18905.4-2002软件工程 产品质量第4部份，需方用的过程 GB/T 18905.5-2002软件工程 产品质量第5部份，评价者用的过程 GB/T 18905.6-2002软件工程 产品质量第6部份，评