性能测试框架设计
大纲：[*]测试环境搭建
[*]测试用例设计
[*]测试脚本框架设计
[*]测试报告框架
[*]测试分析指标
[ 本帖最后由 大漠行者 于 2008-12-16 10:11 编辑 ]
1. 测试环境搭建
<P>1. 测试工具： Webload </P><P>2. server 分布： </P>
<P></P>
<P>每个测试环境都是独立的局域网，测试机唯一可以与外界通信的就是console。</P>
<P>console控制测试的起始、并发等控制，load generator负责模拟并发用户load给应用server，同时console负责搜集测试机的性能参数：CPU,Memory，network等等。</P>
[ 本帖最后由 大漠行者 于 2008-12-16 10:10 编辑 ] 学习webload中，希望楼主更新 :handshake 原帖由 1qazse4 于 2008-12-17 09:36 发表 http://bbs.51testing.com/images/common/back.gif
学习webload中，希望楼主更新 :handshake
本帖关注与测试框架，所以对WEBLOAD可能涉及不多，不过可以交流，毕竟使用过，或许能为你解答些什么。
2. 测试用例设计
<P>通常性能测试最关注的直接指标是：throughput 和 response time， 一般这两项指标都是通过测试工具直接给出的（loadrunner），这里谈下另一种方法思路。<BR>首先提到一个transaction的概念，这个是从用户角度提出的，所以transaction分两种： atomic transaction 和 compound transaction<BR>1. atomic transaction 是指单个http request。 比如请求一个图片，一个页面等等。 本节提到的throughput和response time是基于这个而来的。<BR>2. compound transaction是指为完成一件事情的所以atomic transaction的集合。这个指标更能符合用户的体验，比如网上购物，从筛选到下订单到付款，这一系列动作实际上有若干个atomic transaction（http request）组成的，如果把每个request的response time给用户看，他可能看不多，如果你能给他一个订货（search+check+submit）的response time，用户更能直观的理解和接受。<BR>所以对应的throughput也是基于compound transaction而来的，通常从人的感受角度，完成一个网上操作1秒钟是可以忍受的，所以我们可以用1秒作为单位，在这个单位时间内能够完成的compound transaction的数量就是它的throughput，这个指标同样比起单纯看单位时间内返回网络流量多来更直观，更有意义。</P><P>毕竟用户至上，所以一切的考虑应当从用户的角度 :)</P> 少了协议封装 模块
页:
[1]
