软件测试流程-入门

🥝入门篇

一. 🎗️测试需求文档

产品需求文档、产品原型图、用户使用手册

• 重点理解业务需求：

了解熟悉业务，分析需求测试点

二. 🧩测试用例

设计测试用例是整个测试中最重要的部分，复杂性也最高。
需要充分理解测试需求和业务流程，才能写出完整的、易用性强的测试用例。

（1）确认功能(业务功能，辅助功能，数据约束，易用性需求，编辑约束，参数需求，权限需求）

（2）场景分析（考虑场景调用者和系统内部各个场景之间联系），场景调联涉及整个项目的核心，必须优先保证项目能跑通。
可以从正常场景和异常场景分别编写，尽量做到全覆盖。（我觉得这部分也最难，如果对需求和业务没那么熟悉，这块很容易垮掉，一些潜在的bug也发现不了）

（3）挖掘隐性需求（常用业务流程以及各分支）

1.常用方法

等价类划分法（把所有可能的输入分成几个小组：有效等价类和无效等价类，只测每个小组里的一个代表，代表测试这个小组里的所有输入）

边界值分析法（选出的测试用例，应选取正好等于、刚刚大于、刚刚小于边界的值）

错误推测法（在测试程序时，根据经验或直觉推测程序中可能存在的各种错误）

判定表法（适合于逻辑判断复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，会得到一个判断清晰的策略，类似于数学中的排列组合）

场景法（从用户的角度出发，模拟真实使用场景，覆盖多种用户操作路径，包括正常流程和异常流程）

2.测试用例要素

用例编号，项目模块，用例标题，优先级，前置条件，操作步骤，预期结果

三. 🎫执行测试用例

1.严格按照测试用例执行，记录每个步骤的结果。

2.及时报告发现的缺陷，提供详细的复现步骤。（缺陷都要详细记录下来，一般都会使用管理软件）

3.关注边界条件和异常情况的测试。

4.进行探索性测试，发现潜在的未覆盖问题。

5.保持与开发团队的沟通，快速解决测试中遇到的问题。

四. ✨回归测试

1.回归测试的定义

在开发对软件进行修改（修复Bug、新增功能、优化代码）后，重新执行已有测试用例，以确保：

🍬原有功能未被破坏（没有引入“回退缺陷”）

🍞新修改的部分未影响其他模块

2.回归测试的策略

策略	适用场景	优点	缺点
全量回归	关键版本发布前、重大重构后	覆盖全面	耗时耗资源
选择性回归	修改影响范围明确时（如只改了支付模块）	高效	依赖开发者的经验判断
自动化回归	高频迭代的敏捷项目	快速反馈	初期搭建成本高
基于风险的回归	时间紧张时优先测试核心功能	资源利用率高	可能遗漏边缘场景