var _gaq = _gaq || []; _gaq.push(['_setAccount', 'UA-333696-1']); _gaq.push(['_trackPageview']); _gaq.push(['_trackPageLoadTime']); (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })();
  • 2007年10月09日

    【翻译】性能测试

    分类:

    原作者:Goranka Bjedov                                               

    原文链接

     

    这篇文章是我最好的针对我做什么,为何我做这,和为何我认为这是正确的做法的解释。性能测试是一项测试分类,它看起来似乎引起人们强烈的感情:恐惧感(哦,上帝,我不知道怎么去做是因为性能测试是如此之难!),无能感(我们买下了这套能做任何方面性能测试的工具,我们为它花费如此之多,然而我们什么都没获得!),困惑感(那么,究竟什么我理应再做?),并且我认为这没必要。

     

    把性能测试看作是你测试集成中的另一项工具――一些当你需要做的时候你将做的。它探讨了若干系统质量,这能被简化为:

    l  速度--系统反应的足够快否

    l  容量――结构是否充分地估量

    l  可扩展性――系统能否增长来应付今后的容量

    l  稳定性――系统能否在压力下运行正常

     

    于是,我做一项服务的性能测试,当风险分析表明掉进这一类风险将会耗费公司更多于是就该履行这项测试。(如果你名叫Google并且你关注你的牌子,这项测试发生于你启动的任何一项服务。)注意我正在谈论服务――我近乎完全跟服务器工作还没花费时间在担心客户端渲染/处理问题。当这些正变得日益重要并且通常是很复杂时,然后我考虑把这些作为功能性测试的我的工作的一部分,于是它们被设计,创建和执行由功能测试团队。

     

    另一个关于性能测试有趣的事是你将永远不能做到100%“正确”或“完成”。接受它,处理它,并且继续。如今现存的任何系统将依赖于成千不同的参数,而且如果我时间分析它们中的每一个,理解每两个或三个参数间的关系,绘制它们的影响曲线,尝试不维数它们,两年后我仍将测试我的第一项服务。想做任何东西少点会让我充满恐惧(一年之内他们不能严格地期望我提供有意义的性能测试结果,他们能吗?)但是我已然知道花费仅10%我全部的努力和时间我能提供至少90%的有意义信息给我的客户。而且,对大多数问题来说90%足够了。

     

    这样,这里是我实际做的――我创建了基准。如果我够幸运还有极好的信息关于个别产品当前使用率的答答声 (我经常这么做),我将确定这个基准覆盖的大部分操作是最先独占资源(不是单独使用就是累积)。我将对一个松散控制系统(会很好,如果对我们有的每项服务100台机器都归我,我能一天或一星期一次地使用它,但这会是昂贵和不切实际的)以不同负载(虚拟用户数)运行这个基准还研究它的行为。哪种事务需要多数时间?哪种事务看起来随着负载的增加日益变糟?哪种事务看起来不稳定(我不能够解释它们的行为)?我把这叫做探索性性能测试,而且我将重复我的这些测试知道我信服我正在观察真实系统行为。当我在做这的时候,我确定在调查代码时我不变得偏颇。如果我有问题,我问程序员,但我知道他们是偏颇的,所以我将避免自己偏颇!

     

    一旦我有了我的图(这里,思考,有趣的事务延迟和吞吐量相比负载)我跟开发团队会议并且讨论发现。通常,有一或两件事是他们所知并正在工作的,还有一些更多的是他们有时没意识到,他们查看我的基准并提出变更建议(你可以做到80:20比例,而不是50:50吗?)在这次会议后,我们创建了我们最终的基准,我修改性能测试脚本,然后现在这个基准就将尽可能经常地运行,但希望至少一晚一次。这里是这份努力最大的价值:如果有代码变更以一个不能接受的方式影响到性能,你将找出它在第二天。不是一星期或一月后(我们记得多少次我们上月做过什么?因此,为何期望我们的开发人员也要做到这点?)

     

    这里是为何我认为这是正确该做的:我已看过更糟的开发代码因为过早的性能优化――在团队面前甚至认为它们有问题!请不要这么做。开发你的服务以一种干净,可维护和可扩展方式。让我测试它,还要坚持回归测试它。如果我们发现在某一特定区域我们有一个问题,我们就能容易地解决这问题――因为我们的代码不是混淆的以性能优化,这已提升了每月一次代码路径执行5%

     

    我通常能做这在24星期,这取决于项目的复杂度。偶尔,我们将发现一个问题用性能测试不能被解释或被理解。在那个时间点,我们看向底层。这里涉及到了性能探测和性能模型。而且,它们两个相比性能测试更为复杂。伟大的工具应该被使用,只当容易的工具失败。

     

    工具,工具,工具但是,我们使用什么工具?我在Google伦敦测试大会上做过一次关于这的演讲。我使用开源工具。我在演讲中探讨了原因。一般,即使你已经决定选择其它二条路线(厂商工具或你自己的)中一个,检查什么可用。你可能找出你将得到大量关于你的服务使用JMeter的信息并花费一些时间摆弄它。当然,你也能花费50万元($)来获得相似的信息或者你花费2年开发“下个有史以来最佳性能测试工具”,但在你肯定免费的还不够好之前,为何你会要这样呢?

     

    结束语:监视你的服务在性能测试期间。如果你没有服务相关监视被开发和设定被使用在真的操作期间,你就不需要性能测试。如果你服务失败的风险不那么重要,你会知道它在它发生**,这样你就不必在性能测试上浪费时间或金钱。在这方面我难以置信地幸运――Google基础结构被开发由一群这样的人,如果他们有个关于主题“怎样使Goranka生活容易?”的会议,不能做的比他们更好。我喜欢他们――他们使我的工作琐细。最少,我监视CPU,内存和I/O使用率。我不能看见一个当你想要做少点事的案例,但偶尔你可想要做更多些。

    分享到:

    历史上的今天:

    移除FeedDemon广告 2009年10月09日