Day1
1.测试分类
（1）按照阶段划分
- 单元测试--源代码
- 集成测试--接口
- 系统测试--功能、兼容、安全、性能
- 验收测试--内测、公测
（2）按代码可见度划分
- 黑盒测试--系统测试
- 灰盒测试--接口测试
- 白盒测试--单元测试
扩展：测试策略--冒烟测试
2.测试考虑哪些方面？
**质量模型：**功能、性能、兼容、易用、安全
3.测试流程
需求分析、测试计划、用例设计、缺陷管理、测试报告
4.测试用例
**定义：**即执行测试时使用的案例。
**格式：**用例编号、用例标题、项目/模块、前置条件、优先级、测试步骤、测试数据、预期结果
**如何设计：**不同场景有不同设计方法
作业：
答：
在测试领域，即便是一个简单的"花瓶"，我们也会从 ISO/IEC 25010 软件质量模型（及其延伸出的通用产品质量维度）出发，确保测试的全面性。以下是为你整理的"花瓶测试用例"参考答案，涵盖了功能、性能、易用性、安全等多个维度：
花瓶设计测试用例 (基于质量模型)
测试维度 用例编号 测试标题 预期结果 功能性 (Functionality) TC-01 盛水功能测试 注入 80% 水量，观察 24 小时，底部及瓶身无渗漏。 功能性 (Functionality) TC-02 插花支撑性测试 插入长短、重量适中的花枝，花瓶能保持花枝直立不倾倒。 功能性 (Functionality) TC-03 容积测试 实际盛水量符合设计说明书标注的额定容量。 可靠性 (Reliability) TC-04 稳定性测试 放置在 15° 的斜面上，花瓶在空载和满水状态下均不翻倒。 可靠性 (Reliability) TC-05 耐温变测试 倒入 60°C 的温水，瓶身不会因热胀冷缩产生裂纹。 易用性 (Usability) TC-06 易清洁性测试 瓶口宽度应允许清洁刷进入，内部死角容易冲洗干净。 TC-07 搬运防滑性测试 手部潮湿时拿取花瓶，表面应有一定的摩擦力，不易脱手。 安全性 (Safety) TC-08 表面光滑度测试 瓶口及边缘圆润，无锋利毛刺，确保不划伤用户或花茎。 安全性 (Safety) TC-09 材质环保性测试 材质无毒无异味，长期盛水不会释放影响室内空气或植物健康的物质。 效率/性能 (Efficiency) TC-10 自重测试 空瓶重量适中，既能保证重心稳固，又方便单手拿起。 维护性 (Maintainability) TC-11 兼容性测试 瓶身结构应支持更换不同的内衬（如图片所示的支架结构）。 外观 (Aesthetics) TC-12 工艺完整性测试 瓶身无气泡、无划痕，色彩均匀，符合设计图的美学要求。
💡 给 Day 1 学习者的 Tips：
多维思考： 测试不仅是看"能不能用"（功能），还要看"好不好用"（易用性）、"耐不耐用"（可靠性）以及"有没有危险"（安全性）。
边界值： 比如 TC-01 中提到的"注入 80% 水"或"100% 水"，这就是在测试它的承载极限。
场景化： 考虑用户在不同环境下（如斜面、潮湿手拿、温水环境）的使用情况。
Day2
1.解决穷举测试覆盖问题
方法：等价类
- 有效等价：在有效的范围内任取一个即可
- 无效等价：在有效范围之外任取一个即可
步骤：
- 明确需求
- 划分出有效与无效的界限
- 编写用例
2.解决边界限制测试覆盖问题
方法：边界值+等价类
1.取7点：
- 边界点（2个）
- 边界左右两边的临近点（4个）
- 范围内的点（1个）
2.取5点：
- 开内闭外
- 开区间：不包含，使用（）
- 闭区间：包含，使用[ ]
步骤：
- 明确需求
- 划分等价（有效、无效）
- 确定边界
- 编写用例
3.解决多条件依赖测试覆盖问题
方法：判定表
表格工具：
- 条件桩：先列出所有条件
- 条件项：条件的取值
- 动作项：预期结果
- 动作桩：系统规则实际输出的结果
步骤：
- 明确需求
- 画判定表
- 用例
4.解决项目业务测试覆盖问题
方法：画流程图
**提示：**测试用例，首先设计业务用例，其次设计单功能
作业：
1.ATM业务用例。
答：
流程简述：
开始：用户插入银行卡。
验证：系统读取卡片并要求输入密码（通常有 3 次错误锁卡机制）。
选择业务：用户选择"取款"。
输入金额：用户输入或选择取款金额（需校验余额、单笔限额、ATM 钞箱余额）。
出钞/打印：系统扣款、吐钞、询问是否打印凭条。
结束：退卡。
作业2：小程序测试用例（只做功能测试用例即可）
答：
这张图片展示了一个典型的小程序电商购物流程。在软件测试中，针对流程图编写功能测试用例，核心逻辑是**"覆盖路径"** 。我们需要确保流程图中的每一个箭头（路径）和每一个判断框（分支）都被测试到。以下是基于该流程图设计的 12条功能测试用例：
小程序购物功能测试用例
模块 用例编号 测试标题 测试步骤/操作 预期结果 登录授权 TC-01 授权登录成功 进入小程序，点击"授权"按钮。 成功登录，进入商品浏览页面。 登录授权 TC-02 拒绝授权登录 进入小程序，点击"拒绝授权"。 提示登录失败，无法进入后续业务。 商品浏览 TC-03 退出小程序 在商品浏览页面点击退出/关闭小程序。 正常退出，业务流程结束。 购物车 TC-04 添加购物车 在商品详情页点击"添加购物车"。 页面提示添加成功，购物车内商品数量增加。 下单环节 TC-05 库存充足下单 选择有库存的商品点击"下单"。 成功跳转至订单支付页面。 下单环节 TC-06 库存不足下单 选择库存为0或库存小于购买量的商品下单。 提示"下单失败"或"库存不足"。 订单支付 TC-07 支付成功流转 在支付页面输入正确密码并完成扣款。 订单状态变为"已支付"，并流转至"已发货"。 订单支付 TC-08 支付失败/中途取消 进入支付界面后，关闭支付弹窗或输入错误密码。 提示"支付失败"，订单状态转为"待付款"。 订单支付 TC-09 余额不足支付 使用余额不足的支付方式进行支付。 提示支付失败，订单进入"待付款"列表。 订单状态 TC-10 待付款二次支付 从"待付款"列表点击该订单重新支付。 支付成功后，订单状态更新为"已支付"。 闭环测试 TC-11 流程完整性测试 从进入小程序到发货结束完整走一遍。 所有环节状态切换正常，数据一致。 异常路径 TC-12 网络中断测试 在点击"下单"或"支付"瞬间断开网络。 小程序应有合理的超时提示，不能卡死或导致重复扣款。
🎓 划重点：如何根据流程图写用例？
你可以记住这个公式：
正向路径：顺着流程图最顺利的箭头走到底（如：TC-01 -> TC-05 -> TC-07）。
逆向/分支路径：在每一个菱形判断框（是否授权？下单成功？支付成功？）选择"否"或"失败"的情况。
状态迁移：关注每一个蓝色方框（状态/动作）的变化，确保数据（如订单状态、余额、库存）随之更新。
作业3：单模块。
答：
这份作业针对的是 "注册模块" 的单页面功能测试。这是软件测试面试中最常考的场景之一。在 Day 1 的学习中，我们需要运用等价类划分法 和边界值分析法来设计用例。
针对你提供的图片信息（手机号、密码规则、验证码），我为你整理了这份标准的参考答案：注册模块功能测试用例
1. 手机号码测试
用例编号 测试场景 输入数据 预期结果 TC-01 正确手机号 有效的11位手机号（如 13800138000） 验证通过，不报错 TC-02 空手机号 留空，直接点击注册 提示：手机号码不能为空 TC-03 格式错误 输入少于11位或多于11位，或包含非数字 提示：手机号码格式不正确 2. 密码规则测试（核心：a/b/c/d 四条规则）
用例编号 测试维度 输入数据（示例） 预期结果 TC-04 正常通过 abc123456(字母+数字，长度10)验证通过 TC-05 纯数字校验 12345678提示：密码不能为纯数字 TC-06 纯字母校验 abcdefgh提示：密码不能为纯字母 TC-07 长度下限边界 a1(长度为2)提示：密码长度需在6-16位之间 TC-08 长度上限边界 a123...(长度17)提示：密码长度需在6-16位之间 TC-09 边界长度测试 a12345(长度6)验证通过 TC-10 包含特殊字符 abc@123验证通过（规则未禁止，通常应支持） 3. 验证码及其他
用例编号 测试维度 操作步骤 预期结果 TC-11 图片验证码为空 不输入验证码直接注册 提示：验证码不能为空 TC-12 图片验证码错误 输入错误的图形验证码 提示：验证码输入有误 TC-13 验证码刷新 点击验证码图片 验证码图片成功更换 TC-14 协议勾选 不勾选"已阅读并同意"直接注册 提示：请先阅读并同意注册协议
💡 进阶知识点：如何体现你的专业性？
在实际工作中，除了输入框的文字逻辑，我们还会考虑交互与UI：
数据脱敏：输入密码时，是否以密文（星号或圆点）显示？点击"眼睛"图标能否切换显示？
按钮状态：在信息未填写完整前，"免费注册"按钮是灰色不可点击，还是点击后才报错？
安全性：如果同一个手机号短时间内多次发送验证码，是否有频率限制（如 60s 倒计时）？
📝 学习小结
等价类：TC-04（有效类）、TC-05/06（无效类）。
边界值：TC-07（小于6）、TC-08（大于16）、TC-09（等于6）。
这三个作业（花瓶、ATM、注册模块）涵盖了从实物测试 到业务流测试 ，再到单页面组件测试的完整路径。恭喜你完成了 Day 1 的学习！
Day3
1.如何区分是前端bug还是后端bug？
- 1、如果是界⾯或兼容性的错误为前端bug
- 2、如果是功能错误区分前端和后端bug,需要抓包查看请求和响应。
2.能够使用Excel对于缺陷进行管理
缺陷id：bug_001
标题：
- 测试步骤描述+预期+实际
- 测试步骤描述+实际+需求
- 测试数据描述+实际结果（具体测试数据）
**状态：**新建、打开、关闭、拒绝、延期
**优先级：**参考用例优先级
模块
**缺陷描述：**前置、步骤、预期、实际
**附件/备注：**日志、截图（实际结果）
作业1：注册模块测试点有哪些？
答：
Day4------项⽬实战
1 登录模块
1.1 测试点
重点提示：
正向：⼀次尽量覆盖多条
逆向：⼀次只能覆盖⼀条，其他选项必须正确。
1.2 测试用例
2 发布文章模块
2.1 需求分析
2.2 测试点
2.3 测试用例
3 整体测试流程
3.1 执行用例
- 登录测试用例表
- 发布⽂章测试用例表
3.2 缺陷管理
- 描述要素+提交要素
3.3 测试报告
（1）项目背景
传智作为⼀个IT教育机构，拥有⾃⼰开发且实际运营的产品，将开发和运营的技术作为授课
的内容，对于学员⽽⾔学到的都是⼀⼿的真实案例和实际经验，知识内容也可以细化深⼊。⽽且
⼀个产品就可以涵盖公司多个学科的技术，衍⽣的课程价值辐射多个学科，这可以作为公司的⼀
个核⼼竞争⼒。
（2）测试目标
- 登录模块
- 发布文章模块
（3）提测标准
- 冒烟测试用例100%通过
- 被测试内容符合约定版本及功能
（4）上线标准
- p0~p2全部修复完成
- p3修复完成95%
（5）⻛险控制
- ⼈员⻛险（多储备1-2名、测试、开发、产品）
- 环境⻛险（开发、运维、测试共同完成）
- 需求⻛险（跟产品确定有可能变动部分
（6）bug统计
- 登录模块：8个
- 发布⽂章：1个 --> p0
（7）测试总结
问题：
1、登录需求（验证码）不明确
2、选择频道需求不明确
3、上传图⽚功能有些⼲扰发布⽂章主线
收获：
1、先设计主功能，其次设计独⽴功能点
2、设计⽤例之前先设计测试点，可以避免遗漏。