尴尬了，补齐了基础知识的盲区

好的，多谢大佬

嗯，在 200 的用户的时候已经到达瓶颈了。 我的意思是继续增加并发用户数，看到压力机的网络上传速度没有增加。
我理解压力机的加压跟服务端的能力是无关的，继续加压应该会出现发送流量一直上涨。

比如下图里面，300 用户的时候，流量几乎没怎么动。 电脑管家的流量监控显示的上传流量也跟 200 的时候差不多。

def my_function(n):
    if n==1:
        return 1
    result = my_function(n-1)*n*(2*n-1)
    return result

用递归计算了下组合数，计算结果跟你的没对上。

噗~~，看来我算错了，算了 11w+。

不过，理论上我觉得穷举所有组合其实不太可能。 等到你有 30 个节点以后，不得跑个好几年。 你做这个事情的具体业务场景是啥？

@ 杨漫步 5 个节点的时候，有多少种组合？ 我验证下自己的计算结果

感觉有点类似括号嵌套的问题

流程性、依赖性的自动测试需要 MBT 来配合实施，也就是业务流程建模，你可以简单的理解为把每个功能点作为一个节点，流程用有向图连起来，构造、画图用 proxy 挂 mock-server 录制就可以实现基本的画图了，后续根据实际业务稍加修改就行，然后每个节点做一下业务功能标注和描述，推荐使用 canvas/svg，之前一个小伙伴用 graghviz，卡在图的编辑上很久，而且也比较重了；

这个把业务点用有向图串联起来，现在运维的基础设施上了 skywalking 以后，就感觉很好做了，直接把数据迁移或者爬取下来就可以，而且调用链路非常清晰。

还有只是反推到接口级别的，通过 ASM 分析（通俗点说，有点类似于平时 idea 里的 find usage 倒推调用位置，一直倒推到 controller 层）+ 运行时数据采集（比如通过反射来调用的，就只能用这种了），反推某次代码改动影响到哪些接口，然后执行这些接口相关的接口测试用例。客户端类型的话把接口改为界面（activity/fragment/view/url），也可以同理推断

非常赞同上面这个思路，我们现在的精准测试就正准备尝试这种方法。

之前去 QEcon 大会，有个工商银行的分享。提出了两个思路，一个是按照时间段，另外一个是用例打标（这个不懂怎么实现），感觉可操作性性都不强。

旁边的人就是最好的老师，开会的时候，尝试做个会议纪要，然后没事的时候拿出来复盘下，从别人的结论中反推考虑问题的思路。