先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7
深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新软件测试全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
如果你需要这些资料,可以添加V获取:vip1024b (备注软件测试)
正文
大多数功能测试的现状应该差不多,通常是测试着 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(这个在测试阶段时就要上的护甲,测试报告提示风险和大群聊天记录),要表现出先解决问题的态度,同时搜索对自己有利的条件。
问题五:测试报告风险规避
主要有几点:
-
测试日报中,阻塞测试进度 bug、偶现 bug、p0 级未解决 bug 需要标红加粗放在测试报告醒目的地方。
-
对于测试环境无法完美模拟现网环境的测试场景,需要在报告中标红加粗体现(风险多说不亏)。
-
测试进度根据测试用例执行的百分比来写。
问题六:测试时间不足
造成测试时间压力的通常有以下几种:开发时间延期、产品上线日期提前【大 boss 给的压力】、需求变更、测试人力资源变动、测试物料阻塞、复杂的业务逻辑。通常遇到时间不足,最好的解决方式还是加人,其他的只能前期进行预防。
- 开发延期:喜闻乐见的情况,鉴于经验通常都是延期 1-0.5 天,所以测试时间评估一般都要在自己评估的时间上至少 +1 天,同时保持在开发转测时间的前一天问下开发进度的习惯。如果开发给了进度不乐观,及时同步给产品和测试领导,看产品是否可以调整时间或者领导这边加测试人力。将测试压力尽量提前告知,给测试领导和产品有调整分配的时间,不要依赖开发去反馈。
- 产品上线日期提前:没有任何方法预防,一般大老板开口了,测试领导比你还紧张,会积极询问你测试进度情况和风险,你这边要是没把握,可以提出增加人力的要求。
- 需求变更:需求变更也是很常见的,特别是都转测了,产品那逼还在每天优化更新他的需求文档。这里需要预防一个坑:你要截图保存他转测前的最后一次需求文档并发到大群 @ 相关人,防止后面现网出现需求不一致情况时,产品拿着他未同步且更新过的文档来兴师问罪。到时你百口莫辩,特别是测试地位比较低的公司,产品修改需求是不跟测试及时同步的。时间上也以每次变动的大小产生的影响,记录在测试报告上,规避背锅的风险。
- 测试人力变动:原本两个人测试的任务,因为其他原因变成一个人。这也是很常见的情况,特别是两个人当初分好了测试范围,你这边只了解和评估了自己的范围,对其他人那部分并不了解,无形之中增加了后期的测试压力和时间。这种情况通常没啥好的解决方法,记得要哭惨,要让测试领导和产品去协调。别一个人傻傻硬撑疯狂加班。
- 测试物料阻塞:电商类型的项目通常涉及一些消费券的申请和配置,同时这些券的使用还带风控判断。测试这边要根据情况,转测前提前沟通准备好测试物料,申请需要用的白名单和权限,熟悉好对应的配置系统。防止正式转测前,被一堆权限和申请的事情严重拖延到进度。
- 复杂的业务逻辑:具体情况具体分析,根据经验,面对复杂的业务逻辑,最好的方法就是编写清晰、详细的测试用例。对自己要有 B 数,评审阶段感觉吃力就求救兵。
问题七:用例执行困难
用例执行困难,通常是开发质量差导致
- 目前感觉最好的办法:转测前,出一份冒烟用例给开发,通过冒烟用例后才能转测,否则主流程测试阻塞,只要代码有大改动,基本都要重新测。测试地位比较低的公司,可以把这个流程安利给测试领导和产品,让领导去推动
问题九:测试数据陷阱
常出现于前端开发,转测时给你的 mock 数据与实际现网数据结构不匹配,如果你是比较擅长 mock 数据和做代码 review 的,通常还挺容易踩这种坑,拿着这个错误的数据模板做了多个边界值和数据类型变化测试,代码对每个数据的处理逻辑也是正确的。然后发布到现网就报错无法交互。
- 对开发要保持怀疑的态度:验证环节需要接入现网数据去看测试页面的响应是否正确。
问题十:业务自动化实现
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
需要这份系统化的资料的朋友,可以添加V获取:vip1024b (备注软件测试)
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
软件测试)**
[外链图片转存中…(img-Hk4f13oV-1713443888427)]
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!