软件测试

定义：使用技术手段运行软件找出缺陷的过程，确保功能正常，用户体验好

• 技术手段：测试理论、测试方法、编程语言等
• 运行软件方式：人工、工具、代码

目的：减少软件缺陷，保障软件质量

AI测试

AI：人工智能（Artificial Intelligence），是一种计算机程序，通过模拟人类的思维过程，从而实现某些人类智能的任务。

如何写提示词？
身份+任务+要求+背景+输出

测试分类

按生产阶段划分

• 单元测试：针对程序源代码进行测试
• 集成测试：针对模块之间功能交互进行测试
• 系统测试：针对整个系统进行测试
• 验收测试：以用户代表为主验证项目是否符合预期需求

按代码可见度划分

• 黑盒测试：源代码不可见、UI功能可见。关注数据输入结果输出—系统测试
• 灰盒测试：部分源代码可见。关注输入输出、数据访问通道—集成测试
• 白盒测试：全部源代码可见、UI不可见。 关注代码本身语法逻辑—单元测试

其他

• 冒烟测试：对核心功能的验证（作用：保障提测内容具备可测性）
  

• 回归测试
  对已修复bug\更新后对已测内容再次测试（保证bug修复)。
  
  对已修复功能\更新后对已测内容再次测试(确保新功能对旧功能没有影响)
  

质量模型

质量模型是衡量软件质量的指标体系

软件质量：软件与明确地和隐含地定义得需求相一致得程度。（软件符合需求说明满足质量要求）

质量模型主要包含八大特性：功能性、性能、兼容性、易用性、可靠性、安全性、可维护性、可移植性

软件测试流程

测试流程作用：明确测试人员如何开展测试工作依据

如何开展软件测试？
1.需求评审
2.编写测试计划与方案
3.编写测试用例并评审
4.执行测试用例
5.提交跟踪缺陷
6.编写测试报告

测试用例

定义：为测试项目而设计的执行文档
作用：使得测试点能被精准的执行，便于团队协作
核心内容：用例编号、用例标题、所属模块、优先级、前置条件、测试数据、测试步骤、预期结果

测试用例设计方法

等价类划分法

等价类：在所有测试数据中，具有某种共同特征的数据子集。
有效等价类：满足需求的数据集合
无效等价类：不满足需求的数据集合

设计用例步骤
1.明确需求
2.确定有效和无效等价类
3.提取数据编写测试用例

适用场景
针对需要有大量数据输入的测试场景，但无法穷举测试的地方。表单类页面元素测试使用（输入框、下拉框、单选框、复选框）等。典型代表：页面的输入框类测试。

边界值分析法

上点：刚好是边界上的点（不考虑区间开闭）
离点：离边界最近的点（考虑区间开闭，开区间选择内部离点，闭区间选择外部离点），选择2个（不包含上点选择范围内的点，包含上点选择范围外的点）
内点：边界范围内的任意点，必选（建议选择中间范围）

设计用例步骤
1.明确需求
2.确定有效和无效等价类
3.确定边界范围值
4.提取数据编写数据用例

适用场景
在等价类的基础上，针对有边界范围的测试数据输入的地方(重点关注边界)，常见词语：大小、尺寸、重量、最大、最小、至多、至少等修饰词语。典型代表：有边界范围的输入框类测试。

判定表法

判定表：一种以表格形式表达多条件逻辑判断的工具
组成：

• 条件桩：列出问题中的所有条件，列出条件的次序无关紧要。
• 动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束。
• 条件项：列出条件对应的取值，所有可能情况下的真假值。
• 动作项：列出条件项的、各种取值情况下应该采取的动作结果。
  规则：
  判定表中贯穿条件项和动作项的一列就是一条规则
  假设有n个条件，每个条件的取值有两个(0，1)，全组合有2的n次方种规则

设计用例步骤
1、明确需求
2、画出判定表

• 列出条件桩和动作桩
• 填写条件项，对条件进行全组合
• 根据条件项的组合确定动作项
• 简化、合并相似规则(有相同的动作)

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

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

场景法

场景法也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。
意义：
用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用
测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试

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

错误推荐法

错误推荐法：通过经验推测系统可能出现的问题

适用场景
时间紧任务量大时，根据之前项目类似经验找出易错的模块重点测试；时间宽裕时，通过该方法列出之前出现问题较多的模块再次测试。

软件缺陷

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

判定标准

• 软件未实现需求规格说明书中明确要求的功能 —少功能
• 软件出现了需求规格说明书中指明不应该出现的错误—功能错误
• 软件实现的功能超出需求规格说明书指明的范围—多功能
• 软件未实现需求规格说明书中虽未明确指明但应该实现的要求 —隐性功能错误
• 软件难以理解，不易使用，运行缓慢，用户体验不好 —不易使用

产生原因

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

软件缺陷的生命周期：注入bug—>发现bug—>修复bug

缺陷的核心内容（描述缺陷时使用）

• 缺陷的标题：描述缺陷的核心问题
• 缺陷的预置条件：缺陷产生的前提
• 缺陷的复现步骤：复现缺陷的过程
• 缺陷的预期结果：希望得到的结果
• 缺陷的实际结果：实际得到的结果
• 缺陷的必要附件：图片、日志等信息（可以为空）

缺陷提交的要素（通过缺陷管理软件与开发交流时使用）

缺陷类型
通常包括功能缺陷（功能未实现或错误）、界面缺陷（UI显示或交互问题）、逻辑缺陷（代码逻辑不严谨导致的条件遗漏）、性能缺陷（响应慢或资源消耗高）、兼容性缺陷（环境差异导致的问题）、安全缺陷（系统漏洞或数据泄露风险）以及易用性缺陷（用户体验不佳或操作不便）

怎么区分前端bug还是后端bug？
如果是界面或兼容性的错误为前端bug
如果是功能错误区分前端和后端bug，需要抓包（将前端给后端的所有请求信息进行拦截，检查请求和响应的数据是否正确）如果请求没有错误，那就是后端有问题；如果请求错误，就是前端有问题。

缺陷编写示例

缺陷ID：用例ID
缺陷标题：操作数据描述+预期+实际
缺陷描述：测试步骤+测试数据

缺陷的跟踪流程

发现bug以后，首先会怎么办？确认bug可复现

缺陷管理工具—禅道，对测试而言的作用：缺陷管理，用例管理