🍅 点击文末小卡片 ,免费获取软件测试全套资料,资料在手,涨薪更快
基础篇
1. 什么是软件测试?
软件测试(Software Testing)的经典定义是:在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。简单来讲就是:软件测试人员验证软件是否满足用户的需求;
2. 软件测试的目的
- 提高软件的质量,其一方面是确认软件做了你所期望的事情,另一方面是确认软件以正确的方式来做了这个事件;
- 提供信息,比如提供给开发人员或程序经理的反馈信息,为风险评估所准备的信息;
- 软件测试不仅是在测试软件产品的本身,而且还包括软件开发的过程,如果一个软件产品开发完成之后发现了很多问题,这说明此软件开发过程很可能是有缺陷的。因此软件测试的第三个目的是保证整个软件开发过程是高质量的;
3. 软件测试与软件开发的区别?
(1) 技能要求专业度
- 软件开发:技能的要求专业度高,技能要求不广泛;要熟悉C/C++,Java,python,PHP等语言,以及相关框架Spring,Spring Boot等,构建工具maven,Gradle等;
- 软件测试:技能要求比较广泛,但是专业度不高;
【测试接口】soupUl, postman , jmeter
【性能测试】loadrunner,jmeter
【自动化测试脚本】Python,java,unittest,TestNg,Charles,fiddler,appium
(2) 软件测试和软件调试
目的不同:
软件测试就是验证软件是否实现了它应该实现的功能(需求);
软件调试的目的是软件开发人员验证软件是否实现了他(开发人员的角度)想让软件实现的功能;
角色不同:
测试是由开发人员(白盒测试)和测试人员共同完成;
调试是由开发人员完成;
阶段不同:
测试现在贯穿了整个软件开发的生命周期; 需求一>计划一> 设计一>编码一>测试一>运维
调试是在开发阶段;
概念篇
1. 什么是需求?
用户的期望和满足合同(文档,规则,标准)的规定所需要的条件和权限;
软件需求是用户需求转换而来的,它是用户需求的细化,是用户需求的具体实现细节和规范;
用户需求比较粗略,直接实现会有困难,因为没有细节,所以需要软件需求把用户需求细节实现和规范,把用户需求变成一个具体的可实现的过程文档;
2. 需求是软件测试的依据
验证需求,保证需求正确可实现,细化需求,从需求中提炼出一个一个的测试项;
以用户登陆为例,阐述下整个过程:
软件测试人员如何深入了解需求? 答:从用户需求分析阶段就开始介入了解需求,站在用户的角度;
3. 测试用例
测试用例(Test Case)是指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,最终形成文档。简单地认为,测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,用于核实是否满足某个特定软件需求;
测试点:用正确(已经注册)的手机号和密码登陆网易邮箱界面,登陆成功
测试用例
测试环境: Chrome版本99.0.4844.51 PC端 Windows系统
测试数据: 用户名: 134****2311 密码: *******
测试步骤: 1、 在浏览器打开邮箱URL: https://mail. 163.com/?msg= authfail#return
2、输入用户名和密码
3、点击登陆
预期结果: (操作完测试步骤后的结果)登陆成功
测试用例告诉我们测什么,怎么测
优点: 衡量需求的覆盖率(测试用例和需求对比); 复用性,借鉴意义; 可以用于回归测试; 防止遗漏测试需求;
4. 什么是BUG?
当且仅当,程序规格说明书(软件需求)存在并且合理,如果软件功能和软件规格说明书不相符合,我们就说是软件错误;当软件需求不存在,用户需求存在并且合理,软件功能和用户功能不相合,就说明是软件错误;软件测试的阶段: 整个软件开发的生命周期,需求阶段介入 验证需求的合理性和正确性;
5. 开发模型(5个模型)
软件开发的生命周期 : 需求分析一计划一 设计一 开发一 测试一 运行维护
(1)瀑布模型
特点 : 阶段性强,每一个阶段比较独立; 看重前期的需求分析和后期的测试
缺点 : 测试在编码后才开始介入,导致前期的问题后期才发现,会失去错误补救的机会
(2) 螺旋模型
适合于项目庞大,风险大,不是很明确项目
特点:强调每一个迭代的测试质量和风险分析
缺点:风险管控人力物力投入很多,成本比较大
(3)增量模型,迭代模型
同一个系统的四个模块 A B C D 两周
增量模型:第一周开发A B功能模块,第二周开发C D功能模块
迭代模型:第一周先开发A B C D的基础功能,第二周再在第一周的基础之上完全其它的功能
特点:抗击风险能力强;
(4)敏捷模型
个体与交互重于过程和工具;可用的软件重于完备的文档;客户协作重于合同谈判;响应变化重于遵循计划
特点:轻文档,轻流程,重目标,重产出
角色:
- PO:product owner,把用户需求转化成user story
- SM:scrum master项目经理,管理整个团队,负责敏捷流程顺利实施,各种会议
- ST:scrum team各种技能的人组成,开发,测试UI
scrum流程:
- 发布计划会议:产品经理收集需求形成userstory ,讲解,排出本迭代需要进行开发的userstory形成sprint backlog
- 迭代计划会议:分析用户故事,把userstory分解- 个个的任务, 分配开发人员,制定开发计划
- 每日站会:昨天干了什么,遇到的问题,今天的计划
- 产品演示会议:甲方,用户演示产品,PO把不足的地方收集成user story,下一次迭代改进
- 回顾计划会议:回顾整个迭代过程,把不足的地方找出,在下一次迭代过程中改进,优化迭代流程
6. 测试模型
(1)V模型
特点: 每一个阶段独立性强;左边每一个阶段都是右边测试阶段的依据;和右边阶段每一个测试阶段一一对应;
缺点:编码后才进行测试;前期的错误后期才会被发现,会失去错误即使补救的机会;
(2)W模型——双V模型
特点: 每一阶段独立性强;测试一开始就介入;可以保证前期的问题及时发现和纠正;测试和开发并行。
缺点:每一阶段都是串行的过程;一个阶段完了之后就进行下一个阶段;不支持敏捷(拥抱变化)开发
7. 软件测试的生命周期(软件测试流程)
需求分析——测试计划——测试设计/开发——测试执行——测试报告
需求分析:分析需求,验证需求的正确性、合理性;细化需求,根据需求去提炼测试点
测试计划:确定测试范围、目的、目标、测试人员、测试工具、时间、测试环境
测试设计/开发:开发测试用例
测试执行:开发人员已经提交了代码,执行测试,提交BUG
测试报告:对本次迭代的测试情况进行分析和总结;写了多少测试用例执行了多少;发现了多少BUG,修改了多少,剩余多少BUG没有解决;方案;测试的覆盖率
8. 如何描述一个BUG
(1)测试版本(代码提交版本号)
(2)测试环境:因为在不同测试环境问题出现的情况也不一样
(3)测试步骤:测试数据和执行测试的详细步骤,方便为开发人员复现问题
(4)实际结果
(5)预期结果(需求期望的结果)
(6)BUG产生时的log日志,错误截图等附件
9. BUG的级别
(1)崩溃
系统崩溃,不能运行,死循环,数据库死锁,资源分配不均,黑屏,闪退,阻塞。
线上(用户使用的环境)出现崩溃级别的BUG:回到上一个可稳定运行的历史版本
(2)严重
服务器可以用,但是不稳定,继续使用会产生严重的错误;一级菜单错误,数据库插入数据错误,威胁到用户的安全等
(3)一般
系统可以稳定的运行,次要的功能没有实现,提示语不完整,弹出框没有关闭按钮,不影响用户的使用
(4)建议(次要)
建议性的,提示信息重叠(看不清楚),界面排版不符合用户使用习惯,颜色不符合软件使用场景
10. BUG的生命周期
问题:发现一个BUG,开发人员修改了,通知测试人员验证,但是测试人员又复现了这个BUG,是哪些可能的原因引起的?
答:测试环境不一样;开发人员理解不到位,没有修改成功;代码在开发人员修改之后未进行远程提交代码,测试人员用旧版本(有问题的代码)进行测试
11. 测试人员因为一个BUG和开发人员发生冲突,该怎么做?
(1) 检查自己的BUG描述,是否描述清楚
(2)可以从用户的角度考虑,说服开发人员
(3)BUG定级要有理有据,符合公司规范
(4)测试人员要不断提升自己的专业技能和业务水平(权威性)
(5)找产品经理去讨论问题的解决方案
最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!凡事要趁早,特别是技术行业,一定要提升技术功底。