04.软件性能测试

摘要:
在经过 4 个 RC 版本后，JMeter 终于发布了 2.3 的 final 版本。在 Apache JMeter 的官方站点上，可以看到从 2.2 到 2.3 还是有很多变动的，包括修改了很多 bug 和完善了一些功能，详情请见 http://jakarta.apache.org/jmeter/changes.html

JMeter 2.3 final version 的下载地址是 http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi

另外，今早又收到了 JMeter 的新邮件，其中提到了一个将来可能会在 JMeter 的新版本中增强哪些方面。包括对于功能的改进、完善，对用户手册的改进，以及对开发过程中一些具体工作的改进，最后也初步定义了将来在 JMeter 2.3.1 中将要发布的特性。详情见 http://wiki.apache.org/jakarta-jmeter/FutureReleases

大家一方面可以通过上面的链接了解一下 JMeter阅读全文

posted @ 2007-10-05 10:06 Jackei 阅读(761) | 评论 (4) 编辑 |

JMeter 2.3 RC1 终于出来了

摘要:

在等待了粉久粉久以后，JMeter 的新版本终于出来了！
额先来给乡亲们报个信，正在下载中，过两天有时间就研究一下 ^_^

想知道 2.3 和 2.2 相比有什么变化吗？看这里：http://people.apache.org/~sebb/jmeter-2.3/site/changes.html

下载地址：http://people.apache.org/~sebb/jmeter-2.3/dist/

阅读全文

posted @ 2007-07-04 11:40 Jackei 阅读(783) | 评论 (8) 编辑 |

WebLOAD 已经开源了!

摘要:

WebLOAD 是 RadView 公司开发的一款 Web 性能测试工具，从1996年至今已经到了8.0版本。虽然 WebLOAD不如 LoadRunner 那么强大，但是价格也便宜很多，并且做为一个商业工具，在整套解决方案的提供上要比一般的开源和免费工具好很多。其实我们一直都是用 JMeter 和 ab 来完成所有的性能测试的，加上操作系统自带的性能监控工具和 Excel 分析结果，一般也够了。不过唯一一点不太满意的就是 JMeter 在模拟大量并发时的稳定性问题。现在WebLOAD 开源，等于又多了一个选择，毕竟是有12年商业工具开发历史的，可以考虑一下。

另外，WebLOAD 现在分为了两个版本——WebLOAD Open Source 和 WebLOAD Professional。相对于 Open Source 的版本，WebLOAD Professional提供了更多的Add-on，更强大的功能以及Service。具体信息请参见 WebLOAD 官方网站的介绍。
阅读全文

posted @ 2007-06-20 09:44 Jackei 阅读(3122) | 评论 (7) 编辑 |

《LoadRunner没有告诉你的》之七——使用 LoadRunner 连续长时间执行测试，如何保证参数化的数据足够又不会重复？

摘要: 其实方法很简单。无论上 LR 还是 JMeter，都提供了将多个参数的取值存放在同一个文件中，或者每个参数单独指定一个文件的功能，针对上面这个例子，我们只是简单的创建了两个文件和三个参数，第一个参数和第二个参数（用户账号和密码）存放在第一个文件中，有1000条记录；第三个参数（Movie 的 ID）存放在第二个文件中，有999条记录。然后在测试工具中设置参数取值的读取为顺序读取并且循环读取。通过这种简单的方法组合出了大量的数据。阅读全文

posted @ 2007-06-13 21:43 Jackei 阅读(4570) | 评论 (13) 编辑 |

软件性能测试实践 PPT 发布——第九次广州软件测试交流会版本

摘要:

交流会 PPT 下载

另外一篇参考文档：Sizing Oracle on Microsoft Windows and Dell PowerEdge Servers 下载

阅读全文

posted @ 2007-02-04 10:25 Jackei 阅读(1643) | 评论 (8) 编辑 |

[转贴]在 JMeter 压力测试工具中使用变量和函数

摘要:

原文如下，写的非常不错。

在 JMeter 压力测试工具中使用变量

阅读全文

posted @ 2007-01-21 22:38 Jackei 阅读(1844) | 评论 (0) 编辑 |

理解 JMeter 聚合报告（Aggregate Report）

摘要: Aggregate Report 是 JMeter 常用的一个 Listener，中文被翻译为“聚合报告”。今天再次有同行问到这个报告中的各项数据表示什么意思，顺便在这里公布一下，以备大家查阅。阅读全文

posted @ 2007-01-17 21:40 Jackei 阅读(10580) | 评论 (29) 编辑 |

"性能测试最佳实践" PPT 下载

摘要:

原本做了这个 PPT 准备上周六参加 Rational 华南用户组的活动，最终因为家里突然有时没能去，这里把 PPT 放出来更大家分享一下吧。

点击这里下载

阅读全文

posted @ 2006-12-19 00:00 Jackei 阅读(2285) | 评论 (7) 编辑 |

《LoadRunner没有告诉你的》之六——获取有效的性能需求

摘要: 本文是《LoadRunner没有告诉你的》系列的第六篇，我将继续保持“无废话”的原则，用尽可能简洁、明确的语句来表述我对性能测试的看法和经验。在这篇文章中，我们要讨论的是如何获取“有效的”性能需求。阅读全文

posted @ 2006-12-12 00:52 Jackei 阅读(5946) | 评论 (10) 编辑 |

《LoadRunner 没有告诉你的》之五——无所不在的性能测试 (已完稿)

摘要: 提到性能测试，相信大家可以在网上找到很多种不同的定义、解释以及分类方法。不过归根结底，在大多数情况下，我们所要做的性能测试的目的是“观察系统在一个给定的环境和场景中的性能表现是否与预期目标一致，评判系统是否存在性能缺陷，并根据测试结果识别性能瓶颈，改善系统性能”。

本文是《LoadRunner没有告诉你的》系列的第五篇，在这篇文章中，我希望可以跟大家一起来探讨“如何将性能测试应用到软件开发过程的各个阶段中，如何通过尽早的开展性能测试来规避因为性能缺陷导致的损失”。

因此，本文的结构也将依据软件开发过程的不同阶段来组织。

另外，建议您在阅读本文前先阅读本系列文章的第三篇《理发店模型》和第四篇《理解性能》。阅读全文

posted @ 2006-12-04 00:38 Jackei 阅读(5649) | 评论 (7) 编辑 |

(更新到 2009-1-5) 两个新的系列文章的写作计划——《LoadRunner 没有告诉你的》和《JMeter从入门到精通》

摘要: 《LoadRunner 没有告诉你的》会包含一系列讲解性能测试本质和最佳实践的文章，其中有些内容是与工具无关的，有些则是内功心法，练好了用哪个工具都能杀人于无形^_^目的是尽可能的帮助大家更准确的理解性能测试，少走弯路。而《JMeter从入门到精通》则完全关注于JMeter(一款在国外非常流行和受欢迎的开源测试工具)在性能测试工作中的应用，其中有些内容或许会于《LoadRunner 没有告诉你的》系列有些交叉。我并不是一个狂热的“开源分子”，但是我会非常乐意提供一系列完整的JMeter中文指南，来帮助那些需要在工作中使用JMeter的同行“脱离苦海”^_^ 点击这里了解整个系列的创作进度，查看文章目录，或浏览已经完成的文章阅读全文

posted @ 2006-12-04 00:27 Jackei 阅读(23485) | 评论 (80) 编辑 |

《LoadRunner 没有告诉你的》之四——理解性能

摘要: 本文是《LoadRunner没有告诉你的》系列文章的第四篇，在这篇短文中，我将尽可能用简洁清晰的文字写下我对“性能”的看法，并澄清几个容易混淆的概念，帮助大家更好的理解“性能”的含义。阅读全文

posted @ 2006-12-04 00:20 Jackei 阅读(6820) | 评论 (19) 编辑 |

《LoadRunner 没有告诉你的》之三——理发店模型

摘要: 大概在一年前的一次讨论中，我的好友陈华第一次提到了这个模型的最初版本，经过几次讨论后，我们发现经过完善和扩展的“理发店模型”可以用来帮助我们理解很多性能测试的概念和理论，以及一些测试中遇到的问题。在最近的一次讨论后，我决定撰写一篇文章来专门讲述一下这个模型，希望可以帮助大家更好的理解性能测试有关的知识。

不过，在这篇文章中，我将会尽量的只描述模型本身以及相关的一些扩展，而具体如何将这个模型完全同性能测试关联起来，我不会全部说破，留下足够的空间让大家继续思考和总结，最好也一起来对这个模型做进一步的完善和扩展^_^ 我相信，当大家在思考的过程中有所收获并有所突破时，那种快感和收获的喜悦才真的是让人倍感振奋而且终生难忘的 ^_^

当然，我要说明的是，这个模型仅仅是1个模型，它与大家实际工作中遇到的各式各样的情况未必都可以一一对应，但是大的方向和趋势应该是一致的。
阅读全文

posted @ 2006-11-20 00:31 Jackei 阅读(15899) | 评论 (51) 编辑 |

转一份在 51testing 上的讨论——如何测试一个门户网站是否可以支持10万用户同时在线？

摘要: 这个帖子的内容比较典型，大家有兴趣可以也思考一下。

下面是楼主提出的问题

最近公司一个项目,是个门户网站,需要做性能测试,根据项目特点定出了主要测试项和测试方案
一种是测试几个常用页面能接受的最大并发数(用户名参数化,设置集合点策略)
一种是测试服务器长时间压力下,用户能否正常操作(用户名参数化,迭代运行脚本)
还有一种则需要测试服务器能否接受10万用户同时在线操作,但使用的Loadrunner的license只能支持1万用户,请问这时该如何制定该方案?阅读全文

posted @ 2006-11-16 01:21 Jackei 阅读(7559) | 评论 (5) 编辑 |

《LoadRunner 没有告诉你的》之二——描述性统计与性能结果分析（续）

摘要: 数据统计分析的思路与分析结果的展示方式是同样重要的，有了好的分析思路，但是却不懂得如何更好的展示分析结果和数据来印证自己的分析，就像一个人满腹经纶却不知该如何一展雄才 ^_^

一图胜千言，所以这次我会用两张图表来说明“描述性统计”在性能测试结果分析中的其他应用。
阅读全文

posted @ 2006-11-15 00:53 Jackei 阅读(13371) | 评论 (46) 编辑 |

《LoadRunner 没有告诉你的》之一——描述性统计与性能结果分析

摘要: LoadRunner中的90％响应时间是什么意思？这个值在进行性能分析时有什么作用？本文争取用最简洁的文字来解答这个问题。

为什么要有90％用户响应时间？因为在评估一次测试的结果时，仅仅有平均事务响应时间是不够的。为什么这么说？你可以试着想想，是否平均事务响应时间满足了性能需求就表示系统的性能已经满足了绝大多数用户的要求？

假如有两组测试结果，响应时间分别是 {1，3，5，10，16} 和 {5，6，7，8，9}，它们的平均值都是7，你认为哪次测试的结果更理想？

假如有一次测试，总共有100个请求被响应，其中最小响应时间为0.02秒，最大响应时间为110秒，平均事务响应时间为4.7秒，你会不会想到最小和最大响应时间如此大的偏差是否会导致平均值本身并不可信？

阅读全文

posted @ 2006-11-11 22:59 Jackei 阅读(20241) | 评论 (55) 编辑 |

《JMeter从入门到精通》之一——开始你的第一个JMeter脚本

摘要: JMeter是一款在国外非常流行和受欢迎的开源性能测试工具，但是因为相关的中文资料太少，很多朋友都无法被倒在大门外。我想这是任何一个开源工具的开发者不希望看到的。

在接下来的一段日子里，我将会把我在 JMeter 性能测试方面的经验进行一个整理和总结，由浅入深的来帮大家完成“JMeter从入门到精通”的过程。我相信在这个过程中可以帮助大家了解到更多有关性能测试的知识和经验，甚至包括一些LoadRunner等商业测试工具所无法提供给你的经验。阅读全文

posted @ 2006-11-10 23:18 Jackei 阅读(34902) | 评论 (67) 编辑 |

[翻译]如何解决使用 JMeter 时遇到的问题

摘要: 这是对 JMeter 官方网站上一篇文章的翻译。
点击这里可以访问原文JMeterTroubleShooting。

*

check the log file. This is normally in the launch (i.e. bin) directory, and is called "jmeter.log".
* 查看 JMeter 的日志文件，通常这个日志文件在你启动 JMeter 的目录下，例如%JMeter_HOME%\bin 目录，文件名通常是 jmeter.log。（这个日志文件中的内容只是与 JMeter 本身运行有关的日志信息，与脚本的执行没有直接关系，脚本执行的情况请查看 JMeter result 文件，扩展名为 .jtl——译者注）
*

check the JMeter documentation to ensure that the test script has been set up correctly
* 查阅读全文

posted @ 2006-11-06 16:22 Jackei 阅读(8042) | 评论 (3) 编辑 |

What's Scalability and Scalable System?

摘要:

Wiki 百科上的原文可以点击这里看到。

简单的说，Scalability （可伸缩性）是衡量一个系统处理能力或容量的属性，举个例子说，就是当为一个系统增加了资源——特别是硬件资源后，系统可以承受更大的负载，并获得更大的吞吐量，这个系统可以被称为 Scalable System （可伸缩的系统）。例如测试一个使用了负载均衡和集群技术的系统，测试当增加新的 Cluster 之后是否可以承受更大的负载，并获得相应的吞吐量提升。

阅读全文

posted @ 2006-10-25 21:22 Jackei 阅读(937) | 评论 (0) 编辑 |

45 个 LoadRunner 面试问题(附答案)

摘要: 45 个比较基本的 LoadRunner 面试问题 ^_^阅读全文

posted @ 2006-10-20 13:31 Jackei 阅读(7664) | 评论 (3) 编辑 |

[强烈推荐] 性能测试方法论

摘要: 强烈推荐的一篇文章。英文原版点击这里下载。

中文版可以点击这里访问。< br>
阅读全文

posted @ 2006-10-19 15:42 Jackei 阅读(2111) | 评论 (3) 编辑 |

"并发用户数量"的正确英文表示

摘要: 并发用户数量
the number of concurrent users

最佳并发用户数量
the optimum number of concurrent users

最大并发用户数量
the maximum number of concurrent users阅读全文

posted @ 2006-10-12 10:31 Jackei 阅读(2959) | 评论 (2) 编辑 |

JMeter 中的如何区分 Server Time 和 Network Time

摘要: 在 LR 中是有一个“网页细分图”的，通过这个图，你可以比较容易的区分哪些请求的响应时间最长，如果响应时间过程，是消耗在server处理的时候，还是消耗在网络传输过程中——也就是所谓的 Server time 和 Network time。
JMeter 并没有提供这么详细的区分——至少目前尚未发现，但是在 JMeter 的执行结果中也有一个字段可以利用一下。阅读全文

posted @ 2006-09-27 18:12 Jackei 阅读(1497) | 评论 (5) 编辑 |

使用 JMeter 分布式性能测试

摘要: 作为一个纯 JAVA 的GUI应用，JMeter 对于CPU和内存的消耗还是很惊人的，所以当需要模拟数以千计的并发用户时，使用单台机器模拟所有的并发用户就有些力不从心，甚至还会引起JAVA内存溢出的错误。不过，JMeter 也可以像 LoadRunner 一样通过使用多台机器运行所谓的 Agent 来分担 Load Generator 自身的压力，并借此来获取更大的并发用户数。根据 JMeter官方文档的署名，你需要自己完成这个配置，不过不用担心，这将非常简单 ^_^阅读全文

posted @ 2006-09-14 22:57 Jackei 阅读(9119) | 评论 (58) 编辑 |

简单配置 Tomcat JVM 的方法 —— WINDOWS 平台适用

摘要: 1.新建一个环境变量，命名为：CATALINA_OPTS ；
2.给这个环境变量赋值：-server -Xmx400m （-Xmx400m 表示 JVM 的最大值，这里表示 400 MB，可以自己修改为其他值）；
3.重启 Tomcat，完成。阅读全文

posted @ 2006-09-13 18:04 Jackei 阅读(1414) | 评论 (0) 编辑 |

[zt] Viewing the Apache server status

摘要: 检测 Apache server 状态或者做性能测试时会需要用到。阅读全文

posted @ 2006-09-13 17:35 Jackei 阅读(812) | 评论 (0) 编辑 |

使用命令行方式运行 JMeter 脚本

摘要: 今天尝试 300 个虚拟用户连续运行 5 分钟时——使用 GUI 方式，发现开始运行后不久 UI 就失去了响应，并提示一个有关 AWT 的错误，最终只能把 Java 进程结束掉。但是使用命令行方式时却很稳定。
不过当在命令行方式下尝试 500 个虚拟用户连续运行 5 分钟时，JMeter 抛出了一个 Out of Memory 的异常并退出了进程。阅读全文

posted @ 2006-09-08 22:47 Jackei 阅读(4778) | 评论 (8) 编辑 |

解决 JMeter 中 SQL 语句参数化的问题

摘要: 当使用 JMeter 的JDBC 脚本对数据库进行测试时，JMeter的JDBC Request中包含的SQL语句时无法使用参数的。例如 SELECT * FROM ${table_name} 是无效的。

如果需要实现同时多个不同的用户使用不同的SQL，可以通过把整条SQL语句参数化来实现。例如把SQL语句放在 csv 文件中，然后在JDBC Request 的Query 中使用参数代替 ${SQL_Statement} 。阅读全文

posted @ 2006-08-01 11:46 Jackei 阅读(2034) | 评论 (12) 编辑 |

LoadRunner 同开源性能测试工具 OpenSTA 的比较

摘要: 前端时间做评估的时候找到的，有兴趣的朋友可以了解一下。

两篇，第一篇来自 testingreflections.com ——测试大师云集的地方 ^_^

第二篇来自 AdventNet 公司的一份评估报告，宣传自家产品的意味比较浓。阅读全文

posted @ 2006-08-01 08:59 Jackei 阅读(3725) | 评论 (0) 编辑 |

如何解决 JMeter 通过 JDBC 访问 Oracle 和 MySQL 的问题 (留言中有 Test Plan 实例下载)

摘要: JMeter 的手册中描述了如何访问 MySQL，但是没有说明如何访问 Oracle。对于没有 Java 应用开发经验和对 Oracle 不是特别熟悉的朋友，可以参考这篇文章来简单、快速的配置好 JMeter 中的 JDBC 连接和 JDBC Request。阅读全文

posted @ 2006-07-31 14:02 Jackei 阅读(7864) | 评论 (29) 编辑 |

介绍几个有关 ab 的有用的参数

摘要: 参数格式: -n number_of_requests
用来标明在本次测试中将要发送的请求的总数

参数格式: -c Number_of_requests_at_one_time
用来标明每次发送多少请求

参数格式: -e csv_file_full_path
表示把响应时间存放到一个 csv 文件中——CSV文件表示用逗号来分隔的文件。

参数格式: -g tsv_file_full_path
表示把每个请求的响应情况存放到一个 tsv 文件中——TSV文件表示用 Tab 健来分隔的文件。
阅读全文

posted @ 2006-07-20 20:12 Jackei 阅读(870) | 评论 (2) 编辑 |

开源性能测试工具 - Apache ab 介绍

摘要: ab的全称是ApacheBench，是 Apache 附带的一个小工具，专门用于 HTTP Server 的benchmark testing，可以同时模拟多个并发请求。前段时间看到公司的开发人员也在用它作一些测试，看起来也不错，很简单，也很容易使用，所以今天花一点时间看了一下。

通过下面的一个简单的例子和注释，相信大家可以更容易理解这个工具的使用。
阅读全文

posted @ 2006-07-18 22:55 Jackei 阅读(23994) | 评论 (21) 编辑 |

Oracle 性能诊断和调优 (不断更新……)

posted @ 2006-06-25 09:34 Jackei 阅读(1849) | 评论 (2) 编辑 |

Apache + jk + Tomcat 实现集群

posted @ 2006-06-21 22:11 Jackei 阅读(886) | 评论 (1) 编辑 |

[zt]性能测试计数器分析指南

posted @ 2006-06-16 11:56 Jackei 阅读(3778) | 评论 (0) 编辑 |

性能测试方法——推荐阅读

摘要: 也是一篇不错的文章，理清一些基本的思路。

英文版

中译版
阅读全文

posted @ 2006-04-13 12:34 Jackei 阅读(915) | 评论 (0) 编辑 |

Tuning Your Stress Test Harness —— 很值得一读

摘要:

Tuning Your Stress Test Harness

一篇不错的文章，讨论了一个在性能测试过程中很容易产生不同理解的概念——并发。另外，还提出了如何通过对服务器施加有效的负载来获得更加真实可靠的性能数据的方法。

很值得一读。阅读全文

posted @ 2006-04-11 23:01 Jackei 阅读(831) | 评论 (2) 编辑 |

如何监视 WINDOWS 的性能

摘要: 本来也想自己写这样一个系列的文章，不过后来想到 Bill 不太可能不预先给我们准备好这些东西，于是去 MSDN 搜索了一下，嗯，收获还不少。有兴趣的朋友可以参见这个链接。

随着各家厂商的竞争越来越激烈，技术支持和服务逐渐变成了竞争的主要内容，于是，就有了 M$ MSDN 、IBM developerWorks 这样的地方，可以有大量的资料让我们免费获取。大家鼓掌鼓励一下
阅读全文

posted @ 2006-04-04 09:42 Jackei 阅读(643) | 评论 (1) 编辑 |

性能测试的 Check List （不断更新中）

摘要: 去年整理的一篇文档，最近做性能测试，翻出来参考，自我感觉良好，同大家分享。 ^_^阅读全文

posted @ 2006-03-24 09:32 Jackei 阅读(1288) | 评论 (4) 编辑 |

开源工具+开源工具＝强大的商业工具？

摘要: 今天在51的坛子上发现有测友提到 LoadRunner 的 License 被限制的问题。记得原来听朋友说，现在市面上流行的几个 LR 的 License 都不是盗版的，而是 Mercury 放出来的，虽然支持的并发用户数少，但是很多时候也足够用了。现在 Mercury 已经在性能测试工具方面占领了很大的市场，就把原来的 License 禁止了，有点“卸磨杀驴”的意思。阅读全文

posted @ 2006-03-16 17:58 Jackei 阅读(688) | 评论 (0) 编辑 |

IPTV系统的VOD与TV业务性能测试

摘要: IPTV的未来发展正在成为业界的焦点话题。据市场研究公司MRG的统计，全球IPTV用户将由2004年的200万增加至2010年的2000万，预计全球IPTV市场2005～2010年的复合增长率为102%。在国内，IPTV产业尚处于试验阶段，中国电信、中国网通、中国铁通正在积极开展IPTV试验。　　目前已有很多设备厂家提供IPTV系统平台和设备，业界公认IPTV业务包含两种基本业务：VOD点播和TV直播。国内IPTV的发展如火如荼，对于 IPTV系统的测试也亟需进行规范，本文拟将对IPTV系统的这两种基本业务的性能测试进行简单的探讨。本文仅仅考虑端到端的性能测试，测试的观察点在于用户侧，不考虑服务器端的分级缓存性能。　　由于VOD点播网络和TV直播网络在网络结构上的不同，VOD分发需要依靠CDN网络，而TV的分发则需要依靠组播网络，不需要CDN网络进行缓存，基于此，该两种业务性能测试的着重点也不尽相同。阅读全文

posted @ 2006-02-16 16:27 Jackei 阅读(881) | 评论 (6) 编辑 |

LoadRunner日积月累(9) —— 分段录制脚本

摘要: 在LR的参考资料中也可以看到，建议将登录系统这类的脚本放在Init部分，而将业务相关的脚本放到Action部分，退出系统的脚本放到End部分。这样做除了使脚本结构更加清晰以外，还可以保证在多次迭代时，不用反复的重复登录和退出操作。

今天看到论坛上有朋友问是否一定要每次录制完以后把脚本从Aciton部分分别剪切、粘贴到Init和End部分？其实可以在录制脚本的时候就分段录制的。如下图所示
阅读全文

posted @ 2005-09-01 21:45 Jackei 阅读(2404) | 评论 (6) 编辑 |

LoadRunner日积月累(8) —— 添加注释

摘要: 将LR返回结果保存为Session的好处之一，是可以添加注释，将你在分析图表过程中的思路记录下来，不至于下次看时毫无头绪，重新来过。阅读全文

posted @ 2005-08-31 22:37 Jackei 阅读(1224) | 评论 (0) 编辑 |

LoadRunner日积月累(7) —— 使用 Scenario Start Time

摘要: 在进行稳定性测试时，我们希望在可以充分利用时间和测试资源，让两个场景分别在前半夜和后半夜运行。为此需要准备两台Controller机，分别打开不同的场景，并对两个场景持续运行的时间进行设置——例如都运行6个小时。然后通过Scenario Start Time来分别设置两个脚本开始运行的时间——例如第一个脚本设置为从当天下午6点钟开始运行，第二个脚本从第二天凌晨1点钟开始运行。如下图阅读全文

posted @ 2005-08-24 23:12 Jackei 阅读(1587) | 评论 (2) 编辑 |

LoadRunner日积月累(6) —— 使用View Measurement Trends

摘要: 上面这个图是对Google的搜索功能的一次测试后，使用“Merge Graphs…”功能将Hits per Second、Throughput、Average Transaction Response Time三个图组合在一起生成的图表，我们希望从中可以看出在场景执行过程中，随着Hits per Second的增加，Throughput的变化情况，以及对Average Transaction Response Time的影响。

但是因为三个原图中的性能计数器的数值和单位都不同，当Analysis使用同样的比例进行显示时，根本无法体现出三者的关系——图中高高在上的绿色线是Throughput，而几乎平伏在接近0水平的是Hits per Second和Average Transaction Response Time。

这种情况下，除了手工调整各个性能计数器的显示比例外，一个更简单有效的方法是使用“View Measurement Trends”功能（如图1所示）。使用后的效果就像下面这样
阅读全文

posted @ 2005-08-23 23:28 Jackei 阅读(1381) | 评论 (0) 编辑 |

LoadRunner日积月累(5) —— Init all VU before run

摘要: 我们需要对一个商业系统进行整体性能测试，按照对用户以往使用情况的分析，我们整理出了用户在多个业务上的分布情况，也在Controller中添加了这些业务所对应的脚本，设置了每个脚本对应的虚拟用户数。我们还希望可以模拟一开始就让所有用户同时在线的情况，但我们又不希望使用集合点在每次迭代时都对各个业务造成那么大的压力——因为对组合场景来说，这种压力似乎又不太合理……阅读全文

posted @ 2005-08-22 20:07 Jackei 阅读(1558) | 评论 (6) 编辑 |

LoadRunner日积月累(4) —— 使用 Cross with Result

摘要: 有些时候我们需要将多个返回结果放在一起进行对比，例如，一个场景在多个不同的发布版本上运行后，我们希望通过对测试结果的比较来判断不同版本的性能差别；或者对同一个压力点，我们设计了几个场景，在这几个场景都运行通过后，我们要比较一下不同的负载对系统的影响。当然，你也可以因为更多的原因产生这种需求。不过不管怎么说，如果为了实现这个愿望，而不得不同时打开几个Analysis，那恐怕的确是有些麻烦——况且在比较这些结果时还要不停的切换窗口。

LoadRunner提供的一个比较好的功能可以帮助我们更简单的完成这项工作——“Cross with Result”。如下图所示阅读全文

posted @ 2005-08-22 00:54 Jackei 阅读(983) | 评论 (0) 编辑 |

LoadRunner日积月累(3) —— 场景的管理

摘要: 在一个使用LoadRunner进行的性能测试项目中，需要管理的东西通常有三种：

1. 通过VuGen生成的脚本；

2. 通过Controller生成的场景；

3. 执行场景生成的返回结果。

我通常习惯于用下面的目录结构来管理这些内容，如下图
阅读全文

posted @ 2005-08-21 12:21 Jackei 阅读(1406) | 评论 (2) 编辑 |

LoadRunner日积月累(2) —— 将Result保存为Session

摘要: 每次在Controller中运行一个场景时，LR都会把返回结果保存在你指定的目录下，场景运行结束后，你可以在该目录中找到一个扩展名为“lrr”的文件，双击这个文件就可以在Analysis中看到在本次场景运行过程中LR收集到的各种信息。但是每次在Analysis中打开返回结果时，LR都要去ACCESS数据文件中读取数据，然后初始化图表，耗时太长。所以我们可以将返回结果保存成Session ……阅读全文

posted @ 2005-08-20 16:11 Jackei 阅读(1616) | 评论 (1) 编辑 |

LoadRunner日积月累(1) —— WINDOWS下的安装配置要求

摘要:
折腾了一阵，总算是在自己那台赛扬566/128M内存的机器上把LR装好了。顺便看了看LR的手册，嗯，这样的机器也还是可以跑起来的 ^_^

等到年底家里再添台机器，就可以搭个小环境在家里作试验了 ^_^阅读全文

posted @ 2005-08-20 11:56 Jackei 阅读(1572) | 评论 (2) 编辑 |

性能测试－转自MSDN

摘要:
明确了具体的性能要求后，可以开始进行测试，确定应用程序是否满足这些要求。性能测试假定应用程序稳定、可靠地运行。因此，在测试中消除尽可能多的变数很重要。例如，代码中的错误可以导致出现性能问题，甚至掩盖性能问题。要精确地比较不同性能测试的结果，应用程序必须正确地工作。如果调整过程修改了组件的实现，则重新测试应用程序的功能尤其重要。应用程序必须通过功能性测试后才可以测试性能。除了应用程序更改外，硬件、网络通信量、软件配置、系统服务等诸多方面也会发生意外的更改。控制应用程序更改很重要。阅读全文

posted @ 2005-05-19 11:47 Jackei 阅读(1062) | 评论 (0) 编辑 |

让LoadRunner走下神坛

摘要: Loadrunner无疑是一个强大有力的压力测试工具。它的脚本可以录制生成，自动关联；测试场景可以面向指标，多方监控；测试结果图表显示，拆分组合。相信有人这样想象过：拿着一张性能指标标准列表和测试数据相比较，如同PH试纸一样，遇碱则蓝，遇酸则红，一目了然，之后就可以大声地喊道：我找到了软件系统的性能瓶颈！
然而，我们无论在loadrunner前面加多少个“强大”、“智能”的形容词，别忘了其最终修饰的只是一个名词－“工具”。《大话西游》中也有相当精辟的论断：官兵？最多也只是个长了痔疮的官兵！把loadrunner比喻成长了痔疮的官兵有点粗俗，但loadrunner它是个工具，那么是否能够找到性能瓶颈就取决于使用工具的人，而不是工具本身。要做一个成功的性能测试，仅读懂和精通了loadrunner的使用手册是不够的，还需要对被测软件系统的方方面面都要有了解，比如软件体系构架，网络拓扑等知识。这就如同一个技艺高超的木匠，并不是因为他背熟了凿子，锤子的说明书，而是他能结合木材的质地和尺寸，用凿子和锤子这些工具做出一把精巧的椅子来。那么在性能测试中，人的智慧活动体现在哪里呢？阅读全文

posted @ 2005-05-10 15:23 Jackei 阅读(1631) | 评论 (1) 编辑 |

04.软件性能测试

公告

搜索

随笔分类(933)

Blog收藏

积分与排名

最新评论

阅读排行榜

评论排行榜