测试方向基础篇

1. 基础部分

   测试方向常见的基础概念以及软件生命周期，软件开发模型和测试模型，设计测试用例的方法，了解测试分类。

2. 测试管理部分

   了解什么是测试管理以及如何执行测试管理，使用禅道工具提高对测试管理的理解

3. 自动化部分

   了解什么是自动化测试以及如何编写自动化测试（非常重要，提升测试效能（测试效率 + 测试质量））

   中大厂自动化测试是测试人员中必不可少的一部分

4. 性能测试部分

   了解什么是性能测试以及基础的性能测试如何执行

什么是软件测试

软件测试就是验证软件产品特性是否满足用户的需求。

调试和测试的区别

目的

调试：发现并解决软件中的缺陷。

测试：发现软件中的缺陷。

参与角色

调试：开发人员

测试：测试人员，开发人员等，单元测试主要由开发人员来测试

执行阶段不同

调试：编码阶段

测试：测试贯穿软件的整个生命周期

软件测试的岗位

1. 软件测试工程师
2. 软件测试开发工程师

统称为测试人员，开发工程师，需要开发效能工具：自动化测试工具，代码覆盖率工具，数据构造工具。

自动化不能完全代替手工测试。

需要的能力

1. 综合素质
   1. 快速的学习能力
   2. 良好的沟通能力
   3. 良好的开发能力
2. 掌握自动化技术
3. 优秀的测试用例能力
4. 探索性思维
5. 兴趣
6. 责任感和压力

名词解释

需求

满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。

用户需求

可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。

软件需求

或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据就是软件需求

为什么用户需求不能直接作为开发和测试人员的依据呢？

需要对用户的需求进行需求分析：1.市场可行性 2. 技术可行性 （技术上无法实现，投入的人力成本和时间成本远远大于市场收益）

bug

1. 当且仅当规格说明书存在并且正确，程序与规格说明之间的不匹配才是错误。
2. 当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最总用户的合理预期的功能要求时，就是软件错误。

测试用例

测试用例是为了实施测试而向被测试的系统提供一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

软件开发的生命周期

1. 需求分析

   分析用户是否合理（市场分析，技术上分析）=》软件需求文档

2. 计划

   制定需求执行计划

3. 设计

   将需求细化成一个个任务，进行技术设计（设计哪些接口，采用哪些技术）=》产出设计文档

4. 编码

   开发人员按照需求文档以及设计文档来进行编码

5. 测试

   测试人员参考测试用例来执行测试

6. 运行维护

   项目上线之后对产品进行线上的维护 =》

   修复性维护：对项目中未发现的问题进行修复

   完善性维护：对功能进行完善

   预防性维护（居安思危）：为了避免产品在线上出现其他的问题，进行一些预防的手段。

开发模型

瀑布模型

start =》需求分析 =》计划=》设计=》编码=》测试=》end

特点：先行顺序的软件开发模式。

缺陷：测试被后置

1. 风险往往到后期的测试阶段才显露，因而失去及早纠正的机会。

2. 没有足够的时间留给测试，导致测试不充分，从而把缺陷遗留给用户

最大的缺陷在于，可以运行的产品很迟才能被看到。

适用场景：需求确定的小项目

螺旋模型

螺旋模型引入全流程的风险分析，每次分析完成后都会生成一个新的原型。

适用场景：规模庞大、复杂度高、风险大的项目

缺陷：时间拉长、人力、资金

增量模型

假如用户有一个需求，功能包含A，B，C。。

开发完A我就直接上线让用户使用

开发完C直接上线让用户使用

开发完B直接上线让用户使用

如果是一个人物画：先画头，再画身体，在画四肢（逐块建造）

迭代模型

先开发一个基础版本（包含功能A、B、C），但是A、B、C功能都比较简陋

接下来我会继续在基础版本上对ABC功能进行迭代优化

如果是一个人物画：先画一个轮廓，再细化，再补色

敏捷模型

敏捷宣言：

个体与交互重于过程和工具=》轻流程，强调人与人之间面对面的高效沟通

可用的软件重于完备的文档=》轻文档，重产出

客户协作重于合同谈判=》

相应变化重于遵循计划

在每对比中，后者并非全无价值，但我们更看重前者。

特点：轻流程，轻文档，重目标，重产出

scrum：

三个角色和五个会议。

三个角色：

1. 产品经理：收集用户的需求，编写需求文档，对产品负责的人
2. 项目经理：负责召开各种会议，协调项目，为研发团队服务
3. 研发团队：开发人员、测试人员、ui设计人员等等

需求代表列表（需求池）：专门放没有实现的用户需求

周期内需求实现的用户需求

每日会议

可交付的软件

五个会议：

1. 发布计划会议：从需求池里选取几个，开展发布计划会议
2. 迭代计划会议：各司其职，开始推动项目开发
3. 每日例会：及时了解项目进度，预知风险，规避风险
4. 演示会议
5. 回顾会议

软件测试的生命周期

需求分析：站在用户的角度：查看需求逻辑是否正确，是否符合用户习惯；站在开发人员的角度：思考需求是否可以实现，或者实现起来难度大小

测试计划：制定测试计划（包括但不限于测试的工时，人力的安排 ）

测试设计、测试开发：设计测试用例，经验丰富的白盒测试人员可以开始单元测试

测试执行：参考测试用例来执行测试

测试评估：测试人员需要记录测试、最好缺陷管理，看后进行测试的评估

软件测试贯穿于整个软件的生命周期！！！

软件的生命周期

需求分析

​ 测试也要对需求进行分析，分析需求逻辑是否合理，需求是否符合用户的行为习惯，站在开发人员的角度思考技术实现的难度，针对技术难度来合理调整需求

计划

​ 根据需求编写测试计划/测试方案

设计

​ 测试人员适当的了解设计，合理的进行测试用例的设计和调整

编码

​ 专业的白盒测试人员可以计划执行单元测试，完善、细化测试用例以及调整测试计划和方案

测试

​ 参考测试用例来执行测试

运行维护

​ 测试往往是最了解需求的人。测试人员通常来进行产品的演示和功能的介绍，期间记录下来大家的反馈建议，反馈给产品经理，成为一个新的用户需求。

如何描述一个bug

发现bug的版本

发现bug的环境

发现bug的步骤

期望的结果

实际的结果

其他

bug的级别

崩溃：阻碍开发或测试工作的问题；造成系统崩溃，死机，死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。

严重：系统主要功能丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。

一般：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。

次要：主要是一些优化建议类的问题。

bug的生命周期

测试人员创建完bug之后，开发人员要修复bug，测试人员还需要进行bug回归验证！！

new =》测试人员执行测试过程中发现bug，测试人员要创建bug

开发人员收到了bug，查看是否是bug，

open=》是bug

rejected=》开发人员不认为是bug

delay=》暂时修改

fixed=》立即修改

进入bug回归验证

closed=》确实修复了

reopen=》没完全修复

测试模型

V模型

概要设计：设计整体，架构框架

详细设计：模块和模块之间的详细设计

单元测试和集成测试：通常由开发人员来执行

特点：

1. 明确标注了测试类型
2. 明确标注了测试阶段和开发阶段之间的对应关系

缺点：测试后置

W模型

测试从需求开始阶段就介入了

缺点：

1. 上一个阶段完成下一个阶段才能开始
2. 开发模型和测试模型也保持着一种前后的线性关系

跟开发产生争执怎么办

1. 具有批判性思维，多反思自己是不是bug描述的不清楚。可能是无效的bug

2. bug等级一定要有理有据

   提了一个bug是严重级别，开发不认可

3. 合理友好的进行沟通，站在用户的角度反问：如果你是用户，你能接受这样吗？

   bug可以忽略不需求要修改，小问题

4. 不仅能够提出问题，最好也能够给出解决方案。

5. 组织bug评审

   邀请代表参加bug评审：产品代表、开发代表、测试代表

   1. 如何解决bug
   2. 如何预防类似的bug

设计测试用例的万能思路

对某个物品、功能进行测试

功能测试 + 界面测试 + 性能测试 + 兼容性测试 + 易用性测试 + 安全测试

设计测试用例的方法

针对有需求的案例来设计测试用例

需求分析——需求有哪些功能——设计测试点——设计测试用例

不能通过穷举法来设计测试用例

等价类

分区分块=》使用较少的测试用例达到符合的系统测试覆盖

针对需求输入范围划分若干个等价类，从其中一个等价类里取出一个用例，若该测试用例测试通过，则认为该测试用例所在的等价类通过。

需求：姓名长度是6~200位，该如何来设计测试用例

有效等价类：针对需求来说是有效且有意义的数据构成的集合

无效等价类：针对需求来说是无效且没有意义的数据构成的集合

1. 确定有效等价类和无效等价类
2. 编写测试用例

有效等价类：6~200

无效等价类：小于6，大于200

边界值

边界值法通常是对等价类的补充。

设计边界值

次边界值：就是边界值左右的值

判定表

一种表达逻辑判断的工具

需求：订单已提交，订单合计金额大于300元或者订单有红包，则认为该订单属于有优惠的订单，否则属于没有优惠的订单。

判定表设计测试用例的步骤：

1. 确认输入和输出

   输入条件：金额大于300元、有红包、订单已提交

   输出条件：有优惠，无优惠

2. 找出输入条件和输出条件的关系

   需要金额大于300，或有红包，并且订单已提交，才是有优惠

3. 画判定表

   

4. 根据判定表编写测试用例

   金额大于300，没有红包，提交订单，结果为有优惠。

   金额不大于300，有红包，提交订单，结果有优惠。

   …

适用场景：需要考虑输入之间的组合关系，不同的组合关系对应的输出结果不同。

正交法

需要用到正交表。

因素数：输入的条件

水平数：输入条件对应的结果（不是输出条件）

如果需求是用户填写，姓名，电子邮箱，密码，确认密码，验证码等，这些就是因素数，

对于这些信息的填写和不填写就是水平数。

正交表的特性：

1. 每一列中，不同的数字出现次数相等。
2. 任意两列中数字的排列方式齐全而且均衡

专门生成正交表的工具——allparis

通过正交表法设计测试用例的步骤：

1. 找到因素数和水平数
2. 用allparis工具来生成正交表
3. 根据正交表来编写测试用例
4. 补充测试用例

场景设计法

主要分为基本事件流和多个备用事件流

编写测试用例：

1. 基本事件流

   插入银行卡，输入正确的密码，选择取款业务，选择小于5万且金额是50倍数的金额，等待出钞，最终出卡

2. 备用事件流

   1. 插入银行卡，第一次密码输入错误，第二次输入正确的密码，选择取款业务，选择小于5万且金额是50的倍数的金额，等待出钞，最终出卡
   2. 插入银行卡，前两次密码输入错误，第三次输入正确的密码，选择取款业务，选择小于5万且金额是50的倍数的金额，等待出钞，最终出卡
   3. …

错误猜测法

依赖测试人员的个人工作经验和积累