软件测试(英语:Software Testing),描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说,软件测试是一种实际输出与预期输出之间的审核或者比较过程。
通俗的来讲,“软件测试”就是软件测试人员验证软件是否满足用户的需求。最终交付的产品是否和用户本来的需求一致,如果不一致,需要找出不一样的点提交给开发进行修复改善,测试人员在测试过程中找出的问题统称为“Bug”。
软件测试的经典定义是:在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。
所谓“(Bug)”,是指电脑系统的硬件、系统软件(如操作系统)或应用软件(如文字处理软件)出错。硬件的出错有两个原因,一是设计错误,一是硬件部件老化失效等。
软件的Bug:狭义概念是指软件程序的漏洞或缺陷,广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。仅就狭义概念而言,软件出现Bug的原因有:
对各种流程分支考虑不全面;对边界情况的处理不到位;编码时的手误。
任何软件在发布时都不可能是绝对的零Bug。在软件过程管理中通行的CMM(能力成熟度模型)中规定的软件质量标准是(Bug个数/千行源码):
CMM1级 11.95、CMM2级 5.52、CMM3级 2.39、CMM4级 0.92、CMM5级 0.32
当且仅当,程序规格说明书(软件需求)存在并且合理,如果软件功能和软件规格说明书不相符合,我们就说是软件错误。当软件需求不存在,用户需求存在并且合理,软件功能和用户功能不相符合,就说明是软件错误;软件测试的阶段:整个软件开发的生命周期,需求阶段介入 验证需求的合理性和正确性。
①技能要求专业度:
软件研发:技能的要求专业度高,技能要求不广泛,需极强的代码基础
编程语言:Java、C、JavaScript、C++、Go、R、HTML 以及 C# 和 SQL
软件测试:技能要求比较广泛,但是专业度不高,无硬性代码基础
接口测试:soupUl, postman , jmeter
性能测试:loadrunner jmeter
自动化测试脚本:Python java unittest TestNg Charles fiddler appium
②软件测试和软件调试
目的:软件测试就是验证软件是否实现了它应该实现的功能(需求)软件调试的目的是软件开发人员验证软件是否实现了“开发”想让软件实现的功能。
角色:测试是由开发人员(白盒测试)和测试人员共同完成,调试是由开发人员完成。
阶段:测试现在贯穿了整个软件开发的生命周期:
需求一>计划一> 设计一>编码一>测试一>运维调试是在开发阶段
用户的期望和满足合同(文档,规则,标准)的规定所需要的条件和权限。软件需求是用户需求转换而来的,它是用户需求的细化,是用户需求的具体实现细节和规范。
用户需求比较粗略,直接实现会有困难,因为没有细节,所以需要软件需求把用户需求细节实现和规范,把用户需求变成一个具体的可实现的过程文档。
验证需求,保证需求正确可实现,细化需求,从需求中提炼出一个一个的测试项。以用户登陆为例,阐述下整个过程:
软件测试人员如何深入了解需求? 答:从用户需求分析阶段就开始介入了解需求,站在用户的角度。
测试用例就是向被测试系统发起的一组集合,包含测试环境,测试数据,测试步骤,预期结果,(重要性、优先级、操作方式、标题等)
如图:测试点:用正确(已经注册)的账号和密码登陆知乎界面,登陆成功
测试用例:所测试的项目标题
测试环境:Chrome版本99.0.4844.51 PC端 Windows系统
测试数据:用户名:QingshengRuanjianCeshi 密码: *******
测试步骤:
1.在浏览器打开网页URL:https://www.zhihu.com/
2.输入用户名和密码
3.点击登陆
预期结果:(操作完测试步骤后的结果)登陆成功
测试用例告诉我们测什么,怎么测,该测哪些。
优点:衡量需求的覆盖率(测试用例和需求对比):复用性,借鉴意义; 可以用于回归测试; 防止遗漏测试需求。
软件开发的生命周期 : 需求分析一计划一 设计一 开发一 测试一 运行维护
(1)瀑布模型
瀑布模型在软件测试工程中占有重要地位,是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次,因此是线性顺序的软件开发模式。
特点:阶段性强(强调开发的阶段性、强调早期计划及需求调查、强调产品测试),每一个阶段比较独立; 看重前期的需求分析和后期的测试
缺点:易串行有去无回,测试介入晚,导致项目前期的问题到后面才发现,失去了错误及时修正的机会、不支持项目频繁变动
(2)螺旋模型
适合于项目庞大,风险大,不是很明确项目,一个项目分多层小迭代。
特点:强调每一个迭代的测试质量和风险分析。适合风险比较大并且整个项目也比较庞大,每一个迭代做风险分析,讨论项目是否有价值继续。
缺点:风险管控人力物力投入很多,风险分析要求很高,需要投入专业人员,导致时间,项目支出成本费用比较高。风险对比对测试人员和开发人员要求比较高。
(3、4)迭代、增量模型
前置:4周时间开发 系统的A模块,B模块,C模块,D模块的功能
增量:
第一周完成A模块;
第二周完成B模块:
三周完成C模块:
第四周完成D模块:
迭代:
第一周完成A B C D四个模块的基础框架部分,
第二周完成基础功能的开发和测试,
第三周进一步开发复杂的功能,
第四周完善细节;
特点:抗击风险能力强
(5)敏捷模型(常用)
注重和客户的沟通,整个研发团队有效沟通,注重产品的质量,注重产品规定的交付日期;(拥抱变化,客户可以在项目开发过程中改变需求)
敏捷开发周期很短(1~4周时间),团队研发人员少;
特点:重目标、重产出、轻文档、轻流程;
举例说明:Scrum流程:
角色解析:
PO(product Owner)产品经理:负责整理用户需求,形成userstory;
SM(scurm Master)项目经理:负责保证整个敏捷开发流程的顺利实施,开发和各种协调等;
ST(scrum team)研发团队:负责整个项目的研发,各种技能的人组成,测试、开发、UI设计等;
发布计划会:产品经理需求整理成userstory,形成product backlog,会议上讨论userstory的重要性排版,决定本期迭代要开发的userstory;
迭代计划会议:研发团队确认迭代任务,分解userstory,将userstory分解成为一个个的任务,确定任务完成的时间,具体的人员等;
每日站会:(重点在于总结和解决出现的问题,以及了解整个研发的进展)解决三个问题:昨天完成了什么?解决了什么问题?今天的计划;
产品展示会议:给客户和Boss演示产品研发的成果,PO整理后形成新的userstory,放到下一次的迭代中;
项目总结:总结这个迭代的优缺点,不足的改进,优化这个敏捷开发流程;
软件测试V模型:
特点: 每一个阶段独立性强;左边每一个阶段都是右边测试阶段的依据;和右边阶段每一个测试阶段一一对应。
缺点:编码后才进行测试;串行的过程,测试是在编码后有的,测试的介入比较晚导致前期的错误后期才发现,后期测试发现时,已经失去了错误及时纠正的最好时机。
软件测试W模型:又称双V模型
特点: 每一阶段独立性强;测试一开始就介入;可以保证前期的问题及时发现和纠正;测试和开发并行。
缺点:每一阶段都是串行的过程;一个阶段完了之后就进行下一个阶段。不适合需求频繁变更的项目,不支持敏捷(拥抱变化)开发。
需求分析——测试计划——测试设计/开发——测试执行——测试报告
去求分析:分析需求,验证需求的正确性、合理性;细化需求,根据需求去提炼测试点
测试计划:确定测试范围、目的、目标、测试人员、测试工具、时间、测试环境
测试设计/开发:开发测试用例
测试执行:开发人员已经提交了代码,执行测试,提交BUG
测试报告:
对本次迭代的测试情况进行分析和总结;
写了多少测试用例执行了多少;
发现了多少BUG,修改了多少,剩余多少BUG没有解决;
方案;测试的覆盖率;上线风险评估
举例场景:注册功能,密码长度是8~18个字符,但输入1个字符时,也能注册成功
标题:注册时密码输入1位字符,提示注册成功
测试版本(代码提交版本号):代码版本号Qs1001
测试环境:Chrome浏览器 版本号96.0.4664.45(因为在不同测试环境问题出现的情况也不一样)
操作系统:Windows10,电脑品牌型号联想xx型号
测试数据:账号;[email protected]、密码;1
测试步骤:测试数据和执行测试的详细步骤,方便为开发人员复现问题
(打开注册页面输入邮箱账户填写密码点击同意条款点击注册)
实际结果:注册成功
预期结果(需求期望的结果):注册成功注册失败,提示“密码长度不符合规则”BUG的级别,附件(截图,错误日志)BUG产生时的log日志,错误截图等附件:
描述BUG 的要素:测试环境,测试数据,测试步骤,预期结果,实际结果,附件(错误,错误日志),等级,标题
致命错误:系统崩溃,不能运行,死循环,数据库死锁,资源分配不均,黑屏,闪退,阻塞。线上(用户使用的环境)出现崩溃级别的BUG:回到上一个可稳定运行的历史版本即可
严重错误:服务器可以用,但是不稳定,继续使用会产生严重的错误;一级菜单错误,数据库插入数据错误,威胁到用户的安全等
一般错误:系统可以稳定的运行,次要的功能没有实现,提示语不完整,弹出框没有关闭按钮,不影响用户的使用
次要(建议):建议性的,提示信息重叠(看不清楚),界面排版不符合用户使用习惯,颜色不符合软件使用场景
提问:当测试员发现一个Bug提交给开发员后修改,开发员通知测试员验证,但是测试员又复现了这个Bug,是哪些可能的原因引起的?
回答:测试环境不一样;开发人员理解不到位,没有修改成功;代码在开发人员修改之后未进行远程提交代码,测试人员用旧版本(有问题的代码)进行测试
检查自己的BUG描述,是否描述清楚
可以从用户的角度考虑,说服开发人员
BUG定级要有理有据,符合公司规范
测试人员要不断提升自己的专业技能和业务水平(权威性)
找产品经理去讨论问题的解决方案
答:一名优秀的软件测试人员应具备良好的沟通能力,编程能力,学习能力,自动化开发能力,编写测试用例的能力。首先对于软件测试,我非常感兴趣,我认为做一个十分优秀的测试人员也是非常不容易的;我学了点关于开发的技能, 能在以后作为一个专业的测试人员与开发人员沟通过程中会更容易点。其次现在一个软件产品的问世,也离不开软件测试,在平常的工作学习生涯中,我具有强烈的责任感和压力并且善于发现探索新事物,对日后的职业生涯肯定会有很大的促进作用。
现在我邀请你进入我们的软件测试学习交流群:【
746506216
】,备注“入群”, 大家可以一起探讨交流软件测试,共同学习软件测试技术、面试等软件测试方方面面,还会有免费直播课,收获更多测试技巧,我们一起进阶Python自动化测试/测试开发,走向高薪之路。
最后感谢每一个认真阅读我文章的人,看着粉丝一路的上涨和关注,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走…
这些资料,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!凡事要趁早,特别是技术行业,一定要提升技术功底。希望对大家有所帮助…….