软件测试基础理论、分类、方法、缺陷

A1 测试分类

A2 质量模型

功能、性能、兼容、易用、安全、可靠性、移植性、维护性

A3 测试流程

1、需求评审：在测试流程开始之前，测试团队需要深入理解和分析软件的需求规格说明书，以确保对软件功能和性能的测试是基于清晰的需求基础

2、计划编写：测试计划的编写包括确定测试的范围、目标、资源需求、时间安排、风险评估等内容。此阶段还涉及制定测试策略、制定测试进度和确定测试方法

3、用例设计：在用例设计阶段，测试团队根据需求规格说明书编写测试用例和测试场景。测试用例应该覆盖各种典型和边缘情况，以确保对软件功能和性能的全面测试

4、用例执行：在用例执行阶段，测试人员将运行测试用例，并记录测试结果。他们将验证软件的各项功能和性能是否符合预期，并记录测试执行的详细信息

5、缺陷管理：在整个测试过程中，测试团队会发现和报告软件中的缺陷。这些缺陷需要进行记录、跟踪和报告，同时与开发团队合作进行缺陷修复

6、测试报告：在测试结束后，测试团队将编写测试报告，总结测试执行的情况，包括测试覆盖率、缺陷统计、测试通过的功能等信息，并向相关方提交测试报告以便进行后续的决策和验收

A4 测试用例

为测试项目而设计的执行文档

练习

B1 等价类划分

等价类划分将输入数据划分为若干个等价类，即具有相同功能和行为特征的数据集合。

步骤

1、明确需求
2、划分【有效等价】和【无效等价】
3、提取数据编写用例

案例1

案例2


优化

B2 边界值分析法

步骤

1、明确需求
2、确定有效和无效等价类
3、确定边界范围值
4、提取数据编写测试用例

案例1

案例2

B3 判定表法

步骤

1、明确需求
2、画出判定表
	1)列出条件桩和动作桩
	2)填写条件项，对条件进行全组合
	3)根据条件项的组合确定动作项
3、根据规则编写测试用例

使用场景：
- 有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系
- 判定表一般适用于条件组合数量较少的（4个以内）
- 条件超过4个，就不适合覆盖所有条件，应采用（正交法）来解决

案例1


案例2

B4 场景法

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

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

案例

B5 错误推测法

应用场景:当项目用例都执行完毕，且bug修复完成，离上线还有一段时间，在这段时间中可是使用错误推荐法复测主要业务或测试未覆盖的功能

C1 缺陷

定义:软件中存在的各种问题，都为缺陷，简称bug

缺陷标准：
1、少功能
2、功能错误
3、多功能
4、缺少隐形功能
5、易用性（软件测试人员专业角度）

缺陷产生的原因：
1、需求阶段：需求描述不易理解，有歧义、错误等
2、设计阶段：设计文档存在错误或者缺陷
3、编码阶段：代码出现错误
4、运行阶段：软硬件系统本身故障导致软件缺陷

C2 软件缺陷的生命周期

1、回归测试：
常规项目回归：项目本次发布新增两个模块，最基本要测新增模块功能及新增模块关联的旧模块
非常规项目（银行、部队、航天）：新增功能，必须全部复测
2、回归bug：
上一个版本发现的缺陷，开发修复完毕，在下一个版本进行重新验证

软件缺陷的核心内容：

缺陷提交要素：

软件缺陷类型：
1、功能错误
2、UI界面错误
3、兼容性
4、数据（数据库）
5、易用性
6、建议
7、架构缺陷

总结

1、设计用例 —>执行用例 —> 缺陷（提交、验证、关闭yinx）
2、缺陷定义：任何问题（bug）
3、缺陷标准：多功能、少功能、错误、缺少隐性功能、易用性
4、描述缺陷重点：缺陷标题、前置条件、复现步骤、预期结果、实际结果、附件备注
5、提交缺陷信息：指派人、缺陷等级、修复优先级、类型、状态（统计缺陷）

案例


缺陷跟踪流程

面试题：发现缺陷后，首先会怎么办？
确定bug可复选，确定是bug，提交时，要检查缺陷是否已存在。