[发明专利]一种业务功能的回归测试方法、装置及系统

说明书

技术领域

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

背景技术

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

部分业务系统/平台目前也在使用如；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等面向工具、针对类Visual Basic或类C/C++语言的代码的自动化测试工具。案例的编写、脚本的录制、执行和维护等，要求测试人员：熟悉业务规则和操作流程、熟练操作工具、严格规范的在业务系统上录制脚本。显而易见，整个测试过程太依赖人为经验和技能，加大了测试环节在人员、培训等的投入。

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

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

发明内容

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