背景：公司开始抓人效，部门老大开始从测开比入手，一开始打开引入 AI 写用例等方法，尝试后发现并不可行，现在开始另寻他路。
问题：公司目前是起步阶段，大部分需求都是 0->1，自动化等暂时看不到很好的效果，但是大佬迫切看到一些效果或方案。之前看到高飞大佬说他都是把一些工作转移到开发这边来完成，但是部门老大要求 基本不增加各角色的工作量 的情况下进行提效。在我的认知里也就只有加班这个方法了。
想看看大家有没有好点的方法。
其实大部分短期能提效的手段都是流程上的改进， 尤其是不必要的东西不要做， 我在第四范式的时候有个研发总监就特别注重这一点， 他会跟产品那边 battle，什么需求是无效的，不合理的，不完整的，在他那里会打回不少的需求。 测试这边也是一样的，有些东西可不可以不用测， 可不可以让研发自测（走免测流程）。 或者就直接重新定义测试投入的计算法， 比如大老板觉得测试周期太长了， 那就得好好掰扯掰扯什么是测试周期， 提测打回的这期间算不算测试周期， 研发修 bug 的时间算不算测试周期， 部署环境的期间算不算测试周期。 在第四范式的后期的时候， 那个大老板请来的人才就是玩这种文字游戏愣是把测试效率在明面上提高了 7 倍。 再就是开启裁员 + 加班模式，大家玩了命的干，每天工作 12 小时，周末也加班（没加班费），生生的打排期打下来。
能立杆见影的都是上面这些方法，当然有些同学可能会说这好像也不是真的提升了效率了， 但大家觉得老板真的是关心效率么， 老板才不关心效率是不是真的提高了。 只要最后展示出来的数字显得效率提高了就可以了， 不管你是疯狂的加班还是用别的方法， 老板其实不关心。 老板关心的是成本， 是报表中冷冰冰的数字。 老板要看到的是测开比 1：xxx 的数字， 至于你是用疯狂的加班的形式去完成的， 还是把工作转移到其他角色上完成， 还是推脱掉了很多工作完成的，或者是真的通过技术手段和流程改进提升了效率，这些不重要。
所以很多聪明人的做法都是玩各种文字游戏和流程优化，也就是我上面说的这些立竿见影的方法， 然后找个说的过去的说辞（比如引入了什么技术， 引入了什么迭代模式）档在前面。 相信我，很多小领导都是这么玩的，只要给大老板看到的数字是漂亮的就可以了， 至于怎么堆到这个数字的，那就且看我怎么解释（瞎编）给你听。
其实真正关心效率的往往都是大头兵，因为大头兵才是那个在一线执行的人， 效率真的上去了大头兵们才不会那么痛苦。 这也是为什么我愿意长期的投入精力在提效上。真正的效率上的提升都是长期的积累，是量变引起质变的客观规律。
那你是想降本，还是想提效呢？
我是想提效，还把本降了！
提不成！
提不成？
提不成！
加班，能不能提？
能提，耗命。
嗯...自降工资，能不能提？
能提，憋屈。
加班加上降薪，能不能降着本把效提了？
敢问九筒大哥何方神圣？
鄙人，张牛马！
但是部门老大要求 基本不增加各角色的工作量 的情况下进行提桶
这是让马儿跑又不让马儿吃草啊
尝试找找可自动化或者半自动化的地方
但是部门老大要求 基本不增加各角色的工作量 的情况下进行提效？你会不会骂人？我问你会不会骂人！？
领导：我允许你给我两个嘴巴子，但是你不能动！
赶紧跑路吧
1、写点脚本辅助测试，可以节约很多重复造数的时间，还提高了数据丰富度
2、把无关紧要的文档工作分出去咯，时间抽出来用到核心的测试工作上
3、多拿点资源在手上，数据库、api 文档、需求、原型文档、检查表、测试知识库、gpt 的账号等等，提前把装备搞好点
个人觉得：所做的事都去围绕着测试目标：“在有限的时间内，尽可能多的发现问题”
至于用什么类型（点点点、自动化），用什么工具（测试平台、AI 大模型、其他各种测试工具），根据公司的财力、个人的能力以及项目的情况来，但如果脱离上面那个测试目标，那就走远了....
"高飞大佬说他都是把一些工作转移到开发这边来完成"。
--这句的前提是我好像记得他说过，他那的研发测试比是 20：1。
你不能看问题只看一半。
一线的测试人员，对这种从 0 到 1 项目测试最头疼的点会比较了解
1.需求理解不足
会面临需求不明确或频繁变，直接影响测试计划的制定和执行。会花费大量时间在需求澄清上，甚至需要反复修改测试用例
2 测试用例设计
测试人员需要从头设计测试策略、场景和用例。为了覆盖更多的功能、性能和边界情况，这一过程需要大量的思考和规划，尤其在复杂系统中，设计全面的测试用例需要耗费不少时间
3.环境搭建与配置
在从 0 到 1 的项目中，测试环境往往还未完全成熟，需要测试自行搭建或频繁调整，确保与生产环境一致。这种情况下，可能需要额外时间处理基础设施和系统集成问题
4Bug 修复与回归
Bug 需要督促开发人员修复，修复后的版本需要进行回归测试。随着项目的复杂度增加，Bug 数量和回归测试的次数都会增加，中间要不断更新和执行用例，确保修复后的系统没有引入新的问题
就上面的四点，都是要实打实人力执行的，先搞定第一版的测试再说什么效能提升了
增效的潜台词就是降本
针对测试这块想一下有哪些可以做成自动化的嘛
1。回归用例能不能做成自动化
- 一些测试场景的构建能不能做成自动化
- 数据校验能不能做成自动化 然后就是衡量标准了；看你衡量标准怎么去体现提效价值
其实大部分短期能提效的手段都是流程上的改进， 尤其是不必要的东西不要做， 我在第四范式的时候有个研发总监就特别注重这一点， 他会跟产品那边 battle，什么需求是无效的，不合理的，不完整的，在他那里会打回不少的需求。 测试这边也是一样的，有些东西可不可以不用测， 可不可以让研发自测（走免测流程）。 或者就直接重新定义测试投入的计算法， 比如大老板觉得测试周期太长了， 那就得好好掰扯掰扯什么是测试周期， 提测打回的这期间算不算测试周期， 研发修 bug 的时间算不算测试周期， 部署环境的期间算不算测试周期。 在第四范式的后期的时候， 那个大老板请来的人才就是玩这种文字游戏愣是把测试效率在明面上提高了 7 倍。 再就是开启裁员 + 加班模式，大家玩了命的干，每天工作 12 小时，周末也加班（没加班费），生生的打排期打下来。
能立杆见影的都是上面这些方法，当然有些同学可能会说这好像也不是真的提升了效率了， 但大家觉得老板真的是关心效率么， 老板才不关心效率是不是真的提高了。 只要最后展示出来的数字显得效率提高了就可以了， 不管你是疯狂的加班还是用别的方法， 老板其实不关心。 老板关心的是成本， 是报表中冷冰冰的数字。 老板要看到的是测开比 1：xxx 的数字， 至于你是用疯狂的加班的形式去完成的， 还是把工作转移到其他角色上完成， 还是推脱掉了很多工作完成的，或者是真的通过技术手段和流程改进提升了效率，这些不重要。
所以很多聪明人的做法都是玩各种文字游戏和流程优化，也就是我上面说的这些立竿见影的方法， 然后找个说的过去的说辞（比如引入了什么技术， 引入了什么迭代模式）档在前面。 相信我，很多小领导都是这么玩的，只要给大老板看到的数字是漂亮的就可以了， 至于怎么堆到这个数字的，那就且看我怎么解释（瞎编）给你听。
其实真正关心效率的往往都是大头兵，因为大头兵才是那个在一线执行的人， 效率真的上去了大头兵们才不会那么痛苦。 这也是为什么我愿意长期的投入精力在提效上。真正的效率上的提升都是长期的积累，是量变引起质变的客观规律。
