软件测试 第一章 概述.doc

目录第一章概述211软件测试的发展历程及现状2111 软件测试的发展历程2112软件测试的现状212什么是软件测试3121 软件测试的定义3122 软件质量4123 软件测试生命周期（sofftware testing life cycle）4123 软件开发与测试模型5124 与软件测试相关的术语713软件测试技术分类714软件测试的目的815软件测试的原则8151 尽早的和不断的进行软件测试8152 不可能完全的测试9153 增量测试，由小到大9154 避免测试自己的程序10155 设计周密的测试用例10156 注意错误集中的现象10157 确认BUG的有效性11158 合理安排测试计划11159 回归测试121510 测试结果的统计和分析121511 及时更新测试1316软件测试工作流程1417软件测试中的误区17第一章 概述本章要点软件测试的发展历史；软件测试技术的分类方法；软件测试原则；软件测试的定义；软件测试同软件开发之间的关系；软件测试与开发模型；软件测试工作流程本章目标l 了解软件测试的发展历程和行业现状l 掌握软件测试技术的分类l 理解软件测试的目的和测试原则，了解人们对软件测试行业的错误认识l 掌握软件测试中的基本定义、基本知识l 理解软件开发与软件测试的关系11软件测试的发展历程及现状111 软件测试的发展历程一、 计算机诞生：软件测试（类似于调试）二、 20世纪50年代60年代：诞生各种高级语言，测试理论与方法发展依然缓慢三、 20世纪70年代：开发技术的成熟与完善软件规模大复杂度增加可靠性危机挑战软件测试测试理论和测试方法测试人才112 软件测试的现状开发工程师与测试工程师的比例微软：1：2国内：6：112什么是软件测试121 软件测试的定义软件测试的研究至今已有40多年的发展历史，但对于什么是软件测试（ software testing）,还一直未能达成共识，根据侧重点的不同，主要有以下三种观点：n IEEE在1983年将软件测试定义为“使用人工或自动手段运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别”，该定义明确的提出了软件测试以检验是否满足需求为目标。n Myers则认为软件测试“是为了发现错误而执行程序的过程”，明确提出了“寻找错误”是测试目的。n 从软件质量保证的角度看，软件测试是一种重要的软件质量保证活动，其动机是通过一些经济、高效的方法，捕捉软件中的错误，从而达到保证软件内在质量的目的。定义：软件测试是一个在可控的环境中执行软件的过程，目的就是为了验证软件是否按照预期运行。测试活动包括“分析”、“运行”软件静态测试（static testing）：与分析软件开发中的产品相关的测试活动，包括：代码审查、走查和桌面检查。动态测试（dynamic）：与运行软件测试有关的活动。测试对象：源程序、需求规格说明、概要设计说明、详细设计说明注意：测试包括寻找缺陷，但不包括跟踪漏洞极其修复软件测试的2个基本职责：验证（verification）:保证开发过程中某一具体阶段的产品与该阶段和前一阶段的需求一致。确认（validation） : 保证最终得到的产品满足系统需求。软件测试与调试的差别：1、调试是一个分析和定位软件BUG的过程。可以认为它是一总支持测试，但不能完全替代测试活动。2、调试的目的是为了使软件能够正确运行，而测试的目的是为了发现软件中存在的错误。3、调试的对象主要是源代码，而测试的对象则是软件开发过程中各个阶段所产生的所有产品。122 软件质量1991年软件产品质量评价国际标准ISO9126中定义的“软件质量”是：软件满足规定或潜在用户需求特性的总和。1999年，软件“产品评价”国际标准ISO14598经典的“软件质量”定义是：软件特性的总和，软件满足规定或潜在用户需求的能力。软件测试与质量保证的区别：质量保证：（QA）质量保证的重要工作通过预防、检查与改进来保证软件质量。QA采用“全面质量管理”和“过程改进”的原理开展质量保证工作。所关注的是软件质量的检查与测量。软件测试：关注的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。123 软件测试生命周期（software testing life cycle） 错误需求规格说明错误 错误 设计 错误 错误 编码 错误 修复缺陷排除 错误缺陷分离 缺陷分类 测试失效 错误 图1-1 软件测试生命周期123 软件开发与测试模型测试过程包括：确定要测试什么（测试范围和条件）以及产品如何被测试（制作测试用例），建立测试环境，执行测试，最后再评估测试结果，检查是否达到已完成测试的标准，并报告进展情况等活动。评审评审已集成软件用户需求定义需求分析书书已确认软件可交付软件需求分析系统测试确认测试概要设计需求获取软件产品需求分析评审评审评审评审概要设计书集成测试详细设计评审已测试模块评审详细设计书书单元测试编码程序图1-2 V模型示意图V模型的价值：l 单元测试的主要目的是根据详细设计说明书来验证和确认每个单元模块是否符合预期的要求，发现编码过程中存在的各种错误。l 集成测试的主要目的是根据概要设计来验证和确认各个模块是否已正确集成到一起，主要是检查各单元与其他模块之间的接口上可能存在的错误。l 确认测试的主要目的是根据需求分析定义、验证和确认软件是否符合用户的预期要求。l 系统测试的主要目的是根据需求定义、验证和确认系统作为一个整体是否能够正常有效的运行，例如：判断系统是否达到了用户预期的性能。需求测试需求分析验收系统测试功能测试概要设计确认确认测试设计测试详细设计集成测试集成单元测试编码图1-3 W模型示意图W模型的优点：每个软件开发活动结束后就可以执行相应的测试 测试就绪点测试执行测试准备测试流程其他流程 图1-4 H模型示意图H模型揭示了：l 软件测试不仅仅指测试的执行，还包括很多其他的活动。l 软件测试是一个独立的流程，贯穿产品的整个开发周期，与其他流程并发进行。l 软件测试要尽早准备，尽早执行。l 软件测试根据被测物的不同是分层次的，不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。124 与软件测试相关的术语1、错误（Error）：程序员在编写代码时会出错，把这种错误称之为BUG？。2、缺陷（Default）：缺陷是错误的结果，更确切的说是错误的表现。过错缺陷：将某些信息输入到了不正确的表现方式中遗漏缺陷：没有输入正确的信息3、失效（Failure）：缺陷运行所导致的结果。4、测试（Test）：是一项采用测试用例执行软件的活动。测试活动有2个目标：找出失效和显示软件执行正确。测试可以由一个或多个测试用例组成。5、测试用例（Test Case）：6、回归测试（Regression Testing）：完全回归测试和部分回归测试13软件测试技术分类1、从是否需要执行被测软件的角度分类：静态测试定义：不利用计算机运行被测程序，而是通过其他手段到达测试目的的方法称做静态测试。方法：代码检查和走查，以及桌面检查和同行评分。动态测试：黑盒测试与白盒测试。2、从软件测试用例设计方法的角度分类：黑盒测试（Black-Box Testing）： 是一种从用户观点出发的测试，又称为功能测试、数据驱动测试和基于规格说明的测试。白盒测试（White-Box Testing）：又称为结构测试、逻辑驱动测试或基于程序的测试。它是基于产品的内部结构来进行测试，检查内部操作是否按规定来执行，软件各个部分功能是否得到充分利用。3、从软件测试的策略和过程的角度分类：单元测试（Unit Testing）：是针对每个单元的测试，是软件测试的最小单位。它确保每个模块能够正常工作。单元测试多数使用白盒测试，用于发现内部错误。集成测试（Integration Testing）：是对已测试过的模块进行组装，进行集成测试的目的主要在于检验与软件设计相关的程序结构问题。集成测试一般使用黑盒测试方法来完成。确认测试（Validation Testing）：检验所开发的软件能否满足所有功能和性能需求的最后手段，通常采用黑盒测试方法。系统测试（System Testing）：主要是检测被测软件与系统的其他部分的协调性，如：能否适应硬件环境、数据库环境。验收测试（Verification Testing）：是软件产品质量的最后一关。这一环节，测试主要从用户的角度着手，其参与者主要是用户和少量的程序开发人员。14软件测试的目的Myers提出关于测试的几条规则，我们可以看作是测试的目标：（1）软件测试是为了发现错误而执行程序的过程。（2）软件测试是为了证明程序有错，而不是证明程序无错。（3）一个好的测试用例在于它能发现至今未发现的错误。（4）一个成功的测试是发现了至今未发现的错误软件测试的目的：“找错误”15软件测试的原则151 尽早的和不断的进行软件测试编码阶段缺陷详细设计阶段缺陷概要设计阶段缺陷需求阶段缺陷 放大n1倍 放大n2倍 放大n3倍图1-5 缺陷放大模型152 不可能完全的测试1、不可能测试程序对所有可能输入的相应2、不可能测试到程序每一条可能的执行路径3、无法找出所有的设计错误4、不能采用逻辑来证明程序的正确性153 增量测试，由小到大由小到大：指的是软件测试的粒度。通常把单元测试作为软件测试的最小粒度。 系统测试 单元测试集成测试 测试时间可用资源 测试范围图1-6 测试资源关系图154 避免测试自己的程序避免程序员测试自己的代码的主要原因归纳如下：（1）程序员轻易不会承认自己写的程序有错误。（2）程序员的测试思路有局限性，在做测试时很容易受到编程思路的影响。（3）多数程序员没有严格正规的职业训练，缺乏专业测试人员的意识。（4）程序员没有养成错误跟踪和回归测试的习惯。155 设计周密的测试用例软件测试的本质就是针对要测试的内容确定一组测试用例。测试用例至少应包括如下几个基本信息：（1）在执行测试用例之前，应满足的前提条件。（2）输入（合理的、不合理的）。（3）预期输出（包括后果和实际输出）。下图显示了一个典型的测试用例所应该具有的基本信息测试用例ID：目的：前提：输入：预期输出：后果：执行历史日期： 结果： 版本： 执行人：图1-7 典型的测试用例信息156 注意错误集中的现象有经验的测试人员会发现，在做软件测试的过程中，常发生软件缺陷“扎堆”的现象，因此当我们在某一部分发现了很多错误时，应该进一步仔细测试是否还包含了更多的软件缺陷。 软件缺陷“扎堆”现象的常见形式有：（1）对话框的某个控件功能不起作用，可能其他控件的功能也不起作用。（2）某个文本框不能正确显示双字节字符，则其他文本框也可能不支持双字节字符。（3）联机帮助某段文字的翻译包含了很多错误，与其相临的上下段的文字可能也包含很多的语言质量问题。（4）安装文件某个对话框的“上一步”或“下一步”按纽被截断，则这2个按扭在其他对话框中也被截断。157 确认BUG的有效性测试过程的不规范和对设计理解的歧义都是无效BUG的主要来源。除此之外，无效BUG还可能由于工具或方法使用错误，无效的运行环境以及人为因素或者其他原因造成。工具或方法使用错误13%其他12%人为因素9%无效的运行环境11%对设计的歧义29%测试过程的凌乱26%图1-8 无效BUG来源构成图158 合理安排测试计划良好的开始是成功的一半。合理的测试计划有助于测试工作顺利有序的进行，因此要求在对软件进行测试之前所做的测试计划中应该结合多种针对性强的测试方法，列出所有可使用资源，建立一个正确的测试目标，本着严谨、准确的原则，周到细致的做好测试前期的准备工作，避免测试的随意性。尤其是要尽量科学合理的安排测试时间，并留出一定的动机时间，防止意外情况的发生，以免出现测试时间不够用，甚至使很多测试工作不能正常进行的情况，尽量降低测试风险。159 回归测试错误关联是一种常见的现象，是指某个错误因为其他错误而出现或消失。此时，若想关闭某个错误必须先关闭它的父类错误。这些错误之间存在单纯的依赖或者复杂的多重依赖关系，如图1-9所示：AAACBCBBDFE（a）单纯依赖 （b）多重依赖 （c）复合依赖 图1-9 错误依赖关系1510 测试结果的统计和分析测试人员常常会发现，在输出的测试结果中存在着大量正确的以及错误的输出信息。因此，只有对这些输出信息进行深入的统计、分析和比较，才能够正确的鉴别测试后输出的数据，给出清晰的错误原因分析报告。当输出的信息很庞大时，就需要借助与专业的测试工具。1511 及时更新测试导致测试失败的原因很多，大致可归纳为如下几点：（1）测试团队管理者失职。（2）测试团队中沟通不好。（3）测试团队和项目团队沟通不良。（4）测试过程中，执行角色无准确定义。（5）测试团队缺乏良好的培训。在测试过程中，变更管理不善也容易造成测试过程的混乱，从而导致测试失败，尤其是对于中小型软件企业来说出现这种情况的可能性更多一些。在一些大型的软件公司可以通过定义严格的测试流程并使用成熟的测试变更管理工具等方法来避免类似情况的发生。因为为了避免因各种因素导致测试失败的情况发生，唯一的解决办法就是要即使更新测试。16软件测试工作流程结项总结阶段验收测试阶段立项阶段需求阶段设计阶段编码和单元测试阶段集成测试阶段系统测试阶段图1-10 软件测试工作总体流程图1、 需求阶段需求工作培训总体测试计划编写需求：业务、用户、功能需求评审系统测试方案需求规格说明书需求变更需求跟踪矩阵需求变更记录需求报警需求报警信号 进入下一阶段图1-11 需求阶段测试活动流程图2、 设计和编码阶段测试工作流程上一阶段 需求相关文档集成测试方案概要设计自动测试方案评审抽象出验证标准详细设计单元测试方案编码以模块为单位，不断循环 测试抽检单元测试进入下一阶段单元测试总结报告图1-12 设计和编码阶段测试流程图3、 集成测试、系统测试和验收测试阶段上一阶段集成测试方案集成测试系统测试申请测试部评估自动测试方案产品化工作系统测试系统测试方案产品化工作报告系统测试综合报告验收测试质量合格证书测试工作总结结图1-13 集成测试、系统测试和验收测试阶段流程图17软件测试中的误区误区1：调试和测试是一样的事实上，在软件开发的过程中调试和测试是2个不同的过程，分别由程序开发人员和测试人员来完成。第一， 调试的过程是随机的不可重复的；而测试的过程是有计划的、可以重复的过程。第二， 调试的目的是为了隔离和确认问题的所在，并且加以解决，使得程序能够正常运行；而测试的目的是为了找出与软件实现定义的规格和标准不符合的问题，保证软件能够满足用户需求。 二者的相同之处：最终的目的都是为了提高软件质量。误区2：软件测试在软件开发过程中并不重要、误区3：在软件开发结束之后进行测试误区4：过分依赖Beta测试Beta测试是从用户角度进行的测试，是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。它是在开发者无法控制的环境下进行的软件现场应用。一般有2种途径：公共Beta测试和私有Beta测试。公共Beta测试不一定能完全替代实验室内的系统测试，原因如下：（1）Beta测试人员不是专业的测试人员，很难发现一些深层次的问题，更多的是停留在使用性方面的问题上；（2）