软件测试性能测试.ppt

6.1 性能测试,6.1.1 性能测试的基本概念,性能测试主要检验软件是否达到需求规格说明书中规定的各类性能指标，并满足一些性能相关的约束和限制条件。,性能测试包括以下几个方面：,评估系统的能力。测试中得到的负荷和响应时间等数据可以被用于验证所计划的模型的能力，并帮助做出决策。识别系统中的弱点。受控的负荷可以被增加到一个极端的水平并突破它，从而修复系统的瓶颈或薄弱的地方。系统调优。重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能，检测软件中的问题。,6.1.2 性能测试方法,基准法性能测试的基准大体有以下几方面：响应时间 从应用系统发出请求开始，到客户端接收到最后一个字节数据为止所消耗的时间。合理的响应时间取决于实际的用户需求。并发用户数 一般是指同一时间段内访问系统的用户数量。吞吐量 指单位时间内系统处理的客户请求数量。性能计数器 描述服务器或操作系统性能的一些数据指标，比如Windows系统资源管理器。,6.1.2 性能测试执行,分为三个阶段：1计划阶段2测试阶段3分析阶段,计划阶段,定义目标并设置期望值收集系统和测试要求定义工作负载选择要收集的性能度量值标出要运行的测试并决定什么时候运行它们决定工具选项和生成负载编写测试计划，设计用户场景并创建测试脚本,测试阶段,做准备工作（如建立测试服务器或布置其他设备）运行测试收集数据,分析阶段,分析结果改变系统以优化性能设计新的测试,6.1.3 性能测试案例分析,一个数据库应用系统性能测试的具体应用 目前有许多用于功能测试的自动化测试工具可供用户使用来节省测试时间、提高测试效率。结合现在比较流行的JMeter这一开源的自动化测试工具介绍一下数据库系统的性能测试。,(1)系统介绍 被测系统是一个分布式数据库系统Testbase。该数据库采用Oracle数据库，Testbase里包括三张表，这里仅取其中一张名为City的表来说明测试过程，表的创建语句如下：create table City(Country varchar(20)not null,Name varchar(20)not null,Des varchar(20)not null),(2)测试目的 测试Testbase数据库的查询性能。(3)测试工具的选择 Jmeter。,JMeter,(4)测试步骤安装必要的JDBC驱动（数据生成可以使用工具DataFactory）准备好Jmeter测试工具建立测试计划配置与数据库的连接设置结果的查看方式用JMeter分析了Oracle数据库的查询性能,图6.4 配置数据库连接,图6.5 测试结果,6.2 压力测试（负载测试、并发测试）,6.2.1 压力测试的基本概念,压力测试（Stress Testing）是指模拟巨大的工作负荷，以查看系统在峰值使用情况下是否可以正常运行。压力测试是通过逐步增加系统负载来测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，以此来获得系统性能提供的最大服务级别的测试。,压力测试方法具有如下特点：,（1）压力测试是检查系统处于压力情况下的能力表现。比如，通过增加并发用户的数量，检测系统的服务能力和水平；通过增加文件记录数来检测数据处理的能力和水平等等。,（2）压力测试一般通过模拟方法进行。通常在系统对内存和CPU利用率上进行模拟，以获得测量结果。如将压力的基准设定为：内存使用率达到75%以上、CPU使用率达到75%以上，并在此观测系统响应时间、系统有无错误产生。除了对内存和CPU的使用率进行设定外，数据库的连接数量、数据库服务器的CPU利用率等等也都可以作为压力测试的依据。,（3）压力测试一般用于测试系统的稳定性。如果一个系统能够在压力环境下稳定运行一段时间，那么该系统在普遍的运行环境下就应该可以达到令人满意的稳定程度。在压力测试中，通常会考察系统在压力下是否会出现错误等方面的问题。,压力测试与性能测试的联系与区别：,压力测试是用来保证产品发布后系统能否满足用户需求，关注的重点是系统整体；性能测试可以发生在各个测试阶段，即使是在单元层，一个单独模块的性能也可以进行评估。,压力测试是通过确定一个系统的瓶颈，来获得系统能提供的最大服务级别的测试。性能测试是检测系统在一定负荷下的表现，是正常能力的表现；而压力测试是极端情况下的系统能力的表现。,例如对一个网站进行测试，模拟10到50个用户同时在线并观测系统表现，就是在进行常规性能测试；当用户增加到系统出项瓶颈时，如1000乃至上万个用户时，就变成了压力测试。,压力测试和负载测试（Load Test）：,负载测试是通过逐步增加系统工作量，测试系统能力的变化，并最终确定在满足功能指标的情况下，系统所能承受的最大工作量的测试。压力测试实质上就是一种特定类型的负载测试。,压力测试和并发性测试：,并发性测试是一种测试手段，在压力测试中可以利用并发测试来进行压力测试。,6.2.2 压力测试方法,压力测试应该尽可能逼真的模拟系统环境。对于实时系统，测试者应该以正常和超常的速度输入要处理的事务从而进行压力测试。批处理的压力测试可以利用大批量的批事务进行，被测事务中应该包括错误条件。,压力测试中使用事务获得途径,测试数据生成器；由测试小组创建的测试事务；原来在系统环境中处理过的事务。,压力测试中应该模拟真实的运行环境。测试者应该使用标准文档，输入事务的人员或者系统使用人员应该和系统产品化之后的参与人员一样。实时系统应该测试其扩展的时间段，批处理系统应该使用多于一个事务的批量进行测试。,有效的压力测试将可采用以下测试手段：,（1）重复（Repetition）测试：重复测试就是一遍又一遍地执行某个操作或功能，比如重复调用一个Web服务。压力测试的一项任务就是确定在极端情况下一个操作能否正常执行，并且能否持续不断地在每次执行时都正常。这对于推断一个产品是否适用于某种生产情况至关重要，客户通常会重复使用产品。重复测试往往与其它测试手段一并使用。,（2）并发（Concurrency）测试：并发是同时执行多个操作的行为，即在同一时间执行多个测试线程。例如，在同一个服务器上同时调用许多Web服务。并发测试原则上不一定适用于所有产品（比如无状态服务），但多数软件都具有某个并发行为或多线程行为元素，这一点只能通过执行多个代码测试用例才能得到测试结果。,（3）量级（Magnitude）增加：压力测试可以重复执行一个操作，但是操作自身也要尽量给产品增加负担。例如一个Web服务允许客户机输入一条消息，测试人员可以通过模拟输入超长消息来使操作进行高强度的使用，即增加这个操作的量级。这个量级的确定总是与应用系统有关，可以通过查找产品的可配置参数来确定量级。,（4）随机变化：该手段是指对上述测试手段进行随机组合，以便获得最佳的测试效果。,随机变化,使用重复时，在重新启动或重新连接服务之前，可以改变重复操作间的时间间隔、重复的次数，或者也可以改变被重复的Web服务的顺序；使用并发时，可以改变一起执行的Web服务、同一时间运行的Web服务数目，也可以改变关于是运行许多不同的服务还是运行许多同样的实例的决定。,随机变化,量级测试时，每次重复测试时都可以更改应用程序中出现的变量（例如发送各种大小的消息或数字输入值）。如果测试完全随机的话，因为很难一致地重现压力下的错误，所以一些系统使用基于一个固定随机种子的随机变化。这样，用同一个种子，重现错误的机会就会更大。,6.2.3 压力测试执行,可以设计压力测试用例来测试应用系统的整体或部分能力。压力测试用例选取可以从以下几个方面考虑：输入待处理事务来检查是否有足够的磁盘空间；创造极端的网络负载；制造系统溢出条件；,当应用系统所能正常处理的工作量并不确定时需要使用压力测试。压力测试意图通过对系统施加超负载事务量来达到破坏系统的目的。压力测试和在线应用程序非常类似，因为很难利用其他测试技术来模拟高容量的事务。压力测试的弱点在于准备测试的时间与在测试的实际执行过程中所消耗的资源数量都非常庞大。通常在应用程序投入使用之前这种消耗的衡量是无法进行的。,【例6.4】某个电话通信系统的测试,测试采用压力测试方法。在正常情况下，每天的电话数目大约2000个，一天24小时服从正态分布。在系统第1年使用时，系统的平均无故障时间大约1个月左右。分析表明，系统的出错原因主要来源于单位时间内电话数量比较大的情况下，为此，对系统采用压力测试，测试时将每天电话的数目增加10倍，即20000个左右，分布采用均匀和正态两种分布，测试大约进行了4个月，共发现了314个错误，修复这些错误大约花费了6个月的时间，修复后的系统运行了近2年，尚未出现问题。,6.3 容量测试,6.3.1 容量测试基本概念,所谓的容量测试（Volume Testing）是指，采用特定的手段测试系统能够承载处理任务的极限值所从事的测试工作。这里的特定手段是指，测试人员根据实际运行中可能出现极限，制造相对应的任务组合，来激发系统出现极限的情况。,容量测试的目的容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理，通过测试，预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），确定系统在其极限值状态下是否还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。,对软件容量的测试，能让软件开发商或用户了解该软件系统的承载能力或提供服务的能力，如电子商务网站所能承受的、同时进行交易或结算的在线用户数。知道了系统的实际容量，如果不能满足设计要求，就应该寻求新的技术解决方案，以提高系统的容量。有了对软件负载的准确预测，不仅能对软件系统在实际使用中的性能状况充满信心，同时也可以帮助用户经济地规划应用系统，优化系统的部署。,容量测试与压力测试的区别,与容量测试十分相近的概念是压力测试。二者都是检测系统在特定情况下，能够承担的极限值。然而两者的侧重点有所不同，压力测试主要是使系统承受速度方面的超额负载，例如一个短时间之内的吞吐量。容量测试关注的是数据方面的承受能力，并且它的目的是显示系统可以处理的数据容量。,容量测试往往应用于数据库方面的测试数据库容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。,压力测试、容量测试和性能测试的区别,更确切的说，压力测试可以看作是容量测试、性能测试和可靠性测试的一种手段，不是直接的测试目标。压力测试的重点在于发现功能性测试所不易发现的系统方面的缺陷，而容量测试和性能测试是系统测试的主要目标内容，也就是确定软件产品或系统的非功能性方面的质量特征，包括具体的特征值。容量测试和性能测试更着力于提供性能与容量方面的数据，为软件系统部署、维护、质量改进服务，并可以帮助市场定位、销售人员对客户的解释、广告宣传等服务。,压力测试、容量测试和性能测试的测试方法相通，在实际测试工作中，往往结合起来进行以提高测试效率。一般会设置专门的性能测试实验室完成这些工作，即使用虚拟的手段模拟实际操作，所需要的客户端有时还是很大，所以性能测试实验室的投资较大。对于许多中小型软件公司，可以委托第三方完成性能测试，可以在很大程度上降低成本。,6.3.2 容量测试方法,进行容量测试的首要任务就是确定被测系统数据量的极限，即容量极限。这些数据可以是数据库所能容纳的最大值，可以是一次处理所能允许的最大数据量等等。系统出现问题，通常是发生在极限数据量产生或临界产生的情况下，这时容易造成磁盘数据的丢失、缓冲区溢出等一些问题。,资源利用率、响应时间、用户负载关系图,为了更清楚的说明如何确定容量的极限值，参看图6.6（资源利用率、响应时间、用户负载关系图）：,图中反映了资源利用率、响应时间与用户负载之间的关系。可以看到，用户负载增加，响应时间也缓慢的增加，而资源利用率几乎是线形增长。这是因为应用做更多的工作，它需要更多的资源。一旦资源利用率接近百分之百时，出现一个有趣的现象，就是响应以指数曲线方式下降，这点在容量评估中被称作为饱和点。饱和点是指所有性能指标都不满足，随后应用发生恐慌的时间点。执行容量评估的目标是保证用户知道这点在哪，并且永远不要出现这种情况。在这种负载发生前，管理者应优化系统或者增加适当额外的硬件。,一些组合条件下的测试,为了确定容量极限，可以进行一些组合条件下的测试，如核实测试对象在以下高容量条件下能否正常运行：链接或模拟了最大（实际或实际允许）数量的客户机。所有客户机在长时间内执行相同的、可能性能不稳定的重要业务功能。已达到最大的数据库大小（实际的或按比例缩放的），而一起同时执行多个查询或报表事务。,选用不同的加载策略,当然需要注意，不能简单地说在某一标准配置服务器上运行某软件的容量是多少，选用不同的加载策略可以反映不同状况下的容量。举个简单的例子，网上聊天室软件的容量是多少？在一个聊天室内有1000个用户，和100个聊天室每个聊天室内有10个用户，同样都是1000个用户，在性能表现上可能会出现很大的不同，在服务器端数据输出量、传输量更是截然不同的。在更复杂的系统内，就需要分别为多种情况提供相应的容量数据作为参考。,容量测试执行,开始进行容量测试的第一步也和其他测试工作一样，通常是获取测试需求。系统测试需求确定测试的内容，即测试的具体对象。,获取测试需求,测试需求主要来源于各种需求配置项，它可能是一个需求规格说明书，或是由场景、用例模型、补充规约等组成的一个集合。其中，容量测试需求来自于测试对象的指定用户数和业务量。容量需求通常出现在需求规格说明书中的基本性能指标、极限数据量要求和测试环境部分。,容量测试常用的用例设计方法,容量测试常用的用例设计方法有规范导出法、边界值分析、错误猜测法。,容量测试的步骤,分析系统的外部数据源，并进行分类；对每类数据源分析可能的容量限制，对于记录类型数据需要分析记录长度限制，记录中每个域长度限制和记录数量限制；对每个类型数据源，构造大容量数据对系统进行测试；分析测试结果，并与期望值比较，确定目前系统的容量瓶颈；对系统进行优化并重复以上四步，直到系统达到期望的容量处理能力。,常见的容量测试例子,处理数据敏感操作时进行的相关数据比较；使用编译器编译一个极其庞大的源程序；使用一个链接编辑器编辑一个包含成千上万模块的程序；一个电路模拟器模拟包含成千上万块的电路；一个操作系统的任务队列被充满；一个测试形式的系统被灌输了大量文档格式；互联网中庞大的E-mail信息和文件信息。,6.3.4 一个容量测试案例分析,【例6.5】容量测试是用来研究程序加载非常大量的数据时、处理很大量数据任务时的运行情况，这一测试主要关注一次处理合理需求的大量数据，而且在一段较长时间内高频率地重复任务。对于像银行终端监控系统这样的产品来讲，容量测试是至关重要的。在下面的内容中将选取一个银行系统进行容量测试的案例进行简单的分析。,银行系统进行容量测试的案例,首先根据某银行终端监控系统的需求说明，作出如下分析：服务器支持挂接100台业务前置机。每台前置机支持挂接200台字符终端。字符终端有两种登录前置机的模式，即终端服务器模式和Telnet模式。不同的用户操作仅反映为请求数据量的不同。不同的配置包括：不同的系统版本（如SCO、SOLARIS等），不同的shell（shell、cshell、kshell）。,容量需求分析的策略,对应上面五条容量需求分析，分别制定如下策略：对于需求1、2，挂接100台业务前置机，200台字符终端的容量环境不可能真实地构造，这里采取虚拟用户数量的方式，多台业务前置机采用在一台前置机上绑定多个IP地址的方式实现，同时启动多个前置程序。,对于需求3可以给出两种字符终端登录前置机的模式。对于需求4，不同数据量可以执行不同的shell脚本来实现。实际上可以执行相同的脚本，而循环输出不同字节数的文本文件内容。最后，对于不同的系统版本，则只能逐一测试，因为谁也代替不了谁。当然，以用户实际使用的环境为重点。,测试用例的设计,测试工作离不开测试用例的设计。不完全、不彻底是软件测试的致命缺陷，任何程序只能进行少量而有限的测试。测试用例在此情况下产生，同时它也是软件测试系统化、工程化的产物。当明确了测试需求和策略后，设计用例只是一件顺水推舟的事。,怎样组合测试点,从测试需求可以提取出许多的测试点，而测试用例则是测试点的组合。怎样组合呢？可以参考这样一个原则：一个测试用例是为验证某一个具体的需求，在一个测试场景下，进行的若干必要操作的最小集合。也就是说，只要明确地定义目的、场景、操作，就形成了用例的基本轮廓。再加上不同类型测试必须的测试要素，就构成了完整的测试用例。对于容量测试来说，测试要素无外乎容量值、一定容量下正常工作的标准等。下面给出一个容量测试用例模版的例子。,表6.1 容量测试用例模版,作为前面例子的延续，下面简单说明一下各栏目的填法：1）测试目的：需要验证的测试需求，如“在XXX的容量条件下，前置程序是否能正常工作”。2）需求可追踪性：对应测试需求的标识号。3）测试约束条件：本次测试需遵循的制约条件，如终端以终端服务器模式登录到主机。4）测试环境：前置程序的版本等。,5）测试工具：来源于测试策略，如前面提到的终端服务器模拟程序。6）初始化：在测试前需作的准备工作。7）操作步骤及输入：如终端登录，不同的数据量操作等。8）预期结果及通过准则：一定容量下正常工作的标准，如正常录像，正常压缩传送，资源占用率等。,对于不同的容量条件，因为测试场景不一样，建议编写不同的用例。执行出了测试策略，也完成了测试用例的设计，接下来的事就是真正的去操作，即测试执行。容量测试执行的具体步骤与其他类型测试没有太多区别，大致分为七步：,容量测试执行的具体步骤,1）按用例中测试环境的描述建立测试系统；2）准备测试过程，合理的组织用例的测试流程；3）根据用例中“初始化”内容运行初始化过程；4）执行测试，从终止的测试恢复；5）验证预期结果，对应测试用例中描述的测试目的；6）调查突发结果，即对异常现象进行研究，适当地进行一些回归测试；7）记录问题报告。,6.4 健壮性测试,6.4.1 健壮性测试基本概念,健壮性测试（Robustness Testing）主要用于测试系统抵御错误的能力。这里的错误通常指的是由于设计缺陷而带来的系统错误。测试的重点为当出现故障时，是否能够自动恢复或忽略故障继续运行。,健壮性的两层含义：,一是高可靠性，二是从错误中恢复的能力。前者体现了软件系统的质量；后者体现了软件系统的适应性。二者也给测试工作提出了不同的测试要求，前者需要根据符合规格说明的数据选择测试用例，用于检测在正常情况下系统输出的正确性；后者需要在异常数据中选择测试用例，检测非正常情况下的系统行为。,6.4.2 健壮性测试方法,健壮性测试可以根据以下方面评价系统的健壮性：通过：系统调用运行输入的参数产生预期的正常结果。灾难性失效：这是系统健壮性测试中最严重的失效，这种失效只有通过系统重新引导才能得到解决。重启失效：一个系统函数的调用没有返回，使得调用它的程序挂起或停止。夭折失效：程序执行时由于异常输入，系统发出错误提示使程序中止。沉寂失效：异常输入时，系统应当发出错误提示，但是测试结果却没有发生异常。干扰失效：指系统异常时返回了错误的提示，但是该错误提示不是期望中的错误。,自动化实现上述测试内容是需要把握以下原则：可移植性：健壮性测试基准程序是用来比较不同系统的健壮性，因此移植性是测试基准程序的基本要求。覆盖率：理想的基准程序能够覆盖所有的系统模块，然而这种开销是巨大的。因此一般选取使用频度最高的模块进行测试。可扩展性：可扩展性体现在当需要扩展测试集时能够前后一致。这种可扩展性不仅指为已有模块增加测试集，还包括为新增加的模块增加测试集。测试结果的记录：健壮性测试的目的是找出系统的不健壮性因素，因此应详细的记录测试结果。,设计健壮性测试的策略,基于错误的策略：确认所有可能的错误源，为每一类错误开发错误注入技术；基于覆盖率的策略：接口覆盖的数量，故障位置覆盖的数量，例外覆盖的数量；基于失效的策略：用例设计故障是否被处理了，例外是否被处理了，一个组件中的失效是否影响另一个组件；,健壮性测试用例设计方法,在进行健壮性测试时，常用的用例设计方法主要有三种：故障插入测试，变异测试和错误猜测法。健壮性测试方法通常需要构造一些不合理的输入来引诱软件出错，如输入错误的数据类型，输入定义域之外的数值等。,6.4.3 一个健壮性测试案例分析,【例66】为了更清楚的让读者了解什么是健壮性测试，在这里举个简单的例子。假如定义了两个变量X1和X2，两个变量都有自己的取值范围，则写成如下这种形式：aX1b；cX2d；用坐标的形式表示，如图6.7所示。,图6.7 两变量函数的健壮性测试用例,在图中，灰色区域外的4个点就是健壮性测试要重点考虑的情况。一般情况下，边界值分析的大部分讨论都直接适用于健壮性测试。健壮性测试最需要关注的部分不是输入，而是预期的输出。当物理量超过其最大值时，会出现什么情况。如果是飞机机翼的迎角，则飞机可能失速，健壮性测试的主要价值是观察例外处理情况。,6.5安全性测试,安全性测试基本概念,安全性测试是检查系统对非法侵入的防范能力，其目的是为了发现软件系统中是否存在安全漏洞。软件安全性是指在非正常条件下不发生安全事故的能力。安全性一般分为两个层次，即应用程序级的安全性和系统级别的安全性,程序级安全性和系统级安全性的关系,应用程序级别的安全性包括对数据或业务功能的访问；而系统级别的安全性包括对系统的登录或远程访问。应用程序级别的安全性可确保在预期的安全性情况下，操作者只能访问特定的功能或用例，或者只能访问有限的数据。例如，某财务系统可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。系统级别的安全性对确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的入口来访问。,安全性测试方法,（1）功能验证功能验证是采用软件测试当中的黑盒测试方法，对涉及安全的软件功能，如用户管理模块、权限管理模块、加密系统、认证系统等进行测试，主要是验证上述功能是否有效。,（2）漏洞扫描 安全漏洞扫描通常都是借助于特定的漏洞扫描器完成。漏洞扫描器是一种能自动检测远程或本地主机安全性弱点的程序，通过使用漏洞扫描器，系统管理员能够发现所维护信息系统存在的安全漏洞，从而在信息系统网络安全防护过程中做到有的放矢，及时修补漏洞。,模拟攻击试验 对于安全测试来说，模拟攻击试验是一组特殊的黑盒测试案例，通常以模拟攻击来验证软件或信息系统的安全防护能力。,在数据处理与数据通信环境中的几种攻击方法冒充 重演 消息篡改 服务拒绝 内部攻击 外部攻击 陷阱门 特洛伊木马 侦听技术,6.5.2.2 确定安全性标准,（1）安全目标预防：对有可能被攻击的部分采取必要的保护措施，如密码验证等。跟踪审计：从数据库系统本身、主体和客体三个方面来设置审计选项，审计对数据库对象的访问以及与安全相关的事件。数据库审计员可以分析审计信息、跟踪审计事件、追查责任，并且对系统效率的影响减至最小。监控：能够对针对软件或数据库的实时操作进行监控，并对越权行为或危险行为发出警报信息。保密性和机密性：可防止非授权用户的侵入和机密信息的泄漏。多级安全性：指多级安全关系数据库在单一数据库系统中存储和管理不同敏感性的数据，同时通过自主访问控制和强制访问控制机制保持数据的安全性。匿名性：防止匿名登陆。数据的完整性：防止数据在未被授权情况下不被修改的性质。,（2）安全的原则加固最脆弱的连接：进行风险分析并提交报告，加固其薄弱环节。实行深度防护：利用分散的防护策略来管理风险。失败安全：在系统运行失败时有相应的措施保障软件安全。最小优先权：原则是对于一个操作，只赋予所必须的最小的访问权限，而且只分配所必须的最少时间。分割：将系统尽可能分割成小单元，隔离那些有安全特权的代码，将对系统可能的损害减少到最小。简单化：软件设计和实现要尽可能直接,满足安全需求的前提下构筑尽量简单的系统,关键的安全操作都部署在系统不多的关键点（choke points）上。保密性：避免滥用用户的保密信息。,（3）缓冲区溢出：防止内部缓冲区溢出的实现、防止输入溢出的实现、防止堆和堆栈溢出的实现。,（4）密码学的应用使用密码学的目标：机密性、完整性、可鉴别性、抗抵赖性。密码算法（对称和非对称）：考虑算法的基本功能、强度、弱点及密钥长度的影响。密钥管理的功能：生成、分发、校验、撤消、破坏、存储、恢复、生存期和完整性。密码术编程：加密、散列运算、公钥密码加密、多线程、加密cookie私钥算法、公钥算法及PKI、一次性密码、分组密码等,（5）信任管理和输入的有效性：信任的可传递、防止恶意访问、安全调用程序、网页安全、客户端安全、格式串攻击。（6）口令认证：口令的存储、添加用户、口令认证、选择口令、数据库安全性、访问控制（使用视图）、保护域、抵抗统计攻击。,（7）客户端安全性：版权保护机制（许可证文件、对不可信客户的身份认证）、防篡改技术（反调试程序、检查和、对滥用的响应）、代码迷惑技术、程序加密技术。（8）安全控制/构架：过程隔离、权利分离、可审计性、数据隐藏、安全内核。,安全性评价模型,（1）贝叶斯模型：设D为软件的输入空间，其运行剖面为pi，i，iD，pi=1，测试剖面为di，i，iD，di=1。其中di=zipi，zi为根据失效危害严重度将测试输入出现概率放大或缩小的调整因子。对于划分为相同失效危害严重度的输入取相同的调整因子，也即将D划分成C，C，C，C，对于每一输入子空间Cj，j，取同一调整因子，令其分别为Z、Z、Z 和Z。又设总测试次数为n，其中Cj进行了nj次测试，且有xj次失效，j为第j级错误的失效率，其运行剖面下的验前分布是参数为aj和bj的Beta分布。根据贝叶斯推断，j的验后分布为：aj+xj nZj+aj+bj,（2）3M评价模型。在3M评价法中，用软件中残留致险缺陷数的估计作为安全性评价的指标，它所依据的信息包括：被评估软件所控制对象的功能复杂性对安全性的影响C，用复杂度因子AC来反映这一方面的信息；该安全苛求系统所拥有的技术支持S，包括宿主系统的质量（硬件和系统软件可靠性、容错结构）、软件开发工具对安全性的影响等，这方面的信息用技术支持因子AS来衡量；软件开发队伍的技术素质和水平对安全性的影响L，用开发水平因子AL来衡量。因此一个软件产品在系统测试之前的内在缺陷数可估计为f(AC，AS，AL)，它是AC的单凋递增函数，AS，AL的单调递减函数。,不失一般性，可将测试前致险缺陷估计值用 来表达，其中、为正实数，分别描述了各因子对残留致险缺陷的影响规律，K也是正实数，为描述的各因子对残留缺陷数的比例值。对于一特定系统，、K为常数，其值可通过数据拟合取得，如果=l，则表明DP和AC成正比，如果0l，则是一个凹函数，和随、的变化情况同样如此。,6.5.2.4 安全性测试执行,危险和威胁分析。执行系统和它的实用环境的风险和威胁分析。以一种它们可以和系统的安全性动作相比较的方式来定义安全性需求和划分优先级。基于威胁分析，为系统定义安全需求，最关键的安全性需求应该得到最大程度的关注。注意，系统最弱的链接也是重要的，安全性需求的定义是一个反复的过程。模拟安全行为。基于划分的安全需求的优先次序，识别形成系统安全动作的功能和它们依赖的优先顺序。执行安全性测试。实用合适的证据收集和测试工具。估计基于证据的安全活动的可能性和影响。合计出一个准确的结果及系统是否满足安全性需求。,6.6 可靠性测试,6.6.1 可靠性测试的基本概念,1软件可靠性测试过程,2描述软件可靠性的基本参数假设系统S投入测试或运行后，工作一段时间t1后，软件出现错误，系统被停止并进行修复，经过T1时间后，故障被排除，又投入测试或运行。假设t1，t2，tn是系统正常的工作时间，T1，T2，Tn是维护时间，如图6.11所示。,（1）故障率（风险函数）：的单位是FIT，1FIT=10-9/小时。,(2)维修率：(3)平均无故障时间：,(4)平均维护时间：(5)有效度,(6)残留的缺陷数目N0：可以采用第二章叙述的方法进行估计。(7)可靠性：,【例6.8】某个系统的使用情况如图6.12所示。根据题义，n=6,t=186天=1488小时（每天8小时），T=15小时，则：MTBF=248小时=0.004/小时MTTR=2.5小时=0.4A=0.99.,3测试剖面和使用剖面之间的关系(1)计算准确的软件运行剖面，只有得到真实的软件运行剖面，软件可靠性计算的结果才是真实的，否则，就会存在误差。假设Test(D)是测试时的运行剖面，User(D)是用户使用时的运行剖面。(2)计算测试强度C，也称为压缩因子。C被定义为：,定理6.1：设x1，x2，xn是测试期间的n个无故障时间间隔，测试剖面等于使用剖面，即Test(D)=User(D)，则：,定理6.2：假设软件有n功能或模块，实际使用时每个模块被执行的概率分别为p1，p2，pn，均匀分布测试M小时，相当于按使用剖面测试了小时。,定理6.3：假设软件有n功能，实际使用时每个功能被执行的概率分别为p1，p2，pn，测试期间假设的每个功能被执行的概率分别为：p1，p2，pn，令：则x越大，测试时估计的可靠性就越不准确。反之，亦然。,6.6.2 软件的运行剖面,1运行剖面的概念及意义定义6.1：软件的运行剖面：设D是软件S的定义域，D=d1，d2，dn，P(di)是di的发生的概率，则运行剖面被定义为：(d1,P(d1),(d2,P(d2),(dn,P(dn)。,软件测试与软件可靠性的评估离不开软件的运行剖面。软件S的运行剖面是指软件输入空间D以及D中的点取值的分布，也就是说，D中每个点取值的概率（一般，将D及D的分布称为运行剖面）。显然，如果dD，若S（d）是正确的，则S的正确运行的概率为1，即P（S）=1。假设D=D1D2，D1是S正确运行的概率，D2是S产生错误的概率。在均匀分布假设下，S正确运行的概率为：,2获取运行剖面的步骤,构件软件的运行剖面要经过的五个步骤,3获取运行剖面的一般描述从软件到运行剖面的求解过程可用图6.14的网络模型派描述。在该图中，每个箭头代表了从上一级剖面的某个元素到下一级剖面的某个元素的转换概率。nx代表不同剖面中结点的个数。用代表第i层从结点j到结点k之间的转换概率。i=0，表示从软件到客户层，此时，Wjk用来Wk表示。因此Rk间可以表示为：,软件可靠性模型,6.6.3.1 概述1软件可靠性建模的基本思想 软件可靠性建模的基本思想是：在测试t时间内，共发现n个故障，假设每个故障发现的时刻分别为t1，t2，tn。或者在n固定的时间周期T内，所发现的故障数目分别是f1，f2，fn。根据上述假设，建立软件可靠性模型。通过此模型可以预测软件可靠性的未来行为。,软件可靠性建模的基本假设是：软件的运行剖面与可靠性测试剖面一致。一旦发现错误，则立刻修正，并不引入新的错误。错误被查出、失效是独立的。每个错误被发现的概率相等。,M(t)：软件失效数目函数，即到t时刻软件的失效数目。u(t)：M(t)的均值函数，u(t)=EM(t)。F(t)：错误的累积分布函数，。f(t)：错误的失效密度函数，。Z(t)：危险率函数，。,2软件可靠性模型分类Musa和Okumoto于1983年提出了软件可靠性模型的一种分类模式，这种模式将软件可靠性模型分为下列五类：时间域：日历或执行（CPU或处理器）时间。类别：在无限时间内发生的失效数是有限的还是无限的。类型：到指定时间发生的失效分布，类：失效强度的函数形式（只适用于类别是有限失效）。族：失效强度预期出现的失效数的函数形式（只适用于类别是无限失效）。,3建立软件可靠性模型方法建立软件可靠性模型的步骤包括四部分：（1）模型的假设：根据经验、现有模型和其它相关因素对M(t)、u(t)、F(t)、f(t)、Z(t)等之一的假设。这个假设是至关重要的，它后面三个部分起决定性的作用。（2）模型的形式：根据（1）模型的假设，推导出其它函数的形式。（3）参数估计：根据模型的形式，估计模型中的参数。参数的估计方法有极大似然估计法、最小二乘法等。（4）实践检验：应用工程软件的可靠性数据，检验所估计参数的正确度。,6.6.3.2 指数失效时间模型,此类模型的特点是：失效强度函数都是为指数的有限失效模型；单个缺陷是常数危险率Z(t)=；第i个缺陷被检测出来后，危险率函数是剩余缺陷的函数，即Z(t)=f(N-(i-1)；失效强度函数为指数形式，即：,Jelinski_Moranda模型,(1)基本假设软件中初始缺陷个数是一个未知常数N；错误检测率与软件中存在的缺陷数目成正比，比例常数假设为。(2)模型形式 Jelinski_Moranda模型假设失效时间间隔xi是与软件中仍存在的缺陷数目N-（i-1）成正比，并把这个值作为参数的指数分布，因此，P（ti）是关于ti的密度函数，则：由假设可以导出：,(3)参数估计由P（ti）可得似然函数：对上述方程采用极大似然估计法对N和进行估计，可得方程：解这个方程，即可得到N和。,2非均匀泊松过程（NHPP）模型,在该模型中，N(t)代表到t时刻为止发现的累积缺陷数目，u(0)=0，u()=N（N是一个未知常数）。,（1）基本假设到时刻t的累积失效数M(t)满足均值函数为u(t)的泊松过程。任意时间间隔t到t内的期望发现的缺陷数目与软件中的缺陷数目成正比，比例常数假设为b。在(0,t1),(t1,t2),，(tn,tn)内检测的缺陷数目f1，f2，fn相互独立。,（2）模型形式,（3）参数估计1）fi=1(i=1,2,n)。则时间t的联合密度函数为：对上述方程采用极大似然估计法对N和 b进行估计，可得方程：,2）fi是任意的。则fi的联合密度函数为：对上述方程采用极大似然估计法对N和 b进行估计，可得方程：,【例6.17】对【例6.16】中（1）的数据计算可得：对【例6.16】中（2）的数据计算可得：,3Schneidewind模型,该模型的基本思想是：现时缺陷率能够比以前观测的缺陷率更好的预测未来。假设有n个等长的观测时间单元，Schneidewind给出了三个模型：模型1：利用n个周期中的所有错误计数。模型2：只考虑从周期s到n之间的n-s+1个周期的数据。模型3：使用从周期1到s-1的累积错误计数，作为首选数据点，而使用从周期s到n的独立错误计数作为辅助数据点。,（1）模型假设1）到时刻t的累积失效数M(t)满足均值函数为u(t)的泊松过程。从均值函数可以看出任意周期期望的缺陷数目与此周期期望的未检测的缺陷数目成正比。假设u(t)是一个有界非减函数，且对于参量，有：2）假设失效强度:,（2）模型形式第i个时期期望的缺陷数目为：,（3）参数估计用fi作为独立非均匀泊松随机变量，则联合密度函数为：Ms-1是区间1到s-1的平均累积错误计数，Fs-1是区间1到s-1的累积错误计数,模型1：模型2：模型3：Schneidewind定义了三种评价标准，根据此标准，可以计算其最小或较小误差，由此决定s的取值。,4Musa模型,（1）基本假设：到时刻t的累积失效数M(t)满足均值函数为 的泊松过程。（2）模型形式因为故,（3）参数估计假设系统已检测了n个缺陷，且最后一次失效时间tn以来，在时间x内未发现其它缺陷，则此模型的联合密度函数为：因此，参数估计为：,【例6.18】假设x=20，对【例6.16】中（1）的数据计算可得：,5其它模型,指数类失效模型还有其它变种的形式。（1）超指数模型：Ohba、Yamada、saki和Laprie等人在Musa模型的基础上，提出了超指数模型，这种模型根据软件的性质将其分为K个不同的部分，而每个部分满足具有不同参数的指数分布，即：,（2）S_型软件可靠性增长模型。Ohba于1984年提出了此模型，定义其均值函数为：,扩展执行时间模型：Everett于1992年提出了此模型，模型的均值函数为：指数模型的基本假设是,6.6.3.3 Weibull和Gamma失