软件检测实验室能力验证方案研究

软件检测实验室能力验证方案研究王欣中国电子技术标准化研究所摘要 本文分析了目前国内外软件检测机构能力验证方案的现状与需求，提出了一种针对软件检测实验室的能力验证方案，并就实施能力验证过程中各个主要环节应注意的主要问题及其解决方案进行了探讨。由于篇幅限制，本文只提出了概要的设计思想，并未就具体技术细节进一步展开。1. 引言近年来，各地建立了大批第三方软件产品检测实验室，到目前为止已超过50家。这些机构承担了国内几乎全部软件产品的外部测试工作，其中很多实验室的业务还介入到了企业的开发过程中。这些实验室检测能力的高低，将直接影响某个地区软件行业的发展。不同于传统检测实验室，软件产品检测实验室的能力往往无法通过传统的方法得到。例如，针对传统的检测与校准实验室，可以采取不同实验室对同一标准物质进行测量，然后对测量结果进行比对的手段。而对于软件产品检测实验室，这种方法的意义就显得并不明显。因此，需要一种针对软件产品检测实验室的新的能力验证方案。这种方案目前在国内和国际上都还没有形成。本报告通过对软件检测实验室能力验证方案的现状、需求和技术发展趋势的分析，结合曾经举办过的一些能力验证活动的实际数据，列举出了建立一整套严密验证方案所面临的几大重点课题，并尝试着就这些课题给出了某种可行的解决方案。最终，本报告试图通过以上分析，给出一条理论上可行的解决途径，作为建立第三方软件检测实验室能力验证方案的一种参考，供相关人员研究。2. 正文2.1. 现状分析软件产业的飞速发展极大地提高了生产力，促进了社会发展。随之而来的问题就是如何来有效地规范市场上众多的软件产品，如何有效地鉴别软件产品质量的优劣，从而保护消费者利益，引导软件产业健康发展。无疑，最直接和最有效的手段就是对软件产品实施检测。正是基于这个原因，近年来国内成立了很多从事软件检测业务的机构。但是如何来验证这些检测机构是否真的具备从事相应检测业务的能力呢？如何来验证这些检测机构出具的检测结果是否准确有效呢？这显然是企业、用户以及管理部门共同关心的关键问题。目前，为了保证检测结果的公正、科学，软件产品的检测任务通常由中立的第三方软件检测机构来承担。这些检测机构在开展检测业务之前须经过国家实验室认可委员会的认可。认可后的各个实验室之间，相同业务范围内的检测结果应是互相认可并一致的。然而，由于软件实验室相对于传统实验室的特殊性，很多检测实验室通过认可之后，在同样业务范围内的检测能力仍然相差很多，往往造成彼此间的检测数据不一致。截止到2006年，国内各类第三方软件检测实验室已经达到了一定数量（超过50家），覆盖了我国大部分的行政区域，在软件产业比较发达的地区，实验室的数量更加集中，例如北京地区，各种检测实验室达到7、8家。上海、广州等地区也有多家实验室同时开展工作。这些实验室中，绝大部分是由于“双软认证”任务的需要建立起来的，所以实验室的检测业务能力范围多数均为GB/T17544和GB/T16260。但由于这两个标准本身的一些原因导致的各个实验室理解上的差异，以及实际检测能力上的差别，经常出现某一产品在某地区通过检测后，在另外一个地区无法通过当地实验室检测的情况。为解决这种状况，除了继续加强标准化工作以外，急需出台专门面向软件检测实验室的能力验证制度。软件检测实验室能力验证方案的最终用户虽然是各个第三方软件检测实验室，但这一方案发挥的效果对国内软件市场的影响力是不可估量的。在国外，软件检测实验室主要通过市场机制进行约束和调控，有关能力验证方面的资料非常少。而国内的检测实验室统一受国家认证认可监督管理委员会监督管理。国家认证认可监督管理委员会于2006年3月13日发布了实验室能力验证实施办法，于2006年5月1日起施行。这标志着国家对于各类检测实验室能力验证的重视已经达到了新的高度。而到目前为止，有关软件检测实验室能力验证的方法、工具还是空白，所以研制专门面向软件检测实验室的能力验证工具是管理部门的迫切需求。只有掌控了检测机构的实际能力，才能规范整个软件检测行业，进而促进软件产业的健康发展。这一办法既表明了国家加强实验室管理的态度，也对软件检测实验室的能力验证问题提出了严峻的挑战。另一方面，软件检测实验室和其他检测、校准实验室有很大差别，无法运用传统手段进行能力验证。作为实验室管理机构的中国实验室国家认可委员会，目前对软件检测实验室的认可工作基本上仍然以对其他领域实验室的认可准则为依据，这本身在很大程度上并不适合于软件检测实验室。为了解决这个问题，国际标准化组织专门发布了技术文件ISO/IEC TR13233:1995Information technology-Interpretation of accreditation requirements in ISO/IEC Guide 25-Accreditation of Information Technology and Telecommunications testing laboratories for software and protocol testing services，国家认可委正在将该技术文件转化为检测和校准实验室认可准则（CNAL/AC01）在软件检测实验室的应用附加指南。该文件在一定程度上针对软件检测实验室进行了调整，并提出了部分合乎软件检测实验室实际需求的要求条款。但是一直到目前为止，有关软件检测实验室能力验证方案的问题，国内外都没有可借鉴的参考方案。2.2. 总体方案根据实验室能力验证实施办法中第二条的规定，“本办法所称的能力验证，是指利用实验室间指定检测数据的比对，确定实验室从事特定测试活动的技术能力。”参考传统实验室的这种比对活动，都是采取标准物质作为测试对象，对各个参加能力验证的实验室的实际测量结果进行比较分析，最终得出结论。作为软件检测实验室，其能力验证的原理也是如此，只是在某些具体问题上与其他实验室差别较大。这些问题在下面的章节中会详细讨论，这里先给出能力验证的总体设想方案和其中的几个主要环节（这些方案和环节中并没有考虑组织管理上的诸多因素，那部分内容不在本报告的讨论范围之内）：设想方案：建立一套软件检测实验室能力验证用测试对象库，也就是一个可以任意组装和拆卸的软件模块库，这些模块或大或小对应着GB/T16260中规定的质量特性、子特性或是度量元，当我们要开始一次能力验证时，确定了要使用的质量模型之后，就从库中抽取合适的模块，组装成测试对象。主要环节：（1） 设定能力验证范围（2） 制备测试对象（3） 分发并实施测试（4） 收集测试结果并进行统计分析针对上面列出的4个主要环节，我们一一讨论其解决方案及可行性。2.3. 主要课题（1） 设定能力验证范围在这个环节中，我们的任务主要是以下几个方面：a. 确定检测依据和范围目前的软件检测实验室，其业务范围主要是GB/T17544和GB/T16260。其中GB/T16260已经修订，而与之配套使用的GB/T17544的修订工作还没有结束。这两个标准是针对所有软件产品的通用标准，覆盖了软件产品的全部质量特性。但是一般来说，一个软件产品并不会涉及到全部这些质量特性。那么哪些质量特性在验证范围内，哪些不在验证范围内，要给出明确的说明。这些质量特性在GB/T16260中又被分为了子特性和度量元，因此，在确定了检测依据和范围之后，应给出本次能力验证使用的质量模型。b. 确定结果数据的要求定义了质量特性范围之后，要对测试结果数据有明确要求。如果测试的依据只是GB/T17544，那么由于该标准并未对测试后产生何种数据进行规定，因此必须在这一环节中给出明确要求。例如，要求给出Buglist，统计错误和失效的数量，进行错误分布分析等等。同时，由于这些错误与失效的严重性级别是不同的，因此，还有必要对错误的分级进行统一的定义，并要求结果数据中给出相应的级别描述。如果测试的依据中包括了GB/T16260，那么由于该标准中将各个质量特性划分为子特性，并进一步细分为度量元，且给出了将各个度量元测试结果归结为数值的方法，因此在这一环节中应给出进行比对测试时使用的质量模型。也就是说，应列出需要各个实验室提供结果数据的那些度量元的列表。（2） 制备测试对象这个环节是整个能力验证方案中最为艰难的一个环节。其主要问题集中在以下几个方面：a. 标准结果数据的问题其他实验室使用的测试对象是标准物质，其标准的结果数据是已知的；而软件由于其自身的特殊性，标准的结果数据几乎是无法获得的。要解决这一问题，方法有两个。一是向测试对象植入错误，并在结果分析时只考虑这些植入的错误。这种方法针对功能性比较有效，但是对于其他质量特性，效果不明显。二是对测试对象进行反复测试，使结果数据尽量逼近真实数据。这种方法理论上是可以实现的，但是由谁来进行测试是个问题。单独选取一家检测机构进行测试很难达到效果；而如果选取多家反复进行测试，测试对象就变得公开。b. 测试对象对标准的覆盖程度问题除了结果数据的问题，整套的能力验证方案必须覆盖GB/T中规定的所有质量特性，依靠一个单一的测试对象很难达到这一标准，因此，应该采取测试对象库的方式。也就是说，设计一套可以任意组装和拆卸的软件模块库，这些模块或大或小对应着GB/T16260中规定的质量特性、子特性或是度量元，当我们要开始一次能力验证时，确定了要使用的质量模型之后，就从库中抽取合适的模块，组装成测试对象，分发给实验室进行比对测试。这部分工作的工作量极其庞大，而且涉及了软件开发、软件测试、软件标准化等不同领域，需要大量的投入。鉴于目前软件检测市场上的需求，可以先从功能性方面的模块入手。（3） 分发并实施测试这个环节和传统实验室的能力验证没什么重大区别，可以按照以往经验进行操作。（4） 收集测试结果并进行统计分析如果要求结果数据是针对度量元的数值，那么就要给出每个度量元可以接受的结果数值范围。这个结果数值范围的确定，应通过严密的数学分析，借助统计学的某些概念和公式最终导出。这需要协同其他行业的专家一起来完成。如果要求的结果数据是Buglist形式，不能只考虑最终发现缺陷的个数，而应对应标准的缺陷列表，为每个缺陷分配权值，再依据加权后的标准缺陷列表，为各个实验室打分。权值的分配，同样需要软件领域和数学领域的专家协同工作来一起完成。3. 小结通过上述探讨，本文提出的解决方案的核心思想，是建立一套软件检测实验室能力验证用测试对象库。由于工作量和市场需求的问题，考虑先从功能性方面的5个子特性14个度量元入手。同时，在软件实验室能力验证的实施过程中，还应注意质量模型的设定、结果数据的要求以及结果数据的评判标准等方面的问题。4. 参考文献表GB/T 16260.1-2006 软件工程 产品质量 第1部分：质量模型GB/T 16260.2-2006 软件工程 产品质量 第2部分：外部度量GB/T 17544-1998 信息技术 软件包 质量要求和测试实验室能力验证实施办法ISO/IEC TR13233:1995 Information technology-Interpretation of accreditation requirements in ISO/IEC Guide 25-Accreditation of Information Technology and Telecommunications testing laboratories for software and protocol testing services6 / 6文档可自由编辑打印