CN103164328B - 一种业务功能的回归测试方法、装置及系统 - Google Patents

Abstract

本发明公开了一种业务功能的回归测试方法、系统及装置，先通过案例编辑软件生成业务测试案例；再将生成的业务测试案例翻译为测试工具可执行的测试程序脚本；根据得到的测试程序脚本执行测试；输出测试结果。本发明能够有效降低使用者的技术门槛、生成结构统一的测试报告，并能使测试脚本的复用性增强。

Description

一种业务功能的回归测试方法、装置及系统

技术领域

本发明涉及一种信息系统测试技术领域，尤其涉及一种业务功能的回归测试方法、装置及系统。

背景技术

电信行业业务支撑系统的关键业务功能测试，目前主要使用手工测试。由开发人员或者测试人员，根据业务功能、流程手动测试。随着移动业务需求、用户业务办理要求等的不断增加，在指定时间内完成每一次业务/版本的上线，测试人员不得不经常在晚上、周末甚至假期集中加班测试，以保证测试环节保质、保量、稳定上线和运行。最后由测试人员根据业务功能，结合每次的测试情况手动编写测试报告文档。

部分业务系统/平台目前也在使用如；QTP(HP)、WINRUNNER、LoadRunner、Ruby等业内自动化测试工具，但都是面向工具层面，不具备业务封装功能。业务系统开发完成，测试人员利用工具(如QTP)进行业务流程手动操作录制测试脚本。当页面属性发生一点变更时，就要求修改脚本。如单独使用QTP有3种方法：1.在应用系统中执行业务操作重新录制，优点是对测试人员要求低，缺点是脚本复用率差速度慢；2.在对象库中手动补充修改，优点是相比较方法1节省时间，缺点是要求测试人员熟练QTP对象库的添加、修改等常用操作；3.在专家试图中编写代码，优点相比较方法1节省时间，缺点是要求测试人员非常熟练QTP代码编程的高级操作。相同业务不同的测试人员理解难免存在差异，就不仅要求所有测试人员对相同业务的操作全部相同，还要求测试的对象属性全部相同，才能保证每一次回归测试的结果统一。自动测试工具根据脚本的执行情况，生成面向工具的测试报告。

现有技术主要存在以下缺点：

第一，手工测试风险高、业务串行测试、周期长。手工测试过程比计算机过程的错误和疏忽更多，如人员会变得疲倦、输入数据错误、不能总是正确执行测试，不能保证所有必测内容都被测试。如中国移动在不断推出新业务，3G品牌早已经被成功的商业化，谁能抓住商机、谁的服务质量能被用户高度满意，谁才能拥有竞争力的优势。业务支撑系统内部结构已经越来越复杂，如陕西业务支撑系统业务种类数量已经非常庞大和复杂，各级菜单已达300多个，业务数量多达1000多个，随之会出现成千上万个测试案例；关键是业务之间的关联度也越来越高，测试者在编写测试案例时不仅要考虑业务需求，更要考虑业务关联性，场景案例也势必会成倍增加。所以，要保证测试案例的覆盖度、一致性、时效性，仅仅依靠传统手工测试人员的经验和技能很难实现。仍旧依靠手工测试必然会推迟系统BUG发现、修复的时间。研究发现，Bug发现的越晚修正的成本就越高，测试阶段修正bug的成本是编码阶段的约4倍的关系。那么项目开发的进度延长、成本的成倍增加、系上线时间推迟，客户满意度受影响等都会随之而来。

第二，现有的自动化测技术门槛高、难掌握。单纯的使用HPQTP、WINRUNNER、Ruby等面向工具、针对类VisualBasic或类C/C++语言的代码的自动化测试工具。案例的编写、脚本的录制、执行和维护等，要求测试人员：熟悉业务规则和操作流程、熟练操作工具、严格规范的在业务系统上录制脚本。显而易见，整个测试过程太依赖人为经验和技能，加大了测试环节在人员、培训等的投入。

第三，测试报告不统一、难理解。手动编写的测试报告太依赖测试人员对业务的理解程度和文档编写能力，而生成的测试报告又是面向工具、面向代码开发的；脚本每次执行的环境和录制步骤都相同，才会生成统一的测试报告，同时要快速从测试报告中定位问题，对阅读者的经验和技能要求也很高，从而加大了测试结果分析的难度和测试进度。

第四，开发的脚本通用性低、维护量大。如QTP无法针对实时更新的数据进行参数化，导致QTP录制的脚本只能运行一次。一旦业务检查点发生变化，测试部门将不得不投入大量人员和时间，重新操作业务流程录制脚本，或者由高级测试工程师修改代码更新脚本。致使测试人员没有足够的时间精力，很难做到业务流程的深层次理解、BUG数量和质量的保证、案例的质量和覆盖的深度。所以在整个测试的周期内，很难做到测试人员、测试案例、测试脚本的灵活复用。

发明内容

本发明的目的是针对以上现有测试状态、自动化测试工具和方法存在的突出矛盾而提出的一种业务功能的回归测试方法、装置及系统，能够使从业人员不需掌握繁琐难懂的自动化测试程序脚本，只需从业人员熟悉业务并熟练使用EXCEL工具即可对于关键业务功能进行测试。

本发明主要是一种针对信息系统的测试技术，尤其适合业务功能种类数量多的系统/平台的回归测试，以帮助检测新业务需求功能是否能够正常运行，以及原有关键业务功能是否受到新业务需求功能变更的影响。特别是在电信、金融、电力等行业支撑系统/平台的质量保证方面，有非常广泛的应用。

根据本发明的一方面，提供了一种业务功能的回归测试方法，包括步骤：

通过案例编辑软件生成业务测试案例；

将生成的业务测试案例翻译为测试工具可执行的测试程序脚本；

根据得到的测试程序脚本执行测试；

输出测试结果。

优选地，所述案例编辑软件是MicrosoftEXCEL。

优选地，所述通过案例编辑软件生成业务测试案例的步骤进一步包括：

对所述需要测试的业务进行测试要点分析、校验方式分析、测试路径覆盖分析，得到业务流程图；

根据得到的业务流程图，将业务功能的操作步骤按预定顺序组织，并将每一步骤的操作对象和操作动作一一对应，对操作对象设置不少于一个的关键字，生成逻辑测试脚本；

设置所述每一步骤的参数值和检查结果值。

优选地，上述步骤还包括：

将不少于一个的测试案例按照预定的逻辑组织成一个场景；

设置测试案例使用的测试数据。

优选地，所述将生成的业务测试案例翻译为测试工具可执行的测试程序脚本的步骤进一步包括：

在测试案例中设置的对象元素和被测试系统的对象元素间创建映射关系；

将测试案例翻译为测试工具可执行的测试脚本。

优选地，上述步骤还包括：

将所述在测试案例中设置的对象元素和被测试系统的对象元素间创建映射关系的步骤和所述将测试案例翻译为测试工具可执行的测试脚本的步骤合并执行。

优选地，所述根据得到的测试程序脚本执行测试的步骤进一步包括：

将不少于一个的测试案例按照预定顺序组织，通过脚本调度执行测试。

优选地，所述输出测试结果的步骤进一步包括：

输出的测试结果包括总结性的一个场景下案例的通过情况和/或所述案例的每一步骤的通过情况和具体值的验证情况。

根据本发明的另一方面，还提供了一种业务功能的回归测试系统，包括构建装置、翻译装置、执行装置和输出装置，其中

所述构建装置，用于通过案例编辑软件构建业务测试案例，并输出给翻译装置；

所述翻译装置，用于将输入的业务测试案例翻译为测试工具可执行的测试程序脚本，并输出给执行装置；

所述执行装置，用于根据输入的测试程序脚本执行测试，并将测试结果输出给输出装置，还用于将不少于一个的测试案例按照预定顺序组织，通过脚本调度执行测试；

所述输出装置，用于输出测试结果，所述输出的测试结果包括总结性的一个场景下案例的通过情况和/或所述案例的每一步骤的通过情况和具体值的验证情况。

优选地，所述构建装置进一步包括：

业务路径分析模块，用于对所述需要测试的业务进行测试要点分析、校验方式分析、测试路径覆盖分析，得到业务流程图，并将所述业务流程图输出给逻辑测试脚本组织模块；

逻辑测试脚本组织模块，用于根据输入的业务流程图，将业务功能的操作步骤按预定顺序组织，并将每一步骤的操作对象和操作动作一一对应，对操作对象设置不少于一个的关键字，生成逻辑测试脚本，并输出给测试数据设置模块；

测试数据设置模块，用于根据输入的逻辑测试脚本，设置所述每一步骤的参数值和检查结果值。

测试场景组织模块，用于将不少于一个的测试案例按照预定的逻辑组织成一个场景。

优选地，所述翻译装置进一步包括：

对象映射模块，用于在测试案例中设置的对象元素和被测试系统的对象元素间创建映射关系，并输出给脚本解析模块；

脚本解析模块，用于根据输入的对象映射关系，将测试案例翻译为测试工具可执行的测试脚本。

脚本封装模块，用于将脚本解析模块和对象映射模块进行封装。

根据本发明又一方面，还提供了用于业务功能的回归测试系统的装置。

一种用于业务功能回归测试系统的构建装置，包括：

业务路径分析模块，用于对所述需要测试的业务进行测试要点分析、校验方式分析、测试路径覆盖分析，得到业务流程图，并将所述业务流程图输出给逻辑测试脚本组织模块；

逻辑测试脚本组织模块，用于根据输入的业务流程图，将业务功能的操作步骤按预定顺序组织，并将每一步骤的操作对象和操作动作一一对应，对操作对象设置不少于一个的关键字，生成逻辑测试脚本，并输出给测试数据设置模块；

测试数据设置模块，用于根据输入的逻辑测试脚本，设置所述每一步骤的参数值和检查结果值。

优选地，所述构建装置还包括：

测试场景组织模块，用于将不少于一个的测试案例按照预定的逻辑组织成一个场景。

优选地，所述翻译装置包括：

对象映射模块，用于在测试案例中设置的对象元素和被测试系统的对象元素间创建映射关系，并输出给脚本解析模块；

脚本解析模块，用于根据输入的对象映射关系，将测试案例翻译为测试工具可执行的测试脚本。

优选地，所述翻译装置还包括：

脚本封装模块，用于将脚本解析模块和对象映射模块进行封装。

本发明的技术效果在于：

低门槛的测试人员。对编写人员的技术要求特别低，只需要了解所涉及业务的功能逻辑(如前台缴费)、会EXCEL的简单操作。业务需求明确后，测试人员即可以业务需求为导向，按照统一模板编写自动化回归测试案例，每一步的业务操作均可视化、通俗易懂，无需懂得自动化测试技术。测试人员可根据测试进度、业务量需要灵活进行交叉测试各自负责业务，从而提高测试效率。通过与HPQTP工具的结合，可使自动化测试广泛的推广到各业务部门、各角色，只需简单的培训均可参与。

自动化生成脚本。只需一句简单的调用语句，编写好的测试案例会自动生成基于QTP的自动化测试脚本。测试步骤的自动化执行、数据的自动录入、场景的自动操作都可避免，因人员经验和技能差异而导致的脚本质量参差不齐，实现案例的准确性、时效性和完整性，缩短开发周期、保证系统质量。为企业、项目参与者节省出更多的时间和精力，集中到问题定位、业务分析、案例覆盖度保证中，以便快速准确地提升用户满意度、产品竞争力，抓住商机创造更多效益。

清晰一致的测试报告。每次自动测试，系统会自动判断并生成测试结果，避免因人员经验和文档编写能力而导致测试结果的多样性，保证每次回归测试报告都准确一致。测试结果业务化、可视化，能帮助开发人员快速定位问题；同时，系统会自动保存可视化的测试结果，方便查询者随时查询任意批次的详细测试记录，为后期重现问题、定位问题、修复问题提供有力依据。

案例脚本的维护量小、投入少。案例和脚本均模块化、相对独立，通用性好，容易维护。业务功能发生变更，测试人员可根据业务关联关系，做简单(如增加下拉框的值、增加一个检查点、增加一个点击操作等)的修改，灵活组合案例和脚本，即可生成新的测试场景。据初步估算，对于新开发的业务，可提高自动化回归测试脚本开发效率100％以上，减少维护工作量超过200％。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1是本发明一种业务功能的回归测试方法的流程图。

图2是本发明中生成业务测试案例的流程图。

图3是本发明中将生成的业务案例翻译为测试工具可执行的测试程序脚本的流程图。

图4是本发明一种业务功能的回归测试系统的结构示意图。

图5是本发明中一个实施例的构建装置的结构示意图。

图6是本发明中一个实施例的翻译装置的结构示意图。

图7是本发明中一个实施例的“营业厅缴费”的业务流程图。

图8是本发明中一个实施例的逻辑测试脚本的示意图。

图9是本发明中一个实施例的测试数据配置表的示意图。

图10是本发明中一个实施例的自动化测试可视化报告的示意图。

具体实施方式

以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。

以下将从业务功能的可视化回归测试方法的步骤和业务功能的可视化回归测试系统以及各组成装置的结构等三个方面来详细描述本发明。

根据本发明的构思，首先本发明基于主流自动化测试工具的测试案例构建引擎。然后通过MQC测试管理软件，利用其产品成熟和对测试管理支持全面等特点，为自动化测试提供测试需求管理、案例管理、测试执行和缺陷管理等主要管理功能，并输出测试报告到EXCEL模板中。

如图1所示，一个优选的业务功能的可视化回归测试方法包括以下步骤：

步骤101：通过案例编辑软件生成业务测试案例；

步骤102：将生成的业务测试案例翻译为测试工具可执行的测试程序脚本；

步骤103：根据得到的测试程序脚本执行测试；

步骤104：输出测试结果。

以下分别对每个步骤进行详细描述。

步骤101：通过案例编辑软件生成业务测试案例

编写测试案例必须对测试对象，即业务功能分析清楚，利用业务功能的可视化开发的回归测试方法构建关键业务测试案例的前提条件。在步骤101中，案例编辑软件可以选择为MicrosoftExcel，在实际应用中，其他可以执行VBScript脚本语言的编辑软件也可以进行此项编辑工作，本领域技术人员应该能够想到利用其它同类软件进行替代。

如图2所示，通过MicrosoftExcel生成业务测试案例的步骤主要包括：

步骤201：待测试业务路径分析，得到业务流程图；

步骤202：根据业务流程图进行逻辑测试脚本组织；

步骤203：测试数据设置；

步骤204：测试场景组织。

业务功能的可视化开发的回归测试方法主要采用业界常用的MicrosoftEXCEL作为用户交互界面，用于构建业务测试案例，而不需要手工编写任何的程序代码。在本实施例中构建业务测试案例的具体方法如下：

首先进行待测试业务路径分析，主要包括：

测试要点分析：业务功能需要对哪些测试要点进行验证，既可以是功能点，也可以是业务规则。

校验方式分析：对每个测试要点如何进行校验。如对于“缴费是否成功”的校验，可以从“用户余额查询”和“营业员操作日志查询”等业务功能处得到验证。对于利用前台功能无法进行验证的测试要点，可以从后台相关的数据表中进行查询验证。只是鉴于业务验证的严谨性，不建议这样做。

测试路径覆盖分析：需要设置几个业务测试分支，以完整的覆盖需要检查和验证的功能点及规则。这里所述的测试路径不是穷举法中所有可能的路径，而指经过分析认为需要进行验证的业务分支。

描述业务流程图：从业务角度对涉及的业务逻辑、步骤、状态判断等利用流程图方式来进行直观描述。

如图7所示，就是根据上述步骤分析得到的“营业厅缴费”的业务流程图。在该图中，对于业务功能需要的每个测试要点都进行了分析整理，完整的覆盖了需要检查和验证的功能点及规则。

第二是进行逻辑测试脚本组织。

如图8所示，将应用系统(如中国移动的业务支撑系统)中某业务功能(如“营业厅缴费”)的操作步骤按顺序组织，同时将每个步骤涉及的操作及操作对象对应到操作步骤中，即可完成逻辑测试脚本。具体如下：

测试步骤分析：根据业务流程图，以颗粒度尽可能最小化为标准，将图中的节点分解成一个或多个颗粒测试步骤。如在“营业厅缴费”中，“输入手机号码”、“查询余额”就是其最小的颗粒步骤。

测试步骤动作分解：分解为如输入文本、单击操作、检查对象是否存在、选择数值、检查值是否正确、获取参数值等。原则上以把业务功能的单个操作设计为一个测试步骤(如输入“手机号码”，点击“查询”按钮等)。

界面元素对应：每个测试步骤的操作对象和操作动作之间做一一对应。如浏览器、子页面、下拉列表、输入文本框等，这些界面元素一般可以分为：超链接、网页输入框、网页按钮、网页表格等。其操作动作一般可以分为：单击、双击、输入、选择等。

关键参数识别：对于需要操作的界面元素，需设置一个或多个关键字识别。如文本标题、界面元素的名字、界面元素的类型等。并给每个关键字设置一个识别的参数值，如营业厅缴费中输入的“手机号码”可以设二个关键字“名称”为“txtPhone”、“标题”为“手机号码”等。可借助QTP工具自动识别界面元素的功能，获取界面元素的关键参数及相关数值。

第三是进行测试数据设置。

如图9所示，设置测试案例中用到的所有数据，控制自动化测试脚本的运行，同时把测试结果体现在测试报告中。具体如下：

设置每个步骤的输入参数：设置需要界面输入或从界面上选择的参数值。如“客户号”、“账号”、“手机号码”等。为保证测试更加全面，可设置多条不同的测试数据验证业务功能。

设置是否要输出检查结果值。保证输出详细的检查要点的结果值，如“提交缴费信息”是否成功，以便系统开发人员对问题的定位。

另外，还可以进行测试场景组织。

如下述测试场景表所示，针对不同业务，将各测试脚本按照一定的逻辑组织成一个场景执行，从而使关键业务的自动化回归测试结果可以更符合实际业务需求，同时也能大量节省自动化脚本的执行时间。此处的测试逻辑即为测试流程，包括多个测试脚本，每个测试脚本是针对被测业务功能的一种，根据多个测试脚本选择需要操作的界面元素和操作动作，完成多个功能的场景测试。测试方法具体如下：

测试案例组织：每个场景需执行多少个测试案例。如把“用户登录”、“账户管理”等案例组织在一个场景中来执行。

测试逻辑设置：设置测试案例需要利用哪些测试数据来验证。通常不需测试所有数据，可选择某行数据、某几行数据来进行验证。

案例文件	参数选择	备注描述
			01-用户登录\TestScript_001-用户登录.xls	2
02账户管理\01账户信息查询\TestScript_002-账户信息查询	3,5
			02账户管理\01账户信息查询\TestScript_01-本人账户互转	2-4

步骤102：将生成的业务测试案例翻译为测试工具可执行的测试程序脚本。

如图3所示，将生成的业务测试案例翻译为测试工具可执行的测试程序脚本步骤主要包括：

步骤301：在测试案例中设置的对象和被测试系统的对象元素间创建映射关系；

步骤302：将测试案例翻译为测试工具可执行的测试脚本。

上述步骤还可以包括：将所述在测试案例中设置的对象元素和被测试系统的对象元素间创建映射关系的步骤和所述将测试案例翻译为测试工具可执行的测试脚本的步骤合并执行。

将EXCEL中表示的测试案例翻译为业界测试工具(如HPQTP)可执行的自动化测试程序脚本，同时借助MQC或手工来组织生成不同的自动化测试场景。利用EXCEL支持的VISUALBASIC脚本语言，来形成固定的转换程序，用宏的方式镶嵌在测试案例中。具体如下：

在测试案例中设置的对象和被测系统的对象元素间创建映射关系，保证测试脚本对被测对象的正确操作。在本实施例中，如上所述，对于如浏览器框架、弹出窗体、页面、标签、文本框、下拉列表、日期选择框、网页网格、按钮、超链接等界面元素，以及这些界面元素涉及的操作如选择、单击、双击、输入等，和HPQTP能识别的界面元素表示方式、某个操作涉及的函数进行映射关联。如“点击按钮”操作，代表在界面上对“提交”按钮的点击确认；“输入”操作，代表在界面上的“文本框”中输入字符；“选择”操作，代表在“下拉列表”进行“单击”+“选择”的操作，对于这些操作通过HPQTP管理软件与具体操作涉及的函数相关联。

HPQTP管理软件将测试案例翻译为测试工具可执行的自动化测试脚本。

首先，根据已经建立好的在测试案例中设置的对象和被测系统的对象元素间的映射关系，建立相应的映射文件，加载到HPQTP资源池中，用于HPQTP解析脚本文件；

其次，使用调用函数，使程序自动扫描测试案例中有关“步骤操作涉及对象”、“对象的关键参数信息”、“步骤的操作方式”等设置信息，将所述界面元素名称、执行脚本动作、测试数据的设定值以及预期输出结果文件等组合生成中间脚本；

最后，HPQTP管理软件根据映射文件和中间脚本自动生成HPQTP能识别的测试脚本。然后读取测试数据文件中的测试数据信息，形成一个或多个测试脚本实例。这些测试脚本在测试执行时，会被单独执行一次/或执行多次。

在一个优选的实施方式中，可以将上述两个步骤301和302封装运行行，以便在MQC等测试管理工具中自动调度测试脚本，驱动HPQTP测试工具执行测试脚本，完成测试场景中测试案例的执行工作。

步骤103：根据得到的测试程序脚本执行测试。

得到可以被测试工具自动执行的测试脚本之后，就可以通过调度该测试脚本在业务平台上模拟输入、点击、选择等操作执行自动化测试。也可以将不少于一个的测试案例按照预定的测试顺序组织，再通过调度所述不少于一个的测试脚本执行自动化测试，达到对于一个或多个业务功能的综合测试目的。

步骤104：输出测试结果。

测试脚本执行结束后，HPQTP管理软件将生成的测试结果报表，根据预定的Excel模板或其他设置好的模板输出测试报告上传至MQC测试管理工具。测试报告可以分为两种：一类是总结性的，展示某场景下案例的通过情况，如下表所示；另一类是详细的，如图10所示，展示某案例每步骤的通过情况，及具体值的验证情况。MQC支持自动保存更详细的步骤截图信息。

在上述方法中，当某步骤或某元素的类型发生变化，只需针对步骤重新配置步骤名称、关键参数、界面元素及相关操作等配置值即可完成脚本更新。通过MQC平台自动或者手工调用“自动化脚本生成”的功能，就能自动生成新的业务功能自动化测试物理脚本。

以“产品变更”中“验证主体产品名称”测试步骤的测试案例为例，若业务规则不需该步骤，只需在测试案例中将测试数据清空、或删除该操作步骤；若只是“选择证件类型”从原来的下拉列表选择方式改到文本框输入方式，则只需要将该步骤的动作修改成文本框输入方式。

根据这一发明构思，本发明一种业务功能的回归测试系统的一个最佳实施例，如图4所示。

如图4所示，一种用于业务功能的回归测试系统，包括：构建装置，用于通过MicrosoftEXCEL构建业务测试案例，并输出给翻译装置；翻译装置，用于将输入的业务测试案例翻译为测试工具可执行的测试程序脚本，并输出给执行装置；执行装置，用于根据输入的测试程序脚本执行测试，并将测试结果输出给输出装置；输出装置，用于输出测试结果。

以上详细公开了本发明的一种业务功能的回归测试方法和系统，上述实施例中的方法可通过上述系统执行。

在本发明最优选的一个实施例中，还公开了用于业务功能的回归测试系统的装置。其中：

如图5所示，构建装置包括：业务路径分析模块，用于对所述需要测试的业务进行测试要点分析、校验方式分析、测试路径覆盖分析，得到业务流程图，并将所述业务流程图输出给逻辑测试脚本组织模块；逻辑测试脚本组织模块，用于根据输入的业务流程图，将业务功能的操作步骤按预定顺序组织，并将每一步骤的操作对象和操作动作一一对应，对操作对象设置不少于一个的关键字，生成逻辑测试脚本，并输出给测试数据设置模块；测试数据设置模块，用于根据输入的逻辑测试脚本，设置所述每一步骤的参数值和检查结果值；测试场景组织模块，用于将不少于一个的测试案例按照预定的逻辑组织成一个场景。

如图6所示，翻译装置包括：对象映射模块，用于在测试案例中设置的对象元素和被测试系统的对象元素间创建映射关系，并输出给脚本解析模块；脚本解析模块，用于根据输入的对象映射关系，将测试案例翻译为测试工具可执行的测试脚本；脚本封装模块，用于将脚本解析模块和对象映射模块进行封装。

执行装置根据输入的测试程序脚本执行测试。也可以将不少于一个的测试案例按照预定顺序组织，通过脚本调度执行测试。

输出装置输出测试结果，包括总结性的一个场景下案例的通过情况和/或所述案例的每一步骤的通过情况和具体值的验证情况。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种业务功能的回归测试方法，其特征在于，包括步骤：

通过案例编辑软件生成业务测试案例；

将生成的业务测试案例翻译为测试工具可执行的测试程序脚本；

根据得到的测试程序脚本执行测试；

输出测试结果；

所述通过案例编辑软件生成业务测试案例的步骤进一步包括：

对需要测试的业务进行测试要点分析、校验方式分析和测试路径覆盖分析，得到业务流程图；

根据得到的业务流程图，将业务功能的操作步骤按预定顺序组织，并将每一步骤的操作对象和操作动作一一对应，对操作对象设置不少于一个的关键字，生成逻辑测试脚本；

设置所述每一步骤的参数值和检查结果值。

2.如权利要求1所述的业务功能的回归测试方法，其特征在于，所述案例编辑软件是MicrosoftEXCEL。

3.如权利要求1所述的业务功能的回归测试方法，其特征在于，所述步骤还包括：

将不少于一个的测试案例按照预定的逻辑组织成一个场景；

设置测试案例使用的测试数据。

4.如权利要求1或2所述的业务功能的回归测试方法，其特征在于，所述将生成的业务测试案例翻译为测试工具可执行的测试程序脚本的步骤进一步包括：

在测试案例中设置的对象元素和被测试系统的对象元素间创建映射关系；

将测试案例翻译为测试工具可执行的测试脚本。

5.如权利要求4所述的业务功能的回归测试方法，其特征在于，所述将生成的业务测试案例翻译为测试工具可执行的测试程序脚本的步骤还包括：

将所述在测试案例中设置的对象元素和被测试系统的对象元素间创建映射关系的步骤和所述将测试案例翻译为测试工具可执行的测试脚本的步骤合并执行。

6.如权利要求1或2所述的业务功能的回归测试方法，其特征在于，所述根据得到的测试程序脚本执行测试的步骤进一步包括：

将不少于一个的测试案例按照预定顺序组织，通过脚本调度执行测试。

7.如权利要求1或2所述的业务功能的回归测试方法，其特征在于，所述输出测试结果的步骤进一步包括：

输出的测试结果包括总结性的一个场景下案例的通过情况和/或所述案例的每一步骤的通过情况和具体值的验证情况。

8.一种用于业务功能的回归测试系统，其特征在于，包括构建装置、翻译装置、执行装置和输出装置，其中

所述构建装置，用于通过案例编辑软件构建业务测试案例，并输出给翻译装置；

所述翻译装置，用于将输入的业务测试案例翻译为测试工具可执行的测试程序脚本，并输出给执行装置；

所述执行装置，用于根据输入的测试程序脚本执行测试，并将测试结果输出给输出装置，还用于将不少于一个的测试案例按照预定顺序组织，通过脚本调度执行测试；

所述输出装置，用于输出测试结果，所述输出的测试结果包括总结性的一个场景下案例的通过情况和/或所述案例的每一步骤的通过情况和具体值的验证情况；

所述构建装置进一步包括：

业务路径分析模块，用于对需要测试的业务进行测试要点分析、校验方式分析、测试路径覆盖分析，得到业务流程图，并将所述业务流程图输出给逻辑测试脚本组织模块；

逻辑测试脚本组织模块，用于根据输入的业务流程图，将业务功能的操作步骤按预定顺序组织，并将每一步骤的操作对象和操作动作一一对应，对操作对象设置不少于一个的关键字，生成逻辑测试脚本，并输出给测试数据设置模块；

测试数据设置模块，用于根据输入的逻辑测试脚本，设置所述每一步骤的参数值和检查结果值；

测试场景组织模块，用于将不少于一个的测试案例按照预定的逻辑组织成一个场景。

9.如权利要求8所述的用于业务功能的回归测试系统，其特征在于，所述翻译装置进一步包括：

对象映射模块，用于在测试案例中设置的对象元素和被测试系统的对象元素间创建映射关系，并输出给脚本解析模块；

脚本解析模块，用于根据输入的对象映射关系，将测试案例翻译为测试工具可执行的测试脚本；

脚本封装模块，用于将脚本解析模块和对象映射模块进行封装。