那么业务模块划分的准则和依据到底是什么呢？不同的系统有着不同的标准，下面引用一个案例对金融系统做个粗略的介绍。
对金融系统来说，我们进行业务分解和设计业务流程的时候需要做如下要求：
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有限带来的时效性不高的问题。
刚才提到外界压力，什么是外界压力：我是你老大，我让你写1000个脚本你就不能偷懒写900……
文章来源于领测软件测试网 https://www.ltesting.net/