1.宝路说
宝路最近一直在自我思考：性能基准DevOps工作已经开展一段时间了，目前我们确实已经取得了一些成果，显然这还远远不够。趁闲暇之余跟组员进行了简单的头脑风暴！于是这就有了今天的主题，当然这仅是主题之一，后面会继续分享其他主题。
2.背景说明
随着测试环境DevOps工作的不断开展，业务场景覆盖率不断扩增，涉及的接口数量也是成倍的增长，据统计目前接口数量已近两百。
在实施过程中，我们愈发明显的发现，执行一次全场景耗时明显增长，脚本执行时间越长出现不稳定因素的几率就越大，严重可能导致邮件报告可信度降低，如何提升脚本执行效率成了目前需要重点解决的问题。
3.现状分析
在组员电脑上用JMeter的GUI模式打开脚本一看，吓一跳，只见N多个事务控制，密密麻麻的！都用上鼠标滚轮了。。。
脚本结构如图：
后面还有N多个场景未列出来，从图明显可以看出，随着业务场景的增加，脚本肯定执行时间越长。
如置之不理，久而久之，情况只会越来越糟糕。
4.头脑风暴
就如何提升脚本执行效率，我们也是*发言的讨论，讨论可行方案如下：
方案一：将目前脚本进行拆解，形成多个压测脚本
该方案确实可行，但无疑付出的时间成本太高，就简单的拆解脚本来说工作量确实不大。拆解成多脚本（多测试计划）运行，也就意味着会产出多个测试报告。目前平台还不具备多报告合并功能，还要重新开发。
不合并多个报告，那么无疑在邮件通知报告中要增加多个动态报告链接 方便收件人查看更详细的报告数据（聚合数据、吞吐量曲线）等，三四个连接我还能忍受。。。一下放那么多报告链接，谁还有心情去点呢。。。
有的同学可能会想想到，放几个重点报告链接不就行了么。此方式确实可行，但还不能满足我们目前的要求，重点业务场景也很多，我们最终还是想让相关人员全方位的看到接口实时性能情况。
显然此方案不是最优解。
方案二：将目前脚本进行“拆解”，多线程组模式
此方案是在方案一的基础上进行在调整，将原始的单一线程组改成多线程组模式。这样扔保持一个测试计划，也就是说最终扔是一个报告。
脚本结构如图：
我们目前在做基准测试场景，是单线程组单线线程执行。脚本按多线程组改造后将成倍缩短场景执行时间。
举个简单的例子：起初一个包工头指派一个工人去完成某个项目工程，但是这种工作模式显然效率不高，于是又指派好几个工人同时加入到项目工程中同时还依照工人技能不同对工作进行了分工。
那么问题来了，线程组该怎么进行分工呢？我们目前的解决方案：业务场景+测试数据 组合分工模式。按业务场景来分，这个大家都还可以理解，怎么还来个按测试数据分，这是？
归根结底还是业务场景的“锅”，有些场景那就是需要特殊用户数据才能正常执行。进而我们决定采用业务场景+测试数据 组合分工模式。
5.其他建议
关于压测脚本，还是再多啰嗦几句：
- 脚本结构不要搞的太复杂。
- 要求高性能的话，尽量少用前置、后置处理器，如果必须要用的话里面的代码不搞的很复杂。
- 请求报文涉及到加解密，最优解还是定制开发Sampler采样器，这样测试人员不用花更多的时间去关注加解密代码及相关流程，测试人员编写脚本仅需填写服务器地址相关信息、请求明文，这样编写脚本效率也会质的提升。