🔥个人主页： 中草药
一、Bug
概念
⼀个计算机bug指在计算机程序中存在的⼀个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障(fault)，这些bug使程序无法正确的运行。Bug产生于程序的源代码或者程序设计阶段的疏忽或者错误。准确而言：
1、当且仅当规格说明是存在的并且正确，程序与规格之间的匹配才是错误的。
2、当需求规格说明书没有提到的功能，判断标准以最终用户为终；当程序员没有实现其最终用户合理的功能要求时就是软件错误。
描述Bug的要素
核心要素：
标题：简洁描述问题（如“首页轮播图在iOS 15下无法滑动”）。
环境：操作系统、浏览器版本、设备型号等。
步骤：可复现的操作流程（附截图或视频）。
预期与实际结果：明确对比差异。
举例
标题 微信发红包领取总金额与实际发送金额不符
问题出现的版本：8.0.54(线上版本)
问题出现的环境：Android 16
问题出现的步骤
- 打开微信
- 打开群对话框
- 点击对话框右下角“+”
- 选择“红包“功能
- 选择拼手气红包
- 输入金额
- 输入密码，点击发送
- 红包被群友领取
预期结果：红包被领取，不同的用户领取到的金额不完全相同，整体存在差异，领取总金额等于发送的金额不同的用户领取到的金额
实际结果：红包被领取，不同的用户领取到的金额不完全相同，整体存在差异，领取总金额不等于发送的金额
优先级：
指定负责人：
备注：
Bug描述要素实际根据企业需求来定，描述项并不完全相同
Bug的级别
Bug级别帮助团队确定哪些问题需要优先修复，根据Bug的严重性，团队可以合理分配开发、测试和运维资源
崩溃，严重，一般，次要
1. 崩溃（Critical）
描述：导致系统崩溃、数据丢失、或主要功能完全失效阻碍开发和测试工作的Bug。
影响：用户无法继续使用系统，可能导致重大业务损失或安全风险。
示例：系统崩溃、登录功能完全失效、代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等(该问题在测试中较少出现，一旦出现应立即中止当前版本测试）
2. 严重（Major）
描述：影响主要功能，但系统仍可运行。
影响：用户无法完成关键操作，体验严重受损。
示例：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他 功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用 冲突，安全问题、稳定性等。
3. 一般（Moderate）
描述：影响次要功能或非核心业务流程，不影响使用。
影响：用户可能通过其他方式完成任务，但体验不佳。
示例：界面显示错误、部分功能响应缓慢、操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多)
4. 次要（Minor）
描述：对系统功能影响较小，通常为界面或用户体验问题。
影响：用户可能注意到问题，但不影响主要功能。
示例：错别字、界面格 式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等(此类问题在测试初期较多，优先程度较低;在测 试后期出现较少，应及时处理)
Bug的生命周期
Bug的生命周期（Bug Life Cycle）是指一个Bug从被发现到最终关闭的整个过程。它描述了Bug在不同阶段的状态流转，帮助开发团队和测试人员跟踪和管理问题。以下是Bug生命周期的典型阶段：
1. 新建（New）
描述：测试人员发现并报告一个新的Bug。
操作：测试人员提交Bug报告，包括详细描述、重现步骤、截图等信息。
下一状态：待分配（Open）。
2. 待分配（Open）
描述：Bug被确认并等待分配给开发人员。
操作：测试负责人或项目经理确认Bug的有效性，并将其分配给相关开发人员。
下一状态：已分配（Assigned）。
3. 已分配（Assigned）
描述：Bug已分配给具体的开发人员。
操作：开发人员开始分析问题并尝试修复。
下一状态：修复中（In Progress）。
4. 修复中（In Progress）
描述：开发人员正在修复Bug。
操作：开发人员编写代码、修复问题，并在本地环境中测试。
下一状态：已修复（Fixed）。
5. 已修复（Fixed）
描述：开发人员完成修复并提交代码。
操作：开发人员将修复后的代码合并到主分支，并标记Bug为“已修复”。
下一状态：待验证（Pending Verification）。
6. 待验证（Pending Verification）
描述：修复后的Bug等待测试人员验证。
操作：测试人员在最新版本中验证Bug是否已修复。
下一状态：
如果修复成功，状态变为“已验证（Verified）”。
如果修复失败，状态变为“重新打开（Reopen）”。
7. 已验证（Verified）
描述：测试人员确认Bug已修复。
操作：测试人员验证并通过Bug修复。
下一状态：已关闭（Closed）。
8. 已关闭（Closed）
描述：Bug已完全解决并关闭。
操作：Bug被归档，不再需要进一步处理。
下一状态：无（生命周期结束）。
9. 重新打开（Reopen）
描述：测试人员验证后发现Bug未完全修复。
操作：Bug被重新打开，并再次分配给开发人员。
下一状态：修复中（In Progress）。
10. 拒绝（Rejected）
描述：开发人员认为Bug无效或不符合预期行为。
操作：开发人员拒绝修复，并说明原因。
下一状态：已关闭（Closed）。
11. 推迟（Deferred）
描述：Bug在当前版本中不修复，计划在后续版本中处理。
操作：Bug被标记为“推迟”，并记录在后续版本的修复计划中。
下一状态：在后续版本中重新打开（Reopen）。
12. 重复（Duplicate）
描述：Bug已被其他测试人员报告过。
操作：标记为“重复”，并关联到原始Bug。
下一状态：已关闭（Closed）。
13. 无法重现（Non-Reproducible）
描述：开发人员或测试人员无法复现Bug。
操作：标记为“无法重现”，并记录相关信息。
下一状态：已关闭（Closed）。
14. 建议（Enhancement）
描述：Bug实际上是功能改进建议。
操作：标记为“建议”，并记录为需求或改进点。
下一状态：已关闭（Closed）。
与开发发生争执怎么办（高频）
1、首先检查自身，是否将Bug表述清楚，或者误操作导致的无效Bug，理解对方诉求
2、站在用户角度考虑并抛出问题
3、Bug定级应该有理有据（站在用户角度）
4、努力提高自身技术和业务水平，做到不仅能提出问题，最好也能够出解决方案
5、如果确实有Bug，友好沟通不能够解决问题，召开Bug评审
Bug评审
目的
- 决定如何处理Bug
- 分析缺陷产生的原因，找出预防的对策
代表参加
- 测试代表：主要从Bug的具体表现、严重程度等方面提供信息，并提出自己对Bug的处理意见。
- 开发代表：开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、 可能引发的风险等，如果决定要修改，还要讨论出修改的初步方案
- 产品代表：产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见
二、测试用例
概念
测试用例（Test Case）是软件测试中为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、测试步骤、测试数据、预期结果
正确设计测试用例的思想：常规思维+逆向思维+发散性思维
设计测试用例原则一：
测试用例中的一个必须部分是对预期输出或结果进行定义
设计测试用例的原则二:
1.测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应该根据无效和未预料到的输入情况。
2.检查程序是否“未做其应该做的”仅是成功的一半，测试的另一半是检查程序是否“做了其不应该做的”。(是上一条原则的必然结果)
3.计划测试工作时不应默许假定不会发现错误。
万能公式
万能公式：功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全测试
功能测试
验证软件的功能是否符合需求规格说明书（或用户需求），确保每个功能模块按预期逻辑正常运行的测试类型。
功能测试通常是一项黑盒操作，在进行测试时，需要对规格说明进行分析以提炼出测试用例，此外为了明确需求，可以进行以下操作
1、查找其他相关文档，来帮助理解所要测试的产品需要完成的目标;
2、尽量多参加项目组内的会议，比如需求讨论、设计讨论、计划讨论等，能够加深对产品的理解
3、召集相关人员，对你整理的结果进行讨论，通过评审后，这份文档就可以作为依据来设计你的case了;
4、如果是一款已经上线的产品，可以多使用产品，有不懂的问产品经理;也可以去看历史bug，可以了解到一些需要关注的东西。
核心关注点：
- 功能是否完整覆盖需求（无遗漏）；
- 功能逻辑是否符合设计（如流程跳转、数据计算、条件判断是否正确）；
- 边界条件和异常场景是否处理（如输入为空、超范围值、错误操作时的表现）。
常见测试点：
- 核心功能流程（如电商的 “浏览 - 加购 - 下单 - 支付” 全流程）；
- 按钮、表单、接口等交互功能的正确性（如提交表单后数据是否正确保存）；
- 错误处理机制（如输入无效数据时是否提示明确的错误信息）；
- 权限相关功能（如普通用户是否无法访问管理员功能）。
界面测试
对软件界面上的所有内容进行测试 ，观察测试界面实现是否与设计图一致，验证界面元素，控件操作
核心关注点：
- 界面元素的显示正确性（如文字、图片、按钮、图标是否正常显示，无错位 / 缺失 / 模糊）；
- 布局适配性（如不同屏幕尺寸下布局是否合理，无重叠 / 溢出）；
- 交互反馈的及时性（如点击按钮后是否有状态变化，加载时是否有提示）；
- 界面风格的一致性（如字体、颜色、控件样式在全系统中是否统一）。
常见测试点：
- 控件尺寸、位置、颜色是否符合设计稿；
- 文字是否清晰、无错别字，字体大小 / 行距是否合理；
- 响应式布局在不同分辨率（如 PC 端、平板、手机）下的适配效果；
- 交互状态（如按钮点击、hover、禁用状态）是否正确反馈；
- 弹窗、菜单、导航栏等组件的显示与关闭逻辑是否正常。
性能测试
在不同负载条件下，测试软件的响应速度、稳定性、资源占用等性能指标，验证其是否满足性能需求。性能测试和功能测试的区别是：功能测试检查软件是否做了，而性能测试测试软件做的好不好。
核心关注点：
- 响应时间（如接口返回时间、页面加载时间是否在预期范围内）；
- 吞吐量（如单位时间内处理的请求数、数据量）；
- 资源利用率（如 CPU、内存、磁盘 IO、网络带宽的占用是否合理）；
- 稳定性（如长时间运行或高负载下是否无崩溃、无内存泄漏）。
常见子类型及测试点：
- 负载测试：在预期用户量（如 1000 用户并发）下，测试系统性能是否达标；
- 压力测试：逐步增加负载（如并发用户从 1000 增至 5000），找到系统崩溃的临界点；
- 并发测试：验证多用户同时操作时是否存在资源竞争、数据混乱（如秒杀场景下的库存准确性）；
- 耐久性测试：系统连续运行 24 小时 / 7 天，观察是否有性能退化（如内存泄漏导致响应变慢）；
- 基准测试：对比不同版本或优化前后的性能指标（如优化后接口响应时间是否缩短）。
兼容性测试
验证软件在不同环境（硬件、操作系统、浏览器、设备等）下是否能正常运行的测试。例如：如QQ可以在PC端打开，也可以在移动端打开;移动端又分为I0S系统和Android系统，且市面上手机又有不同的品牌、不同的机型、不同的版本。
核心关注点：
- 环境多样性适配（如不同操作系统、浏览器、设备型号的兼容）；
- 软硬件依赖的兼容性（如软件与数据库版本、中间件版本是否兼容）。
常见测试点
- 平台兼容：Windows（不同版本如 Win10/11）、macOS、Linux 等操作系统下的运行效果；
- 浏览器兼容：Chrome、Firefox、Edge、Safari 等不同浏览器及版本的适配（如 CSS/JS 兼容性问题）；
- 设备兼容：手机（不同品牌如华为、苹果，不同尺寸屏幕）、平板、PC 等设备的适配；
- 分辨率兼容：不同屏幕分辨率（如 1080P、2K、4K）下的界面与功能表现；
- 软件版本兼容：与其他依赖软件（如数据库 MySQL 5.7 vs 8.0，JDK 11 vs 17）的兼容性。
易用性测试
从用户视角出发，测试软件的使用便捷性、学习成本、操作效率等，评估用户体验是否友好。确认 “软件是否好用、易上手”，即普通用户能否高效完成操作，无使用障碍。
核心关注点：
- 操作流程的直观性（如完成一个任务的步骤是否简洁，逻辑是否符合用户习惯）；
- 学习成本（如新手是否能快速理解功能，无需复杂培训）；
- 反馈的清晰度（如操作结果、错误原因是否明确告知用户）；
- 人性化设计（如是否有快捷操作、历史记录、防错提示等）。
常见测试点：
- 核心任务流程的步骤数（如注册流程是否能在 3 步内完成）；
- 导航与菜单的逻辑性（如用户能否快速找到目标功能）；
- 错误提示的友好性（如提示 “密码错误” 而非 “系统错误”）；
- 帮助文档 / 引导的有效性（如是否有新手引导、 tooltip 提示）；
- 用户习惯适配（如支持键盘快捷键、常用操作记忆功能）。
安全测试
识别软件中的安全漏洞，验证系统对未授权访问、数据泄露、恶意攻击等风险的抵御能力。确保 “软件数据和功能安全”，即防止敏感信息泄露、系统被非法操控。
核心关注点：
- 身份认证与授权（如是否能有效验证用户身份，权限分配是否合理）；
- 数据保护（如敏感数据是否加密，传输 / 存储过程是否安全）；
- 漏洞防御（如是否能抵御常见攻击手段，如 SQL 注入、XSS 等）；
- 审计与应急（如是否有操作日志，异常攻击时是否能快速响应）。
常见测试点：
- 认证机制（如密码复杂度校验、多因素认证、防暴力破解）；
- 授权控制（如普通用户能否越权访问管理员接口 / 数据）；
- 数据安全（如密码是否明文存储，API 传输是否用 HTTPS 加密）；
- 漏洞检测（如输入特殊字符是否触发 SQL 注入，页面是否防御 XSS 攻击）；
- 会话管理（如会话超时是否自动登出，token 是否易被窃取）；
- 日志审计（如关键操作是否记录日志，是否可追溯操作人）。
除此万能公式所见的测试之外，还有几个常用的测试类型
弱网测试
通过模拟低带宽、高延迟、网络波动、丢包甚至断网等恶劣网络环境，验证软件在非理想网络条件下的功能稳定性、数据可靠性及用户体验的测试类型。
需要工具构造弱网，比如fiddler
安装卸载测试
验证软件从 “安装→运行→升级→修复→卸载” 全生命周期关键环节的完整性、稳定性及用户体验的测试类型，覆盖软件与系统环境的适配及资源清理能力。
核心关注点
- 安装过程流畅性：安装步骤是否简洁、指引是否明确，进度反馈是否及时，无卡顿或无响应。
- 环境兼容性校验：安装前是否检查系统版本、硬件配置、依赖组件（如.NET Framework、JRE）是否符合要求。
- 安装后完整性：安装完成后，文件、目录、注册表（Windows）、权限配置是否完整，核心功能能否正常启动。
- 升级 / 降级可靠性：跨版本升级、降级时，用户数据（如配置、缓存、账号信息）是否保留，功能是否兼容无异常。
- 卸载彻底性：卸载后，安装目录、临时文件、注册表项、服务进程是否完全清除，无残留占用系统资源。
- 异常场景容错性：安装 / 卸载中断（如断电、磁盘满、强制关闭）后，能否恢复或清理残留，避免系统污染。
常见测试点
安装测试：
- 安装方式验证：覆盖官方安装包（.exe/.msi）、应用商店下载、离线安装包、绿色版解压等不同安装途径。
- 前置条件校验：检测系统版本（如 Windows 10 是否支持）、硬件要求（如内存 / 磁盘空间是否达标）、依赖组件是否缺失（缺失时是否提示安装）。
- 安装过程监控：进度条是否准确、步骤指引是否清晰（如许可协议、安装路径选择），异常中断（如断电、手动终止）后重启能否继续或回滚。
- 安装后验证：程序能否正常启动，桌面快捷方式 / 开始菜单是否生成，安装目录文件是否齐全（无缺失.dll/.so 文件），注册表 / 配置文件是否正确写入。
升级 / 降级测试：
- 覆盖安装：高版本覆盖低版本安装，验证功能是否正常，用户数据（如设置、历史记录）是否保留。
- 跨版本升级：跳过中间版本直接升级（如 v1.0→v3.0），验证数据兼容性（如数据库结构变更是否兼容旧数据）。
- 降级安装：高版本卸载后安装低版本，验证数据是否兼容（如是否提示 “数据可能不兼容”）。
- 修复安装测试：
- 模拟文件损坏（如删除关键.dll），执行 “修复安装”，验证能否恢复文件完整性及功能正常。
- 修复过程是否保留用户配置，无数据丢失。
卸载测试：
- 常规卸载：通过控制面板 / 卸载程序执行卸载，验证是否完全移除安装目录、快捷方式、启动项。
- 残留检查：卸载后检查注册表（Windows）、配置文件目录（如 Linux 的
/etc、macOS 的~/Library）、临时文件夹是否有残留文件 / 键值。 - 进程清理：卸载后相关后台进程、服务是否完全终止，无僵尸进程占用资源。
- 权限场景：非管理员权限下能否正常卸载，是否提示 “需要管理员权限”。
异常场景测试：
- 安装时磁盘空间不足，是否提示 “空间不足” 并终止，无半安装状态残留。
- 安装过程中强制断电，重启后是否识别 “未完成安装” 并提供 “继续 / 卸载” 选项。
- 卸载时文件被占用（如程序正在运行），是否提示 “请关闭程序后重试”，而非强制删除导致文件损坏。
设计测试用例
基于需求的设计方法
等价类
依据需求将输入划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例通过，则认为所代表的等价类测试通过，这样就用较少的测试用例达到尽量多的功能覆盖
等价类分类：有效等价类和无效等价类
边界值
对输入或输出的边界值进行测试的一种黑盒测试方法，是对等价类的补充
边界值包括 边界值+次边界值
判定表法（注重思维）
判定表是一种逻辑判断的工具，将复杂的问题照各种可能情况全部列举出来
正交法（注重思维）
正交法（Orthogonal Array Testing）是一种基于正交实验设计（Orthogonal Experimental Design）的测试用例设计方法，核心目标是在减少测试用例数量的同时，尽可能覆盖多因素（参数）之间的关键组合，确保测试的高效性和有效性。
正交表是一种标准化的数学表格，记为 (L_n(t^k))，其中：
- n：正交表的行数（即测试用例数量）；
- t：每个因素的水平数（每个参数的取值数量）；
- k：正交表可容纳的因素数（参数数量）。
L4(2^3)
正交表性质：
- 每一列中，不同数字出现次数相等
- 任意两列中，数字的排列方式齐全均衡
使用allpairs工具生成正交表
1、找到因素和水平并填入Excel（电脑自带）
2、在allpairs创建新的文本文件txt，复制excel中的因素和水平直接粘贴到文本保存
3、使用命令生成正交表：allpairs.exe new.txt>demo1.txt
生成结果
~表示可是填写也可以是不填写
4、根据正交表编写测试用例
5、补充遗漏的重要测试用例（补全全不填写的情况）
场景法（思维）
场景法（Scenario Testing）是一种基于业务流程或用户操作场景的测试用例设计方法，核心是通过模拟用户真实使用软件的 “场景”（即一系列连续操作步骤），来验证软件在完整业务流程中的功能正确性和流程连贯性。
场景法通过 “基本流” 和 “备选流” 来描述业务流程的不同路径：
基本流（Base Flow）：
指 “理想情况下” 用户完成业务目标的正常流程，是最常见、无异常的操作路径。
例：电商 “下单支付” 的基本流为：
浏览商品 → 加入购物车 → 点击结算 → 填写收货地址 → 选择支付方式 → 支付成功 → 订单生成。备选流（Alternative Flow）：
指偏离基本流的异常或特殊流程，可能是用户操作错误、系统异常或特殊条件触发的分支路径。
例：上述下单流程的备选流可能包括：- 备选流 1：加入购物车时商品库存不足；
- 备选流 2：结算时收货地址未填写；
- 备选流 3：支付时余额不足；
- 备选流 4：支付过程中网络中断。
错误猜测法
对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计特例
针对命令行设计测试用例
举例说明-zip命令测试
功能测试
普通的txt文件能够生成zip文件
图片/视频/音频文件那够生成zip文件
多个文件能生成zip
空文件能生成zip
错误的命令是否可以解压（没有源文件）
界面测试
文件压缩成功命令行提示是否美观
文件压缩失败命令行提示是否美观
性能测试
文件大小超过1G是否可以压缩，且压缩时间是否在合理范围内
兼容性测试
zip工具可以在多系统使用，Windows，Linux，Mac
易用性测试
zip命令是否有提示符
是否有使用帮助教程，如zip --help命令下会展示如何使用
安全性测试
zip命令会不会泄漏文件内容
如果压缩失败，会不会损坏源文件
针对接口设计测试用例
接口说明，url，请求方法，请求参数，返回数据
功能测试
完全按照需求文档，使用完全符合的参数，验证返回结果是否与预期一致
不同的请求方式：以Get/Post方式请求接口是否可以返回数据
验证异常返回的状态码是否符合约定
参数组合：
1、空参数
2、多参数（少参数）
3、参数的对应的值为空/过长/特殊字符
4、参数类型与实际不相符（如接口参数age声明为int，测试传入字符串"20"、小数20.5、布尔值true时，接口是否返回类型错误提示）。
性能测试
响应时间测试：单用户调用接口，验证响应时间是否在阈值内（如普通查询 < 200ms，复杂计算 < 1s）。
并发测试：模拟多用户同时调用（如 1000 用户并发调用/api/login），验证接口是否正常响应，无超时或数据错乱。
极限测试：
- 大数量级参数（如查询
pageSize=1000的列表接口），验证是否超时或 OOM（可通过 Java VisualVM 监控内存）。 - 长时间运行（如连续 24 小时调用接口），验证是否有内存泄漏、连接池耗尽等问题。
兼容性测试
确保接口在不同场景下的一致性（版本，协议）
幂等性测试
对于写操作接口（如确认订单，支付），确保重复调用没有实际影响
安全性测试
认证授权校验：
- 未登录调用需授权的接口（如
/api/admin/delete），验证是否返回 401（未认证）。 - 低权限用户调用高权限接口（如普通用户调用管理员接口），验证是否返回 403（权限不足）。
防注入 / 攻击：
- SQL 注入：向查询参数传入
"1' or '1'='1"，验证接口是否过滤特殊字符，避免数据库被攻击。 - XSS 攻击：向文本参数（如
remark）传入<script>alert(1)</script>，验证返回时是否转义（如变为<script>...</script>）。
敏感数据保护：
- 验证返回结果中敏感信息（如密码、身份证号）是否脱敏（如
password显示为******，身份证号显示为110********1234）。
佛教中有一句话：初学者的心态；拥有初学者的心态是件了不起的事情。---乔布斯
🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀
以上，就是本期的全部内容啦，若有错误疏忽希望各位大佬及时指出💐
制作不易，希望能对各位提供微小的帮助，可否留下你免费的赞呢🌸