大家好,我是bug郭,一名双非科班的在校大学生。对C/JAVA、数据结构、Spring系列框架、Linux及MySql、算法等领域感兴趣,喜欢将所学知识写成博客记录下来。 希望该文章对你有所帮助！如果有错误请大佬们指正！共同学习交流

作者简介:

• CSDN java领域新星创作者blog.csdn.net/bug…
• 掘金LV3用户 juejin.cn/user/bug…
• 阿里云社区专家博主,星级博主,developer.aliyun.com/bug…
• 华为云云享专家 bbs.huaweicloud.com/bug…
  @TOC

本章要点

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

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