提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档
软件测试基础
一、认识软件测试
1.1什么是软件测试？
使用技术手段验证软件是否满足需求
1.2软件测试目的
用最少的人力、物力、财力、找到软件中的问题并修复，从而降低商业风险
二、常见的测试分类
2.1 主流的测试技能
功能测试，接口测试，web自动化测试，性能测试
2.2 按测试阶段划分
（1）单元测试：正对程序的源代码进行测试。
（2）集成测试：又称接口测试，针对模块之间访问地址进行测试。
（3）系统测试：对整个系统进行测试包括功能、兼容性、文档等测试。
（3）验收测试：主要分为内测、公测；使用不同人群来发掘项目缺陷。
内测：公司内部进行测试
公测：让玩家来进行测试
2.3 按代码可见度划分
（1）黑盒测试：又称功能测试，看不见源代码只能针对功能进行测试。
（2）灰盒测试：又称接口测试，只能看见部分代码。
（3）白盒测试：又称单元测试，针对程序源代码进行测试
拓展-总结
1.系统测试和黑盒测试重点核心是**功能测试**
2.集成测试和灰盒测试又称**接口测试**
3.单元测试和白盒测试是对**代码**进行测试
4.自动化测试归属**功能测试**
5.性能测试、安全测试归属**专项测试**
2.4 测试策略
冒烟测试：大规模执行测试之前，针对程序主功能进行验证，保证程序具备可测性。
准入标准：冒烟测试的测试用例100%通过
三、模型
3.1 软件质量模型（ISO/IEC 25010）
（1）功能性：功能满足需求
（2）性能效率：性能满足实际需求
（3）兼容性：软件能与主流硬件或软件兼容
（4）易用性：便于使用
（5）可靠性：性能和功能应用可靠
（6）信息安全：信息在传输或者存储过程中的安全程度
（7）可维护性：便于维护
（8）可移植性：具备迁移和便捷性
3.2 软件测试模型（W模型）
说明：W模型简称双V模型，即以开发为主导的一个“V”和以测试为主导的另一个”V“构成。
优点：测试伴随整个产品的开发周期，测试对象不仅是程序还有需求、设计文档
测试介入较早，及早发现问题，降低修复成本
缺点：实施起来比较复杂，难度大，对于需求阶段和设计阶段的测试设计要求较高
四、软件测试流程
（1）需求分析：确保各部门需求理解一致，站在不同的角度对需求进行（查、漏、补缺）
（2）计划编写：
测什么：测试目标和范围
谁来测：人员进度安排
怎么测：测试策略与测试工具
（3）用例设计：设计执行测试的文档
（4）执行用例：项目模块开发完成开始执行用例文档实施测试
（5）缺陷管理：对执行用例过程中发现的缺陷进行管理
（6）测试报告：实施测试结果文档
五、测试用例
5.1 什么是测试用例
用例：用户使用的案例
测试用例：是为测试项目而设计的执行文档（用户使用的案例）
考虑点：质量模型（功能，性能，兼容，易用性，安全）
5.2 测试用例的作用
（1）防止漏测
（2）实施测试的标准
5.3 用例设计编写格式-说明
（1）用例编号：项目+模块+编号
（2）用例标题：预期结果+操作步骤
（3）所属模块：所属项目或模块
（4）优先级：表示用例的重要程度或者影响力P0~P4（P0最高）
（5）前置步骤：要执行此条用例，有哪些前置操作
（6）测试步骤：描述操作步骤
（7）测试数据：操作的数据，没有的话可以为空
（8）预期结果：期望达到的结果
5.4 花瓶设计测试用例
六、如何设计测试用例
6.1等价类划分法（解决穷举问题）
说明：在所有测试数据中，具有某种共同特征的数据集合进行划分。
分类：
有效等价类：所有有效数据集合取一个即可
无效等价类：不满足需求的数据集合
步骤：
1.明确需求
2.确定有效和无效等价类
3.提取数据编写测试用例
6.1.1 验证QQ账号的合法性
要求：6~10位自然数
6.1.2 验证某城市电话号码正确性
要求：
- 区号：空或者是三位数字
- 前缀码：非0且非1开头的三位数字
- 后缀码：四位数字
6.1.3 适用场景
针对：需要大量数据测试输入，但没法穷举测试的地方
（1）输入框
（2）下拉列表
（3）单选复选框
6.2 边界值分析法（解决边界限制问题）
6.2.1 边界范围节点
选取正好等于、刚好大于、刚好小于边界的点作为测试数据
上点：边界上的点
离点：距离上点最近的点（刚好大于、刚好小于）
内点：范围内的点（区间范围内的数据）
6.2.2 验证标题长度的合法性
要求：标题长度大于0，小于等于30个字符
6.2.3 使用场景
（1）在等价类的基础上针对有边界范围的测试数据输入的地方（重点关注边界）
（2）常见词语描述：大小、尺寸、重量、最大、最小、至多、至少等修饰词语
（3）典型代表：有边界范围的输入框类测试
6.3 判定表法
6.3.1 判定表定义及组成部分
定义：是一种以表格形式表达多条件逻辑判断的工具
组成：
条件桩：列出问题中的所有条件
动作桩：列出问题中可能采取的操作
条件项：列出条件对应的取值，所有可能情况下的真价值
动作项：列出条件项，各种取值情况下应该采取的动作结果
规则：
判定表中贯穿条件项和动作项的一列就是一条规则
假设有n个条件，每个条件的取值有两个（0，1），全组合有2的次方种规则
6.3.2 订购单检查
规则：
（1）如果金额大于500元，又未过期，则发出批准单和提货单
（2）如果金额大于500元，但过期了，则不发批准单与提货单
（3）如果金额小于等于500元，则不论是否过期都发出批准单和提货单
（4）在过期的情况下不论金额大小还需要发出通知单。
6.3.3 文件修改案例
规则：
（1）输入的第一列字符必须是A或B
（2）第二列字符必须是一个数字
（3）如果第一列字符不正确，则给出信息L
（4）如果第二列字符不正确，则给出信息M
（5）如果两列字符输入正确，则修改文件成功
6.3.4 使用场景
（1）有多个输入条件，多个输出结果，输入条件有组合关系，输入条件和输出结果之间有依赖（制约）关系
（2）判定表一般适用于条件组合数量较少的情况下（4个条件以下）
如果碰到多条件组合大于4个相互依赖可以使用正交表和因果图来实现
6.4 场景法
6.4.1 介绍
说明：场景法也叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。
意义：
（1）用户平时使用的不是单个功能，而是多个功能的组合起来进行使用。
（2）测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试。
6.4.2 流程图
使用标准图形和箭头来表达程序或业务的走向
6.5 错误推荐法
6.5.1 介绍
定义：通过经验推测系统可能出现的问题
思想：根据经验列举出可能出现问题的清单，根据清单分析问题可能原因，推测发现缺陷。
6.5.2 使用场景
（1）时间紧任务量大时，根据之前项目类似的经验找出易出错的模块重点测试。
（2）实际宽裕通过该方法列出之前问题较多的模块再次测试。
七、缺陷
7.1 缺陷的定义
软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug。
7.2 缺陷的判定标准
（1）软件未实现需求（规格）说明书中明确要求的功能 -少功能
（2）软件出现了需求（规格）说明书中指明不应该出现的错误 -功能错误
（3）软件实现的功能超出需求（规格）说明书指明的范围 -多功能
（4）软件未实现需求（规格）说明书中虽未指明但应该要实现的功能 -隐性功能错误
（5）软件难以理解，不易使用，运行缓慢，用户体验不佳 -不易使用
7.3 缺陷产生的原因
需求阶段：需求描述不易理解，有歧义、错误等。
设计阶段：设计文档存在错误或者缺陷
编码阶段：代码出现错误
运行阶段：软硬件系统本身故障导致软件缺陷
7.4 软件缺陷的生命周期
注入bug -> 发现bug -> 修复bug5
7.5 软件缺陷的核心内容
（1）缺陷标题：描述缺陷的核心问题
（2）缺陷的预置条件：缺陷产生的前提
（3）缺陷的复现步骤：复现缺陷的过程
（4）缺陷的预期结果：希望得到的结果
（5）缺陷的实际结果：实际的到的结果
（6）缺陷的必要附件：图片、日志等信息
7.6 缺陷提交要素
通过缺陷管理工具与开发交流使用
（1）缺陷的报告编号：缺陷的唯一标识
（2）严重程度：
严重（S1）：主功能
一般（S2）：次要功能
微小（S3）：易用性、界面
建议（S4）：建议性问题
（3）缺陷优先级：
Priority0：24小时之内解决
Priority1：发布前必须修复
Priority2：可以在下一个版本中修复
（4）Bug类型：代码问题、兼容性、设计缺陷、性能问题
（5）缺陷状态：
New：新建
Open：打开
Closed：关闭
Postponed：延期
7.7 缺陷类型
7.8 缺陷编写
7.8.1 缺陷报告示例
7.8.2 缺陷跟踪流程
7.8.3 提交缺陷注意事项
（1）可重现：缺陷可以复现
（2）唯一性：一个缺陷上报一个问题
（3）规范性：符合公司或者项目要求
7.9缺陷管理工具
7.9.1 禅道
一种缺陷管理工具
特点：
（1）国产、免费、开源、简单、轻量级
（2）三管融合（产品管理、项目管理、质量管理）
总结
以上就是软件基础的所有内容，希望对你有所帮助。
标签：基础,用例,测试用例,6.3,测试,缺陷,软件测试 From： https://blog.csdn.net/m0_73996481/article/details/145011243