让loadrunner走下神坛[1]

  无疑是一个强大有力的压力测试工具。它的脚本可以录制生成，自动关联；测试场景可以面向指标，多方监控；测试结果图表显示，拆分组合。相信有人这样想象过：拿着一张性能指标标准列表和测试数据相比较，如同PH试纸一样，遇碱则蓝，遇酸则红，一目了然，之后就可以大声地喊道：我找到了软件系统的性能瓶颈！

   然而，我们无论在loadrunner前面加多少个"强大"、"智能"的形容词，别忘了其最终修饰的只是一个名词－"工具"。《大话西游》中也有相当精辟的论断：官兵？最多也只是个长了痔疮的官兵！把loadrunner比喻成长了痔疮的官兵有点粗俗，但loadrunner它是个工具，那么是否能够找到性能瓶颈就取决于使用工具的人，而不是工具本身。要做一个成功的性能测试，仅读懂和精通了loadrunner的使用手册是不够的，还需要对被测软件系统的方方面面都要有了解，比如软件体系构架，网络拓扑等知识。这就如同一个技艺高超的木匠，并不是因为他背熟了凿子，锤子的说明书，而是他能结合木材的质地和尺寸，用凿子和锤子这些工具做出一把精巧的椅子来。那么在性能测试中，人的智慧活动体现在哪里呢？

    一、首先性能测试也是测试的一种，这就意味着做性能测试也要写测试案例。你所作的性能测试能不能足以支持找出性能测试瓶颈，和你在初期设计的测试案例关系甚为重要。我曾写过对一个软件系统的不下十个性能测试场景案例，等后来运行时却发现我必须增补几个案例才能找到瓶颈，而原来十多个案例其实重复甚多。如果你要写出好的不重复的性能测试案例来，你就得对被测软件系统有一定的了解。

   在这里，我顺便插一句，在目前测试界总在争论测试人员需不需要懂编程，需不需要有开发经验这种问题，这完全是本末倒置，忘记了测试人员的目标是什么，测试目标就是写出好的测试案例，好的测试案例就是发现了一个原来未曾发现的软件bug。那么一个测试人员知识体系是否够用的标准就是能不能写出一个好的测试案例。而针对不同类型的测试，所需的知识深度是不一样的，有的是不需编程知识，比如界面测试；有的是必须有开发经验的，比如接口测试，不能一概而论。