软件测试的相关概念

软件测试的概念:

验证软件功能是否满足用户的需求

需求:你的期望
概念有两层意思:
1.找Bug
2.验证软件是正确的

  • 软件的概念没有错与对,只是在每个不同的阶段有不同的解释
软件测试的发展

1.软件调试
2.独立的软件测试(1950~)
3.软件测试的第一次定义(1973~),软件测试就是对程序能够按预期的要求运行建立起一种信心
4.软件称为专门的学科(1980~)
5.开发与测试的融合(2000~)

  • 许多人会把调试当做成软件测试,但其实两者是完全不同的两个概念

测试与调试的区别:

1.目的不同

测试–发现程序中的缺陷
调试–定位并解决程序中的问题

2.参与角色不同

测试–主要由测试人员的研发人员完成,黑盒测试主要由测试人员完成,单元/集成测试主要由开发人员执行
调试–由开发人员完成

3.执行的阶段不同

测试–贯穿整个软件开发生命周期
调试–一般在开发阶段和集成阶段

软件测试的目的

验证软件有或没有问题

软件测试的原则

以客户为中心,遵循软件测试的规范、流程、标准和要求

质量管理的八项原则:

1.以顾客为关注焦点

组织依存于他们的顾客,因而组织应理解顾客当前和未来的需求,满足顾客需求并争取超过顾客的期望

2.领导作用

领导者建立组织相互统一的宗旨、方向和内部环境。所创造的环境能使员工充分参与实现组织目标的活动

3.全员参与

各级人员都是组织的根本,只有他们的充分参与才能使他们的才干为组织带来收益

4.过程方法

将相关的资源和活动作为过程来进行管理,可以更高效地达到预期的目的

5.管理的系统方法

针对指定的目标,识别、理解并管理一个由相互联系的过程所组成的体系,有助于提高组织的有效性和效率

6.持续改进

持续改进是一个组织永恒的目标

7.基于事实的决策方法

有效的决策是建立在对数据和信息进行合乎逻辑和直观的分析基础上

8.与供方互利的关系

组织和供方之间保持互利关系,可增进两个组织创造价值的能力

什么是需求??

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

  • 用户需求:该需求一般比较简略。

  • 软件需求:或者叫功能需求,该需求会详细描述开发人员必须实现的软件功能。软件需求是测试人员进行测试工作的基本依据。

例:
用户需求
你和爸爸说:“我想买手机。”—这是一个用户需求,比较简略
软件需求
需要爸爸和你反复的沟通了解更加详细具体的需求,来指定解决方案
比如爸爸问你:“想买那个牌子的?”
你说:“某某牌子。”

问题:有一个声控灯,说一下你对这个灯的需求
有的人可能会说声音大于多少分贝灯会亮等等。
但其实这个问题问的就有错误。首先没有说这个声控灯是要安装在哪里,范围太广,需要与用户进行沟通,将用户需求转为软件需求
注:
1.需求要有范围
2.需求不一定是对的,要对需求也进行测试

什么是Bug??

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

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

什么是测试用例??

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

  • 测试用例就是为了解决测试过程中可能遇到如下的问题
    1.不知道是否较全面的测试了所有功能
    2.测试的覆盖率无法衡量
    3.对新版本的重复测试很难实施
    4.存在大量冗余测试影响测试效率

软件的生命周期可以分成6个阶段:需求分析、计划、设计、编码、测试、运行维护

开发模型

瀑布模型

适合需求较为稳定的,变更少的
串行的

螺旋模型

采用渐进式的开发模式
对于那些规模庞大、复杂度高、风险大的项目尤其适合

增量、迭代

降低项目风险

敏捷

个体与交互重于过程和工具—人与人之间的沟通
可用的软件重于完备的文档—对文档的依赖度不高了
客户写作重于合同谈判———客户参与开发过程
响应变化重于遵循计划———拥抱变化

敏捷开发有很多种方式,其中scrum是比较流行的一种。
scrum里面的角色

  • Product owner(类似产品经理):负责整理user stroy(用户故事),定义其商业价值,对其进行排序,制定发布计划,对产品负责

  • Scrum master(类似项目经理)敏捷教练:负责召开各种会议,协调项目,为研发团队服务

  • Team(研发团队):由不同技能的成员组成,通过紧密协同,完成每一次迭代的目标,交付产品
迭代开发

与瀑布不同,scrum将产品的开发分解为若干个小迭代,其周期从1周到4周不等,但不会超过4周。

Scrum的基本流程:

产品负责人负责整理user story,形成product backlog
发布计划会议
迭代计划会议
每日例会
演示会议
回顾会议

软件测试的两种模型

V模型(串行)

这里写图片描述
单元和集成测试:检测程序的执行是否满足软件设计的需求
系统测试:检测系统功能、性能的质量特性是否达到系统要求的指标
(1)环境搭建
(2)数据准备
(3)测试执行
(4)缺陷管理
(5)测试报告编写
验收测试:确定软件的实现是否满足用户需求或合同的要求
V模型的局限性:把测试作为编码后的一个阶段,未在需求阶段就进入测试,让人误以为测试不重要

W模型(并行)

这里写图片描述
验收测试准备:验收计划,需求学习
系统测试准备:编写测试计划,搭建测试用例框架
集成测试准备:细化测试计划,编写测试方案、策略
单元测试准备:完善、细化方案、策略、计划、测试用例框架
编码:编写测试用例(包括单元测试的测试用例)
集成测试:提取编码时写的测试用例并加以完善
(1)系统测试:环境搭建
(2)数据准备
(3)测试执行
(4)缺陷管理
(5)测试报告编写
验收测试:协助客户,可能需要对客户进行培训
W模型的优点:有利于尽早的发现问题
W模型的局限性:无法支持敏捷开发模式。对于当前软件开发复杂多变的情况,W模型并不能解除测试管理面临着困惑

什么是配置管理??

配置管理是通过对在软件生命周期不同的时间点上的软件配置进行标识,并对这些被标识的软件配置项的更改进行系统控制,从而达到保证软件产品的完整性和可塑性的过程

猜你喜欢

转载自blog.csdn.net/nessie_zhao/article/details/81149456