以下关于软件测试原则的叙述中，正确的是（55）。 <br />①测试开始得越早，越有利于发..

2016年下半年上午试卷综合知识

第 55 题


知识点	测试计划软件测试原则测试方法测试原则软件测试
关键词	测试方法测试计划测试用例穷举测试软件测试数据测试用例
章/节	软件测试基本概念

以下关于软件测试原则的叙述中，正确的是（55）。
①测试开始得越早，越有利于发现缺陷
②测试覆盖率和测试用例数量成正比
③测试用列既需选用合理的输入数据，又需要选择不合理的输入数据
④应制定测试计划并严格执行，排除随意性
⑤采用合适的测试方法，可以做到穷举测试
⑥程序员应尽量测试自己的程序

A. ①②③④⑤⑥

B. ①②③④⑤

C. ①②③④

D. ①③④

相关试题软件测试原则

第56题

2011年下半年

以下关于软件测试原则的叙述中，不正确的是（56)。

第52题

2015年下半年

以下关于软件测试原则叙述中，不正确是的（52）。

第55题

2019年下半年

以下关于软件测试原则的叙述中，不正确的是（）。

知识点讲解

· 测试计划

· 软件测试原则

· 测试方法

· 测试原则

· 软件测试

测试计划

制定一个全面的测试计划是负载测试成功的关键。定义明确的测试计划将确保制定的方案能完成负载测试目标。这部分内容描述负载测试计划过程，包括分析应用程序、定义测试目标、计划方案实施、检查测试目标。在任何类型的系统测试中，制定完善的测试计划是成功完成测试的基础。负载压力测试计划有助于：

①构建能够精确地模拟工作环境的测试方案。负载测试指在典型的工作条件下测试应用程序，并检测系统的性能、可靠性和容量等。

②了解测试需要的资源。应用程序测试需要硬件、软件和人力资源。开始测试之前，应了解哪些资源可用并确定如何有效地使用这些资源。

③以可度量的指标定义测试成功条件。明确的测试目标和标准有助于确保测试成功。仅定义模糊的目标（如检测重负载情况下的服务器响应时间）是不够的。明确的成功条件应类似于“50个客户能够同时查看他们的账户余额，并且服务器响应时间不超过1分钟”。

下面详细论述负载压力测试计划过程的4个步骤。

分析应用程序

负载测试计划的第一步是分析应用程序。应该对硬件和软件组件、系统配置以及典型的使用模型有一个透彻的了解。应用程序分析可以确保使用的测试环境能够在测试中精确地反映应用程序的环境和配置。

确定系统组件

绘制一份应用程序结构示意图。如果可能，从现有文档中提取一份示意图。如果要测试的应用程序是一个较大的网络系统的一部分，应该确定要测试的系统组件。确保该示意图包括了所有的系统组件，例如客户机、网络、中间件和服务器等。

如下图所示说明了一个由许多Web用户访问的联机银行系统。各Web用户连接到同一数据库以转移现金和支票余额。客户使用不同的浏览器，通过Web方式连接到数据库服务器。

联机银行系统应用布署

描述系统配置

增加更多详细信息以完善示意图。描述各系统组件的配置。应当掌握以下信息：

. 连接到系统的用户数；

. 应用程序客户端计算机的配置情况（硬件、内存、操作系统、软件、开发工具等）；

. 使用的数据库和Web服务器的类型（硬件、数据库类型、操作系统、文件服务器等）；

. 服务器与应用程序客户端之间的通信方式；

. 前端客户端与后端服务器之间的中间件配置和应用程序服务器；

. 可能影响响应时间的其他网络组件（调制解调器等）；

. 通信设备的吞吐量以及每个设备可以处理的并发用户数。

例如，在如上图所示的示意图中，多个应用程序客户端在访问系统。客户端的配置如下表所示。

客户端配置内容

分析使用模型

定义系统的典型使用方式，并确定需要重点测试的功能。考虑哪些用户使用系统、每种类型用户的数量，以及每个用户的典型任务。此外，还应考虑任何可能影响系统响应时间的后台负载。

例如，假设每天上午有200名员工登录记账系统，并且该办公室网络有固定的后台负载：50名用户执行各种字处理和打印任务。可以创建一个200个虚拟用户登录访问记账数据库的方案，并检测服务器的响应时间。要了解后台负载对响应时间的影响，可以在运行方案的网络中再模拟员工执行字处理和打印活动的负载。

任务分布

除定义常规用户任务外，还应该查看这些任务的分布情况。例如，假设银行用户使用一个中央数据库为跨越多个州和时区的客户提供服务。250个应用程序客户端分布在两个不同的时区，全都连接到同一个Web服务器中。其中150个在芝加哥，另外100个在底特律。每个客户端从上午9点开始工作，但由于处于不同的时区，因此在任何特定时间内都不会有超过150个的用户同时登录。可以分析任务分布，以确定数据库活动峰值期的发生时间，以及负载峰值期间的典型活动。

定义测试目标

开始测试之前，应精确地定义想要实现的目标。

以可度量的指标制定目标

确定了负载测试的一般性目标后，应该以可度量指标制定更具针对性的目标。为了提供评估基准，应精确地确定、区分可接受和不可接受测试结果的标准。

例如：

. 一般性目标产品评估：选择Web服务器的硬件。

. 明确目标产品评估：在一台HP服务器和一台NEC服务器上运行同一个包含300个虚拟用户的组。当300个用户同时浏览Web应用程序页面时，确定哪一种硬件提供更短的响应时间。

. 测试目标

①度量最终用户的响应时间，完成一个业务流程需要多长时间；

②定义最优的硬件配置，哪一种硬件配置可以提供最佳性能；

③检查可靠性，系统无错误或无故障运行的时间长度或难度；

④查看硬件或软件升级对性能或可靠性有何影响；

⑤评估新产品，应选择哪些服务器硬件或软件；

⑥度量系统容量，在没有显著性能下降的前提下，系统能够处理多大的负载；

⑦确定瓶颈，哪些因素会延长响应时间。

确定测试的时间

负载测试应贯穿于产品的整个生命周期。如下表说明了在产品生命周期的各个阶段有哪些类型的测试与之相关。

产品生命周期与测试类型

计划方案实施

下一步是确定如何实现测试目标。

定义性能度量的范围

可以度量应用程序中不同点的响应时间。根据测试目标确定在哪里运行Vuser（虚拟用户）以及运行哪些Vuser。

. 度量端到端的响应时间。

可以在前端运行GUI Vuser（图形用户界面用户）或RTE Vuser（终端用户）来度量典型用户的响应时间。GUI Vuser可以将输入提交给客户端应用程序并从该应用程序接收输出，以模拟实际用户；RTE Vuser则向基于字符的应用程序提交输入，并从该应用程序接收输出，以模拟实际用户。

可以在前端运行GUI或RTE Vuser来度量跨越整个网络（包括终端仿真器或GUI前端、网络和服务器）的响应时间。如下图所示为端到端的响应时间。

端到端的响应时间

. 度量网络和服务器响应时间。

可以通过在客户机运行Vuser（非GUI或RTE Vuser）来度量网络和服务器的响应时间（不包括GUI前端的响应时间）。Vuser模拟客户端对服务器的进程调用，但不包括用户界面部分。在客户机运行大量Vuser时，可以度量负载对网络和服务器响应时间的影响。如下图所示为网络和服务器的响应时间。

网络和服务器的响应时间

. 度量GUI响应时间。

可以通过减去前两个度量值，来确定客户端应用程序界面对响应时间的影响。GUI响应时间=端到端响应时间-网络和服务器响应时间。如下图所示为GUI响应时间。

GUI响应时间

. 度量服务器响应时间。

可以度量服务器响应请求（不跨越整个网络）所花费的时间。通过在与服务器直接相连的计算机上运行Vuser，可以度量服务器性能。如下图所示为服务器响应时间。

服务器响应时间

. 度量中间件到服务器的响应时间。

如果可以访问中间件及其API，便可以度量服务器到中间件的响应时间。可以使用中间件API创建Vuser，来度量中间件到服务器的性能。如下图所示为中间件到服务器响应时间。

定义Vuser活动

根据对Vuser类型的分析以及它们的典型任务和测试目标来创建Vuser脚本。由于Vuser模拟典型最终用户的操作，因此Vuser脚本应包括典型的最终用户任务。例如，要模拟联机银行客户端，应该创建一个执行典型银行任务的Vuser脚本。需要浏览经常访问的页面，以转移现金或支票余额。

中间件到服务器响应时间

根据测试目标确定要衡量的任务，并定义这些任务的事务。这些事务度量服务器响应Vuser提交的任务所花费的时间（端到端时间）。例如，要查看提供账户余额查询的银行Web服务器的响应时间，则应在Vuser脚本中为该任务定义一个事务。

此外，可以通过在脚本中使用集合点来模拟峰值期活动。集合点指示多个Vuser在同一时刻执行任务。例如，可以定义一个集合点，以模拟70个用户同时更新账户信息的情况。

选择Vuser

确定用于测试的硬件配置之前，应该先确定需要的Vuser的数量和类型。要确定运行多少个Vuser和哪些类型的Vuser，请综合考虑测试目标来查看典型的使用模型。以下是一些一般性规则：

. 使用一个或几个GUI用户来模拟每一种类型的典型用户连接；

. 使用RTE Vuser来模拟终端用户；

. 运行多个非GUI或非RTE Vuser来生成每个用户类型的其余负载。

例如，假设有五种类型的用户，每种用户执行一个不同的业务流程，如下表所示。

Vuser的数量和类型

选择测试硬件和软件

硬件和软件应该具有强大的性能和足够快的运行速度，以模拟所需数量的虚拟用户。

在确定计算机的数量和正确的配置时，请考虑以下事项。

. 建议在一台单独的计算机上运行测试工具主控台。

. 在一台Windows计算机只能运行一个GUI Vuser；而在一台UNIX计算机上则可以运行几个GUI Vuser。

. GUI Vuser测试计算机的配置应该尽量与实际用户的计算机配置相同。

关于每个测试组件的硬件要求，请参考下表一和下表二。要获得最佳性能，应满足表中所列要求。

测试机硬件与软件要求（Windows配置要求）

注意：对于一个要运行许多事务的长方案，结果文件需要几个MB的磁盘空间。负载生成器计算机还需要几个MB的磁盘空间来存储临时文件（如果没有NFS）。有关运行时文件存储的详细信息，请参阅第10章“配置方案”。

有关最新的安装要求，请访问

http://www.mercuryinteractive.com/products/loadrunner/technical/

测试机硬件与软件要求（UNIX配置要求）

检查测试目标

测试计划应该基于明确定义的测试目标。下面概述了常规的测试目标。

①度量最终用户响应时间。

②定义最优的硬件配置。

③检查可靠性。

④查看硬件或软件升级。

⑤评估新产品。

⑥确定瓶颈。

⑦度量系统容量。

度量最终用户响应时间

查看用户执行业务流程以及从服务器得到响应所花费的时间。例如，假设想要检测：系统在正常的负载情况下运行时，最终用户能否在20秒内得到所有请求的响应。如下图显示了一个银行应用程序的负载和响应时间度量之间的关系。

负载和响应时间度量关系

定义最优的硬件配置

检测各项系统配置（内存、CPU速度、缓存、适配器、调制解调器）对性能的影响。了解系统体系结构并测试了应用程序响应时间后，可以度量不同系统配置下的应用程序响应时间，从而确定哪一种设置能够提供理想的性能级别。

例如，可以设置三种不同的服务器配置，并针对各个配置运行相同的测试，以确定性能上的差异。

. 配置1：200MHz、64MB RAM。

. 配置2：200MHz、128MB RAM。

. 配置3：266MHz、128MB RAM。

检查可靠性

确定系统在连续的高工作负载下的稳定性级别。可以创建系统负载：强制系统在短时间内处理大量任务，来模拟系统在数周或数月的时间内通常会遇到的活动类型。

查看硬件或软件升级

执行回归测试，以便对新旧版本的硬件或软件进行比较。可以查看软件或硬件升级对响应时间（基准）和可靠性的影响。应用程序回归测试需要查看新版本的效率和可靠性是否与旧版本相同。

评估新产品

可以运行测试，以评估单个产品和子系统在产品生命周期中的计划阶段和设计阶段的表现。例如，可以根据评估测试来选择服务器的硬件或数据库套件。

确定瓶颈

可以运行测试以确定系统的瓶颈，并确定哪些因素导致性能下降，例如，文件锁定、资源争用和网络过载。使用负载压力测试工具，以及网络和计算机监视工具以生成负载，并度量系统中不同点的性能。如下图所示为系统不同点的性能。

系统不同点的性能

度量系统容量

度量系统容量，并确定系统在不降低性能的前提下能提供多少额外容量。要查看容量，可以查看现有系统中性能与负载间的关系，并确定出现响应时间显著延长的位置。该处通常称为响应时间曲线的“拐点”。确定了当前容量后，便可以确定是否需要增加资源以支持额外的用户。如下图所示为响应时间与负载关系。

响应时间与负载关系

软件测试原则

基于测试是为了寻找软件的错误与缺陷，评估与提高软件质量，我们提出这样的一组测试原则，如下所示。

. 所有的软件测试都应追溯到用户需求。

这是因为软件的目的是使用户完成预定的任务，并满足用户的需求，而软件测试所揭示的缺陷和错误使软件达不到用户的目标，满足不了用户需求。

. 应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。

由于软件的复杂性和抽象性，在软件生命周期各个阶段都可能产生错误，所以不应把软件测试仅仅看作是软件开发的一个独立阶段的工作，而应当把它贯穿到软件开发的各个阶段中。在软件开发的需求分析和设计阶段就应开始测试工作，编写相应的测试文档。同时，坚持在软件开发的各个阶段进行技术评审与验证，这样才能在开发过程中尽早发现和预防错误，杜绝某些缺陷和隐患，提高软件质量。只要测试在生命周期中进行得足够早，就能够提高被测软件的质量，这就是预防性测试的基本原则。

. 完全测试是不可能的，测试需要终止。

想要进行完全的测试，在有限的时间和资源条件下，找出所有的软件缺陷和错误，使软件趋于完美，是不可能的。主要有三个原因：

①输入量太大；

②输出结果太多；

③路径组合太多。

一个适度规模的程序，其路径组合近似天文数字，对于每一种可能的路径都执行一次的穷举测试是不可能的。此外，测试也是有成本的，越是测试后期，为发现错误所付出的代价就会越大，因此也要根据测试错误的概率以及软件可靠性要求，确定最佳停止测试时间，我们不能无限地测试下去。

. 测试无法显示软件潜在的缺陷。

进行测试是可以查找并报告发现的软件缺陷和错误，但不能保证软件的缺陷和错误全部找到，继续进一步测试可能还会找到一些，也就是说测试只能证明软件存在错误而不能证明软件没有错误。

. 充分注意测试中的群集现象。

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

. 程序员应避免检查自己的程序。

基于心理因素，人们认为揭露自己程序中的问题总不是一件愉快的事，不愿否认自己的工作；由于思维定势，人们难于发现自己的错误。因此，为达到测试目的，应由客观、公正、严格的独立的测试部门或者独立的第三方测试机构进行测试。

. 尽量避免测试的随意性。

应该从工程的角度去理解软件测试，它是有组织、有计划、有步骤的活动。

测试方法

根据是否执行软件，将软件测试方法分为静态测试和动态测试。动态测试是建立在程序的执行过程中，根据是否要求了解被测对象的内部，分为黑盒测试和白盒测试。

静态测试和动态测试

静态测试

静态测试方法包括检查单和静态分析方法，对软件文档的静态测试方法主要是以检查单的形式进行文档审查，而对软件代码的静态测试方法一般采用代码审查、代码走查和静态分析的形式进行。

静态分析是一种对代码的机械性和程序化的特性分析方法。一般包括控制流分析、数据流分析、接口分析和表达式分析。

代码审查是检查代码和设计的一致性、代码执行标准的情况、代码逻辑表达的正确性、代码结构的合理性以及代码的可读性。代码审查应根据所使用的语言和编码规范确定审查所用的检查单，检查单的设计或采用应经过评审。

代码走查是由测试人员组成小组，准备一批有代表性的测试用例，集体扮演计算机的角色，按照程序的逻辑，逐步运行测试用例，查找被测软件缺陷。代码走查应由测试人员集体阅读讨论程序，是用“人脑”执行测试用例并检查程序。

对于规模较小、安全性要求很高的代码也可进行形式化证明。静态分析常需要使用软件工具进行。

静态测试的特点有：不必设计在计算机上执行的测试用例；可充分发挥人的逻辑思维优势；不需特别条件，容易开展；发现错误的同时也就定位了错误，不需作额外的错误定位工作。

动态测试

动态测试是建立在程序的执行过程中，根据是否对被测对象内部的了解，分为黑盒测试和白盒测试。

黑盒测试是一种按照软件功能说明设计测试数据的技术，不考虑程序内部结构和编码结构，也不需考虑程序的语句及路径，只需了解输入／输出之间的关系，依靠这一关系和软件功能说明确定测试数据，判定测试结果的正确性。黑盒测试又称功能测试、数据驱动测试或基于需求的测试。

白盒测试是一种按照程序内部逻辑结构和编码结构设计测试数据的技术，可以看到程序内部结构，并根据内部结构设计测试数据，使程序中的每个语句、每个条件分支、每个控制路径的覆盖情况都在测试中受到检验。白盒测试又称结构测试、逻辑测试或基于程序的测试。

动态测试的特点有：实际运行被测程序；必须设计测试用例来运行；测试结果分析工作量大，测试工作费时、费力；投入人员多、设备多，处理数据多，要求有较好的管理和工作规程。

在软件动态测试过程中，应采用适当的测试方法，实现测试要求。配置项测试和系统测试一般采用黑盒测试方法；部件测试一般主要采用黑盒测试方法，辅助以白盒测试方法；单元测试一般采用白盒测试方法，辅助以黑盒测试方法。

黑盒测试

黑盒测试方法一般采用功能分解、等价类划分、边界值分析、判定表、因果图、随机测试、猜错法和正交试验法等。

功能分解

功能分解是将需求规格说明中每一个功能加以分解，确保各个功能被全面地测试。功能分解是一种较常用的方法。

步骤如下：

（1）使用程序设计中的功能抽象方法把程序分解为功能单元。

（2）使用数据抽象方法产生测试每个功能单元的数据。

功能抽象中程序被看成一种抽象的功能层次，每个层次可标识被测试的功能，层次结构中的某一功能有由其下一层功能定义。按照功能层次进行分解，可以得到众多的最低层次的子功能，以这些子功能为对象，进行测试用例设计。

数据抽象中，数据结构可以由抽象数据类型的层次图来描述，每个抽象数据类型有其取值集。程序的每一个输入和输出量的取值集合用数据抽象来描述。

等价类划分

等价类划分是在分析需求规格说明的基础上，把程序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试用例。

步骤如下：

（1）划分有效等价类：对规格说明是有意义、合理的输入数据所构成的集合。

（2）划分无效等价类：对规格说明是无意义、不合理的输入数据所构成的集合。

（3）为每一个等价类定义一个唯一的编号。

（4）为每一个等价类设计一组测试用例，确保覆盖相应的等价类。

边界值分析

边界值分析是针对边界值进行测试的。使用等于、小于或大于边界值的数据对程序进行测试的方法就是边界值分析方法。

步骤如下：

（1）通过分析需求规格说明，找出所有可能的边界条件。

（2）对每一个边界条件，给出满足和不满足边界值的输入数据。

（3）设计相应的测试用例。

对满足边界值的输入可以发现计算错误，对不满足的输入可以发现域错误。该方法会为其他测试方法补充一些测试用例，绝大多数测试都会用到本方法。

判定表

判定表由四部分组成：条件桩、条件条目、动作桩、动作条目。任何一个条件组合的取值及其相应要执行的操作构成规则，条目中的每一列是一条规则。

条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试用例。

建立并优化判定表，把判定表中每一列表示的情况写成测试用例。

该方法的使用有以下要求：

（1）需求规格说明以判定表形式给出，或是很容易转换成判定表。

（2）条件的排列顺序不会影响执行哪些操作。

（3）规则的排列顺序不会影响执行哪些操作。

（4）每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。

（5）如果某一规则的条件的满足，将执行多个操作，这些操作的执行与顺序无关。

因果图

因果图方法是通过画因果图，把用自然语言描述的功能说明转换为判定表，然后为判定表的每一列设计一个测试用例。

步骤如下：

（1）分析需求规格说明，引出原因（输入条件）和结果（输出结果），并给每个原因和结果赋予一个标识符。

（2）分析需求规格说明中语义的内容，并将其表示成连接各个原因和各个结果的“因果图”。

（3）在因果图上标明约束条件。

（4）通过跟踪因果图中的状态条件，把因果图转换成有限项的判定表。

（5）把判定表中每一列表示的情况生成测试用例。

如果需求规格说明中含有输入条件的组合，宜采用本方法。有些软件的因果图可能非常庞大，根据因果图得到的测试用例数目非常多，此时不宜使用本方法。

随机测试

随机测试指测试输入数据是在所有可能输入值中随机选取的。测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难，多用于可靠性测试和系统强度测试。

猜错法

猜错法是有经验的测试人员，通过列出可能有的错误和易错情况表，写出测试用例的方法。

正交实验法

正交实验法是从大量的实验点挑出适量的、有代表性的点，应用正交表，合理地安排实验的一种实验设计方法。

利用正交实验法来设计测试用例时，首先要根据被测软件的需求规格说明找出影响功能实现的操作对象和外部因素，把它们当作因子，而把各个因子的取值当作状态，生成二无的因素分析表。然后，利用正交表进行各因子的状态的组合，构造有效的测试输入数据集，并由此建立因果图。这样得出的测试用例的数目将大大减少。

白盒测试

白盒测试方法一般包括控制流测试（语句覆盖测试、分支覆盖测试、条件覆盖测试、修订的条件／判定覆盖MC/DC、条件组合覆盖测试、路径覆盖测试）、数据流测试、程序变异、程序插桩、域测试和符号求值等。

控制流测试

控制流测试依据控制流程图产生测试用例，通过对不同控制结构成分的测试验证程序的控制结构。所谓验证某种控制结构即指使这种控制结构在程序运行中得到执行，也称这一过程为覆盖。以下介绍几种覆盖：

（1）语句覆盖。语句覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每一条语句至少被遍历，语句覆盖在测试中主要发现错误语句。

（2）分支覆盖。分支覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每个真值分支和假值分支至少执行一次，分支覆盖也称判定覆盖。

（3）条件覆盖。条件覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判断中的每个条件的可能取值至少满足一次。

（4）修订的条件／判定覆盖（MC/DC——Modified Condition/Decision Coverage）。修订的条件／判定覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判定中的每个条件都曾独立的影响判定的结果至少一次（独立影响意思是在其他的条件不变的情况下，只改变一个条件，就可影响整个判定的值）。

对安全性要求比较高的软件，一般采用此覆盖要求。此覆盖要求在测试用例的效率和数量之间较为平衡。

（5）条件组合覆盖。条件组合覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判断中条件的各种组合至少出现一次，这种方法包含了“分支覆盖”和“条件覆盖”的各种要求。

（6）路径覆盖。路径覆盖要求设计适当数量的测试用例，运行被测程序，使得程序沿所有可能的路径执行，较大程序的路径可能很多，所以在设计测试用例时，要简化循环次数。

以上各种覆盖的控制流测试步骤如下：

（1）将程序流程图转换成控制流图。

（2）经过语法分析求得路径表达式。

（3）生成路径树。

（4）进行路径编码。

（5）经过译码得到执行的路径。

（6）通过路径枚举产生特定路径的测试用例。

控制流图是描述程序控制流的一种图示方式，它由结点和定向边构成。控制流图的结点代表一个基本块，定向边代表控制流的方向。其中要特别注意的是，如果判断中的条件表达式是复合条件，即条件表达式是由一个或多个逻辑运算符连接的逻辑表达式，则需要改变复合条件的判断为一系列单个条件的嵌套的判断。控制流图的基本结构如下图所示。

控制流图基本结构

数据流测试

数据流测试是用控制流程图对变量的定义和引用进行分析，查找出未定义的变量或定义了而未使用的变量，这些变量可能是拼错的变量、变量混淆或丢失了语句。数据流测试一般使用工具进行。

数据流测试通过一定的覆盖准则，检查程序中每个数据对象的每次定义、使用和消除的情况。

数据流测试步骤：

（1）将程序流程图转换成控制流图。

（2）在每个链路上标注对有关变量的数据操作的操作符号或符号序列。

（3）选定数据流测试策略。

（4）根据测试策略得到测试路径。

（5）根据路径可以获得测试输入数据和测试用例。

动态数据流异常检查在程序运行时执行，获得的是对数据对象的真实操作序列，克服了静态分析检查的局限，但动态方式检查是沿与测试输入有关的一部分路径进行的，检查的全面性和程序结构覆盖有关。

程序变异

程序变异是一种错误驱动测试，是为了查出被测软件在做过其他测试后还剩余一些的小错误。本方法应用于测试工具。

程序插装

程序插装是向被测程序中插入操作以实现测试目的方法。程序插装不应该影响被测程序的运行过程和功能。

有很多的工具有程序插装功能。由于数据记录量大，手工进行将是一件很烦琐的事。

域测试

域测试是要判别程序对输入空间的划分是否正确。该方法限制太多，使用不方便，供有特殊要求的测试使用。

符号求值

符号求值是允许数值变量取“符号值”以及数值。符号求值可以检查公式的执行结果是否达到程序预期的目的；也可以通过程序的符号执行，产生出程序的路径，用于产生测试数据。符号求值最好使用工具，在公式分支较少时手工推导也是可行的。

测试原则

系统测试是保证系统质量和可靠性的关键步骤，是对系统开发过程中的系统分析、系统设计和实施的最后复查。根据测试的概念和目的，在进行信息系统测试时应遵循以下基本原则。

（1）应尽早并不断地进行测试。测试不是在应用系统开发完之后才进行的。由于原始问题的复杂性、开发各阶段的多样性以及参加人员之间的协调等因素，使得在开发的各个阶段都有可能出现错误。因此，测试应贯穿在开发的各个阶段，应尽早纠正错误，消除隐患。

（2）测试工作应该避免由原开发软件的人或小组承担，一方面，开发人员往往不愿否认自己的工作，总认为自己开发的软件没有错误；另一方面，开发人员的错误很难由本人测试出来，很容易根据自己编程的思路来制定测试思路，具有局限性。测试工作应由专门人员来进行，这样会更客观、更有效。

（3）在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期输出结果。将实际输出结果与预期结果相比较就能发现测试对象是否正确。

（4）在设计测试用例时，不仅要设计有效、合理的输入条件，也要包含不合理、失效的输入条件。在测试的时候，人们往往习惯按照合理的、正常的情况进行测试，而忽略了对异常、不合理、意想不到的情况进行测试，而这可能就是隐患。

（5）在测试程序时，不仅要检验程序是否做了该做的事，还要检验程序是否做了不该做的事。多余的工作会带来副作用，影响程序的效率，有时会带来潜在的危害或错误。

（6）严格按照测试计划来进行，避免测试的随意性。测试计划应包括测试内容、进度安排、人员安排、测试环境、测试工具和测试资料等。严格地按照测试计划可以保证进度，使各方面都得以协调进行。

（7）妥善保存测试计划、测试用例，作为软件文档的组成部分，为维护提供方便。

（8）测试例子都是精心设计出来的，可以为重新测试或追加测试提供方便。当纠正错误、系统功能扩充后，都需要重新开始测试，而这些工作的重复性很高，可以利用以前的测试用例，或在其基础上修改，然后进行测试。

软件测试

测试是为评价和改进产品质量、识别产品的缺陷和问题而进行的活动。

软件测试是针对一个程序的行为，在有限测试用例集合上动态验证软件是否达到预期的行为。

软件测试过程如下：

（1）拟定测试计划。

（2）编制测试大纲。

（3）设计和生成测试用例。

（4）实施测试。

（5）生成测试报告。

软件测试方法：

.人工测试：采用人工方式进行测试，目的是通过对程序静态结构的检查，找出编译时不能发现的错误。人工测试包括个人复查、抽查和会审等。

.机器测试：把设计好的测试用例作用于被测程序，比较测试结果和预期结果是否一致。机器测试包括黑盒测试（功能测试）和白盒测试（结构测试）。

软件测试伴随软件开发和维护过程，通常可以在概念上划分为以下三个阶段：

.单元测试：也称为模块测试，在模块编写完成且无编译错误后就可以进行。

.集成测试：也称为组装测试，就是把模块按系统设计说明书的要求组合起来进行测试。

.系统测试：是将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起，进行信息系统的各种组装和确认测试。其目的是通过与系统需求相比较，发现所开发的系统与用户需求不符合的地方。

更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5