本章要点
什么是软件测试?
软件测试的特定?
软件测试和开发的区别?
软件测试和软件开发中的调试有什么区别?
软件测试在不同公司的定位?
一个优秀的测试人员应该具备的素质(你为啥要选择测试开发)
需求是衡量软件测试的依据
从软件测试人员角度看需求
为啥需求对软件测试人员如此重要?
如何才可以深入理解别测试软件的需求?
测试用例的概念?
软件错误bug的概念?
软件的生命周期?
开发模型和测试模型?
软件测试的生命周期(软件测试流程)?
如何描述一个bug?
如何定义bug级别?
bug的生命周期?
和开发人员产生争执怎么办?

本章要点

什么是软件测试?
软件测试和研发的区别?
软件测试都有那些岗位?
软件测试在不同类型公司定位?
优秀的测试人员需要具备的素质?
什么是需求?
什么是bug?
什么是测试用例?
开发模型和测试模型?
软件测试的生命周期?
如何描述一个bug?
如何定义bug级别?
bug的生命周期?
如何开始第一次测试?
测试的执行和bug管理?
和开发人员产生争执怎么办?

什么是软件测试?

通俗讲:软件测试就是找BUG,发现缺陷!
软件测试就是验证软件特性是否满足用户的需求!

软件测试的特定?

软件测试只是一个样本实验,具有不可穷举性,没有办法进行一个完整的测试

软件测试和开发的区别?

技能:开发要求技能集中,专业度高,测试要求的是技能广泛,专业要求不那么高 … 难易程度,薪资,发展前景
测试要求技能广泛:接口测试,自动化测试,性能测试工具,抓包,APP测试工具,以及有一定的编程基础

软件测试和软件开发中的调试有什么区别?

目的:
软件调试:开发人员验证软件是否实现了他想让软件实现的功能
软件测试:测试人员验证软件是否实现了用户需求
角色:
软件调试:开发人员软件测试:测试人员+开发人员(白盒测试代码相关)
阶段:
软件调试:开发阶段
软件测试:贯穿整个软件开发过程中,处处有软件测试

软件测试在不同公司的定位?

无组织,专职,兼职…
项目性:就是一个项目分配测试人员进这个项目组直到项目结束!
职能性:就是测试部门派遣测试人员进行项目跟进,一个测试人员可能同一时间需要跟进多个项目!

一个优秀的测试人员应该具备的素质(你为啥要选择测试开发)

综合能力
沟通能力,学习能力(新技能业务)开发能力(测试开发),文字描述能力(文档,描述BUG)
测试用例的编写能力(掌握了测试用例设计的基本方法)
自动化测试能力(掌握了selenium等自动化测试工具的使用)
兴趣责任感,抗压能力!
探索性思维:不会被条条框框束缚,发散性思维,结合实际思考问题
核心竞争力:开发+测试用例设计+掌握自动化测试技术

需求是衡量软件测试的依据

需求的概念:
满足用户期望或者正式规定文档(合同,标准,规范)所具有的条件和职能
包含用户需求和软件需求
用户需求:甲方提出的需求,如果没有甲方,那么就是用户使用
软件需求:软件需求是用户需求转换而来的,是用户需求的细化,是用户需求的具体实现细节和规范
用户需求比较粗略,直接实现比较困难,因为没有细节,所以需要软件需求将用户需求细节实现和规范,把用户需求变成一个具体可实现的过程文档

从软件测试人员角度看需求

需求是测试人员开展软件测试工作的依据
在设计测试用例的时候,首先需要搞清楚每个业务需求对应多个软件需求功能点,在分析每个软件功能需求点对应的多个测试需求点,然后针对每个测试需求点设计测试用例

业务需求->软件功能需求点->测试需求点->测试用例
假如要写一个用户登入
用户登入就是一个业务需求,登入又有注册和用户登入2个软件功能需求点,然后登入功能需求点又需要测许多测试需求点,功能,性能,兼容性,安全性等待测试点,然后根据不同的测试点编写测试用例!

为啥需求对软件测试人员如此重要?

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

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

测试人员需要在需求分析和设计阶段就开始介入,因为这个阶段是理解和掌握软件的原始业务需求的最好时机
只有真正理解了原始业务需求之后,才有可能从业务需求的角度去设计针对性明确,从终端用户的使用场景到端对端的覆盖率较高的测试用例集!

测试用例的概念?

测试用例是为了实施测试而先被测试的系统提供的一组集合,这组集合包含:
测试环境,测试步骤,测试用例,预期结果等要素!
测试用例解决了2个问题,测什么和怎么测!
编写测试用例可以解决测试过程中遇到以下的问题:

不知道是否全面的测试了所有功能
测试的覆盖率无法衡量
对新版本重复的测试很难实施
存在大量冗余测试影响测试效果

软件错误bug的概念?

当仅当软件需求文档规格说明存在并且正确,程序与规格说明不匹配才是bug
当需求规格说明书没有提到的功能,判断标志以最终用户为准:当程序没有实现用户合理预期的功能要求时就是bug!

软件的生命周期?

6个阶段:需求分析,计划,设计,开发,测试,运行维护

开发模型和测试模型?

瀑布模型,螺旋模型,增量,迭代,敏捷

瀑布模型:
按照软件的生命周期进行串行开发
特点:阶段性强,每个阶段比较独立;看着前面的需求分析和后期的测试
缺点: 测试在开发后才介入,导致前期的问题后期才发现,会失去错误补救机会!
螺旋模型:前期需求不是很明确,一般针对项目庞大,复杂度高,风险大,采用渐进式的开发模型,迭代开发模式!
特点:强调每一个迭代测试质量和风险分析
缺点:风险管控人力物理投入较多,成本比较大
增量模型:
第一周开发A,C功能模块,第二周开发B,D功能模块
迭代模型:
第一周想开发ABCD的基础功能,第二周在第一周开发的基础上增加功能
特点:抗击风险能力强
敏捷模型:
敏捷宣言:
个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者。
特点:轻文档,轻流程,总目标,总产出
敏捷开发有很多种方式，其中scrum是比较流行的一种!
scrum:
角色:
scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成
product owner:负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。
scrum master: 负责召开各种会议，协调项目，为研发团队服务。
team研发团队:则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品
迭代开发:
与瀑布不同，scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。
scrum的基本流程:
产品负责人负责整理user story，形成左侧的product backlog。
发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。
迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。
每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果
敏捷中的测试:
挑战: 轻文档, 快速迭代
1、测试工作的核心内客是没有变的，就是不断地找Bug，只是要调整好自己的心态，一切以敏捷的原则为主。
2、测试人员不能依赖文档，测试用例作用减弱，更多的采用思维导图、探索性测试（强调自由度，设计和执行同时执行，根据测试结果不断调整测试计划）、自动化测试
3、敏捷讲求合作，在敏捷项目组中，测试人员应该更主动点，多向开发人员了解需求、讨论设计、一起研究Bug出现的原因。

V模型:

特点:
每一个阶段的独立性很强左边开发阶段是右边测试阶段的依据
缺点:
瀑布模型的变种,前期的错误后期才会发现,会失去错误及时纠正的机会

W模型:

特点:
每一个阶段的独立性很强,测试一开始就介入,可以保证前期问题及时发现和纠正,测试和开发并行!
缺点:
每一个阶段都是串行的过程,一个阶段完了之后就进行下一个阶段
不支持敏捷开发

软件测试的生命周期(软件测试流程)?

需求分析->测试计划->测试设计/测试开发->测试执行->测试评估

需求分析:验证需求的正确性,合理性,细化需求找出测试项,写测试用例
测试计划:测试人数,测试环境,测试时间,测试设备
测试设计/测试开发:根据需求写测试用例,开发自动化脚本
测试执行:开发已经完成,执行测试用例,验证功能,bug,提交bug,验证bug
测试评估:写了多少测试用例执行了多少,剩余测试用例,bug数量,解决的bug数,遗留的bug及解决方案,测试的范围和测试的功能

如何描述一个bug?

依赖于Bug管理工具,通过文字的形式进行描述,有禅道,jira,tapd等bug管理工具

测试版本号(代码版本信息):代码第几个迭代版本,方便开发人员复现
测试环境:硬件信息:电脑品牌及型号web端:操作系统及版本,浏览器及版本
app端:手机品牌及型号,系统网络环境,WiFi还是数据4g还是5g
测试数据:测试用例,更加快速的复现问题
测试步骤:最快导致bug的测试步骤
测试实际结果
测试预期结果
附件,错误日志,错误截图等

如何定义bug级别?

每个公司对bug级别定义不一样(以下是典型普遍情况)
1.崩溃
系统无法正常运行出现崩溃,操作死锁,死循环,黑屏,阻碍测试人员工作
如果线上版本出现了这样的情况,那就回退一个版本即可进行补救
2.严重
系统运行,但不稳定,继续运行会造成严重损失,重要功能没有实现,或者功能和需求不符合,数据库中的用户数据存储错误,威胁到用户的安全(信息,财产)
3.一般
次要的功能没有实现或者有错误,系统可以稳定运行
4,建议
会影响用户体验,排版(仓促),颜色不符合大众审美,信息没有换行或者提前换行!

bug的生命周期?

bug的状态转换图

New(新建):新发现的bug,未经评审决定是否指派给开发人员修改
Open(确认):确认是bug,并且认为需要修改,指派给相应的开发人员
Fixed(已解决):开发人员进行修改后标识成修改状态,有待测试人员的回归测试验证
Rejected(拒绝修改):认为不是bug,拒绝修改
Delay(延后修改):如果认为暂时不需要修改或者暂时不能修改,则延后修改
Closed(关闭):修改状态的bug经测试人员回归测试验证通过,则关闭bug
Reopen(重开bug):如果验证bug依然存在,则需要重新打开bug,开发人员重新修改
无效的bug:open->closed open->rejected->closed