核心奥义四个字：能跑就行。平时多锻炼身体，有备无患

能不能让领导多招个人

只要主线流程能通，其他的都好说

我只能说: 大家一起摆, 看谁被开除

那就直接不报错就行了 他们延期了 为啥要压测试时间呢

这种情况只能保证主流程了，多给自己留点跑路的准备时间吧

这种情况，但凡领导想保证质量，项目组都应该有 2 个测试，保证能做交叉测试

不幸的是我正在经历的就是这样的情况，直接摆烂，当天提测当天发版上线的我都遇到过。我是准备跑路了，干不来干不来

很正常，要看客户的需求是什么（要什么样的版本）

Z 看到公司在招测试 不过可能是平替现在这个坑位

开会骂领导的时候别问候家人就行。

如果你是个新人（钱不多），骑驴找马，去有测试氛围的公司，共同进步；
如果你是个老人（钱给够），规划方案，向上寻求资源，解决问题

很多公司都有这种情况，这就是把你测试当杂工呗，上线前去点点点，主要功能有没有问题，是一个人都可以做，没任何个人价值提现

甚至比你这还离谱，功能未开发完成，这周出测试报告，下周功能开发完成

你这还好，我这边在你说的这种情况下，还要要求 BUG 几乎没有

只要他敢压缩我测试时间，我就敢泄露。谁怕谁跑路就是了

我也一样,项目组只有我一个人测。
1.前端服务有 4 个，后端服务十多个，常发版的服务前端 2 个，后端 4 个。
2.不需要写用例，没有用例评审，只用思维导图写测试点。
3.对系统和业务熟悉，有所有项目权限代码，初次提测时代码变动量挺多的，时间不够基本不看，测试期间改 bug 提交代码都会看下，有些小小的好处。比如有时候告诉前端，详情和列表页都要改，然后前端只改了列表，提交代码；这时看代码，可以看出前端改了哪些 vue，可以节省一个发版的时间。
4.基本每周四发版本，有忙有闲。忙的时候加班到 8 点半，闲的时候准点下班。
5.工作中基本是功能测试，性能测试较少，大版本更新或者环境迁移的时候才会做性能测试。新需求跟着测试点执行，周版本上线前至少有半天的回归时间，手动回归主流程，同时接口脚本也会跑一遍。如果测不完就延期。项目经理实在要上，可以上，有问题他负责。
6.版本质量不稳定，每周会有运营、商务、客服反馈问题，业务流程基本正常，但是小问题比较多，比如用户录入的某个字段超长，导入 excel 异常提示语不明确。很多工作时间会浪费在这些小问题上，有时候其他同事也会和我来问业务流程。比较舒服的是从来不会因为有小 bug 流出而被叼。
7.是去是留，还是取决于自己，大多是考虑薪资和个人的成长，以及工作的舒适度。如果觉得工资合适，工作强度适中，就是当测试杂工也没关系，在公司学不到什么的，大多是看自己自学的。如果觉得测开才是高大上，最好找好下家再跑。

我们项目之前为把控上线质量，版本是否上线取决于测试，测试觉得可以上线才发邮件（测试测完还有业务测试的流程，一般是业务 A 提的需求就一定要业务 A 进行测试并回复邮件，功能没有问题，与需求一致），有一次一个跨团队测试项目，主流程都跑不通，我直接打回了，产品 + 开发重新梳理，开发自测没有问题再提测。

你这主要表现就是测试时间被压缩，工作进度紧张；建议你挂个专家号
首先己评估工期的时候，就要多增加的风险时间；然后尽早抛出问题可能存在的风险点，如果这样可能导致测试不全面，存在漏测功能；最后，整理并压缩测试范围，并找领导确认；

你看，你匿名发帖的名字都在告诉你要明哲保身，尽早跑路了

1、测试按照计划进行，延期上线。
2、正常上线，只保证主流程没问题，允许带问题上线，向领导、项目负责人提示风险。