许愿

背景与闯祸实习期间承接需求时，我发现很多系统的业务逻辑盘根错节，上下文关联极深。有时需求本身涉及的代码改动明明很简单，可要是不把背后的业务脉络和代码逻辑摸透，就根本没法理解修改的初衷。最开始我接手需求，往往只盯着技术需求文档（TRD）里的修改要求，照着文档改完代码、做完自测，就觉得万事大吉了。到了代码评审环节，大家都要逐一讲解自己负责的需求和对应的代码改动。我负责的部分改动点很简单，无非是删几行冗余代码、调整一点参数配置，所以准备得很仓促，没多琢磨背后的逻辑。评审时，同事们针对这些修改提出了不少问题，比如 “为什么要删掉这段代码？会不会影响下游接口的调用？”“这里的参数调整有没有考虑到历史数据...

各位佬，帮忙看看是不是简历有问题？简历有没有需要修改的地方

得物测开一面面经，摘自优秀牛油面试时间：24/10/19面试时长：30 min1. 自我介绍； 2. 为什么找测试岗位； 3. 讲一下测试的一般流程； 4. 设计测试用例的常用方法； 5. 如果需要测试一个接口，去测试一个并发场景，应该如何去做； 6. 如何去设置多线程； 7. 10万级别的接口访问量，如何去模拟； 8. 数据库了解如何； 9. 2000万中有2万条数据是热数据，需要经常使用的，如何实现； 10. socket 和 http 的区别； 11. 现场直播或者打游戏，在线视频，使用 http 还是 socket； 12. 如果你负责一个项目，需要多个团队或者业务组合作，作为项目负责...