熟悉一个应用系统的业务流程是非常关键的，因为这不仅在方法上给我们带来很大的便利，我们做自动化（回归）测试，多数都是为了某些个系统核心业务的完整性和正确性作保证，这当然要求我们精通“业务”。明确一个较为庞大的业务系统的业务流程不是件容易的事情，在多数情况下需要将精通的业务的同事拉进来参与我们的流程制定、选取和覆盖设计。对业务模块的精确划分是我们完成一份高效的自动化测试的良好基础，否则，我们的自动化可能杂乱无章，甚至徒劳无功。

那么业务模块划分的准则和依据到底是什么呢？不同的系统有着不同的标准，下面引用一个案例对金融系统做个粗略的介绍。

对金融系统来说，我们进行业务分解和设计业务流程的时候需要做如下要求：

1.较为模块化的设计，避免重复的脚本，减少建立或维护脚本的成本。

2.在应用软件开发的同时，就可以同步进行脚本建立的动作，而且当应用软件功能变动时，只需要修改业务功能脚本。

3.由于应用软件的功能已经被分解成独立的业务功能脚本，测试人员可以随意组合业务功能脚本成为更复杂多样的测试个案。

4.测试输入数据与验证数据与脚本分开，储存在另外的档案，如纯文字文件或 Excel 文件，测试人员可以更容易修改与维护。

5.加强错误处理合结果分析判断，让脚本更有弹性。

当然这样做也会带来一定的额外开销，但是这些都是必须的，自动化本身就是需要结合良好的管理以牺牲人力成本来赢得时间的，针对一些缺点我做一下简单的注释：

1.在编写业务功能脚本时，需要「精通」测试工具脚本语言的工程师：其实很多公司都有实力寻找这样的人，因为VBS本身相对比较简单，虽然自动化测试还没有在整个中国全面兴起，但是有着丰富自动化测试经验的测试人员已经非常多了。

2.每个Action都会有自己的输入输出参数，需要用文档统一维护，控制变更：这的确增加了一些工作量，但是对测试本身的规范来说，是一大进步。

3.测试人员除了要维护测试计划之外，还要另外维护数据文件：同上。

4.对测试工具以及脚本语言来说，使用数据文件可能也要注意数据文件的格式。

这个分解结果来自51Testing上的一位同仁，我在做完兴业银行自动化之后做总结的时候无意发现了这段话，缘分哪！与我的想法不谋而和，呵呵，所以当时就Copy下来了，并非有意剽窃，如果侵犯了这位仁兄，敬请原谅！这里修改了一些地方，我觉得这是金融尤其是银行业务分解的一个经典，也算是一个不大不小的标准吧，可能并不能适用于所有系统，但是对银行来说，还是很实用的。

下面以兴业银行交易处理中心项目自动化测试为例，看看这份业务分解和脚本规范会带来什么样的效果。（注：附件文档乃非正式发布文档，系个人私有，不牵涉兴业银行商业秘密，诸位放心！）

系统说明：

前台Teller（银行柜员操作界面）、电子验印系统（印章校验）、Integrator（信息管道）、工作流系统（IBM的FileNet）、后台交易集中处理系统（中间业务平台）、核心（联想亚信的FTS）等。考虑金融系统的安全性，所有交易流程的处理采用独占的方式，后台界面交易处理按交易优先级次、时间先后进行，同等条件下FileNet随机分配，所以自动化的难度相当的大。交易功能分解按照操作员岗位职责划分为前台柜员，CPC（中间业务平台）的录入岗、审核岗、报文审核岗、异常处理岗、监控岗等部分。

实际应用：

这样的框架设计会带来什么结果呢？我们来计算一下：

1.前台发起的交易大约有60多个，每个交易的典型业务覆盖需要大约20个流程，这样共计1200个测试流程；

2.每个测试流程除去操作员登陆、签退之后大约有10个脚本，这样如果没有采取公用的话，每个健全的脚本应该在200行左右，不计算重复的测试流程，总的脚本的行数应该是：10*200*60=120000行；

3.但是采用了子模块的公用，我们完整地写了不到300个脚本（其中包含近百个10行以内的登陆、登出脚本），平均每个脚本只有不到100行，并且通文件系统操作覆盖了所有的流程，即：300*100=30000行；

4.这样可以清楚地看到，同样覆盖了1200个流程，我们节省了75%的脚本行数，减轻至少50%的工作量（考虑技术问题甚至80%），为QC/TD服务器也减轻了75%的存储压力，虽然在技术上带来一定难度，但是也没有产生多大的影响。

如果在没有外界压力的情况下，这种框架设计是非常有效的。很明显，稍微加大一些技术层面的工作量会给我们带来很大的好处：

1.减少30%到50%甚至更多的脚本编写的工作量，系统越大，有点越明显。

2.后期维护难度和工作量在同一的管理下大幅度下降。

3.减轻了测试管理服务器的存储压力，对于QC/TD和QTP的license不多的企业和单位来说，统一协调运行、管理可以很大程度上减少由于license有限带来的时效性不高的问题。