@fishfish-yu 我是社区的徐士钊，老师能留人微信嘛

测试环境是否独享资源，建议先和团队成员以及运维同学确认一下吧

我们基本和你这个一样，测试环境就是走 mock 或者沙盒测试，正式环境会针对特定测试账号生成一个支付订单，只要有支付链接回调，就默认接口没问题。
但是每次发版后，我们会使用这个账号进行一次真实订单支付，验证一次支付流程

每个公司不同阶段诉求不同，公司业务所需技术也不同，我理解没办法一概而论
现在外面都在抄一个概念，市场不景气呀，行业不景气呀，都在裁员，掌握了各种 各样技术就不会被裁之类的
但在公司中，就会发现，裁员和具备什么技术不能说毫无关联，只能说只有一丁丁关系
主要还是看的公司业务形态，对于现有团队规模的调整方式，以及测试团队在部门中的占比。

比如：
1、部门要求整体裁员 15%，人数一平均，各个团队分一分，有需要换新血的就借这个机会换一波，当然在测试人员本身就不够的情况下，是有可能不对测试进行裁员的
2、业务稳定，没有过多测试任务，公司确实会倾向于保留有自动化能力的同学
3、业务不稳定，资源严重不够，公司更愿意保留更熟悉业务的同学
4、在无法平衡的情况下，更愿意保留，平时在团队中担事，解决问题的同学

除了废开发外，就全剩收益了呀，定位方便，跟踪方便~

社区版会一直免费

公司内部搭建测试环境无线网络，访问不同的 wifi 调用不同测试环境

这是一个 bug，还没有进行修复，审核功能当时候特别急，不是很完善，已记录，后续版本修复掉

近两天频繁出现此类问题，正在排查中....,
昨日社区频繁被攻击中，还在解决中，太难了....

组织长期技术提升培训，把开发用起来，把他们当成培训老师~~

建议跟着研发体系走，掌握和研发同类型语言，双方会有更多的沟通以及深度认可的机会

可以向测试架构师方向发展，但技术经验要求相对高一些，最少要对研发体系、研发框架、以及具体业务有一定的了解。
也可以转型到研发团队，现在很多都在说效能，但未来效能大部分应该也是研发在做了，测试在这里的作用应该会转变成需求方了。

看向哪个方向深入了，一般我们会分成业务、技术深度
1、业务深度
足够了解业务需求，在产品需求阶段，能够推进产品经理对于功能设计的完善，不合理以及挂件类功能，提前劝退
当产生功能歧义时，能够指导开发对功能需求的理解，推进产品及时进行功能需求更正
功能需求、项目进度整体把控，研发整个阶段足够敏感，各环节主动 push，及时审查以及推进各阶段风险解决

2、技术深度
熟悉研发框架，能够分析缺陷产生于框架哪一层，具体原因相关
与开发进行功能实现方案探讨，能够解读开发功能具体实现方案，提前规避研发风险（很多时候都是开发告诉我们如何做的，测试可以一起加入探讨，明确需求如何实现）
对于缺陷，能够有更加明确的日志以及问题原因分析（哪块代码，由于什么导致，建议如何修改 ，一些懂代码的测试同学，是能够辅助给出具体产生原因以及修改建议的）

还有一个方向是测试基建的完善
各阶段自动化建设
各阶段效能工具的建设
各阶段验收流程的优化（也可以做为基建一部分）

如果你可以起步开发，直接开发岗位还是比较合适的

这样测试会很累，费力还不讨好吧.......
不过也要看：纯保姆式，或兼职教育式了

如果纯保姆，只能说你们总监太会做人了......

管理员还没有走发贴审核，现在应该可以了

@charseki 楼主可以加我下微信 不 15910532052

接口测试脚本，最好以接口本身的功能转化用例
功能测试场景，只是使用到了接口中的功能

设备没有连接上啊

没事，邮箱我们也收到了，会正常沟通处理

我用的也和你这个差不多，是这个网站 www.json.cn

很多公司应该都有类似于这样的强制淘汰率，其实也是维持团队活力的一部分吧
不过我们以前是连续一直 C 会有被淘汰的风险，但团队中都不错的情况下，有可能人性化的做轮背，不过这个也要看公司文化了

不要这么消极嘛，因为有时候也是个机会呀。