为什么楼上的五年都这么优秀呜呜呜

超出我的认知了，留个言涨下知识

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

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

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

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

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

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

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

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

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

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

营业的兔兔最美～

催更催更催更

辛勤的兔纸又营业了～给兔纸打 call

但如果因为某些事，你给人是造假、延期、不靠谱等负面的标签，虽然明面上大家都会客客气气，也不会直接说，但是反映到工作中，就需要不断去做检查，时不时地过问下你的进度，还要检查你的交付物，会不会很累呢？你累，你的上级也累。这些标签一旦被打上，短期内很难消除。

非常认可。打工已经很不容易了，时不时还要去 check 下别人的进度我是真的会谢

说实话 点进来之前我以为是另一个接口测试工具的广告贴

TesterHome 十周年快乐！刚毕业的时候导师就给我推荐了这个论坛，到现在，每一年都有新的收获与成长。祝福大会越办越好，走出中国走向国际～也期待自己能有一天可以去到现场～Tester Forever 未来的每个十年我们都在

感觉楼主是一些学习思路上的问题，不一定转了开发就能找到方向。

刚好在测 SDK，感觉楼主有几处说到我的痛点了...

楼上说的很全面了，难的是怎么当好测试经理，如何让你手下的点工能够快乐打工。

我感觉...比如在浏览器输入 “XXX” 后点击确定跳转到一个搜索结果界面这个 case，这中间涉及的全部流程应该都要熟悉....虽然是功能用例设计，但你都写精通了，应该是要熟悉功能背后的技术实现的

看完感觉 “面试造火箭入职拧螺丝” 愈发形象了

我感觉已经出现的生产问题还是要复盘下，出现原因不同 应对措施也不一样。
举个例子，因为时间压缩导致有一半的测试点没有时间执行：测试前先确认好必须要过的主流程测试点，测试解阶段重点测核心场景。交付之前要拉齐多方对齐，说明哪些测试点没有测到，其可能造成的影响范围。暗示要么给多点时间，要么接受带问题上线。
如果产研坚持要上，我会在测试报告里一一列出这些风险点，也说明多方对齐的结论（产品要上的啊，出问题找他 ）及上线后的注意事项。

正如楼上所说，这整个流程问题都太多了，如果氛围很难改变就跑吧

iOS 端可以用自带的 developer，你在社区搜索下呗，我记得有人写过这种弱网测试的 wiki

前段时间看某个教程的中文版本，有一句操作的中文翻译很狗血，怎么想都不明白到底要干嘛，还原成英文后我瞬间茅塞顿开

英文：Create a file named Dockerfile in the same folder as the file package.json with the following contents.
翻译：使用以下内容在与 Dockerfile 该文件相同的文件夹中创建一个文件。package.json