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

赞一个！思路学习了

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

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

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

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

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

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

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

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

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

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

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

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

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