【测试开发篇1】软件测试基础

课程链接：06-测试分类_哔哩哔哩_bilibili

软件测试定义：使用技术手段验证软件是否满足需求

1.常见测试分类

1.1 按测试阶段划分

单元测试：针对程序源代码进行测试

集成测试：又称接口测试，针对模块之间访问地址进行测试。

系统测试：对整个系统进行测试包括功能、兼容、文档等测试。

验收测试：主要分为内测、公测，使用不同人群来发掘项目缺陷。

1.2 按代码可见度划分

分为：黑盒测试，灰盒测试，白盒测试

2.质量模型

说明：衡量一个优秀软件的维度

质量模型：功能、性能、兼容、易用、安全、可靠性、移植性、维护性

3.测试流程

• 需求评审: 确保各部门需求理解一致
• 计划编写: 测什么、谁来测、怎么测
• 用例设计: 验证项目是否符合需求的操作文档
• 用例执行: 项目模块开发完成, 开始执行用例文档实施测试
• 缺陷管理: 对缺陷进行管理的过程
• 测试报告: 实施测试结果文档

4.用例

4.1 什么是用例

用例: 用户使用的案例

4.2 什么是测试用例

测试用例: 是为测试项目而设计的执行文档

4.3 测试用例的作用

• 防止漏测
• 执行测试的标准

4.4 用例测试编写格式

• 用例编号: 项目_模块_编号
• 用例标题: 预期结果(测试点)
• 模块/项目: 所属项目或模块
• 优先级: 表示用例的重要程度或者影响力p0-p4 (p0最高) 重要程度由用户的使用频率决定
• 前置条件: 要执行此条用例，有哪些前置操作
• 测试步骤: 描述操作步骤
• 测试数据: 操作的数据，没有的话可以为空
• 预期结果: 期望达到的结果

5.软件开发模型

5.1 瀑布模型

瀑布模型

• 需求分析

研发分析需求说明书

判断需求的可实现性

• 概要设计

用到具体的技术点

大致模块划分

• 详细设计

详细到可以为编码做支持

类和类关系, 类的设计

函数设计

各个接口的细节

数据库表的关系, 字段关系

• 编码

依托于详细设计进行编码操作

• 测试
• 维护

上线后也是需要持续维护

特点：

1.是线性模型的一种，在所有模型中占有重要地位，是所有其他模型的一个基础;

2.每一个阶段执行-一次，文档驱动，按线性顺序进行软件开发。

优缺点：

• 优点

• • 每个阶段很清晰
  • 只需要关注后续阶段

• 缺点

• • 依赖于需求，不能适应需求变化
  • 风险到项目后期才体现,失去早期纠正的机会

5.2 螺旋模型

优点：引入风险分析

缺点：风险分析需要专业的知识和人员

5.3 增量模型

对于每一个小的需求，也就是增量，无须等到所有需求都出来，分开进行编码和测试、分开上线

5.4 迭代模型

开发迭代是一次完整地经过所有工作流程的过程 ，每一个迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集

5.5 敏捷模型

敏捷宣言：

1、个体以及互动而不是过程和工具

2、可用的软件而不是完整的文档

3、客户合作而不是合同谈判

4、应对变更而不是遵循计划

scrume

三大角色

scrum里面的角色

scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成

• • 其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。
  • scrum master负责召开各种会议，协调项目，为研发团队服务。
  • 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

6.测试过程模型

6.1 测试v模型

优点：

包含了底层和高层的测试过程

每个步骤都是文档驱动的

缺点：

和研发瀑布模型一样, 不能适应需求的改变灵活性比较低

6.2 测试w模型

6. 设计测试用例的方法

6.1 等价类划分法

说明：在所有测试数据中, 具有某种共同特征的数据集合进行划分。

分类:

有效等价类: 满足需求的数据集合

无效等价类: 不满足需求的数据集合

例：6-8位账号，有效等价为6-8位，无效等价为小于6，大于8，

只取其中一个为代表

步骤:

1.明确需求

2.确定有效和无效等价类

3.提取数据编写测试用例

适用场景：

针对: 需要有大量数据测试输入,但是没法穷举测试的地方。

输入框

下拉列表

单选复选框

典型代表: 页面的输入框类测试。

---

案例：电话

要求：

1. 区号:空或者是三位数字
2. 前缀码:非“0”且非“1”开头的三位数字
3. 后缀码:四位数字

此时根据有效等价和无效等价，得出共有10个用例（将有效数据进行合并，得2个，将无效数据每个都进行控制变量，得到8个）

6.2 边界值划分法

边界值法作为一种等价类法的补充，通过选择边界值点编写测试用例

6.3 判定表法

案例: 验证“若用户欠费或者关机，则不允许主被叫”功能的测试

说明:

• 等价类边界值分析法主要关注单个输入类条件的测试
• 并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试。

定义: 是一种以表格形式表达多条件逻辑判断的工具

组成:

• 条件桩:列出问题中的所有条件,列出条件的次序无关紧要。
• 动作桩:列出问题中可能采取的操作，操作的排列顺序没有约束。
• 条件项:列出条件对应的取值，所有可能情况下的真假值。
• 动作项:列出条件项的、各种取值情况下应该采取的动作结果。

步骤：

1、明确需求

2、画出判定表

1) 列出条件桩和动作桩

2) 填写条件项，对条件进行全组合

3) 根据条件项的组合确定动作项

4) 简化、合并相似规则(有相同的动作)

3、根据规则编写测试用例

使用场景：

• 有多个输入条件，多个输出结果,输入条件之间有组合关系,输入条件和输出结果之间有依赖(制约)关系
• 判定表一般适用于条件组合数量较少的情况(比如4个条件以下)

6.4 场景法

流程图：

流程图对测试人员有什么作用?

1、能够看懂流程图，设计业务用例

2、当需求文档信息不全是,能够根据需求,梳理出流程

网页版工具: ProcessOn思维导图流程图-在线画思维导图流程图_在线作图实时协作

Windows工具: visio

提示: 业务用例是根据流程图来梳理的,需要先了解流程图

介绍：

• 说明:

• • • 场景法也可以叫流程图法, 是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。

• 意义:

• • • 用户使用角度: 用户平时使用的不是单个功能，而是多个功能组合起来进行使用
    • 测试人员角度: 平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试

适用场景：

根据实际的应用场景, 来测试业务用例，可以使用场景法

案例（ATM取款流程）：

最左边的那条全部通过业务线路，称为冒烟测试用例，只有冒烟测试通过，程序才具有可测性

6.5 错误推测法

定义：通过经验雅测系统可能出现的问题

思想：根据经验列举出可能出现问题的清单，根据清单分析问题可能原因，推测发现缺陷

场景: 1、时间紧任务量大时，根据之前项目类似经验找出易出错的模块重点测试

2、时间宽裕通过该方法列出之前出现问题较多的模块再次测试

应用场景: 当项目用例都执行完毕，且BUG修复完成，离上线还有一段时间，在这段时间中可是使用错误推测

法复测主要业务或测试未覆盖的功能。

7.缺陷

7.1 用例执行

说明: 执行结果与用例的期望结果不一致(含义)，为缺陷 。

7.2 缺陷相关概念

定义：软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug。

判定标准：

软件未实现需求(规格)说明书中明确要求的功能--少功能

软件出现了需求(规格)说明书中指明不应该出现的错误--功能错误

软件实现的功能超出需求(规格)说明书指明的范围--多功能

软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求--隐性功能错误

软件难以理解，不易使用，运行缓慢，用户体验不好--不易使用

产生的原因：

需求阶段: 需求描述不易理解，有歧义、错误等

设计阶段: 设计文档存在错误或者缺陷

编码阶段: 代码出现错误

运行系统: 软硬件系统本身故障导致软件缺陷

生命周期：

7.3 缺陷要素

核心内容：

缺陷描述: 发现缺陷以后如何描述，让别人看的懂。

缺陷提交: 指派人、优先级、类型、

类型：

7.4 缺陷流程

缺陷报告示例：

缺陷的跟踪流程：

提交缺陷注意事项：

• 可重现：缺陷可以复现
• 唯一性：一个缺陷上报一个问题
• 规范性：符合公司或者项目要求

缺陷编写规范：

• 准确，具体，简洁易懂，次序清晰

7.5 缺陷管理工具

禅道介绍：

特点:

国产、免费、开源、简单、轻量级

三管融合(产品管理、项目管理、质量管理)

禅道特点:

• 三权分立:

• • 产品部门一构想者
  • 研发部门一执行者
  • 测试部门一保证者

• 四角协同:

• • 产品经理
  • 项目经理
  • 研发团队
  • 测试团队

禅道使用流程：

7.6 缺陷标题分析