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