直接生成用例效果会不好，但是帮你检查用例效果可以很好

不懂代码的这批人，日子已经很难过了，他们中的绝大部分也不在这个社区里，还要被人这样嘲讽。
发这个帖子有什么现实意义呢？

不确定我们做的算不算。
目前有一套检测增量代码系统，可以检测到两个 commit 之间的差值，进而找到对应影响的接口。
拿到这批接口后，我们会重跑 jvm-sandbox-repeater 录制到的接口请求。
目前这套已经接到持续集成中了，每次开发部署代码之后都会和线上版本进行对比，跑一遍涉及到的旧接口。
但是局限性还是比较大，只能说有点帮助，但是不多。

今年是过去十年来最难的一年，今年也是未来十年里最好的一年。
来，干了这碗毒鸡汤。

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

以前打 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++ 来表示应该可以，然后只要求实例中的起始点小于结束点就可以。

老哥，你工资少了吗？

class Solution(object):
    def __init__(self, this_str: str):
        self.this_str = this_str

    def unzip(self):
        return_str = ''
        cal_str = ''
        while len(self.this_str) > 0:
            cur_word = self.this_str[0]
            self.this_str = self.this_str[1:]
            # 如果是字母
            if 90 >= ord(cur_word) >= 65 or 122 >= ord(cur_word) >= 97:
                return_str += cur_word
            # 如果是[则进入递归，返回后防止同层级有多个压缩，需要重置倍率值
            elif ord(cur_word) == 91:
                z = self.unzip()
                return_str += int(cal_str)*z
                cal_str = ''
            # 如果是]则返回中括号内的内容
            elif ord(cur_word) == 93:
                return return_str
            # 如果是数字，则存入计算字符串中
            elif 57 >= ord(cur_word) >= 48:
                cal_str += cur_word

        return return_str

路本来就是自己走的。
没有写过这些半吊子的平台、自动化，就不会意识到自己有多差。
意识到自己还需努力后，继续写，发现写了的东西技术都还可以了，但是没办法解决实际问题，就会意识到需要回归测试的本质。
所以我不觉得社区里各种半途而废、半吊子的平台有什么问题。
你作为一个站在山上的人，看这些还在爬山的人，看他们半途而废，路径不对，希望在你走过的或者其他山上的人走过的路上插上旗，贴上标语进行引导，大体上没错。但是真当所有人都按前人的经验行走时，新的路，更高的路谁来探索呢？

似乎大部分人都没看懂楼主要表达什么？凡测试平台一定是烂的、一定要嘲讽这种观点；凡测试平台一定是脱离了测试本质的这种观点那确实是反智的。
让我想起了上周看的觉醒年代，新文化到来时，总有一股守旧的势力会进行反抗。这种观点或许就是守旧势力们压抑太久进行的阶段性爆发，我不觉得社区的形成了这样的风潮。

经过过滤层（也就是堡垒机）转发请求的情况，通常是考虑到系统安全性问题。具体的操作需要你咨询一下公司做转发时的策略。有些限制的不是很死的策略，你可以直接请求堡垒机发送的真实请求数据，只是中间要经过一些转换，有些转换写的很复杂也不好做接口测试；有些限制的比较死，做了白名单策略的话，你可以问一下能否将请求代码部署到堡垒机中运行。

这是跳槽了？

我在进行远程 WebDriver 服务部署时碰到过这个问题。按照字面意思理解就是计算机图形库不可用。
出现的原因是因为在启动 WedDriver 时，未带上允许使用 GL 库的参数，而你使用 WebDriver 的方式又不是 headless 的方式，所以会报这个错误。
解决的办法有两个，一个是启动参数带上 --headless，这个方法我自己没有使用，只是推测的。
另一个是启动参数中带上 -enable-webgl --no-sandbox --disable-dev-shm-usage。这个方法亲测是可用的，只是理论上应该只需要第一个参数就可以，但是在实际使用过程中会报另外一个错误，所以其他两个参数也一并写上。

让开发配合做 deeplink，通过不同的 url 可以跳转到不同的页面。

正常面试不是应该问对方会什么，然后往别人会的地方深挖。
能挖多少就看面试官的本事了。

这是有 BUG 吧，我没有给这个帖子回复，却已经给我推了三次消息提醒了。