【转载】测试基础培训-测试理论知识

1           测试的定义

测试是指由给定产品、过程或按照规定的规程服务的一个或多个特性的测定组成的技术操作。【ISO/IEC2号导则】

测试相关术语：

l         测试计划：为测试和评价某一系统应建立详细的需求、准则、一般方法、职责和

              一般大纲的计划。

l         测试方法：规定技术规程以执行某一测试。

l         测试数据：用于检验问题的数据。

l         测试用例：测试者使用的文档化的细则，其规定如何对某项功能或功能组合进行

              测试。

测试用例通常包含下列内容的详细信息：

——测试目标；

——需测试的功能；

——测试环境和其他条件（配置细节和准备工作）；

——测试数据；

——过程；

——系统的预期行为。

 

2           测试的地位

测试是软件生存周期中一个独立的，关键的阶段，也是保证软件质量的重要手段。测

试代表了规约、设计和编码的最终检查，是软件质量保证的最后一个环节。

 

3           测试的目标

测试的目标是设计出最可能发现最多数量错误，并耗费最少时间和最小代价的测试。

（测试无法说明错误不存在，它只能表示错误已经出现。）

 

4           测试的基本原则

    测试有一些基本原则，掌握、体会这些原则非常有用。

l         所有的测试都应追溯到用户需求。

我们的产品最终是为了给用户使用，测试人员应该把自己看做是用户的代表，从  用户的角度来测试产品，而对用户来说，最严重的错误是那些导致程序不能够满        足他们的需求的错误。

对于我们测试的产品来说，测试的依据是：有标准协议的依据标准协议，无标准

    协议的以用户需求（用户感受）为准。

l         所有的测试活动都应该是有计划的。

测试不仅是应该有计划的，而且要在测试工作真正开始的较长时间就应该进行计

划。测试计划可以在需求一确定，需求模型一完成就开始，总之要在代码产生之前就

    应该开始。

测试计划包括测试设计，产品的质量是设计出来的，同样，测试的质量也是设计

出来的。测试不但要有计划，还需有详细计划，也就是我们常说的测试规程，或者叫

做测试用例设计。

要坚决反对无计划的、无目的的、随意的测试活动，这样的测试或许能发现一些

    错误，但决不是一种有效的工作方法。

l         软件测试的Pareto原则。

  Pareto是一种理论，也就是“二八原理”，最初用于研究社会问题，后来广泛运用

    于各个领域，同样也适用于测试领域。

测试中的Pareto原则是指：80％的故障起源于程序模块中的20％。理解了Pareto原则

有助于我们在测试过程中抓住重点，只有抓住了系统的薄弱环节，然后在此深入下去，

测试才有成效。

l         测试应从“小规模”开始，然后转向“大规模”。

最初的测试应该把焦点放在单个程序模块上，然后是集成测试，最后转向整个系

统的测试。

l         穷举测试是不可能的，然而，充分覆盖程序逻辑，确保程序设计中使用的所有条件是有可能的。

我们的产品运用于不同的环境和条件下，要做到穷举是不可能的，但是我们应该

提高测试的覆盖率，保证程序的每一个逻辑判断分支可以测试到。

l         为了达到最佳效果，应该由独立的第三方来构造测试。

我们目前正是这么做的。

 

5           软件测试技术

5.1         白盒测试

    白盒测试注重于程序控制结构。

l         基本路径测试

l         控制结构测试

－条件测试

  目的：测试程序条件的错误和程序的其他错误

  条件测试策略：分支测试、域测试

－数据流测试

－循环测试

 

5.2         黑盒测试

 黑盒测试发现功能需求错误，而不考虑程序的内部工作。

黑盒测试试图发现以下类型错误：

1）功能不对或遗漏

2）界面错误

3）数据结构或外部数据库访问错误

4）性能错误

5）初始化和终止错误

 

黑盒测试通常用于回答以下问题：

－ 如何测试功能的有效性？

－ 何种类型的输入会产生好的测试用例？

－ 系统是否对特定的输入值尤其敏感？

－ 如何分隔数据类的边界？

－ 系统能够承受何种数据率和数据量？（处理能力、容量）

－ 特定类型的数据组合会对系统产生何种影响？

 

l         等价划分法

定义：等价划分法是将程序的输入域划分为数据类，以便导出测试用例。试图定义一

      个测试用例以发现各类错误，从而减少必须开发的测试用例。

理解：用最精简的、最有代表性的输入设计测试用例，达到最大的覆盖率。

应用：被测对象具有对称性、传递性、自反性的关系连接，即存在等价类。典型地，

      输入条件为一个特定的值、一个数值域、一组相关值或一个布尔条件。

指南：如果输入条件代表一个范围，可以定义一个有效等价类和两个无效等价类。

      如果输入条件需要特定的值，可以定义一个有效等价类和两个无效等价类。

      如果输入条件代表集合的某个元素，可以定义一个有效等价类和一个无效等价

      类。

      如果输入条件是布尔式，可以定义一个有效等价类和一个无效等价类。

 

l         边界值分析（BVA－boundary value analysis）

边界值分析是一种补充等价划分的测试用例设计技术。

指南：

1．如果输入条件代表一组值，测试用例应当执行其中的最大值和最小值，还应当测试略

   大于最小值和略小于最大值的值。

   例子1：数据配置中有一个局容量配置，列举了一些参数的最大值，如：邻接局最大

           数255，交换局网络类型最大数8，GT翻译表容量4096，7号路由最大数512，

           等等，是否测试了所有的边界值呢？

     例子2：IGW－MDB设计容量为6万，VDB设计容量为60万，那么就要测试最大

             容量时系统的处理和相应的指标，如CPU，MEM占用情况等。

2．指南1也适用于输出条件。

3．如果程序数据结构有预定义的边界（如数组有100项），要测试其边界的数据项。

   常见错误：数组越界，循环变量错导致死循环

   典型例子：咸宁HLR7月份出现业务处理机反复重起。原因：循环变量定义错，原定

             义BYTE，结果取值超过255。

 

5.3         白盒测试与黑盒测试的比较

 白盒测试：使用白盒测试技术可以保证一个模块中的所有独立路径被执行一遍，特别

           是检验逻辑错误、不正确的假设条件（设计错误）下程序的处理。

 黑盒测试：通常不考虑控制结构，而是注意信息域。黑盒测试不是白盒测试的替代品，

       而是用于辅助白盒测试发现其他类型的错误。

 

 推荐方法：

     白盒测试与黑盒测试的结合。运用白盒测试技术分析程序控制结构和逻辑关系，（对

于协议程序来说，通常理解协议流程就可以了，但我们现有的协议程序中，加入了大量的非协议内容，所以白盒技术还是需要使用的。）在运用白盒技术的基础上，列出测试的项目（分支覆盖、异常情况），再运用黑盒技术设计测试分项目（等价划分、边界值）。

         

5.4         其他测试技术

黑盒测试和白盒测试是传统的测试方法，可以用于所有的环境、体系结构和应用

    程序，但随着软件技术的复杂，有时还需要运用许多专门的测试技术。

l         面向对象测试技术

l         （嵌入式）实时操作系统测试技术

l         C/S体系结构测试技术

l         GUI测试技术

l         帮助（文档）测试技术

 

6           软件测试策略

软件测试是V&V（验证与确认）的一个部分：

验证：是否正确地完成了产品

确认：是否完成了正确的产品

6.1         制定测试策略

     在设计测试方案，制定测试策略之前，以下问题必须考虑：

1．明确测试目标，并用可度量的术语来描述。

   可度量的术语包括：测试有效性、测试覆盖率、故障出现的平均时间、允许剩         余的缺陷，每次回归测试的测试时间等。

2．分析软件应用的实际环境以及交互情况。

在测试前，一定要有针对性，详细分析合同配置、容量规划、组网模式、开通业务

    等。有的放矢才有成效。

3．建立一个强调“快速循环测试”的测试计划。

一定要考虑回归测试。

4．使用有效的正式技术复审来评估测试策略和测试用例本身。

对测试方案和测试规程进行评审，评审输入必须有测试依据（协议或研制规范、用

    户资料分析等）和相应的测试方案/规程。

5．总结与分析。

   在测试过程中应收集相关数据，进行统计与分析，作为软件测试的统计过程控制方

法的一部分。

 

6.2         单元测试

单元测试包括：

l         对模块接口的测试

l         对局部数据结构的检查

l         对边界条件的测试

l         对独立路径的（基本路径）测试

l         对错误处理路径测试

 

    单元测试的最主要任务是路径测试，即采用分支覆盖等方法保证每条语句被执行一遍。

而单元测试是针对模块的，为了保证这个模块在孤立的情况下能够执行，必须为该模块提供一个“驱动器”（用来模拟输入、输出）和/或“稳定桩”（用来模拟被调用的模块），开发这些模拟程序往往开销是很大的，通常只做一些相对简单的模拟（针对比较简单、独立的模块），而复杂的模拟由于开销太大，这部分的覆盖执行测试被放到后面的集成测试中去。

 

6.3         集成测试

    集成测试是通过测试发现和接口有关的问题来构造程序结构的系统化技术。集成测试

就是接口测试。通常开发部的联调就是一种集成测试。当集成测试时，测试人员应当能够识别系统的关键模块，对关键模块要尽早测试，并且要充分测试。

    对于协议软件来说，标准的接口都有协议要求，那么对接口的测试就表现在协议顺从

上：是否正确理解了协议并按照协议编程。很多情况下，错误产生于对协议的理解不一致

或顺从协议不严格。

集成测试还应注重于内部接口的测试，如相关模块间接口、前后台接口。对于开发人

员来说，和外部接口一样，明确规范内部接口间协议，同步修改是避免接口错误的最有效

方法。

 

6.4         确认测试

    定义：确认测试即确认软件是否可以按照用户合理的期望的方式来工作。

   

    谁或者什么来作为用户合理的期望的裁定者？――测试依据？

 

    对于有协议标准的，以协议标准为裁定者；对于无协议标准的，以研制规范中的软件

需求规约为裁定。（软件需求规约是在软件工程早期阶段对用户需求进行收集分析获得的，针对我们目前的状况，需求分析较差，那么测试人员作为软件的第一用户，站在用户的角度考虑需求；用服人员作为和用户最接近的部分，充分考虑用服部门的意见。）

    确认测试主要用来发现程序实现与用户需求之间的偏差。

 

6.5         系统测试

l         恢复测试

系统的容错性测试，系统必须在一定的时间内从错误中恢复（包括自动恢复和手工恢

复）过来。

l         安全测试

用来验证集成在系统内的保护机制是否能够在实际保护系统中不受到非法侵入。（要把

系统设计为想要攻破系统而付出的代价大于攻破系统之后得到的信息的价值）

我们的系统安全性不是重点，但也存在一些保密措施，如VLR容量表配置、安全管理

中的变量控制。

l         压力测试

压力测试是在一种需要反常数量、频率或资源的方式下执行系统。“看看能将系统折腾

到什么程度而不会出错？”

例子：模块间通讯流量测试时，将每秒发送包数不断增大。

l         性能测试

性能测试用于测试软件在集成系统中的运行性能。

性能测试常常和压力测试一起进行，在一种苛刻的环境中衡量资源的使用。通过对系

统的检测，可以发现导致效率降低和系统故障的情况。对于实时系统和嵌入系统来说，满

足性能需求尤其重要。

 

更高质量的软件需要更系统化的测试方法。我们需要的是贯穿整个测试过程的一个整

体策略，而且在方法学上应当象基于分析、设计和编码的系统化软件开发一样进行周密的

计划。

 

7           软件质量要求

一个合格的，符合标准的软件包必须遵循以下要求：

―――产品描述的要求，尤其应包含规定信息，并且其所有要求的内容是可测试的、

      正确的；

―――用户文档的要求；

―――程序要求和数据要求。

 

l         产品描述

产品描述包含内容：

―― 标识和指示

     产品描述标识、产品标识、供方、工作任务、符合需求文档、要求系统配置、与

     其他产品接口、要交付项、安装、支持、维护

―― 功能说明

     功能概述、边界值、安全

―― 可靠性说明

―― 易用性说明

   用户界面、要求的知识、适应用户的需要、防止侵权行为、使用效率和用户满意度。

―― 效率说明

―― 可维护性说明

―― 可移植性说明

l         用户文档

―― 完整性

     安装手册、操作手册、维护手册

―― 正确性

―― 一致性

―― 易理解性

―― 易浏览性

l         程序和数据

―― 功能性

     安装、功能表现、正确性、一致性

―― 可靠性

―― 易用性

     易理解性、易浏览性（如告警、日志）、可操作性

―― 效率

―― 可维护性

―― 可移植性

 

8           软件测试文件编制规范

    软件测试文件类型包括：测试计划、测试说明、测试报告

测试计划：描述测试活动的范围、方法、资源和进度。规定被测试的项、被测试的特

           性、应完成的测试任务、担任各项工作的人员职责及与本计划有关的风险等。

 

测试计划内容：

1）测试计划名称

2）引言

    归纳所要求测试的软件项和软件特性，可包括系统目标、背景、范围及引用材料等。

3）测试项

    描述被测试的对象，包括其版本、修订级别、并指出在测试开始之前对逻辑和物理变换的要求。

4）被测试的特性

    指明所有要被测试的软件特性及其组合，指明每个特性或特性组合有关的测试设计   说明。

5）不被测试的特性

    指明不被测试的所有特性和特性的有意义的组合及其理由。

6）方法

    描述测试的总体方法，规定测试制定特性组所需要的主要活动、技术和工具，应详尽地描述方法以便列出主要的测试任务，并估计执行各项任务所需的时间。规定所希望的最   低程度的测试彻底性，指明用于判断测试彻底性的技术。指出对测试的主要限制，如测试项可用性、测试资源的可用性和测试截止期限等。

7）测试项通过准则

    规定各测试项通过测试的标准。

8）暂停标准和再启动要求

    规定用于暂停全部或部分与本计划有关的测试项的测试活动的标准。规定当测试再启动时必须重复的测试活动。

9）应提供的测试文件

    规定测试完成后所有应提交的文件。

10〕测试任务

    指明执行测试所需的任务集合，指出任务间的一切依赖关系和所需的一切特殊技能。

11〕环境要求

    规定测试环境所必备的和希望有的性质。包括：软硬件环境、支撑软件设备、测

试工具及其它测试要求。指出测试组目前还不能得到的所有要求的来源。

12〕职责

    人员分工。指出负责设计、准备、执行、监督、检查和仲裁的人员，以及提供测试项和测试环境的人员。

13〕人员和培训要求

    指明测试人员应有的水平以及为掌握必要技能可供选择的培训科目。

14〕进度

    规定测试里程碑和所有测试项传递时间。

15〕风险和应急

    预测测试计划中的风险，规定对各种风险的应急措施（如：加班、申请支援等）。

 

测试说明：

―― 测试设计说明：详细描述测试方法，规定该设计及其有关测试所包括的特性，规定完

                   成测试所需的测试用例和测试规程，并规定特性的通过准则。

测试设计说明内容：

1）测试设计说明名称

2）被测试的特性

      规定测试项，描述作为本设计测试目标的特性和特性的组合，其它特性可以论及，

  但不必测试。

3）方法详述

      将测试计划中规定的方法进行细化，包括要用的具体测试技术，规定分析测试结果

  的方法。规定为选择测试用例提供合理依据的一切分析结果。归纳所有测试用例的共同

  属性，如输入约束条件，共享环境的要求，对共享的特殊规程的要求及任何共享的测试

  用例间的依赖关系。

4）测试用例名称

5）特性通过准则

 

―― 测试用例说明：列出用于输入的具体值以及预期的输出结果，并规定在使用具体测试

                   用例时，对测试规程的各种限制。将测试用例与测试设计分开，可以

                   使它们用于多个设计并能在其它情形下重复使用。

―― 测试规程说明：规定对于运行系统和执行指定的测试用例来实现有关测试设计所要求

                   的所有步骤。

测试报告：

―― 测试项传递报告：指明在开发组和测试组独立工作的情况下或者在希望正式开始测试

                     的情况下为进行测试而被传递的测试项。

―― 测试日志：测试组用于记录测试执行过程中发生的情况。（测试记录）

―― 测试事件报告：描述在测试执行期间发生并需要进一步调查的一切事件。（故障报告）

―― 测试总结报告：总结与测试设计说明有关的测试活动。

测试总结报告内容：

1）测试总结报告名称                   

2）简述

3）差异

4）测试充分性评价

5）结果概述

6）评价

7）测试活动总结