京玉银行测试作业平台项目

测试平台定位

为了规范测试流程，为项目测试提供统一、标准、规范化的支持，整体提升测试工作的质量和效率，经过我部反复论证最终决定自主研发建设一套可视化的测试作业平台。该平台结合测试管理的理念，支持手工测试和自动化测试，覆盖测试需求和测试案例管理，整合测试分析、案例设计、测试执行、投产需求测试范围评估、测试报告等具体测试工作，形成一体化的测试全流程作业和管理体系，为我行企业级测试活动提供统一存储、统一管理、统一分析、统一规范、统一操作的平台，同时复用目前已有的存款系统自动化测试成果。

平台建设目标

平台操作简单化，封装了更多方法，降低自动化测试的难度，不需要安排专门的脚本开发人员，将测试重点转移到测试业务场景设计、用例设计上，而不是如何编写脚本，提高测试的深度；

平台支持测试业务分析，可以通过设计业务流程图、分析业务规则等方式生成测试点，保证测试业务范围的有效界定。

平台支持测试案例的设计与管理，使测试案例成为测试资产可以被不断复用。

支持不同的测试阶段及类型的测试与项目复用，保证手工测试与自动化测试并行模式。

通过测试管理平台能体现出一套相对规范的自动化测试体系。可将测试脚本资源整合到平台中，实现资产的统一管理，有效地帮助测试资产的积累和重用。

自动化测试框架尽可能采用描述性语言编程方式支持尽早测试，界面对象设计完的同时，即可进行测试设计；（考虑到以后可以前移自动化测试工作）。

支持不同的团队人员可以同时进行一个自动化测试项目的设计和执行；

有效预防与监控执行异常，做到无人值守，并实现测试过程和结果的实时同步。

支持被测系统不同发布版本或测试轮次之间从需求-案例-脚本版本的差异对比功能。

平台设计思想

自动化测试框架部分设计思想应基于“关键字驱动”及“数据驱动”的混合型自动化测试框架，实现测试逻辑、测试脚本和测试数据的层层分离。

测试作业平台与QTP测试工具对接，QTP工具仅作为对测试脚本的解释执行，弱化或不直接使用QTP工具进行脚本开发。

测试平台采用数据库方式进行数据的统一存储，采用标准的SQL编写方式，便于不同数据库之间的数据移植。

测试平台所需运行环境涉及到的系统软件优先考虑开源软件，平台采用BS与CS混合架构模式，BS模式侧重管理功能及数据图表的展现，CS模式侧重测试工作的实施过程。自动化测试框

架使用VBS，前端使用图形化操作界面。

测试作业平台中可以将自动化测试框架部分单独分离出来使用。

测试平台易用性、可扩展性

开放式体系结构。提供开放的系统框架，能够支持模块和接口的开发与管理，支持其他测试工具的集成，从而具有广泛的适用性。如：自动化测试框架驱动接口除支持商业测试工具

外也应支持watir、selenium开源测试工具。测试作业平台应与被测应用系统类型无关，支持关键字及公共函数的扩展。

自身可配置性和外部可配置性。平台自身可配置性指框架部署在新的环境中能自动化完成一些必要的设置；外部可配置性指与其他开源测试工具接口或第三方系统数据的交互可通过参

数配置方式完成（例如：数据库访问配置、 缺陷管理工具Mantis等），以及在项目应用层面将可配置项放在外部文件中（测试框架在服务端的存储目录路径、配置文件、测试报告格式文

件等）。

界面操作简单，功能整合，业务人员与自动化测试人员在同一平台各自完成测试案例的设计与自动化测试脚本的转化过程，同时保证测试成果的延续与工作间的配合。

在熟悉业务操作流程及平台提供关键字含义的前提下，则可以完成中间脚本的设计与开发，降低对自动化测试的技术门槛。

测试平台兼容性

测试平台能够兼容目前已积累的测试脚本中的关键字，将中间脚本文件及测试数据移植到平台中即可生成相同的QTP脚本。（要求复用目前已有的存款系统自动化测试成果）

测试平台可以适应改进，新的改进不会影响到已有测试脚本的有效性。

任何界面对象改动引起的变动应该最小，测试平台应支持简单、方便的完成对象的变更。

平台前端应该对IE 7以上版本以及其他常用浏览器FireFox、Google Chrome有较好的兼容性。

 1/2    1 2 下一页 尾页