性能测试需求分析：WebTrends Log Analyzer的应用【一】

&RwA3R b0

      作为测试工程师，大家都会接触性能测试；在我接触的同行朋友里，谈的比较多的话题也是性能测试。一方面因为这个工作需要的技能比较全面，有所挑战，另一方面也正因如此，很多人都想学、想做、想做好！诚然，性能测试在目前的测试行业是个热门领域，很多企业招聘里有所要求和侧重，而对个人职业发展也是个不错的选择（详见：软件测试职业发展三步曲之一 - 软件测试职业发展方向）。

    在我的面试经历中，经常向求职者问道：你们做性能的需求来自哪里？答曰：客户给我们！又问：客户给的需求明确么？答曰：不明确！问曰：不明确的话怎么办？答曰：客户如此要求，满足它既可！我心想：那么你的价值何在？莫非只是被客户驱动型的按照他们提出的目标来做事？

    这是个比较极端的例子。实际上国内多数软件公司在做性能的时候有此现象，但是会比较该情况要好；多数人会告诉我：我们按照客户的需求，要模拟500个人并发在系统做操作，每个页面响应时间不超过5秒；或者持续测试5*24小时没有CPU和内存问题…但是我这里想说的是，500个并发用户来自哪里（除了客户因素外）？500个用户如何分配在不同的并发操作上？每批用户行为测试时间持续多久？在一个完整的工作日8小时内，这批用户分别如何分布？…我确信这样进一步的问题，客户不会告知，但是作为测试工程师，尤其是专业的性能测试工程师，在做性能测试的时候，肯定要考虑这样的问题，否则你的测试结果可能不准确，在客户面前没有说服力，甚至即便你发现性能瓶颈，开发团队都会有理由怀疑你，理由就是：你模拟的场景不足以反映真实用户的操作行为！

    这篇文章里，我想讲讲性能测试里需求分析的事情。我们国内多数公司是做项目的，也有做产品的，开发技术主要是.NET或J2EE的BS架构，也可能是传统的CS架构。一般来说，一个项目或产品刚立项后，在需求分析阶段，我们总要考虑软件的性能需求，作为后续性能测试的依据。那么这个需求来自哪里呢？

• 客户口述，业务人员搜集编写

• 技术人员自行分析

    第一个方式是多数公司和项目团队如今采用的模式，但是大家都很清楚，光靠客户的讲述还是远远不够的，尤其对于一些国企或非IT类客户，他们也许对性能需求没有概念，很可能随口说说，比如“我们系统要支持一万用户”这样的一句话。那么第二个方式就是我要说的重点。虽然专业的客户也普遍存在，如银行、电信、金融行业的大客户，他们有专业的IT部门，可以提出明确、切合实际的需求给软件供应商；但是作为一个专业的软件测试工程师，尤其专注于性能测试的团队，也该有一套自身的性能需求分析方法，作为客户提出明确需求后的一个有力的补充！从而让后续性能测试的结果真实、可信，任何人都提不出毛病。

    我们说，性能测试的目的是找出系统的性能瓶颈，并修改它；那么为了让性能测试的执行策略能够捕获瓶颈，就要有有个明确的性能测试目标；达到目标的无瓶颈，没达到则有瓶颈！一般来说，一个典型网络应用程序的性能目标有以下四个维度：

• 响应时间

• 服务器吞吐量

• 服务器资源利用率

• 系统负载量
  8I*M(RAD%B*a0

    这些概念这里不做解释，相信同行们都了解。总之在需求分析阶段，这些指标都会根据产品特征、开发技术、客户确认得到明确的值域。接下来就是进一步的事情了：我们为了后续性能测试的时候有一套切实可信的测试策略，要在需求分析阶段去分析系统的用户行为。这也就是我要说的“技术人员自行分析”的工作。为什么要分析用户行为呢？这是我们将来做性能测试时候设计性能场景的依据，否则上述的4个指标如何通过明确的测试得以体现呢？那么为了保证最终性能测试结果准确，就要保证性能测试场景真实；如何达到真实的场景模拟？只有知道真实的客户的行为是什么样，我们就模拟什么样。例如在很多网友写的文章里都讲到，我们需要把一个系统的业务流根据时间轴进行分解，然后逐个开发性能测试脚本去实现它。简单拿51JOB为例，如要对51JOB整个系统进行性能测试，我们要把51JOB拆分出若干业务流：统计时间为正常工作日的8小时，有500用户在录入简历，1000用户在搜索招聘职位，300用户在搜索简历，100用户在浏览广告…后续就是开发脚本去模拟录入简历、搜索招聘职位、搜索简历、浏览广告的操作而已。那么问题来了，凭什么知道8小时内是500用户录入简历？1000用户搜索招聘职位？….这些数据从何处来？答案很简单了，从客户的历史日志来！

    这里排除了一种情况，那就是如果贵公司开发的应用系统是全新的软件，从来没有上线过，自然没有没有任何历史日志。我觉得这种情况，完全要靠公司自身对产品特征、开发技术以及行业经验去分析、定义性能需求，然后再经过内部的专业性能测试，最终告知客户该系统对上述4个指标的描述。

    除此情况，不管贵公司要做性能测试的应用系统是新产品、是升级的、是迁移的、是二次开发的、是系统集成的等等，只要它曾经上线过，有真实客户操作过，那么自然会有真实用户的操作日志。（旁白：如果真的连日志都没有这么办？拜托，Mr麦兜，不要太较真，当我随便说说而已）巧了，恰好目前业内多数应用软件是BS架构，而它们的WEB服务器要么是IIS，要么是Apache；更巧了，我这里要介绍的工具WebTrends Log Analyzer就是专门分析IIS和Apache日志的专业工具！强吧?！

    关于IIS、APACHE这些WEB服务器的日志分析工具，其实有很多；如针对IIS的LogParserLizard、IISTrace，针对APACHE的XLogan，针对IIS、APACHE的AWStats使用尤其普遍。但是我这里要介绍的WebTrends Log Analyzer与它们的使用目的不同。在我看来，LogParserLizard、IISTrace、XLogan、AWStats是根据WEB服务器的运行进行数据采集后，根据一定的算法进行统计、归类、创建图表的工具；对测试人员来说，这类工具一般应用于性能测试里的性能分析环节。例如，我们多数人使用Loadrunner去做性能测试，当通过Loadrunner工具发现某个页面响应时间比较长后，因为LR对WEB响应时间的度量是一个黑盒层面，它无法很准确的告知该页面的代码解析和执行的时间；这种情况下，通过上述这类日志分析工具去查看该页面对应的WEB服务器对其代码解析的时间，从而帮助测试工程师或开发人员进一步去分析（当然数据库层面的时间分析，这里忽略）。这是非常可行和有效的分析手段，LogParserLizard、IISTrace、XLogan、AWStats这类工具的作用也体现于此。但是我介绍的WebTrends Log Analyzer的使用目的不在这里，事实上该工具根本不度量响应时间这一指标。WebTrends Log Analyzer的作用是根据现有日志文件去进行逆向反推的过程，它会根据日志的内容反推出当时的用户是如何在前台页面操作，从而分析出整个度量时间范围内的用户行为！例如，它会分析出该时间范围内，有多少用户在线，他们操作了哪些页面，在那些页面停留多久，用户使用的客户端是什么类型，来自哪个国家区域等等。对于一个上线的WEB系统来说，运营人员需要知道该系统的访问流量和访问行为，为了动态甚至自动的每天获知这些信息，WebTrends Log Analyzer就是选择之一。话说回来，这些虽然是业务层面的问题，但是对于性能测试需求分析阶段，这个工具就是我们制定性能测试场景的最有力的依据了！

    至此，WebTrends Log Analyzer是一款功能强大的Web流量分析软件，用它可处理超过15GB的日志文件，并且可生成关于网站内容信息分析的可定制的多种报告形式，如DOC、HTML、XLS和ASCII文件等格式，可处理所有符合工业标准的Web服务器日志文件，如非标准的、Proprietary、IIS、Netscape、APACHE、CERN、NCSA、O'Reilly、Lotus Domino和Oracle等日志格式。即使WebTrends Log Analyzer没有运行，也能通过使用独立运行的Scheduler计划程序自动输出流量分析报告，为管理员、Web开发小组和营销管理人员提供了一套分析日志文件的基本解决方法。

    与WebTrends Log Analyzer同类的软件还有Advanced Log Analyzer、FastStats Analyzer和Happy Log等。它们的使用非常类似，这里我只介绍WebTrends Log Analyzer的基本用法给大家；请看第二章。

                                            作者：叶赫华  2009年9月