可以转化拿下 ascii 码看看三个字符的顺序，ASCII 码的比对是依次进行的，最小的前缀必然是所有用例共有的，只是在某个点位的字符小于其他用例的该点位字符，在循环获取到该位置后即可进行截取了

我在功能测试岗位的时候，还兼着性能测试的工作内容

真是辛苦你啦

是吗？我当时换了个问题就是 ok 的，再问下这个问题就又 429 了

大佬了解大模型测试的情况吗，可以开篇普及下
gpt 了下直接

全部 短暂来看是不可能的事，除非真进化到了红皇后的程度

重点是结果的判断，现在很多测试平台都支持自动化用例的自动生成，在这个基础上再拓展下，能否通过训练来打造出一个拥有 测试场景判断、用例设计和执行、断言判断、自动化转换等思想的 AI，只要求达到普遍测试场景的能力即可，这就可以让大部分的测试退休了

得物预备队在此，这就拿这 bug 去应聘

楼上各位大佬一看就不审题，只是测试工程师生涯重新开始，不是人生 重新开始
ps：我选择在 19 年的冬天去举报某海鲜市场存在生化武器

人才市场？脆皮烤肠？菜煎饼？肉夹馍？儿童辅食？卖袜子？卖屁股？种地？中介？

不建议使用模拟器，有很多问题是真机不会出现的，测试结果存疑

如果重新开始...
也许我会留在一线，而不是为房价退缩
也许我会更早的开始学习，而不是因为舒适停步
也许我会有更好的选择，而不是现在的茫茫不知前路
也许我能找到无数的更优点，但我还是会选择为家妥协
如果重新开始，也许我最终还是会走到现在
这也没有什么不好的不是吗

感觉 #9 的分析是对的
当并发压力升高时，TPS 反而下降，但响应时间仍然很低
响应时间很低 代表软件性能仍在允许范围内，未达到瓶颈点
TPS 下降 代表在软件性能可上升的情况下处理事务数却在下降，只可能是因为进入的事务数降低引起的，也就请求数
但是首端的 “并发压力在升高”，尾端的请求数却在降低，工具监控的在线线程也是 OK 的，
应该就是中间件的问题导致的，也就是负载机的问题

你可以先不去想，而是去试一试，在老家的二线城市应聘找找（大部分回归人的选择），看一看薪资差距与归属感在你心中哪个更重就完了

永远记住：
工作只是工作

加班不给批啊

我们公司不知道这个节日

当你可以实现以后再去想慢的问题

你这才是真正吃到红利的大佬啊

欠的越多越是大佬啊

感觉下面这个帖子说的一些内容挺符合自动化的编写要求的，可以参考下
https://testerhome.com/topics/37703

安全测试中，验证篡改请求的 https 请求通常涉及以下几个步骤：
1.验证证书的合法性：HTTPS 使用 SSL/TLS 协议来加密通信，确保数据传输的安全性。在建立连接时，服务器会发送证书给客户端，证书包含了服务器的公钥和其他相关信息。客户端需要验证证书的合法性，包括检查证书的有效期、颁发机构的可信度等。如果证书验证失败，可能意味着请求被篡改。
2.使用数字签名验证篡改：证书中的公钥用于加密会话密钥，确保数据传输的机密性。同时，证书也使用颁发机构的私钥进行数字签名，以确保证书的完整性和真实性。客户端可以使用颁发机构的公钥来验证数字签名，确保证书没有被篡改。如果数字签名验证失败，可能意味着请求被篡改。
3.使用哈希函数验证篡改：在传输过程中，如果请求被篡改，可能会导致请求的内容发生变化。为了验证请求的完整性，可以使用哈希函数对请求的内容进行计算，并将计算结果和请求中的哈希值进行比较。如果两者不一致，可能意味着请求被篡改。
4.使用完整性保护机制：除了上述验证方法外，HTTPS 还提供了一些完整性保护机制，如消息认证码 (MAC) 和加密哈希函数 (HMAC)。这些机制可以在传输过程中添加额外的校验和，确保请求的完整性和真实性。

100 多个我自己上班的怎么破

不知 ChatGPT 在这方面的具体使用方式是否方便分享下

同样是编写测试用例方面的探索