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

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

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

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

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

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

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

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

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

赞一个！思路学习了

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

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

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

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

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

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

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

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

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

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

没 Metasploit、软件测试基础、当前主要编程语言及项目使用框架么？

技术搞不了，只能去搞服务了。。。

脚本没必要，基础框架得要。自动化用例一般也就业务耦合，框架把常见业务提取出来就行。设计模式主要是让自动化测试易于维护，比如改个东西啥的，好改你的脚本。要是做了永远都不变，引不引入设计模式，说实话好像也没有那么必要。