先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7
深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新软件测试全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
如果你需要这些资料,可以添加V获取:vip1024b (备注软件测试)
正文
我们的项目测试流程一般需要,制定测试计划,编写测试用例,执行测试用例,输出测试报告等工作,我们可以根据流程中的各个阶段来进行划分。
不同的人员负责不同测试阶段的工作。
优点:
1、流程清晰,就像瀑布试项目开发流程,不同阶段的工作由不同的人员担任。
2、划分流程的每个阶段难易程度和所需要的技能。
编写测试计划人员需要对整个项目的工作时间、资源分配,测试内容,实施过程有整体的把控能力。
用例辨析人员,需要对项目需求,测试方法,测试点有深入的了解。
用例执行人员需要细心,使用缺陷系统,沟通,协助研发定位缺陷。
输出测试报告人员需要对项目的测试过程,缺陷数量,类型,分布。用例执行请况等进行统计。也可以由测试执行人员担任。
按项目模块划分
对中大型的项目,这种划分就非常必要了,项目的模块非常多,功能也非常多。不同的测试人员负责不同模块的功能,这样会使用测试工作变得更加清晰。
1、人员利用率高,为什么这么说呢? 不同的人员负责的功能不一样。工作就不会存在交叉与重复。
2、更容易挖掘深度缺陷,假如A人员今天测试这个功能,明天测试那个功能,他就不可以对被测功能内部逻辑与业务有深入有了解。找到的也只是很表面的缺陷。那么如果一个人员长期负责一个模块的功能,那么就会更容易发现更有深度的缺陷。而往往深度的缺陷是致命的。
按照测试类型分工
我们知道软件除了功能需要测试以外,软件在编码阶段需要单元测试,接口测试等,在系统测试阶段,为提高功能测试的效率,可能对某些模块进行功能自动化,我们还要考虑软件的性能、安全性等问题。这些类型也是我项目中最常见的分类。我们可以根据这些类型为测试人员分配测试工作。当然,其专业性对测试人员的要求也比较高。
这种分工方式的特点。
1、专业技能要求较高,在这些分类中除了手工测试要求较低外(表面看是这样的),其它分类都需要较高的专业技能。例如,安全性测试需要掌握网络协议,编程技术,脚本攻击,SQL注入,漏洞分析等方面的技能。
2、不同分类之间交互性低,正国为不同分类需要的技能不同,虽然同为“测试”工作,但一个做单元测试的人就无法让其去做性能测试。
上面分类方式的疑问
看了上面的几种分工方式,你是不是每一种测试人员分工方式都似曾相识,但又没有哪个公司是单一的按照上述某种分工作方式工作。
拿笔者目前所在的公司,是一个长期的互联网产品,产品功能比较多,每位测试人员负责不同的功能模块,测试员人员从测试计划到测试报告都基本由一个人来完成。当然对于比较大和紧急的版本迭代,也会多人协作对版本进行测试(协作的方式一般更将版本功能再次细分到每个人员身上)。安全测试由专业的安全人员指导功能测试人员对自己负责的功能进行安全扫描与分析。有独立的性能测试小组,对需要进行性能的产品版本进行性能测试。在独立的功能自动化人员,对于适合自动化的功能进行自动化工作。
笔者公司的分工作方式几乎包括了上面所有的分工方式。那么,我为什么要进行上面那么单一的分工方式划分呢?这样有助于我们理清对测试工作的各种分工方式。在实际的工作中,有大型项目,有小型项目,有客户端软件,也有互联网产品,有短到几天的项目,也有“永久”性的项目。有一次开发完成交付的,也有不段迭代更新的。根据项目的情况,我们可以可以选择合适的分工方式来应用于项目中。
投入人员与发现缺陷的关系
在人员分工时,这也是一个必须也要考虑问题,对一个项目,投入的人员数量,投入的时间,与发现缺陷的数量有密切的关系。
投入时间与发现缺陷的关系:
在人员一定的情况下,投入的时间越多,发现的缺陷越多。但有一个规律,越到后期发现的新缺陷越少。假设软件总缺陷为100个,第一周发现50个问题,第二新发现20个,第二周可能只发现10个新缺陷。而且一个必然的结果是,测试不可能发现所有的缺陷。
投入人员数量与缺陷的关系:
在时间一定有的情况下,投入的人员越多,发现的问题越多,从图中可以看出,投入的人员越多,人员发现缺陷的重叠度越高。当然,你可以说,把每个人员要测试的内容划分清晰就不会重叠了。做为一个系统的各个功能模块,他们之间肯定存在必然的联系。有可能A人员在测试时会涉及到B人员测试的功能,并且发现了问题,不管是告诉B缺陷还是A人员直接提交缺陷(当然,你也可以装作没看到,等着B去发现),这都算不可避免的重叠。
当然了,划分更清晰的任务有效的降低重叠度。同步也降低了发现缺陷的数量,提高项目风险。除非投入更多的时间测试。这之间的关系,需要测试管理者认真去权衡。
在项目不紧急测试时间充分的情况下,可以投入更少的人员,延长测试时间发现更多的缺陷。 在项目紧急的情况下,需要投入更多的人员测试,以便尽快的发现更多的缺陷。在项目质量要求很高的情况下需要投入更多的人员与时间进行测试。在测试时间少,项目质量要求不高的情况下,可以投入较少的人员与时间进行测试。
--------------------------------------------------------------------------------------
本文结束,但还有许多问题我没有讲清楚(或者,我目前还说不清楚)。
1、A人员发现了b功能模块的缺陷(b模块由B人员负责测试)应该如何处理? 自己提缺陷单 ,告诉B人员,让B人员提单。直接忽视,等着B测试人员去发现。
2、项目紧急情况,人员投入,时间投入,某些情况下,考虑某些模块不进行测试。
3、测试人员的发展职业发展,这与测试人员的分工有着密切的联系。
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
需要这份系统化的资料的朋友,可以添加V获取:vip1024b (备注软件测试)
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
朋友,可以添加V获取:vip1024b (备注软件测试)**
[外链图片转存中…(img-Qgs1FoTO-1713609245334)]
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!