以下是我的理解：

• 首先评估下第三方接口性能有问题对你们有没有影响，毛影响没有就别管了。
• 都收费的第三方接口了，找他们给个性能参数不就行啦，你花钱了你就是大爷。
• 线上监控看下这个接口实际性能表现，预估下是否符合他们给的性能指标，是否满足你们业务发展的需要
• 按第三方性能参数，设置 mock，先把自己系统性能瓶颈摸清
• 如果第三方的性能指标线上观察后不符合你们的预期，找他们谈撒

最好的办法还是线上观察后预估，然后和第三方接口做沟通，第三方接口的性能本来是他们要保证的，你是被服务方。

你做大保健的时候指明点个技术最好的，难道还特么要花钱把整个店的技师包了一个个试么。。。

那就看多有限了。
首先你得没技术债，回归关联功能得自动化。
其次，你最好开发并行的做甚至比他们提前弄好（比如 TDD）。做好了你再根据需求设计执行写自动化测试，测试周期确实可能拖得很长。
最后，找个熟手，啥业务都不懂的人谈不上效率。

仅仅是 UI 的话，没啥建议，我做的不多。。。如果已经进行分层自动化测试了，UI 搞起来应该不难，这么规范的测试，一般没有易测性这种技术债的。

标题党啊。。。人类计算能力早就被计算机击败了。现在只是把计算机换成了 AI

不建议，并不是一条相对好的出路。建议考公务员，稳定可靠，就是有时候身心都会很累，心大点不求上进就好。工资虽然不高，但是体制内是有光环效应的。

一般这种我觉得人比较好使。我还能听出他是不是有问题。

2、4 熟悉相应的算法这个 “业务”，任何一个合格测试都能干。但是进行具体数据收集和处理，还是得了解开发以及产品的想法才行。

“作为一家科技公司，我们意识到不能是某专家解决问题的模式，而是希望在不断经营的过程中有积累、有传承，能够让更多的经验在平台上进行沉淀，赋能更多的产品”。学习了~有所触动

对进度敏感的都这样~顶多能缓解~有时候无法避免。比如当晚必须要你修复个漏洞啥的

业务逻辑再爆炸也得测的，莫得法

自动化测试还要强调 UAT 么？老实说，我认为功能级别的自动化测试和 UAT 没两样

测试环境搭建不是和你被测对象相关么。。。测网站功能的，弄个可以跑功能的网站就行了啊。至于各种配置这些，每个项目都不一样。部个一两次就会了，前几次找开发教你或者你直接负责项目的配置管理，包你啥都知道。

排之前先问下啥时候上？开发靠谱不？需求明确不？用的技术成熟不？你业务熟不？要求的质量高不？环境稳定不？中间有其他糟心事不？开发可以迭代提测不？可以做 TDD 或者相对并行的测试不？如果都有问题，并且要在第 16 天后上线，开发 15 天后才提测，你趁这 15 天空了去找其他工作吧。

测试设计就那些基本的方法，其他就看你业务了解程度了。

业界领先的测试方法和技术...外行人的说法而已。十年前的测试方法和技术，拿到现在也落伍不了多少。

赞一个！思路学习了

预期相似度太玄学了。另外文本相似度和语义相似度是两码事，除非结合起来我觉得才有点搞头。文本的测试上弄统计学，我始终觉得有点虚。测试不就是看那不相似的么。。。

1.整个团队为产品质量负责，而不仅仅是测试
2.测试顶多能决策这个产品具备达到上线的质量要求，上不上是需要看整体安排、用户需求、业务规划的。测试能决定上，就说明产品没啥整体规划，或者对这些不敏感，能上就无脑上了。
3.如果需求上明确指出哪个色号，间隔几个像素，粗细几个像素，测试能不测？
4.说实话，项目里角色其实并不完全是泾渭分明的，你强你可以多管管，能力不行就多学。围绕 “整个团队为产品质量负责”，问题都是能解决的。从出发点就开始分锅，最后的解决大多不欢而散。

能当讲师而且能忽悠到人的，哪个行业的前途都不差。

搞安全啊 有这么好条件。测试到最后，还是你排斥的那些玩意儿，起点低而已。我是你我就从高门槛的开始搞

业务划分好，日志梳理清楚就 ok。

领域门槛高的，多提升业务。领域门槛低的，多提升技术。啥都不行的，提升下做人。还是不行的话，降低下自己对生活的期望。。。

举的几个例子
1.codereview 和测试都应该可以找出来
2.说段子呢。。
3.产品、测试、运维都有责任，运维责任更大。

总的来说，线上出了问题，没有哪个能完全脱离干系。SB 公司才会找单独的背锅侠。加班那个段子成功逗笑了我

用的技术都是时下流行，得到的结果经常千奇百怪。

没测过多少支付，我一般看两块。支付接口本身有没有问题，比如对各类金额、超大金额、转码金额等，限制能不能绕过，接口用的技术本身有没有问题，比如 XML 类，有没有 XXE 等。另外就是支付功能，能不能改价格，能不能绕过一些验证，并发支付、多次支付、回退支付、支付撤销等等。支付测试我反正比较头疼，风险大，网上大神多，出点问题估计就要被开。。。