LoadRunner性能测试应用（连载三十一）

zt425

8.3.5  业务处理能力估算
　　根据上一节的业务量统计表，计算每分钟交易数量，如表8-5所示。其中高峰交易量仍是根据80/20法则估算，即在工作时间内，80%的业务是在整个工作日的20%时间内完成，其中业务量按照每天可能发生的最大交易量乘以80%来计算，工作时间按照正常工作时间8小时的20%来进行计算。

　　表8-5  单位时间内业务量统计表

类型 年度 吞吐量（万） 高峰日交易量（笔） 日高峰期交易量（笔/90分钟） 高峰期单位时间交易量（笔/分钟）
常规 2007 140 15 340 12 272 136
2008 161 17 641 14 113 157
2009 185 20 287 16 230 180
2010 212 23 330 18 664 207
容灾 2007 — 70 43 750 486
— — — —

8.3.6  网络流量分析估算
　　假设执行每笔业务时，假设大约占用10Kbps资源，同时不考虑网络带宽在传输

　　过程中的效率损失，表8-6给出了对网络带宽的需求。

　　表8-6  网络带宽的需求表（无效率损失）

类型 年度 吞吐量（年） 高峰期单位时间交易量（/min） 日高峰期每分钟数据传输量（Kb/Min） 日高峰期每分钟数据传输量（Kb/s）
常规 2007 140万 136 1 360 22.6
2008 161万 157 1 570 26.2
2009 185万 180 1 800 30
2010 212万 207 2 070 34.5
容灾 2007   486 4 860 80.8

　　假设每笔业务处理需要10Kbps的流量，考虑到并发情况及网络利用效率等问题（效率损失为60%），实际所需要的网络带宽如表8-7所示。

　　表8-7  实际所需网络带宽列表

类型 年度 吞吐量（万） 不考虑网络效率损失的带宽要求（Kb/s） 考虑网络效率损失后的带宽要求（60%）（Kb/s） 假定传输压缩率50%，压缩后的带宽要求（Kb/s）
常规
2007 140 22.6 37.6 18.8
2008 161 26.2 36.9 18.4
2009 185 30     
2010 212 34.5 50 25
容灾 2007 70 80.8 134.6 67.3

zt425

　自动化测试并不只是利用自动化测试工具进行录制回放操作。虽然基本是每一个自动化测试工具都必须提供的功能，但如果只是这么应用，从严格意义上来说，这并不能算是自动化测试。最多只能说是实现了一定的自动化操作。因为这时自动化脚本都是写死的，自动化测试使用的数据也是写死的，没有灵活性可言，也没有对脚本进行容错性处理，脚本基本是运行不完。且也没有添加测试验证，不能验证执行结果是否符合预期的结果。

　　早期使用QTP，可以利用QTP提供的功能实现三层架构：测试数据，测试对象和测试脚本三个结构的分离。QTP提供DataTable对象来保存测试数据，且也提供了把脚本中的测试数据参数化到DataTable而脚本中只引用了参数化的名称的功能，而DataTable存储的是一个Excel文档，方便修改测试数据，这样便实现了测试数据与测试脚本分离；QTP也把自动化测试中要操作的对象放到了对象库中进行管理者，实现了对对象的统一管理，也实现了测试对象与测试脚本的分离。

　　

　　进一步的深入，会发现自动化脚本中的逻辑结构的功能实现紧密的结合在一起，给后期的维护和修改造成的很大的麻烦。这时就会想到需要把测试脚本进行细分。因此除了按上面说到的把测试数据，测试对象分离出脚本外，还需要把脚本细分为：逻辑控制和功能实现脚本。也即实现了自动化脚本的四层架构设计。功能实现脚本即为把脚本把每个小功能细分出来并编写成一个个独立的小的功能实现脚本，如登录，登记等等。然后编写逻辑控制脚本来实现这些小的功能实现脚本执行的先后和次数，如，实现流程等。

版权声明：原创作品，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。本文出自chenyb85的51Testing软件测试博客：http://www.51testing.com/?130986

　　

　　实际应用自动化后，会发现很多脚本实现方法相同或相似，而且功能小脚本拼接不容易修改。这时可以再上面四层架构的基础再增加一个框架结构，实现五层架构。利用框架封装一些常用的方法、函数和小脚本，以实现公共脚本的复用，减少自动化脚本的开发时间。在框架中还可以把上面的四层架构的内容包含到框架中进行统一管理和调度。当然还可以利用配置文档（如ini文件）来实现流程或其他功能的可配置测试（如，网址，用户名，密码。方便改变测试环境后修改）。