测试压力也很大啊，你想象一下，出现一个线上问题，你的大 BOSS 盯着你问：“为什么没测到？” 的时候

请大家务必要理解这句话：我们不是测 BUG 的，我们是做质量管理的

作为一个快 10 年的测试，来讲讲自己的心得吧
1、测试时间评估
问题点：项目的排期不合理，首先要明确一点，项目经理/产品 知不知道一个人同时做两个需求是不可能的事情，如果不知道，直接找下家，这种公司呆不得
如果知道，那么问题就好处理了，测试任务来了，首先明确提测时间，上线时间，还有自己的测试时间，然后再看自己已经排期了的项目，如果中间有空挡时间安排的下，那么就排，如果排不下，和现在手头项目 PK 优先级，被 PK 掉的项目顺延
临时拉会这种我觉得不算问题，对自己的业务很了解的话，其实评完了能估个八九不离十的，而且基本上研发怎么实现也都差不多知道，这个看每个人的水平，不过我觉得一般的老测试应该都能做到，要求不高，但是比较忌讳直接按开发百分比排，因为有时候开发改一行代码你要回归很多东西，所以这个排期你得拿出依据，要回归哪里哪里有理有据
2、同一时间多个任务
上面讲过了，就是排期问题
3、需求不明确
这个基本上都碰得到，这个得靠团队磨合，有的产品就是一句话，但是你作为测试就得反向约束，如果约束不了
要么提前确认细节 (要留证据，不要口头，最好是钉钉飞书上的文字记录)
测试已经尽力确认了，然后还存在需求文档上没有提到的，线上发生问题，我觉得这个锅应该产品背，实际也就该产品背
4、线上 BUG
这个得看公司氛围，有的领导喜欢抓人背锅，有的领导就是大家对事不对人，复盘之后总结一个规避策略，以后不在发生，这个你决定不了
5、测试报告风险规避
没啥好说的，提高风险意识，存在不确定性的事情就提出来，不要自己觉得可以就放过。
6、测试时间不足
突发情况的确没办法，不过 1 天内的延期基本都是可以消化掉的，消化不掉的，要马上报出风险 (延期风险)，要么调整排期要么加人，你不好意思开口，那你就加班呗
但是往往越紧急的时刻，越容易出现问题，就算你觉得你 hold 住，事实上可能并不能 hold 住，别太自信。所以千万不要自己觉得能把握住就主动说没问题 (大忌),出了问题就是第一锅
一个原则，有风险报风险，时间不够就是要提出来，不要默默担着，吃力不讨好
7、用例执行困难
把握提测质量，很多公司测试没有话语权，但是话语权是不断开发博弈中争取到的，提测质量做好数据统计，定期反馈给上级，上上级
8、测试数据陷阱
没太看懂这个场景。。都是自己造数据啊
9、业务自动化
市面上的自动化工具，只能做到通用，但是不能做到合适，这个得清楚，适合自己业务的自动化一定是高度定制的
如果公司自己做的不好用，那就是产品力的问题，不过现在很多测试都只是以为整个平台出来就 OK 了，实际上为什么会有测开，就是得了解测试需求，知道测试习惯，怎么做自动化产品能让人写得快维护方便，这才是产品力
技术实现 low 还是高大上倒是不关心的东西，抓住老鼠就是好猫，适合自己的才是最好的，
自动化能做成功的关键就是 写的快 + 好维护 + 可复用，不然后面都是负担
总结：讲了这么多，其实你会发现测试做的不仅仅只是测 BUG 而已，更多的是做质量管理，把控好交付周期中的风险，及时上报及时同步，对于质量数据存档，然后形成反馈，在不断地迭代中提升测试话语权，做到这基本上你会发现上面的问题都很好解决
什么时间紧啊，任务时间冲突啊，那些不要觉得不好意思开口，一定要说出来，本来就不是你导致的原因，没什么不好意思说的

自动化用例的生成，指的是文本用例直接转换成自动化用例么？我上面提到的指的是使用大模型将手工文本用例直接转换成自动化用例

在我开始进入测试行业的时候买比特币，然后记住东方通信，酒鬼酒，诚迈科技，阳光电源，锦浪科技，石大胜华，九安医疗，中通客车，西安饮食，剑桥科技，鸿博股份

感谢分享
我在看的时候有几个疑问点，看博主能否给解答下哈
1、测试开发比 1:20，具体的统计方式是什么样的？语雀平台在这个过程中大幅减少了哪一部分的时间？
2、在达成测试开发比 1:20 的时候，其他的质量指标情况是什么样的呢？比如项目线上 BUG 率

垃圾团队才分锅，优秀团队都做总结 + 增加手段预防。
锅就算找到人背了又怎样，以后不出问题才更重要

就是看你需求之外做了些什么了。降本增效，工具，左移，右移等等

大家都是做需求，肯定写点需求以外的东西哇，不然怎么突出出来。。这么理解，把需求做好，是 60 分及格线

这都还不走？

CTMD，中国战区导弹防御体系（China Theater Missile Defense ）

怎么算是精通 JAVA 呢

父愁者联盟

不是说自动化没有用，是说做自动化的成本是低于收益的么？

这玩意有用？

那就是有可能是 start+ start？ end+end？

所有的组合指的是 必须是一个 start 和一个 end 么？还是说只能是 A start 和 A end

现在企业里面有一种风气，就是测试必上自动化，尤其是领导层，只要一提到效率，必然就是做自动化，他们对于自动化的理解仅限于 ‘自动化’ 这三个字，对于他们来说，自动化就是被神话了，觉得自动化无敌，而不去考虑实施自动化所需要的前提条件，盲目追求自动化，最后时间没节省，反而更慢了

既然都不变，那何必要测？既然改的不多，手工测完不是更快？

有这样一种场景，接口入参是定义了一个 bean，然后我在这个 bean 里面加了一个字段，校验是 NotNull，然后这个 bean 被很多个接口用到，那么在修改掉这个 bean 时，会导致自动化用例大规模的报错，然后再去一个一个修改自动化用例，这样成本就高了

能力强的写可能没什么问题，但是团队里面能力良莠不齐，对于能力稍弱的同学可能就不太容易了，而且写完不是结束，后期维护才是大头

大致的思路都查得到，具体的实施细节可以自己研究一下。

这是理想情况，但是往往的迭代过程都是研发还未提测功能时，测试还在上一个迭代的测试工作中。
走验收流程的自动化测试的话，那么花那么多人时投入自动化，是不是收益太低了？

我一直有几个问题
1、都说敏捷中的自动化加快了测试速度，实际上，只是把写自动化用例的时间往迁移了，测试所需要的花的时间没有真正减少，甚至可能由于测试人员的代码能力不够，导致花的时间更长。。如果从单迭代看，同等代码能力的测试做自动化花的时间比手工测试需要的时间更长，以前可能只需要 3 天手工测试，现在要花 4 天写自动化，然后 3 天做手工，反而多增加了 4 天的人力成本，所以自动化真的加快了测试速度么？
2、如果说自动化是加快了回归的速度，那么每个迭代都需要回归么 (我个人觉得无脑回归不是正解)？良好的开发设计是不是可以规避掉一个改动影响一大片功能的这种情况 (就是说测试需要深入了解评估研发的设计)？如果有了精准测试，是不是就不需要再付出大量的时间去做自动化了？