社区里大部分都是测试开发的分享，作为功能测试，我也分享下日常工作中功能测试值得吐槽的问题，由于工作时间不长且未进过大厂，不了解大公司的工作模式和流程，所以自己的方法和理解都是基于中小公司的工作经验总结，应该适用于跟我一样的小白，没有各种高大上的左右移动，测开大佬们轻喷。
这是一个工作日常经常需要回复的问题，理论上 测试这边要做出较科学合理的回复，那就要将
【需求变更】
【开发进度延误】
【bug 修复不稳定】
【复杂业务流程】
【测试环境不稳定】
【上下游服务依赖】
【人员资源】
【是否引入新技术】
【回归范围】
等等不确定因素考虑进去，再多方沟通确定才能获得相对合理的答案。但现实里 一个功能测试会同时测试几个项目，通常是最晚得知新需求的内容，需求评审会议都是被冷不丁拉入，然后产品劈里啪啦讲完后就让你给个测试时间，方便他安排工作。
临时进入会议，需要你马上给个估计时间场景：
流程较规范，测试先拿到需求文档进行评估：
注意：如果觉得系统很复杂，自己无法正确评估，拉上你的领导/组长一起判断，千万别不好意思或者觉得这样显得自己很差，我们是功能测试，要学会哭惨！，任务太难或者太多就让组长拉多一个人来帮忙。同时测试这边投入的人力数量需要告知下产品，防止那种一旦看到时间有盈余，就疯狂后期加需求的产品。
大多数功能测试的现状应该差不多，通常是测试着 A 任务，就接到 B 任务的需求评审，已上线的 C 任务现网出现了些问题反馈需要你跟进，然后测试组自动化的任务 D 也要完成进度，最后 C 任务根据用户的一些反馈做了功能整改，拉你评审和排期
需要当天确定的任务：
多个周期任务：
注意： 任务多顶不住就求救，别硬撑，看过应届生一个人测试着吃力不说，搞得老同事接锅加班的
这应该几乎是所有功能测试都会遇到的问题，主要分为三种：
(1). 一句话需求，甚至需求文档写在 txt 里，就一句话，eg:【充值满 XX 元获得奖励】（本人真实经历）
(2).抄袭的需求，同为差不多的功能，拿了其他产品的需求文档适当做了修改就发出给研发
(3).全文字需求，无流程图 无交互稿
情况一：（老实说这种类型的产品一般都是愣头青，你要是把需求文档打回去，通常情况下只是从一句话需求变成十句话需求，解决不了问题，你还是要在时间内完成测试）
情况二：（通常拿来主义的产品都是很懒的，同时没啥主见，甚至他会叫你去找他抄袭的那个产品聊，麻烦的点主要在于实际转测后发现功能实现与文档不一致，开发给的原因是其中的业务逻辑或用户需求不适用于当前项目）
情况三：（通常这类产品还挺固执，认为自己描述得很清楚）
注意：以上三种情况，务必都要告知自己的直属领导，同时减少和产品的私聊，多在大群里聊，多留刷锅的证据
线上出现 bug 时，大多第一时间会很慌，生怕是自己的锅，所以步骤很重要，一方面防止非自己的锅被人甩在身上，一方面要显得自己是个负责的成熟测试
注意： 遇到线上 bug，一定不要急着疯狂甩锅和叠 buff（这个在测试阶段时就要上的护甲，测试报告提示风险和大群聊天记录），要表现出先解决问题的态度，同时搜索对自己有利的条件。
造成测试时间压力的通常有以下几种：开发时间延期、产品上线日期提前【大 boss 给的压力】、需求变更、测试人力资源变动、测试物料阻塞、复杂的业务逻辑。通常遇到时间不足，最好的解决方式还是加人，其他的只能前期进行预防```
开发延期：喜闻乐见的情况，鉴于经验通常都是延期 1-0.5 天，所以测试时间评估一般都要在自己评估的时间上至少 +1 天，同时保持在开发转测时间的前一天问下开发进度的习惯。如果开发给了进度不乐观，及时同步给产品和测试领导，看产品是否可以调整时间或者领导这边加测试人力。将测试压力尽量提前告知，给测试领导和产品有调整分配的时间，不要依赖开发去反馈
产品上线日期提前：没有任何方法预防，一般大老板开口了，测试领导比你还紧张，会积极询问你测试进度情况和风险，你这边要是没把握，可以提出增加人力的要求。
需求变更： 需求变更也是很常见的，特别是都转测了，产品那逼还在每天优化更新他的需求文档。这里需要预防一个坑：你要截图保存他转测前的最后一次需求文档并发到大群 @ 相关人，防止后面现网出现需求不一致情况时，产品拿着他未同步且更新过的文档来兴师问罪。到时你百口莫辩，特别是测试地位比较低的公司，产品修改需求是不跟测试及时同步的。 时间上也以每次变动的大小产生的影响，记录在测试报告上，规避背锅的风险。
测试人力变动： 原本两个人测试的任务，因为其他原因变成一个人。这也是很常见的情况，特别是两个人当初分好了测试范围，你这边只了解和评估了自己的范围，对其他人那部分并不了解，无形之中增加了后期的测试压力和时间。这种情况通常没啥好的解决方法，记得要哭惨，要让测试领导和产品去协调。别一个人傻傻的硬撑疯狂加班
测试物料阻塞：电商类型的项目通常涉及一些消费券的申请和配置，同时这些券的使用还带风控判断。测试这边要根据情况，转测前提前沟通准备好测试物料，申请需要用的白名单和权限，熟悉好对应的配置系统。防止正式转测前，被一堆权限和申请的事情严重拖延到进度。
复杂的业务逻辑： 具体情况具体分析，根据经验，面对复杂的业务逻辑，最好的方法就是编写清晰、详细的测试用例。对自己要有 B 数，评审阶段感觉吃力就求救兵
* 用例执行困难，通常是开发质量差导致
常出现于前端开发，转测时给你的 mock 数据与实际现网数据结构不匹配，如果你是比较擅长 mock 数据和做代码 review 的，通常还挺容易踩这种坑，拿着这个错误的数据模板做了多个边界值和数据类型变化测试，代码对每个数据的处理逻辑也是正确的。然后发布到现网就报错无法交互
很多公司的业务通常都是未经探讨直接强行自动化的，UI 自动化能阻止就阻止，阻止不了就加入。对于接口/ui 自动化，老实说我一直觉得最好的提效方式就是找个市面上商业化的自动化平台工具，直接买来就用（面过一个国企，他们就是这样干的），都不用投入什么人力，付费工具那点钱对公司来说也不多，测试这边还能把精力放在业务上，有需求就给技术方提，这才是最好的提效方式。可惜现在都要抽出一部分人力去搞这种做完很少人用且不好用的平台，搞笑的是这些平台的技术难点都集中在前后端框架业务实现，反而能在业务中起到多大作用的考虑倒是最低的，基本还是走的请求返回再断言那套，或者更魔幻点的 UI 自动化都给你加上 AI 赋能寻找控件。。。。。其实大部分都是把实现过程复杂化，然后起作用的还是你用最原始的 pytest+request 组合去断言那套
