确实是自测，但是很难推行，普遍会认为这种自测是测试在推活，研发在帮测试走用例
有些害怕这种反而会适得其反
想先 将自测观念 打入，目前 研发团队 自测意识薄弱，都是优先完成，甚至 bug 修改，部分研发都直接叫测试进行回归，一个 bug 甚至需要来回修改 3-4 次，想想就离谱
看来还是得想开点，哈哈哈

谢谢，您的答复对我很有启发
目前还存在以下问题
1、产品定义粗糙（对应上面说的 这么多 P3，说明产品设计层面可能有问题。）
2、公司缺乏统一标准。目前产品缺乏公信力，研发团队基本全是外包人员，产品定义粗糙，也导致产品定义没人看，不太在意产品定义；研发不在意，产品定义就越来越粗糙（这方面没有管理好导致的），这就形成了恶性循环。
3、关于 *“你的质量观念和目标是否和大环境一致？” * 这点确实不太一致，目前最大的痛点就是 我觉得 +1 的目标只是先将主要功能做出来，粗糙没有关系，只要在 deadline 前有一个 版本拿出来先，然后才是 完善功能；
公司的目标是 在 deadline 前有一个 版本拿出来，这个版本需要客户满意，这就有冲突了；
目前也确实 deadline 前有一个 版本拿出来这个事情 对研发来说有挑战， 但是我不认为是软件粗糙的理由，这样后期会花费更多的时间

反思
接受建议：
先按现行合作方式走，即使有很多问题

试行
抓 1-2 个重要模块 而非全部，将这 1-2 个模块的功能按照好用（用户视角）为标准走，其他安装能用（+1 视角）标准走，极大减轻研发压力
且可以试行 优化流程的方案，看看效果
同时 归类并统计这 1-2 个模块 ，产品定义细节问题、UI 设计问题、功能未对齐问题、bug 的数量

先看看效果，然后确定自己的定位（选择暂时接受，还是其他...）

产品更新需求，不同步开发，测试？ 还真不知道，有些功能变动了测试是真不知道，更别说开发了，需求文档这种东西从来没有，为什么会是增加工作量？是整个团队都没有啥干劲了，都不是一条心的，大部分人都没有抱着将产品做好的心态去做的，都是产品怎么定怎么做，只做好本职工作就行，哈哈哈，不背锅

肯定会被吊的，哈哈哈，增加别人的工作量，谁会支持啊，所有想法得不到实践的机会，就注定只是想法
所以发帖想确认想法的可实施性与正确性。因为理论并不等于现实，更想知道现实的情况

大佬，UI 自动化中的关键字驱动，是不是类似于接口自动化的

Yaml 参数化一样的实现效果啊，现在在做 POM 封装，目前还没有实现 UI 自动化的关键字驱动，就像你说的但是随着业务越来越复杂其实学习 excle 的成本已经不亚于直接写代码了。这种关键字驱动不就是等于重新学了一个更复杂的平台吗？而且这平台随着业务越来越复杂，学习也越来越负责，要知道的关键字越来越多，感觉在 UI 自动化中需要实现的关键字驱动模式就是个伪命题，并不会节约时间成本，而且 UI 自动化去写已经封装好的代码的用例，感觉是比了解关键字去写用例要简单的。
还有 UI 自动化大部分公司的是用不到的吧，只是为了凸显专业性而已，在一个产品中，最经常的就是界面，UI 自动化的维护成本很高，要说价值吧，肯定也是有的，在回归 bug 与业务性测试能节约很多时间，但是全功能覆盖就是没啥太大的用处，除非界面已经不经常性的改动了
想问的是：UI 自动化的关键字驱动真的有可以用的地方吗？在什么情况下比学习已经封装好的代码去写代码用例更简单

我倒是希望被劝退，一是被裁，二是先总结下，再骑驴找马

是这样的，主要还是这个项目线的团队人员都没有动力了，现在又搞绩效，有不能涨薪，上层领导对研发团队极其不信任，之前都动过全部换血的想法，因为成本太大就没有实施，现在找了外包负责了，外包人越来越多，但是还是没有搞定，还得加时间 + 人手，笑死

好的好的，毕业后只在这一家公司工作了三年，所有比较想多了解下其他公司的流程，做下参考

认可，所有我让它空着，自己准备随时跑路，只是想跑路的过程中发现自己过得太安逸了，也市场脱轨了，现在在努力接上轨道
之前同事和我说过，要经常想的去投简历，了解市场行情，当时我不以为意。果然事教人一次就会啊。现在我就处于要将这几年学到的东西进行总结的阶段，总结完也就差不多得跑了。总结的东西太多了，估计得需要几个月

哈哈哈，就该如此，理应如此