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

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

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

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

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

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

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

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

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

测试一定要会测试这个很认同，但是我现在所处的环境告诉我，高测试覆盖率很抽象，不管是场景法，因果图、错误推断法也都是基于业务去实现的，这些也只是一些被归纳总结的方法，方便学习；可以在面试过程中体现测试的专业性。在我参与实际的项目中（仅是我个人观点，与我的经历有关，没有人的环境都不一样），非测试人员的更多关注点，并不是测试过程中使用了哪些专业的知识使测试覆盖率增加，而是能够在什么时候发布版本，这种往往留给测试的时间并不是很多，一般要不就是产品延期就是开发延期，导致测试时间被压缩，但是又得在规定时间内发包，这种情况下测试覆盖率就不会很高，只能测测关键流程，重要功能以满足能够快速发布版本的需求，公司的要求也只有不出现重大事故（说实话，这个很难量化，出现了往往就是测试背锅）
在我刚进公司的时候，也往往已测试覆盖率、测试用例设计的完整度为导向，以此体现自己的专业度，但是这种太隐蔽了，输出的测试点、测试用例也并不能体现专业性，无法被看到、关注到，就更加无法获得晋升。从而慢慢的往其他更加容易看到结果与反馈的技能上靠、比如自动化、接口、性能等。不会这些技能的在市场中也仅仅是功能测试，市场价值就已经决定了这条路的终点，现在体现测试专业性的往往只是测试辅助技术（自动化、接口、性能），这些技能更加容易被量化，更加容易被上层关注到，从而获得晋升。这些技能也往往符合老板的预期：自动化节省人工成本，较高端等
总而言之 并不是我们忽视了测试基础的重要性，而是市场大环境忽视了，我们只是在适应环境

与他们都深度交流过，感觉是管理上的问题，小公司的管理都是内部晋升的，年限到了就自然升上去了，不太懂得指定规则去约束下属，怕得罪人，因为做与不做对领导层来说没有影响，多一事不如少一事
我是有点觉得我自己目前的想法太过于理想了，感觉轻量级流程更适合于小公司，在确认想法中...这对我来说也是一种成长。至于期望，已经完全没有了
就害怕理想与现实的偏差，会导致我陷入死循环中，还是不能太理想化了，想将理想化的东西转化为可以实现的现实。
当然理想化的东西可以认为是完美的，但是也必须允许不完美发生，不能太较真了。一步一步去完美化，结合实际去制定轻量化的流程管理
所有现在有就有点想知道其他公司都是怎样的流程，多看看先