第三部分说的很在理。我也遇到很多问题解决方案都是临时性的,不能长期落地,一碰就碎。思考问题不能太表面,要关注真正的目标。
楼上说的挺对的,公司招你主要是解决问题,如果只会执行可能比较难被选中。我的建议是你投简历期间可以梳理下自己做功能测试的心得,遇到的问题及解决方案,可能对你面试会有帮助。
比如:你发现组内测试用例不需要经过评审,直接测试 -- 然后你推动组内落地了用例评审流程,保证了用例的质量【一个简单的例子,类似这样】
目前做法
新接口测试:基本都是通过手动调接口,手动传参数,不会用太多枚举,基本就业务主流程
旧接口回归:一条用例能通就行,不验证业务逻辑,code=正常就行
现在更多是结合客户端测试为主,接口测试为辅。
挺好的。等哪天测 WEB 项目了实践下。
很实用,特别是那个时序图的,再也不用等着开发给图了
可以通过 text 去定位么 text=估值
刚好最近在用 MS 写接口自动化用例,再次复习一遍了~
有些比较基础的方法感觉是可以结合常规需求做的,慢慢去培养自己的安全思维,由小及大,码住。
对于已知的问题,找开发确认下前因后果,做下缺陷分析。如果是测试场景遗漏,补充对应的用例库。如果是固定机型问题,可以一个季度/半年去找三方做下比较全面的兼容测试。
营业的兔兔最美~