测试报告的目的

前言：想要写出一篇令人眼前一亮的文章吗？我们特意为您整理了5篇测试报告的目的范文，相信会为您的写作带来帮助，发现更多的写作思路和灵感。

测试报告的目的范文第1篇

为了解决学生动手能力差、缺乏质量观念等问题，本文提出了以项目为驱动的基于CMM的软件工程教学方案。其核心思想为：学生以项目组形式进行软件项目研发，理论教学围绕方法和工具来支撑项目，教师及组员共同把握CMM3级的“需求管理过程改进、项目跟踪与监督过程改进、软件质量保证过程改进、软件配置管理过程改进”四个关键过程域，使软件的开发过程文档化、标准化。具体实施如下：

1.1项目组人员构成

依据项目规模，4-6名学生构成一个项目组，职责及任务分配如下（可兼职）：组长：协同教师组织管理整个开发过程。配置管理人员：对各种文档、数据、代码进行管理。质保人员：执行质量保证计划、测试计划，并设计测试用例进行评审。需求专员：需求汇总以及需求规格说明文档的撰写。设计专员：概要设计和详细设计，并撰写相应的文档。编码及维护人员：依据设计编码实现软件系统，对实现的单元模块进行单元测试、集成测试，完成交付后的维护工作。

1.2教师职责。

课堂教学应与项目进度无缝衔接，围绕项目所处阶段的技术和工具进行讲解。项目伊始，教师指导小组长制定开发计划及进度表，并在全程跟踪和监督执行情况；其次，深入企业调研并结合GB8567-2006等软件过程标准，制定CMM3文档体系标准；最后，作为专家评审参与各项目组的测试与评审工作。

1.3需求管理过程改进。

需求管理是软件工程非常关键的一个步骤，需求分析的完整与否直接影响到产品的成功交付，甚至导致软件项目的终结。小组成员、用户通过会议论证形式确定需求，由需求专员记录并形成文档资料，评审通过后提交至配置管理人员。

1.4项目跟踪与监督过程改进。

教师及小组组长在整个研发周期中执行项目的跟踪和监督工作。根据项目的计划，在指定的时间对项目的产品进行检测，目的是规范软件过程的流程，避免开发周期延迟的情况。

1.5软件质量保证过程改进。

软件质量保证是CMM中的一个关键过程域，直接影响软件产品的质量及交付。项目初期，质保人员在教师的指导下制定质量保证计划并分阶段检查，如软件结构的合理性、兼容性、易维护检查等；其次，协同教师采用W模型对软件产品进行测试和评估。在需求分析分析结束后，采用静态测试方法，对需求规格说明文档进行测试评审并提交测试报告；概要设计结束后结合需求规格说明，对概要设计说明书进行静态测试并提交测试报告；详细设计阶段对详细设计说明书进行评审，质保人员着手设计测试用例，提交测试报告及测试用例文档；编码和集成阶段，开发人员实现某一单元模块后进行单元测试、模块间的集成测试，提交测试报告；质保人员依据设计的测试用例进行确认测试、系统测试工作，并最终提交软件产品质量评估报告。

1.6软件配置管理过程改进。

软件配置是一种通过标识和文档来记录配置项的管理工作，控制这些资料的变更、记录和报告变更的过程状态。每一过程活动结束都应提交评审通过的文档、数据等资料，配置管理人员通过工具（比如VSS）进行入库、授权修改管理，形成需求基线、设计基线、代码基线及测试基线，使整个软件产品资料齐全且版本一致，规范化管理。

2结束语

测试报告的目的范文第2篇

【关键词】评估方法；软件可靠性；电子系统

对于软件可靠性的研究至今已经有几十年的历史，也取得了一定程度的进展，研究软件的可靠性是当前时代的一个前沿科技课题，软件的可靠性研究就目前的情况来看还不够成熟，与实际的工程应用之间还存在着一定的差距，还处于理论研究的探索阶段。传统的软件可靠性模型由于多种因素，导致在实际工程中软件可靠性模型无法直接应用，当前一种用于工程软件可行的可靠性定量评估方法是我们所缺少的。

一、软件可靠性评估的基本概念

软件的可靠性包括以下三个主要要素：

（1）规定的环境条件

软件的运行环境指的就是环境条件。其涉及到如操作系统、输入数据格式域范围、支持硬件、操作规程、其他支持软件等软件系统运行时所需要的各种支持要素。软件的可靠性在不同的环境条件下是有所差异的。规定的条件具体来说主要是描述在软件系统运行的过程中对输入数据的要求以及计算机的配置情况，其他因素并假定都是理想因素。对环境条件进行了明确的规定，可以判断出软件失效的责任是在研制方还是使用方。

（2）规定的时间

运行时间可以作为规定时间的定量，因为软件可靠性所体现的只是其运行阶段。软件系统在运行后挂起与工作的累计时间是运行时间的主要内容。此外，选取程序路径和软件的运行环境由于具有随机性，因此软件的失效为随机性事件，运行时间也就相应的属于随机变量。

（3）规定的功能

规定的工程和任务与软件的可靠性也有着重要的关系。软件的运行剖面会由于所要完成的不同任务而有所区别，其调用的子模块因此也有所不同，可靠性也因此有可能不相同。因此，必须要先明确其功能和任务，这样才能准确对软件的可靠性进行度量。

说到软件可靠性评估就少不了软件可靠性模型。建立的数学模型和可靠性框图用以估算或预计软件的可靠性，可靠性模型的建立是为了便于定量分配、估算、预计以及评价复杂的系统可靠性，为了将较为复杂的系统可靠性逐层分解为较为简单的系统可靠性。

二、测试软件可靠性的过程

测试软件可靠性的完成过程应该包括：设计测试用例、测试实施、编写测试报告、测试前检查以及可靠性数据的收集。

（1）测试前检查

在工程软件可靠性正式测试之前，研制任务书与软件需要要检查是否一致，检查程序与文档的一致性，数据、相应的软件支持环境、所交付的程度要检查是否符合要求，软件研制过程中所形成的文档要检查其是否齐全，文档的完整性与准确性要检查是否已经通过了相关的评审。软件研制过程中形成的文档，根据软件行业的相关标准共有16种：《软件开发计划》、《计算机资源综合保障手册》、《接口需求规格说明》、《软件程序员手册》、《软件设计文档》、《计算机系统操作员手册》、《版本说明文档》、《软件测试说明》、《系统和段设计文件》、《固件保障手册》、《软件需求规格说明》、《软件用户手册》、《接口设计文档》、《软件测试报告》、《软件产品规格说明》、《软件测试计划》。其中《软件测试说明》、《软件测试报告》以及《软件测试计划》，在这里需要注意，是在研制过程中研制方进行测试所形成的测试文档。如果软件的规模不是特别大，原则上来说，是可以将某些文档合并的。虽然进行测试前检查增加了一定的工作量，但是为了提高软件的质量以及及早发现一些错误，进行检查是非常必不可少的一个环节。

（2）测试用例设计

针对组合功能或者是特定的功能设计测试方案，并且将其编写成文档，这就是我们所说的设计测试用例。选择测试用例时要注意，要包括一般情况，也要包括最小与最大边界情况以及极限情况。在选择数据和测试用例时，要尽量考虑那些比较容易发现缺陷的数据和测试用例，因为进行测试的目的就是找出隐藏在软件中的缺陷，要结合复杂的运行环境，确定所有可能的输出条件与输入环境中的测试数据，对软件是够能够产生正确的输出进行检查。一个标准的测试用例应该包括以下信息：待测试的功能； 测试日期； 评价输出结果的准则；测试步骤； 测试目标； 预期的输出； 测试输入。此外，测试用例要在经过专家评审后方可投入使用。对测试用例进行描述是选择和设计测试用例集的第一步，这种描述是否完整、规范化、可理解、权威，决定了试验鉴定人员、软件研制人员、操作人员在多大程度上或者是能否理解和接受该测试用例。因此，在软件的评估与测试中规范化的测试用例描述具有非常重要的意义。

（3）实施测试

上述准备就绪后，便可以进行具体测试。用户稳定、数据、说明书、程序等于可靠性质量特性有关的部分交付的所有软件文档部分，都应该按照质量需求和需求说明进行测试。数据和程序，在需求说明书、用户文档、项目合同中规定的所有配置情况进行测试。可以在测试的过程中考虑进行强化输入。在强化输入下如果软件可靠，那么就说明在正规输入下要更加可靠。我们应该采用多台计算机同时运行软件，进一步增加累计运行时间，以获得更多的可靠性数据。

（4）收集可靠性数据

可靠性评估的基础就是软件可靠性数据，应该建立软件错误分析、错误报告、错误纠正系统。可靠性数据和软件错误报告的保存、收集、处理、分析规程，按照相关的标准要求进行制定与实施，对测试阶段软件的可靠性数据和错误报告进行准确完整的收集与记录。软件可靠性数据如果用时间定义，那么可以分为四类：记录发生一次失效所累计的时间为第一失效时间数据；记录上一次与本次失效之间的间隔时间，为第二失效间隔时间数据；记录某个时间区内发生了多少次失效，为第三分组数据；记录某个区间内的累积失效数，为第四分组时间内的累积失效数。这四类数据是可以进行相互转化的。每个测试记录都必须要包含充分的信息，主要包括：便有测试用例的测试说明或测试计划；参与测试的个人身份；测试时间；包括所有测试时发生的故障在内的，与测试有关的所有测试结果。

（5）测试报告的编写

软件可靠性测试报告，在完成测试活动后是必须要编写的，要对在测试报告中对测试结果以及测试项目进行归纳和总结。可以参考相关的规范格式进行编写，同时要根据具体情况进行剪裁。测试报告应该具有以下主要内容：软件和硬件的使用配置；用户文档、数据和程序的测试结果、产品说明；测试的最终日期；产品标识；与需求不相符合的项目列表；使用的文档。这种规范化的过程控制管理，可以为最终得到客观的评估结果奠定基础，有利于获得真实有效的数据。

总结：本文对软件可靠性的基本概念以及测试软件可靠性的过程进行了简要叙述。完全用现场试验的方法可以说是最好的评估软件可靠性的方法。对软件的可靠性进行评估受到很多条件限制，其中可靠性信息的不足是最大的限制。这就需要：明确软件与各模块的可靠性关系；软件研制部门的配合；收集足够的各模块和软件历史可靠性试验信息；以及已知的各模块寿命类型。

参考文献

[1]石柱.基于模糊技术的软件质量评价及可靠性评估[D].北京： 北京航空航天大学， 2000（03）.

[2]王强，陆阳，方欢，朱晓玲.基于结构分析的复杂软件可靠性评估方法[J].2013（04）.

测试报告的目的范文第3篇

测试不是挑毛病

然而，对测试领域先行者Glenford Myers先生“测试的目的是证伪”这一概念理解也不能过于片面。在很多软件工程学、软件测试方面的书籍中都提到一个概念:“测试的目的是寻找错误，并且是尽最大可能找出最多的错误”。这很容易让人们认为测试人员就是“挑毛病”的，而由此带来诸多问题。

我们可以假想在一个软件开发公司内，软件测试人员专注于“挑毛病”，开发人员和公司管理层每天会得到这样“简洁”的测试报告:“在今天的测试过程中，系统出现10次宕机现象”。

从“挑毛病”的角度看，测试人员已经很好的完成了自己的工作，但其工作成果对开发人员和公司管理层几乎没有任何帮助。开发人员面对这样的测试报告是无法对软件进行任何修改的;而公司管理层也会疑惑软件质量到底如何，系统能否如期。

长此以往，必然会造成开发人员和测试人员之间无法调和的矛盾;而公司管理层也会认为，测试团队只是“带来坏消息的人”，对公司产品没有提供任何帮助，不如取消为好。

这样的例子看似比较极端，业内普遍认为类似的问题仅出现在一个初创测试团队的公司内，但实际的情况远没有这样乐观，这类现象甚至还蔓延到近年来蓬勃兴起的部分第三方测试机构之中。

一个软件开发公司的管理者，拿到一份刚由某第三方测试机构完成的测试报告，报告结论是该公司开发的软件无法完成预定的需求，在500个用户并发交易的情况下会发生大量交易失败。应该说这样的报告确实挑出了软件的“毛病”，但报告中并未提及造成交易失败的原因，是硬件资源不足、支撑软件参数设置错误还是应用开发问题。这样的报告会使得委托测试单位置疑自己投资进行第三方测试的是否有实际帮助。

造成这些问题的原因归根结底就是对“测试的目的是证伪”这一概念的片面理解。那么，一次成功的测试是如何对问题进行阐述的呢？质量工程学中软件失效的机理给出了很好的答案。

软件错误是人为错误

质量工程学中对于软件失效是这样分析的:由于软件内部逻辑复杂，运行环境动态变化，且不同的软件差异可能很大，因而软件失效机理可能有不同的表现形式。

譬如有的失效过程比较简单，易于追踪分析，而有的失效过程可能非常复杂，难于甚至不可能加以详尽描述和分析，尤其是运行于高度复杂实时环境中的大型软件。

但总的说来，软件失效机理可描述为:软件错误?软件缺陷?软件故障?软件失效。如图1所示，是软件错误发生的过程。

软件错误软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可见软件错误是一种人为过程，相对于软件本身，是一种外部行为。

软件缺陷软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一逗点、多一语句等。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。

软件故障软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。譬如软件处于执行一个多余循环过程时，我们说软件出现故障。此时若无适当措施（容错）加以及时处理，便产生软件失效。显然，软件故障是一种动态行为。

软件失效软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。

因此，软件错误是一种人为错误。

逆流而上解决问题

我们了解了软件失效的机理后，就可以逆流而上，沿着软件失效嗳砑故障嗳砑缺陷嗳砑错误的方向对问题进行阐述和分析?首先，测试人员会说明软件出现了问题，在此对软件失效现象进行了描述;

其次，测试人员会详细阐明是在哪个测试用例的作用下（包括输入数值、处理过程和预期输出结果），软件产生了何种异常输出，问题的类型、严重程度、修改的紧急程度如何，这样就明晰了软件故障的情况;

第三，测试人员会根据测试经验和实际情况，帮助开发人员进行故障定位，找到软件缺陷所在;

第四，测试人员在对问题情况进行统计的基础上，会指出共性问题并分析其产生的原因，发现软件错误。

在这样对问题进行充分分析的基础上，对问题提出修改意见，这样一份问题报告会是一份对开发人员和管理层有意义的报告。

我们可以按照这样的分析方法，对前面企业内部和第三方的两个测试失败的情况进行修正。

软件失效现象:发生宕机/不能承担500个用户的并发交易;软件故障情况:在使用非法数据输入的情况下发生宕机/在进行用户交纳月通话费的情况下交易失败;软件缺陷:软件中缺少合法性校验/服务器CPU占用率达到98%;软件错误:详细设计环节缺少合法性校验内容，且文档评审工作不到位/概要设计环节未进行关键技术验证与仿真;修改建议:增加合法性校验，加强文档评审工作/重新选择服务器（重点是CPU），加强对关键技术的验证与仿真工作。

对于所有问题，都应该对软件的失效现象和故障情况做清晰的表述。除了严重程度会影响外，人员差异也对问题分析的程度有着较大影响。不同的测试人员需要承担不同的职责。

软件测试需三方协调

通过上面的分析可以看到，软件测试的目的决不仅仅是“寻找错误”，今天的软件测试需要在三个方面和开发协调工作，其相互作用如图2所示。

测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。这一工作靠对软件失效现象记录、软件故障表示、软件缺陷的分析完成。

通过分析错误产生的原因还可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进;同时通过对测试结果的分析整理，还可以修正软件开发规则，并为软件可靠性分析提供依据。这一工作靠对软件错误的分析完成。

测试报告的目的范文第4篇

评审条件更加细化

1999年11月12日，《计算机信息系统集成资质管理办法（试行）》（以下简称试行版）正式颁布实施，标志着计算机信息系统集成资质管理制度在我国的正式确立。

目前，我国系统集成企业的资质等级从高到低分为四级，其中一级企业可独立承揽国家级（含）以下集成项目，二级企业可独立承揽省级（含）以下集成项目，三级企业可独立承揽中小型企业项目或合作承揽大型企业项目，四级企业可独立承揽小型项目或合作承揽中型企业项目。

系统集成资质对我国系统集成企业来说意义重大：一方面，这是系统集成企业承揽一些重大系统集成项目的前提，另一方面，不同资质的系统集成企业可以相应地享受税收优惠政策。

中国软件评测中心主任助理刘闯指出，自试行版颁布12年来，我国信息化建设取得了巨大成就，集成企业取得了长足的进步，拥有集成资质的企业逐步发展成为我国信息化建设的主力军，它们的成长和壮大，对规范我国系统集成市场，推进信息化建设，保证信息系统的安全和质量，确保国家信息化战略的实施，起到了不可替代的作用。

为完善计算机信息系统集成企业资质管理工作，进一步规范信息系统集成行业，促进市场的健康和良性发展，推动软件和信息技术服务业做大做强，工业和信息化部计算机信息系统集成资质认证工作办公室从2010年起组织中国软件评测中心、情报研究所等单位，针对当前系统集成行业的发展趋势和特点，对试行版进行修订。

与试行版相比，新颁布的修定版从综合条件、财务状况、信誉、业绩、管理能力、技术实力、人才实力等七个方面对集成商企业进行资质评审，对一些不易审核落实、对企业综合实力不能定性或定量衡量的指标进行了调整。

据悉，修定版颁布后，所有新申请系统集成资质的评定要按照修定版的要求来执行，达不到对应等级的新评定要求的企业将无法获得相应的集成资质。

值得一提的是，修定版的同时，《计算机信息系统集成企业资质等级评定条件实施细则》也了。《计算机信息系统集成企业资质等级评定条件实施细则》将修订版评定条件中的相关内容进行逐一解释，方便企业理解及申报。

鼓励企业更大更强

那么，修定版和试行版的主要差别在哪里呢？

中国软件评测中心资质评定中心副总经理蒋巍分析，与试行版相比，修定版主要有三方面内容值得关注：

第一，强调了评审企业不能拥有信息系统工程监理单位资质，避免集成企业既当选手又当裁判。

第二，修定版提高了评审企业集成收入的比例，避免集成企业不务正业，如一级资质要求企业近三年的系统集成收入总额占营业收入总额的比例不低于70％，二级资质要求企业近三年的系统集成收入比例不低于60%。

第三，修定版从注册资金和集成收入等方面提高了一、二级集成资质的进入门槛。比如说，一级集成资质的注册资金下限从原来的2000万元提高到5000万元，二级资质要求注册资本从原来的不少于1000万元，提高到不少于2000万元。再比如说，一级集成资质要求近三年的集成收入从原来的3亿元提高到5亿元，二级集成资质则从原来的1.5亿元提高到2.5亿元。

刘闯总结说，对修定版和试行版进行对比后可以发现，修定版对一、二级资质的条件提高了，同时也更加严格，并且更加要求量化。修定版对200万元以上大项目的收入总额提出了更高的要求，强调拥有一、二级资质的企业要想做好做强，就要做大项目，在国家级的大型项目上发挥更大的作用。

另外，修定版规定一级企业“项目管理人员资质的人数不少于30名，其中高级项目经理人数不少于10名”。中国软件评测中心培训一部副总经理邓金花建议，集成企业在进行资质申报前，要详细了解修定版对人才条件的要求和相关考试时间，提早进行人才培养计划和储备。

不过刘闯指出，修定版对三、四级集成资质的评定要求则有所放宽，旨在对中小集成企业进行保护。

第三方测评角色加重

修定版的另外一个亮点，是增加了对集成商企业实施的项目质量的要求，特别是要求申请一、二级资质系统集成商需通过第三方验收测试：规定符合要求的系统集成项目及纯软件和信息技术服务项目需通过第三方验收测试，且验收测试报告数量不少于5个的评审条件；要求具有不少于10个软件登记测试报告（近三年），三级资质则不少于3个软件登记测试报告的评审条件。

可见，第三方测评在系统集成资质评审中的角色变得越来越重要。

蒋巍告诉记者，新版本强调第三方验收测试，表明监管机构在今后的系统集成资质等级评定工作中对于集成企业所实施项目的质量会更加关注。

谈到这一评审条件，北京赛迪信息工程监理有限公司副总经理吕小刚说，一些系统集成企业在信息系统项目收尾阶段不重视项目的验收工作，认为验收只是一种形式，或者不知道该如何有效组织项目验收，导致用户在应用过程中系统质量问题层出不穷，需求变更难以实现，后续维护服务无法跟进等问题，给用户带来难以估量的损失。

刘闯认为，引入第三方评测，通过技术手段对项目质量进行科学、客观、公正的评价，为资质等级评定工作提供了客观的判断依据。此外，第三方验收测试报告是评价系统集成项目质量是否合格的最有效的方式之一，在资质等级评定工作中，评审人员可通过第三方验收测试报告对集成企业的系统集成项目质量一目了然。

刘闯总结说，引入第三方评测将对资质等级评定工作产生重要的意义，不仅能够协助监管机构做好资质等级评定工作，而且能够促进集成商企业提高自身项目实施能力，加强项目管理，降低项目风险。

系统集成企业和用户在选择第三方测试机构的时候，也应充分考察第三方测试机构的技术实力，确保该测试机构有能力公平、正确地对项目进行测试。而且，在《计算机信息系统集成企业资质等级评定条件实施细则》中明确规定，省级以上的第三方测试机构出具的测试报告才有效。

值得一提的是，中国软件评测中心作为国家计算机信息系统集成行业管理的支撑机构、系统集成企业资质的评审机构，12年承担、参与了计算机信息系统集成资质的政策调研、法规文件起草、资质日常管理等大量支撑工作，对众多计算机信息系统集成企业进行了人员培训及资质评审推荐工作，为我国计算机信息系统集成行业管理和信息化建设做出了应有的贡献。

链 接

系统集成资质管理的发展历程

·1999年，《计算机信息系统集成资质管理办法（试行）》（信部规〔1999〕1047号）

·2000年，《计算机信息系统集成资质等级评定条件（试行）》（信部规[2000]821号文件）

·2001年，《计算机信息系统集成资质认证申报程序》和《计算机信息系统集成资质认证机构管理办法(试行)》

·2002年，《计算机信息系统集成项目经理管理办法》(信部规[2002]382号)，计算机信息系统集成行业开始推行项目经理制度

·2003年，《计算机信息系统集成资质等级评定条件（修定版）》（信部规[2003]440号）

·2004年，国务院412号令，明确系统集成资质认定被列为行政许可保留项目

测试报告的目的范文第5篇

关键词：　自动化测试；面向业务；自动化测试框架

0　引言

传统自动化测试，通常针对被测系统特点专项开发自动化测试脚本，当系统功能变更频繁时，自动化测试维护成本很大；测试资产不便于统一的管理，重要测试资产不便于积累和复用；另外，自动化测试对测试人员的开发技术要求，限制了自动化测试的大规模普及和推广。为此，本文给出了一种业务与技术分析、脚本与数据分离的面向业务的测试框架BOSATF（Business　Oriented　Software　Automated　Testing　Framework）。

1　BOSATF架构设计

1.1　架构设计原则

业务逻辑和测试脚本分离：框架提供协同工作平台，业务人员设计业务组件和业务流，自动化测试技术人员关注具体自动化脚本的开发，两个角色分工明确、高效配合。

测试脚本和测试数据分离：脚本和数据分别独立构建，同一测试脚本适用不同的测试数据，并使得脚本和数据的变更对整个测试工程的维护量降到最低。

框架功能模块高内聚低耦合：分层架构设计，模块内功能专一，模块间功能独立，在满足自动化测试框架基本功能需求的基础上，减少框架维护工作量。

1.2　分层架构设计

BOSATF由资源层、构建层、控制层、服务层和基础函数层等五大组件构成。

资源层提供框架运行过程中所需要自动化测试脚本、测试用例、测试数据和业务流程。各类资源逻辑上互相独立。

构建层负责资源层调度和管理，实现脚本、数据、用例、业务流程的统一管理，为构建层提供一致。

控制层协调构建层基础服务，遵循测试执行计划和测试机群管理规则，按照计划分配测试资源，保证测试执行有序进行。

服务层主要功能有日志信息的收集、缺陷的管理、测试过程中错误场景的恢复以及测试报告的生成。

基础函数层主要提供框架运行过程所需要的通用功能，包括日志管理、字符串格式转换、身份证号生成、保费校验和移动设备控件识别等功能。

2　BOSATF功能模块

2.1　测试用例管理

采用“业务流程分析法”，遵循“合并”和“拆分”原则，把手工测试案例转化成自动化测试案例，并建立映射关系，明确手工测试和自动化测试的对应关系，让测试人员实时掌握自动化测试进度，以便及时制定和调整测试执行方案。

实现自动化测试用例和成熟测试管理工具的互联互通，实现测试用例的导入、导出和多模式测试用例管理功能。

2.2　测试数据的管理

部分中间业务流程测试数据的准备时间占总测试周期的30%。针对这个问题，框架支持测试数据自动生成功能。根据被测功能特点，定制测试数据生成策略，批量自动生成测试数据。

框架同时提供“一次性数据”解决方案。针对部分业务模块测试数据无法恢复的情况，框架记录测试历史数据，避免数据的重复使用。

2.3　业务流程定义模块

该模块提供了可视化业务流程定义功能，降低了框架使用的技术难度。通过该模块，测试人员无需关注技术细节，只需要从业务人员视角定义业务操作流程，实现自动化测试脚本的自动组装。

2.4　测试执行管理

测试执行管理模块调用测试脚本、测试用例、测试数据、业务流程定义等相关服务，分配硬件执行机器资源，执行测试计划。同时，收集测试执行过程信息，为服务层的缺陷管理、测试报告管理提供基础数据依据。

2.5　场景恢复模块

目的是在出现故障的情况下能尽快的恢复系统，保证能快速、准确地正常恢复测试场景。根据故障的不同，明确地定义恢复的策略，制定不同的恢复机制，确保自动化测试在可预知风险前提下，快速恢复测试场景，按计划执行测试案例，保证测试进度。

2.6　缺陷管理模块

该模块采用与常用缺陷管理工具（QC、BugFree、JIRA）集成的办法，提供对发现缺陷的管理功能。支持缺陷状态的自定义，实现缺陷的自动提交，测试处理进度的自动追踪。

2.7　测试报告模块

以测试执行过程日志记录为基础，结合测试计划、测试执行管理等基础信息，提供多模式（TXT，Excel，Word，PDF）测试报告生成功能。

2.8　测试机群管理模块

该模块在实现自动化测试框架基本功能基础上，结合虚拟化IT运维趋势，开发了基于虚拟机技术的机群管理模块。

测试机群从职责上划分为五类：自动化控制调度服务器、资产管理服务器、资产备份服务器、测试执行机群及公共函数服务器。

3　结论

针对传统自动化测试框架不足之处，结合实际工作需求，提出了一种面向业务的软件自动化测试框架-BOSATF。它独立于自动化测试实施过程，作为专题项目开展工作，实现了业务流程管理和技术实现的分离，降低了自动化测试成本，提高了自动化测试大规模推广的技术可行性。

该框架在实现自动化测试框架基本功能基础上，结合虚拟化IT运维趋势，开发了基于虚拟机的机群管理模块。同时，框架提供了开放式集成接口，为与成熟的软件测试管理工具互通集成提供了途径。

实践证明，该自动化测试框架功能丰富、扩展便捷，有效降低了自动化测试难度，提高了测试工作效率。

参考文献：

[1]丁祥武、张钦、韩朱忠，SQL测试用例集的自动生成[J].计算机应用与软件，2012，29（8）：185-188.

[2]黄彪贤、熊建斌、李振坤，金融软件功能自动化测试的分析及应用，计算机工程与设计，2012，　33（2）：787-790.