不知道我理解的对不对：根据字段规则随机生成字段内容？那这个生成是有个定时任务？

我目前也是这个思路。前两年也弄过，但是弄了也没用起来。大的方向还是得跟着部分的方向走

感谢大家的回复，不讨论了，领导有了明确的要求，必须要用用例工具，方便统计出了多少用例，UI 覆盖了多少。就是为了看数据呀

也不是融合到一起，谁写谁的，只是放到一个文档里了，他们还是独立存在的，不过我虽然一直在反驳大家，但是大家的意思是最好还是不要写到一起了。咱们这里都是测试同学，能不能麻烦各位看看自己的开发是如何感觉的。前提是你们也是用例驱动开发模式

这个之前是给脑图的链接，但是对应关系不太好找，一个项目多个开发时，开发也不能对应找到自己负责那部分的用例。但是需求模块是明确的，然后按模块在下方提供用例。这样开发很容易找到对应的模块和用例。有关联关系的再用例标明一下就行

我们的需求有两种形式，一种是在原来的基础上增加，还有一种是分期的，一期，二期这种，每一期略有不同，用例有部分可复用，有部分就直接没用了。有比较大的需求，等这个大的需求完成了，就会提一些小的优化。我想表达的是我们历史的用例看的很少。回归测试用例之前也整 过，但是没啥人看

原因呢？

用例也跟着迭待呀，有一版需求就会有一版用例，而且这个维护，要维护什么呢？

现在系统成熟，人员变动也小，我们这个业务的测试我待了 11 年了，其他测试人员也五年以上，开发人员变动也不大，所以我们的用例基本上就没那么细致了，要说细致的也写过，阅读起来太费劲，还不如一个流程图直观，流程了解了才去了解小分支。

就是一个开发组长，不是管测试的，我感觉他的意见完全是他对应的测试人员相互配合的不好，我们 100 多的开发人员从来没人说过用例的事。

想要的太多，又哪个也不精通，就是现在的我

你这个直击心底，确实不精通，只是照猫画虎能写写

打击我

再补充一点，去年我做的事情是写的用例怎么让开发更易读，更直观的去看用例。今年的话，就是根据看板的去匹配用例，用例不会很庞大，因为一个项目多个开发人员，开发人员也不用去在一个大的用例里去找自己做的那一部分，用例的提供更有针对性

感谢回复，说到心坎里去了，首先说一下我为什么还待在这，因为这种情况也只是一部分，还有一部分也是需要测试的，在一个我在这个团队待了 13 年了，说出来可能丢人，人没啥出息，不想操心当领导，有机会的时侯也没把握就想在一线干。您回复的这些对我还是有启发的，我觉得第一点的去深研质量是不是真的好，其实我想的是可以从出的线上 BUG 入手。第二里的造工具造平台这个是有专门的人去做然后供我们使用。当然后也是我个人能力问题可能也搞 不了。所以总结出来就是我可能还是偏质量流程上去做改进。

感谢回复，在我所在的业务线来说大概有一半的开发做的业务是不需要测试介入的，我们这个团队人员非常的踏实，大部分的开发人员待了有 6，7 年了。而我们的业务又是比较固定的。可扩展性不强，底层的数据这么多年来也就那几样，在这几样业务上也不玩不出什么花来了。我目前就是觉得除了写用例和执行测试外，不知道我还能再干什么。我想过接口测试，但是我看了好多的文档又说服不了我做接口自动化测试，总觉得不如页面测试快，可能我接口自动化测试太烂了

感谢回复，我还是想长期干的，但是不想学习的理由也千千万。但是也不想放弃不学习，部分今年刚换了大领导，我这小兵子也迷茫了

感谢回复，这就是我想问的点，我要怎么去挖掘，内卷的历害，我也是想向大家取取经

感谢回复，现在我们也不是百分百的不需要测试，一些项目尤其是时间周期略长，多业务合作的，测试去推进业务，或者说开发人员找到了用例中的问题，或者测试人员测出了 BUG 都是很有成久感的。但是也在想不需要写用例和测试的，我们测试人员但测试这个环节又需要做些什么吗？不是说很大的范围 ，我只是个小小测试员我就想我做为一个测试要做什么？

感谢您的回复，您这个链接里是整个质量部要做的事情，像一些数据呀，平台化的东西，自动化的我们平时也在做的，除了本人以为我们也有专门的人员去做这些事，我只是一个最小的业务测试人员，平时主要工作就是保证项目的质量，但是现在开发都不需要测试的介入了，我就有点慌了，一开始还庆幸终于没那么忙了，但是现在又怕自己在团队中越来越没有输入出。

我现在也是老提醒我老公，别老玩游戏，别熬夜，不是我唠叨，而是我经历过，不想让他在经历