select id, category, max(value) from t group by category;
max(value) 查出来不用就行了

测试计划如果来源于版本、迭代计划，按照测试、阶段类型自动创建呢？
计划中需要执行的 case 根据这个版本、迭代下的需求、任务关联的 case 自动加入，测试计划随版本、迭代计划内容的变更自动变更，这样测试报告如果是按照测试计划自动生成，到期自动发送呢？
还会有客户不愿意用吗，他们可能只是懒得花时间去操作吧，devops 工具链是要集成的，单纯的割裂测试管理的确不好用

有意无意的忽略流程算是不错的，我跟你做差不多同样的事情吧——效率和标准化，我面临的情况是大部分开发 leader 和 PM 反对流程，总觉得工具能解决一切，并且反对在工具里面加上流程、规则的控制点。

我觉得这种时候就没必要指望至下而上的达成共识了，自顶向下的流程强推反而会更有效！

老图，一直适用，这社区里我都发了好几回了
楼主显然处于绝望之谷……不要着急，快了快了

公示一下，匿名区斑竹有我一个，我喜欢删帖

标题党，虽然不提倡，不过还是蛮有趣的
不怪 3 楼认为是营销号，套路真是营销最恶俗的套路之一

一次因为社区，一次因为大量出 U

code-server 了解一下，集成到你的平台里面，装好插件，就是个 cloud-IDE，调试应该还是比较方便的

按照我设计的来，ABCD 都给我改
……虽然是个玩笑，但是如果不影响效率，有时候适当的独裁是需要的，别在你的效率工具上花 6 个人月去实现十个开发每天多 5 秒的操作习惯……再说五花八门的操作习惯里面隐含了多少风险呢，你可以去分析一下～

楼主弱爆了，要是我，当场回一句你煞笔吗，你脑子被狗吃了吗……别说是个菜逼项目经理，就是 CTO 都照怼不误~

我记得以前用某云测服务的时候，他们也提供覆盖率分析，但是我们提交的是 apk 而非源码，可能是有方案的吧，不过具体原理不清楚。

至于 “如何让用户不用在自己的项目内去配置覆盖率相关的内容”，我觉得直接把.pipeline 文件拿到项目仓库外管理就可以实现了……如果是 gitlab-ci.yml 那就逃不过了～～～

不过我不认可开发者不自己处理 ci/cd 的行为，都交给测试或者 devops 工程师，本质上就是甩手掌柜！

我已经很久没干测试了，但是你这言下之意，测试很不需要脑子吗？请问你做什么高大上的工作，来给大家分享一下~

我怀疑楼主在凡尔赛

你们说的是 pyscript 么，正在学

从你的描述可以简单总结一个信息：只动嘴不动手或者推不动事情，主要是别人没有给予大力支持等客观条件造成的……即便事情做成了，也有被领导 “抢走功劳” 的风险，所以不如不做～

我觉得 BUG 还是关联需求比较现实，跟 task 挂在一起实在有点细过头了

太忙，又不想靠写教程挣钱吃饭……而想靠这个挣钱的人都被骂的很惨了~因为白嫖才是主旋律

这些问题建议你还是查查网上别人怎么回答的，感觉你回答的按道理到不了 2 面的，尤其是第一个问题，坦诚到几乎就是被秒杀了……第二个，你完全可以装着 X 回答：相对比较轻松，规定的是 965，实际基本是 985/986，已经比互联网好得多了~

我毕业开始到现在 15 年了，还从来没用过 excel 写 case 和管理 case……最早用 QC/TD，再后来魔改 testlink，再后来用公司自研的，再再后来就自己动手写了~

楼主公司的采购充分说明了采购负责人 “鸡蛋不要放在一个篮子里” 的理念，用两个不同生态圈的工具在一起协作
猫总 DOGE 买起来啊

我从来都是 push -f，我写代码只用我自己的分支，谁在合并之前我的分支上 push，f 不 f 我都捅他

谢绝骗方案、骗代码型面试

应该是 AI 芯片相关软件支撑吧，kernel、driver、toolkit、framework 之类的，面的莫不是寒武纪？

你这个论断忒想当然了，我就是测试工作好几年了学的 Java
原因很简单，开发团队都用 Java，学习中有问题好请教、探讨，有共同语言定位缺陷也好沟通，这样也更容易获得开发的信任感和认同……

你觉得他们具备这个实力？