|
|
知识路径： > 系统开发和运行维护知识 > 系统实施知识 > 系统开发与测试 > 系统测试基础知识 >
|
|
相关知识点：13个
|
|
|
|
|
软件测试策略将软件测试用例的设计方法集成到一系列经过周密计划的步骤中去，从而使软件构造成功地完成。测试策略提供以下方面的路径图：描述将要进行的测试步骤，这些步骤计划和执行的时机，需要多少工作量、时间和资源。因此，任何测试策略都必须包含测试计划、测试用例设计、测试执行以及结果数据的收集和评估。
|
|
|
|
软件测试策略应该具有足够的灵活性，以便促进测试方法的定制。同时，它必须足够严格，以便在项目进行过程中对项目进行合理地策划和追踪管理。
|
|
|
|
有效的软件测试实际上分成单元测试、集成测试、确认测试和系统测试4步进行。
|
|
|
|
|
|
单元测试也称为模块测试，在模块编写完成且无编译错误后就可以进行。单元测试侧重于模块中的内部处理逻辑和数据结构。如果选用机器测试，一般用白盒测试法。这类测试可以对多个模块同时进行。单元测试主要检查模块的以下5个特征：
|
|
|
|
（1）模块接口。模块的接口保证了测试模块的数据流可以正确地流入、流出。在测试中应检查以下要点：
|
|
|
|
①测试模块的输入参数和形式参数在个数、属性、单位上是否一致。
|
|
|
|
②调用其他模块时，所给出的实际参数和被调用模块的形式参数在个数、属性、单位上是否一致。
|
|
|
|
③调用标准函数时，所用的参数在属性、数目和顺序上是否正确。
|
|
|
|
|
|
|
|
|
|
|
|
⑧在使用文件之前是否已经打开文件或使用文件之后是否已经关闭文件。
|
|
|
|
（2）局部数据结构。在单元测试中，局部数据结构出错是比较常见的错误，在测试时应重点考虑以下因素：
|
|
|
|
|
|
|
|
|
|
|
|
（3）重要的执行路径。在单元测试中，对路径的测试是最基本的任务。由于不能进行穷举测试，需要精心设计测试例子来发现是否有计算、比较或控制流等方面的错误。
|
|
|
|
①计算方面的错误。算术运算的优先次序不正确或理解错误；精度不够；运算对象的类型彼此不相容；算法错；表达式的符号表示不正确等。
|
|
|
|
②比较和控制流的错误。本应相等的量由于精度造成不相等；不同类型进行比较；逻辑运算符不正确或优先次序错误；循环终止不正确（如多循环一次或少循环一次）、死循环；不恰当地修改循环变量；当遇到分支循环时，出口错误等。
|
|
|
|
（4）出错处理。好的设计应该能预测到出错的条件并且有对出错处理的路径。虽然计算机可以显示出错信息的内容，但仍需要程序员对出错进行处理，保证其逻辑的正确性，以便于用户维护。
|
|
|
|
（5）边界条件。边界条件的测试是单元测试的最后工作，也是非常重要的工作。软件容易在边界出现错误。
|
|
|
|
由于模块不是独立运行的程序，各模块之间存在调用与被调用的关系。在对每个模块进行测试时，需要开发驱动和桩两种模块。其中，驱动模块相当于一个主程序，接收测试例子的数据，将这些数据送到测试模块，输出测试结果；桩模块也称为存根模块，桩模块用来代替测试模块中所调用的子模块，其内部可进行少量的数据处理，目的是检验入口、输出调用和返回的息。
|
|
|
|
提高模块的内聚度可以简化单元测试。如果每个模块只完成一种功能，对于具体模块来讲，所需的测试方案数据就会显著减少，而且更容易发现和预测模块中的错误。
|
|
|
|
对于面向对象软件，单元的概念发生了变化。封装导出了类的定义。每个类和类的实例（对象）包装有属性（数据）和处理这些数据的操作（函数或方法）。封装的类常是单元测试的重点，然而，类中包含的操作是最小的可测试单元。由于类中可以包含一些不同的操作，且特殊的操作可以作为不同的类的一部分存在，因此，面向对象软件的类测试是由封装在该类中的操作和类的状态行为驱动的。
|
|
|
|
|
|
集成测试就是把模块按系统设计说明书的要求组合起来进行测试。即使所有模块都通过了测试，但在集成之后，仍可能会出现问题：穿过模块的数据丢失；一个模块的功能对其他模块造成有害的影响；各个模块集成起来没有达到预期的功能；全局数据结构出现问题。另外，单个模块的误差可以接受，但模块组合后，可能会出现误差累积，最后到不能接受的程度，所以需要集成测试。
|
|
|
|
通常集成测试有两种方法：一种是分别测试各个模块，再把这些模块组合起来进行整体测试，即非增量式集成；另一种是把下一个要测试的模块组合到已测试好的模块中，测试完后再将下一个需要测试的模块组合起来进行测试，逐步把所有模块组合在一起，并完成测试，如自顶向下集成、自底向上集成，即增量式集成。非增量式集成可以对模块进行并行测试，能充分利用人力，并加快工程进度。但这种方法容易混乱，出现错误不容易查找和定位。增量式测试的范围逐步扩大，错误容易定位，而且已测试的模块可在新的条件下再测试，测试更彻底。
|
|
|
|
面向对象软件没有明显的层次控制结构，类的成分间的直接或间接相互作用，使得每次将一个操作集成到类中往往不可能。因此，面向对象系统的集成有两种不同的策略：一是基于线程的测试，集成响应系统的一个输入或事件所需的一组类，每个线程单独地集成和测试；另一种方法是基于使用的测试，通过测试很少使用服务类的那些类（称为独立类）开始构建系统，独立类测试完后，利用独立类测试下一层的类（称为依赖类）。继续依赖类的测试直到完成整个系统。
|
|
|
|
|
|
经过集成测试之后，软件就被集成起来，接口方面的问题已经解决，将进入软件测试的最后一个环节，即确认测试。确认测试的任务就是进一步检查软件的功能和性能是否与用户要求的一样。系统方案说明书描述了用户对软件的要求，所以是软件有效性验证的标准，也是确认测试的基础。
|
|
|
|
确认测试，首先要进行有效性测试以及软件配置审查，然后进行验收测试和安装测试，经过管理部门的认可和专家的鉴定后，软件即可交给用户使用。
|
|
|
|
（1）有效性测试：就是在模拟环境下，通过黑盒测试检验所开发的软件是否与需求规格说明书一致。在设计测试例子时，除了检测软件的功能和性能之外，还需要对软件的容错性、维护性等其他方面进行检测。测试人员可由开发商的内部人员组成，但最好是没有参加该项目的有经验的软件设计人员。在所有测试例子完成之后，若发现测试结果与预期的不符，这时要列出缺陷清单。在这个阶段才发现的严重错误，一般很难在预定的时间内纠正，需要与用户协商，寻找妥善解决问题的办法。
|
|
|
|
（2）软件配置审查：主要是检查软件（源程序、目标程序）和文档（包括面向开发和用户的文档）以及数据（程序内部的数据或程序外部的数据）是否齐全，分类是否有序。确保文档、资料的正确和完善，以便维护阶段使用。
|
|
|
|
（3）验收测试：是以用户为主的测试。软件开发人员和质量保证人员也应该参加。在验收测试之前，需要对用户进行培训，以便熟悉该系统。验收测试的测试例子由用户参与设计，主要验证软件的功能、性能、可移植性、兼容性和容错性等，测试时一般采用实际数据。多数软件开发者使用α测试与β测试的过程，其中α测试是最终用户在开发者的场所进行，而β测试是在最终用户场所执行。
|
|
|
|
|
|
系统测试是将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起，进行信息系统的各种集成测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方。系统测试是根据系统方案说明书来设计测试用例的，常见的系统测试主要有以下内容：
|
|
|
|
（1）恢复测试。监测系统的容错能力。检测方法是采用各种方法让系统出现故障，检验系统能否按照要求从故障中恢复过来，并在约定的时间内开始事务处理，而且不对系统造成任何伤害。如果系统的恢复是自动的（由系统自动完成），需要验证重新初始化、检查点和数据恢复等是否正确。如果恢复需要人工干预，就要对恢复的平均时间进行评估并判断它是否在允许的范围内。
|
|
|
|
（2）安全性测试。检测系统的安全机制、保密措施是否完善，主要是为了检验系统的防范能力。测试的方法是测试人员模拟非法入侵者，采用各种方法冲破防线。系统安全性设计准则是使非法入侵者所花费的代价比进入系统后所得到的好处要大，此时非法入侵已无利可图。
|
|
|
|
（3）压力测试。也称为强度测试，是对系统在异常情况下的承受能力的测试，是检查系统在极限状态下运行时，性能下降的幅度是否在允许的范围内。因此，压力测试要求系统在非正常数量、频率或容量的情况下运行。压力测试主要是为了发现在有效的输入数据中可能引起不稳定或不正确的数据组合。例如，运行使系统处理超过设计能力的最大允许值的测试例子；使系统传输超过设计最大能力的数据，包括内存的写入和读出等。
|
|
|
|
（4）性能测试。检查系统是否满足系统设计方案说明书对性能的要求。性能测试覆盖了软件测试的各阶段，而不是等到系统的各部分都集成之后，才确定系统的真正性能。通常与强度测试结合起来进行，并同时对软件、硬件进行测试。软件方面主要从响应时间、处理速度、吞吐量和处理精度等方面来检测。
|
|
|
|
（5）可靠性、可用性和可维护性测试。通常使用以下两个指标来进行衡量：平均失效间隔时间（Mean Time Between Failures，MTBF）是否超过了规定的时限，因故障而停机时间（Mean Time To Repairs，MTTR）在一年中不应超过多少时间。
|
|
|
|
（6）安装测试。在安装软件系统时，会有多种选择。安装测试就是为了检测在安装过程中是否有误、是否容易操作等。主要监测系统的每一个部分是否齐全，硬件的配置是否合理，安装中需要产生的文件和数据库是否已产生，其内容是否正确等。
|
|
|
