一、质量模型
1. 功能性：功能数量、功能正确实现、错误处理情况
2. 性能
3. 兼容性：浏览器兼容性：谷歌，火狐，Edge
4. 易用性：简洁、友好、流畅、美观
5. 可靠性
6. 安全性
7. 可移植性
8. 可维护性
*. 界面布局
a. 布局与UI原型一致
b. 图片与文字准确与UI原型无误
二、测试流程
1. 需求评审
2. 计划编写：测什么、谁来测、怎么测
3. 用例设计：验证项目是否符合需求的操作文档
4. 用例执行：项目模块开发完成后执行用例文档实施测试
5. 缺陷管理
6. 测试报告
三、测试用例
1. 用例编号：项目_模块_编号
2. 用例标题：预期结果（测试点）
3. 项目/模块
4. 优先级
5. 前置条件
6. 测试步骤
7. 测试数据
8. 预期结果
四、常见测试情景和办法
1. 穷举场景 等价类划分法
a. 步骤
A. 明确需求
B. 确定有效和无效等价类
C. 提取数据编写用例
b. 适用场景
A. 输入框
B. 下拉列表
C. 单选复选框
2. 限定边界规则 边界值分析法
a. 点的分类
A. 上点：正好等于
B. 离点：刚好大于/小于
C. 内点：范围内的点
-> 七条用例 -> 优化：五条用例；优化办法：保留上内，开外闭内
b. 步骤
A. 明确需求
B. 确定有效和无效等价类 -> 等价类划分法
C. 确定边界范围值
C. 提取数据编写用例
3. 多条件依赖关系 判定表法 适合条件组合数量较少的情况 可采用其他方法：正交法和因果图法，
a. 概念
A. 条件桩：问题中所有的条件
B. 动作桩：问题中可能采取的操作
C. 条件项：条件对应的取值和真价值
D. 动作项：条件项各种取值情况下的动作结果
b. 步骤
A. 明确需求
B. 画出判定表
i. 列出条件桩和动作桩
ii. 填写条件项，对条件进行全组合
iii. 根据条件项的组合确定动作项
iv. 简化、合并相似规则（有相同的动作）
C. 根据规则编写测试用例
4. 项目业务 场景法
a. 流程图
5. 错误推荐法
a. 场景
A. 实际场景：时间紧任务量大时，根据之前项目类似经验找出易出错的模块重点测试
-> 时间紧任务量大面试回答：不写用例，和产品确定重点业务，覆盖主要业务、只要模块
B. 理论场景/推荐场景：时间宽裕时，通过该方法列出之前问题较多的模块再次测试
五、缺陷管理
1. 定义：软件中存在的各种问题
2. 判定标准
a. 少功能
b. 功能错误
c. 多功能
d. 隐性功能错误
e. 不易使用
3. 产生缺陷的原因
4. 软件缺陷生命周期
a. 注入缺陷：需求、设计、编码
b. 发现缺陷：测试
c. 清除缺陷：
A. 缺陷分类
B. 缺陷隔离
C. 缺陷解决
5. 缺陷的核心内容/描述：
a. 标题
描述缺陷的核心问题 ：测试数据+实际结果（预期结果）
b. 预置条件
缺陷产生的前提
c. 复现步骤
复现缺陷的过程
d. 预期结果
希望得到的结果
e. 实际结果
实际得到的结果
f. 必要附件
图片、日志等信息
6. 缺陷的提交要素
a. 缺陷标号
b. 严重程度
A. S1:主功能
B. S2:次要功能
C. S3:易用性和界面
D. S4:建议性性问题
c. 缺陷优先级
A. P0:24小时内解决
B. P2:发布前必须修改
C. P3:可以在下一个版本修复
d. 缺陷类型
A. 功能错误
B. 错误界面、兼容性
C. 数据、易用性、改进和建议、架构
e. 缺陷状态
f. 缺陷提交人
7.
六、
标签：场景,模块,基础,功能测试,用例,测试,条件,缺陷 From： https://www.cnblogs.com/randolph-chen/p/18108323