软件测试教程(华为培训专用)-第6章.ppt

第六章 系统测试 6.1 性能测试 6.1.1 性能测试的基本概念 n性能测试主要检验软件是否达到需求规 格说明书中规定的各类性能指标，并满 足一些性能相关的约束和限制条件。 性能测试包括以下几个方面 ： n评估系统的能力。测试中得到的负荷和响应时 间等数据可以被用于验证所计划的模型的能力 ，并帮助做出决策。 n识别系统中的弱点。受控的负荷可以被增加到 一个极端的水平并突破它，从而修复系统的瓶 颈或薄弱的地方。 n系统调优。重复运行测试，验证调整系统的活 动得到了预期的结果，从而改进性能，检测软 件中的问题。 6.1.2 性能测试方法 n基准法 性能测试的基准大体有以下几方面： n响应时间 从应用系统发出请求开始，到客户端接收到最后一个字节数据为止所消耗的 时间。合理的响应时间取决于实际的用户需求。 n并发用户数 一般是指同一时间段内访问系统的用户数量。 n吞吐量 指单位时间内系统处理的客户请求数量。 n性能计数器 描述服务器或操作系统性能的一些数据指标，比如Windows系统资源管理器 。 6.1.2 性能测试执行 分为三个阶段： n1计划阶段 n2测试阶段 n3分析阶段 计划阶段 n定义目标并设置期望值 n收集系统和测试要求 n定义工作负载 n选择要收集的性能度量值 n标出要运行的测试并决定什么时候运行它们 n决定工具选项和生成负载 n编写测试计划，设计用户场景并创建测试脚本 测试阶段 n做准备工作（如建立测试服务器或布置其他 设备） n运行测试 n收集数据 分析阶段 n分析结果 n改变系统以优化性能 n设计新的测试 6.1.3 性能测试案例分析 n一个数据库应用系统性能测试的具 体应用 n目前有许多用于功能测试的自动化测试工具可 供用户使用来节省测试时间、提高测试效率。 n结合现在比较流行的JMeter这一开源的自动化 测试工具介绍一下数据库系统的性能测试。 n(1) 系统介绍 n 被测系统是一个分布式数据库系统Testbase。该 数据库采用Oracle数据库，Testbase里包括三张表，这 里仅取其中一张名为City的表来说明测试过程，表的创 建语句如下： create table City (Country varchar(20) not null, Name varchar(20) not null, Des varchar(20) not null) n(2) 测试目的 测试Testbase数据库的查询性能。 n(3) 测试工具的选择 Jmeter。 JMeter n(4) 测试步骤 n安装必要的JDBC驱动（数据生成可以使用 工具DataFactory） n准备好Jmeter测试工具 n建立测试计划 n配置与数据库的连接 n设置结果的查看方式 n用JMeter分析了Oracle数据库的查询性能 图6.4 配置数据库连接 图6.5 测试结果 6.2 压力测试（负载测试、并 发测试） 6.2.1 压力测试的基本概念 n压力测试（Stress Testing）是指模拟巨 大的工作负荷，以查看系统在峰值使用 情况下是否可以正常运行。 n压力测试是通过逐步增加系统负载来测 试系统性能的变化，并最终确定在什么 负载条件下系统性能处于失效状态，以 此来获得系统性能提供的最大服务级别 的测试。 压力测试方法具有如下特点： n（1）压力测试是检查系统处于压力情况 下的能力表现。 n比如，通过增加并发用户的数量，检测系统 的服务能力和水平；通过增加文件记录数来 检测数据处理的能力和水平等等。 n（2）压力测试一般通过模拟方法进行。 n通常在系统对内存和CPU利用率上进行模拟 ，以获得测量结果。如将压力的基准设定为 ：内存使用率达到75%以上、CPU使用率达 到75%以上，并在此观测系统响应时间、系 统有无错误产生。 n除了对内存和CPU的使用率进行设定外，数 据库的连接数量、数据库服务器的CPU利用 率等等也都可以作为压力测试的依据。 n（3）压力测试一般用于测试系统的稳定 性。 n如果一个系统能够在压力环境下稳定运行一 段时间，那么该系统在普遍的运行环境下就 应该可以达到令人满意的稳定程度。在压力 测试中，通常会考察系统在压力下是否会出 现错误等方面的问题。 压力测试与性能测试的联系与 区别： n压力测试是用来保证产品发布后系统能 否满足用户需求，关注的重点是系统整 体； n性能测试可以发生在各个测试阶段，即 使是在单元层，一个单独模块的性能也 可以进行评估。 n压力测试是通过确定一个系统的瓶颈， 来获得系统能提供的最大服务级别的测 试。 n性能测试是检测系统在一定负荷下的表 现，是正常能力的表现；而压力测试是 极端情况下的系统能力的表现。 n例如对一个网站进行测试，模拟10到50 个用户同时在线并观测系统表现，就是 在进行常规性能测试；当用户增加到系 统出项瓶颈时，如1000乃至上万个用户 时，就变成了压力测试。 压力测试和负载测试（Load Test）： n负载测试是通过逐步增加系统工作量， 测试系统能力的变化，并最终确定在满 足功能指标的情况下，系统所能承受的 最大工作量的测试。 n压力测试实质上就是一种特定类型的负 载测试。 压力测试和并发性测试： n并发性测试是一种测试手段，在压力测 试中可以利用并发测试来进行压力测试 。 6.2.2 压力测试方法 n压力测试应该尽可能逼真的模拟系统环 境。对于实时系统，测试者应该以正常 和超常的速度输入要处理的事务从而进 行压力测试。批处理的压力测试可以利 用大批量的批事务进行，被测事务中应 该包括错误条件。 压力测试中使用事务获得途径 n测试数据生成器； n由测试小组创建的测试事务； n原来在系统环境中处理过的事务。 n压力测试中应该模拟真实的运行环境。 n测试者应该使用标准文档，输入事务的人员 或者系统使用人员应该和系统产品化之后的 参与人员一样。实时系统应该测试其扩展的 时间段，批处理系统应该使用多于一个事务 的批量进行测试。 有效的压力测试将可采用以下 测试手段： n（1）重复（Repetition）测试： n重复测试就是一遍又一遍地执行某个操作或 功能，比如重复调用一个Web服务。压力测 试的一项任务就是确定在极端情况下一个操 作能否正常执行，并且能否持续不断地在每 次执行时都正常。这对于推断一个产品是否 适用于某种生产情况至关重要，客户通常会 重复使用产品。重复测试往往与其它测试手 段一并使用。 n（2）并发（Concurrency）测试： n并发是同时执行多个操作的行为，即在同一 时间执行多个测试线程。例如，在同一个服 务器上同时调用许多Web服务。并发测试原 则上不一定适用于所有产品（比如无状态服 务），但多数软件都具有某个并发行为或多 线程行为元素，这一点只能通过执行多个代 码测试用例才能得到测试结果。 n（3）量级（Magnitude）增加： n压力测试可以重复执行一个操作，但是操作 自身也要尽量给产品增加负担。例如一个 Web服务允许客户机输入一条消息，测试人 员可以通过模拟输入超长消息来使操作进行 高强度的使用，即增加这个操作的量级。这 个量级的确定总是与应用系统有关，可以通 过查找产品的可配置参数来确定量级。 n（4）随机变化： 该手段是指对上述测试手段进行随机组 合，以便获得最佳的测试效果。 随机变化 n使用重复时，在重新启动或重新连接服务之前，可以改变重 复操作间的时间间隔、重复的次数，或者也可以改变被重复 的Web服务的顺序； n使用并发时，可以改变一起执行的Web服务、同一时间运行 的Web服务数目，也可以改变关于是运行许多不同的服务还 是运行许多同样的实例的决定。 n量级测试时，每次重复测试时都可以更改应用程序中出现的 变量（例如发送各种大小的消息或数字输入值）。 n如果测试完全随机的话，因为很难一致地重现压力下的错误 ，所以一些系统使用基于一个固定随机种子的随机变化。这 样，用同一个种子，重现错误的机会就会更大。 6.2.3 压力测试执行 n可以设计压力测试用例来测试应用系统 的整体或部分能力。压力测试用例选取 可以从以下几个方面考虑： n输入待处理事务来检查是否有足够的磁盘空间； n创造极端的网络负载； n制造系统溢出条件； n当应用系统所能正常处理的工作量并不确定时 需要使用压力测试。压力测试意图通过对系统 施加超负载事务量来达到破坏系统的目的。 n压力测试和在线应用程序非常类似，因为很难 利用其他测试技术来模拟高容量的事务。 n压力测试的弱点在于准备测试的时间与在测试 的实际执行过程中所消耗的资源数量都非常庞 大。通常在应用程序投入使用之前这种消耗的 衡量是无法进行的。 【例6.4】某个电话通信系统的测试 n测试采用压力测试方法。在正常情况下，每天的电话数目大 约2000个，一天24小时服从正态分布。在系统第1年使用时， 系统的平均无故障时间大约1个月左右。分析表明，系统的出 错原因主要来源于单位时间内电话数量比较大的情况下，为 此，对系统采用压力测试，测试时将每天电话的数目增加10 倍，即20000个左右，分布采用均匀和正态两种分布，测试大 约进行了4个月，共发现了314个错误，修复这些错误大约花 费了6个月的时间，修复后的系统运行了近2年，尚未出现问 题。 6.3 容量测试 6.3.1 容量测试基本概念 n所谓的容量测试（Volume Testing）是 指，采用特定的手段测试系统能够承载 处理任务的极限值所从事的测试工作。 n这里的特定手段是指，测试人员根据实 际运行中可能出现极限，制造相对应的 任务组合，来激发系统出现极限的情况 。 n容量测试的目的 n容量测试的目的是使系统承受超额的数据容量来发 现它是否能够正确处理，通过测试，预先分析出反 映软件系统应用特征的某项指标的极限值（如最大 并发用户数、数据库记录数等），确定系统在其极 限值状态下是否还能保持主要功能正常运行。容量 测试还将确定测试对象在给定时间内能够持续处理 的最大负载或工作量。 n对软件容量的测试，能让软件开发商或用户了解该 软件系统的承载能力或提供服务的能力，如电子商 务网站所能承受的、同时进行交易或结算的在线用 户数。知道了系统的实际容量，如果不能满足设计 要求，就应该寻求新的技术解决方案，以提高系统 的容量。有了对软件负载的准确预测，不仅能对软 件系统在实际使用中的性能状况充满信心，同时也 可以帮助用户经济地规划应用系统，优化系统的部 署。 容量测试与压力测试的区别 n与容量测试十分相近的概念是压力测试。二者都是 检测系统在特定情况下，能够承担的极限值。 n然而两者的侧重点有所不同，压力测试主要是使系 统承受速度方面的超额负载，例如一个短时间之内 的吞吐量。 n容量测试关注的是数据方面的承受能力，并且它的 目的是显示系统可以处理的数据容量。 n容量测试往往应用于数据库方面的测试 n数据库容量测试使测试对象处理大量的数据，以确 定是否达到了将使软件发生故障的极限。容量测试 还将确定测试对象在给定时间内能够持续处理的最 大负载或工作量。 压力测试、容量测试和性能测 试的区别 n更确切的说，压力测试可以看作是容量测试、性能 测试和可靠性测试的一种手段，不是直接的测试目 标。 n压力测试的重点在于发现功能性测试所不易发现的 系统方面的缺陷，而容量测试和性能测试是系统测 试的主要目标内容，也就是确定软件产品或系统的 非功能性方面的质量特征，包括具体的特征值。 n容量测试和性能测试更着力于提供性能与容量方面 的数据，为软件系统部署、维护、质量改进服务， 并可以帮助市场定位、销售人员对客户的解释、广 告宣传等服务。 n压力测试、容量测试和性能测试的测试方法相通， 在实际测试工作中，往往结合起来进行以提高测试 效率。一般会设置专门的性能测试实验室完成这些 工作，即使用虚拟的手段模拟实际操作，所需要的 客户端有时还是很大，所以性能测试实验室的投资 较大。对于许多中小型软件公司，可以委托第三方 完成性能测试，可以在很大程度上降低成本。 6.3.2 容量测试方法 n进行容量测试的首要任务就是确定被测 系统数据量的极限，即容量极限。这些 数据可以是数据库所能容纳的最大值， 可以是一次处理所能允许的最大数据量 等等。系统出现问题，通常是发生在极 限数据量产生或临界产生的情况下，这 时容易造成磁盘数据的丢失、缓冲区溢 出等一些问题。 资源利用率、响应时间、用户 负载关系图 n为了更清楚的说明如何确定容量的极限 值，参看图6.6（资源利用率、响应时间 、用户负载关系图）： n图中反映了资源利用率、响应时间与用户负载之间 的关系。可以看到，用户负载增加，响应时间也缓 慢的增加，而资源利用率几乎是线形增长。这是因 为应用做更多的工作，它需要更多的资源。 n一旦资源利用率接近百分之百时，出现一个有趣的 现象，就是响应以指数曲线方式下降，这点在容量 评估中被称作为饱和点。饱和点是指所有性能指标 都不满足，随后应用发生恐慌的时间点。 n执行容量评估的目标是保证用户知道这点在哪，并 且永远不要出现这种情况。在这种负载发生前，管 理者应优化系统或者增加适当额外的硬件。 一些组合条件下的测试 n为了确定容量极限，可以进行一些组合 条件下的测试，如核实测试对象在以下 高容量条件下能否正常运行： n链接或模拟了最大（实际或实际允许）数量的客户 机。 n所有客户机在长时间内执行相同的、可能性能不稳 定的重要业务功能。 n已达到最大的数据库大小（实际的或按比例缩放的 ），而一起同时执行多个查询或报表事务。 选用不同的加载策略 n当然需要注意，不能简单地说在某一标准配置 服务器上运行某软件的容量是多少，选用不同 的加载策略可以反映不同状况下的容量。 n举个简单的例子，网上聊天室软件的容量是多少？ 在一个聊天室内有1000个用户，和100个聊天室每 个聊天室内有10个用户，同样都是1000个用户，在 性能表现上可能会出现很大的不同，在服务器端数 据输出量、传输量更是截然不同的。在更复杂的系 统内，就需要分别为多种情况提供相应的容量数据 作为参考。 6.3.3容量测试执行 n开始进行容量测试的第一步也和其他测 试工作一样，通常是获取测试需求。系 统测试需求确定测试的内容，即测试的 具体对象。 获取测试需求 n测试需求主要来源于各种需求配置项， 它可能是一个需求规格说明书，或是由 场景、用例模型、补充规约等组成的一 个集合。其中，容量测试需求来自于测 试对象的指定用户数和业务量。容量需 求通常出现在需求规格说明书中的基本 性能指标、极限数据量要求和测试环境 部分。 容量测试常用的用例设计方法 n容量测试常用的用例设计方法有规范导 出法、边界值分析、错误猜测法。 容量测试的步骤 n分析系统的外部数据源，并进行分类； n对每类数据源分析可能的容量限制，对于记录类型 数据需要分析记录长度限制，记录中每个域长度限 制和记录数量限制； n对每个类型数据源，构造大容量数据对系统进行测 试； n分析测试结果，并与期望值比较，确定目前系统的 容量瓶颈； n对系统进行优化并重复以上四步，直到系统达到期 望的容量处理能力。 常见的容量测试例子 n处理数据敏感操作时进行的相关数据比较； n使用编译器编译一个极其庞大的源程序； n使用一个链接编辑器编辑一个包含成千上万模块的 程序； n一个电路模拟器模拟包含成千上万块的电路； n一个操作系统的任务队列被充满； n一个测试形式的系统被灌输了大量文档格式； n互联网中庞大的E-mail信息和文件信息。 6.3.4 一个容量测试案例分析 n【例6.5】容量测试是用来研究程序加载非常大量的 数据时、处理很大量数据任务时的运行情况，这一 测试主要关注一次处理合理需求的大量数据，而且 在一段较长时间内高频率地重复任务。对于像银行 终端监控系统这样的产品来讲，容量测试是至关重 要的。在下面的内容中将选取一个银行系统进行容 量测试的案例进行简单的分析。 银行系统进行容量测试的案例 n首先根据某银行终端监控系统的需求说 明，作出如下分析： n服务器支持挂接100台业务前置机。 n每台前置机支持挂接200台字符终端。 n字符终端有两种登录前置机的模式，即终端服务器 模式和Telnet模式。 n不同的用户操作仅反映为请求数据量的不同。 n不同的配置包括：不同的系统版本（如SCO、 SOLARIS等），不同的shell（shell、cshell、kshell ）。 容量需求分析的策略 n对应上面五条容量需求分析，分别制定 如下策略： n对于需求1、2，挂接100台业务前置机，200台字符 终端的容量环境不可能真实地构造，这里采取虚拟 用户数量的方式，多台业务前置机采用在一台前置 机上绑定多个IP地址的方式实现，同时启动多个前 置程序。 n对于需求3可以给出两种字符终端登录前置机的模 式。 n对于需求4，不同数据量可以执行不同的shell脚本 来实现。实际上可以执行相同的脚本，而循环输出 不同字节数的文本文件内容。最后，对于不同的系 统版本，则只能逐一测试，因为谁也代替不了谁。 当然，以用户实际使用的环境为重点。 测试用例的设计 n测试工作离不开测试用例的设计。不完 全、不彻底是软件测试的致命缺陷，任 何程序只能进行少量而有限的测试。测 试用例在此情况下产生，同时它也是软 件测试系统化、工程化的产物。当明确 了测试需求和策略后，设计用例只是一 件顺水推舟的事。 怎样组合测试点 n从测试需求可以提取出许多的测试点，而测试用例则 是测试点的组合。怎样组合呢？ n可以参考这样一个原则：一个测试用例是为验证某 一个具体的需求，在一个测试场景下，进行的若干 必要操作的最小集合。也就是说，只要明确地定义 目的、场景、操作，就形成了用例的基本轮廓。再 加上不同类型测试必须的测试要素，就构成了完整 的测试用例。对于容量测试来说，测试要素无外乎 容量值、一定容量下正常工作的标准等。下面给出 一个容量测试用例模版的例子。 表6.1 容量测试用例模版 系统测试用例用例标识 用例类型容量测试 编写人 编写日期 测试目的 需求可追踪性 测试约束 测试环境 测试工具 初始化 N操作步骤及输入预期结果及通过准则 1. 2. 测试结果问题报告标识码 审核： 附注： n作为前面例子的延续，下面简单说明一 下各栏目的填法： n1）测试目的：需要验证的测试需求，如“在XXX的 容量条件下，前置程序是否能正常工作”。 n2）需求可追踪性：对应测试需求的标识号。 n3）测试约束条件：本次测试需遵循的制约条件， 如终端以终端服务器模式登录到主机。 n4）测试环境：前置程序的版本等。 n5）测试工具：来源于测试策略，如前面提到的终 端服务器模拟程序。 n6）初始化：在测试前需作的准备工作。 n7）操作步骤及输入：如终端登录，不同的数据量 操作等。 n8）预期结果及通过准则：一定容量下正常工作的 标准，如正常录像，正常压缩传送，资源占用率等 。 n对于不同的容量条件，因为测试场景不 一样，建议编写不同的用例。 n执行出了测试策略，也完成了测试用例的设计，接 下来的事就是真正的去操作，即测试执行。容量测 试执行的具体步骤与其他类型测试没有太多区别， 大致分为七步： 容量测试执行的具体步骤 n1）按用例中测试环境的描述建立测试系统； n2）准备测试过程，合理的组织用例的测试流程； n3）根据用例中“初始化”内容运行初始化过程； n4）执行测试，从终止的测试恢复； n5）验证预期结果，对应测试用例中描述的测试目 的； n6）调查突发结果，即对异常现象进行研究，适当 地进行一些回归测试； n7）记录问题报告。 6.4 健壮性测试 6.4.1 健壮性测试基本概念 健壮性测试（Robustness Testing）主要用 于测试系统抵御错误的能力。这里的错 误通常指的是由于设计缺陷而带来的系 统错误。测试的重点为当出现故障时， 是否能够自动恢复或忽略故障继续运行 。 健壮性的两层含义： n一是高可靠性，二是从错误中恢复的能力。前 者体现了软件系统的质量；后者体现了软件系 统的适应性。二者也给测试工作提出了不同的 测试要求，前者需要根据符合规格说明的数据 选择测试用例，用于检测在正常情况下系统输 出的正确性；后者需要在异常数据中选择测试 用例，检测非正常情况下的系统行为。 6.4.2 健壮性测试方法 健壮性测试可以根据以下方面评价系统的健壮性： n通过：系统调用运行输入的参数产生预期的正常结果。 n灾难性失效：这是系统健壮性测试中最严重的失效，这种失 效只有通过系统重新引导才能得到解决。 n重启失效：一个系统函数的调用没有返回，使得调用它的程 序挂起或停止。 n夭折失效：程序执行时由于异常输入，系统发出错误提示使 程序中止。 n沉寂失效：异常输入时，系统应当发出错误提示，但是测试 结果却没有发生异常。 n干扰失效：指系统异常时返回了错误的提示，但是该错误提 示不是期望中的错误。 自动化实现上述测试内容是需要把握以下原则： n可移植性：健壮性测试基准程序是用来比较不同系统的健壮 性，因此移植性是测试基准程序的基本要求。 n覆盖率：理想的基准程序能够覆盖所有的系统模块，然而这 种开销是巨大的。因此一般选取使用频度最高的模块进行测 试。 n可扩展性：可扩展性体现在当需要扩展测试集时能够前后一 致。这种可扩展性不仅指为已有模块增加测试集，还包括为 新增加的模块增加测试集。 n测试结果的记录：健壮性测试的目的是找出系统的不健壮性 因素，因此应详细的记录测试结果。 设计健壮性测试的策略 n基于错误的策略：确认所有可能的错误源，为每一类错误开 发错误注入技术； n基于覆盖率的策略：接口覆盖的数量，故障位置覆盖的数量 ，例外覆盖的数量； n基于失效的策略：用例设计故障是否被处理了，例外是否被 处理了，一个组件中的失效是否影响另一个组件； 健壮性测试用例设计方法 n在进行健壮性测试时，常用的用例设计 方法主要有三种：故障插入测试，变异 测试和错误猜测法。健壮性测试方法通 常需要构造一些不合理的输入来引诱软 件出错，如输入错误的数据类型，输入 定义域之外的数值等。 6.4.3 一个健壮性测试案例分析 n【例66】为了更清楚的让读者了解什么是健壮性测试，在 这里举个简单的例子。假如定义了两个变量X1和X2，两个变 量都有自己的取值范围，则写成如下这种形式：al，则是一个凹函数，和随、的变化情 况同样如此。 6.5.2.4 安全性测试执行 n危险和威胁分析。执行系统和它的实用环境的风险和 威胁分析。 n以一种它们可以和系统的安全性动作相比较的方式来 定义安全性需求和划分优先级。基于威胁分析，为系 统定义安全需求，最关键的安全性需求应该得到最大 程度的关注。注意，系统最弱的链接也是重要的，安 全性需求的定义是一个反复的过程。 n模拟安全行为。基于划分的安全需求的优先次序，识 别形成系统安全动作的功能和它们依赖的优先顺序。 n执行安全性测试。实用合适的证据收集和测试工具。 n估计基于证据的安全活动的可能性和影响。合计出一 个准确的结果及系统是否满足安全性需求。 6.6 可靠性测试 6.6.1 可靠性测试的基本概念 n1软件可靠性测试过程 n2描述软件可靠性的基本参数 n假设系统S投入测试或运行后，工作一段时 间t1后，软件出现错误，系统被停止并进行 修复，经过T1时间后，故障被排除，又投入 测试或运行。假设t1，t2，tn是系统正 常的工作时间，T1，T2，Tn是维护时 间，如图6.11所示。 n（1）故障率（风险函数）： 的单位是FIT，1FIT=10-9/小时。 n(2) 维修率： (3) 平均无故障时间： n(4) 平均维护时间： n(5) 有效度 n(6) 残留的缺陷数目N0：可以采用第二章叙述 的方法进行估计。 n (7) 可靠性： n【例6.8】 某个系统的使用情况如图6.12所示。 n n根据题义，n=6,t=186天=1488小时（每天8小时），T=15小时 ，则： nMTBF=248小时 n=0.004/小时 nMTTR=2.5小时 n=0.4 nA=0.99. n3测试剖面和使用剖面之间的关系 n(1) 计算准确的软件运行剖面，只有得到真实的软件运行剖 面，软件可靠性计算的结果才是真实的，否则，就会存在误 差。假设Test(D)是测试时的运行剖面，User(D)是用户使 用时的运行剖面。 n(2) 计算测试强度C，也称为压缩因子。C被定义为： n n定理6.1：设x1，x2，xn是测试期间的n个 无故障时间间隔，测试剖面等于使用剖面，即 Test (D)= User (D)，则： n定理6.2：假设软件有n功能或模块，实际 使用时每个模块被执行的概率分别为p1， p2，pn，均匀分布测试M小时，相当 于按使用剖面测试了 小时。 n定理6.3：假设软件有n功能，实际使用时每个 功能被执行的概率分别为p1，p2，pn， 测试期间假设的每个功能被执行的概率分别为 ：p1，p2，pn，令： 则x越大，测试时估计的可靠性就越不准确。 反之，亦然。 6.6.2 软件的运行剖面 n1运行剖面的概念及意义 n定义6.1：软件的运行剖面：设D是软件S的 定义域，D=d1，d2，dn，P(di)是di 的发生的概率，则运行剖面被定义为： (d1 ,P(d1), (d2 ,P(d2), (dn ,P(dn)。 n软件测试与软件可靠性的评估离不开软件的运行剖面 。软件S的运行剖面是指软件输入空间D以及D中的点 取值的分布，也就是说，D中每个点取值的概率（一 般，将D及D的分布称为运行剖面）。显然，如果 dD，若S（d ）是正确的，则S的正确运行的概率为 1，即P（S）=1。假设D=D1D2，D1是S正确运行的 概率，D2是S产生错误的概率。在均匀分布假设下，S 正确运行的概率为： n2获取运行剖面的步骤 构件软件的运行剖面要经过的 五个步骤 n3获取运行剖面的一般描述 n从软件到运行剖面的求解过程可用图6.14的网络模型派描述 。在该图中，每个箭头代表了从上一级剖面的某个元素到下 一级剖面的某个元素的转换概率。nx代表不同剖面中结点的 个数。 n用代表第i层从结点j到结点k之间的转换概率。i=0，表示从 软件到客户层，此时，Wjk用来Wk表示。因此Rk间可以表 示为： n 6.6.3软件可靠性模型 n6.6.3.1 概述 n1软件可靠性建模的基本思想 软件可靠性建模的基本思想是：在测试t时 间内，共发现n个故障，假设每个故障发现 的时刻分别为t1，t2，tn。或者在n固 定的时间周期T内，所发现的故障数目分别 是f1，f2，fn。根据上述假设，建立软 件可靠性模型。通过此模型可以预测软件可 靠性的未来行为。 n软件可靠性建模的基本假设是： n软件的运行剖面与可靠性测试剖面一致。 n一旦发现错误，则立刻修正，并不引入新的 错误。 n错误被查出、失效是独立的。 n每个错误被发现的概率相等。 nM(t)：软件失效数目函数，即到t时刻软 件的失效数目。 nu(t)：M(t)的均值函数，u(t)=EM(t)。 nF(t)：错误的累积分布函数， 。 nf(t)：错误的失效密度函数， 。 nZ(t)：危险率函数， 。 n2软件可靠性模型分类 nMusa和Okumoto于1983年提出了软件可靠性模 型的一种分类模式，这种模式将软件可靠性模型分 为下列五类： n时间域：日历或执行（CPU或处理器）时间。 n类别：在无限时间内发生的失效数是有限的还是无限的。 n类型：到指定时间发生的失效分布， n类：失效强度的函数形式（只适用于类别是有限失效）。 n族：失效强度预期出现的失效数的函数形式（只适用于类 别是无限失效）。 n3建立软件可靠性模型方法 n建立软件可靠性模型的步骤包括四部分： n（1）模型的假设：根据经验、现有模型和其它相关因素对 M(t)、u(t)、F(t)、f(t)、Z(t)等之一的假设。这个假设是至关 重要的，它后面三个部分起决定性的作用。 n（2）模型的形式：根据（1）模型的假设，推导出其它函数 的形式。 n（3）参数估计：根据模型的形式，估计模型中的参数。参数 的估计方法有极大似然估计法、最小二乘法等。 n（4）实践检验：应用工程软件的可靠性数据，检验所估计参 数的正确度。 6.6.3.2 指数失效时间模型 n此类模型的特点是： n失效强度函数都是为指数的有限失效模型； n单个缺陷是常数危险率Z(t)=； n第i个缺陷被检测出来后，危险率函数是剩余缺 陷的函数，即Z(t)=f(N-(i-1)； n失效强度函数为指数形式，即： Jelinski_Moranda模型 n(1)基本假设 n软件中初始缺陷个数是一个未知常数N； n错误检测率与软件中存在的缺陷数目成正比，比例常数 假设为。 n(2)模型形式 nJelinski_Moranda模型假设失效时间间隔xi是与软件中仍 存在的缺陷数目N-（i-1）成正比，并把这个值作为参数 的指数分布，因此，P（ti）是关于ti的密度函数，则： 由假设可以导出： n(3)参数估计 n由P（ti）可得似然函数： n对上述方程采用极大似然估计法对N和进行估计，可得方程： n解这个方程，即可得到N和。 2非均匀泊松过程（NHPP）模型 n在该模型中，N(t)代表到t时刻为止发现 的累积缺陷数目，u(0)=0，u()=N（N 是一个未知常数）。 n（1）基本假设 n到时刻t的累积失效数M(t)满足均值函数为 u(t)的泊松过程。 n任意时间间隔t到t内的期望发现的缺陷数 目与软件中的缺陷数目成正比，比例常数假 设为b。 n在(0,t1),(t1,t2) ,，(tn ,tn)内检测的缺陷 数目f1，f2，fn相互独立。 n（2）模型形式 n（3）参数估计 n1）fi=1(i=1,2,n)。则时间t的联合密度函数为： n对上述方程采用极大似然估计法对N和 b进行估计，可得方程 ： n2）fi是任意的。则fi的联合密度函数为： n对上述方程采用极大似然估计法对N和 b进行估计，可得方程 ： n【例6.17】 对【例6.16】中（1）的数据计 算可得： n对【例6.16】中（2）的数据计算可得： 3Schneidewind模型 n该模型的基本思想是：现时缺陷率能够比以前 观测的缺陷率更好的预测未来。假设有n个等 长的观测时间单元，Schneidewind给出了三个 模型： n模型1：利用n个周期中的所有错误计数。 n模型2：只考虑从周期s到n之间的n-s+1个周期的数 据。 n模型3：使用从周期1到s-1的累积错误计数，作为首 选数据点，而使用从周期s到n的独立错误计数作为 辅助数据点。 n（1）模型假设 n1）到时刻t的累积失效数M(t)满足均值函数为u(t) 的泊松过程。从均值函数可以看出任意周期期望的 缺陷数目与此周期期望的未检测的缺陷数目成正比 。假设u(t)是一个有界非减函数，且对于参量， ，有： n2）假设失效强度: n（2）模型形式 n第i个时期期望的缺陷数目为： n（3）参数估计 n用fi作为独立非均匀泊松随机变量，则联合密度函 数为： nMs-1是区间1到s-1的平均累积错误计数，Fs-1是区 间1到s-1的累积错误计数 n模型1： n模型2： n模型3： nSchneidewind定义了三种评价标准，根据此标准，可 以计算其最小或较小误差，由此决定s的取值。 4Musa模型 n（1）基本假设： n到时刻t的累积失效数M(t)满足均值函数为 的泊松过程。 n（2）模型形式 n因为 故 n（3）参数估计 n假设系统已检测了n个缺陷，且最后一次失 效时间tn以来，在时间x内未发现其它缺陷 ，则此模型的联合密度函数为： n因此，参数估计为： n【例6.18】假设x=20，对【例6.16】中 （1）的数据计算可得： 5其它模型 n指数类失效模型还有其它变种的形式。 n（1）超指数模型：Ohba、Yamada、saki和 Laprie等人在Musa模型的基础上，提出了超指数 模型，这种模型根据软件的性质将其分为K个不 同的部分，而每个部分满足具有不同参数的指数 分布，即： n（2）S_型软件可靠性增长模型。Ohba于1984年 提出了此模型，定义其均值函数为： n扩展执行时间模型：Everett于1992年提出了此模型 ，模型的均值函数为： n指数模型的基本假设是 6.6.3.3 Weibull和Gamma失效时间模型 n在此类模型中，每个错误的失效分布分 别为Weibull分布和Gamma分布，而不是 上节论述的指数分布。 Weibull分布模型 n（1）基本假设 n1）软件初始的缺陷数目为N； n2）导致缺陷发生的时间记为T，T满足 Weibull分布，且参数为和，即T的密度函数 为： n 3）每一个单独的时间间隔区间(0,t1)， (t1,t2),(ti-1,ti),(tn-1,tn)内的缺陷数目分别 为f1，f2，fn，该采样是独立的。 n（2）模型形式 n(3)参数估计 n采用最小二乘法，从累积分布函数可得： Y=x+b 其中： S型可靠性增长模型 n（1）基本假设 n1）到时刻t的累积失效数M(t)满足均值函数 为的泊松过程。 n2）第i-1次失效到第i次失效的时间间隔依赖 于到第i-1次失效的时间。 n（2）模型形式 n在ti+t时刻函数的可靠性函数和危险率函数为： n定义li=ti-ti-1，则i个时间间隔的期望错误数目为： n n（3）参数估计 n在给定划分上的联合密度函数为： n因此参数估计为： n【例6.20】 对【例6.16】中（1）的数 据计算可得 6.6.3.4 无限失效类模型 n1Duane模型 n（1）基本假设：到时刻t的累积失效数M(t)满足 均值函数为的泊松过程。 n（2）模型形式 n（3）参数估计 n采用极大似然估计法，得： n2几何模型 该模型的基本思想是：失效时间间隔是一种指 数分布，其均值以几何形式下降。 n（1）基本假设 n z(t)=Di-1，01，ti-1tti。 n 失效时间间隔是一种指数分布。 n（2）模型形式 n根据假设，第i-1次和第i次失效间的时间间隔密度为 指数形式： n利用： n可得： n n（3）参数估计 nXi联合密度函数为: n采用极大似然估计法，得： 3Musa_Okumoto对数泊松模型 n（1）基本假设 n随的递减而呈指数递减，即： nM(t)符合泊松分布过程。 n2）模型形式 n根据假设，可得： n令： nMusa曾经证明： n（3）参数估计 6.6.3.5 Bayes模型 nLV模型是Bayes模型的代表。Littlewood 和Verrall于1973年提出了该模型。 n（1）基本假设 nXi被假设为i的独立指数随机变量。 ni满足参数为和(i)的分布。 n（2）模型形式 nLittlewood和Verrall指出，Ti有着以Zi为条件的指数分布，即： nZi被假定为一个随机变量，服从标参为(i)，形参为的的分布。于是有： n nLittlewood和Verrall假设，(i)=0+1i， (i)=0+1i2，则： n（3）参数估计 n采用极大似然法，可得： 6.7 恢复性测试与备份测试 n恢复性测试主要检查系统的容错能力。 当系统出错时，能否在指定时间间隔内 修正错误并重新启动系统。 n备份测试是恢复性测试的一个补充，也 是恢复性测试的一个部分。备份测试的 目的是验证系统在软件或者硬件失败时 备份数据的能力。 n在设计恢复性测试用例时，需要考虑下面这些 关键问题： n(1) 测试是否存在潜在的灾难，以及它们可能造成 的损失？消防训练式的布置灾难场景是一种有效的 方法。 n(2) 保护和恢复工作是否为灾难提供了足够的准备 ？评审人员应该评审测试工作及测试步骤，以便检 查对灾难的准备情况。评审人员包括主要事件专家 和系统用户。 n(3) 当真正需要时，恢复过程是否能够正常工作？ 模拟的灾难需要和实际的系统一起被创建以验证恢 复过程。用户、供应商应当共同完成测试工作。 n备份测试需要从以下几个角度来进行设计： n备份文件，并且比较备份文件与最初的文件的区别 ； n存储文件和数据； n完善系统备份工作的步骤； n检查点数据备份； n备份引起系统性能衰减程度； n手工备份的有效性； n系统备份“触发器”的检测； n备份期间的安全性； n备份过程日志。 6.8 协议一致性测试 n在计算机网络的发展历程中，协议一直处于核心地位，它是计算机网络 和分布式系统中各种通信实体之间相互交换信息所必须遵守的一组规则 。1984年国际标准化组织ISO提出了开放式系统互连ISO/OSI参考模型。 1993年1月1日TCP/IP被宣布为Internet上唯一正式的协议，为Internet的 发展铺平了道路。 n协议软件作为软件的一种特殊形式，自20世纪80年代以来，其开发和检 测方法已经得到快速的发展，并形成了一个崭新的学科协议工程学 ，它的研究范围包括协议说明（Protocol Specification）、协议证实（ Protocol Validation）、协议验证（Protocol Verification）、协议综合（ Protocol Synthesis）、协议转换（Protocol Conversion）、协议性能分 析（Protocol Performance Analysis）、协议自动实现（Protocol Automatic Implementation）和协议测试（Protocol Testing）。 6.8.1 协议一致性测试基本概念 n 协议测试是在软件测试的基础上发展起来的。根据对被测软件的控 制观察方式，软件测试方法分为三种：白盒测试、黑盒测试和灰盒测 试。协议测试是一种黑盒测试，它按照协议标准，通过控制观察被测 协议实现的外部行为对其进行评价。 n 目前协议测试分成三个方面进行研究：一致性测试（Conformance Testing）、互操作性测试（Interoperability Testing）和性能测试（ Performance Testing）。一致性测试主要测试协议实现是否严格遵循 相应的协议描述；互操作性测试关注的是对于同一个协议标准，不同 协议实现之间的互连通问题。性能测试是用实验的方法来观测被测协 议实现的各种性能参数，如吞吐量和传输延迟等等，其结果往往与输 入负载有关。 n在上述三个方面，一致性测试开展最早，也形成了很多有价值 的成果。1991年国际标准化组织ISO制订的国际标准ISO9646， 即OSI协议一致性测试的方法和框架，用自然语言描述了基于 OSI七层参考模型的协议测试过程、概念和方法。 n目前，国际协议测试研究领域已经取得了以下两点共识： 第一，理顺了协议一致性测试的过程； 第二，将形式化技术引入了协议测试领域，力图用严格的数学 语言清晰、无二义性地研究协议测试的概念和方法。但是也发 现这种方法存在着很多不足，其中最明显的就是这些理论研究 与实际应用之间还存在着巨大的差距。 6.8.2 协议一致性测试方法 n 国际标准化组织OSI/ITU针对协议一致性测试需求， 颁布了协议一致性测试基本框架和方法，该标准（ ISO/IEC 9646 ITU X.290 series）由五大部分构成，树 表描述语言（Tree Tabular Combine Notation）是其中 的第三部分，即ISO/IEC 9646-3。该标准的颁布为通讯 协议的一致性测试提供了准则，所以TTCN得到了广泛 的应用。下面分别介绍协议一致性测试框架、协议一致 性测试标准方法以及TTCN的执行过程。 6.8.2.1 协议一致性测试基本框架 n在一致性测试中一个被测试部分（Implement Under Test，简称 IUT）是一个OSI协议实体，IUT所在的系统称为被测试系统（ System Under Test，简称SUT）。一个概念上的一致性测试体系 结构如图6.16所示。 n IUT有一个上层测试（Upper Test）接口和下层测试（Low Test） 接口，UT和LT通过控制观察点（Points of Control and Observation， 简称PCOs）对系统进行测试。通常LT是远程可访问接口，因此IUT定 义一个远端的PCO，即底层接口被设置在远端。通信被认为是异步通 信，所以在每一个PCO都对应两个队列（FIFO），一个是输入，另一 个是输出。在一致性测试方法框架（Conformance Testing Methodology Framework，简称CTMF）中，严格区分上层测试和下 层测试功能，IUT的上层测试由UT控制，下层测试由LT控制。在测试 过程中，UT扮演一个用户来使用IUT提供的功能，而LT模仿一个IUT 下层的通信实体。也就说UT与IUT的交互是通过LT来实现的。 n IUT和UT之间通过抽象服务元语（Abstract Service Primitives ，简称ASPs）进行通信。从概念角度，IUT和LT通过协议数据单 元（Protocol Data Units，简称PDUs）交换数据；从实际角度， PDUs采用ASPs对基本服务动作进行编码，即PDUs不是直接进行 交互，而是CTMF 允许根据PDUs的编码进行交互，即在一个抽象 的测试中使用PDUs进行交换，所以ASPs与PDUs不再加以区分。 n 正如图6.16所示，测试协调过程（Test Coordination Procedures，简称TCP）来协调LT和UT的动作，这在LT和UT是两 个独立的过程时十分必要。图6.16仅表现了一致性测试方法框架 （CTMF）的概念结构，实际中的测试系统可根据采用的测试方法 的不同有相应的变化。在CTMF中测试方法可分为局部的、分布的 、协调的和远程的测试几种。它们的主要不同是对LT和UT的协调 以及对它们的控制与观察程度不同 n 图6.17是一个基于CTMF的测试过程。一个IUT首先由测试例的触 发条件激活，并从稳定状态进入被测试状态；经过测试用例在测试体 中运行，进入结束状态；如果执行的结果不唯一，则需要经检查步分 析结果中存在的问题，从而进入End State（Verification）状态；根据 检查结果提出反馈，进入下一次的测试阶段。在上面的测试过程中， 如果测试例的结束状态相同，则直接进入到下一次测试过程。 6.8.2.2 协议一致性测试标准 n 为了测试IUT，需要建立一个仿真测试事件集合或交互 行动序列。这个用于描述测试任务的事件或行动的序列称 为测试例（test case），一个特定协议的测试例集合称为测 试套。 n TTCN就是一种用于说明测试例的符号集，它可以建立 一个实际被测系统的抽象模型，并说明测试例的执行过程 。抽象的测试例包括所有的IUT所支持的被测