软件测试的目的和原则、开发模型、测试模型

目录

需求的概念

需求是测试人员开展软件测试工作的依据。

为什么需求对软件测试人员如此重要 

如何才可以深入理解被测试软件的需求 

测试用例的概念

软件错误(BUG)的概念

开发模型和测试模型

软件的生命周期

瀑布模型(Waterfall Model)

螺旋模型(Spiral Model)

增量、迭代

敏捷

scrum 

1、敏捷宣言: 

2、角色

3、迭代开发

4、流程

软件测试v模型 

流程·:

特点:

优点:

缺点:

软件测试W模型

流程:

W模型特点:

W模型优点:

局限性:

练习题:

描述测试用例的概念和要素。尝试写一个测试用例。

删除微信聊天记录功能是否正常

描述软件的生命周期以及各阶段可能涉及到的内容


需求的概念

满足用户期望或正式规定文档(合同、标准、规范)所具有的条件和权能,包含用户需求和软件需求。

用户需求:可以简单理解为甲方提出的需求,如果没有甲方,那么就是终端用户使用产品时必须要完成 的任务。该需求一般比较简略。

软件需求:或者叫功能需求,该需求会详细描述开发人员必须实现的软件功能。

需求是测试人员开展软件测试工作的依据。

在具体设计测试用例的时候,首先需要搞清楚每一个业务需求对应的多个软件功能需求点,然后分析出 每个软件功能需求点对应的多个测试需求点,然后针对每个测试需求点设计测试用例。

过程如下,业务需求—>软件功能需求点—>测试需求点—>测试用例

为什么需求对软件测试人员如此重要 

从软件功能需求出发,无遗漏的识别出测试需求是至关重要的,这将直接关系到用例的测试覆盖率 对于识别出的每个测试需求点,需要采用具体的设计测试用例的方法来进行测试用例的设计

如何才可以深入理解被测试软件的需求 

测试工程师在需求分析和设计阶段就开始介入,因为这个阶段是理解和掌握软件的原始业务需求的最好 时机。

只有真正理解了原始业务需求之后,才有可能从业务需求的角度去设计针对性明确,从终端用户的使用 场景到端到端的覆盖率较高的测试用例集。

测试用例的概念

测试用例(Test Case)是为了实施测试而向被测试的系统提供的一组集合,这组集合包含:测试环 境、操作步骤、测试数据、预期结果等要素。

测试用例解决了两大问题:测什么,怎么测。

测试过程中可能会遇到以下问题: –不知道是否较全面的测试了所有功能 –测试的覆盖率无法衡量 –对新 版本的重复测试很难实施 –存在大量冗余测试影响测试效率

测试用例的产生就是为了解决上述的问题

软件错误(BUG)的概念

当且仅当规格说明是存在的并且正确,程序与规格说明之间的 不匹配才是错误

当需求规格说明书没有提到的功能,判断标准以最终用户为准:当程序没有实现其最终用户合理预期的 功能要求时,就是软件错误

开发模型和测试模型

随着软件工程学科的发展,人们对计算机软件的认识逐渐深入。软件工作的范围不仅仅局限在程序编 写,而是扩展到了整个软件生命周期,如软件基本概念的形成、需求分析、设计、实现、测试、安装部 署、运行维护,直到软件被更新和替换新的版本。软件工程还包括很多技术性的管理工作,例如过程管 理、产品管理、资源管理和质量管理,在这些方面也逐步地建立起了标准或规范。

软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。 如果把软件看成是有生命的事 物,那么软件的生命周期可以分成6个阶段,即需求分析、计划、、设计、编码、测试、运行维护。

瀑布模型(Waterfall Model)

瀑布模型在软件工程中占有重要地位,是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一 次,因此是线性顺序进行的软件开发模式。

优点: –强调开发的阶段性; –强调早期计划及需求调查; –强调产品测试。

缺点: –依赖于早期进行的 唯一一次需求调查,不能适应需求的变化; –由于是单一流程,开发中的经验教训不能反馈应用于本产 品的过程; –风险往往迟至后期的测试阶段才显露,因而失去及早纠正的机会。

瀑布模型的一个最大缺陷在于,可以运行的产品很迟才能被看到。这会给项目带来很大的风险,尤其是 集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现,通常会导致前面阶 段的工作大面积返工,业界流行的说法是:“集成之日就是爆炸之日”。尽管瀑布模型存在很大的缺陷, 例如,在前期阶段未发现的错误会传递并扩散到后面的阶段,而在后面阶段发现这些错误时,可能已经 很难回头再修正,从而导致项目的失败。但是目前很多软件企业还是沿用了瀑布模型的线性思想,在这 个基础上做出自己的修改。例如细化了各个阶段,在某些重点关注的阶段之间掺入迭代的思想。

在瀑布模型中,测试阶段处于软件实现后,这意味着必须在代码完成后有足够的时间预留给测试活动, 否则将导致测试不充分,从而把缺陷直接遗留给用户。

螺旋模型(Spiral Model)

一般在软件开发初期阶段需求不是很明确时,采用渐进式的开发模式。螺旋模型是渐进式开发模型的代 表之一。

这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的 要求,它不允许有一段独立的测试时间和阶段,测试必须跟随开发的迭代而迭代。因此,回归测试的重 要性就不言而喻了。

优点: –强调严格的全过程风险管理。 –强调各开发阶段的质量。 –提供机会检讨项目是否有价值继续下 去。

缺点: –引入非常严格的风险识别、风险分析和风险控制,这对风险管理的技能水平提出了很高 的要求。这需要人员、资金和时间的投入 

增量、迭代

增量开发能显著降低项目风险,结合软件持续构建机制,构成了当今流行的软件工程最佳实践之一。增 量开发模型,鼓励用户反馈,在每个迭代过程中,促使开发小组以一种循环的、可预测的方式驱动产品 的开发。因此,在这种开发模式下,每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件 版本,意味着测试需要频繁进行,测试人员需要与开发人员更加紧密地协作。

增量通常和迭代混为一谈,但是其实两者是有区别的。增量是逐块建造的概念,例如画一幅人物画,我 们可以先画人的头部,再画身体,再画手脚……而迭代是反复求精的概念,同样是画人物画,我们可以 采用先画整体轮廓,再勾勒出基本雏形,再细化、着色。

敏捷

2001年,以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的“轻量”过程派 聚集在犹他州的Snowbird,决定把“敏捷”(Agile)作为新的过程家族的名称。 在会议上,他们提出了《敏捷宣言》(http://agilemanifesto.org/): 我们通过身体力行和帮助他人来 揭示更好的软件开发方式。经由这项工怍,我们形成了如下价值观。

由敏捷宣言可以看出,敏捷其实是有关软件开发的社会工程(Social Engineering)的。敏捷的主要贡献在 于他更多地思考了如何去激发开发人员的工作热情,这是在软件工程几十年的发展过程中相对被忽略的 领域。 敏捷开发有很多种方式,其中scrum是比较流行的一种。

scrum 

1、敏捷宣言: 

重沟通,轻流程 

重交付,轻文档

重协作,轻谈判

拥抱变化

2、角色

PO(产品经理):收集用户需求

SM(项目经理):协助整个项目顺利完成

Team(前端开发,后端开发,测试,设计)

3、迭代开发

与瀑布不同,scrum将产品的开发分解为若干个小sprint(迭代),其周期从1周到4周不等,但不会超过4 周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。

4、流程

 scrum的基本流程如上图所示:

产品负责人负责整理user story,形成左侧的product backlog。

发布计划会议:product owner负责讲解user story,对其进行估算和排序,发布计划会议的产出 就是制定出这一期迭代要完成的story列表,sprint backlog。

迭代计划会议:项目团队对每一个story进行任务分解,分解的标准是完成该story的所有任务,每 个任务都有明确的负责人,并完成工时的初估计。

每日例会:每天scrum master召集站立会议,团队成员回答昨天做了什么今天计划做什么,有什 么问题。

演示会议:迭代结束之后,召开演示会议,相关人员都受邀参加,团队负责向大家展示本次迭代取 得的成果。期间大家的反馈记录下来,由po整理,形成新的story。

回顾会议:项目团队对本期迭代进行总结,发现不足,制定改进计划,下一次迭代继续改进,已达 到持续改进的效果。

软件测试v模型 

流程·:

V模型最早是由Paul Rook在20世纪80年代后期提出的,目的是改进软件开发的效率和效果。是瀑布 模型的变种

明确的标注了测试过程中存在的不同类型的测试,并且清楚的描述了这些测试阶段和开发过程期间 各阶段的对应关系

V模型指出,单元和集成测试应检测程序的执行是否满足软件设计的要求;系统测试应检测系统功 能、性能的质量特性是否达到系统要求的指标;验收测试确定软件的实现是否满足用户需要或合同 的要求

局限性:仅仅把测试作为在编码之后的一个阶段,未在需求阶段就进入测试 

特点:

线性的

左边是开发。右边是测试

优点:

每个阶段做什么事情非常清晰

测试被划分成许多类型

缺点:

测试人员介入太晚

测试和开发是串行的

软件测试W模型

流程:

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成,分 别代表测试与开发过程,图中明确表示出了测试与开发的并行关系。

W模型特点:

测试的对象不仅是程序,需求、设计等同样要测试,测试与开发是同步进行的

W模型优点:

有利于尽早地全面的发现问题。例如,需求分析完成后,测试人员就应该参与到对需 求的验证和确认活动中,以尽早地找出缺陷所在。同时,对需求的测试也有利于及时了解项目难度 和测试风险,及早制定应对措施,显著减少总体测试时间,加快项目进度。

局限性:

需求、设计、编码等活动被视为串行的;测试和开发活动也保持着一种线性的前后关系, 上一阶段完全结束,才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复 杂多变的情况,W模型并不能解除测试管理面临着困惑 

练习题:

描述测试用例的概念和要素。尝试写一个测试用例。

测试用例是为了实施测试而向被测试的系统提供的一组集合这组集合包含:测试环境、操作步骤、测试数据、预期结果。

网页登录qq邮箱

测试环境:Chrome浏览器

操作步骤:打开浏览器,搜索QQ邮箱,输入帐号密码,点击登录。

测试数据: 帐号: 123456 @ qq.com

                   密码:123456.

预期结果:展现登陆成功的结果页,并且使用账号可以正常登录。

删除微信聊天记录功能是否正常

基本测试点:

(1)单条删除;

(2)全部删除

(3)清空聊天记录

(4)没有网络的情况下删除聊天记录

(5)弱网的情况下删除聊天记录

兼容性:

(1)测试不同的微信版本

(2)测试不同的手机系统(iOS,Android,包括不同安卓机不同品牌的机型)

性能:

  删除聊天记录时的速度(单条,全部,清空)

描述软件的生命周期以及各阶段可能涉及到的内容

软件的生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。如果把软件看成是有生命的事物,那么软件的生命周期可以分成6个阶段,即需求分析、计划、设计、编码、测试、运行维护。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值