浪晋的测试小讲堂萌芽计划第二期视频学习笔记

学习测试ing

按照知乎：

https://zhuanlan.zhihu.com/p/32505591

上面提供的B站课程整理笔记

视频链接如下：

https://www.bilibili.com/video/av57464686/?p=1

时长6.5小时（0基础也能两倍速的快乐课程！）

课程中老师省略的部分有时间会补齐的

软件测试的介绍和分类

什么是软件测试：检查，是否符合最开始的设计，把不合理的部分挑选出来（实际结果是否符合预期结果）。

·软件测试的发展历程：

软件测试是去证明软件是正确的。

软件测试是去证明软件是错误的。

软件测试是保证软件的质量是符合用户需求的一系列手段（并不是为了发现bug，而是为了预防bug）。

 

（国外）依靠流程管理来控制软件的质量。

（国内）以技术发展来控制软件的质量。

功能测试→自动化测试（测试开发/持续集成/testops）/性能测试（高级性能测试→架构师）/转行（开发、产品、设计、运维、运营……）/管理向（项目经理、QA）

 

·软件测试的分类：

·按方法分类

    黑盒测试（不透明的盒子）：只检查输入和输出即可→外部暴露出来的功能能够实现，不关注原理

    白盒测试（透明的盒子）：通过检查内部的结构看对不对（对内部逻辑结构进行测试，通过逻辑的覆盖率来判断测试是否有效）→直接看代码写的对不对

    灰盒测试（半透明的盒子）：介于黑盒与白盒之间（或结合两者）

 

·按方向分类

    功能测试：测试功能 能不能做

    性能测试：测试性能（高并发 承载量）功能能做多好

       压力测试：逐渐增加模拟用户数量，发现瓶颈（发现软件的性能瓶颈）

       负载测试：持续保持高强度的工作能维持多长时间

       并发测试：同时做一件事会不会出错

    安全测试：测试安全

 

·按阶段分类

单元测试：针对代码块（方法、函数、类）

集成测试：把代码块连接起来（接口）

系统测试：功能、性能、安全、兼容性、易用性、稳定性、UI……

    兼容性（WEB-浏览器 APP-andriod-iOS）

    易用性（用户体验）

    稳定性（可归于性能测试）

    UI（界面-好不好看，设计图比对）

验收测试：系统测试通过之后

 

·按对象分类

    APP测试

    WEB测试

    物联网测试

    车联网测试

    小程序测试

    嵌入式测试

    大数据测试

    AI测试

    ……

 

·按状态分类

    静态测试：软件没有运行，白盒，看代码

    动态测试：软件运行，黑盒

·其他

冒烟测试：测试前的测试→是否具备可测试性

回归测试：检查之前的bug有没有被修改

α测试：内测

β测试：公测

 

软件的研发模型和测试流程

·研发管理模型

瀑布流

从上往下，步骤与步骤之间是相互独立的。

好处：上下级分明，必须要完成第一步才能完成第二步。

缺点：不变通

 

V字型

    左边是开发的工作，右边是测试的工作

    好处：测试和开发的工作有了一一对应的关系

    缺点：还是从上往下

 

W字型

    （双V模型）

    左边的V是开发做的事，右边的V是测试做的事。

    也有对照关系：

    效率比较高。

 

敏捷模型

    特点：

       高效的工作、及时的沟通、日报、白板、站立会、集中办公

 

螺旋型

H字型

 

·测试流程

    需求分析阶段：

       需求分析（需求文档、产品原型、口述）

                   产品原型

       学习业务流程(金融、银行……)

       提取功能点

           模块（以产品原型举例）：首页、发现、下载、我的；首页又可以划分：推荐、课程、路径、实战……

           找到最小的功能，列出来（树状结构）：

 

编写需求分析说明书

           转换为文档

    ··没有需求怎么办

       参考市面上已经成熟的同类型的产品的实现

 

测试设计阶段（文档阶段）

    测试计划·5W1H

   

    测试方案·5W1H

    测试策略·5W1H

    *测试用例

          

       用例编号

           -唯一的

       用例名称

           -言简意赅，用最少的字描述清楚这个用例是做什么的

       前置条件

           -执行这个用例之前，软件必须要满足的条件

       优先级

           -执行这条用例的时间要求紧急的等级

       重要级

           -这个被测的功能在系统里面的重要级别

       测试数据

       测试步骤

       预期结果

       实际结果

        5W1H：what where when who why how

       在有限的时间里挑出重要级高的先测试

 

测试执行阶段

       预期结果和实际结果做对比，如果一样则通过，如果不一样则有问题

       提交BUG

       回归测试

           -在版本2上去检查在版本1上发现的问题有没有被解决

 

测试总结阶段

       编写测试报告

           -对工作的总结

           -对BUG的统计分析

           -对被测软件的评估

 

·测试方法（设计测试用例）

    等价类

       通过少量的数据代表大量的数据

       -无效等价类（找不是有效值中的）e.g.0 200.01

       -有效等价类（找出有效值中的有代表性的数据）e.g. 0.01 0.02 200 199.99 99.99（0.01，＞0.01的数，200，＜200的数，中间值）

 

    边界值

       比如微信红包→￥0.01-200

       伪代码：

    场景法

       

   

    因果图

    判定表

    路径覆盖法

    ……

 

·测试常识

    测试是无穷无尽的（测试的数据是无穷无尽的）

 

·评审（检查测试用例）

    同行评审

    小组评审

    部门评审

    项目评审

    第三方评审

    邮件评审

 

 

用例的编写和BUG的管理

用例编号

           -唯一的

       用例名称

           -言简意赅，用最少的字描述清楚这个用例是做什么的

       前置条件

           -执行这个用例之前，软件必须要满足的条件

       优先级

           -执行这条用例的时间要求紧急的等级

       重要级

           -这个被测的功能在系统里面的重要级别

       测试数据

       测试步骤

       预期结果

       实际结果

       在有限的时间里挑出重要级高的先测试

 

·BUG的管理

BUG的管理平台/系统/工具

       禅道

       BUGFree

       ALM/QC

       testlink

       Bugzilla

       JIRA

       ……

 

BUG的六要素

       编号

       BUG的名称

           言简意赅，看到题目就知道是什么问题

       BUG的优先级

           根据实际的情况，这个BUG需要优先解决吗？高/中/低

       BUG的严重级别

           致命的（三者任意满足一条）

              -影响产品的核心流程的正常使用

              -导致软件挂了，闪退，崩溃

              -和钱有关

           严重的

              -导致了功能无法正常使用（不是核心功能）

           一般的

              -功能的某些异常场景有问题

           轻微的

              -建议的东西，用户体验，UI上的问题

       BUG的复现步骤

           可以把用例的步骤复制过来

           预期结果

           实际结果

       附件

           截图/日志/视频

           目的是为BUG佐证

    BUG的生命周期

       在解决BUG之后，如果回归测试还存在，就激活BUG。

       如果开发认为不是BUG，就讨论。

       BUG彻底解决了就关闭

    BUG的状态

       新建/new

       打开/激活/open

       已确认

       已解决

       拒绝

       重新打开/reopen

       关闭/closed

       延期处理

       重复BUG

 

e.g.

 

版本1→版本2：迭代

会在版本2上做回归测试（在版本2上去检查在版本1上发现的问题有没有被解决）

 

·版本迭代

    -随着时间/测试次数多推进，会发布很多版本，其中的版本号是不断叠加的

    -增量测试

       只测试已知的有变化的功能（但是该回归的还要回归）

    -全量测试

       测试软件的所有功能（增加了功能之后要把所有功能都测试一遍）

 

测试应用和测试报告的编写

·测试应用

    APP测试

APP专项测试

           -安装/卸载

           -消息推送

            -更新

            -弱网测试   2G/3G/4G/5G/WIFI

            -场景交互测试-来电话了

                         -正在听音乐

                         -调用相机

                         -前后台的切换

            -权限测试

            -离线测试

    WEB测试

 

·软件结构（区别：一个需要安装，一个不需要安装）

    B/S结构

       Browser  浏览器

       Server  服务器

    C/S结构

       Client  客户端（需要单独安装的，比如APP）

       Server  服务器

 

·测试报告

    对工作的总结

       -工作很努力，完成了xx工作，存在哪些问题

    对BUG的统计分析

       -测试

       -开发

       -等级

       -解决的时间

       -每个版本

       -BUG的状态

       ……

    对被测软件的质量评估

       一二级的BUG全部关闭了

       三级的BUG关闭了80%+

       四级的BUG无所谓

       →达到验收标准了

 

-----------------------------------------------------------------------------------

补充在B站视频中提到的慕课网上有关测试用例编写课程的笔记

课程地址：

https://www.imooc.com/learn/816

如何写好测试用例

·前置知识点

软件的相关概念

-软件：数据、程序、文档的结合

-测试时操作数据，程序是测试的主体，文档是工作时的可视化（测试用例是文档的一部分）

软件测试基础

    -软件测试是以满足需求为目的保证软件质量的一系列的手段。

测试流程

    -需求分析→计划指定→用例编写与执行→对测试结果的分析报告

测试生命周期

    -测试计划→测试设计→*测试开发（测试用例的编写属于测试开发）→测试执行→测试评估

 

·常用术语

按软件测试的手段划分

    黑盒：把软件比做黑色的盒子，不知道盒子里面的内部结构，只能通过外面暴露出来的接口、功能进行测试

    灰盒：把软件比做半透明的盒子，可以看到内部少量的东西，可以通过外面暴露的功能和盒子内部的数据进行对比，得出测试结论。

• e.g.测试订单生成的功能
• 可以通过软件上生成的订单和数据库里的数据进行对比，验证是否一致。

    白盒：把软件看成一个透明的盒子，通过观察内部的结构直接推敲出软件是否符合需求（三者中计数难度最高的）

按软件测试方向划分

    功能：验证软件是否符合用户提出的表面需求

    性能：测试一个软件的工作效率

    安全：测试软件是否能够保护用户的信息

按测试点划分

    兼容性：测试软件在不同平台上的表现

    易用性：测试软件是否友好，满足用户的使用习惯

    UI元素：检查界面的布局是否一致、美观

 

·测试用例是什么

    （在测试时按照测试用例的描述进行操作的，规范每一步都输入输出，对照判断是否满足需求。通过测试用例和需求的一一对照，确定测试是否能够覆盖需求，是否有遗漏）

    -测试工作的核心

    -一组在测试时输入输出的标准

    -软件需求的具体对照

 

·测试用例有什么作用

    -检验软件是否满足客户需求（测试用例是以需求为基础生成的）

    -提现一个测试人员的工作量

    -展现测试用例的设计思路

 

·测试用例包含哪些内容

    -用例编号

       每一个编号都是唯一的，可以用简单的数字来编写，也可以带上是做什么的，e.g.xxxx_001。

    -用例名称

       用例的名字，设计要求。要求用最少的字去描述，言简意赅。

    -测试背景

       测试用例是属于哪一个项目的，用例是测什么的

    -前置条件

       执行这条测试之前应该满足什么条件，e.g.测试登录要求账号密码是注册了的

    -优先级

       优先级和重要级没有绝对的关系，e.g.周末计划出去玩，出去玩的优先级最高，突然公司要求加班（重要级）

    -重要级

    -测试数据

       在测试时输入的数据，e.g.登录功能，账号密码就是登录数据。

       有些测试用例是不需要用键盘输入值的，也是有测试数据的，只是没有明确写出来（鼠标的操作也属于数据）

    -测试步骤

    -预期结果

       每一步操作对应的现象，e.g.输入正确的账号密码，预期结果就是登录成功

    -实际结果

       在执行测试的时候出现的实际的状况，e.g.输入正确的账号密码，登录失败/成功/网络异常（满足需求或者功能有问题）

    -备注

       特殊情况

 

·测试用例编写流程

需求分析：客户需要的东西和对那个东西的要求。

       -业务需求：关注系统是否满足业务（购物？银行？）。

       -用户需求：关注系统是否满足用户习惯。

       -功能需求：关注系统是否满足功能要求。

       如果没有需求怎么办

       -参考市面上已经上线的同类产品

       如果需求模糊怎么办

       -收集整理已有需求

       -和产品经理逐条确认

       -参考同类型产品的实现情况

提取测试点

       什么是测试点

       -测试点即通过需求分析后对得出的需要进行测试的具体内容

       测试点对测试用例的设计有什么好处

       -快速：根据测试点快速设计测试用例。

       -覆盖：测试点可以完全覆盖需求。

       -方法：在擦拭点上可以快速应用测试方法

       -细节：展现出需求的细节

测试用例编写

      测试用例编写注意

       -根据项目的实际情况设计测试用例表格

       -用例格式不是固定的，不要生搬硬套

       -根据具体情况编写

      测试用例编写方法

       -等价类划分法

           如何选择适当的数据子集。来代表整个数据集。

           通过降低测试的数目去实现“合理的”覆盖，覆盖了更多的可能数据，以发现更多的软件缺陷。

           (一种典型的黑盒测试的方法)将所有可能输入的数据划分为若干个等价类，从每个部分中选出最具有代表性的数据，作为测试用例，进行合理的分类。

           等价类分为有效等价类和无效等价类→测试用例具有完整性和代表性。

           -有效等价类：合理的有意义的数据，检验程序是否满足规格说明

           -无效等价类：对于软件规格来说是不合理的、没有意义的输入数据的集合

       -边界值分析法

           使用边界值分析方法设计测试用例时，一般与等价类花饭结合起来，但它不是从一个等价类中任选一个例子作为代表，而是将测试边界情况作为重要目标，选取正好等于、刚刚大于或刚刚小于边界值的测试数据。（边界值可以作为等价类的补充。）

       -场景法

           通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果。

           场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。

       -猜测法

 

·测试用例评审

       →简单的来讲。评审就是对测试用例进行检查。

       →评审包括同行评审、小组评审、部门评审、三方评审（开发、测试、客户）等

       →不同的评审类型会有不同的角色参与

  评审的意义在哪里

1. 通过评审可以发现测试用例的不足
2. 方便测试人员改进用例
3. 达到在测试是提高测试质量的目的

评审的流程

 

·测试用例管理

为什么需要管理用例

1. 测试用例数量巨大
2. 测试用例会随着需求变更
3. 测试用例需要补充完善

如何管理用例

1. 原始的excel管理方式
2. 专业的项目管理系统

如何管理用例