说个以前公司的，有一套单独的应用市场，各个团队自己在用的一些小工具啥的，按照应用规范加个入口，就可以集成到平台上，对外提供使用。

嗯，对于 toB 或者 toG 的公司来说，确实有很多应对交付的文档工作。可以抽象出来，通过配置映射模板，可以将 excel 的用例转成对应的 word 用例文档。

刚好您问到了这问题，最近我们的计划应能满足你

我们计划 在迭代下，你可按条件把当前把一些用例选出来，然后自动生成一个回归的场景，挂到当前迭代下，这样你就不用建迭代了，相当于，一个迭代下，用例支持多轮执地且执行结果是分开的，在迭下下多一个 TAB 回归测试， 只是每建一次分配，你要取一个回归的名字。

后面的那套逻辑确实是满足回归的需要了，但是从操作层面上还有些疑问。
1、从执行角度，迭代中测试的视角是不是计划更好一点，就是上面的这个回归？因为这时候用例更像是一个用例库，是一个供选择的资源池；
2、从质量角度，由于用例多轮的执行，迭代的质量数据应该是汇总的多轮次的执行数据；

jira 是怎么支持发送测试报告的？是新版本特性？

先顶一下，豁然开朗，感觉把之前对指标比较零散的概念立体化了。

顶一顶，数仓测试这块与以往系统测试在测试面、测试流程上截然不同，我个人的感觉是在功能测试和数据分析上需要一定的平衡能力，要不然在陷在数仓无穷无尽的数据优化测试中，且测试本身也没有成就感。

产品问题很多是有什么样的表现，项目经理和产品是否知情
1、表象是缺陷很多，那可能需要坐下来围绕当前产品的 bug 确定下投入情况，产品的投入是整体的，测试的投入是先期条件，在研发确定投入人力的情况下，在考虑测试已有的人力暴露问题；
2、围绕流程、人员、质量、需求等等进行产品的摸排，从现象->根因，如果一个产品问题很多的话，那一定是全方面的问题，抓大放小，逐步改进
3、对上资源的协调，对研发负责人意识的同步

对于 token 的处理影响不大吧，主要还是看后续业务的实现。我们之前有业务是根据用户 id 进行分表存储的，单用户压测导致业务缓存全倾斜到单表中，导致查询变慢，与预期的性能结果不同。

哈哈，看昵称，应该是 itestwork，开源的测试平台

Hephaestus ： 火神和锻造之神，锻造产品质量

有个疑问，这样的话研发的接口管理和测试的接口测试还是存在断点，如何保证研发的变动及时被测试感知，并体现到后续的自动生成自动化用例这边呀。

swagger 那个东西主要是，没有字段注解，没办法给功能测试的同学。。。。做不到提效。。。而且公司的测试数据管理的很严，很多数据其实不太好自动造。。。

也遇到类似问题，项目团队不是很开放，对一些工具的引入比较抵触。我们的想法是基于测试内部来去做，落到小处，逐渐去推动一些想法落地。比如 swagger，我们考虑是测试引入 yapi，在结合一些 idea 的插件，最小成本在测试内部维护接口（是不是很喜剧…），然后推一些注释规范的落地，这样对测试来讲就初步满足了提效的准入条件，围绕接口在继续做接口自动化（smoke），在基于 yapi 的能力做持续集成。有了一定效果之后在反过来去与研发团队沟通，拿案例和实践说话。
其实，很多测试的工作开展，真的需要一个好的项目经理配合，不多说，泪目

第一种看上去与业务绑定太密切了