对你自己的压力测试工具进行压力测试是一件非常有挑战性的事情，正如我的同事Aviad Diamant在他最近的一则帖子中指出的，这就像是“喝自己的香槟”（即用自己的产品测试自己的产品，如用自己的矛测试自己的盾）。虽然Aviad说的是功能测试，性能测试具有同样的挑战。比如，需要有各种各样的被测应用（Application
Under Test，简称AUT），这样你的程序才能测试它所有的功能。或者，需要招聘测试方面的专业人员，并且对你们使用的技术要了如指掌。一个例子是，对压力测试工具进行监控，可能影响它产生报表的速度。压力测试是一个耗时的过程，对压力测试工具自己进行压力测试，在某些情况下，需要消耗对其他应用进行压力测试的双倍的时间。
在这则帖子中，我会在Aviad的文章的基础上提供更多的见解，这些见解主要针对的是压力测试工程师以及压力测试工具（译者注：Aviad谈的是功能测试）。我会同时提供一个例子。
对StormRunner
Load进行性能测试（译者注：StormRunner Load本身是一个网络版的压力测试工具）
我们使用StormRunner Load，我们的基于云的压力测试工具，来测试它自己。我们发现这样做有几点好处。
· 我们可以把回馈及时给到这个工具的开发者，帮助提高产品的质量，减少后期的维护成本。
· 作为一个用户，我们可以快速发现哪些功能缺失，并且提供新的想法。
· StormRunner
Load提供了非常直观的图形界面，让你实时地设置基准线或者分析运行结果。许多老旧的工具都没有这个功能。
· 这同时证明了这个产品是可以工作的，因为我们自己就在使用它。
StormRunner
Load允许我们从任何地方访问和测试它，它主要用于云测试。在我们的案例中，由于我们的网络不能从公共云中访问并且我们要用StormRunner Load测试它自己，我们搭建了一个室内的类云环境作为我们的测试平台，我把这个室内的类云环境称作SR（即测试者）。我们在另外一个分开的内部云中部署了完整的StormRunner Load，我们把它叫做SR-AUT（即被测试者）。
通过这样的测试，我们可以既独立又完整地观察各个组件。SR测试SR-AUT。（译者注：在这个测试环境中，SR的表现代表了StormRunner Load的功能，SR-AUT的表现代表了StormRunner
Load的性能）。
我们采取了下列步骤：
1. 在SR-AUT中创建一个测试，使用预先写好的测试脚本。
2. 使用Web HTTP，创建HTTP请求/调用，用TruClient (UI),在后台启动一个浏览器。
3. 配置监控器。
4. 运行测试。
5. 实时分析结果，或在运行完毕后分析结果。
我们学到了什么
最大的挑战在于如何处理一个工具，它会在运行时像产卵一样动态地创建很多工具（译者注：指StormRunner Load动态创建LG。这正是StormRunner
Load的一大优势，即用户不需要自己部署和维护LG，极大地降低了使用成本）。我们在室内的类云环境（即SR）中创建了一些静态的LG组件，解决了这个问题。SR-AUT连接到外部的云供应商正常使用。
随着这个项目的进行，越来越多的测试流程被自动化了。今天，即使最简单最通用的测试也在每晚的编译之后运行一次。在每一次发布之前，针对新特性执行一次回归测试。在这个过程中，自动化测试脚本也做过调整添加到每晚的测试中。测试的结果越是自动化，我们对测试结果越有信心，那就意味着一个越好的产品会发布到市场上。
现在就开始试用StormRunner Load对你的应用进行压力测试吧！
原文作者为Aviran Harom，原文位置：https://www.linkedin.com/pulse/load-testing-your-own-toolthe-adventure-continues-aviran-harom?trk=prof-post
