CN102393833B - 基于hfsqm排队模型考虑排错资源局限性的构件软件可靠性分析方法 - Google Patents

Abstract

基于HFSQM排队模型考虑排错资源局限性的构件软件可靠性分析方法，本发明涉及软件可靠性分析方法，它解决了实际中不可能拥有无限的排错资源，当所有排错人员都被占用时，新检测到的故障必须排队等待的缺陷。实现由三步组成：资源分配，故障检测过程和故障排除过程。资源分配为HFSQM中等待排错资源的故障分配合适的资源。故障检测过程基于构件软件应用的运行剖面对整个应用执行集成测试。故障排除过程对HFSQM中占有排错资源的故障进行修复。这能为软件发布和测试资源的合理配置提供依据，使软件既能按计划准时发布，又能满足用户的可靠性需求，降低软件的总成本。因此，基于HFSQM的仿真方法对于构件软件测试，进一步对于软件市场决策具有着重要指导意义。

Description

基于HFSQM排队模型考虑排错资源局限性的构件软件可靠性分析方法

技术领域

本发明涉及一种软件可靠性分析方法

背景技术

目前提出的构件软件可靠性分析模型对构件软件集成测试中故障排除过程的忽略，提出了HISQM模型建模分析故障排除过程。HISQM模型假设排错人员的数目是无限的，检测到的故障能立即分配排错人员。这个假设没有考虑排错资源的局限性问题。实际中不可能拥有无限的排错资源，由于成本以及预算等原因，排错人员的数目往往是有限的且严格受控制的。当所有排错人员都被占用时，新检测到的故障必须排队等待。

发明内容

本发明为了解决实际中不可能拥有无限的排错资源，当所有排错人员都被占用时，新检测到的故障必须排队等待的缺陷，而提出了一种基于HFSQM排队模型考虑排错资源局限性的构件软件可靠性分析方法。

基于HFSQM排队模型考虑排错资源局限性的构件软件可靠性分析方法的仿真过程中，每次执行采取的行动包括如下三个步骤：

资源分配的步骤ALLOCATING，具体过程为：

HFSQM中等待排错资源的故障分配合适的资源；

首先检查每个FSQ系统中有没有空闲的排错资源，以及等待队列中有没有故障在等待；如果条件满足，给等待队列队首的故障分配资源，并将其移到排错队列的队尾；以上过程重复进行，直到条件不满足为止；

故障检测过程的步骤DETECTING，具体过程为：

基于软件应用的运行剖面对整个应用执行集成测试；

在执行当前构件curr_comp之前，首先根据运行剖面P确定下一个要执行的构件next_comp，然后由curr_comp和next_comp确定curr_comp本次执行所需要的时间time_this_visit；

如果curr_comp执行过程中发生失效，则执行如下操作：将检测到的故障用结构体fault_info进行封装，然后根据排错策略放入相应的等待队列中，在下一个时间步到来之时参与排错资源分配；更新相应的计数器；设置curr_comp等于最后一个构件n，以便于在下一个时间步到来之时重启系统；中断对curr_comp的执行；

curr_comp执行完成之后，检查curr_comp是否等于n，若终止应用一次执行正常完成或发生失效时，则curr_comp等于n；当curr_comp等于n，需要重新启动系统，通过设置curr_comp等于构件1来实现；否则curr_comp不等于n；

以上过程重复执行，直到整个应用执行集成测试完成；

故障排除过程的步骤CORRECTING，具体过程为：

对HFSQM中占有排错资源的故障进行修复；

定义变量f指向排错队列中的每个故障；

如果f的状态是CORRECTING，表示还未被排除，则执行修复；

利用函数occur()判断修复是否完成；如果修复完成，更改f的状态为CORRECTED，释放排错资源，累加相应的计数器；

如此重复，直到完成对HFSQM中所有排错队列的遍历。

以上三个步骤重复进行，直到到达时间t停止执行，然后返回在这段时间内修复的总故障数。

本发明通过离散事件仿真为这些问题提供了一种解决方法。仿真方法由于它所具有的灵活性和动态性，使它能够放宽基于模型方法中一些过于严格的假设，跟踪软件的动态失效过程。近年来，基于率的仿真方法开始用于分析软件的随机失效过程。目前所提出的软件可靠性增长模型将测试及故障排除阶段的总可靠性增长看作或近似为执行时间中的马尔可夫过程，或非齐次泊松过程，后者实际上也是马尔可夫过程。尽管不同模型在基本失效机制上的假设可能有很大差别，但在数学上仅是率函数的形式不同而已。因此可以采用基于率的仿真方法实现对软件可靠性过程的仿真。本发明提出一个混合有限服务员排队模型HFSQM来建模构件软件的集成测试过程。以HFSQM作为仿真模型，提出一种基于率的仿真方法来描述构件软件测试中的可靠性增长过程。

本发明从描述构件软件实际的可靠性过程出发，提出一个基于率的仿真方法。首先定义基于率的仿真。基于率的仿真是一种速率控制事件进程的离散事件仿真方式。采用基于率的仿真方法来对软件可靠性过程仿真是因为，虽然不同的软件可靠性增长模型在基本失效机制上的假设有很大区别，但在数学上仅是率函数的形式不同而已。

基于HFSQM模型开发出基于率的仿真过程实现对构件软件可靠性过程仿真。仿真过程的实现由三步组成：资源分配，故障检测过程和故障排除过程。资源分配为HFSQM中等待排错资源的故障分配合适的资源。故障检测过程基于构件软件应用的运行剖面对整个应用执行集成测试。故障排除过程对HFSQM中占有排错资源的故障进行修复。

基于HFSQM的仿真方法放宽了传统的基于模型的方法中一些过于严格的假设，准确地描述了构件软件应用的可靠性过程，预测构件软件可靠性随测试过程的增长。这能为软件发布和测试资源的合理配置提供依据，使软件既能按计划准时发布，又能满足用户的可靠性需求，降低软件的总成本。因此，基于HFSQM的仿真方法对于构件软件测试，进一步对于软件市场决策具有着重要指导意义。

附图说明

图1是混合的有限服务员排队模型(HFSQM)的结构示意图，图2是FSQ_i队列系统的状态图，图3是一个示例应用的体系结构示意图，图4是FSQ₁的故障检测剖面和故障排除剖面曲线图，图5是FSQ₃的故障检测剖面和故障排除剖面曲线图，图6是FSQ₁的故障排除剖面曲线图，图7是FSQ₃的故障排除剖面曲线图，图8至图13是FSQ₁中未排除故障数随时间的变化图，图8是排错人员数目：1；图9是排错人员数目：2；图10是排错人员数目：3；图11是排错人员数目：4；图12是排错人员数目：5；图13是排错人员数目：6；图14至图19是FSQ₃中未排除故障数随时间的变化图：图14是排错人员数目：1；图15是排错人员数目：2；图16是排错人员数目：3；图17是排错人员数目：4；图18是排错人员数目：5；图19是排错人员数目：6。

具体实施方式

具体实施方式一：结合图1和图2说明本实施方式，本实施方式中的构件软件集成测试表示将应用中所有构件组装在一起进行测试的过程，应用中所有构件协同工作。随着测试的执行，故障不断被发现，排除，软件应用经历可靠性增长。该测试过程包括故障检测过程和故障排除过程。集成测试排错策略将这两个随机过程联系起来。

集成测试过程中，根据排错策略组织排错活动的进行。排错策略根据实际开发特点以及预算和进度要求，合理地配置排错资源，将检测到的故障以一定的方式分配给相应的排错人员进行故障排除。集成测试排错策略包含应用中每个构件的排错机制。因为构件软件应用是以异构方式开发的，对于检测到的不同构件的故障，需要采用如下两种不同的机制进行排除：

第一种，独立排错机制。对于检测到的某个构件的故障使用专门的独立排错资源进行修复。

第二种，共享排错机制。对于检测到的某些构件的故障，根据检测到的先后顺序使用共享的排错资源进行修复。

为了实现对构件软件集成测试中可靠性增长过程的仿真，首先需要根据集成测试过程建立仿真模型。

由n个构件组成的顺序执行的终止构件软件应用。不失一般性，假设应用从构件1开始执行，到构件n执行结束。对于该应用，集成测试中需要用k(0＜k≤n)个独立的排错系统对构件故障进行排除，k由排错策略决定。

因此，用一个包含k个独立的FSQ(Finite Server Queueing)系统的混合的有限服务员排队模型HFSQM来建模构件软件集成测试中的故障排除过程，如图1所示。

基于HFSQM的可靠性过程仿真的实现基于如下假设：

(1)软件系统为由n个构件组成的顺序执行的终止应用，对软件应用执行基于其运行剖面的集成测试，所有构件失效都会引发系统失效；

(2)构件失效过程满足NHPP，所有故障之间相互独立，构件i在充分小的执行时间区间(t，t+Δt)内发生一次失效的概率近似为λ_i(t)Δt，多于一次失效发生的概率可以忽略；

(3)排错是完全的，不会引入新故障，故障排除活动不会影响故障检测过程的继续进行；

(4)故障排除过程用HFSQM排队模型描述，其中每个FSQ建模为G/M/N排队系统，服务时间服从指数分布，第i个FSQ系统中每个排错人员的排错速率为μ_i，在充分小的时间区间(t，t+Δt)内排错人员完成故障排除的概率为μ_iΔt；

(5)故障到达HFSQM后，如果有空闲的排错人员，则立即分配；否则进入队列排队等待。

它的仿真过程中，每次执行采取的行动包括如下三步：

资源分配的步骤ALLOCATING，具体过程为：

HFSQM中等待排错资源的故障分配合适的资源；

首先检查每个FSQ系统中有没有空闲的排错资源，以及等待队列中有没有故障在等待；如果条件满足，给等待队列队首的故障分配资源，并将其移到排错队列的队尾；以上过程重复进行，直到条件不满足为止；

故障检测过程的步骤DETECTING，具体过程为：

基于软件应用的运行剖面对整个应用执行集成测试；

在执行当前构件curr_comp之前，首先根据运行剖面P确定下一个要执行的构件next_comp，然后由curr_comp和next_comp确定curr_comp本次执行所需要的时间time_this_visit；

如果curr_comp执行过程中发生失效，则执行如下操作：将检测到的故障用结构体fault_info进行封装，然后根据排错策略放入相应的等待队列中，在下一个时间步到来之时参与排错资源分配；更新相应的计数器；设置curr_comp等于最后一个构件n，以便于在下一个时间步到来之时重启系统；中断对curr_comp的执行；

curr_comp执行完成之后，检查curr_comp是否等于n，若终止应用一次执行正常完成或发生失效时，则curr_comp等于n；当curr_comp等于n，需要重新启动系统，通过设置curr_comp等于构件1来实现；否则curr_comp不等于n；

以上过程重复执行，直到整个应用执行集成测试完成；

故障排除过程的步骤CORRECTING，具体过程为：

对HFSQM中占有排错资源的故障进行修复；

定义变量f指向排错队列中的每个故障；

如果f的状态是CORRECTING，表示还未被排除，则执行修复；

利用函数occur()判断修复是否完成；如果修复完成，更改f的状态为CORRECTED，释放排错资源，累加相应的计数器；

函数occur()实现对失效发生事件和故障排除事件的仿真。对事件的仿真可以有多种实现方法，采用最普遍的随机数生成器来实现。根据事件的数学概率分布，编程实现随机数生成器来模拟各种事件。根据假设(2)(4)可知，在时间间隔dt内事件发生的概率近似为rate(t)*dt。因此该函数首先生成一个0到1之间均匀分布的随机数x，然后比较rate(t)*dt和x。如果x＜rate(t)*dt，则事件发生。

如此重复，直到完成对HFSQM中所有排错队列的遍历。

以上三个步骤重复进行，直到到达时间t停止执行，然后返回在这段时间内修复的总故障数。

基于以上假设，开发出基于率的仿真过程Procedure S如表1所示。该过程返回到测试完成时总共修复的故障数。它接收如下参数作为输入：时间步dt，为了保证仿真精度，dt必须足够小，并且在任何时候都满足rate(t)*dt＜1，rate(t)表示事件发生速率；集成测试时间t；应用的运行剖面P[n][n]，其中P[i][j](0＜i，j≤n)表示构件i执行完成之后转移到构件j执行的概率，该参数可以通过咨询对该系统非常熟悉的专家得到，也可以从该应用以前发布的版本或者相似应用的历史运行数据中估计得到；每次访问构件时构件执行时间的期望值phi[n][n]，其中phi[i][j](0＜i，j≤n)表示构件i正常执行完成后控制转移到构件j时构件i的执行时间，由于集成测试时构件已经开发完成，执行时间可以通过实际测试得到；构件的失效速率(*lamda)[n]，该参数根据构件单元测试数据建模得到；排错策略policy[n]；每个FSQ系统中排错人员数level[k]，排错速率mu[k]，以上三个参数由实际的集成测试情况确定。除了输入参数，Procedure S还定义如下变量来控制仿真过程的执行：curr_comp表示当前正在执行的构件；next_comp表示下一个要执行的构件；total_faults_detect记录检测到构件软件应用发生的总故障数；faults_detect[n]累计检测到的每个构件的故障数；time_this_visit表示本次访问当前构件在不发生失效的情况下所需要执行的总时间；time_so_far表示当前构件在本次访问中已经执行的时间，它的值小于time_this_visit；数组local_clock[n]保存每个构件执行的总时间；变量global_clock记录测试已经执行的时间；total_faults_correct记录排除的总故障数；faults_correct[n]累计排除的每个构件的故障数；数组queue[k]建模HFSQM。

表1、仿真过程：Procedure S

为了描述HFSQM，我们定义两个结构体，fault_info和queue_info，分别如表2和表3所示。fault_info封装故障检测过程中检测到的故障信息，跟踪故障状态的变化。从被检测出到被排除，故障一共经历三种状态：WAITING，表示等待排错资源；CORRECTING，表示占有资源正在被修复；CORRECTED，表示修复完成，释放资源。queue_info建模一个FSQ排队系统。排队队列根据应用中故障被检测到的先后顺序组织而成，我们用链表数据结构表示。整条队列可分为头尾相接的两条队列，分别为排错队列和等待队列。head0指向排错队列的表头，表示占有排错资源的第一个故障；tail0指向排错队列的表尾，表示占有资源的最后一个故障。head1指向等待队列的表头，表示等待排错资源的第一个故障；tail1指向等待队列的表尾，表示等待资源的最后一个故障。两条队列满足tail0-＞next＝head1。

表2、fault_info结构体定义

表3、queue_info结构体定义

HFSQM顾客到达规律：

HFSQM模型是基于排队论建模的。排队论，也称随机服务系统理论。排队系统一般可描述为顾客到达请求服务，如果无法立即得到服务就排队等待，服务完成之后离开。每个排队系统包括一个或多个服务人员。设FSQ_i表示HFSQM中第i个排队系统，0＜i≤k。根据经典排队模型A/B/n建模FSQ_i。其中，A表示顾客到达的规律；B表示服务时间分布；n表示服务员的数目，即排错人员的数目，满足1≤n＜∞。

设随机过程{N_i(t)，t≥0}表示FSQ_i的顾客到达过程。N_i(t)表示在长度为t的执行时间间隔内到达故障数。它的密度函数Λ_i(t)表示故障到达速率。Λ_i(t)依赖于分配到该系统的每个构件的随机失效过程。

设随机过程{X_j(τ)，τ≥0}表示分配到FSQ_i的构件j的随机失效过程，X_j(τ)表示构件j在长度为τ的执行时间间隔内发生的失效数。假设构件j的失效过程满足NHPP，失效速率为λ_j(τ)。则无论在τ时刻构件j处于什么状态，在τ与τ+Δτ之间的充分小的时间区间内下式成立

$\left\{\begin{array}{c}P(X_j(\mathrm{\τ}+\mathrm{\Δ\τ})-X_j\left(\mathrm{\τ}\right)=1)={\mathrm{\λ}}_j\left(\mathrm{\τ}\right)\mathrm{\Δ\τ}+o\left(\mathrm{\Δ\τ}\right)\\ P(X_j(\mathrm{\τ}+\mathrm{\Δ\τ})-X_j\left(\mathrm{\τ}\right)>1)=o\left(\mathrm{\Δ\τ}\right)\end{array}\right.---(5-1)$

其中，函数o(Δτ)定义为

$\underset{\mathrm{\Δ\τ}\→0}{\lim }\frac{o\left(\mathrm{\Δ\τ}\right)}{\mathrm{\Δ\τ}}=0---(5-2)$

函数o(Δτ)指示在时间区间(τ，τ+Δτ)内多于一次失效发生的概率值是可忽略不计的。

因为构件的失效过程满足NHPP，那么FSQ_i的顾客到达过程也为NHPP，到达速率可表示为

Λ_i(t)＝∑_jη_j(t)λ_j(t_j)                                                (5-3)

式中η_j(t)——t时刻构件j执行的概率；

    t_j——到时间t构件j的累计执行时间。

Λ_i(t)由集成测试剖面决定。在集成测试过程中，每当发生失效后，软件系统重启，从第一个构件重新开始执行。因此，发生在执行序列前面的构件中的故障被检测到并排除后，发生在执行序列后面的构件中所存在的故障才有可能被发现。也就是说，前面构件中的故障“掩盖”了后面构件中的故障。随着测试的进行，前面构件发生失效的概率越来越小，这样后面构件中的故障就有机会被检测到。可以看出，集成测试剖面基于软件应用的运行剖面在集成测试过程中随着失效的发生和故障的排除不断发生变化。FSQ_i的到达速率随之动态变化。该动态变化过程具有非常复杂的非线性特点，利用解析模型难以描述，而仿真方法正式处理这类复杂问题的较好方法。

HFSQM顾客服务规律

设FSQ_i表示HFSQM中第i个排队系统，0＜i≤k。设随机过程{H_i(t)，t≥0}表示FSQ_i的顾客离开过程。H_i(t)表示在长度为t的执行时间间隔内排除的故障数。对于任意时刻t≥0，满足H_i(t)≤N_i(t)。H_i(t)的密度函数U_i(t)表示故障排除速率。U_i(t)依赖于故障到达速率Λ_i(t)，排错人员的数目以及每个排错人员的排错速率。

指数分布是常用的服务时间分布假设。设FSQ_i中每个排错人员的排错速率为μ_i。则对某一故障排错人员已经进行t时间的修复后，将在时间间隔(t，t+Δt)内完成故障排除的概率为

$P(t\≤T\≤t+\mathrm{\Δt}|T>t)=\frac{g\left(t\right)\×\mathrm{\Δt}}{P(T>t)}=\frac{g\left(t\right)\×\mathrm{\Δt}}{1-G\left(t\right)}=u_i\×\mathrm{\Δt}---(5-4)$

式中G(t)——参数为μ_i指数分布函数；

g(t)——为μ_i的概率密度函数。

基于以上分析，FSQ_i可建模为G/M/N队列模型。该队列模型是一个生灭过程模型，其生灭速率为：

$\left\{\begin{array}{c}{\mathrm{\&Lambda;}}_{\mathrm{il}}\left(t\right)={\mathrm{\&Sigma;}}_j{\mathrm{\&eta;}}_j\left(t\right){\mathrm{\&lambda;}}_j\left(t_l\right),l=\mathrm{0,1,2},\&CenterDot;\&CenterDot;\&CenterDot;\\ U_{\mathrm{il}}=\left\{\begin{array}{c}{\mathrm{l\&mu;}}_i,0\&le;l<N\\ {\mathrm{N\&mu;}}_i,l\&GreaterEqual;N\end{array}\right.\end{array}\right.---(5-5)$

式中Λ_il(t)——FSQ_i处于状态l时的生速率，即顾客到达速率；

U_il——FSQ_i处于状态l时的灭速率，即顾客离开速率；

t_l——在系统处于状态l时构件j的累计执行时间。

FSQ_i队列系统的状态图如图2所示。

具体实施方式二：结合图3至图19说明本实施方式，本实施方式与具体实施方式一不同点在于对基于HFSQM的仿真方法进行实验分析。应用的体系结构如图3所示。

不考虑排错资源限制的仿真过程分析

用Goel-Okumoto软件可靠性增长模型的失效速率来描述应用中每个构件的失效行为。则构件i的失效速率为

其中α_i表示最终可能从构件i中检测出的故障总数的期望值，b_i表示每个故障的查出率，t_i表示构件i的累计执行时间。不失一般性，设应用中所有构件满足a_i＝20.05，b_i＝0.0057，每次访问构件时构件执行时间长度为一个时间单元。

设每个排错程序员的排错速率为μ＝0.025。该构件软件应用一共包括10个构件，根据集成测试中采用的排错策略不同，HFSQM排队模型可能由k(0＜k≤10)个FSQ系统组成，存在10种建模方式。这里只选取k＝3时的HFSQM模型进行分析，由这种一般性情况可以推广到其他各种情况。k＝3时HFSQM模型由3个FSQ系统组成：FSQ₁，FSQ₂，FSQ₃。设排错策略为构件1和5采用独立排错机制，检测到的构件1的故障进入FSQ₁，构件5的故障进入FSQ₂；其他构件采用共享排错机制，检测到的故障进入FSQ₃。

设仿真过程中测试总时间为5,000个时间单元。首先不考虑排错资源的限制，分析HFSQM中各个FSQ系统的故障检测剖面和故障排除剖面。设Procedure S输入参数level＝∞，执行仿真过程2,000次，计算得出平均运行剖面，如图4和图5所示。

图4显示了FSQ₁中的两个剖面，也就是构件1的故障检测和排除剖面；图5显示了FSQ₃中的两个剖面，即除构件1，5之外的其他8个构件的故障检测和排除剖面。可以看出，即使在排错人员数目无穷大的情况下，两个剖面也是不同的，故障排除过程滞后于故障检测过程，因此在构件软件可靠性分析中不可以忽略故障排除过程。在测试区间[0，5000]上，FSQ₁和FSQ₃的故障检测剖面曲线都呈现出先凸后凹的趋势，这表明故障到达系统的速率先增后减。FSQ₁的凸区间比较短，在该区间内，到达FSQ₁的故障数目直线上升，而到达FSQ₃的故障数几乎为0。这就是前面所提到的构件软件集成测试中的“掩盖”现象。构件1由于排在执行序列的第一位，在集成测试初期得到充分测试，它的故障“掩盖”了后面构件中的故障发生。随着测试的进行，构件1发生失效的概率越来越小，排队系统1的故障到达速率逐渐降低，这样后面构件中的故障就陆续有机会被检测到，FSQ₃中的故障到达速率逐渐增大。因为FSQ₃为8个构件的共享队列，构件遍布执行序列的前后，被“掩盖”的层次不一样，因此该系统故障到达速率增长相对缓慢，凸区间比较长。

考虑排错资源约束条件下的仿真过程分析

分析了不考虑排错资源限制的基于HFSQM的仿真过程，进一步仿真在不同的排错人员数目约束条件下的故障排除过程，分析排错人员数目对每个FSQ系统吞吐量的影响。设每个FSQ系统中排错人员数目分别为1到100，以及无穷大。在这种资源配置条件下分别执行Procedure S各2,000次，计算出每种情况下每个FSQ系统的平均故障排除剖面。对仿真结果进行分析发现，FSQ₁和FSQ₃在排错人员数目分别为23和41时达到临界值。达到临界值后，再增加排错人员的数目不会提高排队系统的吞吐量。图6和图7分别显示了FSQ₁和FSQ₃在不同排错人员数目约束条件下的故障排除剖面。从图中可以观察到，排队系统在临界值处的故障排除剖面与排错人员数目无穷大时的剖面非常接近。而到达临界值之前，不同排错人员数目配置下的故障排除剖面是不同的。

为了更形象地说明排错人员数目对FSQ系统服务水平的影响，图8至图13，以及图14至图19都分别列出了排错人员数目为1到6时FSQ₁和FSQ₃中未排除故障数随时间的变化情况。未排除故障包括等待队列中未分配排错资源的故障和排错队列中占有资源还未被排除的故障。从图中可以清楚地观察到在不同的约束条件下，排错人员利用率剖面以及队列长度剖面。随着排错人员数目增加，队列长度逐渐缩短，排错系统效率提高，但排错人员的利用率逐渐下降。表4列出了[0，5000]测试区间内，FSQ₁和FSQ₃中排错人员的利用率统计值。

表4、FSQ₁和FSQ₃中排错人员利用率

人数

1

2

3

4

5

6

7

8

9

FSQ1

100％

100％

100％

99.85％

97.22％

72.62％

64.55％

55.77％

26.98％

FSQ3

97.90％

96.33％

95.98％

91.86％

86.93％

83.56％

79.59％

78.07％

72.18％

从图8至图13明显发现，排错系统1在排错人员数目不小于6时，平均运行剖面显示等待队列中已经没有故障。因此FSQ₁在排错人员数目等于6时，虽然没有达到临界值，但是已经满足系统平均故障检测剖面，此时再分配更多的人员不会显著提高系统的吞吐量。以图19为例观察到，在测试开始时到达FSQ₃的故障数比较少，故障到达后能立即分配排错人员进行排除，排错系统效率比较高，但排错人员的利用率低；随着测试进行，故障到达速率逐渐增大，排错人员利用率随之增加，但等待队列中的故障也迅速增多，排错系统效率降低。此时项目管理者需要决定在什么时候如何调整排错人员的数目来实现排错系统效率和排错资源利用率之间的有效平衡。在选定的时间点，以新配置的排错人员数目为参数，重新执行Procedure S，根据仿真结果，项目管理者可以预测到重新进行资源配置对测试的影响，进一步决定是否要进行资源重新配置。

其它组成和连接方式与具体实施方式一相同。

Claims (2)

1.基于HFSQM排队模型考虑排错资源局限性的构件软件可靠性分析方法，其特征在于它的仿真过程中，每次执行采取的行动包括如下三个步骤：

资源分配的步骤ALLOCATING，具体过程为：

HFSQM中等待排错资源的故障分配合适的资源；

首先检查每个FSQ系统中有没有空闲的排错资源，以及等待队列中有没有故障在等待；如果条件满足，给等待队列队首的故障分配资源，并将其移到排错队列的队尾；

以上过程重复进行，直到条件不满足为止；

故障检测过程的步骤DETECTING，具体过程为：

基于软件应用的运行剖面对整个应用执行集成测试；

在执行当前构件curr_comp之前，首先根据运行剖面P确定下一个要执行的构件next_comp，然后由curr_comp和next_comp确定curr_comp本次执行所需要的时间time_this_visit；

如果curr_comp执行过程中发生失效，则执行如下操作：将检测到的故障用结构体fault_info进行封装，然后根据排错策略放入相应的等待队列中，在下一个时间步到来之时参与排错资源分配；更新相应的计数器；设置curr_comp等于最后一个构件n，以便于在下一个时间步到来之时重启系统；中断对curr_comp的执行；

curr_comp执行完成之后，检查curr_comp是否等于n，若终止应用一次执行正常完成或发生失效时，则curr_comp等于n；当curr_comp等于n，需要重新启动系统，通过设置curr_comp等于构件1来实现；否则curr_comp不等于n；

重复执行故障检测过程的步骤DETECTING，直到整个应用执行集成测试完成；

故障排除过程的步骤CORRECTING，具体过程为：

对HFSQM中占有排错资源的故障进行修复；

定义变量f指向排错队列中的每个故障；

如果f的状态是CORRECTING，表示还未被排除，则执行修复；

利用函数occur()判断修复是否完成；如果修复完成，更改f的状态为CORRECTED，释放排错资源，累加相应的计数器；

重复故障排除过程的步骤CORRECTING，直到完成对HFSQM中所有排错队列的遍历；

以上三个步骤重复进行，直到到达时间t停止执行，然后返回在这段时间内修复的总故障数。

2.根据权利要求1所述的基于HFSQM排队模型考虑排错资源局限性的构件软件可靠性分析方法，其特征在于故障排除过程中的函数occur()实现对失效发生事件和故障排除事件的仿真，采用最普遍的随机数生成器来实现。

Images