测试模型

关键词： 模型

测试模型（精选十篇）

测试模型 篇1

关键词：模型建立,滑动阻力,弓丝刚度

在正畸治疗中，托槽与弓丝间的滑动阻力始终是一个研究重点，其目的是为了尽可能地减少这个系统的滑动阻力，因此，准确的测量就是一个很重要的基础。在以往的研究中测量模型的设计方面没有太大的变化，其原理基本都是将托槽粘在某种固定的装置或固定的牙模型上，牙周膜的缓冲作用对滑动阻力的影响被忽略。因此，本文的目的在于设计并建立一种新的测试模型，尽可能地模拟临床上出现的情况，允许牙齿在移动过程中可以有一定的倾斜和旋转。

1 材料与方法

1.1 模型一的建立———包含牙周膜的模型（测试模型）

1.1.1 建立错

指数为0的Typodont模型根据Robert[1]的错指数计算方法，按错指数为0制作Typodont模型，并翻制石膏模型。

1.1.2 建立牙周膜间隙

建立0.4～0.6 mm的牙周膜间隙：使用厚度为0.016 mm的铝箔16层，包绕模型牙根2周，捏紧使铝箔紧帖牙根（图1）。

1.1.3 制作牙槽窝模型

用1.1.1所制作的石膏模型翻制藻酸盐阴模，将用铝箔包绕牙根的模拟牙倒插在阴模里，用蜡固定，立即翻制石膏模型。待石膏完全固化后，将模拟牙和铝箔完全取出，修整石膏模型，即成有牙槽窝的石膏模型，且牙槽窝比相应牙根宽1.0～1.1 mm（图2）。

1.1.4 制作环氧树脂牙

根据相似理论，按真实牙槽骨，牙本质及牙周膜的弹性模量比值为3 450∶5 113∶1，分别制作比值相同的模拟牙及牙周膜（图2）。

1.1.5 模型完成

根据1.1.1中的Typodont模型制作藻酸盐阴模，将制作好的环氧树脂牙倒插在阴模中，用蜡固定好。按上述弹性模量比例调制硅胶，浇灌进石膏模型的牙槽窝里，再将插有环氧树脂牙的藻酸盐阴模重新复位在有牙槽窝的石膏模型上，这样可以保证环氧树脂牙的牙周膜能按原来铝箔保留的那样均匀，而不致于使牙槽窝底部没有牙周膜间隙。等待硅胶固化后，本次实验使用的主要模型制作完成，记为模型一。

1.2 其他材料

1.2.1 模型二

模拟Henao等[2]的实验材料，以模型一中上颌为模板，不区分牙槽骨、牙周膜及牙齿材料的不同，翻制出超硬石膏模型作为对照，记为模型二。

1.2.2 测试机器

微机伺服万能材料试验机，深圳瑞格尔仪器有限公司。

1.2.3 金属托槽及不锈钢方丝

选择MBTTM金属托槽（3M公司，美国），3M公司出品的不锈钢方丝，尺寸为0.43 mm×0.56 mm,0.46 mm×0.64 mm,0.48 mm×0.64 mm,0.53 mm×0.64 mm，以灰色结扎橡皮圈（3M公司，美国）进行结扎。

1.2.4 实验在恒温恒湿的实验间中进行

为模拟体内环境，按ISO/TR/0271∶1993标准配制人工唾液，并保存于38℃恒温水浴箱中（上海跃进医疗器械厂）。实验时，用38℃人工唾液使实验模型保持在接近34～36℃的潮湿环境中进行实验。

1.3 测试方法

在试验中，每根钢丝在同一托槽中连续测试4次，取平均值。换钢丝的同时更换结扎圈。

不锈钢弓丝上焊接牵引钩，位置在与之间。测试开始时，让牵引钩停留在远中，贴近托槽远中边缘。测试前，机器归零。测试时，用约60 mm长的一段结扎丝对折后对牵引钩进行牵引，结扎丝固定在持针器上，持针器则固定于试验机的上方夹头，调整持针器，使牵引方向位于弓丝牵引钩与颊管牵引钩连线的延长线上。夹头速度0.5 mm/min，当牵引钩移动2 mm时停止测试。测试后用持针器将弓丝恢复到原位，感应夹头归位，机器归零，准备下一次测试（图3）。

1.4 实验数据的记录

微机伺服万能材料试验机的上方夹头直接连接感应头，由电脑直接记录每时刻的位移值和拉力值。当弓丝开始滑动时，读取此时的最大拉力，记为最大静摩擦力。滑动开始后，每隔0.5 mm位移读取并记录拉力值，最终取其平均值，记为滑动阻力。

2 结果

在两种模型上分别使用MBT托槽，各种不锈钢方丝的最大静摩擦力和滑动力见表1。

方差分析结论:模型间比较滑动阻力有显著性差异,P<0.001;弓丝间比较滑动阻力有显著性差异,P<0.001

在不同的模型上所产生的滑动阻力进行单因素方差统计，同种弓丝在两种模型上的滑动阻力均有显著性差异（P<0.001）。在模型一上，滑动阻力随着弓丝的尺寸的增大而增大，但是使用0.48 mm×0.64 mm的不锈钢方丝时，滑动阻力突然下降，其滑动阻力比使用其他不锈钢方丝时都低；而在模型二上，滑动阻力都随着弓丝尺寸的增大而增大。

3 讨论

在使用目前最常用的固定矫治器时，无论是牙列的排齐，还是牙齿的内收，弓丝在托槽槽沟中滑动时产生的滑动阻力是难以避免的，因此，常需建立体外测试模型对滑动阻力加以研究。目前国内外常见测试滑动阻力的模型有以下几种：

测试单个托槽滑动阻力的模型：用一节段弓丝和一个托槽来测量滑动阻力，这种模型相对较多，其测定方法简单，而且能反映出部分托槽本身的机械性能。Khambay等[3]的模型是让弓丝是固定住的，托槽在弓丝上滑动。Nishio等[4]的实验则是固定托槽，让弓丝在槽沟内滑动。为了测试不同转矩对滑动阻力的影响，托槽固定于一个可以旋转的平台上，这样轻易得到所需要的转矩角度。单个托槽的模型虽可以得到托槽本身材质的特性，但在临床上不可能只使用一个托槽，托槽的增加及位置的变化可以通过影响临床接触角等的变化来影响滑动阻力，因此，只测试一个托槽并不能对临床上托槽与弓丝间的滑动阻力有很好的了解。

多个托槽模型：鉴于单个托槽模型的缺点，有学者就设计多个托槽来进行测试，最少的可以包括一个尖牙托槽，一个双尖牙托槽及一个磨牙颊面管。如Baccetti[5]的研究则用了5个托槽（分别是双尖牙托槽、尖牙托槽和切牙托槽），每个托槽粘着在一块大小与牙齿相当的方块上，方块分别以螺钉固定于一牢固的类似牙弓的弧形装置上，其中螺钉可以调节托槽的位置，用以模拟不同的第二序列弯曲。而Simona[6]则在实验模型中用了10个托槽，并全部粘贴于一个固定的平板上，托槽粘成一直线。在这种情况下，研究人员发现，10个托槽的模型与只用1个托槽的模型没有太大差别。

数字模型：现在有限元方法已用于医学学科进行各种生物力学分析。Kang等[7]用托槽和弓丝的几何参数建立了一个三维数字模型，以研究托槽的临床接触角和转矩角度之间的关系。参数包括两种槽沟尺寸、三种托槽宽度和三到四种弓丝尺寸，模型包含托槽和弓丝，但不包含牙齿的任何组织。

滑动过程中牙齿沿着弓丝移动并不是一个平滑连续的过程，而是倾斜、直立、再倾斜、再直立的运动。大多数研究学者在为测量滑动阻力而制作模型时，多没有考虑到牙周膜的影响，牙齿的倾斜和旋转受到限制而不能发生，故而不能很好地模拟牙齿的移动过程。

在本实验中，为尽可能地模拟口腔内的情况制作了包含牙周膜的模型。正常人牙周膜间隙约为0.2 mm，而Svanberg[8]则发现正畸牙在移动时，其牙根表面与齿槽窝的距离可以达到正常间隙的2～3倍。因此，本实验中选择0.4～0.6 mm为所需建立的牙周膜间隙。由于牙根、牙周膜及牙槽骨的弹性模量不同，因此还需要模拟三种材料的弹性模量比值。根据Hart[9]的数据，人体牙槽骨骨皮质及牙齿的弹性模量分别为1.37×104MPa,2.03×104MPa，朱智敏等[10]的实验得出牙周膜弹性模量为3.35～4.59 MPa，取均值3.97 MPa，因此，牙槽骨、牙齿与牙周膜三者的弹性模量比值为3 450∶5 113∶1。本实验中，由于在错的情况下，牙根交错使得将石膏的牙槽窝模型翻成环氧树脂模型困难很大，所以直接采用超硬石膏模型，并测得超硬石膏的弹性模量为125 MPa。按以上弹性模量比值计算，调配弹性模量为185 MPa的环氧树脂和0.036 MPa的硅胶制作牙齿及牙周膜建立多个托槽的模型。

从本实验的结果可以看出，两种模型的滑动阻力有显著性差异，原因分析如下：当弓丝在槽沟中向远中方向滑动时，牙齿受到各种外力的作用，由于牙周膜的存在，允许牙齿有少量的倾斜和旋转，一方面会使弓丝与槽沟形成一定的角度，使托槽翼与弓丝间产生弹性约束，这种倾斜和旋转过大，还会产生刻痕阻力，这两者都会使弓丝的滑动阻力进一步增加；另一方面，弓丝在槽沟中产生一定的形变，这种形变也会增大弹性约束，使滑动阻力更大。在同一模型中，不同弓丝间滑动阻力比较也存在明显差异。在模型二中，滑动阻力随着弓丝的尺寸增加而增加，这与其他学者的结论是一致的。而在模型一中，有一个很明显的例外是：0.48 mm×0.64 mm的不锈钢方丝，其滑动阻力甚至比0.43 mm×0.64 mm的不锈钢方丝还要小，这个结果与MBT技术中提倡使用不锈钢方丝尺寸一致，认为在临床上使用0.48 mm×0.64 mm的不锈钢方丝内收时的效果最好。因此，本实验建立的新的测试模型可更准确地模拟临床实际情况。

参考文献

[1]Robert ML.The irregularity index:a quantitative score of mandibular anterior alignment[J].Am J Orthod,1975,68:554-563.

[2]Henao SP,Kusy RP.Frictional evaluation of dental typodont models Using four self-ligating designs and a conventional design[J].Angle Orthod,2005,75(1):75-85.

[3]Khambay B,Millett D,McHugh S.Archwire seating forces produced by different ligation methods and their effect on frictional resistance[J].Eur J Orthod,2005,27:302-308.

[4]Nishio C,da Motta AF,Elias CN,et al.In vitro evaluation of frictional forces between archwires and ceramic bracket[J].Am J Orthod Dentofacial Orthop,2004,125(1):56-64.

[5]Baccetti T,Franchi L.Friction produced by types of elastomeric ligatures in treatment mechanics with the preadjusted appliance[J].Angle Orthod,2006,76(2):211-216.

[6]Simona T,Felice F,Sergio C,et al.Fiction of conventional self-ligating brackets using a10bracket model[J].Angle Orthod,2005,75(6):1041-1045.

[7]Kang BS,Baek SH,Mah J,et al.Three-dimensional relationship between the critical contact angle and the torque angle[J].Am J Orthod Dentofacial Orthop,2003,123(1):64-73.

[8]Svanberg G.Influence of trauma from occlusion on the periodontium of dogs with normal or inflamed gunguva[J].Odontologisk Revy,1974,25(2):165-178.

[9]Hart RT,Hennebel VV,Thongreda N,et al.Modeling the biomechanics of the mandible:a three-dimensional finite element study[J].J Biomech,1992,25(3):261-286.

信用风险计量模型CPV测试 篇2

CreditPortfolioView模型。20世纪90年代末麦肯锡公司研发的CreditPortfolioView模型运用蒙特卡洛模拟技术和计量经济学相结合分析贷款组合的信用风险。将宏观经济因素纳入模型，建立起宏观经济变量与信用风险的联系。CreditPortfolioView模型通过逐步加入宏观变量冲击来模拟转移概率的变化，该模型根据现实宏观经济数据通过蒙特卡洛模拟得出贷款违约率，并不依赖历史数据，历史数据只是对那些非违约的转移概率进行计算。CreditPortfolioView模型采纳的VAR方法具有较强的前瞻性，可视为对基本信用计量方法的补充，并克服了一般模型不同时期转移概率一成不变的假设。同时具有违约概率模型和盯市模型的双重功能，该模型最重要的创新在于运用宏观经济因素的变动来计量信用风险的变化。

不同模型的基本要素比较：

压力测试流程

对商业银行房地产贷款进行压力测试时，首先选择风险因子，哪些风险因子会触发银行的信贷资产发生损失。接着设计压力情景，情景的设定要严峻于正常状况，极端却有可能发生，通常采用历史情景和专家设计两种情景设定方式，通过构建风险传导模型，得出压力测试的结果。然后分析银行近期的经营状况，是否能够承受假设的极端情景下造成的损失。最后根据评估的结果，银行可以结合对未来宏观经济变化的预期判断提前制定相应的防御措施。

实证分析

1、被解释变量：房地产不良贷款率替代违约率

2、解释变量：消费者价格指数（CPI）、国内生产总值（GDP）、3-5年期贷款利率（R）、股票价格指数（INDEX）、广义货币供应量（M2）、固定资产投资（INVEST）、城市人均季度总收入（IPH）、国房景气指数（NHBI）及消费者信心指数（CCI）这9个宏观经济变量。选取季度数据进行实证分析。其中，商业银行不良贷款率数据来自银监会网站，其他数据来自Wind数据库和国家统计局数据库。

3、数据调整：

（1）价格调整。在所选取的9个经济变量中，有4个是名义变量∶国内生产总值、广义货币供应量、城市居民可支配收入、固定资产投资额，它们会因为物价水平的变动而受到影响。因此在进行回归分析前，要对这些名义变量进行价格调整，排除价格因素对这些指标的影响。本文以2003年4季度为基期，计算各期的CPI数值，用各期相应的CPI数值去除国内生产总值、广义货币供应量、固定资产投资额、城市人均季度总收入的名义值得到各变量的实际值。

（2）季节调整。一般情况下，经济指标的季度和月度数据包含4种变动要素，分别是季节变动要素、长期趋势要素、不规则要素和循环要素。自然条件、社会制度与风俗等因素都会造成经济时间序列的周期变动，因此受季节变动要素影响所产生的这种周期性变化在经济分析中称为季节波动。对于时间序列，季节性因素会导致统计数据不能客观反映经济变化规律，因而在经济统计分析中除掉季节波动因素的影响，需要对季度数据和月度数据进行季节调整。本文用SPSS19.0对国内生产总值和固定资产投资额等进行季节调整。

（3）多重共线性分析：

在存在多重共线性的情况下，当一个变量发生变化时，另一个变量也会随之发生变化，很难衡量每一个解释变量对总体 R2的贡献，因此有必要采取一定策略对解释变量引入回归方程加以筛选。本文使用 SPSS 19.0软件，采用向后筛选策略对解释变量进行筛选以剔除变量的多重性。

上述分析结果表明，应该重新建立回归方程，这里采用向后筛选策略让SPSS19.0软件自动完成解释变量的筛选，观测每一步检验的变化情况，同时进行强影响点探测与残差分析，分析结果如表5.2。

第五个P值都小于0.05，适用。

4、模型检验

（1）拟合优度

（2）回归方程显著性检验

（3）回归系数显著性检验

（4）残差检验

5、模型建立

6、压力测试（核心）

敏捷模型下的回归测试 篇3

关键词 敏捷模型 Scrum 回归测试 持续集成

中图分类号：TP3 文献标识码：A

近年来随着IT行业的迅速发展，软件已经在人们日常生活中随处可见，而软件行业的竞争也日趋激烈。在激烈的竞争环境中，越来越多的软件企业都期望采用一种开发周期短，质量稳定，投资回报高的软件开发模型。于是敏捷模型逐渐走入人们的视野，并受到越来越过的开发团队的青睐。敏捷开发是一种基于用户需求的，循序渐进的迭代式的开发方法。相对于传统的瀑布式模型来说，敏捷模型具有如下优点：

传统的瀑布模型要求用户需求明确，而且一旦确定下来，在后续开发过程中便不能更改。但是对大多数软件项目来说，用户的需求往往是不断变化的。尤其是项目的初期，用户需求很难明确，甚至有时用户自身也很难有一个清晰的需求。而敏捷模式正是以用户需求为核心的一种开发模式，用户可以在敏捷模式的每一个迭代周期中，不断提出自己新的需求（user story），以不断接近最终的需求目标。

瀑布模型往往开发周期比较长，而且团队成员的利用率不高，比如在设计阶段往往只有设计人员和架构师参与其中，开发和测试人员的参与率很低。而敏捷模式由于其周期短，全体参与者在每个迭代周期内往往各司其职，充分参与到项目中，这就大大提高了开发效率。

敏捷模式可以较早推出可以运行的产品，并在用户的使用中发现问题，改进需求，合理的规避风险。在这一点上瀑布模型是无法做到的，如果一旦瀑布模型生产出的产品最终无法被用户所接受，那么产品将不得不重新设计，从而大大增长整个产品的成本和周期。这种返工的代价是巨大的，而且频繁的返工往往会使整个项目面临失败的风险。

瀑布模型中，测试的阶段往往比较滞后，这就导致有时很严重的问题往往到项目快临近结束的时候才被发现出来。更有甚者，有的项目为了追赶时间进度，会把测试周期缩短以保证产品的按时发布，从而导致产品质量低下，严重影响用户满意度。但在敏捷模式中，每一个迭代周期都会对产品进行集成测试，而且自动化的集成测试可以极大的提高测试效率，使产品的质量得到持续性的保证。敏捷模式经常可以把严重的、优先级比较高的缺陷在早期发现并得到修复，保证上线的产品质量稳定，故障率通常较低。

Scrum是敏捷模型中最常用的一种开发模式。Scrum是橄榄球运动中的一个专业术语，表示争球。 我们可以想象当一个项目团队像打橄榄球一样在开发一个项目，那是一件多么快速，多么富有激情的事情。在Scrum模式下，每一次迭代周期（一般为4个星期）定义为一个Sprint，中文意思即为冲刺，也就是说团队成员要在迭代周期内，以最快的速度完成它。这里我们就不对Scrum的具体流程作详细介绍了， 读者有兴趣可以参阅相关资料。

下面我们来看一下，在Scrum模式下测试通常是如何进行的。首先，在产品开发的过程中，新需求和新功能在迭代中不断涌现，每次迭代结束都会产生一个可工作的软件。这就要求测试人员要尽可能早的展开工作，等待开发人员完全开发完毕在Scrum中属于一种错误的概念。

其次，测试用例要尽可能多地采用自动化。Scrum项目初期，产品停留在初步设计中，产品功能不多，复杂度小，手动测试就可以保证质量。而到了中后期，因不断有新需求、新功能的加入，产品复杂度明显增大。若仍然采用手动测试，恐怕难以覆盖产品的各个功能、非功能点，而且手工测试在面对功能诸多的产品时，就会暴露出执行耗时长，易遗忘等缺点。因此，可以用自动化测试来提高工作效率。

然后就是，测试人员要学会做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发人员。

回归测试（Regression Test）简单来说就是重复测试之前的测试用例。这个环节在很多项目，尤其是那些迭代相对频繁的项目往往会被忽视，或者说做得不够充分，究其原因是由于项目开发周期短，产品上线紧急，从而挤压了回归测试的时间。但是不得不说这个环节对保证产品质量和产品功能稳定是十分重要的。当一个新的功能加入到产品中或是一个已有的功能被修改，往往涉及很多模块的变动，尤其是基类和公共类的改变，这时候就非常容易导致新的功能加入进来，已有的功能却无法正常运行的情况，在耦合度相对较大的项目中这类问题更是尤为突出。

回归测试重要性很明显，但是在敏捷模型下，它执行起来却没有那么轻松。由于敏捷模型自身的特点：开发周期短，迭代频繁，所以相对于传统的瀑布模型，会使测试的压力大大增加。其困难主要集中在两个方面，首先是测试用例的数量，一般来说测试覆盖率和测试用例的数量成正比，因此测试人员会在功能测试中会引入大量的测试用例来提高覆（下转第33页）（上接第31页）盖率，从而提高对产品质量和测试流程的信心。但是在测试用例增加的同时，测试时间也会延长，这就给回归测试带来了难度，测试人员很难在有限的时间里执行大量回归测试。其次，当项目迭代次数很多时，大量的测试用例维护也会占用测试人员很多的时间和精力。一旦维护不及时，往往会使一个缺陷影响很多个迭代周期而不被人们发现。

由于回归测试需要执行大量的测试用例，而这些测试用例的验证步骤往往会有些共同的特点，所以人们往往用编程自动化的方法来实现回归。自动化的回归测试的好处主要有如下几个方面：

减少手动回归的测试量，缩短回归测试的时间。

减少人为执行测试用例时的干扰因素，避免人为执行不充分的影响。

结合持续集成测试方法，保证回归测试持续进行。

对复杂的测试用例可以进行分解，自动化每个单独测试点。

对于测试用例中常用的步骤可以封装成通用的方法，让公共的测试步骤可以复用。

自动化还可以执行一些手动测试很难执行的测试用例，比如对于大量用户和并发用户的模拟。

在敏捷模型中，自动化的回归测试几乎是每个项目都会使用到，但是敏捷模型却有一个特点是自动化的回归测试往往陷入困境。那就是在敏捷模型下，需求的变动非常频繁，测试人员经常需要对已有的测试用例进行修改。针对这个特点，在我们创建自动化测试用 例时，最好可以做到如下几个方面：

将测试用例中的测试数据和测试用例本身分开。

尽量将常用方法封装成公共方法。

将经常变化的参数提取到配置文件中。

减少硬编码和重复的代码量。

这样做不仅能让自动化测试代码在需求变化时，修改程度最小化，而且还能让测试代码变得简洁便于维护。

由于在敏捷模式下，迭代周期很短，有时候甚至会每周就发生一次迭代。这就要求测试人员经常对测试用例进行检查，也就是说我们要经常地执行回归测试。上面我们已经提到了自动化回归测试的方法，现在我们再看一下这种方法应该如何执行，以及它执行的频率。在敏捷模型的项目里，有两种执行自动化回归测试的策略，一种是在代码签入时，另一种是以天为单位来执行。具体选用哪种策略，我们通常是看代码签入的频率，如果代码签入频率很高话，按天执行回归将是很好的选择。测试人员只需要每天检查测试结果的报告就可以发现哪些测试用例出了问题，具体是测试用例需要调整，还是产品功能发生了异常，需要测试人员进行分析。当然如果测试用例的日志足够详细的话，将有助于对问题的分析和定位。

综上所述，回归测试在敏捷模式下的作用非常重要，其测试方法也越来越偏重于自动化的实现方案，相较于过去的开发模型，敏捷模型对测试人员的编程能力要求更高。在敏捷模型下的项目，测试人员要从事大量的自动化编程工作，在一些项目中测试人员和开发人员甚至可以做到角色互换。希望测试人员在敏捷模型下可以转变过去传统模型所固有的思路，将回归测试做得更好。

参考文献

[1] Lisa Crispin and Janet Gregory. 敏捷软件测试：测试人员与敏捷团队的实践指南. 清华大学出版社. 2010年.

[2] Robert C Martin. 敏捷软件开发：原则、模式与实践. 清华大学出版社. 2003年.

测试模型 篇4

随着南方电网二次系统一体化战略的推进, 厂站的部分管理已逐步提升到主站端调度自动化系统中完成。厂站源端模型自动同步到主站端调度自动化系统, 也成为二次系统一体化须要着手实现的功能。主站将厂站提供的源端模型导入不仅仅是单纯的模型转换, 还包括对象的映射, 以及拓扑结构的重建。由于SCD文件的模型描述方式与CIM的模型描述方式有着较大差别, 进行SCD模型与CIM模型进行一致性测试是实现源端维护的必要条件。

比较厂站端一次模型的与主站端同一厂站内的模型结构有如下两种场景, 一是在新建厂站模型导入到主站系统后, 必须要解决的问题之一就是要验证导入的模型与厂站源端模型是否一致, 一致性检测分为两个部分, 不同模型框架下对应的对象是否一致, 以及验证就是一次模型的拓扑结构是否一致;二是厂站模型导入工作并非是一次性工作, 随着电网建设规模逐渐扩大, 厂站也会相应的进行改造, 升级, 厂站的模型也会因此发生变化, 此时必须在不

破坏原有模型的基础上实现增量模型的正确导入。

在上述两种情况下, 无论是全新导入还是增量导入, 都需要对主站端最终的CIM模型与厂站端原始的SCD模型进行一致性测试, 只有确保两者完全一致的情况下, 才能保障主站端调度自动化系统以及相关依赖CIM模型的各自动化功能正确可靠的运行[6]。

本文针对厂站端SCD模型与主站端CIM模型的一致性测试技术进行研究, 提出一种SCD与CIM模型一致性和拓扑一致性校验测试方法, 实现二者在不同模型描述框架下的分析与校验, 保证厂站与主站从一次到二次、从信息到拓扑的一致性, 具有十分重要的意义。

2 SCD的模型结构

变电站系统配置描述文件SCD是利用SCL (Substation Configuration description Language) 变电端配置描述语言SCL描述的一种文件类型。SCD文件包含5个主要元素:Header、Substation、IED、Communication和Data Type Templates。

Header (信息头) 包含版本号及其命名空间的映射信息;Substation (变电站描述) 描述变电站的功能结构, 标识一次设备及其之间的电气连接关系;IED (智能电子设备描述) 分别描述变电站各个IED的配置及其功能, 包含访问点、逻辑设备、逻辑节点数据对象等信息;Communication (通信系统描述) 通过逻辑总线和IED访问点来描述通信网络的连接关系;Data Type Templates (数据类型模板) 定义了文件的逻辑节点类型以及该逻辑节点所包含的数据对象和数据属性。

2.1 SCD的一次设备模型

厂站一次设备模型主要在SCD文件的Substation元素内进行描述。该元素描述了厂站内一次设备的信息以及彼此之间的电气连接关系。

厂站模型主要包含下列功能结构:Substation用于描述整个变电站对象;Voltage Level指可描述的电气连接上具有统一电压等级的变电站部分;Bay指某一电压等级内开关场的一个可描述部分或子功能;Equipment指开关场内的一个元件, 如断路器、隔离开关、电压互感器等;Subequipment指设备的一个部分;Connectivity Node指连接不同一次设备的 (电气) 连接节点对象。典型的连接点有:间隔内的连接节点, 相同电压等级中连接数个间隔的母线、连接不同变电站中多个间隔的线路;Terminal指电气连接层上一次设备的一个电气连接点, 端点可以连接到连接节点;Power Transformer是一种特殊设备, 它含有变压器绕组 (Transformer Winding) 设备。变压器绕组又可以与分接开关存在关联。

设备容器对象是一组功能相关, 某些或某个属性相同的一组设备的容器, 主要的设备容器有变电站 (Substation) 、电压等级区 (Voltage Level) 、间隔 (Bay) 、变压器 (Power Transformer) 等。其中, 变电站可以包含变压器设备以及电压等级区容器, 电压等级区可以包含变压器设备以及间隔容器, 而间隔可以包含变压器设备以及其他一次设备。变压器属于一类特殊的设备容器, 它从对象继承关系来说应是设备对象, 但是由于该对象并不直接参与到电气连接的描述中, 而是通过包含的绕组设备对象进行电气连接。所以一般将其视为一个设备容器, 但其能仅能够包含变压器绕组 (Transformer Winding) 设备对象。

一次设备对象是通过Equipment元素进行描述。Equipment是一个抽象的父类, 继承于Equipment的子类用于描述具体业务信息。包括Conducting Equipment (导电设备) 、Transformer Winding (变压器绕组) 以及General Equipment (一般设备) 。对于变电站内各种不同的设备类型, 是通过其type属性进行描述。母线在一次设备模型中属于特殊设备, 其在SCD中并不会以特殊的元素进行描述, 或者通过特别的类型说明来标注, 而是通过有特殊形态的间隔进行标示。母线间隔不含有任何一次设备, 它被建模成仅有连接节点 (Connectivity Node) 的间隔。

2.2一次设备拓扑模型

一次设备拓扑包含两个层面的信息。第一是设备与设备容器的关系, 第二是设备间的电气连接。对于第一层信息, SCD中采用元素嵌套标示包含关系, 设备与设备容器的关系也是通过设备对象元素被设备容器对象元素包含的方式进行描述。对于第二层信息, 变电站的一次设备在变电站内部形成一个有效的网状连接, 设备之间彼此关联。

设备之间的电气连接均是通过tAbstractConducting Equipment–Terminal–Connectivity Node–Terminal–t Abstract Conducting Equipment关联进行描述。即导电设备通过Terminal端点连接到一个具体的Connectivity Node连接节点。通过连接到同一个Connectivity Node的导电设备确立导电设备之间的连接关系。

2.3 SCD的二次信息模型

SCD内的二次信息模型主要是包含Communication中的通信网络信息描述和IED中的智能电子设备功能描述。SCD中提供大量信息用于给各个智能装置进行通信与功能进行配置, 但是其中却有很多的信息在主站端调度自动化系统中并不需要, 例如GOOSE配置信息及MMS服务描述等。同时通信网络的配置由于仅在变电站系统内部有效, 在主站端这些信息没有实际的使用价值。

对于主站端调度自动化系统, 变电站信息除了一次设备信息外, 最重要的是实现四遥所传送的量测、控制、遥调、保护等业务对象信息。

在SCD中, 对应的二次信息由相关逻辑节点来表达。和主站相关的逻辑节点则通过与变电站、电压等级、间隔、设备等相关联的逻辑节点来进行描述。其中, 主要的相关逻辑节点分为控制逻辑节点C、计量和测量逻辑节点M、保护功能逻辑节点P、电力变压器和相关功能逻辑节点Y。这些逻辑节点的详细信息是在IED装置信息中进行描述, 在一次对象中进行引用。

3 CIM的模型结构

遵循IEC 61970的CIM模型是一套用于描述电力企业信息系统的通用模型描述框架。该框架通过资源描述框架的包、类、对象体系进行描述, 并非依赖XML的层次关系来描述对象间关系, 对象和对象间的关系 (包括关联和聚集两种关系) 通过对象的角色进行描述。

3.1 CIM的一次设备模型

CIM的一次设备主要通过Core及Wires类包中的若干个类进行描述。对于变电站 (Substation) 主要设备对象如下:

(1) 电压等级 (Voltage Level) 是在同一个系统电压下的设备集合, 形成一套开关设备 (switchgear) , 设备一般包括断路器、母线段、仪器、控制、调节和保护设备, 以及所有这些的组合。

(2) 间隔 (Bay) 是电力系统资源 (在一个给定的变电站内) 的一个集合, 包括导电设备、保护继电器、量测量和远程测控。

(3) 母线段 (Busbar Section) 是一个或一组可忽略阻抗的导体, 用于连接一个变电站内的其它导电设备。电压量测一般是通过连接在母线段的电压互感器Voltage Transformer得到的。一个母线段可能有多个物理端点, 但分析时母线段只建成一个逻辑端点的模型, 属性类型名 (type Name) 指明母线段的类型, 如:主母线 (Main) 、旁路母线 (Transfer) 。

(4) 导电设备 (Conducting Equipment) 是电力系统的组成部分, 与导电相连有关。Conducting Equipment所属的Substation由它们之间的Member Of关系决定, 该关系从Power System Resourc继承而来。

(5) 变压器 (Power Transformer) 模是由两个或更多的耦合绕组组成, 用来在电路之间引入相互耦合的一种电气装置, 变压器可用来控制电压和移相, 属性表明变压器的类型。

(6) 开关 (Breaker) 是一种机械切换设备, 在正常电路条件下接通、承载和切断电流, 也有能力在规定的电路异常的情况下, 在设定的时间内接通和承载电流及切断电流。其属性是断路器的类型, 如油型开关、空气开关、真空开关、六氟化硫开关等。

(7) 刀闸 (Switch) 可一种用来断开或闭合 (或两者都具备) 一个或多个电路的通用设备。其属性用来表明开关并不对应一个实际的装置, 而仅是由建模的需求而引入。

(8) 接地 (Ground) 为了连接接地导电设备 (例如并联电容器) 的一个公共点, 电力系统模型可有多个接地。属性表明该接地的类型。

3.2 CIM的拓扑模型

CIM设备拓扑是通过两种方式进行描述, 一是通过聚集关系的角色进行描述, 不同于SCL模型的嵌套式模型描述, CIM中的对象是通过角色进行对象间关联。

二是通过Connectivity Node进行设备连接。与SCL类似, 设备间的连接也是基于Connectivity Node对象进行。基本连接方式通过设备附属的Terminal连接到Connectivity Node。但区别之处在于, CIM中的Connectivity Node不代表任何具有实际物理特性的设备, 例如母线段, 在SCL中, 母线段只是一个具有特殊意义的Connectivity Node。而在CIM中, 母线段Bus Sector是一个从导电设备类继承的设备。它也是通过Terminal以及Connectivity Node与其他设备相连。

3.3 CIM的二次模型

CIM中的二次模型主要是通过量测包和保护包中的相关类进行描述。

量测类 (Measurement) 用于描述任何一个测量的、计算的或者非测量非计算的量。任何一个设备都可以包含量测, 电力系统资源和量测的关联用来体现量测的用途, 该关联包含在基于设备容器的命名层次体系中, 命名层次体系通常将量测作为叶节点, 例如变电站-电压等级-间隔-开关-量测。某些量测代表与一个传感器特定位置有关的量, 如一个母线段上的电压互感器 (PT) 或在一个断路器和一个间隔装置之间的线上的电流互感器 (CT) 。虽然传感器位置没有在电力系统资源与量测的关联中体现, 但却可以在明确定义传感器位置的量测与端点的关联中体现。量测与设备的关联通过Measurement-TerminalConducting Equipment途径进行描述。对于特殊的量测, 允许同时使用量测-电力系统资源关联和量测-端点进行关联。量测-电力系统资源关联定义命名层次体系中的量测, 而量测-端点关联定义网络拓扑中配置量测的位置。

控制类 (Control) 可用于监视器/设备控制, 代表用于在进程中改变状态的控制输出, 如开合断路器、一个设定点值或一个升降命令。

命令类 (Command) 是一个用于监控的离散控制。

保护设备 (Protection Equipment) 是一种电器设备, 它按事先规定的方式对输入条件进行响应, 而在特定的条件得到满足后, 将引起触点动作, 控制相关断路器变化, 或只是简单的显示检测到的状态。保护设备与导电设备通常通过通常操作断路器相关联。对于保护继电器, 属性由IEC 61850规定带Pro_前缀的类型进行标识。

4 SCD与CIM设备模型一致性校验

SCD设备模型与CIM设备模型, 在一次设备层面上实际上描述的是同样的业务模型, 但采用的描述框架有着巨大的差异。要对两种模型框架中的设备模型进行比较, 首先要进行对象查找, 确认源端SCD模型中的相关设备对象或量测、保护对象在CIM模型中存在, 然后比较两个对象是否描述相同的业务对象。

由于SCD和CIM的对象描述体系存在差别, 需采用不同的对象定位方式。在SCD中, 由于对象通过XML的层次结构进行描述, 对象和对象间的关系清晰且只需保证在统一层次内命名的唯一性即可准确确定一个对象;在CIM中, 由于对象间的平等关系, 所有的对象必须通过唯一的URI来区分。因此, SCD的对象命名与CIM的ID体系存在巨大的差异。在源端维护体系内, 一般处理方法为使用SCL中的对象路径 (以对象在SCL中的层级对象名称的连接) 作为其在CIM内的URI。

实现SCD模型与CIM模型比较, 首先通过URI匹配来寻找需要对比的对象。确保SCD中的一次设备对象是否在CIM中存在。

比较过程实现流程如下:

(1) 步骤1:在SCD中定位一个对象, 通过对象在层次结构中的位置, 获取对象的Path。

(2) 步骤2:通过Path确定URI, 以此在CIM中获得对应的对象。

(3) 步骤3:分析获取的对象类型, 如果与SCD中的对象类型不匹配, 则判定比较失败。

(4) 步骤4:比较两个对象的相关性质, 如果不一致, 则判定比较失败。

(5) 步骤5:返回步骤1, 直至遍历SCD中所有设备。

5 SCD与CIM拓扑一致性校验

拓扑一致性比较主要是对比双方模型设备的所属关系以及设备间的连接是否一致。拓扑一致性比较主要包含区域一致性以及连接一致性比较两个方面。

5.1区域一致性校验

区域一致性主要指所要比较的对象处于相同的拓扑域 (变电站内功能相关的一组设备或设备容器) 中。区域一致性又细分为电压等级一致性与连接一致性。

电压等级一致性校验是确保两个变电站在电压等级的描述上具有一致性。通常一个变电站会包含2~3个电压等级区, 其中高电压等级为电源输入, 中、低电压等级为负荷输出。源端SCD模型与CIM模型中, 对电压等级的描述须完全一致, 即无论是包含电压等级的数量还是具体的值都一致。如果有任何差异, 则两个变电站不具备可比性。

对于间隔一致性校验, 由于两边模型的差异, 间隔并不强制要求一致。如在源端SCD模型中, 母线必须单独存在于一个独立的母线间隔, 且该间隔内不能有其他设备, 而在CIM中, 母线段可与其他相关设备并存于一个间隔内。虽然间隔一致性并不强制要求, 但是对于出线间隔, 必须满足一致性约束, 即变电站的所有出线间隔在两边的描述必须一致。间隔的一致性比较主要是命名一致, 以及间隔内的域拓扑一致。

5.2拓扑连接一致性校验

拓扑连接一致性主要是检测两个模型在设备连接方面是否一致。由于两个模型的拓扑描述存在微小的差别, 故在拓扑比较时, 需要建立一个中间拓扑模型, 该模型将Connectivity Node忽略, 通过一个设备连接表进行描述, 该表的主要结构如表1所示。

通过将两个相连接的设备放入一条表格记录内并建立索引以供拓扑分析时进行快速查找。由于在SCD模型中母线并不是一个设备, 而是一个Connectivity Node, 故在连接表建立时, 需考虑将母线转化为一个设备进行描述。

拓扑连接一致性校验就是比较两个模型中设备的连接是否一致。由于变电站内的拓扑具有复杂度较高, 直接比较非常困难, 因此需要根据变电站内的拓扑连接特性划分区域后按分区域比较。区域内拓扑连接比较是采用确定一个区域源点, 按照设备的连接关系依次遍历整个区域的设备, 遍历时比较两边的连接表内记录是否一致。如在表1中Breaker1与Switch1相连, 则检测另一个模型中的Breaker1与Switch1是否相连, 如不相连, 则可判定两边的拓扑连接不一致。拓扑连接一致性细又可细分为主拓扑连接一致性和间隔拓扑连接一致性。

主拓扑连接一致性分析对象为非强制一致性的核心拓扑, 该拓扑空间包括从变压器到母线的连接关系。由于变电站最核心的设备为变压器, 对于SCD模型, 变压器可以在任何一个设备区域内描述, 如变电站、电压等级区甚至间隔内, 在CIM模型中亦是如此, 因此变压器所在的区域并不能用来判定变压器的连接关系的一致性。所以进行主拓扑一致性校验时, 其源点设定为变压器的某一绕组, 依次遍历到母线设备, 将母线设备作为遍历的终点。分别按照电压等级排列依次查询, 确保两个模型中所有变压器到母线的设备拓扑连接描述一致。

间隔拓扑连接一致性主要是校验各个母线到出线端的拓扑。在区域一致性校验中, 已经确定所有的出线间隔都存在, 母线到出线端的拓扑都对应放于相同的间隔内, 因此间隔拓扑一致性校验, 也是在比较两个模型中相同命名的间隔的内部拓扑结构。拓扑连接的校验采用由源点深度搜索到末端的方式进行逐个设备的查找比对。由于往往存在一个出线间隔连接多个母线, 而出线通常为一个的情况, 故在间隔内进行拓扑连接遍历时, 源点设定为出线端设备, 依次查询到母线, 验证间隔拓扑的一致性。

6结语

厂站作为主站端调度自动化系统数据采集的源端, 提供各种可自描述的配置参量, 维护时仅需在厂站端利用统一配置工具进行配置, 生成标准配置文件, 包括厂站主接线图、网络拓扑等参数及数据模型。在二次系统一体化运维要求下, 主站系统可通过调度数据网获取厂站的标准配置文件, 并自动导入到自身系统数据库中, 避免通过手工对厂站重新进行建模, 厂站端SCD模型与主站端CIM模型对同一个厂站的描述的一致性对于电网自动化调度运行具有十分重要的意义。

SCD模型与CIM模型一致性包括信息一致性及拓扑一致性两层含义, 前一个重点强调两个模型都能够一致的描述厂站内的一次设备信息以及二次信息, 后者强调设备间有着一致的连接关系。当两个层面都满足要求, 才能确保模型符合一致性约束。因此, 在模型从厂站端导出并在主站端导入过程中, 必须对模型的一致性进行测试。本文对SCD模型与CIM模型一致性测试方法进行研究, 从而有效确保厂站源端与主站端模型的一致性, 对于厂站与主站二次系统一体化建设具有十分重要的意义。

摘要：本文针对电力二次系统一体化运维中, 由于模型描述框架不一致, 厂站端SCD模型与主站端CIM模型的之间相互转换的过程中产生的差异进行了分析, 并在此基础上对SCD模型与CIM模型的一致性测试技术进行了研究。提出一种SCD与CIM模型一致性和拓扑一致性校验测试方法, 实现二者在不同模型描述框架下的分析与校验, 有效保证厂站与主站从信息到拓扑的一致性, 对于厂站与主站二次系统一体化建设具有十分重要的意义。

关键词：SCD,CIM,二次一体化,一致性测试

参考文献

[1]汪际峰.南方电网一体化电网运行智能系统建设初探[J].南方电网技术, 2012, 6 (2) :1-5.

[2]丁宏恩, 赵家庆, 苏大为等.智能变电站和调控主站的模型按需共享技术[J].电力系统自动化, 2012, 36 (22) :73-77.

[3]谢善益, 高新华, 周伊琳等.IEC TC57 CIM和IEC 61850 SCL模型整合及UCIM构建[J].电力系统自动化, 2009, 33 (17) :61-65.

[4]周伊琳, 谢善益.61970 CIM模型与61850 SCL模型比较[J]广东科技, 2009, 16:192-194.

[5]罗建, 朱伯通, 蔡明等.基于CIMXML的CIM和SCL模型互操作研究[J].电力系统保护与控制, 2011, 39 (17) :134-138.

测试模型 篇5

作者：樊光中

“四性测试与评价模型” 是以流程为监察对象的效能监察关键方法技术。以企业的业务流程的运行效能为基本分析单元，建立企业管理效能“四性测试与评价模型”即以企业管理效能的充分性、符合性、有效性和适宜性四个维度为基本框架的测试与评价结构是现代企业效能监察方法的核心内容、主要理论与主要技术特征。

“四性测试与评价模型”解释如下。

1、制度建设充分性。按照企业内部控制理论、风险管理理论、业务流程理论等现代企业管理理论，建立企业生产经营核心业务流程的控制制度体系框架要素指标，对照这些框架要素指标形成测试与评价指标，测试与评价业务流程现有控制制度体系内容的框架要素与过程结构是否齐全、完备即测试与评价制度建设情况的充分性。充分性是针对业务流程控制制度体系的系统风险中制度盲区、制度空缺风险而言，即业务流程控制制度体系建设覆盖业务行为全过程的充分、完备程度。充分性测试与分析一般采用审阅与询问相结合的监察方法，目的在于评估目前企业业务流程控制制度体系覆盖业务行为过程的充分性情况，并且发现制度盲区和制度空缺。

2、业务过程符合性。按照企业针对业务流程建立的现有有效控制制度体系的内容，建立检验业务行为过程是否符合制度要求的测试与评价指标，对业务人员的经办业务的过程符合企业业务流程现有的控制制度体系的情况进行测试与判断。符合性是针对业务执行过程偏

离、执行偏差风险而言。制度体系的建设最终目的在于贯彻执行后对企业业务过程发挥控制与规范作用，实现业务的预期控制目标。符合性测试与评价过程是对业务行为过程执行企业现有业务控制制度体系的情况进行符合性测试与判断，一般采用穿行控制性测试、审阅、观察与询问等监察方法，其中的穿行控制性测试方法是符合性监察的主要方法。

3、执行结果有效性。按照企业管理层确定的各业务绩效考核目标，建立业务执行结果有效性测试与评价指标，对业务执行的实际结果是否达到预设的管理与经济绩效指标进行对比测试与评价。有效性是针对业务执行行为结果失效风险而言。所有的制度要求和业务管理都必须以实现企业预期的业务管理目标与经济绩效为标准，业务执行有效性测试与评价过程是对业务流程运行、业务执行结果的有效性进行测试与认证，一般采用指标对比、审阅、观察与询问等监察方法，其中的指标对比方法是有效性监察的主要方法。

4、制度设计适宜性。按照企业业务流程理论、PDCA循环原理等理论建立业务流程的过程程序控制指标，并形成检验业务流程现有的过程程序控制制度是否科学合理、经济有效的制度设计适宜性测试与评价指标。对业务流程控制制度体系设计本身内容的科学合理、经济有效情况即适宜性进行测试与评价。适宜性是针对业务流程控制制度体系的系统风险之制度体系控制功能丧失风险而言。有制度并不一定就能够具有控制业务过程、管理风险的作用，制度设计必须科学合理、经济有效即适宜。制度设计适宜性测试与评价过程是对业务流程的控

制制度体系本身进行适宜性测试与分析，一般采用穿行实质性测试、审阅与询问相结合的监察方法。

制度建设充分性、业务执行符合性、业务执行有效性和制度设计适宜性四个方面是测试与评价企业业务流程管理效能的有机统一体，不可分割，四个方面是一个完整的PDCA循环测试与评价过程。充分性和适宜性是监察制度建设的两个维度，符合性和有效性是监察制度执行的两个维度。效能监察实质是对制度建设与制度执行两个方面的监督管理。

测试模型 篇6

摘 要：随着网络教育的发展，网络教育规模日益扩大，实现资源的可重用性以及系统的互操作性成为网络教育发展面临的主要问题。网络教育技术标准化是解决该问题的根本措施，但是规范或标准大多是用文字表述的，具有二义性，因此有必要对标准或规范的实现进行一致性测试。本文从学习设计规范出发，探讨了一致性测试的模型、方法及其过程，最后介绍了基于上述模型所开发的学习设计规范一致性测试系统。实验证明，该测试系统能够很好地完成学习设计规范一致性测试的要求，并且能够大大提高资源的可重用性及系统的互操作性。

关键词：一致性测试 学习设计 学习设计规范一致性测试

中图分类号：G434 文献标识码：A 文章编号：1673-8454（2009）01-0052-04

一、引言

随着网络教育的发展，网络教育规模日益扩大，实现资源的可重用性以及系统的互操作性成为网络教育发展面临的主要问题。虽然许多教育技术专家已经开始关注如何实现资源的共享、跨平台使用，并提出了大量的规范标准，如学习对象元数据规范、内容包装规范、测试互操作规范等，但是这些研究过分地强调学习内容的可重用性，而忽视了学习过程的设计。

2003年，IMS提出了学习设计（LD）规范，它是对学习单元设计过程的描述，支持学习过程的多种学习策略和教学方法的使用，提供多角色的学习过程，是一种强调学习活动设计的规范。它的目标是提供一种能够用正式的方式描述“教—学”过程中元素的框架。具体来说，学习设计规范应符合以下要求：完整性、教学的灵活性、个性化、形式化、重用性、互操作性及兼容性等。[1]

但是规范或标准本身并不能满足互操作性的要求，因为规范或标准文本基本上是使用自然语言描述的，存在着很大的二义性和模糊性，表现为叙述过于简单或复杂难以理解、例外处理没有定义以及标准本身存在矛盾或错误等，实现者对于规范或标准的不同理解会导致不同的标准实现，从而导致其产品不同程度地与标准的不一致。[2]目前，关于学习设计规范的研究还尚未成熟，内容过于复杂，不利于课程设计者对规范的理解；另外对于一些基于学习设计规范研发的工具，虽然使用相对方便，但是还存在着一些问题。例如，Reload学习设计编辑器，它需要用户具备一定的技术知识背景。因此，有必要对学习设计规范的实现进行一致性测试。然而，如何进行学习设计规范一致性测试尚待研究。[3]

下文将在学习设计规范的基础上，深入探讨一致性测试的模型、方法及其工具实现。

二、学习设计概念模型

1.学习设计概念模型

学习设计概念模型，如图1所示，定义了学习设计规范中的基本概念和各种关系，体现了学习设计规范的核心概念和基本思想。学习设计规范提倡按照一定的方法从活动中学习。无论在何种教学模式中，每个人都会承担一定的角色（学习者或者教师），然后根据各自的角色在环境中进行学习活动或支持活动，同时生成活动的结果。因此在学习设计中包含了许多元素，如角色、方法、活动、环境等。为了促进规范的产生和相继地执行，学习设计的实施又划分为三个层次：A层、B层和C层，其复杂程度依次增高。A 层中包含支持教学多样性的核心元素, 主要有方法、角色、活动、环境等；B层包含了A层的全部要素, 并增加了“属性”和“条件”两个元素；C层包含了B层的全部要素，并增加了“通知”元素，它是由学习结果触发的。[4]

2.学习设计规范与其它规范的关系

（１）学习设计规范与内容包装规范的关系

学习设计规范综合了其他规范，如内容包装规范、学习对象元数据规范等。学习设计的主要用途是通过一个内容包来包装学习设计以模型化学习单元。一个内容包当且仅当包的内容清单的组织部分中包含一个有效的学习设计元素时才被称为“学习单元”。一个学习单元=内容包+学习设计。技术上, 通过把学习设计元素包含在一个内容包的清单中来实现。如图2展示了如何将学习设计整合到内容包装模型里。[1]

（２）学习设计规范与简单序列化规范的关系

学习设计规范与简单序列化规范之间既有相同点，又有不同点。二者的相同之处体现在：提供序列化机制；被整合在内容包装模型里；主要是针对学习活动进行设计。

学习设计规范和简单序列化规范的主要区别如表1所示。

三、一致性测试模型研究

一致性测试是验证标准的实现与相应标准要求符合程度的符合性测试，包括语法和语义上的一致性测试。[5]

1.一致性测试模型

学习设计规范一致性测试是对包含学习设计信息的文件实例（即XML文档）进行一致性测试，然后根据测试的结果，给出测试报告，揭示被测实例与学习设计规范是否一致。

具体如下：首先，使用软件工具导入被测试对象（XML文档）；然后，调用XML文档解析器或验证器（Java中的Parser或Validator），根据现有的标准的XML Schema（或者XSD文件），判断被测对象是否结构完整以及是否与标准一致；最后，根据测试结果，导出测试报告。其模型如图3所示。

2.一致性测试方法与过程

学习设计规范一致性测试对包含学习设计信息的文件实例（即XML文档）进行测试，一方面要验证XML文档的合法性，另一方面要验证XML文档的有效性。换句话说，一方面要看其是否符合XML语言的语法规则，另一方面要看其是否符合学习设计规范。

学习设计信息模型描述了学习设计规范的数据结构，列出了与学习设计相关的数据元素。这些数据元素可以分为核心元素和扩展元素，核心元素又分为必须数据元素和可选数据元素。另外，信息模型还规定了每个数据元素及其属性的类型和取值范围。如表2所示。对于各个学习设计的实例来说，必须数据元素是必不可少的，可选数据元素和扩展元素可以有，也可以没有。因此对于某个学习设计实例来说，如果包含所有的必须数据元素，且所有的数据元素类型均采用的是规定的数据类型且在取值范围内，那么该实例与学习设计规范是一致的；如果不包含必须数据元素，或者未包含所有的必须数据元素，或者数据元素采用的不是规定的数据类型，或者数据元素的取值不在取值范围内，那么该实例与学习设计规范是不一致的。[1][6][7]

四、一致性测试工具实现

依据上面所提出的一致性测试模型和方法，同时在借鉴Reload Learning Design Editor的基础上，我们开发出了学习设计规范一致性测试系统。该测试系统是基于Eclipse开发的，其核心是对包含学习设计信息的XML文档进行验证（或测试）。

1.一致性测试工具实现过程

学习设计规范一致性测试的核心是测试，也就是对包含学习设计信息的XML文档进行验证。因此解决如何验证XML文件是实现一致性测试的关键。该系统采用了Java语言的XML验证API，它可以快速检查输入是否符合预期的形式。Java5引入了javax.xml.validation包，该包提供了独立于验证模式语言的验证服务接口。javax.xml.validation API使用三个类来验证XML文档：SchemaFactory、Schema和Validator。验证过程主要有以下五个步骤：

（１）为编写模式所使用的语言加载一个模式工厂，如下所示：

SchemaFactory schemaFactory=SchemaFactory.newInstance；

（２）编译源文件中的模式，如下所示：

Source one=new StreamSource("schemaValidate/cp_v1p1.xsd");

Source two=new StreamSource("schemaValidate/A/LD_Level_A.xsd");

Source three=new StreamSource("schemaValidate/md_v1p2p4.xsd");

Schema schema=schemaFactory.newSchema(new Source[]{one,two,three});

（３）用编译后的模式创建一个验证程序，如下所示：

Validator validator=schema.newValidator();

(4)为需要验证的文档创建Source对象，如下所示：

Source source=new StreamSource("learningdesign.xml");

（５）验证输入的源文档，如下所示：

validator.validate(source);

在验证的过程中需要注意以下几个问题：

（１）在该系统中我们采用标准的ＸＳＤ文件而不是采用标准的DTD文件来验证XML文件，主要有以下几方面原因：首先，XML Schema事实上是XML的一种应用，它与XML有相同的语法结构以及相同的合法性验证机制，便于使用；其次，XML Schema提供了较多的数据类型，更重要的是它支持用户自定义的数据类型，增强了数据类型的灵活性，因而更容易对数据类型进行限制，提高测试结果的准确性；再次，XML Schema是一个开放的模型，在XML文档中加入扩展元素不会发生验证错误；最后，XML Schema完全支持命名空间，一个XML文档可以由多个XML Schema文档来描述。

（２）学习设计规范一致性测试不仅包括学习设计自身的测试，还包括内容包装以及学习对象元数据的测试。因此，该系统涉及如何调用多个XSD文件来验证XML文档的问题，也就是如何调用三个相关联的XSD文件：cp_v1p1.xsd、LD_Level_A.xsd、md_v1p2p4.xsd。为了解决该问题，需要在相应的XSD文件中运用将其他命名空间中的元素包含进来。

（３）若包含学习设计信息的XML文档不符合学习设计规范，并且存在多处错误，如果仅使用“validator.validate（ｓｏｕｒｃｅ）；”进行验证，则只能够显示出一条错误信息。为了将XML文档中的多处错误全部显示出来，便于用户快速修正所有的错误，需要自定义一个错误处理类ErrorProcessor，该类继承于DefaultHandler，重写其中的错误处理方法，然后通过使用“ErrorProcessor ep=new ErrorProcessｏｒ（）；ｖalidator.setErrorHandleｒ（ｅ）；”来调用类ErrorProcessor中的错误处理方法，从而将XML文档中的错误全部显示出来。

2.一致性测试系统的主要测试界面和测试结果

前面介绍了一致性测试系统的实现过程，下面将简要介绍该系统的一些主要测试界面及测试结果。由于该测试系统借鉴了Reload学习设计编辑器，增加了学习设计编辑模块，因此，该测试系统不仅可对包含学习设计信息的XML文档进行测试，用户还可方便地进行可视化的学习设计，避免手写繁琐的XML文档。

首先，用户可以使用该系统提供的学习设计模块来创建包含学习设计信息的XML文档。单击“文件”→“新建”→“学习设计”，选择用于存放XML文档的文件夹，选择好文件夹后，用户可在如图4所示的界面上进行学习设计，设计完成后单击“文件”→“保存”，在选择的文件夹中将产生相应的XML文档。

然后，用户可对包含学习设计信息的XML文档进行测试。单击“工具”→“测试”，如果该文档不符合学习设计规范，将显示如图5所示的测试报告，该测试报告不仅显示出了所有的错误，而且显示了出现错误的位置，便于用户准确地定位和修改。

该系统还提供了详细的帮助文档，用户初次使用时可参照帮助文档进行操作。

五、小结

一致性测试是保证标准实现的正确性和有效性的重要手段，是提高资源的重用性和系统的互操作性的重要手段，也是推广和落实学习设计规范的一个必要手段。[8]因此，对基于学习设计规范生成的XML文档进行一致性测试是十分必要的。但是，目前所开发的学习设计规范一致性测试系统只是对学习设计A层的设计和测试，有待于进一步扩展和完善。

参考文献：

[1]IMS Learning Design Information Model [S]. http://www.imsglobal.org/learningdesign/index.html

[2]陶勇,杨贯中,孔婷.CELTS.10标准一致性测试系统[J].计算机工程,2004年10月，第30卷第20期.

[3]曹晓明,何克抗.学习设计和学习管理系统的新发展[J].现代教育技术,2006(4).

[4]周跃良,曾苗苗,李欣.基于IMS学习设计规范设计和开发面向过程的网络课件[J].中国电化教育,2007(7).

[5]张冬敏,阎保平.SQL标准符合性测试相关问题探讨[J].计算机应用与软件,2007年5月,第24卷第5期.

[6]IMS Learning Design Best Practice and Implementation Guid [S]. http://www.imsglobal.org/learningdesign/index.html

[7]IMS Learning Design XML Binding [S]. http://www.imsglobal.org/learningdesign/index.html

电力调度数据网测试模型 篇7

电力调度数据网是承载调度生产控制业务的专用网络,是实现各级调控中心间及调控中心与厂站之间实时生产数据传输和交换的基础设施[1,2,3,4]。随着电网建设步伐的加快,调度数据网的规模逐步扩大,设备的种类也越来越多,其稳定可靠地运行对于电网安全生产至关重要。近年来,随着微电子技术的发展,网络设备在体系架构、容量、接口等方面发展迅速。如何正确选择适合行业特点、满足应用业务需求的网络设备,成为不得不思考的问题。电信行业网络设备入网检测开展较早,组织专业队伍对入网设备进行针对性测试,指导网络设备的选型,主导着网络设备的发展。电力行业的业务特点与电信行业有着较大的区别,如果采用通用的网络设备,不能完全满足电力系统实时生产控制的要求。因此, 按照电力调度数据网的需求来设计专有的测试模型,验证设备的可用性及可靠性,可促进调度数据网络设备的产品提升与持续改进,更好地服务调度数据网的发展。

国家电网公 司电力调 度数据网 (SGDnet)于2002年建设,2003年9月投入运行。2006年,国家电网公司发布了调度数据网省网建设指导意见,进入省网 的集中建 设时期,实现了厂 站全面覆 盖。2009年,开始了国家电力调度数据网骨干网双平面和各级接入网的建设,2010年逐步投入运行。但随着电力调度数据网规模的不断扩大,在运行过程中凸显出一些问题,其中组网结构和设备间兼容性的问题最为突出。在分析了调度数据网业务特点和研究现阶段调度数据网组网结构及路由器设备特点的基础上,通过对主流网络设备的测试验证,提出并建立了一套调度数据网的测试标准模型。通过近3年的不断验证,经过该模型的测试,可有效避免网络设备潜在的组网和兼容性问题。

1 调度数据网现状研究

电力调度数据网的建设按照“标准化建设、同质化管理”的原则稳步推进,各省的网络架构基本一致。现阶段调度数据网的主要业务及组网结构简单 介绍如下。

1.1 调度数据网业务类型及要求

调度数据网作为电网调度生产业务的基本传输和应用平台,主要承载的调度业务分为安全Ⅰ区业务、安全Ⅱ区业务和应急指挥系统业务。各类业务信息的传输优先级、传输频度以及传输的可靠性等要求各不相同,具体如表1所示。

从表1中可以看出,对于安全Ⅰ区和应急指挥系统的业务,优先级和可靠性要求最高,任何情况下都应保证业务可靠地传输,因此在调度数据网建设时应重点考虑路由器设备的冗余性配置、网络结构路由的连续性规划等问题,也是调度数据网测试时应关注的重点。在网络拥塞情况下,应合理地采用服务质量 (QoS)策略,保证重要 的业务优 先转发。因此,在测试中应设计相应的功能测试用例,来验证策略的有效性及网络设备相关功能的满足程度。

1.2 现阶段的调度数据网结构

电力调度数据网采用双平面方式构建,通过对全网的统一规划,全面满足调度业务的实时性、可靠性、安全性要求,实现可持续发展。调度数据网采用分层网络结构,具体分为骨干网和接入网两级网络, 国调、网调、省调、地调节点组成骨干网,各级调度直调厂站组成相应接入网,县调(区调)纳入地调接入网络[5,6,7]。骨干网和接入网内部均按核心层、骨干汇聚层和接入层进行分层设计,核心层为网络业务的交汇中心。通常情况下,核心层完成数据交换功能; 骨干汇聚层位于核心层和接入层之间,主要完成业务的汇聚和分发;接入层主要将用户业务接入网络, 实现质量保证和访问控制。调度数据网网络结构如图1所示。

为保证接入网接入的可靠性,接入网分别接入骨干网的双平面,接入网核心节点与骨干网节点采用OptionB的方式跨域互联,同时各接入网间不设直接互联路由,若有业务需求,通过骨干网连接。

省调接入网整体分为省级接入网和市级接入网。省级接入网与骨干网通过三点互联。省级接入网的省调节点与骨干网第1、第2平面的省调节点背对背互联,作为互联的第1路由;省级接入网的备调核心与骨干网第1、第2平面的备调节点背对背互联,作为互联第2路由;省级接入网各地调汇聚节点与相应的骨干网第1、第2平面地调节点通过背对背互联,作为平级路由,当第1路由和第2路由失效时采用垂直上联转发数据流量。市级接入网与骨干网通过两点互联,市级接入网的地调核心节点与相应的骨干网第1、第2平面地调节点背对背互联, 作为互联的第1路由;市级接入网第2出口核心节点与骨干网第1、第2平面另一地调节点通过传输网互联,作为互联 第2路由。省调接 入网拓扑 如图2所示。

现阶段调度数据网组网主要基于多协议标记交换的虚拟专用网(MPLS VPN)体系结构,采用边界网关协议(BGP)、开放最短路径优先协议(OSPF)和中间系统到中间系统的路由选择协议(ISIS)等动态路由协议,因此对于不同网络设备路由协议的一致性、组网兼容性以及一些调度数据网的特殊应用是调度数据网测试所关注的重点。

2 路由器设备的发展

随着网络技术的迅猛发展,路由器历经了几代的发展,从总体上而言,根据其体系架构可分为集中式和分布式两种[8,9]。早期的路由器均属于集中式的架构,性能受总线及CPU处理能力的限制,目前仅在低端路由器中还有应用。集中式路由器典型架构如图3所示。

图3中:CLI表示命令行接口;SNMP表示简单网络管理协议;FTP表示文件传输协议;SSH表示安全外壳;Syslog表示系统日志;IGMP表示互联网组管理协议;FIB表示转发路由表;Adj.表示调整; MAC表示媒体接入控制模块;PHY表示物理层模块;CON表示控制功能;AUX表示辅助功能;MGE表示管理功能。可以看出,设备控制和转发都集中在主控板处理,整机的处理能力只取决于主控板,因此即使设备能提供较多的接口卡,其在性能上也无法提升,存在性能瓶颈,可扩展能力差。

中、高端路由器,如核心、骨干、汇聚路由器等, 一般采用分布式架构,控制与转发相分离,具有很好的性能及业务扩展能力。全分布式路由器典型架构如图4所示。

图4中:ASIC表示专用集成电路;NPU表示网络处理单元;Framer表示组帧。可以看出,全分布式架构路由器实现了控制和转发的分离,有独立的控制平面和数据平面。设备引擎只负责 控制平面 (设备管理、路由计算等),线卡分布式完成数据转发,并且各个线卡相互独立,整机数据转发能力随着线卡数量增加而倍增。因为线卡间相互独立,某一块线卡故障不影响其他线卡的数据转发,整机可靠性也随着线卡数量的增加而提升。

表2给出了集中式架构和分布式架构路由器在多个方面的比对情况。

随着CPU技术的发展,为降低设备成本,基于高性能CPU设计的路由器也能达到汇聚甚至骨干路由器的性能要求,虽然可以配置两个转发引擎,但整机性能并无扩展的空间。如何衡量和鉴别路由器的系统架构、设备所在的层次及其可扩展性、升级能力等,也是调度数据网测试时需注意的问题。

3 调度数据网测试模型

3.1 调度数据网测试的必要性

随着调度数据网规模的逐渐扩大,网络设备的种类和数量急剧增加,承载的业务容量和类型也在逐渐增多,组网方式日渐多元化,为保证调度数据网的稳定安全生产和运行,有必要开展调度数据网设备的入网测试工作。

1)电力调度数据网业务的特殊性

电力调度数据网的稳定安全运行关系国计民生,业务的实时性、可靠性要求高,与电信行业有着较大的区别,通用的网络设备不能完全满足电力系统实时生产控制的要求。

2)路由器设备更新换代加速

芯片技术的飞速发展使得路由器设备的开发周期逐渐缩短,产品、版本的升级换代也在加快。设计电力调度数据网的专有测试模型对入网新设备、新版本进行测试,可以有效地避免一些潜在问题。

3)测试标准不够完善

目前国内路由器设备的标准主要是参照邮电部发布的标准,协议的基础来自请求注解(request for comments,RFC)文档。邮电部的标准主要是针对单机进行测 试,组网和兼 容的测试 并未涉及。而RFC文档对于协议中的要求有些比较重要是必选的,也有一些是任选的;某些要求在路由器的应用中非常关键,而有些并不重要,厂商会因特定原因选择不同的特性。尽管都是参照相同的标准来设计,各制造商的路由器设备功能还是存在一定的差异。因此,对于由不同制造商和不同型号的路由器组成的调度数据网而言,很有必要进行兼容性和组网的测试,这样可大大缩短网络建设和扩容时的调试周期。

4)与通用性测试存在差异

运营商网络设备的测试采用通用测试方法,主要注重于单机协议一致性(与标准的符合程度)的测试,一般有专门的协议一致性检查工具进行自动测试,不进行组网和兼容性测试,因此通用的测试方法满足不了电力系统业务特殊应用的需求。为保证电力调度数据网运行的可靠性和稳定性,应侧重于业务应用设计专门的测试用例,特别是在MPLS VPN标签应用、兼容性和组网结构等容易产生问题的方面。

在分析了调度数据网业务特点和路由器架构的基础上,综合实验室对国内主流网络设备的测试结果,本文提出了性能、兼容性和组网的测试模型,为电力调度数据网的建设和运行提供服务。

3.2 性能测试模型

对于路由器的设计,制造商在性能方面给出的宣称值一般都为理论值,实际的容量与实际配置的主控板、交换板或是线卡的版本有关,理论值与实际配置所能到达的值之间有一定的差异。因此,在性能测试方面,特别是对于中、高端的路由器,应考虑整机最大容量和典型配置所能达到的容量两种情况。通常这两种情况下所采用的主控板、交换板和线卡等板卡不是同一型号,因此,通过测试可判断出路由器设备性能的可扩展性和可升级程度。这里给出的性能测试模型如图5所示。图中:VPN表示虚拟专用网;ACL表示访问控制列表。

对于路由器设备的路由容量性能测试,应注意在路由器默认内存分配的情况进行测试,以防止通过内存调整得到单项高性能指标而占用了其他应用的内存分配。同时路由容量的测试应通过双向满载的流量来验证,并且保证负载流量字节分配的均衡性。这里应注意所有的性能项测试时都应在路由器默认配置参数下进行。

对于路由器最大容量的测试,这里采用全交叉 (fully-meshed)的测试拓扑[10],可以有效地测试设备真实容量。通过测试可杜绝制造商虚报性能指标的情况发生。

通过该性能模型的测试,可获得路由器设备的主控/交换容量、线卡带宽等主要性参数,并可判断路由器的可扩展性能和可升级空间。

3.3 兼容性测试模型

现阶段国家电网调度数据网中在运行的网络设备主要来自国内主流的三家网络设备制造商(华为、H3C和中兴),高、中、低端设备 约有30个型号左 右。随着中、低端厂家高端产品的出现,未来入网厂家可能会逐渐增加。为了尽可能减少和避免不同制造商的不同设备组网时可能产生的问题,良好的设备兼容性是顺利组网的重要前提。

目前电力调度数据网中设备间互连的物理接口主要包括E1,POS,cPOS和GE等。网络协议包括内部网关协议(IGP)、BGP、MPLS等。因此,从接口、协议两方面来对设备兼容性进行测试,可有效地解决不同厂商设备对接的兼容性问题,兼容性测试模型如图6所示。图中:RIP表示路由 信息协议; MP-EBGP表示BGP-4的多协议扩展,其中EBGP表示外部边界网关协议。

该测试模型中,路由器之间的链路按E1,POS, cPOS,FE/GE和捆绑链路分别进行测试。两台设备分别配置3个VPN,每个VPN采用不同的协议, 路由器之间采用OptionB方式跨域互联。接口和协议配置时 应关注的 主要参数 列于表3中。表中: NTP表示网络时间同步。

该兼容性测试模型覆盖了现网中所有用到的接口和协议,测试拓扑简单,测试效率高,协议兼容性配置一次可全部完成。由于物理接口的不同,接口的兼容性需分别按接口测试。

3.4 组网测试模型

国网调度数据网目前网络设备的产品系列分类较多,不同系列产品的命令配置、功能实现的方式、性能等都存在差异。随着新的系列产品的逐渐加入,会使得今后网络的可靠性面临严峻的挑战。根据目前调度数据网双平面、分层的组网结构设计组网测试模型如图7所示。

图7中:骨干网平面1(AS100)、骨干网平面2 (AS200)、接入网A(AS300)、接入网B(AS400)配置为独立的自治系统(AS),每个AS内的路由器均运行多协议扩展的内部边界网关协议(MP-IBGP), 自治系统间的互连按OptionB跨域方式进行配置; 测试仪的端口1至5与路由器A-R1,B-R2,C-R4, A-R4,C-R6连接,并建立EBGP邻居。测试仪模拟用户边缘设备(CE),与测试仪相连的路由器配置为运营商边缘设备(PE),接口上划分为3个子接口, 分别绑定3个VPN,代表实时业务(vpn1)、非实时业务(vpn2)和应急业务(vpn3)。三类业务VPN全网完全独立,VPN内各节点实现完全互通。

该组网测试模型覆盖了目前调度数据网的双平面网络架构,网络结构简单高效,灵活可扩展。在该组网模型上可实现目前现网用到的所有类型接口的对接和协议功能的验证,并可实现多种功能在组网模型中的叠加测试。

根据调度数据网目前的运行情况,在此组网模型上设计了路由汇聚、路由策略、路由探测、VPN互通、QoS策略、网络管理、可靠性、网络安全以及全网NTP同步等方面的测试用例,全面覆盖目前电力调度数据网的应用,具体内容如表4所示。

利用组网测试模型,通过表4所列测试用例的测试,发现了网络设备的设计存在不少差异性。督促设备制造商解决相应的问题,可避免在现网运行中发生类似的情况。通过该组网模型的测试,在一定程度上可保证不同厂商设备联合组网的稳定运 行。同时在该模型上还可根据调度数据网的发展和新应用扩展新的测试用例。

4 测试模型验证

通过以上给出的性能、兼容性和组网测试模型的测试,在对主流网络设备测试的过程中发现并解决了不少问题,其中比较具有代表性的一些主要问题如表5所示。

从表5中可以看出,制造商提供的宣称值一般都高于实测值。通过该性能测试模型的测试,有效地规范了制造商对于性能指标的定义。

对于兼容性模型和组网模型测试中发现的问题,通过专业技术分析,有的是配置问题,有的是软件BUG,有的则是功能设计方面的缺陷。制造商针对发现的问题及时进行了修正,有效地避免了在实际应用中发生类似的问题。

近几年主流网络设备制造商的路由器在测试过程中出现的问题统计情况如图8所示。

从图8中可以看出,各制造商的网络设备在测试过程中的出现的问题逐年降低,性能、功能也得到了提高。通过系统性地测试,有效地促进了制造商对投入电力调度数据网设备质量的重视。

5 案例简析

在本文构建的组网测试模型基础上,对某省出现的故障问题进行了离线分析。在该组网测试模型上可完全复现出故障现象。通过测试和分析,很快地定位到了故障点,通过分析原因,给出了相应的解决方案。具体过程描述如下。

1)故障现象

某区路由器A与某省备调路由器B通过某区路由器C透传,进行BGP路由交互时,邻居状态出现振荡,大字节报文被丢弃。

2)故障复现

在图7所示的组网测试模型中,A-R1为路由器A,A-R2为路由器B,B-R1为路由器C,并且将路由器C的软件版本恢复成现场的故障版本。测试仪Port端口1分别发送5 000,1 000和100条BGP路由进行测试,出现了一致的故障现象。

3)故障定位及原因分析

通过现象判断为大包数据被丢弃。分析路由器C从GE接口收入的大路由的更新报文经网络处理器处理后,报文字节长度发生了变化,比接口卡设置的最大接收单元(MRU)值多了2B(点对点协议中未设置压缩[11,12]),因此报文被丢弃,导致了路由振荡的产生。

4)故障解决方案

通过软件升 级将C路由器cPOS接口卡的MRU值修改为9 600,进行验证测试。测试仪发送2×105条路由进行测试,BGP邻居状态稳定,未出现振荡,发送1 518B报文数据,未发生丢失,问题得到解决。

从上述的案例分析可以看出,本文给出的组网测试模型可很好地对现网运行情况进行离线模拟, 不仅可用于故障问题的分析,还可作为调度数据网升级或扩建的离线验证,缩短了建设周期,增强了调度数据网的可维护性。

6 结语

综合实验室测试情况,本文提出的性能、兼容性和组网测试模型能够对网络设备进行较为全面的测试。组网测试模型简洁有效地模拟了现网的运行环境,覆盖了电力调度数据网的全部业务场景。随着电网技术的不断发展,电力调度数据网的规模逐渐扩展延伸,远程遥控、远程运行维护和浏览等多元化的业务需求将会逐步得到发展,加之IPv6技术未来在电网中应用等,对电力调度数据网的性能、功能、实时性、可靠性和安全性的要求将会越来越高。在测试模型上根据电力调度数据网的运行状况进行测试模型的调整以及测试用例的扩展,以适应调度数据网的发展,做到测试与应用的同步更新,是电力调度网测试所面临的新的挑战。

摘要：随着电力调度数据网的规模及业务应用逐步扩展,入网路由器设备类型不断增加,设备的组网特性、性能和兼容性等技术要求对于调度数据网络的安全稳定运行起着重要的作用。在分析了调度数据网的现状、业务类型、组网结构及路由设备发展的基础上,提出了一种调度数据网的性能、兼容性和组网测试模型。经过3年的实践证明,该模型涵盖了目前调度数据网的全部业务应用场景,进一步规范了设备入网测试工作,促进了调度数据网络设备的产品提升与持续改进。

软件测试改进模型研究进展 篇8

软件测试模型即在测试实践的基础上,有机结合相应的软件开发活动所总结和抽象出的一系列测试活动规律。与软件开发过程一样,软件测试过程同样遵循软件工程原理与管理学思想等。软件测试行业蓬勃发展的同时,对软件质量的关注也接踵而来。目前软件的质量控制越来越难以控制并实施,软件测试模型作为保证软件测试工作效率和质量的结构框架,需通过强化和改进来适应不断复杂化的软件开发过程。随着软件产品开发趋于复杂化、多样化的同时,传统测试模型已不足以适应当前软件测试过程。近些年,已有不少专家学者在深入研究传统测试模型基础上,提出一系列改进模型及其应用方案,作为测试过程及管理活动的重要参考依据。

本文主要对近几年软件测试领域中所产生的一系列测试改进模型的特点及进展作综述性研究。

1 传统测试模型的局限性

传统测试模型即测试V模型、W模型、X模型、H模型与前置模型(模型图详见文献[3],本文不予列出)。近些年许多文献都不同程度的指出以上传统测试模型所存在的一系列局限性以及在指导软件测试过程中的不足之处。介于篇幅所限,这里只作简介。

1.1 V模型

V模型衍生于软件开发瀑布模型,具有瀑布模型所存在的缺陷。尽管其强调测试活动可尽早开始,但是测试活动与开发活动在模型中被划分成具有固定边界的不同阶段,并且难以逾越阶段的边界从不同的阶段中进行测试活动信息的分析与综合。V模型也未能体现出测试设计与规划过程,测试活动在模型中演变为开发过程中的一附带阶段,完全等同于测试执行。各测试活动之间的联系也不甚明确。

1.2 W模型

W模型要求测试与开发活动并行,测试对象并非测试代码本身。但是开发活动(需求、设计、编码)与测试活动(单元测试、集成测试、系统测试、验收测试)始终保持的是一种线性关系,模型也不支持迭代及变更调整等活动。

W模型虽然刻画出各测试阶段与对应的修改工作之间的微循环关系,但是该模型将循环的关系仅仅局限于单个测试阶段之内的做法容易对测试人员造成误导。此外,W模型需要提供有完善的设计文档的支持。

1.3 X模型

X模型是一基于实践的测试模型,由V模型衍生。其强调了可以对单独的程序段进行独立的编码与测试不断进行频繁的交接,通过集成最终成为可执行的程序,再对其进行测试活动。

X模型局限性体现在过份关注程序级别的低级别行为,无法描述完整的软件开发周期活动[5,6,7]。既未指明测试各阶段所需要进行相应的测试设计活动,也无明确的需求角色确认活动。同时X模型中表现出测试活动的松散性,当发生开发需求变更时,却未能给出相应的变更处理方案。

不过X模型引入了探索性测试,希望不需要通过制定复杂的测试计划和设计大量的测试用例来发现更多的软件缺陷。但是探索性测试在实际的测试活动中对测试人员要求过高,容易造成人力及财力资源的浪费。

1.4 H模型

H模型也是对V模型的改进。测试活动作为一独立流程与其它开发(或测试)流程并发进行,贯穿整个软件开发周期。测试条件一旦成熟,完成了测试准备活动,即可开展测试执行活动[9]。H模型的缺陷在于没有把软件开发过程中的测试活动流程具体化,未能提出测试活动如何与开发流程发生交互活动。

1.5 前置测试模型

前置测试模型是在V模型与X模型的基础上所提出。尽管该模型可以对开发过程中每个交付软件产品进行单独的阶段性测试,把对产品的“技术测试和验收测试”相独立。但是模型依旧把开发活动和测试活动对立了起来,采取了“先开发后测试”的过程,没有很好的与实际接轨[10]。

前置测试模型因繁琐复杂而不适合轻量级项目的测试,亦不适合需求变更频繁所采用原型开发的项目测试过程。

2 测试改进模型及结构特点分析

基于上述五种传统软件测试模型中所反映出的局限性,近年来已有不少专家学者对其进行相应的过程改进和优化,或者结合实际测试项目特点设计出新的测试模型并予以应用。改进模型大都遵循“测试先行”的思想,测试与开发活动有效交互并贯穿于软件生命周期。各测试活动之间以及与开发活动的关联性在改进模型中也有一定程度上的体现。

2.1 并行V模型

并行V模型[4]是对传统V模型的一种改进,由中国科技大学周学海等人于2005年提出,如图1所示。

模型的改进主要着眼于实际项目测试中,当较高层次测试阶段(如系统测试、验收测试)发现的软件缺陷有可能会把问题引入到较低的测试层次中(单元测试),缺陷修复后往往要回溯到单元测试阶段进行回归测试检测。

该模型显著特点是允许相邻测试阶段并发执行,各测试流程的执行时间在一定条件下有所重叠,提高测试效率。例如,把作为子系统一部分的模块的单元测试内容延迟至对该子系统集成测试阶段中进行。此外,模型增加了从各个测试阶段指向单元测试的箭头,表示在该阶段发现并修改错误以后回归测试的范围要从单元测试开始[4]。

并行V模型本着“错误越早发现,修复成本越低”的测试原则,一定程度上可以解决测试需求变更频繁的问题。但是模型局限性在于纯粹从测试活动的角度去探讨各测试流程的相互关系,忽视测试流程与开发过程之间的交互准则及交互关系等。

2.2 改进V模型

东北电力学院曲朝阳等人同样于2005年提出了对传统V模型的另一种改进V模型[11],如图2所示。

改进后模型保留了传统V模型框架,但是模型左边的一系列开发活动(需求分析、设计、编码等)不遵循完全相互独立的原则,而在一定程度上并行或交错。模型右边的各测试流程与左边相应的开发流程有所交互。例如,设计阶段(详细设计进行了约二分之一),工作逐步移至单元测试用例的设计中;编码阶段并行执行单元测试用例,着手已集成(或可集成)的模块的集成测试等。

模型中增添了把执行测试用例包括将错误反馈给开发人员,然后根据改正情况,修改、重复执行测试用例的过程[11]。测试人员可以及时修改和完善因后阶段开发结果变更而所受影响的前一阶段设计的测试用例,并予以维护。

改进V模型的优点主要体现在测试与开发活动的交互行为。例如把制定、设计测试计划和编写测试用例工作与软件开发过程中的需求分析、软件设计和编写代码工作并行,克服了测试工作的盲目性[11]。系统设计过程中能够不断地对已有测试用例进行回溯与修改,确保最终的测试用例(集)是基于系统最新发布版本的。

2.3 基于行为的测试模型

基于行为的测试模型[12]由华中科技大学陆永忠等人于2007年提出,如图3所示。

该模型特点是把以行为规格说明同时贯穿于测试与开发两个并行过程。着眼于“软件测试是一定义与组织的过程”思想,本着“测试活动尽早介入软件开发过程中,有效结合测试计划制定、测试用例设计、测试执行及结果分析等测试流程”的测试策略,运用了使用测试场景和基于使用测试用例的建模技术。

软件需求阶段之后得出完整的测试规格说明是模型的基础,在此基础上进行测试场景、测试用例设计,与开发同时进行,测试规格说明在开发过程中不断得到优化与改进。通过测试场景和测试用例来进行单元测试来确认详细设计,通过集成测试来确认概要设计,通过系统测试来验证需求[12]。

基于行为的测试模型要求测试人员从最初就参与软件开发全过程,测试计划、测试设计、测试执行、测试结果分析、回归测试等各个阶段的元素在模型中得到体现。该模型有利于更早地发现需求设计上的错误,亦能有效地选择回归测试的测试用例。

2.4 X改进模型

汕头大学熊智等人针对传统X测试模型结构松散以及不够严谨的局限,于2011年提出一种X改进模型[8],如图4所示。

X改进模型遵循传统X模型的框架,但是增加了迭代测试与回归测试。模型同样分左右两部分,每个部分内部对测试活动的执行次序做出相应调整。模型左半部分(模块单元测试活动)与右半部分(模块间的不断交接,逐步进行集成测试)分别增添了探索性测试和回归测试流程,并要求至少两个模块单元测试结束后才开始集成测试。模型的两个部分的测试过程中要求用户与客户不同程度的参与,并且定义了测试活动中各测试流程所对应的人员角色及任务分配。

模型对各阶段的测试工作进行了验证,提出了测试终止条件,尽可能多地适用各种具体情况下的项目测试过程[13]。

X改进模型的主要优点在于模块的单元测试及集成测试过程中允许迭代测试过程。在某个测试阶段遇到问题可以回溯到之前测试的任一阶段,有效地解决因需求变化而导致测试变更的问题。此外,模型要求对软件需求验证及系统设计工作在测试前期完成,从而确保产品代码实现与客户要求相吻合。产品集成测试的最后阶段加入了验收测试过程,客户和用户一起参与到验收测试中来以确定开发的系统是否满足客户需求[8]。

2.5 前置改进测试模型

湖南师范大学涂洪澄等人于2008年在传统前置测试模型的基础上提出一基于测试驱动及并行工程的前置改进测试模型[10],如图5所示。

该模型针对传统前置测试模型“先开发后测试”不能满足实际软件开发过程的特点,提出了结合测试过程与开发于一体,采取“测试-开发-测试”,即模块测试代码的设计工作提前于其开发过程,测试驱动开发。改进模型中对于循环开发的过程中可以开展单元测试甚至结合几个模块进行集成测试,前提是执行测试活动之前需要编写好测试代码[10]。

前置改进模型强调了开发与测试活动的并行行为。不同的系统组成元素并行开发、系统的技术测试流程与验收测试并行执行、开发某单元模块的同时允许并行执行其它组成模块的测试代码是该模型最显著的三个并行行为。前置改进模型的优点体现在软件开发全过程测试,测试过程与开发过程并行,在编码阶段就开始部分的系统测试,使软件设计中的错误尽早暴露出来[10]。最后模型参考了X模型而引入探索性测试活动,增强测试人员的测试主观能动性,从而进一步保证测试高效性。

2.6 统一测试过程模型

统一测试过程模型[14]由浙江大学胡玮于2006年底提出,如图6所示。

模型依据项目测试在实际中往往存在测试计划周期偏短(测试计划仅在系统分析时制定,没有贯穿于整个项目开发过程)、测试时间开展较晚(代码实现后才进行测试活动)、测试活动不完整(测试活动中只有测试执行,缺少测试需求分析、测试用例设计、测试脚本开发等流程)等因素,借鉴RUP开发模型中核心工作流思想设计测试改进过程。

模型提出将测试过程分为测试计划(包括系统测试计划与软件版本测试计划),测试设计(测试用例设计、测试脚本开发、测试数据准备等),静态测试(开发阶段中每一个可交付产品的需求测试、设计审查、测试策略走查、测试用例审核、代码审核等),动态测试(包括可用性测试、兼容测试、性能测试等非功能测试),测试度量与分析(包括产品度量、过程度量和项目度量)共五个工作流,贯穿于软件开发的整个生命周期[14]。把测试活动中各测试流程合理地分布在软件开发的各阶段中。测试流程间相互交迭并有序的展开,以二维的形式反映出来。

统一测试过程模型具有可以让测试团队与开发团队相互独立,便于有效进行测试过程管理;支持迭代测试来处理实际中测试需求变更频繁的状况;对系统功能方面与非功能方面(可用性、兼容性等)进行全面测试过程的优点。然而模型中缺少清晰的定义测试与开发活动之间的交互关系及联系是其局限性所在。可以增加定义若干主要的交互行为(如测试团队和开发人员在需求分析阶段一起进行软件需求的评审、验证等)作为模型的适当补充。

2.7 改进喷泉模型的测试模型

改进喷泉模型的测试模型[15]由合肥工业大学耿晓伟等人于2009年提出,如图7所示。

该模型在喷泉开发模型[16]基础上改进,迭代思想贯穿整个测试工作。模型中设计了每一次测试过程由测试需求(主要是测试需求提取与需求验证,通过静态测试完成)、测试分析(包括测试计划的制定与测试用例的设计、验证等)、测试执行(单元测试、集成测试、验收测试、系统测试以及相关文档测试)与测试维护(包括以修复软件功能缺陷为主的开发维护和以缺陷修复后的测试验证、增加系统新功能后的回归测试等为主的测试维护)四个阶段组成。

该模型主要优点在于扩大了设计和选取测试用例的范围,包括从程序、文档等所有可使用的信息中获得,提高测试用例的覆盖率,保证测试的充分性和完全性[15]。模型较好地实现了测试与开发的并行活动,及各过程内各阶段之间的同步,提高软件测试质量。

2.8 迭代测试模型

国防科学技术大学陈小勇等人于2008年提出了一种迭代测试模型[17],如图8所示。

该模型设计思想基于软件开发各活动流程交叉进行的特点,测试活动不必遵循一定的顺序关系。当某个测试达到准备测试点时.测试活动就可开展,同时各层次的测试(单元测试、集成测试、系统测试等)是存在反复触发与迭代关系的[17]。模型由文档级测试与软件级测试两个阶段组成,通过引入测试准备点和测试结束出口作为每次迭代测试活动的起始点。

迭代测试模型中明确区分了测试活动中的文档测试与软件测试,测试准备与测试执行活动也清晰地体现出来。其主要优点还是在于保证了测试活动的灵活性,不同的测试活动可以反复进行,不必拘泥于先后顺序。

2.9 基于敏捷开发模式的测试模型

基于敏捷开发模式的测试模型[18]由电子科技大学邹波于2010年针对软件开需求变更频繁所采用的软件敏捷开发模式[19]中提出,如图9所示。

模型反映了测试过程管理的思想,结合了敏捷开发方法中敏捷测试的特点。在充分分析传统测试模型中存在的测试活动介入较晚、不支持迭代开发、不能接受需求变更及小版本发布等问题基础上,在图9所示的一个测试迭代周期中,引入了测试人员参与系统中对客户有价值的程序功能片段(story)的制定、划分与评价来完成对系统需求及设计的验证,测试人员与开发人员共同完成对测试用例的评审。模型还引入了在程序功能片段集成后已通过验收测试所进行的冒烟测试活动,从而检测保证系统是否能运行其基本功能。在决定是否进入下一轮迭代测试之前,模型通过设计迭代验收测试来检验本轮迭代是否达到了预定的验收标准[18]。

模型同样对测试计划与测试策略进行改进。测试计划的制定上,要求一次迭代测试为周期,某轮迭代测试可以部分并行于上轮迭代开发阶段,从而使测试贯穿于整个软件生命周期。测试策略的制定上,要求迭代测试周期内开发人员从事白盒测试为主的单元测试、模块功能测试等来重构与验证代码单元;引入集成验证测试即通过利用自动化测试工具模拟集成测试的过程,验证集成的正确性[18];对某次迭代交付的内容通过引入迭代验收测试进行验证。

模型的优点主要体现在极大提高了单元测试的地位,在测试前期即消除大量隐藏的软件缺陷,从而保证后续测试的质量。通过一轮轮迭代验收测试取代了传统测试中低效的一轮轮系统测试及系统修补,保证软件迭代开发质量。

2.10 敏捷开发模式下的Y测试模型

华中师范大学杨晶利于2009年提出另一种在敏捷开发模式下的模型组成形状像“Y”字的Y测试模型[20],如图10所示。模型同样融合了敏捷方法中的“测试驱动”思想,描述了一个迭代开发周期内即从需求至产品提交用户过程中历经的各测试活动。

模型主体思想即结束了某次迭代开发周期内的详细设计后,开发人员进行单元测试用例代码的编写。通过单元测试用例代码设计模块,并进行单元测试直至模块功能正确且符合用户需求。集成测试在开发人员完成对通过单元测试模块的集成工作后进行,可以适当的与未完成单元测试的模块所进行单元测试过程并行开展。该过程中可以修改或重构单元模块代码直至所有模块的集成通过测试验证。回归测试在被测模块提交用户之前进行,修改或重构可能存在的错误以后再进行测试。最后用户进行验收测试,若发现问题后反馈给开发人员,由其对问题验证、修改,测试人员进行回归测试。用户验收直至产品满足客户需求。

Y测试模型优点在于单元测试用例根据用户需求提前设计,然后由此去编写模块代码,接着通过单元测试,早期阶段可以发现模块的问题,有效地保证了模块的质量[20]。模型允许单元测试与部分模块间的集成测试并行,减少测试时间。测试人员参与需求验证和设计验证,站在用户角度可以发现更多问题。

2.11 基于XP测试驱动的测试模型

基于XP测试驱动的测试模型[21]由西南大学秦晾于2010年在基于轻量级软件敏捷开发方法中的极限编程(简称XP)的开发思想的基础上,针对传统XP开发方法中的测试过程中所存在不足之处所提出的,如图11所示。

文献[21]中深入分析了传统XP开发方法中的测试过程中主要存在的三点不足之处:首先,测试用例驱动详细设计只局限于在单元测试阶段,而需求分析至概要设计阶段仍然采取的是阶段式设计与测试的过程。其次,传统XP方法的测试过程中因为各测试阶段相互独立性导致回归测试往往难以确定测试范围。最后,单元测试用例的设计在模块单元开发中将同时承担开发指导与质量保证的作用,测试无法发现模块单元代码内部功能正确而用户需求不准确的逻辑性错误。

改进后模型根据上述局限性,提出了以测试驱动开发过程的“两部分、四阶段”特征模型。两部分即系统设计迭代与开发迭代,四阶段指验收测试、系统测试、集成测试、单元测试四个阶段测试过程。通过分别设计上述相应四种测试用例来驱动用户需求、系统设计、概要设计与详细设计四个开发过程。在进入编码之后,分别在重构、模块集成、系统架构、版本发布之后,执行相应的阶段性测试,获得错误反馈之后进行系统修改,每个阶段本身都是一个微循环[21]。为保证测试的有效性,模型在单元与集成测试阶段额外引入了独立测试流程,检测模块代码内部的逻辑性错误。最后在回归测试阶段采用了效率较高的RTSM算法[23](算法内容这里不做赘述,可参见文献[20])确定回归测试范围,减小回归测试范围搜索的代价。

介于文章篇幅所限,本文只列出模型中验收测试阶段流程图,如图12所示。验收测试用例的设计直接来源于用户的需求,后阶段的测试用例的设计均来自于对前阶段用例的继承与扩展(如系统测试用例的设计继承验收测试用例的一个或多个,可以进行适当的扩展)。

基于XP测试驱动的测试模型的优点在于整个软件开发周期中通过对各阶段测试用例继承及细化机制的设计体现出测试驱动开发,引入独立测试保证测试直接来源于需求的思想,采用RTSM算法有效确定回归测试的范围。

2.12 基于复用的测试模型

北京跟踪与通信技术研究所尹平于2010年中提出一基于复用的测试模型[24],如图13所示。

该模型主要关注测试活动中测试用例设计以及复用方面。由测试需求及测试策略定义出所需要的测试用例,检索在可复用测试用例库中是否存在满足功能要求的用例(集)。若有,则“提取测试用例”,对其进行分析的基础上确定最合适的,并进行“补充完善”;若无,则设计“新测试用例”[24]。最后对所设计的可复用测试进行是否满足测试需求的审核,在实际的测试活动中总结与分析执行测试用例的结果,纠正或补充其不完善和不充分之处,将所设计出的通过测试验证的测试用例放入可复用测试用例库中,已备下次复用。

基于复用的测试模型避免大量重复性工作,一定程度上减轻测试工作量,有效提高测试效率。但是该测试模型只是着眼于测试活动中具体的测试用例设计环节上,未能从宏观上设计整个测试过程的复用流程,也没有明确地表明测试与开发之间的关系及测试管理过程等。

2.13 基于对比的测试改进模型

郑州大学张文宁等人同样在软件测试用例复用技术研究的基础上,结合CMM/CMMI、6-sigma等软件过程改进方法,于2010年提出一支持复用并基于对比的测试改进模型[25],如图14所示。

模型从软件复用特点所应具备的时间、重现和应用维度三个方面维度强调了测试效率的提高取决于对测试用例的重用来验证功能相近或相似的模块。

测试人员通过对比可重用测试用例库中资源,分析项目功能、规模等因素,设计或复用测试用例作为执行测试的依据。在此基础上分析测试结果并对比于行业水平来确定改进点,综合运用GQM方法[26]建立改进目标与评估改进执行效果。

基于对比的测试改进模型的优点体现在可以有效利用历史测试项目的资源,减少测试用例设计阶段的工作量,方法易于实施,能够促使软件测试过程的持续改进[25]。

3 总结与发展方向

3.1 测试改进模型总结

随着软件质量的重视程度越来越高,在传统测试模型研究的基础上先后涌现出的一系列改进测试模型中,测试活动具有独立的操作流程,只要测试前提具备,就可以着手进行测试工作,测试与开发活动的交互也都较好的得到体现。测试对象不再等同于仅对软件代码部分的测试,软件的需求、设计、架构等方面亦是全方位的测试范畴。测试迭代思想贯穿于整个测试过程,通过实际测试项目实现了不同测试活动之间的并行性,提高测试效率。作为测试活动的指导,设计测试用例的重要性不言而喻。上述不少的改进测试模型中在单元测试、集成测试、验收测试等诸阶段均引入测试用例设计环节,并通过有效选取用例确定回归测试的范围。专门的测试团队进行测试用例的设计、执行、分析与评审,并行于开发过程,旨在开发初期发现更多的错误,避免前阶段错误引入后一阶段而带来的“放大”效应,从而保证测试高效性。

3.2 探索性测试策略

传统测试过程中往往存在设计及执行测试用例过于依赖开发文档、测试执行应对需求变更较差的情况,伴随着测试项目的进展与变化,不断演化的测试用例是测试人员设计与执行的内容。作为传统测试手段的补充,探索性测试不受限于具体的测试场景,而需要测试人员较高的主观能动性和职责。

尽管当前国内外对测试改进模型的研究已取得一定进展,但是鉴于软件开发初期需求变更较大导致测试场景不甚明确、同时缺乏相应开发文档的状况,在借助基于测试人员丰富经验的测试策略及方法上仍存在一些难点,有待进一步研究与探索。

探索性测试策略即基于测试人员丰富的测试经验及手段,重点关注高风险区域测试过程中不断调整测试设计及执行,从而尽快发现潜在的更多缺陷[27]。适用于现代软件项目中所呈现出的迭代开发周期短,开发文档不完全、新功能变更频繁,测试与开发同时开展而要求进行前期尝试性测试等特点。要求测试人员不仅了解被测软件的显示规格说明(如产品需求规格说明等),亦要了解其隐性规格说明。包括测试软件上一版本所反馈的缺陷记录、已发布版本所反馈的用户使用风格、甚至是竞争对手同类产品的使用反馈缺陷等。凭借丰富经验的积累或者类似软件中发现的缺陷记录或失效列表设计测试用例来应对本软件潜在的失效问题。以手动或自动方式在不同的测试过程中反复切换而获得新的测试灵感来执行测试过程,通过制定具体判断准则(如被测对象功能是否与类似产品一致,当前软件表现行为是否与前一版本一致等)用于判断测试用例是否通过。

在传统X测试模型、X改进模型及前置改进测试模型中只是把探索性测试方法作为一条笼统的测试流程引入到模型中,既缺少对探索性测试活动内容的构成进行细致分析与研究,也没有形成完整的过程模型体系,以及具体测试项目的实践情况。目前国外有学者只是基于软件用户图形接口界面测试尝试提出了探索性测试方法[28],但未能实现出完整的体系结构。如何针对实际测试项目构建一套完善的探索性测试过程体系以及与完整的测试生命周期有机结合起来将是未来测试模型研究的热点方向,也是提高软件测试效率的关键。

4 结语

在软件开发生命周期中寻找恰当的测试就绪点,尽早开展测试用例设计活动,并充分发挥测试人员的主观能动性是减少软件缺陷和保证软件质量的有效手段。本文较全面地综述了近几年所出现的一系列软件测试改进模型的特征并进行优缺点分析,提出测试模型中结合探索性测试活动是进一步的研究方向。

软件测试模型的应用研究及改进 篇9

从保证软件质量的角度来说,软件测试是软件质量保证工程的一个重要组成部分,也是最重要的质量保证手段。有研究表明:越早发现软件中存在的问题,开发费用越低,软件质量越高,软件发布后的维护费用越低。为了保证所要提交的软件产品能够满足客户的需求,以及在使用中的可靠性,就必须对所开发的软件产品进行系统而全面的测试。

2 软件测试过程概述

软件测试过程是一种抽象的模型,用于定义软件测试的流程和方法。众所周知,开发过程的质量决定了软件的质量,同样的,测试过程的质量将直接影响测试结果的准确性和有效性。软件测试过程和软件开发过程一样,都遵循软件工程原理和管理学原理。

随着测试过程管理的发展,软件测试人员通过实践总结出了很多的测试过程模型。这些模型将测试活动进行了抽象,并与开发活动进行了有机的结合,是测试过程管理的重要参考依据。

3 传统的软件测试过程模型

3.1 V模型

V模型最早是由Paul Rook在20世纪80年代后期提出的,旨在改进软件开发的效率和效果。V模型反映出了测试活动与分析设计活动的关系,如图1所示。图1描述了基本的开发过程和测试行为,非常明确地标注了测试过程中存在的不同类型的测试以及这些测试阶段和开发过程期间各阶段的对应关系。

V模型指出,单元和集成测试应检测程序执行是否满足软件设计的要求;系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标;验收测试应确定软件的实现是否满足用户需要或合同的要求。但V模型存在一定的局限性,它仅仅把测试作为在编码之后的一个阶段,是针对程序进行的寻找错误的活动,而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。

3.2 W模型

W模型由Evolutif公司提出,相对于V模型,W模型增加了软件各开发阶段中应同步进行的验证和确认活动,如图2所示。W模型由两个V字型模型组成,分别代表测试与开发过程,明确表示出了测试与开发的并行关系。

W模型强调测试伴随整个软件开发周期,而且测试的对象不仅仅是程序,需求、设计等同样需要测试,也就是说,测试与开发是同步进行的。W模型有利于尽早、全面地发现问题。例如,需求分析完成后,测试人员就应该参与对需求的验证和确认活动,尽早地找出缺陷所在。同时,对需求的测试也有利于及时了解项目难度和测试风险,及早制定应对措施,这将显著减少总体测试时间,加快项目进度。

但W模型也存在局限性。在W模型中,需求、设计、编码等活动被视为串行,同时,测试和开发活动也保持着一种线性的前后关系,上一阶段结束后才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况,W模型并不能解除测试管理面临的困惑。

3.3 H模型

V模型和w模型均存在一些不妥之处。如前所述,它们把软件的开发视为需求、设计、编码等一系列串行的活动,而事实上,这些活动在大部分时间内是可以交叉进行的,所以,相应的测试之间也不存在严格的次序关系。同时,各层次的测试(单元测试、集成测试、系统测试等)也存在反复触发、迭代的关系。

为了解决以上问题,有专家提出了H模型。它将测试活动完全独立出来,形成了一个完全独立的流程,将测试准备活动和测试执行活动清晰地体现出来,如图3所示。

图3仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”。图3中标注的其他流程可以是任意的开发流程。例如,设计流程或编码流程。H模型揭示了一个原理:软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行。H模型指出软件测试要尽早准备,尽早执行。不同的测试活动可以按照某个次序先后进行,也可能是反复的,只要某个测试达到准备关键点,测试执行活动就可以开展。

4 X测试过程模型及其改进

4.1 X测试过程模型

X测试模型的目标是弥补V测试模型的一些缺陷,如图4所示。X测试模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试,此后将进行频繁的交接,通过集成最终合成为可执行的程序(右上半部分),这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户,也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。

在图4中,X模型还定位了探索性测试(右下方)。这是不进行事先计划的特殊类型的测试。这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误,X模型包含了测试设计的步骤,就像使用不同的测试工具所要包含的步骤一样;X模型并不要求在进行作为创建可执行程序(图中右上方)的一个组成部分的集成测试之前,对每一个程序片段都进行单元测试(图中左侧的行为)。但X模型没能提供是否要跳过单元测试的判断准则。

4.2 X测试过程模型的改进

软件开发过程中的变化性因素,包括需求变化、开发人员流动和技术更新等,一直是影响软件质量、开发进度和成本的主要因素之一。在传统的软件开发方法中,总希望前期调研分析工作做细、做完整,以减少在后期由于需求变动而带来的开发成本增加,即尽可能把变化排除在开发进程之外。但在实际开发中,这只是一种理想状态,需求变化是不可避免的。

传统的软件开发是获取全部的系统需求之后,开始整个系统的模块设计。而传统的软件系统结构的总体设计是基于功能层次结构建立系统:采用某种设计方法,将系统按功能划分成模块的层次结构;确定每个模块的功能;建立与已确定的软件需求的对应关系;确定模块间的调用关系;确定模块间的接口即模块间传递的信息;评估模块划分的质量及导出模块结构的规则。经常采用自顶向下的方式。然后为每个模块确定相应的数据结构、算法等,最后为程序员分配这些模块,以一个医药管理信息系统为例,说明该传统的模块任务分配方式,如图5所示。

这样的分配就存在了一些不足之处。如只有等所有的模块都设计完毕后,才能开始代码实现,等待时间过长,容易使得开发人员和用户感到疲倦和不耐烦;如果在这里总体模块的划分和设计存在不当的话,则会使得整个系统存在潜在不足,而这种潜在不足将会一直持续到系统完成的那个时刻,从而无法保证系统的正确性。我们可以发现,在一般的任务的分配上,每个开发成员都对应到不同的模块,负责自己模块的详细设计与实现,这样一来,每个人都很独立,只知晓自己负责的内容,而对系统整体性了解不够,对于将来系统的维护带来了很多限制。

因此,可以利用场景分析技术对用户故事进行获取和分割,采用迭代周期实现,集中所有的人力去完成每个场景。例如,上文的医药管理信息系统中的基础信息管理场景被分割成4个子场景,分别分配给不同的程序员,这样即使每个人对应的具体场景是不一样的,实现的内容并非完全相同,但由于都是关于基础信息管理的功能实现,因此在彼此的任务理解上并没有什么障碍,而且由于功能分配的细化,更加贴近实际需要;并且由于每个人都参与了系统的各个部分,对于系统的整体了解性更强了,便于将来系统的维护和扩充。图6是细化模块任务分配方式。

通过上述的分析可以看出,X测试模型具有测试的先行性,集成的频繁持续性,变更的存在性等特征。但在具体的应用中,由于模块任务分配的细化,该X模型显得过于粗略,存在一些不足之处。如未能反映出软件测试中迭代特性;未能很好地体现出对变更的适应性;未能表现软件人员和客户的互动合作性。因此,在X测试模型基础上,本文提出了一些对X模型的改进来适应模块任务分配的细化,如图7所示。

改进型的X测试模型把原模型的下半部分结合到上半部分,并作了相应的变化。模块划分的原理仍大致遵循传统的软件工程方法,但在模块任务的分配上则有所细化,即分配上突出模块的相似性或相通性,因此该改进型测试模型中的程序片断也具有这样的特性。左边各项工作如测试计划、工具配置、测试执行、代码编写都是由软件人员采用结对开发的方式来完成,其中根据实际情况,结对的一方可由客户来组成。集成后由软件人员补充测试设计,由用户编写验收测试,然后由双方共同模拟相应的运行环境来执行测试。整个测试过程也是由多个迭代组成,直至发布。图7中虚线表示变更及为适应变更而作的改动。

5 结束语

本文介绍了几种软件测试模型,并进行了比较研究,总结了它们的长处和局限性。并且针对传统的模块任务分配方式的不足,细化模块分配并结合X模型,提出了一种新的软件测试模型,将在大量的测试应用中,逐渐完善成为使用有效的模型。

参考文献

[1]张海藩.软件工程导论[M].北京:清华大学出版社,2003.

[2]Paul C Jorgensen软件测试[M].北京:机械工业出版社,2003.

[3]软件测试过程管理实践介绍[EB/OL].[2008-07-02].http://www.cppblog.tom/mzty/archive/2006/05/19/7402.html.

[4]Myers G.The Art of Software Testing[M].Newyork:Wiley,1979.

[5]Ian Sommerville.软件工程[M].北京:机械工业出版社,2005.

[6]William E.Perry.软件测试的有效方法[M].2004.

[7]李纬,陈嶷瑛.一种有效的软件测试模型[J].计算机工程与应用2004(10):114-115.

[8]Cem Kaner&Jack Falk.计算机软件测试[M].2版.北京:机械工业出版社,2004.

基于敏捷方法的软件测试模型研究 篇10

敏捷方法通常应用时间定量和迭代和进化试开发、使用自适应计划、提倡增量交付并包含其他提倡敏捷性(快速和灵活的响应变更)的价值和实践，为解决以上这些问题提供了轻量级的项目管理和开发、维护的思路。敏捷方法是上个世纪90年代末，为了应对软件需求和软件架构技术的不断变化，软件行业借鉴了传统制造业的“敏捷制造”思想，逐渐形成了新的软件开发模式。2001年著名的敏捷宣言的提出，标志着敏捷方法的逐步走向成熟。敏捷方法的整体目标是以人为主和欢迎变化。敏捷方法是“适应性”而非“预测性”的，目的是成为适应变化的过程。而传统重量级软件开发方法试图对一个软件开发项目在很长的时间跨度内做出详尽的计划，然后严格的依照计划进行开发，在计划制定完成后拒绝任何变化。敏捷方法则强调软件开发应当是一项愉快的活动，试图将软件开发工作融入人的特点，充分发挥人的自身的创造力。敏捷方法主要有以下四个观点： (1) 个体和交互胜过过程和工具。软件开发需要开发团队和客户有效地工作在一起; (2) 可以工作的软件胜过面面俱到的文档。满足需求的软件比文档更重要; (3) 客户合作胜过合同谈判。开发过程就应及时与客户互动和沟通; (4) 响应变化胜过遵循计划。业务环境在变化，技术随着时间也在变化，变化是软件开发不可逃避的现实。

2 软件测试概述

2.1 软件测试的概念

软件测试是IEEE给出了一个综合的定义：“将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。目前，国际上已对软件测试形成一个共识：软件测试就是在软件投入使用前，对软件的需求分析、设计规格说明和系统编码的最终复审。

2.2 软件测试的目标

软件测试的目标是希望以最小的代价，尽可能早地找出软件中潜在的各种缺陷和错误，并确保其对错误和缺陷给予及时的改正。基于用户和开发者立场的不同，存在两种完全不同的测试目的： (1) 从用户的角度出发，普遍希望在软件测试进行中，暴露出软件中隐藏的错误和缺陷，以便考虑是否可以验收该产品; (2) 从软件开发者的角度出发，希望通过测试来表明软件产品中没有错误，验证该软件已正确地实现了用户的需求，确立人们对该软件质量的信心。

3 传统的V模型结构

V模型是目前软件测试模型中使用比较广泛的模型。如图1所示，左边下降的是软件开发过程中的五个阶段，与此对应的是右边测试过程的相应阶段。测试首先从单元测试开始，然后依次是集成测试、系统测试和验收测试。V模型的优点是：非常明确的标明了测试过程中的几个不同阶段，并且清楚地描述了这些测试阶段和开发过程各阶段的对应关系。V模型的缺点也是显而易见的： (1) 测试活动在编码完成之后才开始，会错过早期可能发现需求分析和设计中隐含的错误的机会。最严重的错误是那些导致程序无法满足需求的错误，根据相关研究表明在需求设计阶段引入的错误往往占了软件错误中的绝大部分。 (2) 开发人员编码完成，就等着测试小组提交缺陷报告，然后修改程序。人力资源的利用率低。 (3) 这个模型将测试过程和开发过程在时间上严格地划分开，这样不利于测试计划、测试设计、错误统计和最后的分析报告等文档的存档。

4 W模型结构

W模型是对V模型的改进，针对在软件设计完成后才开始测试的问题，W模型强调需求、功能和设计也需要测试。明确表示出了测试与开发的并行且相对独立的关系。W模型在V模型的基础上补充了需求测试、规格测试和设计测试，目的是需求的完整性、一致性、准确性、可测试性等。W模型提倡软件测试并不等于程序测试这个理念，不应仅限于程序测试的范围内，而应贯穿于软件定义与设计开发的整个过程。因此，需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档及程序都成为软件测试的对象。W模型虽然强调了开发与测试之间的并行进行的关系，但也有缺点：W模型里虽然刻画了各个测试阶段与对应的修改工作之间的微循环关系，但是该模型将循环的关系仅仅局限于单个测试阶段之内的做法容易对测试人员造成误导。实际上，当在某个阶段发现问题并修改之后，往往要回到最初，从单元测试着手进行回归测试。所以下面的模型就将打破在单个阶段的局限。

5 基于敏捷方法的一种改进模型

基于W模型，在每个阶段主要完成的就是对于设计文本的测试，而没有考虑到文本背后将要形成产品的测试，我们要明白技术文档只是开发过程的中间品，我们要通过技术文档更好的保证软件开发中代码产品的质量，所以我们在进行文本测试的同时，要对后面所进行的单元测试、集成测试、系统测试、验收测试做出计划和设计。实现方式如图3所示。

同时，我们不是严格的划分四个阶段的4个计划和设计，我们都要根据开发变化做出适应性的变更，而每个部分的变更可能引起其他部分的变更，比如说单元测试的变更可能引起集成测试的变更，所以在设计部分我们要采取敏捷方法，及时响应变更。

敏捷方法是很必要的，在开发的初期，我们对于软件的认识并不全面，然而为了提高效率，我们在需求分析时就要开始验收测试计划与设计，在概要设计时就要进行系统测试计划与设计，在详细设计时就要进行集成测试计划与设计，在编码的同时就要进行单元测试计划与设计，然而这些计划和设计都会随着开发计划的变更而变更，我们的测试设计要紧跟开发设计，这样我们的测试才识适应开发的。随着开发的过程，我们对于软件的认识逐步深入，等到软件已经进入编码期，我们对软件的认识已经比较全面，此时我们该变更的设计也已经完成，测试计划和设计也已经比较成熟。可以很好的指导我们的测试执行了。

所以在测试的前期我们以响应变更和适应性为主要目的，这样可以加深对软件的认识，同时此时变更成本要远底于测试执行阶段。而在测试的后期，我们不应该放弃计划驱动的优势，按照已经设计好的计划和设计执行。

6 结束语

对于轻量级的软件开发，基于敏捷方法的软件测试取得了非常好的效果，它的优势是在计划和设计阶段可以及时响应变更，同时在测试执行阶段有可以拥有计划驱动测试的优势：井然有序，但是这种开发模型对于重量级软件的开发是否有效还需要进一步的研究。

参考文献

[1]ROBERT C, MARTIN.Agile software development:Principles, pat-terns, and practices[M].北京:中国电力出版社, 2003.

[2]JENNINGS NR.On Agent-based software engineering[J].Artificial Intelligence, 2000 (7) .

[3]张永梅, 陈立潮, 马礼.软件测试技术研究[J].测试技术学报, 2002 (2) .

[4]沈雷, 沈备军.敏捷方法的研究与实践[J].计算机工程, 2005 (7) .

[5]邓靖颖, 黄穗.敏捷开发:极限编程在管理信息系统开发中的实践探讨[J].计算机工程, 2004 (24) .

[6]沈备军, 陈诚, 居德华.敏捷软件过程的研究[J].计算机研究与发展, 2002 (11) .

[7]李炜, 陈瑛.一种有效的软件测试模型[J].计算机工程与应用, 2004 (10) .