第三部分说的很在理。我也遇到很多问题解决方案都是临时性的，不能长期落地，一碰就碎。思考问题不能太表面，要关注真正的目标。

楼上说的挺对的，公司招你主要是解决问题，如果只会执行可能比较难被选中。我的建议是你投简历期间可以梳理下自己做功能测试的心得，遇到的问题及解决方案，可能对你面试会有帮助。
比如：你发现组内测试用例不需要经过评审，直接测试 -- 然后你推动组内落地了用例评审流程，保证了用例的质量【一个简单的例子，类似这样】

目前做法
新接口测试：基本都是通过手动调接口，手动传参数，不会用太多枚举，基本就业务主流程
旧接口回归：一条用例能通就行，不验证业务逻辑，code=正常就行

现在更多是结合客户端测试为主，接口测试为辅。

挺好的。等哪天测 WEB 项目了实践下。

很实用，特别是那个时序图的，再也不用等着开发给图了

可以通过 text 去定位么 text=估值

刚好最近在用 MS 写接口自动化用例，再次复习一遍了～

有些比较基础的方法感觉是可以结合常规需求做的，慢慢去培养自己的安全思维，由小及大，码住。

对于已知的问题，找开发确认下前因后果，做下缺陷分析。如果是测试场景遗漏，补充对应的用例库。如果是固定机型问题，可以一个季度/半年去找三方做下比较全面的兼容测试。

营业的兔兔最美～