作者:柳永坡 邹磊 金茂忠 刘雪梅
【摘 要】在软件测试组织中,对测试过程中的知识进行有效的管理,是提升组织整体测试水平的关键。一个重要的研究问题是怎样将知识管理过程与软件测试过程有效集成,从而促进知识资产在软件测试组织中的传播与重用。给出了软件测试领域知识管理子系统的体系结构、主要功能以及使用流程,对一些关键技术进行了探讨。最后,给出了知识地图模块的设计与实现,验证了本文所实现的软件测试领域知识管理系统的合理性和有效性。
【关键词】软件测试 知识管理模型 知识地图
知识管理的本质是一个管理问题,但是知识管理的各种功能及服务最终都还得依靠知识管理技术来实现。可以说,没有强大的知识管理技术支持,企业将很难有效实施知识管理,它是构建知识管理系统的基础,也是实现知识管理的强大推动力。从广义的角度看,知识管理技术并不局限于IT技术,但现代信息技术才是知识管理得以有效实现的基本前提。十多年的知识管理研究使得相当一部分的知识管理IT工具已经推向商业市场,但是这些已有的产品并不都是和企业的具体需求结合在一起,特别是在特定领域的应用,这种脱节表现尤为突出。
软件测试是一个知识密集型的活动,测试人员都属于知识工作者,他们的工作不仅仅是依据测试计划对软件进行测试,与测试相关的知识、技巧、经验和灵感在测试过程中有着重要的作用,测试人员如果没有开阔的思路,论文发表没有丰富的测试经验与测试技巧,测试的质量将无法保证。此外技术的飞速发展,不断出现的新的待测软件产品,常使软件测试人员感到压力重重,力不从心,他们有探寻新的测试知识和技术的紧迫需求。而知识管理的出现为我们提供了一种新思路和解决问题的新方法,但是软件测试有其自身的特点,虽然现有的通用知识管理理论及技术已或多或少触及了某些问题,但我们更需要用一种与本领域结合更紧密的理论和技术,来重新思考和审视我们的问题,以便寻找出一种解决问题的更有效的方法。
本系统是目前北航软件所的一个软件测试管理平台QESuite2.0项目中的一个子系统,该项目是北航软件所承担的某型号任务的一个子课题。目前,该系统已经完成了原型系统的构建,全部模块及功能已经实现,并在实际工作中试用,达到了预期的效果。
1软件测试领域的知识管理
1.1国内外研究现状
目前国内外在软件测试领域内实施知识管理的相关研究很少,迄今为止并没有找到在软件测试中实施知识管理的实例。国内知识管理的研究起步晚,同时专门从事软件测试的企业又很少,在测试领域内实施知识管理的需求刚刚出现。
到目前为止,虽然没有发现国外针对软件测试领域实施知识管理的研究和案例,但是从事各领域通用的知识管理的研究已有了很多年的历史,像IBM,Microsoft这样居于软件行业领先地位的公司,已经投入了相当规模的资金与人力来进行知识管理的研究,提出了一整套的知识管理理论并开发出相应的软件产品。
此外,国外在与软件测试最相近的软件工程领域对知识管理也有比较深入的相关研究,已经发表了相当数量的论文并开发出了一系列的软件支持工具。目前,每年都举行专门的基于知识的软件工程年会(KBSE Knowledge-BasedSoftware Engineering Conference),探讨知识管理在软件工程领域的最新进展。
进行软件测试领域知识管理的研究实际上是一个知识管理思想在软件测试领域的IT实现问题,也就是开发出一个软件平台来支持软件测试中的知识管理活动。根据Gallupe在2000年对现有知识管理系统平台、理论、案例等相关信息的较大范围的研究,现有知识管理系平台要真正实现有效的知识获取、编码、存储和搜索还有相当长的一段路要走。
1.2存在的主要问题
根据作者在北航软件所参与的软件测试项目工作经验,同时结合知识管理的基本原理分析国际上主流软件测试过程,认为目前在软件测试过程中存在五大问题:
1)软件测试知识重用率低。目前,软件测试过程中公共测试知识的积累未能有意识地大规模开展,虽然企业内部有一些用于测试知识和经验积累的数据库,但大多数员工忽视其存在,造成测试知识资源的闲置,导致测试知识和经验的重用率低。
2)软件测试知识传递不畅。现有测试知识的保管模式使得知识的传递不畅,测试知识被动地等人来阅读,而使用者则在知识海洋中苦苦寻觅他所需要的知识,员工无法快速掌握新的测试知识。
3)软件测试知识共享环境差。企业内部尚没有正式的、专用的、有组织的知识共享场所,员工之间缺乏相互沟通与交流的机会,沟通与交流的体制也没有建立起来,软件测试过程中的知识共享氛围也有待于培养形成。
4)软件测试知识流失严重。许多专门经验和技能只是少数人所拥有,没有真正成为企业的公共知识,这不仅使测试知识传递不畅,而且在人员变动时,这些测试知识会随之流失,使企业的整体竞争力因人员流动而发生波动,给企业带来严重损失。
5)无法快速实现测试组织中人力资源优化配置。知识管理是人、过程、技术的有机集成,其中人是最主要的,企业的管理者无法对组织中的人员技术特长、知识分布了如指掌,在遇到新的测试项目时,无法根据员工特长,快速搭建出最优的项目团队,从而无法实现组织中人力资源的优化配置。
由于上述问题的存在,造成了软件测试企业的生产效率不高,对市场的整体响应速度慢,应变能力不强。本人认为以上问题的出现是源于在当前的软件测试过程中缺乏对知识的科学管理,因此在该领域内实施知识管理就显得很有必要。
2系统体系结构及工作流程
北航软件所(SEI/BUAA)在多年从事软件测试领域的研究与实践的基础上,对知识管理在测试领域中的应用进行了大量深入的调查、研究,提出了一套针对软件测试领域实施知识管理的思想和方法。
由于软件测试领域的知识管理目前的研究甚少,特别是现成的软件测试知识管理系统更是一片空白,因此本课题的研究只能参照通用的或相关领域的已有研究进行。观察国内外知识管理平台的研究,尽管提出的模式纷繁复杂,但基本上每个模式中都包含着诸如知识产生、分类、积累、共享、重用这样的基本流程。
2.1系统体系结构
QESuite2.0在结构上采用的c/s方式,可支持群组协同工作,其中数据收集和分发的部分使用EJB实现,容器使用JBoss。QESuite2.0的框架基于插件开发的思想创建,利用多态特性声明可扩展的接口。框架与插件的连接、子类别的实例化过程则利用解释引擎(也称作连接器)在运行时动态完成,框架即可根据模板进行统一调用,具有良好的封装性和可扩展性。基于测试管理平台的以上特点,软件测试过程知识管理系统的体系结构如图1所示。
本系统基于J2EE开放式架构,是一个面向软件论文发表测试过程的架构弹性的知识管理平台。系统依循知识生命周期管理,利用软件测试组织中的知识文档,有效帮助企业存储、管理、搜寻、分享各种知识,并通过组织中的知识地图,有效地评估员工的知识程度,使知识地图成为知识型员工的地位象征,并通过统计工具对拥有知识的员工进行肯定,从而促进知识共享的企业文化。
2.2系统工作流程
系统的工作流程主要包括以下几个方面,如图2所示。
(1)首先对本子系统进行初始化,在本系统预定义的基础上,允许用户对软件测试知识分类、知识程度、组织职位定义、项目规模进行自定义。
(2)在交流库中添加文档,用户可以直接编写文档提交交流库,或者在交流库中提出问题,交流库是整个系统的知识文档来源。交流库中筛选出的技术含量较高文档,由知识分析员进行知识分类后,提交知识库。
(3)用户可以自行对知识库中的知识文档进行评估,同时根据知识分析员对文档的评定,以及作者的知识程度、文档的链接程度等加权实现对文档的评定。
(4)知识分析员可以根据组织讨论的结果直接设定组织成员的知识等级,也可以通过编辑组织成员的项目经历,来自动设置成员的知识等级,或者通过成员在组织中发表的知识文档来自动设置成员的知识等级。
(5)知识检索,主要包括知识文档检索和专家检索,通过知识文档元数据可以任意检索知识文档,当用户无法找到需要的知识文档,可以通过专家检索来告诉用户组织中能够解决问题的人。
3几个关键技术的研究与应用
3.1基于本体的软件测试领域知识表示方法
本体(ontology)起源于哲学,是关于存在及其本质和规律的学说。在近一二十年,本体被计算机及建模领域所采用,用于知识表示、知识共享和重用。本体论是对概念化对象的明确表示和描述,是对客观世界存在的现实系统化的描述。从本质上讲,本体是一个或几个领域的概念以及反映这些概念的关系的集合,关系反映了概念的约束和联系,而关系本身也是概念,关系之间也可能构成新的关系。
我们以本体来对软件测试领域知识进行表示,描述领域中相关的概念、属性,及其关系。这些本体概念、概念之间的关系定义在文档、参考文献、项目、人员、知识程度共5类本体中。根据以上属性,软件测试领域知识本体如图3所示。
3.2软件测试领域知识管理模型的提出
在针对软件测试过程的知识管理中,需要实现积极、主动的知识传递,建立起组织级的人员之间沟通和交流的渠道,根据软件测试活动中的知识需求,及时地实现相关知识的传递,通过有效的知识传播来改善和提高知识的重用效果。由于组织所需要的知识处于动态变化中,因而需要通过一个有效的基础设施,来满足以上功能需求。
根据以上分析,我们提出了一个面向软件测试过程的知识管理模型,如图4所示。本模型的要素是“测试组织人员”、“测试组织知识资产”、“测试组织交流场所”。基本思想是在软件测试过程中,建立一个交流场所,记录成员的提出的问题和问题解决过程,以及各种文档。
3.3软件测试领域知识地图的构建方法
知识地图,或称知识分布图(又称作知识黄页簿)是知识的库存目录。知识地图所显示的知识来源,可能是部门名称、小组名称、专家名字、相关人名字、文件名称、参考书目、事件代号、专利号码、或知识库索引等,但却不包含知识的内容本身,它是指南和向导,用以节省员工追踪知识来源的时间。
一个优秀的软件测试知识管理平台软件还应当能够提供强大的软件测试知识分类的能力。根据工程实践经验及SWEBOK分类方法,我们对软件测试领域增加了5大知识域:开发语言、数据库、操作系统、软件测试工具、测试项目相关知识。我们的知识地图中,每一种能力都有5级知识程度:了解、熟悉、熟练、精通、专家级。每一级的程度定义都有描述,务求清晰及易于评价,并避免主观的误差。每个员工的实际能力也依此标准衡量,评估过程应由员工、小组、经理及知识分析员互动完成。
3.4基于本体的知识文档智能检索和排序方法
本体在知识检索子系统中主要扮演知识库的角色,即首先对软件测试领域的概念分类、建立概念之间关系约束的描述,然后以此为基础构建详细的软件测试领域知识库,主要包括软件测试领域的具体概念、概念之间的属性、概念之间的关系以及实例等知识。在知识检索时,根据用户请求的关键词来查找相应的概念或属性,并以此为出发点来检索某条本体信息是否与这些概念或属性相关,从而实现支持逻辑推理的智能检索。
在知识文档检索子系统检索出结果后,必须首先研究检索出来的文档应该按照什么样的顺序进行排列。影响排序的因素有很多,根据研究,我们认为有5类因素是影响排序结果的关键:用户对知识文档的评价、知识分析员对文档的评价、作者的知识程度、文档的链接数,以及文档的打开次数。这五类因素的权值是按次序递减的,可利用递减加权公式来计算各因素的权值。下面是递减加权公式:
知识文档的重要性按下公式来进行计算:
知识文档的重要性=P1×用户对知识文档的评价+P2×知识分析员对文档的评价+P3×作者的知识程度+P4×文档的链接数+P5×文档的打开次数。
通过计算出来的知识文档重要性结果,然后对所有文档按降序排列,就可以将最有价值的知识文档排在前列计算机论文。
4系统实现
限于篇幅,整个系统各个模块的设计以及实现,这里不做详细介绍了。下面以简单图示的方式给出本系统的核心模块——知识地图模块的类设计和实现界面。知识地图模块分为两个部分:专家网络和搭建测试项目团队。普通用户在该模块可以编辑自己的项目经历,在编辑时可以选择项目导人数据,如果项目不存在,则可以自己编辑项目,然后导入项目数据,再编辑自己的项目经历,包括使用的技术、工作时间,项目职位、项目规模等等。知识分析员有权限选择其他用户编辑项目经历。在项目经历编辑完成之后,系统会根据用户对某些技术的使用时间来自行定义用户在这些知识点的知识程度,但是用户的知识程度最多达到熟练级别,要想达到精通和专家级,必须由知识分析员来编辑用户的知识程度。图5是系统中专家网络定义模块的编辑用户知识程度活动图。
知识地图模块的客户端的设计类图如图6所示。在知识地图模块的客户端中,负责界面消息事务处理的类有三个:EditTechDialog,WorkingExperienceDialog,FindPersonToStartProject。EditTechDialog这个类用来编辑用户的知识程度,只有知识分析员才有权限来调用这个类。WorkingExperi—enceDialog是普通用户可以使用的一个类,用来显示用户的工作经历。类FindPersonToStartProject是管理人员,通过输入一些数据来得到组织中比较适合新项目的人员,通过类FindResultDialog来显示查找结果。
结束语
知识管理的出现为我们提供了一种新思路和解决问题的新方法,但是软件测试有其自身的特点。虽然现有的通用知识管理理论及技术已或多或少触及了某些问题,但我们更需要用一种与本领域结合更紧密的理论和技术,来重新思考和审视我们的问题,以便寻找出一种解决问题的更有效的方法Ⅲg]。进行软件测试领域知识管理的研究,对于提升软件测试组织的整体测试水平和软件企业的整体应变能力,从而最终提高软件产品的质量和企业的经济效益,加强软件企业的核心竞争力无疑具有重大意义。
本文在分析目前软件测试领域存在的知识管理问题的基础上,实现了一个面向软件测试过程知识管理系统,对软件测试领域实施知识管理具有一定的意义,对其他领域的知识管理也有一定的参考价值。它是一个面向软件测试过程的知识管理雏形,虽然系统中还有待进一步完善,缺少对邮件系统和消息系统的支持,以及图形化的统计工具的支持,但是已经具有了一定的使用性,并在实际项目QESuite2.0中得到了检验,可望在不久的将来进行商业化和产业化。
期刊库(http://www.zgqkk.com),是一个专门从事期刊推广、投稿辅导的网站。
本站提供如何投稿辅导,寻求投稿辅导合作,快速投稿辅导,投稿辅导格式指导等解决方案:省级投稿辅导/国家级投稿辅导/核心期刊投稿辅导//职称投稿辅导。
【免责声明】本文仅代表作者本人观点,与投稿辅导_期刊发表_中国期刊库专业期刊网站无关。投稿辅导_期刊发表_中国期刊库专业期刊网站站对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。请读者仅作参考,并请自行承担全部责任。