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

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

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

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

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

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

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

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

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

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

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

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