软件测试技术基础

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