在开发性能测试脚本之前，您需要能够巧妙地使用性能测试工具，或者它不是工具本身。最好编写代码；
毕竟，设计合理的性能测试脚本是性能测试的良好开始。
分析系统的特征用于各种HTTP协议的接口性能测试。如果您遇到其他协议：Dubbo，Soap，MQ，等。
1.1，Jforum论坛1.2，服务体系结构
易于通过录制来生成脚本，然后改进它；方案：Badboy+Jmeter，Jmeter自己的录音元素以生成脚本。
2.1，已经给出了脚本记录过程（略）方案，只需转到实际的战斗操作。最终音调生成的脚本结构如下：
2.2。为了在这里改进脚本，您需要做什么才能改善脚本？
2.3。参数化这是增强脚本的重要方法之一。关联处理也是参数化的一种方法。
回到这里，脚本已经开发。在这里，您需要提出一个建议，也就是说，所有脚本都是根据最低单位的业务场景开发的，以确保其独立性和无缝组合。
3.1。独立脚本不称为独立场景，因为独立脚本不受其他可以执行性能测试作为业务场景的脚本的影响。
那么，我们应该如何处理独立脚本？还记得在性能测试中是否对性能指标进行任何分析？否则，绩效测试的基础和意义又如何呢？
假设以下数据是通过业务日志监视或系统监视获得的：
tps13.755.58.2527.5实际上是根据场景设置的。登录不需要是一个独立的脚本，因为我们不做登录的性能测试，或者在此场景中没有发生性能问题。
如下所示：我们需要发布（支持系统中的匿名帖子），并且需要登录答复。然后，将登录和这两个操作组合到独立脚本中，因此浏览是一个独立的脚本。
注意：所有脚本的最小交易是HTTP采样器样本本身，它可以通过交易控制器包括多个操作。
3.2。组合场景通过了先前的数据分析。不可避免的性能测试场景是交叉的，也就是说，不可能在同一时间发布，答复等。一定是有人在发布和答复。
现在已经知道了比例数据，脚本开发完成后，您需要设计脚本：不要将所有业务放在同一线程组中。毕竟，业务很复杂。
它不能按比例准确地分布。建议它基于业务独立线程组，以便维护良好，第二个也是一个很好的扩展。最重要的是，它不会影响执行顺序。
3.3。场景设计不是组合脚本。
为了准确找到性能拐点，系统压力必须持续一段时间。然后，这次，您可以从系统监视中看到峰值谷，以及当您开始缓慢减少这段时间时。
注意：螺纹数量仅限于优先级的优先级小于持续时间，即持续时间为0时，它会受到升级时间（sec）的约束。它在几秒钟内结束，线程停止。
场景设计不仅仅是设计脚本和组合场景，而是符合用户行为习惯并模拟真实的生产业务行为。
绩效测试的准备包括：环境构建，结构数据，脚本开发
在进行性能测试之前，应该进行合理的场景设计，以准确定位性能的瓶颈。
在执行性能测试中，一个是观察脚本操作，第二个是监视系统资源
最终的性能结果分析是通过正在进行的监视平台进一步分析，最后通过监视平台