软件开发模型：
开发模型（软件生命周期模型）是指软件从开始研制到最终被废弃所经历的各个阶段，在不同的阶段中，由不同的组织和人员执行不同的任务。
常见开发模型：
瀑布模型：
特点：线性模型，文档驱动
优点：只需要关注当前进行的阶段
缺点：不响应需求变化
应用场景：大型项目，银行、保险、建筑…
软件开发模型：
常见的测试模型：
V模型：
W模型：
优点：测试贯穿软件开发的全生命周期；早参与，早发现，早解决。
**缺点：**技术和管理要求比较高。
软件质量模型：
功能：关注业务功能使用。
可靠性：容错性能（恢复正常的时间、能力），纠错能力
易用性：易读，易懂
效率：时间、性能（响应时间，消耗的资源（CPU,内存））要求
可维护性：软件运维人员去维护公司现有项目，为后续功能的开发与维护提供便利。
可移植性：在不同软件、硬件平台都能正常工作。
ISO：国际标准
GB：中国标准
软件测试用例：
测试用例：一个为了特定目的（验证产品的功能实现能否满足用户需求）而设计的包含（测试输入、执行条件、预期结果）的文档，文档的形式：Excel、xmind等。
| 标题 | 测试输入 | 执行条件 | 预期结果 |
|---|---|---|---|
| 验证电脑开机功能 | 有电 | 按下开机键 | 屏幕点亮 |
软件测试用例的作用：
- 便于理清测试思路，确保覆盖测测试的功能点无遗漏
- 便于测试工作量的评估
- 便于提前准备测试数据
- 便于把控测试工作进度
- 便于回归测测试
- 便于测试工作的组织，提高测试效率，降低测试交接成本
等价类用例设计方法：
等价类：在所有测试数据中，具有某种共同特征的数据子集。通过科学的方法找到具有共同特征的测试输入的子集，能够从穷举测试中解放出来。
有效等价类：满足需求的。
无效等价类：不满足需求的。
等价类划分法设计测试用例：
步骤：
1：需求分析
2：划分等价类：有效/无效（规则，长度，类型，是否为空，是否重复）
3：设计测试用例
用例优先级：
P0：一般为保证软件中最主要、重要的功能，最基本的流程能够正常运行而设计。
P1：次要功能，小功能。
P2：UI、边界、错误的设置。
P3：错误信息，较复杂的场景，不常用的场景。
边界值：
等价类划分法的一种补充手段。
测试经验表明错误往往会发生在输入或者输出范围的边界上。
边界值概念：对输入或输出的边界值【有效等价类和无效等价类的界限】进行测试的一种黑盒测试方法。
上点：区分有效和无效的分界点，边界之上的点。
内点：有效等价类里面的任意一点，边界之内的点。
离点：分界点附近的点，离边界最近的左右两点。
判定表：
存在多个输入条件，多个输出结果，输入和输入之间有组合关系，输入和输出之间存在制约关系。
判定表的组成：
条件桩：所有输入条件。
动作桩：所有的可能的输出结果。
条件项：单个条件的取值范围，一般都是有效等价类和无效等价类。
表示方法：字符：真/有效等价类/Y，假/无效等价类/N
数字：真/有效等价类/1，假/无效等价类/0
动作项：基于每一种条件的组合，得到确认的结果。
测试用例的步骤：
- 明确条件桩（找到所有输入条件）。
- 明确动作桩（找到所有输出结果）。
- 对条件桩进行全组合。
- 明确每个组合对应的动作桩（基于每一种条件的组合情况， 确定本组合下的输入结果）。
- 设计测试用例，每行数据对应一条测试用例。
使用场景：多条件组合情况。
因果图：
用图解的方法表示输入的各组合关系，写出判定表，进而设计测试用例的一种黑盒测试方法。
适用范围：适用于分析程序输入条件的各种组合情况，以及输入和输出之间的依赖关系。
基本符号：
恒等：- 条件成立，结果成立。
非：～ 条件成立，结果不成立；条件不成立，结果成立。
或：V 只要有一个条件成立，结果就成立。所有条件都不成立时，结果才不成立。
与/且：^ 多个条件必须同时成立，结果成立。只要有一个不成立，结果就不成立。
测试用例的步骤：
- 需求分析
- 画出因果图
- 将因果图转换为判定表
- 生成测试用例
正交法：
用最小的测试用例获得最大的测试覆盖率
正交表：一种特制的表，一般的正交表标记为：Ln(mk)
k表示因素（输入参数）
m表示水平（输入参数的取值）
n表示测试用例数
测试用例的步骤：
- 需求分析
- 确定因素与水平
- 确定要采用的正交表
- 将正交表中的字母用文字代替
- 设计测试用例（一行就是一条测试用例）
场景法：
概念：模拟用户操作软件时的场景，主要用于测试多个功能之间的组合使用情况。
使用在集成测试、系统测试、验收测试。
测试用例的步骤：
- 需求分析
- 绘制流程图
- 设计测试用例（一条路径流程就是一条测试用例）
缺陷跟踪管理流程图：
错误推测法
利用经验和智慧发现程序中可能犯错的地方。
测试用例设计方法总结：
- 具有输入功能，但输入之间没有组合关系：等价类
- 输入有边界，如长度、类型：边界值
- 多输入，多输出，输入和输入之间存在组合关系，输入和输出之间存在依赖关系：判定表、因果图
- 用最少的测试用例获得最大的测试用例：正交法
- 多个功能的组合测试：场景法、流程图
- 最后推荐使用错误推测法来进一步补充测试用例
缺陷
软件缺陷的定义：软件在使用过程中存在的任何问题，都叫软件的缺陷，简称bug。
软件缺陷的存在会导致软件产品在某种程度上不能满足用户的需求。
测试执行时，实际结果和预期结果不一样。
缺陷的判定标准：
- 未达到需求说明书指明的功能
- 出现了需求说明书指明不应该出现的错误
- 实现了需求说明书之外的功能
- 未达到需求说明书虽未明确提及但是应该实现的目标
- 用户角度发现的各种问题与错误
缺陷的产生原因及根本原因：
缺陷产生的原因：需求文档存在错误
设计存在错误：代码错误
缺陷产生的根本原因：需求变更；沟通不畅，信息不同步；软件复杂；进度压力。
软件缺陷的核心内容：
- 标题：描述缺陷的的基本信息（如：输入密码长度为5时，注册成功）
- 前置条件：描述缺陷出现依赖的相关基础条件（如：未注册手机号）
- 复现步骤：测试用例里面的执行步骤
- 实际结果：执行被测试软件过程中，系统给出的结果
- 预期结果：参照需求说明书，在测试用例中设计的预期结果
- 附件：方便开发定位bug的关键信息，包含图片，日志log等。
缺陷的基本要素：
- 缺陷编号：缺陷的唯一性标志
- 缺陷状态：表示缺陷当前处于哪个阶段
- 常见缺陷状态：
new：新建，表示缺陷刚创建
open：打开，表示已经指派或者开发认领了bug
inprogress：进行中，表示开发正在修改中
fixed：已修复，表示测试可以验证了
closed：已关闭，表示测试验证通过
reopen：重新打开。
rejected：已拒绝，表示开发拒绝了当前bug
postpone/delay：已延迟，表示开发延迟修复该bug
- 缺陷所属模块：缺陷属于哪个被测的模块
- 缺陷严重程度：该缺陷的破坏性能或影响程度
5-critical
4-major
3-medium
2-minor
1-tiny
- 缺陷优先级：处理该缺陷的优先程度
urgent priority
veryhigh priority
high priority
medium priority
low priority
- 缺陷类别：用于分类整理缺陷
功能错误
界面（UI）错误
兼容性缺陷
易用性
改进建议
其他
提交缺陷注意事项：
- 核心要素
- 基本要素
- 可重现：缺陷可以复现
- 唯一性：一个缺陷上报一个问题
- 规范性：符号公司或者项目要求
- 准确：描述的信息是争取的
- 具体：有细节且是真实特定的
- 简介易懂：描述简单容易理解
- 次序清晰：描述缺陷过程有条件，有先后顺序
缺陷跟踪管理过程：
缺陷跟踪流程：
场景1:确认bug解决
测试【new】= = 》开发【open】= =〉开发【fix】= =》测试【close】
场景2:验证未通过，缺陷仍存在
测试【new】= =〉开发【open】= =〉开发【fix】= =》测试【reopen】
场景三：开发延期处理
测试【new】= =〉开发【open】= =〉开发【postpone】
场景四：拒绝处理
测试【new】= =〉开发【open】==〉开发【reject】