测试人员验证软件的功能是否满足用户的需求
验证功能是否能够正常运行
补充:
用户包括使用软件的人、出资的甲方(购买软件的人)、流量用户
定义区别
软件开发:用程序开发的方式把用户的需求实现成一个软件(网页,app,小程序等)
软件测试:测试人员进行测试,查看该程序是否满足需求,是否运行正常
难易程度
软件开发:要求技能集中,专业度高
软件测试:技能广泛,专业度相较于开发来说低
目的不同
软件调试:程序员验证软件是否实现了他自己想要让软件实现的功能
软件测试:测试人员验证软件是否实现了用户的需求
角色不同
软件调试:开发人员
软件测试:测试人员和开发人员
阶段不同
软件调试:开发阶段
软件测试:贯穿了整个软件开发过程中,处处都有软件测试
软件测试
通过手工或者自动化来验证软件功能的正确性
软件测试开发
也属于测试工程师,和纯测试不同的是,需要有一定的代码编写能力,能够写开发测试工具,开发测试脚本来帮助提高测试的效率
需要有较好的沟通能力,学习能力,开发能力,文字描述能力
需要有测试用例的编写能力,自动化测试能力
需要对这一份事业保持好奇心,要感兴趣
责任感强大,抗压力强
拥有着探索性思维,发散性思维,不被条条框框束缚
对问题总能够保持着怀疑的态度,批判性思维
满足用户的期望或者合同规定的文档(标准,规定,合同)所需要的条件和权限
用户需求和软件需求
用户需求可以简单理解为甲方要求或者是终端使用用户使用产品时必须要完成的任务。一般比较粗略,直接实现会有困难,缺乏细节
软件需求是用户需求转化而来的,需要把用户需求细节实现和规范,使得用户需求变成一个具体可实现的过程文档
软件需求是测试人员进行测试工作的基本依据
测试用例就是向被测试系统发起的一组集合,包含测试环境,测试数据,测试步骤,预期结果(用例编号,测试概述,重要性,优先级,操作方式,前置条件…)
测试用例告诉我们测试的对象,测试的方法
存在意义
衡量需求的覆盖率(测试用例和需求的对比)
可复用(验证功能相同或类似的模块,加快测试效率)
方便后人借鉴
可以用于回归测试(修改了旧代码后,重新进行测试以确认修改没有引入新的错误或者导致其他代码产生错误)
防止遗漏测试需求
当且仅当,程序规格说明书(软件需求)存在并且合理,如果软件功能和软件规格说明书不相符合,就是软件错误(BUG)
当软件需求不存在的时候,用户的需求存在并且合理,软件功能和用户需求不相符合,就是软件错误(BUG)
软件开发的生命周期指的是软件产品从设想开始到软件不再使用而结束的时间,主要分成6个阶段
需求分析——计划——设计——开发——测试——运行维护
(1)瀑布模型
start——需求分析——计划——设计——编码——测试——end
瀑布模型是线性顺序进行的软件开发模式,是所有其他模型的基础框架,每个阶段都只会执行一次
特点
强调开发的阶段性,每一个阶段比较独立
强调早期计划及需求调查
强调产品测试
缺点
依赖于早期进行的唯一一次需求调查,不能适应需求的变化
由于是单一流程,开发的经验教训不能反馈应用于本产品的过程
分险往往会延迟到后期的测试阶段才会显露,因而失去及时纠正的机会
(2)螺旋模型
螺旋模型适合于项目庞大,风险大,需求不是很明确,采用渐进式开发的项目
特点
强调每一个迭代的测试质量和风险分析
强调各个开发阶段的质量
提供机会会检讨项目是否还有价值继续下去
缺点
风险管控人力物力投入很多,成本比较大
(3)增量、迭代
增量模型和迭代模型非常的类似,能够显著降低项目的风险,鼓励用户反馈,在每个迭代过程中,促使开发小组以一种循环的、可预测的方式驱动产品的开发。
每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本,意味着测试需要频繁进行,测试人员需要与开发人员更加紧密地协作
两者区别
增量是逐块建造的概念(同一个项目分成A、B、C、D四个模块,先做A、B模块,再做C、D模块)
迭代是反复求精的概念(同一个项目分成A、B、C、D四个模块,先开发四个模块的基础功能,再在这个基础上细化其他的功能)
(4)敏捷模型
特点:
个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
轻文档,轻流程,重目标,重产出
敏捷开发中的 scrum 方式:
scrum方式是较为流行的敏捷开发方式
角色安排
产品经理(product owner即PO):负责整理用户故事(user story),定义其商业价值,对其进行排序,制定发布计划,对产品负责
项目经理(scrum master即SM):负责召开各种会议,协调项目,为研发团队服务
研发团队(team):研发团队则由不同技能的成员组成,紧密协同,完成每一次迭代的目标,交付产品
scrum 的基本流程:
发布计划会议:产品经理收集需求形成user story,并对其进行讲解,对其进行估算和排序,制定出这一期迭代要完成的 story 列表形成产品清单(sprint backlog)
迭代计划会议:项目团队对每一个 story 进行任务分解。分解的标准是完成该story的所有任务,每个任务都有明确的负责人,并完成工时的初估计
每日站会:每天项目经理召集站立会议,团队成员回答昨天做了什么今天计划做什么,有什么问题
演示会议:迭代结束之后,召开演示会议,团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来,由产品经理整理,形成新的story,下一次迭代改进
回顾会议:项目团队对本期迭代进行总结,发现不足,制定改进计划,下一次迭代继续改进,已达到持续改进的效果
(1)V模型
特点
每个阶段独立性强,明确的标注了测试过程中存在的不同类型的测试
左边每一个阶段是右边测试阶段的依据,两者一一对应
缺点
相当于瀑布模型的变种
编码后才进行测试,前期的错误后期才会发现,会失去错误及时纠正的机会
(2)W模型
特点
每个阶段独立性强。软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成,分别代表测试与开发过程
测试一开始就介入,保证前期的问题及时发现和纠正
测试的对象不仅是程序,需求、设计等同样要测试,测试和开发并行
缺点
每个阶段都是串行的过程,上一个阶段完后才进行下一个阶段
因其串行的特单,无法适应需求变化,不支持敏捷开发
作者:富春山居_ZYY
原文链接:https://blog.csdn.net/weixin_46103589/article/details/124648884