引言¶
在有限的时间和资源内，尽可能的发现问题，发现至今未发现的问题，尽早的暴露出来，并且协助开发尽快解决。
- 早期定义(
1973, Bill Hetz)：软件测试是对程序能够按预期运行建立起的一种信心。 - 经典定义(
1979, Myers)：测试是为发现错误而执行程序的过程。 - IEEE定义：使用人工或自动手段来运行或测量软件系统的的过程，以检验软件系统是否满足规定的要求，并找出与预期结果之间的差异。
测试原则¶
- 测试依赖于测试场景
- Bug 的分布遵循二八法则，即 Bug 往往会集中在某一模块
- 测试的杀虫剂悖论，同一功能不能总是用同一条 Case 反复验证
- 穷尽测试是不可能的，应设定及时终止的条件
- 测试显示缺陷的存在，但经过软件测试不能证明系统不存在缺陷
测试模型¶
- V 模型
在编码之后，针对项目的每个阶段都进行测试
- W 模型
从前期文档便开始，尽可能早的参与测试。
统计表明，大多数的 Bug 来自于对需求的错误理解，所以测试要尽早介入，尽可能降低修复成本
测试对象不止是程序，还有各种文档等
- X 模型
针对单独程序片段进行测试，另外还增加了探索性测试
- H 模型
测试是一个独立的过程，达到准入条件便可以开始测试
测试分类¶
冒烟测试，是从电路板测试引入的概念。当电路板做好以后，首先会加电测试，如果板子没有冒烟再进行其它测试，否则就必须重新来过。
不同版本
- 向上兼容，渐进增强：业务优先，新版本老功能不会受影响，比如做网站，向上兼容，则会更关注内容本身。
- 向下兼容，优雅降级：新特性优先，新版本老功能可能失效，比如做网站，则会优先考虑那些最高级、最完善的浏览器来设计网站。
兼容性测试比较枯燥，最好采用自动化方式来做，比如移动端
- 多设备管理平台：Appium + Selenium Grid + OpenSTF
- 云测平台：Testin、SauceLab
测试策略¶
- 传统软件：慢，通常采用金字塔模型，重点在 GUI 测试
GUI, Graphical User Interface 图形用户界面，也称为端到端（E2E，End-to-end）测试
- 互联网软件：快，通常采用菱形模型，重点在 API 测试
保证测试质量和测试覆盖率的前提下，有效缩短测试执行时间
测试左移¶
Shift-Left Testing，意味着将测试提前到开发过程的早期阶段，尽早发现问题，减少功能测试时的压力
主要是白盒测试
- 单元测试
- 集成测试，持续集成
- 代码静态分析
- 代码审查（Code Review）
测试精准化
- 根绝代码变更自动分析影响范围
- 代码调用链与黑盒测试用例关联
- 代码流程分析与覆盖率统计
- 黑盒测试过程中借助代码流程覆盖数据指导探索式测试
- 利用线上数据推导有效测试用例
测试右移¶
Shift-Right Testing，强调在部署后进行测试，在真实的运行环境中对软件进行评估，以便捕获并解决那些在标准测试环境可能未被发现的问题，确保软件在生产环境中的稳定性和可靠性
- 监控，生产数据、关键指标、短信邮件等
- 日志分析
- 性能测试
- 用户反馈
- AB 测试
混沌工程¶
混沌工程是一种软件工程方法论，旨在通过有意地在系统中引入故障来测试系统的可靠性和稳定性。
这种做法背后的基本原理是通过模拟可能导致系统故障的各种场景（例如硬件故障、网络延迟、系统资源耗尽等），来验证和提高系统在生产环境下的弹性。
- 定义稳态：确定系统的正常行为（稳态），以便在引入故障时能够衡量系统偏离这种状态的程度。
- 变量假设：明确系统设计中的假设，例如，某个服务的高可用性或数据库的快速响应。
- 小规模开始：从小规模和非核心系统开始引入故障，逐步扩大到更大的系统。
- 故障注入：使用混沌工具（如 Chaos Monkey、Gremlin 等）在系统中引入各种故障（如关闭服务器、制造网络拥堵或断开数据库连接）。
- 监控和分析：监控系统的响应并分析故障注入对系统稳态的影响。
- 优化和修复：根据测试结果进行系统调整和修复，增强系统的弹性。
测试流程¶
- 制定测试计划
- 编写测试用例
- 测试用例评审
- 利用各种测试方法和工具进行不同阶段的测试
- 缺陷管理
- 测试报告
测试计划¶
测试计划通常由测试管理者制定，主要是任务分配、时间安排等
测试方案通常由测试负责人制定，是对测试计划的进一步细化和明确，是技术层面的文档。
它描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计及选择、测试用例的设计方法、测试代码的设计方案等。
- 测试目标
- 被测试项：功能、非功能
- 测试方法/策略：UI测试、接口测试、兼容性测试、安全测试、性能测试
- 测试环境：工具、框架