从我毕业第一年开始，我就始终在思考一个问题：为什么我值这些钱？
希望你也思考一下。

AI 写用例这一套目前有很大的问题：

1. 上下文理解问题。单纯一篇 PRD，一些内部共识的信息很大概率会在脑子里自动补全而不体现在文档中，这部分不告诉 AI 就会生成的很差，轻则用例缺漏，重者驴唇不对马嘴。尝试过接入历史需求、历史用例和历史缺陷，但是又碰到信息过时、场景描述上的省略等等问题，花了很多时间去学习 RAG 相关的知识，然后又花了很多时间去优化，最终效果都很差，反而小伙伴怨声载道。从最开始的积极配合到疑虑重重再到最后消极怠工。
2. 二次评审问题。既然 AI 一次性生成的效果总是难以做到非常好，那我们后面暂行了一个评审 AI 用例的流程。现在事后看来，效果也很差。阅读 AI 写的用例，总会有一种坐副驾驶位上的昏睡感，会导致自己看 AI 生成的用例时难以投入，一些细节错误没发现、该增加的用例没评审到等等问题。甚至本来还算顺畅的用例评审都遭到了各个开发的投诉，说的结结巴巴，甚至要临时调整，完全没有评审自己写的用例时流畅。
3. 维护问题。这个问题我们没有实际经历过，但是在做的时候就有预想。每个迭代都会产生新的历史需求、历史用例、历史缺陷，而这三者的处理逻辑各不相同，尝试过完全让 GPT3.5 去按照预设逻辑处理，但是效果并不好，完全能用的数据只有 30% 左右（可能还高估了），剩下的都要人工处理，即便是人工处理也不能完全保证可用性。而用 GPT4 处理，效果会好很多，但是成本也没办法承受。

上面这些问题，或许交由更专业、更专心的团队去处理，还有机会处理好，但是内中的细节问题、效果问题上应该还会有一大堆又一大堆要进行处理。
在做之前，我其实也已经跟领导说过这些问题了，但是一句试一试吧，让我没办法反驳。只能当做一次技术上的实践去做了。

小米的同学都喜欢说话直截了当，不喜欢去绕弯子，讨厌卖关子吗？

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

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

不确定我们做的算不算。
目前有一套检测增量代码系统，可以检测到两个 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。这个方法亲测是可用的，只是理论上应该只需要第一个参数就可以，但是在实际使用过程中会报另外一个错误，所以其他两个参数也一并写上。