1：软件测试
软件测试：软件测试是软件研发的一部分，不止是找出软件错误的活动，是软件开发每一环节中一些列质量活动的总称，包括软件研发过程的改进，软件质量评定，需要参与到每一环关键的决策
- 发现程序中的错误，根据需求，分析执行软件的全过程
- 保证软件研发中，文档质量的过程
- 分许错误产生的原因，以及发展趋势，提出研发过程中的改进意见
- 未发现错误的测试也是有价值的，测试是评定软件质量的有效方法
软件测试的对象：程序和文档(交互文档，概要设计文档，详细设计文档)
软件测试的价值：
- 质量检测(发现软件缺陷)
- 质量改进(完善软件研发的过程)
- 质量鉴定(证明版本可发布)
- 质量督导(提高团队能力成熟度)
软件测试的原则：
- 软件测试要尽早进行，贯穿软件的整个生命周期
- 穷尽测试是不可能的
- 注意测试过程中的群集现象(多个模块同时产生缺陷)
- 缺陷的二八定律(80%的缺陷出现在20%的代码中)
- 严格执行软件的测试计划，避免随意性的测试
- 注意合法和非法的输入
- 杀虫剂悖论(同模块定期替换测试人员测试)
测试误区：
- 软件测试只是对程序的测试
- 软件测试在开发完成后进行
- 软件质量只是测试人员的责任
- 软件发布后的缺陷全是测试人员的错误
- 软件测试对测试人员的技术不高
- 软件测试是测试的事与开发无关
软件测试流程：
- 需求分析
- 串讲：产品经理对开发和测试人员进行需求讲述
- 反串讲：开发和测试人员对产品经理进行需求讲述
- 串讲和反串讲的目的：
需求对齐
- 测试计划
- 人员安排
- 时间节点
- 测试背景
- 测试环境依赖
- 风险
- 退出机制
- 测试用例覆盖度100%
- 测试用例执行率100%
- 缺陷遗留率2-5%
- 遗留的缺陷需要有解决方案
- 测试分析
- 测试设计
- 用例编写
- 环境搭建
- 提交缺陷
- 回归测试
- 测试报告
- 测试用例执行情况
- 测试分布情况
- 缺陷处理情况
- 测试结论
2：测试用例和缺陷
测试用例要素：
- 用例编号
- 模块
- 子模块
- 测试场景
- 用例标题
- 必须以验证开头
- 不能包含二义性字样
- 用例标题不超30字
- 测试标题需要给出明确的结果
- 用例标题不能重复
- 优先级
- 前置条件
- 执行步骤
- 期望结果
缺陷：
- 不满足客户需求
- 超越客户需求
- 不合符用户操作习惯
- 缺失异常处理
缺陷要素：
- 缺陷编号
- 模块
- 子模块
- 测试场景
- 缺陷标题
- 优先级
- 严重性(缺陷等级：轻微，一般，严重，致命)
- 前置条件
- 重现步骤
- 期望结果
- 实际结果
- 附件：运行截图，大批量数据，运行日志等
缺陷生命周期：
- 提交：提交上级
- 确认：确定是否为缺陷
- 分配：由开发组长进行分配
- 修复：开发进行修复
- 验证：测试进行验证(如果还有问题则直接和修改人员对接，reopen过程)
- 关闭：验证通过，结束缺陷
3：各种测试
| 测试类型 |
描述 |
| E2E测试 |
端到端测试，模拟真实使用环境测试业务的全流程 |
| 单元测试 |
单元测试一般是开发人员进行测试，各个模块在经过单元测试后进行组装 |
| 集成测试 |
主要目的是检查软件模块之间的接口是否正确，主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试 |
| 系统测试 |
是基于软件需求说明书的黑盒测试，是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确 |
| 性能测试 |
性能测试：压力测试(非正常范围)，负载测试(正常范围)，并发测试(短时间内，大量请求同一个接口)，稳定性测试(正常范围，长时间测试，比如一个礼拜)，基准测试(测量和评估软件性能指标) |
| 负载测试 |
系统在不同负载下的性能表现，通过负载测试能够测试出系统在各种负载下的性能变化曲线，发现系统的性能拐点，从而找出系统的最佳性能 |
| 压力测试 |
系统在高强度负载下的性能表现，通过压力测试可以测试出系统能够承受的最大负载。压测是一种寻求系统介于正常和不正常之间临界值的一种负载测试。压测不仅关注高负载下系统是否正常运行，同时关注负载减小后，系统是否能够恢复 |
| 稳定性测试 |
通过对软件稳定性的测试可以观察在一个运行周期内、一定的压力条件下，软件的出错机率、性能劣化趋势等。进而大大减少软件上线后的崩溃卡死等现象，为软件的逐步优化提供方向及验证。在特定的负载下（正常或略高于正常的负载），在一段运行周期内，对被测系统进行一系列的正常操作，观察各个系统性能指标变化以及系统是否能够长期稳定运行 |
| 并发测试 |
测试目的并非为了获得性能指标，而是为了发现并发引起的问题。通常使用一些工具进行并发测试：LoadRunner，JMeter等 |
| 基准测试 |
在特定时期（系统稳定时）通过基准测试建立一个已知的性能水平（称为基准线），当系统的软硬件环境发生变化之后再进行一次基准测试以确定那些变化对性能的影响。基准测试可以比较系统在版本迭代过程中，各个性能指标的变化，为系统的版本迭代优化提供参考 |
| UAT用户验收测试 |
用户验收测试(包含Alpha，Beta测试)，用户可接受性测试：用户或者第三方公司验证测试是否满足客户需求 |
|
A
l
p
h
a
Alpha
Alpha测试 |
一些最终用户在开发环境中进行测试 |
|
B
e
t
a
Beta
Beta测试 |
在
A
l
p
h
a
Alpha
Alpha测试之后由一些最终用户在生产环境(线上环境)中进行的测试 |
4：测试方法
Ⅰ：等价类划分法
将程序的输入域划分为若干等价类，从每个部分中选取少数代表性的数据，当作测试输入数据
- 有效等价类：对程序有意义的，合理的输入数据，构成的集合
- 无效等价类：对程序无意义的，不合理的输入数据，构成的集合
举例：
| 输入条件 |
有效等价类 |
无效等价类 |
| 用户名 |
中文，英文，中英文 |
特殊字符，数字，空格 |
| 密码 |
6-10位纯数字 |
05位，7N位，字符 |
有效等价类测试：
- 中文，6-10位纯数字
- 英文，6-10位纯数字
- 中英文，6-10位纯数字
无效等价类测试：
- 无效等价类的用户名+有效等价类密码
- 无效等价类的密码+有效等价类的用户名
根据等价类表生成测试步骤：(无效一次一个，有效一次尽可能多)
- 为有效等价类编写唯一的编号编写测试用例，使其尽可能多的覆盖尚未被覆盖的有效等价类
- 重复测试，直到所有的有效等价类被覆盖为止
- 为无效等价类编写唯一的编号编写测试用例，使其覆盖一个尚未被覆盖的无效等价类
- 重复测试，直到所有的无效等价类被覆盖为止
Ⅱ：边界值测试法
- 上点：边界值上的点
- 离点：离上点最近的且不属于同一个等价类的点
- 内点：上点内的点
Ⅲ：场景测试法(流程分析法)
- 正常的流程属于基本流
- 因为错误而产生的流程属于备选流
Ⅳ：错误推断法
根据经验和直觉推测程序中所有可能存在的各种错误，从而设计有针对性的测试用例的方法
基本思想：列出程序中所有可能发生的错误或者容易发生错位的特殊情况，根据它们来设计测试用例
- 单元测试的时候整理出来的模块中常见的错误
- 以前产品测试中发生过的错误
- 产品在顾客实际使用中发生的错误
- 容易发生错误的情况
- 一些公共模块(错误会导致群集现象)
- 修复bug的功能和模块
Ⅴ：正交试验法
研究多因素多水平的一种实验法，利用正交表来对实验进行设计，通过少数的试验来代替全部的试验，根据正交表的正交性从全面试验中挑选适量的有代表性的点进行试验，这些有代表的点具备了均匀分散，整齐可比的特点(由于时间和成本的限制不可能进行全面试验)
兼容性正交：(一般测试三个版本)
表单正交：
- 列出所有条件
- 将条件值选项最多的作为第一列，以此类推，进行排列组合
- 正交表除了第一行都是测试用例
表单：输入框，单选，多选，复选，文本，下拉
控件：滚动条，弹出框，按钮等
5：敏捷开发
敏捷模型：敏捷模型是一种以人为核心，迭代 (将软件研发过程分为若干轮次，每一个轮次都称为一个迭代，迭代经历 需求 计划 设计 实现) 循序渐进的开发思想，在敏捷开发过程中软件项目的研发被切分成多个阶段，各个阶段都具备可以独立运行以及独立交付的特征
| 名词 |
描述 |
| scrum |
敏捷开发的一种典型的管理方式 |
| 站立会 |
快速讨论 |
| 看板 |
展示每天的软件研发进度 |
| 用户故事 |
用户需求 |
| 燃尽图 |
进度图(X-时间 Y-工作剩余量) |
| UAT |
用户验收测试 |
| case |
用例 |
| Build |
大概一周，迭代中的小型迭代 |
| Sprint |
大概一个月的时间，一次版本发布(迭代) |
三个回归：
缺陷回归(发生在每一个build)
版本回归(发生在每一个sprint)
产品回归(发生在最后一个sprint)
三个报告：
测试报告(发生在每一个build)
sprint报告(发生在每一个sprint)
产品报告(发生在最后一个sprint)
两个UAT：
sprintUAT(发生在每一个sprint)
产品UAT(发生在最后一个sprint)
每一个build流程：
- 编写用例
- 搭建环境
- 执行测试
- 提交缺陷
- 修复缺陷
- 缺陷回归
- build测试报告
每一个sprint流程：
- 若干build
- 最后一个build
- 版本回归
- sprint测试报告
- sprintUAT
- 最后一个sprint
