实际应用：
这样的框架设计会带来什么结果呢?我们来计算一下：
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有限带来的时效性不高的问题。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
