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

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

好硬核

通过 cookie 绕过

支持

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

这个淘汰很久了

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

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

学习到了，谢谢大佬

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

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

因为我理解的这个平台主要的受众其实是功能测试的测试群体，实际开发或者其他测开可能有更好构造数据的方法，你凭什么让他们都来使用，上手成本低易学习我想是一个比较大的亮点

如果想在项目中普及，建议是可以能够让测试上手成本降低，因为很多测试构造数据的目的是为了快速且符合测试要求，如果上手成本过高，可能会觉得是不是我自己写一个适合自己使用的构造数据的 python 或者 shell 脚本就足够了，还有模板的问题，老实说我们自己项目就是用了类似的技术，但是上传模板需要太多步骤，导致实际在测试中使用的人很少

很中肯，测试同学在追求技术的提高的时候也不能忽略了业务能力的提升

很优秀，但是存在相当程度的上手成本，建议可以在易用性方面再补充做考虑，1.是否可以将数据模板固化下来，因为对于一般测试同学，可能只需要存在某种类型的数据，而不是每种数据都需要自己进行配置

要做到每个接口验证的功能能够单独运行的话，是会存在一条用例冗余的情况，不过这样可以保证你在跑自动化整体的时候不会因为一条失败而阻塞

我是设计新建->查询->删除保证我的全流程可以跑通，又不影响整体的自动化案例执行

有没有一种可能敏捷指的就是流程优化后的瀑布模型

做为使用方，表示公司的数据工厂比较难用有一定上手成本，而且环境需要持续维护，环境时不时就会崩

避免漏测，我说说自己的看法，第一是提升自己的业务能力，对需求和影响面尽量多了解，这样在做测试设计的时候也会考虑的更加全面。第二是要进行测试设计以及测试案例的评审，拉通产品、开发、最好是有之前熟悉这个模块的级别比较高的测试同学，可以提高你的设计质量，也可以站在不同的视角分析问题。第三是最好具有一定的代码能力，可以参与开发的设计评审/代码走读，这样在评审过程中提前发现问题。

在使用手册里面标注好我们适配什么样的系统，需要什么样的配置，需要什么样的条件，优先规范好客户环境，不然客户千奇百怪的环境你不可能无限适配吧

都可以吧，你自己有环境就在本地执行呗，不过一般服务都是搭载在服务器上面的吧