1、第第1.2章章 软件测试基本知识软件测试基本知识 n 测试发展历程n 测试的几种观点n 软件测试目的与原则 n 软件测试分类n 软件测试模型n 测试用例 测试发展历程 早在50年代，英国著名的计算机科学家图灵就给出了程序测试的原始定义。他认为，测试是程序正确性证明的一种极端实验形式。早期测试主要针对机器语言和汇编语言，给出特定的测试用例，运行被测程序，将所得结果与预期结果进行比较，从而判断程序的正确性。缺点：测试方法和理论研究缓慢。除去非常关键的程序系统外，一般程序的测试大都是不完备的。在20世纪60年代计算机发展早期，软件测试含义比较窄，等同于“调试”，目的是纠正软件的故障，常常由软件开发人
2、员自己进行。对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。直到70年代以后，软件测试开始重视 FPBrooks总结了开发IBM OS360操作系统中的经验，在著名的神秘的人月一书中阐明了软件测试在研制大系统中的重要意义。1975年，Goodenough首次提出了软件测试理论，从而把软件测试这一实践性很强的学科提高到理论的高度。WCHetzel整理出版了“Program Test Methods“一书，纵览了测试方法以至各种自动测试工具，这是软件测试的第一本著作。1982年，美国北卡来纳大学召开了首次软件测试技术会议，这次会议成为软件测试技术发展的一个重要的里
3、程碑。J.CHuang提出了程序插装的概念 WEHowden对路径测试进行了深入的分析 LA.Clarke等人提出了符号测试方法 R.A.Demillo提出了基于程序变异的测试方法 LOsterweit等人首先引入了数据流测试方法 L White等提出了新的测试策略域测试策略 DeMillo91提出了一种基于故障的测试产生方法 1996年，测试能力成熟度TMM、测试支持度TSM等一系软件测试相关理论提出。到了2002年，Rick和Stefan在系统的软件测试一书中对软件测试做了进一步描述：测试是为了度量和提高软件的质量，对软件进行工程设计、实施和维护的整个生命周期过程。近20年来，随着计算机和
4、软件技术飞速发展，软件测试技术的研究也取得了很大的突破。许多测试模型（如V模型等）产生，自动化测试涌现了大量的软件测试工具，如功能测试工具、Web测试工具、性能测试工具、测试管理工具、代码测试工具等。以软件测试服务为主导的软件测试产业正在兴起。测试的几种观点 n软件测试的广义论与狭义论n软件测试的辩证论 n软件测试的风险论 n软件测试的经济学观点 n软件测试的标准论 软件测试的广义论与狭义论 传统瀑布模型认为测试是指在代码完成后、处于运行维护阶段之前，通过运行程序来发现程序代码或软件系统中错误。为了更早地发现问题，将测试延伸到需求评审、设计审查活动中去，将“软件质量保证”的部分活动归为测试活动
5、。软件生命周期每一阶段中都应包含测试，用于检验本阶段的成果是否接近预期的目标，尽可能早的发现错误并加以修正，将软件测试和质量保证合并起来的软件测试，被认为是一种软件测试的广义概念。软件测试的辩证论 验证软件是验证软件是“工作的”，是指软件的功能是按照预先的设计执行的，以正向思维，针对软件系统的所有功能点，逐个验证其正确性。其代表人物是软件测试领域的先驱Dr.Bill Hetzel（The Complete Guide to Software Testing)。软件是“不工作的”，以反向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的输入以及系统的弱点，试图破坏系统、
6、摧毁系统，目标就是发现系统中各种各样的问题。其代表人物是Glenford J.Myers。（The Art of Software Testing）强调一个成功的测试必须是发现Bug的测试，不然就没有价值，认为软件测试：“就是以发现错误为目的而运行程序的过程。”软件测试的风险论 软件测试的风险论认为测试是对软件系统中潜在的各种风险进行评估的活动。对应这种观点，产生基于风险的测试策略。Pareto原则（也叫80/20原则）软件测试的经济学观点 “一个好的测试用例是在于它能发现至今未发现的错误”，体现了软件测试的经济学观点。这是由于在需求阶段修正一个错误的代价是1，而在设计阶段就是它的36倍，在编
7、程阶段是它的10倍，在内部测试阶段是它的2040倍，在外部测试阶段是它的3070倍，而到了产品发布出去时，这个数字就是 40 1000倍。修正错误的代价不是简单地随着时间线性增长，而几乎是呈指数级增长的。因此，应该尽快尽早地发现缺陷。软件测试的标准论 验证（Verification）是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。有效性确认（Validation）是确认所开发的软件是否满足用户真正需求的活动。软件测试目的与原则 Grenford J.Myers曾对软件测试的目的提出过以下观点:n测试是为了证明程序有错，而不是证明程序无错误；n一个好的测试用例是在于它能发现至今未发
8、现的错误；n一个成功的测试是发现了至今未发现的错误的测试。n应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。n 严防寄生虫现象 n严防杀虫剂现象 n并非所有的软件缺陷都能修复 n难以说清的软件缺陷 n需求规格说明书不断变化 n测试用例的设计 n软件测试充分性准则 软件测试分类单元测试单元测试集成测试集成测试确认测试确认测试验收测试验收测试按测试阶段划按测试阶段划分分程序划分程序划分系统测试系统测试软件测试软件测试按是否运行按是否运行程序划分程序划分按是否查看源按是否查看源代码划分代码划分静态测试静态测试动态测试动态测试黑盒测试黑盒测试其他其他回归测试回归测试性能测试性能测试随机测试
9、随机测试功能测试功能测试压力测试压力测试可靠性测试可靠性测试安全性测试安全性测试可用性测试可用性测试白盒测试白盒测试按照测试阶段划分 n单元测试n集成测试n确认测试n系统测试n验收测试按照执行主体划分 na 测试n 测试n第三方测试。按照执行状态划分 n动态测试n静态测试按照测试技术划分 n黑盒测试n白盒测试n灰盒测试软件测试模型 软件测试模型是软件测试工作的框架，描述了软件测试过程所包含的主要活动，这些活动之间的相互关系等。nV模型nW模型nH模型nX模型n前置模型V模型V模型反映了测试活动与分析和设计的关系，明确标明了测试过程中存在的不同级别，并清楚描述测试的各个阶段和开发过程的各个阶段之
10、间的对应关系。V模型左侧是开发阶段，右侧是测试阶段。开发阶段先从定义软件需求开始，然后把需求转换为概要设计和详细设计，最后形成程序代码。测试阶段是在代码编写完成以后，先作单元测试开始，然后是集成测试、系统测试和验收测试。V模型具有如下特点：（1）V模型是最具有代表意义测试模型。（2）V模型是软件开发瀑布模型的变种，反映了测试活动与分析和设计的关系。（3）从左到右，描述了基本的开发过程和测试行为，标明测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。V模型具有如下特点：（4）箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试
11、过程的各个阶段。（5）V模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后的一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段的隐藏的问题一直到后期的验收测试才被发现。W模型 相对于V模型而言，W模型增加了软件各开发阶段中应同步进行的验证和确认（V&V）活动。W模型由两个V字型模型组成，分别代表测试与开发过程，测试伴随着整个软件开发周期，测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发同步进行W模型具有如下特点：（1）在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型。（2）开
12、发是“V”，测试也是与此相重叠的“V”。W模型具有如下特点：（3）W模型体现了“尽早地和不断地进行软件测试”的原则。（4）W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行，测试和开发活动保持着一种线性的前后关系，上一阶段结束，才开始下一个阶段工作，因此，W模型无法支持迭代开发模型。H模型 V模型和W模型都认为软件开发是需求、设计、编码等一系列串行的活动，而事实上，这些活动在大部分时间内可以交叉，因此，相应的测试也不存在严格的次序关系，单元测试、集成测试、系统测试之间具有反复迭代。正因为V模型和W模型存在这样的问题，H模型将测试活动完全独立出来，使得测试准备活动和测试执行活动清晰
13、地体现出来。H模型揭示了软件测试作为一个独立的流程贯穿于软件整个生命周期，与其他流程并发地进行，并指出软件测试要尽早准备，尽早执行。不同的测试活动可以按照某个次序先后进行，也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展。因此，H模型具有如下意义：（1）测试准备与测试执行分离，有利于资源调配，降低成本，提高效率。（2）充分体现测试过程（不是技术）的复杂性。X模型 X模型的左边描述的是针对单独程序片段所进行的编码和测试，通过频繁的交接，集成最终合成为可执行的程序。X模型右上方定位了已通过集成测试的成品进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表
14、示变更可以在各个部分发生。X模型右下方定位了探索性测试。这是不进行事先计划的特殊类型的测试，往往是在测试计划之外发现软件错误。前置模型n开发和测试相结合n对每一个交付内容进行测试 n让验收测试和技术测试保持相互独立n反复交替的开发和测试n引入新的测试理念测试用例一个三角形程序，该程序完成：输入三个整数a、b和c，程序判断由这三条边构成的三角形类型是：等边三角形、等腰三角形还是一般三角形，并打印出相应的信息。1是否设计了一种测试输入表示合法的一般三角形?注意，像（1，2，3）和（2，3，9）这样的测试输入不应该回答“是”，为什么？2是否设计了一种测试输入表示合法的等边三角形?3是否设计了一种测试
15、输入表示合法的等腰三角形?像(4，4，8)这样的测试输入不应该回答“是”。4.是否至少设计了三种测试输入表示合法等腰三角形，由此检查了两条边相等的所有三种排列方案？像（3，3，4），（4，3，3）和（3，4，3）。5是否设计了这样的测试输入，其中三角形的一条边长为0？6是否设计了一种测试输入，其中三个整数都大于0，而其中的两数之和等于第三数?注意，如果把（2，3，5）当成一个一般三角形，则表明程序中有故障。7是否至少设计了三种第6类那样的测试输入，检查一条边边长等于另外两边边长之和的所有三种排列方式？如（2，3，5），（5，3，2）和（3，5，2）。8是否设计了一种测试输入，表示三个整数都大于
16、0，而其中某两个数的和小于第三个数?注意，如果把（2，3，9）当成一个一般三角形，则表明程序中有故障。9是否至少设计了三种第8类那样的测试输入，检查了所有三种排列的方案？如（2，3，9），（2，9，3）和（9，2，3）。10是否设计了一种测试输入表示三条边边长都为0？11是否设计了测试输入使得其中三角形的一条边长为负数?12是否至少设计了测试输入使得其中三角形的边长不是整数?13是否至少设计了一种测试输入，其中三角形的边数个数不是3？14对于每一种测试输入，是否还给出了预期的输出?测试用例（Test Case）是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包
17、括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。测试用例的作用主要体现在以下几个方面n指导测试的实施n规划测试数据的准备n评估测试结果的度量基准n保证软件可维护性和可复用性n分析缺陷的标准 测试用例内容n测试阶段和用例关系 n测试用例设计准则n测试用例的设计步骤n 测试用例维护测试阶段和用例关系测 试 阶 段测 试 类 型执 行 人 员单元测试模块功能测试，包含部分接口测试、路径测试开发人员集成测试接口测试、路径测试，含部分功能测试开发人员，如果测试人员水平较高可
18、以由测试人员执行系统测试功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试测试人员验收测试对于实际项目基本同上，并包含文档测试；对于软件产品主要测试相关技术文档测试人员，可能包含用户测试用例设计准则n测试用例设计应注重有效性n测试用例设计必须注重经济性n测试用例设计应考虑多重性n测试用例设计应考虑完备性n测试用例的结果具有可判定性n测试用例应具有可再现性测试用例的设计步骤1制定测试用例的策略和思想，在测试计划中描述出来。2.设计测试用例的框架，也就是测试用例的结构3.细化结构，逐步设计出具体的测试用例4.通过测试用例的评审，不断优化测试用例测试用例维护（1）产品特性没变，只是根据漏掉的缺陷来完善测试用例。这时候，增加和修改测试用例均可，因为当前被修改的测试用例对相应的版本都有效，不会影响某个特定版本所拥有的测试用例。（2）原有产品特性发生变化，不是新功能特性，而是功能增强，这时候原有的测试用例只对先前版本有效，对当前新的版本无效。此时，绝不能修改测试用例，只能增加新的测试用例，不能影响原有的测试用例。测试用例维护（3）原有功能取消了，这时只要将与该功能对应的测试用例在新版本上置为空标志或“无效”状态，但不能删除这些测试用例，因为它们对先前某个版本还是有效的。（4）完全新增加的特性，需要增加新的测试用例。
