软件测试 - 概念

一、了解测试

1.1 什么是测试?

  1. 测试是一个过程,全方面检测软件的过程
  2. 在这个过程中,测试人员去验证软件的特性(功能,非功能)是否符合用户预期,是否满足用户的需求
  3. 通过一些专业的测试方法,发现问题,找出bug

1.2 测试和开发的区别

1.工作内容上:

        开发:利用各种变成技术,实现软件。

        测试:通过各种测试方法,验证软件是否符合用户预期。

2.技术要求上:

        开发:需要一定深度

        测试:需要一定广度

1.3 测试和调试的区别

1.目的

        调试:发现软件缺陷、解决缺陷

        测试:发现软件缺陷、验证缺陷

2.人员

        调试:开发人员完成

        测试:测试人员 + 开发人员 (部分的白盒测试 、剩余的一些白盒测试完成)

3.阶段

        调试:开发阶段进行

        测试:贯穿软件整个生命周期

4.方法

        调试:debug、打印日志..

        测试:有许多方法,例如 白盒测试、黑盒测试、测口测试、自动化测试..

1.4  一个优秀的软件测试人员具备的素质 

1.非技术上

        沟通能力:需要与同事,领导沟通,深入理解产品需求(功能、技术实现)

        学习能力:学习新技术的能力,学习各种业务流程的能力

        团队合作:项目会涉及很多人,同事之间需要互相协助

        文字表达能力:测试用例,bug都需要写成文档,通过文字来描述

        抗压力:保证软件质量的同时,还需要按期交付,这是有一定压力的

        责任感:如果测试的软件出现了线上问题,我们需要及时解决,不要出现甩锅的现象。

2.技术上

        编程能力:做自动化,测试工具提高测试效率

        编写测试用例:因为软件测试依据是测试用例

        

二、 测试相关的概念

2.1 什么是需求?

       1) 用户需求:用户提出的一些需求,他们想要做的事情,交给乙方去完成。(一般来说会是一个大致的需求)

例如,买房,客户就会有一些需求,包括 地理位置、楼层、房屋面积、采光等

而房地产商会提供一些户型供用户选择,或者中介会帮用户去找他们所需要的符合他们要求的房子。

       2) 软件需求:也是功能需求,该需求会详细描述开发人员必须实现的软件功能。(会将比用户需求更详细和全面)

软件需求也叫软件规格说明书,prd(product requirement document)产品需求文档。

2.2 为什么要有需求?

        详尽的软件需求,是开发人员的标准。项目实施过程中有一个标准,可以减少一些问题和冲突。

2.3 测试人员眼里的需求

        

2.4 如何深入理解需求

        需求评审会议上 产品经理会交代 软件诞生的背景,软件需求是什么,预期收益,未来软件发展、规划。

        技术评审会议:研发主要讲需求(围绕技术来展开)

        积极参加各种会议,仔细阅读相关文档(需求文档、技术文档、看bug库)

三、 测试用例

3.1 什么是测试用例

测试用例( Test Case )是 为了实施测试 而向 被测试的系统 提供的 一组集合 ,这组集合包含:测试环 境、操作步骤、测试数据、预期结果 等要素
例如: 一些写OJ题的平台
测试环境:牛客、力扣等提供的平台
操作步骤:写代码、提交代码、观察测试用例通过率
测试数据:平台提供的测试数据
预期结果:通过率期望是100%

3.2 为什么要有测试用例

        测试用例是测试人员执行测试的依据,正常清空下,测试用例写完之后,才能进行测试。

目的是:降低测试工作的冗余度。

        并且 测试用例 也是执行 自动化测试 的依据。自动化测试中,一些重复的操作和测试,可以编写代码,让程序去完成,所以在编写代码过程中,就需要知道 有哪些测试用例。

3.3 练习

例如生活中的例子:手机打电话,测试用例有哪些?

手机号输入框是否正常输入和删除?

输入数据过长或者过短的展示情况?

手机号显示区域是否正常显示?

手机号码是否符合要求?国内外手机号、地区号码、空号等

是否能正常拨号?

手机接通后是否能正常通话?

手机通话时,如果有其他电话打来,是否会有提示?

手机挂断后是否正常结束通话?

通话过程,免提、录音等功能

通话结束后,是否有来电人相关信息的记录

四、软件错误(BUG)

1)当且仅当规格说明是存在的并且正确,程序与规格说明之间的 不匹配才是错误。
2)当需求规格说明书没有提到的功能,判断标准以最终用户为准:
当程序没有实现其最终用户合理预期的 功能要求时,就是软件错误。

五、软件的生命周期

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

1.软件生命周期有哪些阶段

2.每个阶段要做什么

需求分析:需求是什么,要干啥,需求是不是正确的,有没有可行性。然后产品经理产出需        求文档。

计划:开发开始时间,开发结束时间,测试开发时间,测试结束时间,谁开发,谁测试。

设计:UI/UE设计师讲需求转换成图,UI视觉稿。技术人员产出技术设计文档。

编码:写代码,实现软件。

测试:执行测试用例,验收BUG,产出测试报告。

运行维护:上线,如果上线之后,项目有BUG,需要解决BUG,重新上线。

六、开发模型

6.1 瀑布模型 

特点:

线性的

优点:

每个阶段要做的事情很明确

缺点:

每个阶段如果出现bug,要等到最后一个测试阶段才能发现,发现时间太晚。并且需要往前面的阶段回溯去解决问题,极其耗费时间和人力成本

适用于什么样的项目:

适用于较小的项目

6.2 螺旋模型

特点:

每进入到下一阶段,都会进行风险分析

优点:

能及时发现每个阶段的问题

缺点:

如果风险分析错误,就会将问题暴露到线上

并且风险分析需要具备一定的知识

适用于什么项目:

适用于大型项目,适用于风险较多的项目

6.3 增量 、迭代开发

举例:画画

增量:一个一个模块画,先画头、然后画身体、然后画手,直到整幅画画完。

迭代:先将整体大致勾勒出来,再细化其他。

6.4 敏捷

6.4.1.敏捷宣言

个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中,后者并非全无价值,但我们更看重前者。

6.4.2 scrum

三个角色:

scrum 由 product owner 产品经理、scrum master项目经理、team研发团队 组成。

产品经理 负责 整理用户故事(需求),定义其商业价值,对其需求进行优先级排序,指定发布计划(项目什么时候上线,哪个先上线,哪个后上线),对产品负责。

项目经理 负责召开各种会议,协调项目,为研发团队对服务(项目上的支援等)。

研发团队 则由不同技能的成员(team包括:前端开发、后端开发、测试、设计。)组成,通过紧密协同,完成每一次迭代的目标,交付产品

五个重要会议:

需求发布会议、计划发布会议、每日会议、演示会议、回顾会议

需求发布会议:确定需求,有一个需求池

计划发布会议:确定每个人的分工

每日会议:昨天干了啥工作内容(进度)、今日要完成的工作内容(目标)、遇到了什么问题(风险把控)

演示会议:测试人员演示功能,看看有没有问题,提出新的需求放进需求池中

回顾会议:复盘之前有没有做的不够好的地方,下次迭代

6.4.3 scrum 基本流程 

product backlog:需求池

会议: 每日站会,发布会议,回顾会议

上线之前给项目之外的人使用,如果合理,将新的需求加进项目,迭代项目

七、测试模型

7.1 测试 v 模型 

用户需求:产品经理 将用户需求进行收集,形成PRD(软件规格说明书)

需求分析与系统设计:需求能不能做,需求对不对

概要设计:大致设计一下框架

详细设计:每个模块如何实现

编码:开发

单元测试:每个类,每个方法

集成测试:模块之间的调用。例如:接口和接口之间,方法和方法之间的调用

系统测试:将项目全部运行起来,黑盒测试,功能测试。

验收测试:产品经理,运营验收(测试人员需要辅助产品经理去验收)

特点:

        左边是开发,右边是测试

        测试被划分成许多类型

缺点:

        验收测试介入太晚,无法及时发现问题

7.2 软件测试 w 模型

特点:

        测试人员更早的介入了需求

缺点:

        不适用与敏捷

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值