不能携带登录态吗

我一般是已经开始看下个版本的需求并开始设计，或者突然被其他特性组的关联需求叫去了解需求 ，实在没什么事就看一些能力提高的文章呗

是整个项目收尾还是只是一个版本呢

前端的控制是虚假的，可以被绕过

你需要体现当你获得发布权限会带来什么价值后续拉会对齐，例如风险把控、责任人等

首先测试环境发布权限本来也不应该在开发手中，而是由项目经理把控，如果没有项目经理也应该是由测试主管把控什么时候发布

有没有可能是他们京东内部的官号发的内容呢

类型校验这个，看特性组吧，有时候还是需要的

学习到了，感谢大佬

有没有一种可能，所谓的不关注项目本身是因为他们是专职弄效能的同事，或者是已经完成项目的基本功能测试想要追求效能提升。

加油

领导是这样的话，可不可以自己去做一下技术选型，把自己熟悉的知道的自动化框架列一下，陈述利弊，领导有什么问题或者有更好的，后续会议上讨论

如果产品确认是很刁钻的场景客户很难或者几乎不会碰到，不考虑就不考虑了咯

当然需要，产品很多时候也只是把控需求的大概，具体细节很多是考虑不到，建议测试在介入需求后如果有发现需求不明确或者细节不明确的情况，及时记录一下，及时和产品确认，如果疑问太多建议拉齐测试经理、开发负责人、产品、交互设计师一起开会对齐

不然后续随着迭代版本管理以及用例后续的转自动化会是大麻烦的

好硬核

通过 cookie 绕过

支持

确实，不过多学习总是好的，学对方向

这个淘汰很久了

建议还是能统一的在一个地方去管理

按道理来说你知道录制这回事的话，应该是了解可以通过 jemter 设置代理服务器进行录制的，目前许多接口测试或者是 ui 自动化测试平台都支持录制用户操作来进行生成脚本，自己可以对应添加断言也好、检查点也罢来生成用例。用例管理时再区分场景和前置条件。

学习到了，谢谢大佬

具体描述一下你的使用场景

首先在拿到需要对接多个项目组的任务时，首先评估好工作量，需要多少人力和成本并统一提供给项目经理，如果是在合理的情况下确实评估完一个人弄不完，再去申请人力安排也是合理的。其次作为 TSE 培养自己下面的测试，让他们能够独当一面，比如让某一位测试多和其中一个项目接触并加以辅导，后续让他当对应项目的接口人，也可以让自己作为 TSE 有更多伸缩的空间