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