软件测试学习笔记（资料免费分享）

网上有许多软件测试教程，可惜都是说一半藏一半，最后还是需要付费买课才能学完，哔站免费课程笔记也没有途径获取，小编看得也是牙痒痒的，最后还是决定自己整理算了。

历时多月，小编几经周折整理了软件测试，包括功能测试、性能测试、接口测试、UI自动化测试以及Python编程、Linux、数据库等。

附带工具和实战项目，从基础到实战，资料全面，学完不说精通，起码有底气去投个实习了。

适合转行的小白和找实习的大学生，资料放在后面了，需要的铁子自行领取，小编整理不易还花钱了，如果觉得可以铁子们记得点赞关注啊！！！

1、什么是软件？

软件就是程序和数据和文档的集合，程序就是运行的代码，登录信息，好友列表这些就是数据，初次使用一个软件的时候，要勾选用户使用协议，帮助文档

2、什么是软件测试

用人工或自动化的手段去评估或测试一个系统的过程，其目的是为了检验它是否满足规定需要，或弄清实际结果与预期结果的差别，找BUG。

QQ发现一个错误是否符合软件测试，不符合，因为目的不一样，一个是为了交流，另一个是为了发现BUG

3、为什么要进行软件测试？

发现是否存在代码或业务逻辑错误、系统是否符合用户需求、提升用户体验

4、软件测试流程

进行需求分析、需求评审

编写测试计划

编写测试用例、用例评审

执行测试用例、提交bug、回归测试

编写测试报告

5、测试阶段及分类

黑盒测试，只需要关注外部的对象的输入与输出，不需要关注内部的逻辑实现。

白盒测试：不需要关注外部的输入与输出，只需要关注内部的逻辑实现

灰盒测试：既关注外部的输入与输出，也关注内部的逻辑实现

动态测试：运行被测系统进行测试

静态测试：不需要运行被测系统的测试，代码走查、文档检查、界面检查

功能测试：测试被测系统的业务功能是否符合需求

界面测试：开发会有个界面的原型图，测试被测界面是否和原型图一致

安全测试:对被测系统的安全进行测试，（多次输入密码是否冻结账号，SQL注入等）

兼容性测试：被测系统在不同环境下是否能正常运行，淘宝吧b/s架构，测试在fireox、Chrome、百度等浏览器下是否

易用性测试：被测系统是否易于操作，是否易于理解，是否易于上手

性能测试（负载测试、压力测试）：在特点时间段、用户数量剧增时，软件是否正常

冒烟测试：在正式测试前对核心功能进行测试，一般由开发人员或测试主管负责，一个直播软件，测试注册登录，开启直播，界面、语音等这些测试

回归测试:开发对存在的问题进行修改后，再次进行测试，可能部分测试，也可能开发修改了其他部分，其他部分也要重新测试

探索性测试:依赖自己的项目经验所进行的随意测试

6、软件生命周期及流程

·、软件生命周期：从开始研制到最终废弃不用的整个流程

瀑布模型：问题定义及规划--需求分析--设计--编码--运行维护

由上而下，相互衔接，具有顺序性和依赖性、基本不用。

缺点：测试介入比较晚--回溯成本较高，测试周期较长

2、V模型

是软件开发的一个重要模型，大项目、重复性高。

在需求分析时同时进行系统测试内容，如编写测试用例，概要设计时对各个模块和接口设计，可同时准备集成测试所需内容

优点：需求分析时便开始介入，回溯成本低

1、问题定义及规划：主要确定软件开发目的及可行性，制定项目总体开发计划

2、需求分析：在确定软件开发可行的情况下，对软件各个功能模块进行详细设计，产生需求规格说明书（原型图），提交评审

3、设计

把需求分析得到的结果转化为软件架构和数据结构，得到系统架构

概要设计：主要是架构的实现，搭建架构，表述各个模块功能、模块接口和数据传递实现等事物

详细设计：对概要设计中表述的各个模块功能进行深入分析，其中需要包含数据库设计说明

4、编码：按照详细设计好的模块功能表，编写程序代码

敏捷开发模型

是一种以人为核心、迭代、循序渐进的开发方式，强调以人为本，专注于交付对客户有价值的软件，用于开发和维持复杂产品的框架，就是把一个大项目分为多个相互联系，但可以独立运行的小项目，并分别完成，在此期间软件一直处于可使用的状态、

如开发XM聊天软件：文本聊天、语音聊天、视频聊天、朋友圈、小程序等，全部开发完需要一年，而互联网是快速发展，不断更新迭代的，为了快速抢占市场，可使用敏捷开发，先开发文本、语音聊天功能并投入使用。

迭代第二个版本，加入支付、朋友圈功能，吸附更多用户

迭代第三个版本

——

根据需求开发，不断更新维护

一人为核心：敏捷开发的优点是快，不像其他模式都产生文档，敏捷开发弱化文档，开战会，通过人与人之间的沟通进行需求分析。

3、测试流程

编写测试计划：测试工作的统筹安排（人员分工，任务分配、测试环境、工具、时间安排）……测试负责人/主管/组长

测试需要经过2-4轮，测试轮次越多，越能保证软件的稳定

4、 软件在什么情况下可发布（发布上线标准）：不是没有bug才可以发布，而是剩余的bug数量少bug遗留率趋近0）这个需求开发去改）+用例执行覆盖率，所有的测试点都覆盖到了，（这个测试人员去保证）

测试覆盖率：

测试用例的覆盖率：与测试点覆盖率有关，只有测试点覆盖率达到100%，测试用例覆盖率才有可能达到100%，所以测试点覆盖率是决定测试覆盖率的重要指标

测试用例的执行率：编写的测试用例都能执行，就是执行，这个容易实现

测试报告，解决的bug有哪些，剩余的bug有哪些，最终有个评估的结果，可以上线还是不可以上线，可以上线那么进行发布上线的流程，不可以需要继续测

发布上线:开发打包-》运维/运营/开发-》部署生产环境（真是环境）实现发布上线

开发环境：开发人员编写代码的环境

测试环境：测试人员进行测试的环境(1个或以上）

开发用的环境与测试环境是独立的一个环境，数据也是独立的，

预发布环境（UAT测试）:验收测试进行的环境，发现问题了怎么办？给开发去改，改完再测试

生产环境：真实的用户使用环境

首先进行需求分析，去阅读、去了解需求，从而对需求分析进行对应的评审，然后根据测试计划进行对应测试工作的展开，然后编写测试用例，编写完测试用例后我们会去执行用例，并对bug进行跟踪，直到软件符合我们对应的需求之后，最终出一个测试报告，对整个测试过程软件的质量进行评估，确认是否可以上线

5、你们公司的开发流程是怎样的？

进行需求分析，阅读需求，了解需求，进行对应的需求评审，然后编写开发计划，根据计划展开对应的开发工作，进行概要设计、详细设计，编写代码并自测，提交测试

6、你们公司的测试流程，各阶段的输出是什么？

需求分析——》根据需求规格说明书输出项目测试点列表

用例设计——》测试用例文档

执行用例——》bug

评估测试——》测试报告

灰度测试：先更新部分功能，收集反馈，如果没有问题再更新全部功能。将功能分为两部分

AB测试：发布的时候先更新A部分用户的功能，再根据反馈对B部分用户中对应的功能。将用户分为两部分

7、测试需求是什么，要测什么、测试思维

测试需求主要解决测什么的问题，一般来自需求规格说明书的原始需求

测试需求应该全部覆盖已定义的业务流程，以及功能和非功能方面的需求

：功能需求：业务流程

非功能需求： 界面、文档、兼容性、 易用性、安全性、性能

测试需求分析

8、什么是测试需求分析

根据需求规格说明书明确测试的内容，细分需求提取测试点，

测试点：软件包含多个功能，每个功能包含多个子功能，也就是测试点，测试点是软件功能细分的最小单元

9、测试需求分析的目的

软件测试需求是设计测试用例的依据

有助于保证测试的质量和进度。

是衡量测试覆盖率的重要指标

只要明确测试需求，才知道怎么去测试，什么时候开始测试，要多少人测试，在什么环境上测试

测试需求分析没有做好就导致我的测试点少，测试点少那么就会导致用例有问题，出现漏测，那么评估软件的质量就会存在风险所以啊可能就会影响到软件的质量和进度，测试点的覆盖率又是衡量测试覆盖率的重要指标

10、测试需求分析具体实现

查阅需求规格说明书（原型图）

①初步熟悉被测软件的业务流程。了解这个软件是干什么用的，有什么功能

②针对某个功能，细化需求，列出测试点，评审是否存在漏测和错测的测试点

11、一个页面如何进行测试需求分析（功能测试）

①进行界面检查，参考原型图，查看界面是否一致。错别字、字体、样式、背景颜色，必须一模一样

②依次分析每一个输入项/字段名，从上到下，从左到右的顺序进行分析。

约束限制，输入的条件要求，长度、格式，验证类型

是否必填

是否重复

隐形需求：需求上没有明确提及但需要验证，比如手机号长度一定11位，需要常识，熟悉这类业务、根据成熟同类产品去分析

③按钮。根据业务逻辑的先后顺序依次分析，在什么条件下操作成功，操作失败，验证操作结果即关联交互功能，验证当前操作结果的功能

如登录，验证操作结果即进入首页

首先进行正常功能的测试，是否可以正常提交；再进行单个功能项的测试（正常+异常）；

验证结果：进行功能交互验证；非功能性测试。要把所有可能的结果包括正常异常都考虑进来

电商系统功能需求分析

①用户管理

登录功能

界面检查，参考原型图，是否一致

用户名：可编辑、必填、长度、

密码：可编辑、必填、长度、组合

登录：正确用户名密码登录成功，进入首页，展示个人信息：登录失败，进入首页，提示未登录的状态，一用户名不正确点击登录按钮提示“用户不存在！”二，密码不正确，点击登录按钮提示“密码不正确，请检查后重新输入！”

注册：进入新用户注册界面

重置：清空用户名与密码框

关闭：点击关闭，关闭登录页面

②订单管理

③会员管理

④财务管理

⑤商品管理

12、怎么去把握软件的质量？

答：每个阶段在流程中的重要性

13、遇到隐形需求怎么办？

我们要充分熟悉产品，因为只要熟悉了你才知道它应该是什么样子的，需求没有明确写明但是我们该要做到的，同时我们也可以去参考成熟的同类产品，这个和这个需求应该要达到什么样的条件，成熟的产品它支持这个功能的话去看一下我这是否也可以支持这一种，站在用户的角度去考虑从而挖掘需求。

14、给你一个带有logo的水杯，你会如何去测试？（测试思维）

功能：装水、是否漏水、装热水、冷水、饮料、茶水、是否保温

非功能

界面：logo是否与原型图一致，是否美观、是否掉色、材质

易用性：防滑、防烫、带手把、会不会刺到嘴巴、携带是否方

便

安全性：装热水时候 会不会水有毒

兼容性：能否装其他液体

性能：防摔、挤压

15、你会如何去测试朋友圈，购物车等熟知软件产品（支付、优惠卷、二维码）

功能：

测试用例

16、什么叫软件测试用例

是为项目需求而编写的一组测试输入、执行条件以及预期结果的测试文档，目的是为了测试某个程序是否满足客户需求。

可总结为：每一个测试点的数据设计和步骤设计

17、为什么要编写测试用例

测试用例是软件测试的核心，这是毋庸置疑的，因为我们执行测试用例的时候要根据这个文档来执行，测试用例写得好不好最终会影响到是否存在漏测错测等这些问题，所以测试用例写得好不好是跟我们测试人员测试水平关系是极大的，也是评估测试结果的一个重要依据。

1、是软件测试的核心、测试用例是测试工作的指导，是软件测试质量稳定的根本保障，影响测试用例的因素很多，如软件本身的复杂度、开发的质量、测试方法和技术，也有些客官因素是不可避免的，如IT团队的流动、环境、情绪等。

2、评估测试结果的标准

测试用例的通过率和错误率是测试结束的一个重要依据，以此来判断这个软件是否通过，是否达到上限标准。

3、保证测试的时候不遗漏测试功能点，可以在测试人员疲惫的时候起一个牵引作用。

4、在编写测试用例过程中，可以熟悉需求，对系统架构或业务流程有一个整体的、深入的了解

5、好的测试用例不仅方便自己和别人查看，而且能帮助设计的时候考虑周全，因此测试用例的写作和设计一样重要。（执行性。）

18、测试用例的八大要素

IT测试：集成测试——接口测试

st：系统测试

uat：验收测试

①用例编号：或编号/项目+编号：

②模块：测试点所在的模块： 用户管理

③测试标题：主题描述测试的目的，言简意赅，不要重复，格式：输入+动作： 注册界面页面检查

④优先级/重要级别：根据测试点在整个项目的重要程度来进行划分， 高中低（1,2,3）

——》区分：

高：主要核心业务功能，冒烟用例 ，如注册成功

中：错误异常的测试点，如注册失败

低：兼容性、界面错误

⑤预置条件：需要满足一些前提条件，否则用例无法执行，如果用例不需要其他什么条件，都处在统一的条件下如网络，可以不写

⑥测试步骤：对测试点进行验证，具体的测试数据+动作

有时会分为测试输入（数据）＋测试步骤

⑦预期结果：参考需求规格说明书应该有什么样的结果，一个步骤对应一个或多个结果

⑧实际结果：

通过：pass

不通过：falled

阻塞：用例无法执行，上一个有问题无法验证

⑨备注：bugid/原因

大部分都有

10测试版本

11用例设计者

12测试时间

①用例编号：xx项目_st_注册_001

②模块：用户管理

③测试标题：注册成功

④优先级：低

⑤预置条件：正常上网，有效的账号

⑥测试步骤：

1、用户管理》注册

2、用户名：234aad  密码：1233333sa  确认密码：1233333sa

3、点击注册

⑦预期结果：

1、进入注册页面

2、用户名、密码、验证成功

3、进入首页

19、用例是根据测试点进行编辑、是不是要针对每一个测试点编辑一条用例？

不是，比如说注册-注册成功和用户名-用户名正确这两测试点进行测试都是一样的，对每一个测试点编辑一条用例会导致重复测试，降低测试效率

20、具体怎么进行编写用例，多少个测试点对应一个用例，怎样不重复测试？如何选择测试数据进行测试，怎么在达到最大覆盖的情况下用最少的测试数据来获取更多的bug？

不能穷尽测试，编写测试用例需要测试方法和技巧

7、测试用例编写7大方法方法（黑核测试方法）

1、等价类划分法

将所有的数据划分为n个子集合，从子集合中抽出一个数据作为代表进行测试

长度规则

如长度5-23，a集合<5，b集合>23,c集合>5,<23

所谓等价，即为找到bug的效果等价，难点在如何划分集合

有效等价是正确的、有意义的等价类，如c集合

无效等价类是错误的、无意义的等价类。如ab集合

eg：填入必须是字母数字下划线两者或两者以上组合

组合规则

有效等价类d

字母＋数字     字母+下划线   字母＋数字＋下划线  数字＋下划线

无效等价类e

纯数字、纯字母、纯下划线、空、除字母下划线数字的其他

如果ae1、be1，那么出问题了，就分不清是长度还是组合导致的错误

eg:

手机号码

验证格式

有效等价类a：手机号段+纯数字       

 无效等价类b：非手机号段+数字、非手机号段+数字+加其他、非数字、空、

有效性验证：已注册过的邮箱地址，验证码

长度规则c：

有效等价类：11位          无效等价类d     空、《11》

密码

组合规则

有效等价类e：大小写字母＋数字

无效等价类f：纯大/小写字母、纯数字、大小写、大/小写+数字、符号、空

长度规则

有效等价类g：8-16

无效等价类h：《8，16》、空

测试用例：

有效等价类（符合长度规则也符合组合规则），使其尽可能多的用例去覆盖未被覆盖的有效等价类，即用最少的用例去覆盖最多的等价类

aceg

无效等价类：使其仅覆盖一个尚未被覆盖的无效等价类、即用最多的用例去一一覆盖无效等价类

bf、dh

eg

测试编号  模块  用例标题    

yeah_st_001  用户管理/注册   验证字母＋数字用户名密码输入正确  

优先级   预置条件   测试步骤   预期结果   备注

高    /     1、手机号：344223 密码  用户名验证通过

使用场景：

输入项内容存在无穷尽的情况，一般都会通过等价类实现

通过等价类将穷尽测试转化为有效测试，捕捉更多bug

2、边界值分析法

离点、上点、内点

在等价类方法中，用户名8-16该选取那个长度，这便用到了边界值法。

是对等价类划分法的一个补充，边界值一般从等价类的边缘值去寻找，边界值分析的基本思想是：正好等于，刚刚大于，刚刚小于，作为测试数据。

0/负数是一个特殊值，在考虑边界值时同时也要考虑这个值。

作用：我们从长期的测试工作经验中得知，大量的错误是发生在输入或输出范围的边界上，而不是输入的内部，因此针对各种边界值情况设计测试用例，可以查出更多的错误。

如微信红包：最小金额0.01，最大200

边界值：0、0.01、0.02、199.9、200、200.01

特殊值：负数

应用场景：如果需求规定了某个值的取值个数时，可以利用边界值进行测试。

笔试题eg：输入边长a、b、c、判断是否能钩成三角形，输出对应的信息？

思路：

首先考虑a、b、c是否为整数。abc>0

三角形判断：a<b+c, b<a+c, c<a+b

为直角三角形：a^2+b^2=c^2

为等腰三角形：a=b不等于c……

为等边三角形：a=b=c

为等腰直角三角形……

等价类划分法：

abc有效：abc>0，无效a/b/c《=0，

三角形判断有效：a^2+b^2=c^2，无效：a^2+b^2≠c^2

3、场景法

等价类基于每个功能进行测试，而场景法是通过场景描述的业务流程/逻辑，包括代码实现逻辑，设计用例来遍历场景/路径，验证系统功能的正确性。

应用场景：对项目的业务流程功能用例的设计，基于场景法

在进行项目设计的时候我们要去理解它的业务流程，它的核心功能，那么你要对核心功能编写测试用例的话那么我们就用到场景法

业务流程图是基于场景法设计测试用例的依据

先画出业务流程图，业务流程图一般由产品提供，我们就可以知道项目的大概业务流程，如果没有提供，只提供测试文档，那么就需要我们通过文档去理解，去画出业务流程图，可用processon等工具编写

其中：

矩形：表示步骤，输入、操作、输出结果

棱形：表判断

箭头：流向

注意:场景法的重点是测试流程，因此每一个流程一个测试用例验证即可，流程测试没有问题并不代表系统功能没问题，还需要针对单步的功能进行测试，只有单个功能点和流程测试才算是充分的测试

基于流程图进行功能用例设计

正常流（基本流）：从起点开始通过各个路径，到最后节点结束对应的流程，就是从头走到尾达到预期结果的流程，一般有一个或多个。

异常流/错误流（备选流）：从起点开始，在执行正常流时出现某个错误导致结束。或返回上一个流程，通常多个。

场景法分析：

场景法用例编

涉及业务规则，条件之间存在关联可以用场景法，如三角形判断

4、错误推测法（反推法）

是真正的基于经验、知识、直觉去推测程序中所有可能存在什么的各种错误，从而有针对性的设计测试用例的方法

是一种探索性测

5、因果图法、判定表法，二者常一起使用

因果图法

当需求中存在多个条件，不同条件有不同结果，就会使用因果图法。列出需求中的因子/条件

判定表=条件桩+动作桩+条件项

条件桩=需求中的因子（条件）

动作桩=需求中的结果

条件项=不同因子的组合

动作项=不同因子组合的结果=a^N个，其中a为N个条件，N为每个条件的取值，是否感兴趣，一个条件，取

分析步骤：

1、找出需求中的因子及结果

2、确定判定表中的条件桩及动作桩

3、根据条件项。划出对应的动作项，得到一个判定表

4、简化动作表。

5、如何简化

合并条件项及动作项：

合并的项动作项是相同的，合并的因子不同情况的下动作

6、根据简化的判定表，针对每种条件项和动作项编辑设计用

6、正交实验法

使用场景：使用因果图判定表时，条件项=a^N个，当N=因子数过大时，这是指数函数，结果就会特别大，因果关系比较庞大的情况下，即条件很多，组合多，结果也多，不太适合适应用过判定表，这时候我们就可以使用正交实验法，用最少的测试用例集合获得最大的测试覆盖率

如，字体、字符样式、字体颜色、字号等，每一个字段包含的种类很多，这种时候就不适合因果判定表

正交表可从网上找。

8、用例评审

分为组内评审和组外评审。

组内评审由测试负责人根据评审计划发起，然后进行用例审核，由负责这个模块的测试人员讲解测试用例的设计，我覆盖了哪些测试点，是怎么对测试点进行覆盖，听的组员就会进行评审，评审不通过，需要对用例进行修改，评审通过就可以进行用例归纳，就是确定下来这用例没有问题，那么我们就可以去执行下一个阶段，即执行用例。

1、测试用例变更情况

1、需求变动

2、执行完成后的用例完善，在执行过程中发现用例有问题

3、评审后的用例修改

写完用例一定要备份！！！

2、用例需要评审吗？紧急情况用例也需要评审吗？

一定要评审，用例评审可以发现漏测，可规范流程，也需要，将用例发邮件给相关人员确认。

3、如果被测项目很急，来不及写用例，怎么办？

这时候我们可以用xmind列出测试点，一个checklist检查表，根据检查表来一一测试，当测试完成之后如果时间不那么紧就可以去补充完善用例，大概知道自己覆盖了哪些，也方便后面回归测试，

4、遇到隐性需求如何写用例？（需求不明确）

熟悉功能，参考成熟产品，站在用户的角度挖掘需求，编写测试用例过程中有什么不明确的地方可以去参考一下成熟的产品是怎样做的

5、用例有没有优先级？如果一定有优先级，依据什么来确定？

有，根据功能来确定，用户是否使用场景是否多，使用功能多的，核心功能，来判断它是不是很重要，它的优先级就高，如果是一些异常的错误的流程就是中等，一些界面问题，一些改进的建议的就为低等

6、如何编写测试用例？（以项目为基础讲一个小模块，用例设计，手机号）

7、编写测试用例会用到什么方法？

接着问，你觉得你在写用例的时候用到了吗？（结合项目回答）

9、*BUG生命周期及管理流程

执行用例出现问题，该怎么做？

BUG：狭义指软件程序的漏洞或缺陷，广义还包括软件可改进的细节，建议及优化，或与需求问题存在差异的功能实现等。我们的职责就是，发现bug，提交给开发让开发修改。

1、BUG类型

BUG属于哪方面不输于需求导致而划分

代码（功能）错误（最多）：功能错误、性能、安全（开发问题）

界面优化：界面、易用性测试

设计缺陷：建议优化的bug，如某些功能不符合用户的使用规范。产品问题

2、bug的等级

bug的等级，划分为三或四级，也有五级的，等级越高，被修复的等级可能也会高一些，然后有些公司还会根据你提供的bug数量和bug等级考察你的绩效，很多情况下，我们提交的bug的大致等级差不多即可，没有严格区分。

（1）致命错误(block)

1、常规操作引起的系统崩溃、死机、死循环、闪退

2、造成数据泄露的安全性问题，比如恶意攻击造成的账号私密信息泄露

3、设计金钱计算（延时），单纯的延时不算致命错误

4、阻断性测试，所有的测试工作进行不下去（冒烟测试），如过许多操作需要在登录账号后进行，那么登录失败这个问题是致命的，否则就不是。

（2）严重错误 （critical）

1、重要功能不能实现，如微信的视频聊天

2、错误的波及面广，影响到其它重要功能正常实现，次要功能影响到与之关联的重要功能

3、非常规操作导致的程序崩溃、死机、死循环、闪退，如支付连点导致闪退

4、外观（界面）难以接受的缺陷，界面非常难看等等

5、密码明文显示，（界面+数据库）

6、偶尔的致命性bug。致命性错误偶尔出现，复现率=复现次数/总测试次数

（3） 一般错误（major）最多

不会影响产品的运行，不会成为故障起因，但会产品外观和下道工序影响较大的缺陷

1、次要功能不能正常实现

2、操作界面错误（包括数据窗口内列名定义、含义不一致）

3、查询错误、数据显示错误。

4、简单的输入限制放到前端进行控制（如账号密码的格式限制应该放在前端）

5、删除操作未给提示（容易导致误操作）

6、偶现的严重性bug

（4 ）细微错误（minor）

界面方面的问题，描述错误、错别字、改进建议等不算错误但可以改进的错误

3、bug的类型及等级判断

1、用户输入正确的用户名和密码不能登录网站

看软件，qq致命的，爱奇艺严重的

2、客户需求要有充值功能，但是网站没有做

重要的功能没有实现---严重错误

3、网站充值后，出现金额错误

延时后正确，严重，延迟后粗欧文，致命错误

4、在某购物app上进行商品搜索时，闪退回到收集桌面  ---1

5、在某购物app上搜索商品时，手机卡死  ---1

6、关闭按钮在痰喘左侧

使用多---2. 使用不多---3

7、app某个图表显示太小或者像素失真  ---3

8、某个提示语需要改进一下，用户对于专业术语不太懂----4

9、忘记密码，功能没有实现

次要功能没有实现----3

4、*bug的生命周期

就是一个bug被发现到这个bug被关闭的过程，你觉得这个过程有哪些步骤？

生命周期中一般缺陷状态：

新建(提bug）—>指派——>已解决——>待验证——>关闭

new->assignde->resolved-fixed->verifield->closed

我们发现了一个bug，把这个bug进行指派给对应的开发人员，开发受理并对bug进行修复，修复完后状态变成已解决，bug回到测试人员手里，由测试在开发解决的那个版本上进行验证，看看是否真正解决好了，如果解决好了那就把这个bug关闭。如果没有解决好，需要重新打开(激活）->指派……重复这个过程

中间其他状态：拒绝、延期等

5、*bug的跟踪管理流

5、实际结果与预期结果不一致一定是bug吗？不一定

1、发现bug一定要确定bug（有可能是环境问题、操作问题导致），提交bug（缺陷管理工具）---new

2、指派给开发/开发组长，由开发组长去分配

3、研发确认bug

异常N：

   1、重复的bug（已有人提交，要求开发重复的bug编号加入备注）

  测试：确认bug是否重复，是的话bug关闭（避免提交重复bug，搜索bug）。不是重复的bug，加备注描述不是重复的bug原因，重新激活bug

6、不是缺陷--invalid，开发说不是bug，你认为是bug，怎么办？

首先确认bug，确认完后我们要站在用户的角度，参考成熟产品，与开发沟通，说服开发，如果开发坚持认为是bug，找产品/项目经理做最后的确认，他会告诉你这个问题是不是问题。

如果说需要修复，bug重新激活，加备注（要修复的保留证据）

如果不需修复，也要产品或相应人员发邮件等消息火来，备注截图保留证据，避免背锅侠）

无法重现--unreproduced，开发说无法重现，你也要重新确认一下，结果一，帮助开发进行重现，结果二，自己的环境也不能重现，跟踪3-5个版本，加备注说明跟踪了哪些版本都没有出现问题，--关闭bug

若偶现bug，一定要提交，写出bug的复现率，开发可以判断复现率判断bug严不严重，方便对bug进行评估

异常：1、不予解决 wont fix

开发说不解决就不解决了吗？我们需要根据bug优先级，（界面bug、建议性）进行沟通，这时测试人员也要判断有没有必要一定解决，若觉得要解决就去尝试沟通，-无果-产品----加备注--关闭

2、延期--delay

1、建议性

2、优先级低

3、改动太大、影响太大（分析）

我们要站在测试人员、评估软件质量的角度去分析，也就是这个问题不修复的话会不会影响用户的使用，衡量一下时间，在什么时候上线，那我现在在改这个bug是否来得及，bug影响程度，最后找产品经理做最后的确认--加备注，bug状态为挂起

验证bug，要在开发修改的版本里面进行验证，保证测试版本环境正确，如果问题依然存在，重新bug指派开发，开发继续修复

产品≠项目，一个产品可以包含多个项目，腾讯包含，王者、QQ等多个项目

腾讯课堂发送管道符| 实际结果是空格

截止日期一般是由开发确定，我们测试人员不需要设置截止日期

优先级不用填，由开发填，表示解决bug的优先级

重现步骤中结果最好用截图表示，清晰明了

日志：跟踪软件在什么时间做了什么事情，是一个跟踪文件，日志截图，方便开发定位问题，解决问题，也可以发送在结果里面

【期望】预期结果

【附件】上传一些可以辅助开发定位问题，解决问题的一些测试数据，如日志文件，视频（上传某个视频才导致的错误）

7、有没有你印象深刻的bug？bug的原因/bug当时怎么解决？

8、bug的生命周期？

9、当你开了一个bug，但是开发不认为是bug，如何处理？

10、你在发现bug并确认bug的过程中，对于复现率不高的bug如何处理？

11、bug单里面包含什么内容？

10、测试计划编写

测试流程：项目立项-》测试需求分析--》测试计划-》测试设计-》测试执行—》测试评估-》项目结束

测试计划：一份描述测试工作计划的测试文档，对测试工作进行统筹计划安排。

测试计划编写者：测试主管/测试leader

测试人员查阅者：测试人员、测试主管/测试leader、产品、开发、销售人员

因为有非专业人员查阅，因此对于一些专用词需要进行解释

1、*测试计划包含哪些内容？

1、5W1H

why测试目的

what测试范围

when 时间安排（什么时间段做什么）

where测试环境

who测试人员

how怎么来做（测试方法+测试工具）

2、测试风险评估

当前测试工作有什么影响，存在什么风险，我们对应的方案是什么，plan b 预备方案

一般风险：

需求变更？需要做增加：测试时间拉长，人员调配，协调，做计划的时候，时间安排做一些需求变更的预留

测试人员变动：人员调配，协调或者加班

企业测试计划文档到底什么样？

每个企业的测试计划的模板可能不一样（格式不一样），但测试计划包含的内容大体是一致的

DRAET：初稿，尚未评审

MODIEY：修改  评审完发给大家检查

RELEASE：终稿

软件测试完成度与测试点覆盖率、用例覆盖率、bug关闭率、bug遗留率

2、测试计划参考哪些因素

项目计划：告诉我们什么时候要完成项目，以便安排各个阶段

需求规格说明书：测试的内容，业务流程

概要设计说明书、详细设计说明书：某个内容、模块的测试

用户参考资料 ：测试环境准备

测试交付件：每个阶段的输出文件

服务器：磁盘空间和内存空间比个人电脑大得多

人天，10人/15天

测试计划1天

需要分析：用例设计=3:4

测试执行 ：测试用例设计=接近1:1 测试执行分为多轮

测试报告：1天或半天

eg：（测试周期两周）

需求分析（2天）

用例编写（3天，其中0.5天用例评审）

执行前准备（0.5天，包括环境搭建和冒烟）

测试执行（第一轮测试2.5天（全部测试用例的执行，找到bug）、第二轮1.5天（全部测试用例的执行，找到bug），敏捷项目时间比较紧张，一般进行2轮测试，一些大型如银行项目可能进行第三……）

测试报告（0.5天）

3、测试工作量占项目时间比例是多少？

30-40%

项目时间=开发时间+测试时间

11、测试报告

一份评估软件质量的测试文档

测试报告由谁编写：由某个指定测试人员来编写，需要从其他测试人员收集测试数据，也就是说其实每个测试人员都需要写

项目有几份测试报告：仅此一份

1、测试报告包含哪些内容：

测试范围、

测试环境、

数据统计（方便项目复盘总结）：bug数据、bug状态（各种bug数量统计）、bug类型统计、测试阶段统计（第一轮、第二轮……bug是由第一轮修改bug出现的，还是本来就有的没有发现？）、按功能模块统计

测试用例覆盖率

测试总结：包含测试用例数、执行率、成功率、缺陷关闭率、遗留bug情况（一二级修复情况、遗留bug等级，及情况说明，该说情况一定要说清楚），结论是st测试通过/不通过

6、总结

软件测试教程资料来了： 百度网盘 请输入提取码

或者评论区发送111找我免费领取。