【职言】三年功能测试，一些测试工作的“吐槽”，2024年最新GitHub标星8k

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

问题一：测试时间评估

这是一个工作日常经常需要回复的问题，理论上，测试这边要做出较科学合理的回复，那就要将【需求变更】、【开发进度延误】、【bug 修复不稳定】、【复杂业务流程】、【测试环境不稳定】、【上下游服务依赖】、【人员资源】、【是否引入新技术】、【回归范围】等等不确定因素考虑进去，再多方沟通确定才能获得相对合理的答案。但现实里，一个功能测试会同时测试几个项目，通常是最晚得知新需求的内容，需求评审会议都是被冷不丁拉入，然后产品劈里啪啦讲完后就让你给个测试时间，方便他安排工作

• 询问开发所用的时间，将测试时间设定为开发时间的 50%、70% 或 80%（根据现场氛围说自己的百分比）

• 编写完测试点，根据一条用例平均 5 分钟的时间，然后根据一天实际能干活的时间，例如用 6 小时去粗劣计算天数，越多越好（测试时间肯定会被压缩）

• 临时进入会议，需要你马上给个估计时间场景：

• 流程较规范，测试先拿到需求文档进行评估：

注意：如果觉得系统很复杂，自己无法正确评估，拉上你的领导/组长一起判断，千万别不好意思或者觉得这样显得自己很差，我们是功能测试，要学会哭惨！任务太难或者太多就让组长拉多一个人来帮忙。同时测试这边投入的人力数量需要告知下产品，防止那种一旦看到时间有盈余，就疯狂后期加需求的产品。

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：691998057【暗号：csdn999】

问题二：同一时间需要完成多项测试任务

大多数功能测试的现状应该差不多，通常是测试着 A 任务，就接到 B 任务的需求评审，已上线的 C 任务现网出现了些问题反馈需要你跟进，然后测试组自动化的任务 D 也要完成进度，最后 C 任务根据用户的一些反馈做了功能整改，拉你评审和排期。

• 紧急且重要、紧急但不重要、不紧急但重要、不紧急且不重要。四个级别分类任务，虽然老套，但是真的有用，事情一多时，人特别容易烦躁，这时候就需要一个指导思想

• 依据截止日期， 根据任务的截止日期制定计划。先处理最紧急的任务，确保不会因为延误而影响项目进度

• 需要当天确定的任务：

• 多个周期任务：

注意：任务多顶不住就求救，别硬撑，看过应届生一个人测试着吃力不说，搞得老同事接锅加班的。

问题三：需求不明确

这应该几乎是所有功能测试都会遇到的问题，主要分为三种：1. 一句话需求，甚至需求文档写在txt 里，就一句话，eg:【充值满 XX 元获得奖励】（本人真实经历）；2.抄袭的需求，同为差不多的功能，拿了其他产品的需求文档适当做了修改就发出给研发；3.全文字需求，无流程图，无交互稿。

• 测试这边辛苦些，拿上述一句话的例子【充值满 XX 元获得奖励】，列出不清晰的点：缺乏详细活动规则说明、奖励类型不明确、具体数值、活动触发条件、用户资格验证条件、界面展示交互、奖励发放的触发时机等。

• 与产品经理电话沟通，询问有关背景、业务目标、关键功能、用户期望等方面的问题，然后将列出的不清晰点发到大群并 @ 开发和产品，让其在文档里做补充。

• 千万别和产品私聊然后自己一个人确认需求，全部互动都要在大群。

• 转测后，让产品提前先体验，让产品先满意后再测试

• 其他参考情况1

• 解决方式基本和情况1一致

• 情况1：（老实说这种类型的产品一般都是愣头青，你要是把需求文档打回去，通常情况下只是从一句话需求变成十句话需求，解决不了问题，你还是要在时间内完成测试）

• 情况2：（通常拿来主义的产品都是很懒的，同时没啥主见，甚至他会叫你去找他抄袭的那个产品聊，麻烦的点主要在于实际转测后发现功能实现与文档不一致，开发给的原因是其中的业务逻辑或用户需求不适用于当前项目）

• 情况3：（通常这类产品还挺固执，认为自己描述得很清楚）

注意：以上三种情况，务必都要告知自己的直属领导，同时减少和产品的私聊，多在大群里聊，多留刷锅的证据。

问题四：线上出现 bug

线上出现 bug 时，大多第一时间会很慌，生怕是自己的锅，所以步骤很重要，一方面防止非自己的锅被人甩在身上，一方面要显得自己是个负责的成熟测试。

• 冷静点，群里先发一句：“我定位下，看能不能复现”

• 现网尝试复现bug，如果 bug 能百分百复现，@ 相关开发排查，并发出便于定位的相关的日志和信息

• 测试环境尝试复现，若能复现，查询下测试用例有无覆盖当前的场景【确保不是测试用例执行遗漏，执行遗漏和覆盖遗漏是两个不同的锅，执行遗漏是态度问题，很严重的】

• 如果是自己的锅，记得表现出积极解决问题的态度，配合开发检查修复状态，并同步到大群，要将 bug 出现的原因和修复方法了解清楚，方便后续做复盘和回答领导的询问。

• 如果是他人/环境的锅，要表现出超级积极解决问题的态度，将 bug 原因和修复情况实时同步到大群

• 通常都是群里忽然炸锅，截图出 bug 点，然后产品们叽叽喳喳

注意：遇到线上 bug，一定不要急着疯狂甩锅和叠 buff（这个在测试阶段时就要上的护甲，测试报告提示风险和大群聊天记录），要表现出先解决问题的态度，同时搜索对自己有利的条件。

问题五：测试报告风险规避

主要有几点：

1. 测试日报中，阻塞测试进度 bug、偶现 bug、p0 级未解决 bug 需要标红加粗放在测试报告醒目的地方。

2. 对于测试环境无法完美模拟现网环境的测试场景，需要在报告中标红加粗体现（风险多说不亏）。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
软件测试）**
[外链图片转存中…(img-vaaxRlLy-1713443912506)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！