陈哥聊测试

我们团队正面临需求部分明确但市场反馈多变的项目。之前参加禅道中国行的时候看了融合管理框架的白皮书，我就想着试试。但实操时，还是只走了敏捷，完全没达到我想要的效果。

我将会以禅道软件为实操工具，以开发一个APP开发项目为例，按项目启动、项目执行、项目收尾这三个阶段，来拆解一下有效管理进度的核心逻辑与实操方法，帮助大家搭建起科学、可落地的进度管控体系

前几天参加大会和老朋友碰上了，就一起吃了个饭。 他说他们团队这大半年就没踏实过，每个项目都做得特别赶。上次一个定制开发项目，本来留了充足工期，结果做着做着又开始加班。

我最近看了一系列关于LLM改变自动化测试的文章，说实话，真的打开了我新世界的大门。从最早的QTP、Slenium，到后来的Appium、Postman，尽管我们禅道也在做自动化测试，但我以为自动化测试

我看到有不少读者给我留言吐槽代码覆盖率很像自欺欺人的数字游戏，低了怕影响质量，高了又怕陷入“为了覆盖而覆盖”的无效内卷。明明功能测得差不多了，为啥非要揪着这个百分比不放？

从11月开始，我们陆续北京、深圳、上海、济南开展了禅道产品研发流程实战训练营。 我们在后续活动复盘时谈到，有些参会者对需求实例化很感兴趣。 今天想借着这篇文章展开讲讲。

大家好，我是陈哥。 不知道大家看没看过这个问题： 既然测试也要求写代码，那干脆让开发兼任测试不就好了吗？

我所在的禅道一直在做开源，所以我朋友经常会跟我聊开源相关的内容。最近他用的一个开源工具从今年年初更新频率就变慢，现在Issue里的问题没人回答。

每个软件都应该进行端到端测试，以确保其按规定运行。这种测试方法建立了对系统的信心，并帮助开发团队确定软件是否已准备好进行生产部署。