![](https://csdnimg.cn/release/download_crawler_static/86814285/bg4.jpg)
1. 较为模块化的设计,避免重复的脚本,减少建立或维护脚本的成本。
2. 在应用软件开发的同时,就可以同步进行脚本建立的动作,而且当应用软件功能变
动时,只需要修改业务功能脚本。
3. 由于应用软件的功能已经被分解成独立的业务功能脚本,测试人员可以随意组合业
务功能脚本成为更复杂多样的测试个案。
4. 测试输入数据与验证数据与脚本分开,储存在另外的档案,如纯文字文件或 Excel
文件,测试人员可以更容易修改与维护。
5. 加强错误处理合结果分析判断,让脚本更有弹性。
当然这样做也会带来一定的额外开销,但是这些都是必须的,自动化本身就是需要结合良好
的管理以牺牲人力成本来赢得时间的,针对一些缺点我做一下简单的注释:
1. 在编写业务功能脚本时,需要「精通」测试工具脚本语言的工程师:其实很多公司都有
实力寻找这样的人,因为 VBS 本身相对比较简单,虽然自动化测试还没有在整个中国全
面兴起,但是有着丰富自动化测试经验的测试人员已经非常多了。
2. 每个 Action 都会有自己的输入输出参数,需要用文档统一维护,控制变更:这的确增加
了一些工作量,但是对测试本身的规范来说,是一大进步。
3. 测试人员除了要维护测试计划之外,还要另外维护数据文件:同上。
4. 对测试工具以及脚本语言来说,使用数据文件可能也要注意数据文件的格式。
这个分解结果来自 51Testing 上的一位同仁,我在做完兴业银行自动化之后做总结的时候无
意发现了这段话,猿粪哪!与我的想法不谋而和,呵呵,所以当时就 Copy 下来了,并非有意剽
窃,如果侵犯了这位仁兄,敬请原谅!这里修改了一些地方,我觉得这是金融尤其是银行业务分
解的一个经典,也算是一个不大不小的标准吧,可能并不能适用于所有系统,但是对银行来说,
还是很实用的。
下面以兴业银行交易处理中心项目自动化测试为例,看看这份业务分解
和脚本规范会带来什么样的效果。(注:附件文档乃非正式发布文档,系个
人私有,不牵涉兴业银行商业秘密,诸位放心!)
系统说明:
前台 Teller(银行柜员操作界面)、电子验印系统(印章校验)、Integrator(信息管
道)、工作流系统(IBM 的 FileNet)、后台交易集中处理系统(中间业务平台)、核心(联
想亚信的 FTS)等。考虑金融系统的安全性,所有交易流程的处理采用独占的方式,后台界
面交易处理按交易优先级次、时间先后进行,同等条件下 FileNet 随机分配,所以自动化的
难度相当的大。交易功能分解按照操作员岗位职责划分为前台柜员,CPC(中间业务平台)
的录入岗、审核岗、报文审核岗、异常处理岗、监控岗等部分。
实际应用:
这样的框架设计会带来什么结果呢?我们来计算一下: