一.测试需求文档
产品需求文档、产品原型图、用户使用手册
重点理解业务需求：
了解熟悉业务，分析需求测试点
二.测试用例
设计测试用例是整个测试中最重要的部分，复杂性也最高。
需要充分理解测试需求和业务流程，才能写出完整的、易用性强的测试用例。
（1）确认功能(业务功能，辅助功能，数据约束，易用性需求，编辑约束，参数需求，权限需求）
（2）场景分析（考虑场景调用者和系统内部各个场景之间联系），场景调联涉及整个项目的核心，必须优先保证项目能跑通。
可以从正常场景和异常场景分别编写，尽量做到全覆盖。（我觉得这部分也最难，如果对需求和业务没那么熟悉，这块很容易垮掉，一些潜在的bug也发现不了）
（3）挖掘隐性需求（常用业务流程以及各分支）
1.常用方法：
等价类划分法（把所有可能的输入分成几个小组：有效等价类和无效等价类，每个小组里的输入对系统来说都是类似的。我们只需要测试每个小组里的一个代表，就可以代表测试这个小组里的所有输入）
有效等价类：所有在18到60岁之间的年龄（比如18岁、19岁、20岁……60岁）对系统来说都是“有效”的，系统应该允许这些年龄的用户使用。25岁只是这些有效年龄中的一个代表，测试25岁可以代表测试所有有效年龄。
无效等价类：所有小于18岁的年龄（比如17岁、16岁……）和所有大于60岁的年龄（比如61岁、62岁……）对系统来说都是“无效”的，系统应该拒绝这些年龄的用户。17岁和61岁分别是这两个无效范围的代表，测试它们可以代表测试所有无效年龄。
边界值分析法（选出的测试用例，应选取正好等于、刚刚大于、刚刚小于边界的值）
错误推测法（在测试程序时，根据经验或直觉推测程序中可能存在的各种错误）
判定表法（适合于逻辑判断复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，会得到一个判断清晰的策略，类似于数学中的排列组合）
场景法（从用户的角度出发，模拟真实使用场景，覆盖多种用户操作路径，包括正常流程和异常流程）
2.测试用例要素：用例编号，项目模块，用例标题，优先级，前置条件，操作步骤，预期结果
三.执行测试用例
-
严格按照测试用例执行，记录每个步骤的结果。
-
及时报告发现的缺陷，提供详细的复现步骤。（缺陷都要详细记录下来，一般都会使用管理软件）
-
关注边界条件和异常情况的测试。
-
进行探索性测试，发现潜在的未覆盖问题。
-
保持与开发团队的沟通，快速解决测试中遇到的问题。
四.回归测试
-
在开发对软件进行修改（修复Bug、新增功能、优化代码）后，重新执行已有测试用例，以确保：
原有功能未被破坏（没有引入“回退缺陷”）
新修改的部分未影响其他模块 -
回归测试的策略
| 策略 | 适用场景 | 优点 | 缺点 |
| ------- | ------------------- | ------ | ---------- |
| 全量回归 | 关键版本发布前、重大重构后 | 覆盖全面 | 耗时耗资源 |
| 选择性回归 | 修改影响范围明确时（如只改了某个模块） | 高效 | 依赖开发者的经验判断 |
| 自动化回归 | 高频迭代的敏捷项目 | 快速反馈 | 初期搭建成本高 |
| 基于风险的回归 | 时间紧张时优先测试核心功能 | 资源利用率高 | 可能遗漏边缘场景 |