学 java + ts，学完 ts，go 就无师自通了

我也不干测试好几年了，但是我不认为测试和测试技术本身有什么能让人瞧不上的地方，好多东西 99.99% 的人都没吃透，我不想做测试，主要还是测试这个擦屁股的地位，放在当下这种以堆人为主旋律的行情里是无法改变的，真心没意思。

3 年经验 50W 你还想怎样，商汤还有补充公积金，性价比很不错的，老东家了
学区房靠炒币啊，1000 块买屎币变 8kw 的故事，6 万块买狗币变 3 亿的故事不就历历在目么

全项目单测基本就别想了，没几个团队能做到
你这种特定功能，需要大样本测试的，单测最简单最经济，或者你可以管这个叫特定 service 的功能测试，不叫单测也许心里开心点

按道理就是应该单测

A：造轮子，锻炼测试工程化开发能力，方便领导看数据、汇报，讲 KPI 故事，提供绩效参考数据
B：降低测试技术门槛，方便大家做好工具人，保证 70% 以上的人离开公司啥也不是
C：方便全流程、全团队协同，标准化、可视化管理，挖掘质量风险，提供资源池服务……

如果选最实用的话，答案是 A

为啥要开发测试平台，你们 SCG 不是有 SEP 吗，找他们支持啊

表字段太多的时候，尤其有 text、blob 这种类型，最好还是拆一下，分成基本信息和额外信息

道理都懂，我就是为了一套学区房而奋斗，其他的都是屎——但是该装的 B 一分都不能少装：没错，我来贵厂就是为了拯救银河系的，perfect~~~

“暗光下人脸检测的准确率” 的需求是多少？90%？
那低于 90% 都是 BUG 咯……说到底还是没有明确需求呗

看把你给能的，新员工还敢不参加团建

springboot 随便插……而且社区活跃

autoit~~~

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 工程师，本质上就是甩手掌柜！

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