因果倒置了。
最初之所以有测试，其实就是因为你说的这种完美的情况无法普及。
如果真的这么好普及，测试也不会出现并发展成行业很重要的一环。

以前打 dota 的时候有一句话很经典：看了等于会了，玩了一把等于精通，赢了一把等于绝活。
好好的词，就被绝活哥们搞臭了。

这里只是举了一个简单场景，实际业务会远比登录复杂，所以在设计时进行了业务逻辑和数据处理的分层。

确实是习惯问题，这次属于暴雷了，哈哈。
帖子中的举例只是场景中的某一种，之所以要这么做，是因为想把对数据的定向修改放到统一的地方，这样在写业务逻辑时可以分层考虑问题，不会将逻辑处理和数据处理的代码混在一起。

不爽就走人呗。
不过如果真的没去一个地方都觉得主管不行，那也许可以看看是不是自己也有做的不好的地方，比如是不是想法太激进了？

加限制的话，其实也挺难的，6 个点就 800W 种排列了，100 个点加了限制局部也很容易就形成 6 个点 7 个点的情况。
而权重只会影响某个组合出现的概率，并不会影响总数。
如果是要做精准测试的代码函数流转关系的话，这个方式恐怕有点难，你想想 30 个类就已经这样的，正常的项目别说 30 个了，300 个类打底吧。

事实上我认为，这么大的数据，对正常的场景来说已经是没有意义的了。

按我之前回复的计算，5 个点 113400，4 个点 2520，3 个点 90，2 个点 6。这个数据，增长的太快了，别说 100 个了，30 个的数据就已经爆炸了。
你这个求的是排列，太多了，光是 start 立刻接 end 这种，都有 A100 的排列组合，还有 start 接 start，把所有 start 接完再处理 end 的也有 A100*A100。
不过通过上面的数据，发现一个规律，总点数每 +1，连线的总数就在前一个的基础上乘以 (总点数) * (2* 总点数-1)。
按照这个规律计算的话
6 个点的总点数是 7484400（事实上在回复的过程中我就在跑 6 个点的数据，跑完后的总数和预测相符）
30 个点的总连线是 7749523141180528462190498768559996393280264554881719828070400000000000000。
就瞅瞅吧。
好奇是什么具体场景。

只是某些利益相关的人口中被神话了吧，而老板通常更会被这部分人影响。
其实，很多人老早就看到了你说的这些问题，而有些人只看到了问题，有些人却早就在想怎么解决这些问题了。
我很赞同 Jerry 的观点，只看到缺点的话，视线会被影响，只有同时明确自动化的优点和缺点，做到心里有数才能因地制宜。
生活有很多不如意，如果只看到不如意，应该不会快乐吧。
工作也一样。

我来理解一下：我有 5 个类实例，每个实例都有两个属性：起始点和结束点。现在要求实例间的连线，要求每个实例的起始点要先用，才能用结束点。
连线用 1++ 来表示应该可以，然后只要求实例中的起始点小于结束点就可以。