软件测试基本概念

本章要点

• 什么是软件测试?
• 软件测试和研发的区别?
• 软件测试都有那些岗位?
• 软件测试在不同类型公司定位?
• 优秀的测试人员需要具备的素质?
• 什么是需求?
• 什么是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

和开发人员产生争执怎么办?

1. 检查看bug描述是否清楚
2. 从用户的角度说服开发人员修改
3. bug定级有理有据(根据公司规范)
4. 不断提高自己的业务水平和技术水平(权威)
   不但能发现bug,并且能够定位,还能提出解决方案
5. 不用争吵,找产品经理理论
   三方会议,测试人员,开发人员,产品经理讨论这个bug的最终解决方案