由于我们需要在投入生产之前设法在上线前的环境中调优我们的应用系统，这样才能验证配置，所以一个随之而来的问题就是我们需要在这个环境中执行的负载测试脚本。对一个企业应用进行调优的步骤包括实施一些最佳实践设置，负载测试应用，观察应用的行为，以及适当调整配置参数等。这是一个叠代过程，我们需要不断调整以达到最优的配置。一些调整可能会提高性能，而一些会降低性能。这也是为什么性能调优不应该放在开发周期后期的一个原因。
假设我们根据我们的负载脚本进行调优，那对你又意味着什么呢？这意味着负载脚本应该真实反映现实世界用户的使用行为。假设我们在优化一个Web搜索引擎，我们可以写一个测试脚本，该脚本总是在测试苹果和香蕉，但是用户是这样使用吗？我们可以为此调整出最好的性能。但是当查询Bea和IBM时，又会怎样呢？在我的应用中，我可以将技术公司的词汇放在与水果和蔬菜不同的数据库中，那么在测试环境中，永远不会执行到那段代码，我们的调优努力也就徒劳无益了。
更好的解决办法是确定名列前茅1000 或10,000 个查寻词组和他们频率。然后, 计算每个被请求的时间百分比并且编写按照该百分比查询这些词汇的测试脚本。对于剩余的百分比，你可以把负载测试工具连到一个词典，可以随机生成查询的词汇。
3 使用工具分析
编写一个典型用户负载脚本的困难之处是发现你的用户是怎么使用的应用的。 这不是一门精确的学问。但是为得到一个合理的可靠的结果, 第一步是看看您的访问日志。现在, 我不会推荐手工做这件事，因为对于一个中型的Web应用，工作量也是巨大的。现在有大量商业或免费工具可为您分析访问日志。
这些工具将告诉你有关你的服务请求的一些情况:
a) 将服务请求按时间的百分比排序，并显示百分比。
b) 放大或缩小分析时间间隔，便于以粗粒度或细粒度方式显示结果。
c) 识别每天，周，月，年的高峰使用时间。
d) 跟踪字节传输和请求的平均时间。
e) 按照你的应用的内部，外部或地理位置，识别和分类请求的用户。
f) 汇总成功请求的百分比。
g) 汇总HTTP发生的错误。
h) 汇总顾客忠诚度, 譬如回头客和平均会话长度。
i) 跟踪从其他站点的转入情况。
无论你选择哪种软件分析访问日志，重要的是你应该做这些分析工作并且把这些信息作为编写测试脚本的基础。有时访问日志的作用是有限的，在某些情况下不能提供足够的信息。例如前端应用只使用一个URL发出请求，而通过在请求中嵌入不同的参数区分业务功能。在这种情况下，就需要高级一些的工具根据不同的请求参数监测应用的使用情况和划分业务功能。
访问日志只能提供部分解决办法。接下来需要对应用本身有更深入的理解。例如，当发出一个特定的服务请求时，你应该知道其不同的选项所控制的相应行为。这些信息的最好来源是应用的用例和负责该功能的架构设计人员。这些工作的目标是识别出真实世界中用户的使用行为，所以应该彻底和全面地完成此阶段任务。这里发生的错误将导致上文提到的"苹果和香蕉"搜索引擎的问题。
为了全面获得更可靠和更详尽的最终用户行为信息，可以考虑Quest公司的User Experience Monitor(UEM)。UEM在最终用户和Web Server之间，实时捕获向你应用环境发出的每个请求，可提供有关真实用户所做的详尽数据，包括连接速度，浏览器版本，按地理位置汇总等信息。由于采用了被动的网络Sniff技术，所以对应用的性能影响为零。
4 用户如何退出系统
最后，有一个值得重视的问题，我们了解到目前客户在编写负载测试脚本时最大的错误是：用户不知道怎样退出应用系统。不管你把退出按扭作的多大，至多只有20%用户会使用。这是由于现在将Web 作为主要业务平台的必然结果。商业Web站点正式基于此而得以快速发展并统治了Inte.net.
因此，现在用户习惯以下面方式退出网站：
1. 离开当前网站，转到其他网站
2. 关上浏览器窗口。
由于这已是根深蒂固的Web 使用模式，所以不能指望用户正确地退出网站。当编写测试脚本时，应用确定正确退出和非正确退出的用户比例，然后根据这个比例编写脚本。我们遇到的一个大型汽车网站，已经为此困扰了一年多，他们的应用服务器每隔几天就会崩溃，他们已经习惯于在晚上重起应用服务器。仔细分析HTTP会话的使用模式，我们发现闲置的会话非常多。
我们检查了他们的测试脚本，发现每个测试场景都包含了正确的退出。他们就是基于这个假设进行优化的，因此优化工作并没有触及闲置的会话内存问题。在调整测试脚本，重新优化系统环境后，由于"Out of memory"引发的强制重起问题就解决了。
//
文章来源于领测软件测试网 https://www.ltesting.net/
