第二章软件测试基础知识

2.1  软件测试发展历程 

        软件测试伴随着软件的产生而产生。早期软件开发过程中， 软件规模小，复杂程度低，软件开发过程相当混乱无序，软件测试含义也比较窄，等同于“调试”。此时软件测试的目的是纠正软件的故障，常常由软件开发人员自己进行。对测试的投入极少，测试介入也晚，常常是等到形成代码、产品已经基本完成时才进行测试。

　　1957年，软件测试首次作为发现软件缺陷的活动，与调试区分开来。1972年，北卡罗来纳大学举行首届软件测试会议，John Good Enough和Susan Gerhart在IEEE上发表的《测试数据选择的原理》确定了软件测试是软件的一种研究方向。1979年，Glenford Myers在《软件测试艺术》一书中提出“ 测试是为发现错误而执行的一个程序或者系统的过程”。

 

        20世纪80年代早期，软件和IT行业进入了大发展，软件向大型化、高复杂度的方向发展，软件的质量越来越重要。一些软件测试的基础理论和实用技术开始形成，软件开发的方式也逐渐由混乱无序的开发过程 过渡到结构化的开发过程。以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征，软件测试性质和内容也随之发生变化，不再是一个单纯的发现错误的过程，而是具有软件质量评价的内容。1983年，Bill Hetzel在《软件测试完全指南》中指出，测试是以评价一个程序或者系统属性为目标的一种活动，是对软件质量的度量。IEEE给软件测试定义为“ 使用人工或自动手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。这个定义明确地指出，软件测试的目的是为了检验软件系统是否满足需求，软件测试不再是一个一次性的活动，也不只是开发后期的活动，而是与整个开发流程融为一体的。

 

        20世纪90年代，软件测试工具开始运用。1996年，测试支持度TSM、测试成熟度TMM等一系软件测试相关理论被提出。到了2002年，Rick和Stefan在《系统的软件测试》一书中对软件测试做了进一步描述：测试是为了度量和提高软件的质量，对软件进行工程设计、实施和维护的整个生命周期过程。

　　近20年来，随着计算机和软件技术的飞速发展，软件测试技术的研究也取得了很大的突破。许多测试模型(如V模型等)产生，单元测试、自动化测试等方面涌现了大量的软件测试工具。在软件测试工具方面，商业化的软件测试工具，如捕获/回放工具、Web测试工具、性能测试工具、测试管理工具、代码测试工具等大量涌现，一些开放源码社区中也出现了许多软件测试工具，这些工具得到了广泛应用且相当成熟和完善。

 

 

 

2.2  软件测试目的

       软件测试是指使用人工或者自动手段来运行或测试某个系统的过程，其 目的在于检验被测试系统是否满足规定的要求或弄清预期结果与实际结果之间的差别。

　　软件测试是帮助识别开发完成(中间或最终的版本)计算机软件(整体或部分)的正确度、完全度和质量的软件过程，是软件质量保证的重要子域。

 

　　Grenford J.Myers曾对软件测试的目的提出过以下观点:

　　     (1) 测试是为了证明程序有错，而不是证明程序无错误；

 　　    (2) 一个好的测试用例在于它能发现至今未发现的错误；

 　    　(3) 一个成功的测试是指发现了至今未发现的错误的测试。

 

        这种观点指出测试是 以查找错误为中心，而不是为了演示软件的正确功能。但是只从字面意思理解可能会产生误导，认为发现错误是软件测试的唯一目的，查找不出错误的测试就是没有价值的测试。

 

        软件测试的目的往往包含如下内容：

　　(1) 测试并不仅仅是为了找出错误，而且要通过分析错误产生的原因和错误的发生趋势，帮助项目管理者发现当前软件开发过程中的缺陷，以便及时改进。

　　(2) 测试分析帮助测试人员设计出有针对性的测试方法，以改善测试的效率和有效性。

　　(3) 没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。

 

 

2.3  软件测试原则

    软件测试应遵循以下基本原则：

　　(1) 应当把“ 尽早地和不断地进行软件测试”作为软件开发者的座右铭。由于软件的复杂性和抽象性，软件开发各个阶段工作的多样性，以及参加开发各种层次人员之间工作的配合关系等因素，使得开发的每个环节都可能产生错误。因此不应把软件测试仅仅看做是软件开发的一个独立阶段，而应当把它贯穿到软件开发的各个阶段中。坚持在软件开发的各个阶段进行技术评审，尽早发现和预防错误，把出现的错误克服在早期，杜绝某些隐患，提高软件质量。

       (2) 测试用例应由测试输入数据和与之对应的预期输出结果两部分组成。测试用例主要用来检验程序员编制的程序，不但需要测试输入数据，而且需要针对这些输入数据的预期输出结果。如果对测试输入数据没有得到预期的程序输出结果，那么就缺少了检验实测结果的基准，就有可能把一个似是而非的错误结果当成正确结果。

　　(3) 程序员应避免检查自己的程序。测试工作需要严谨的作风、客观的态度和冷静的情绪。心理学告诉我们，人们具有一种不愿否定自己工作的心理，而这一心理状态就成为测试自己程序的障碍。另外，程序员对软件规格说明理解错误而引入的错误则更难发现。因此由别人来测试程序员编写的程序，可能会更客观、更有效，并更容易取得成功。

　　(4) 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。合理的输入条件是指能验证程序正确的输入条件；而不合理的输入条件是指异常的、临界的、可能引起问题异变的输入条件。用不合理的输入条件测试程序时，往往比用合理的输入条件进行测试能发现更多的错误。

　　(5) 充分注意测试中的群集现象。经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目或检错率成正比。根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。　　在所测程序段中，若发现错误数目多，则残存错误数目也比较多。这种错误群集现象已为许多程序的测试实践所证实。例如IBM公司的OS/370操作系统中，大量的错误仅与该系统的4%的程序模块有关。因此，如果发现某一程序模块似乎比其它程序模块有更多的错误倾向时，则应当花费较多的时间和代价测试这个程序模块。

　　(6) 严格执行测试计划，排除测试的随意性。测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方式和过程，系统组装方式，跟踪规程，调试规程，回归测试的规定以及评价标准等。

　　(7) 应当对每一个测试结果做全面检查。有些错误的征兆在输出实测结果时已经明显地出现了，但是如果不仔细、全面地检查测试结果，就会使这些错误被遗漏掉。所以必须对预期的输出结果明确定义，对实测的结果仔细分析检查，抓住征候，暴露错误。

　　(8) 妥善保存测试计划、测试用例、出错统计和最终分析报告，为软件维护提供方便。

 

2.4  软件测试分类

2.4.1  按照开发阶段划分

      　　软件测试贯穿整个软件开发的始末，按照软件开发阶段划分，软件测试分为单元测试、集成测试、确认测试、系统测试、验收测试等。

 

2.4.2  按照执行主体划分

      　　按照测试实施组织划分，软件测试分为开发方测试、用户测试和第三方测试。

　　1．开发方测试

　　开发方测试通常也叫“验收测试”或“ α测试”。在软件开发环境中，开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。用户测试是指在用户的应用环境下，用户检测与核实软件实现是否符合自己预期的要求。

　　2． 用户测试

　　通常用户测试被称为 β测试，指把软件有计划地、免费地分发到目标市场，让用户大量使用、评价和检查软件。通常情况下，用户测试不是指用户的“验收测试”，而是指用户的使用性测试，由用户在应用过程中发现软件的缺陷与问题，并对使用质量进行评价。

　　3．第三方测试

　　第三方测试是指由第三方测试机构来进行的测试，也称 独立测试。第三方测试由在技术、管理和财务上与开发方和用户方都相对独立的组织进行，一般在模拟用户真实应用的环境下，进行软件的确认测试。

 

2.4.3  按照执行状态划分

1．静态测试

转存失败重新上传取消

　　静态测试是指计算机不真正运行被测试的程序，而是人工对程序和文档进行分析与检查，包括走查、符号执行、需求确认等。静态测试一方面利用计算机作为对被测程序进行特性分析的工具，与人工测试有着根本的区别；另一方面并不真正运行被测程序，与动态方法也不相同。因此，静态测试常称为“分析”，是对被测程序进行特性分析方法的总称。静态分析过程如图2.1所示。其中，针对代码的静态测试包括代码检查、静态结构分析、代码质量度量等。

　　1) 代码检查　　代码检查主要检查代码和设计的一致性，代码对文档标准的遵循及代码的可读性，代码的逻辑表达正确性，代码结构的合理性等方面。代码检查比动态测试更有效率，能快速找到30%～70%的逻辑设计错误和代码缺陷。

    　　代码检查一般在编译和动态测试之前进行，其实施方法很多，如走查(Walk through)、审查(Inspection)、评审(Review)等，如表2.1所示。

        　　(1) 走查。 　　(2) 审查。 　　(3) 评审。

　　2) 静态结构分析　　静态结构分析以图形的方式表现程序的内部结构，例如，函数调用关系图、函数内部控制流图等。其中，函数调用关系图描述程序中函数调用与被调用的关系，控制流图显示函数的逻辑结构。

 

2．动态测试

　　动态测试指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能的测试方法。这种方法由三部分组成：构造测试实例、执行程序和分析程序的输出结果。

 

2.4.4  按照测试技术划分

1．黑盒测试

　　黑盒测试也称功能测试或数据驱动测试。它是在已知产品所应具有的功能的前提下，通过测试来检测每个功能是否都能正常使用。在测试时，把程序看做一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息(如数据库或文件)的完整性。黑盒测试试图发现以下类型的错误：功能错误或遗漏、界面错误、数据结构或外部数据库访问错误、性能错误、初始化和终止错误等。

 

2．白盒测试

　　白盒测试又称结构测试或逻辑驱动测试。与黑盒测试正好相反，它是知道产品内部工作过程，检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求正确工作。白盒测试的主要方法有逻辑驱动、路径测试等，主要用于软件验证。

       白盒测试是基于源代码的测试，需要了解程序的构架、具体需求以及一些编写程序的技巧，能够检查一些程序规范、指针、变量、数组越界等问题。　　白盒测试容易发现以下类型的错误：变量没有声明、无效引用、数组越界、死循环、函数本身没有析构、参数类型不匹配、调用系统的函数没有考虑到系统的兼容性等。

 

3．灰盒测试

　　灰盒测试介于黑盒测试和白盒测试之间，主要用于测试各个组件之间的逻辑关系是否正确，相对白盒测试来说要求相对较低，对测试用例要求也相对较低，用于代码的逻辑测试、验证程序接收和处理参数。灰盒测试的重点在于测试程序的处理能力和健壮性，相对黑盒测试和白盒测试而言，投入的时间相对少，维护量也较小。　　软件测试方法与软件开发过程相关联。单元测试一般应用白盒测试方法，集成测试应用灰盒测试方法，系统测试和确认测试应用黑盒测试方法。　　黑盒测试和白盒测试比较如表2.2所示。

 

2.4.5  按照软件发布范围划分

 

1. 国际化测试

　　国际化测试的目的是测试软件的国际化支持能力，发现软件的国际化的潜在问题，保证软件在世界不同区域都能正常运行。以Windows应用软件为例，针对世界软件市场的语言优先级，需要首先应用德语和日语的操作系统。这两种语言代表最重要的区域市场，同时日语又作为东亚双字节字符的典型语言，在英文Windows操作系统上安装具体的语言支持文件进行区域设置。将日语作为系统默认区域设置进行测试，可验证ANSI(非Unicode)组件中的双字节字符集(DBCS)处理。将德语作为系统默认区域设置进行测试，可确保需要进行文本转换时能够正确处理ANSI和OEM代码页。

   　国际化测试使用每种可能的国际输入类型，针对任何区域性或区域设置检查产品的功能是否正常。软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语(可选)的混合字符，其中复杂脚本字符指阿拉伯语、希伯来语、泰语。国际化测试中发现的比较严重的软件错误包括软件在不同区域设置环境下的功能丢失或数据破坏。这些错误经常出现在字符编码转换和双字节字符的输入/输出过程中。

 

2. 本地化能力测试

　　本地化能力是指不需要重新设计或修改代码，将程序的用户界面翻译成任何目标语言的能力。本地化能力高的软件可以容易地实施本地化处理。本地化能力测试的目的是测试软件的本地化支持能力，尽早发现软件本地化时将会出现的潜在错误。本地化能力测试通过以后，表示产品已可用于本地化，才能进行软件的本地化过程和本地化测试。为了降低本地化能力测试的成本，提高测试效率，本地化能力测试通常在软件的伪本地化版本上进行。软件的伪本地化是指将软件中需要本地化的英文文本，使用其它本地化的文本替换，模拟本地化版本的过程。

 

3. 本地化测试

　　本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的对象是软件的本地化版本。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上分为基本功能测试、安装/卸载测试、当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量，包含软件、文档和联机帮助等部分。

　　本地化测试的错误主要包括软件用户界面错误，如布局错误(版式、大小和位置)，本地化有关的功能错误，翻译错误和双字节支持错误。软件的翻译质量包括翻译的准确性、完整性、一致性以及特定区域市场的文化、传统、习俗和政治的敏感内容。为了保证软件本地化测试的质量和成本，通常外包给当地语言为母语的本地化服务公司。

 

 

2.5  软件测试模型

2.5.1  V模型

      　　V模型作为最典型的测试模型，由Paul Rook在20世纪80年代后期提出，如图2.2所示。V模型反映了测试活动与分析和设计的关系，明确标明了测试过程中存在的不同级别，并清楚描述测试的各个阶段和开发过程的各个阶段之间的对应关系。V模型左侧是开发阶段，右侧是测试阶段。开发阶段先从定义软件需求开始，然后把需求转换为概要设计和详细设计，最后形成程序代码。测试阶段是在代码编写完成以后，先从单元测试开始，然后是集成测试、系统测试和验收测试。

转存失败重新上传取消

 

 

　　单元测试对应详细设计，也就是说，单元测试用例和详细设计文档一起实现；而集成测试对应于概要设计，其测试用例是根据概要设计中模块功能及接口等实现方法编写。依次类推，测试计划在软件需求完成后就开始进行，完成系统测试用例的设计等。　　V模型存在如下一些局限性：它仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段，主要针对程序进行寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。

 

2.5.2  W模型

      　　相对于V模型而言，W模型增加了软件各开发阶段中应同步进行的验证和确认(V&V)活动。如图2.3所示，W模型由两个V字型模型组成，分别代表测试与开发过程，明确表示出了测试与开发的并行关系。    

转存失败重新上传取消

　　    W模型强调，测试伴随着整个软件开发周期，测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发同步进行。W模型有利于尽早地发现问题，只要相应的开发活动完成，就可以开始测试。例如，需求分析完成后，测试就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，从而减少总体测试时间，加快项目进度。　　W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行，测试和开发活动保持着一种线性的前后关系，上一阶段结束，才开始下一个阶段工作，因此，W模型无法支持迭代开发模型。

 

2.5.3  H模型

      　　V模型和W模型都认为软件开发是需求、设计、编码等一系列串行的活动，而事实上，这些活动在大部分时间内可以交叉。因此，相应的测试也不存在严格的次序关系，单元测试、集成测试、系统测试之间具有反复迭代。正因为V模型和W模型存在这样的问题，H模型将测试活动完全独立出来，使得测试准备活动和测试执行活动清晰地体现出来。　　图2.4仅仅显示了整个测试生命周期中某个层次的“微循环”。H模型揭示了软件测试作为一个独立的流程贯穿于软件整个生命周期，与其它流程并发地进行，并指出软件测试要尽早准备，尽早执行。不同的测试活动可以按照某个次序先后进行，也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展。

 

转存失败重新上传取消

 

2.5.4  X模型

      　　由于V模型没能体现出测试设计、测试回溯的过程，因此出现了X测试模型。     　　如图2.5所示，X模型的左边描述的是针对单独程序片段所进行的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序。X模型右上方定位了已通过集成测试的成品进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。X模型右下方定位了探索性测试。这是不进行事先计划的特殊类型的测试，往往帮助有经验的测试人员在测试计划之外发现软件错误。

转存失败重新上传取消

2.5.5  前置模型

      　　前置模型将测试和开发紧密结合，具有如下的优点。

 　　(1) 开发和测试相结合。前置测试模型将开发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为，表示这些行为在项目周期中的价值。　　前置测试在开发阶段以“编码→测试→编码→测试”的方式进行。也就是说，程序片段编写完成后会进行测试。

　　(2) 对每一个交付内容进行测试。每一个交付的开发结果都必须通过一定的方式进行测试。源程序代码并不是唯一需要测试的内容。可行性报告、业务需求说明以及系统设计文档等也是被测试的对象。这同V模型中开发和测试的对应关系相一致，并且在其基础上有所扩展。

　　(3) 让验收测试和技术测试保持相互独立。验收测试应该独立于技术测试，这样可以提供双重的保险，以保证设计及程序编码能够符合最终用户的需求。验收测试既可以在实施阶段的第一步来执行，也可以在开发阶段的最后一步执行。

　　(4) 反复交替的开发和测试。项目开发中存在很多变更，例如需要重新访问前一阶段的内容，或者跟踪并纠正以前提交的内容，修复错误，增加新发现的功能等。开发和测试需要一起反复交替地执行。

　　(5) 引入新的测试理念。前置测试对软件测试进行优先级划分，用较低的成本及早发现错误，并且充分强调了测试对确保系统高质量的重要意义。

 

2.6  测试用例

2.6.1  测试用例的基本概念

　　测试用例作为测试工作的指导，是软件测试必须遵守的准则，是软件测试质量稳定的根本保障。测试用例(Test Case)目前没有经典的定义。简单地说，测试用例就是设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的执行结果。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略，内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

 　　测试用例是将软件测试的行为活动做了一个科学化的组织归纳，目的是将软件测试的行为转化成可管理的模式，同时测试用例也是将测试具体量化的方法之一。

 

　　测试用例的重要性体现在以下几方面。

 　　(1) 测试用例构成了设计和制定测试过程的基础。

 　　(2) 测试的“深度”与测试用例的数量成比例，这是由于每个测试用例反映不同的场景、条件或经由产品的事件流。

 　　(3) 测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。

 　　(4) 测试设计和开发的类型以及所需的资源主要受控于测试用例。

 　　(5) 测试用例通常根据它们所关联的测试类型或测试需求来分类，而且将随类型和需求进行相应的改变。

 

　　测试用例主要有如下几种分类。

　　(1) 功能测试用例：包含功能测试、健壮性测试和可靠性测试。

　　(2) 性能测试用例：包含性能测试、压力测试和强度测试。

　　(3) 集成测试用例：包含接口测试、健壮性测试和可靠性测试。

　　(4) 安全测试用例。

　　(5) 用户界面测试用例及少量功能测试用例。

 　   (6) 安装/反安装测试用例。

　　测试种类、阶段和用例的关系如表2.3所示。

转存失败重新上传取消

2.6.2  测试用例的编写

 　　编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。 　　测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果(含判断标准)、出口准则、注释等。以上内容涵盖了测试用例的基本元素：测试索引、测试环境、测试输入、测试操作、预期结果、评价标准。表2.4所示是一个典型的测试用例文档。

　　测试用例可根据基本事件、备选事件和异常事件设计相关的用例。设计基本事件的用例，应该参照用例规约(或设计规格说明书)，根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。

 　　设计备选事件和异常事件的用例，则要复杂许多。

 

 

2.6.3  测试用例的作用

 　　1．指导测试的实施 　　

        测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试，并将测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。

 　　根据测试用例的测试等级，集成测试应测试哪些用例，系统测试和回归测试又该测试哪些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。

 

　　2．规划测试数据的准备

 　　按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其像测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必要的。 除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

 

 　　3．编写测试脚本的“设计规格说明书”

 　　为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。

 

　　4．评估测试结果的度量基准

 　　完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例如：测试覆盖率是多少，测试合格率是多少，重要测试合格率是多少，等等。

 

 　　5．分析缺陷的标准

 　　通过收集缺陷，对比测试用例和缺陷数据库，分析确认是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量的目的。而已有相应测试用例，则反映实施测试或变更处理存在问题。

 

2.6.4  相关问题

　　1．测试用例的评审

 　　测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。

 

　　2．测试用例的修改更新

 　　测试用例在形成文档后还需要不断完善。主要来自三方面的缘故：第一，在测试过程中发现设计测试用例时考虑不周，需要完善；第二，在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成的；第三，软件自身新增功能以及软件版本的更新，测试用例也必须配套修改更新。 一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。如果软件的版本升级更新，则测试用例一般也应随之编制升级更新版本。

 

　　3．测试用例的管理软件

 　　运用测试用例还需配备测试用例管理软件。它的主要功能有三个：第一，能将测试用例文档的关键内容，如编号、名称等自动导入管理数据库，形成与测试用例文档完全对应的记录；第二，可供测试实施时及时输入测试情况；第三，最终实现自动生成测试结果文档，包含各测试度量值、测试覆盖表及测试通过或不通过的测试用例清单列表。

 

 

 

 

2.7  思考与习题

一、选择题

1. 软件测试按照测试技术划分为(  C   )。

　　A. 性能测试、负载测试、压力测试      

　　B. 恢复测试、安全测试、兼容测试

　　C.  A与B都是                        

  　 D. 单元测试、集成测试、验收测试

2. 软件测试的目的是(  C   )。

　　A. 避免软件开发中出现错误           

   　B. 发现软件开发中出现的错误

　　C. 尽可能发现并排除软件中潜藏的错误，提高软件的可靠性

　　D. 修改软件中出现的错误

3. 各个地方对软件测试定义不同，请你根据软件测试方面、理论方面、代码的角度测试填空。

代码方面分为：(  A  )、集成测试、系统测试、验收测试。

理论方面分为：(  C  )、动态测试、静态测试

测试方面分为：(  B  )、压力测试、回归测试、负载测试、恢复测试、安全性测试、兼容性测试、内存泄露测试、比较测试等。

　　A. 单元测试       　　　B. 黑盒测试       　　C. 白盒测试      　　　D. 负载测试　

 

二、判断题

　　(1)  Beta测试是验收测试的一种。(   √   )

　　(2) 尽量用公共过程或子程序去代替重复的代码段。(  √    )

　　(3) 测试是为了验证该软件是否已正确地实现了用户的要求。(   ×   )

　　(4) 对于连锁型分支结构，若有n个判定语句，则有2n条路径。(   ×   )

　　(5) 尽量采用复合的条件测试，以避免嵌套的分支结构。(   √   )

　　(6)  GOTO语句概念简单，使用方便，在某些情况下，保留GOTO语句反能使写出的程序更加简洁。(   √   )

　　(7) 发现错误多的程序模块，残留在模块中的错误也多。(   √   )

       (8)黑盒测试方法中最有效的是因果图法。(   ×   )

       (9)在做程序的单元测试时，桩(存根)模块比驱动模块容易编写。(   ×   )

       (10)程序效率的提高主要应通过选择高效的算法来实现。(   √   )

 

 

三、简答题

　　1. 软件测试的目的是什么？

答:软件测试的目的有:

①软件测试是为了发现错误而执行程序的过程。

②一个好的测试用例能够发现至今尚未发现的错误。

③一个成功的测试是发现了至今尚未发现的错误。

 

　　2. 软件测试中应注意哪些事项？

答:软件测试应注意以下事项:

1.应当把“尽早和不断地测试”作为开发者的座右铭。

2.程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。

3.设计测试用例时， 应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比 如网络异常中断、电源断电等情况。

4.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。

5.对测试错误结果一定要有一个确认的过程。- - 般有A 测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

6.制定 严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一一个高水平的测试。

7.回归测试的关联性一 定要引起充分的注意，修改-一个错误而引起更多错误出现的现象并不少见。

8.妥善保存- -切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。

 

　　3. 按执行主体划分，软件测试分哪几类？

答:哪找测试实施组织划分，软件测试分为a 测试，β 测试和第三方测试。

 

　　4.  V模型和W模型各自的优缺点是什么？

答: V模型:

    优点是:如此简单的模型适合工程量小、人力投入 也少的情况。而且项目的改动不大，风险不高的情况。

    缺点:在实际中能用上V 模型的项目很少。错误也发现得迟。采用V模型的而产生的风险费用很高

W模型:

    优点:能在前期发现需求错误，在测试过程中也有利于及时了解项目难度。适合做中型软件。

    缺点: W模型继承V模型而来，仍要求项目需求不能有大变动，否则前期准备很容易白费。也不适合 于大型的项目，大型项 目不能一-开始就有完整的需求，而且风险大而造成需求变动大。人力上也要求有专门测试的人员。

 

　　5. 测试用例是什么？

答:测试用例是指对一-项特定的软件产品进行测试任务的描述，体现在测试方案，方法，技术，策略等。测试用例的内容包括测试目标，测试环境，输入数据，测试步骤，预期结果，测试脚本等，并形成文档。

测试用例的属性:

    1.测试用例具有优先性。

    2.测试用例具有目标性。

    3.测试用例具有范围性。

    4.测试用例具有关联性。

    5.测试用例具有阶段性。

    6.测试用例具有状态性。

    7.测试用例具有代表性。

    8.测试用例具有时效性。