目录
软件测试专栏入口：
https://blog.csdn.net/m0_73804764/category_12704003.html
欢迎各位关注订阅，您的一键三连是对我最大的肯定！！！
1.1软件测试的生命周期
软件测试是软件开发的一个阶段，然而测试阶段本身又可以划分成不同的阶段，这就构成了软件测试的生命周期。
根据实践经验的总结，我们仿照软件开发的生命周期模型，给出软件测试的生命周期模型，如图2.1所示。
1．计划阶段
在此阶段，通过对系统的整体分析，提出针对性的策略和规范，同时对系统输入空间进行合理的划分，据此来写出足够的、具体的测试用例。
计划阶段的主要任务包括安排进度、分配资源、人员及确定测试的起始点和结束点等。
图2.2给出了最佳的测试结束点，在该点的左侧，虽然测试成本很低，但还有很多错误没有被发现，不能结束测试；而在最佳测试结束点的右侧，虽然还会发现更多的软件错误，但是测试成本会大大提高，测试的代价太高，除非系统有着特殊的要求，否则就可以结束测试了。
所以，我们需要对测试进行合理的计划安排，把测试作为一个项目来进行，要做到在有限的时间内，完成所设计的测试工作，并且达到要求的程序结构覆盖或需求覆盖。
2．设计阶段
测试的设计包括测试过程的设计和测试用例的设计。
测试过程设计是指对给定的系统如何展开测试、展开哪些测试。
测试过程的设计主要考虑测试内容和测试顺序。
（1）测试内容：针对系统的要求，给出将如何展开测试。
（2）测试顺序：软件测试的一般顺序为，首先进行功能性测试，然后进行性能测试（包括压力测试、负载测试等），符合要求后进行可靠性测试，最后进行安全性测试等。
软件测试的任务有两个方面：
一方面是尽可能多地发现系统中的Bug；
另一方面是评估系统的性能，我们设计的测试输入数据这两方面都要满足。
测试用例在软件测试中是使用最多的名词术语，也就是说，测试用例设计包含两个部分，首先要给出针对系统要进行怎样的输入；另外还要给出针对这样的输入，系统会产生怎样的反应，也就是预期结果。
由于被测软件系统的输入要求不同，所以测试用例又可以分为以下几种。
（1）纯数据型测试用例。
（2）文件型测试用例。
（3）操作序列型测试用例。
（4）程序型测试用例。
3．开发阶段
由于系统的规模庞大，测试用例的多样化，在执行时要考虑效率问题，所以需要开发必要的工具，以便在测试用例的选择、修订、完善和执行上尽可能采用自动化的手段。
开发阶段主要包括准备测试脚本、测试数据自动生成、测试流程自动化等工作。
4．执行阶段
这一阶段的任务就是执行测试用例，有手动执行和自动执行。
5．评估阶段
这是测试的最后一个阶段，也是最重要的阶段，没有评估阶段就不能对被测系统给出正确的评价，测试也是不完整的。
这一阶段的任务是对测试结果进行评估和对发现的错误数进行统计。
测试结果评估主要依靠信息比较，也就是将测试结果与期望输出进行比较，通过各种量化方法，对测试的有效性及结果的可信性提供量化的依据。对于发现的错误数，可以进行多方位的统计，包括：错误数与时间的函数关系图（见图2.3）；错误数与功能点的函数关系（见图2.4）；错误数与开发人员的关系等。
1.2测试步骤
软件测试工作也可从这一螺旋线上体现出来。
在螺旋线的核心点针对每个单元的源代码进行单元测试。
在各单元测试完成以后，沿螺旋线向外前进，开始针对软件整体构造和设计的集成测试。
然后是检验软件需求能否得到满足的确认测试，最后，来到螺旋线的最外层，把软件和系统的其他部分协调起来，当作一个整体，完成系统测试。这样，沿着螺旋线，从内向外，逐步扩展了测试的范围。
以上用螺旋线表明的测试过程按4个步骤进行，即单元测试、集成测试、确认测试和系统测试。图2.6所示为测试的4个步骤。
2.2.1 单元测试
单元（unit）是程序的最小组成单位，它具有以下的特征。
（1）通常可分配给某个程序人员开发，在单元之间或与外界除去有技术接口（如相互调用）、引用数据库以外，总会有操作的界面需要协调。
（2）单元接受数据输入后，经过加工，得到一些结果，这时可能给出输出数据，也可能仅仅发生一些状态的改变。但如果输入、加工和输出三者缺少任何一个，这个程序单元都不是完整的。（3）原则上说，每个程序单元都应有正规的规格说明，使之对其输入、加工和输出的关系做出明确的描述。
模块应该具有以下的基本属性：
名字； 明确规定了的功能； 内部使用的数据，或称局部数据； 与其他模块或与外界存在的数据联系； 实现其特定功能的算法； 可被其上层模块调用，在其工作过程中也可调用其下属模块协同工作。
单元测试是要检验程序最小单位有无错误，它是在编码完成后，首先要施行的测试工作。
通常由编码人员自己来完成，因而有人把编码与单元测试考虑成一个开发阶段。
单元测试大多从程序的内部结构出发设计测试用例，即多采用白盒测试方法。多个程序单元可以并行地独立开展测试工作。
1．单元测试要解决的问题
单元测试是要针对每个模块的程序，解决以下5个方面的问题（参见图2.7）。 模块接口—对被测的模块，信息能否正常无误地流入和流出。
局部数据结构—在模块工作过程中，其内部的数据能否保持其完整性，包括内部数据的内容、形式及相互关系不发生错误。 边界条件—在为限制数据加工而设置的边界处，模块是否能够正常工作。 覆盖条件—模块的运行能否做到满足特定的逻辑覆盖。 出错处理—模块工作中发生了错误，其中的出错处理设施是否有效。
2．单元测试的步骤
单元测试常常被当作代码编写的附属步骤，它是在完成了程序编写，经过了复查，确认没有语法错误以后，针对每个程序模块单独进行的测试工作。
图2.8所示为一个被测模块进行单元测试时的环境状况，其中，设置了一个驱动模块和3个桩模块。 驱动模块在单元测试中接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果。
2.2.2 集成测试
在每个模块完成单元测试以后，需要按照设计时作出的结构图把它们连接起来，进行集成测试（integrated testing）。
实践表明，一些模块能够单独地工作，并不能保证连接起来也能正常工作。
程序在某些局部上反映不出的问题，在全局上很可能暴露出来，影响功能的发挥。
怎样合理地组织集成测试？这里提供两种不同的方法，即非增式测试和增式测试。
增式测试的做法与非增式测试有所不同。
它的集成是逐步实现的，集成测试也是逐步完成的。也可以说它把单元测试与集成测试结合起来进行。增式集成测试可按不同的次序实施，因而可以有两种： （1）自顶向下增式测试。 （2）自底向上增式测试。
2.2.3 确认测试
集成测试完成以后，分散开发的模块被连接起来，构成完整的程序。其中各模块之间接口存在的种种问题都已消除。 于是测试工作进入最后阶段—确认测试（validation testing）。 （1）确认测试准则。 （2）配置评审。 
2.2.4 系统测试
1．恢复测试
恢复测试（recovery test）是要采取各种人工干预方式使软件出错，而不能正常工作，进而检验系统的恢复能力。
2．安全测试
安全测试（security test）的目的在于验证安装在系统内的保护机构确实能够对系统进行保护，使之不受各种非常的干扰。
3．强度测试 （压力测试）
检验系统的能力最高实际限度。进行强度测试（stress test）时，让系统的运行处于资源的异常数量、异常频率和异常批量的条件下。
4．容量测试
容量测试（capacity test）是要检验系统的处理能力最高能达到什么程度，在使系统的全部资源达到“满负荷”的情形下，测试系统的承受能力。
5．性能测试
性能测试（performance test）检验安装在系统内的软件运行性能。这种测试常常与强度测试、容量测试结合起来进行。
6．α测试和β测试
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的主要是评价软件产品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持），尤其注重产品的界面和特色。β测试是由软件的多个用户在实际使用环境下进行的测试。
7．安装测试
安装测试（installation test）的目的不是找软件错误，而是找安装错误。在安装软件系统时，会有多种选择。安装测试是在系统安装之后进行测试.
8．可使用性测试
可使用性测试（usability test）主要从使用的规范性、合理性和方便性等角度对软件系统进行检查，以发现人为因素或使用上的问题。
1.3静态方法与动态方法
静态方法的主要特征是不利用计算机运行被测试的程序，而是采用其他手段达到检测的目的，注意与人工测试的根本区别。
静态分析是对被测程序进行特性分析的一些方法的总称。这些方法本身各有自己的目标和步骤。
1.4黑盒测试与白盒测试
1.4.1 黑盒测试
黑盒测试与白盒测试是很广泛使用的两类测试方法。
黑盒测试（Black-box Testing）又称功能测试、数据驱动测试或基于规格说明的测试（Specification-based Testing）
用这种方法进行测试时，被测程序被当作打不开的黑盒，因而无法了解其内部构造。
在完全不考虑程序内部结构和内部特性的情况下，测试者只知道该程序输入和输出之间的关系，或是程序的功能（见图2.13），他必须依靠能够反映这一关系和程序功能的需求规格说明书考虑确定测试用例和推断测试结果的正确性。即所依据的只能是程序的外部特性。因此，黑盒测试是从用户观点出发的测试。
1.4.2 白盒测试
白盒测试（White-boxTesting）又称结构测试、逻辑驱动测试或基于程序的测试（Program-based Testing）。采用这一测试方法，测试者可以看到被测的源程序，他可用以分析程序的内部构造，并且根据其内部构造设计测试用例。这时测试者可以完全不顾程序的功能。
1.4.3 黑盒测试与白盒测试的比较
表2.1所示为黑盒测试与白盒测试两类方法的对比。
图2.14所示为它们各自的能力范围、它们的互补关系以及各自的不足。
1.5 回归测试方法
回归测试可以应用于软件测试的各个阶段，用来验证错误修改情况，这称为改错性回归测试；同时在软件的增量式开发构件复用过程中，通过重新测试已有的测试用例和设计新的测试用例，来测试改动（增加或删除）的程序，这称为增量性回归测试。实践表明，回归测试在发现错误中起着非常重要的作用。
Rothermel和Harrold在1996年提出了对安全缩减测试用例库的评价标准。
（1）包含性（Inclusiveness）：缩减的测试用例库所揭示的回归错误数与可能显示的回归错误数的百分比。
（2）精度（Precision）：缩减的测试用例库所忽略的不能揭示的回归错误数与系统存在的不能揭示的回归错误数的百分比
（3）效率（Efficiency）：识别一个缩减的测试用例库的成本。
（4）普遍性（Generality）：选择的策略的应用范围。
1.6人工测试与自动测试
1.6.1人工测试技术概述
人工测试是不依赖于计算机的测试技术。人工走查（walkthrough）与审查会(inspection)的差别主要在于侧重点和目标有所不同。人工走查通常被当作开发人员在开发过程中使用的技术（尽管实际上不只是开发者本人参加），其目的在于提高编码的质量。
审查会则常被当作一种管理机制，经过审查不仅可以提高各阶段软件产品（不仅是编码）的质量，而且还可以收集到一些有关该软件产品质量的数据。项目管理人员可借以合理和定量地做出决策。因此，软件开发过程中每个阶段的审查都必须十分正规地、严格地加以定义，并且根据规格说明实施。
1.6.2软件审查
软件审查工作大致要经历以下几个步骤： 制定计划； 预审； 准备； 审查会； 返工； 终审。
1.6.3软件审查的作用
1．软件审查所得数据的使用
任何一个软件审查都将取得一些数据，这些数据如图2.15所示，它真实地反映了开发过程中出现的各种问题。充分利用这些数据指导和改进开发工作，将是十分有益的。图2.16所示为处在两个开发阶段之间的审查，其所获数据有3方面用途，即反馈、前馈和馈入。
2．作为软件开发进程控制的审查
为了使软件审查成为软件开发进程的控制手段，就要在开发过程的若干控制点实施前面介绍过的阶段审查。图2.17所示为安排有阶段审查的软件开发过程。
图中涉及的开发阶段包括需求分析、概要设计、详细设计、编码、制定测试计划以及设计测试用例。其中的每个阶段审查都应规定它的进入条件、出口条件、推荐的参审人员、查出问题分类以及查找问题策略。
正如图2.15中所给出的数据，阶段审查所发现的问题主要有3种表现形式，即 遗漏—在规格说明或标准中指明应该有的内容，送审资料中丢掉了。 多余—超出规格说明和标准，多给出的信息。 错误—应该有，也的确有，但内容有误的信息。
图2.15中对审查中发现的问题归纳成13类，即接口、数据、逻辑、输入和输出、功能、性能、人为因素、标准、文档、语法、测试环境、测试覆盖和其他。下面结合某一项目概要设计的审查，举例说明其分类方法。
图2.18所示为这一分类的实例，而其项目概要设计说明则在图2.19中给出。
1.6.4自动测试
自动测试与手工测试消耗的工作量的比率如图2.20所示。
从长远的角度来看，自动测试不仅节省人力资源，而且自动测试还有如下好处。
（1）可对系统的新版本自动地运行已有的测试数据（回归测试）。
（2）在系统调优阶段，为了比较算法中参数的各种取值效果，需要反复运行同样的测试数据，以找到最优值，自动测试就可以快速地得到结果。这种测试主要针对系统的性能。
（3）可以执行一些手工测试困难或不可能做的测试。
（4）更好地利用资源。
（5）测试具有一致性和可重复性。
自动测试的过程如图2.21所示，当我们选择了一个测试案例需要进行自动化测试时，就可以分成并行的工作，一方面着手准备测试数据，另一方面确定测试的执行步骤，设计测试脚本，接下来设置好自动运行的测试环境，使得测试脚本可以不断重复地运行，在结束之前，还要清除测试环境，如生成的临时数据、占用的临时变量、存储的临时文件等，最后总结测试结果。
自动测试主要依靠编写测试脚本或使用测试工具来实现，在测试的不同阶段可以完成不同的测试任务，主要能够完成以下功能。
（1）测试数据自动生成（test data generation）。
（2）基于需求的测试设计 （requirements-based test design）。
（3）捕捉/回放（capture/playback）。
（4）覆盖分析（coverage analysis）。
2111
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
