软件测试工程师基础理论（四）

回归测试

1. 验证bug是否被正确修复的过程
2. 验证bug修复后没有引入新的bug
3. 所有的测试阶段都有可能发现bug，都需要进行回归测试

回归测试策略

• 完全回归测试：

1. 把软件所有的功能全部重新测试一遍

2. 覆盖全面，随着需求的增多,耗费的人力/时间越来越多,成本高

• 选择性回归测试：

1. 已发现的bug被正确修复，并且没有引入新的bug

2. 用户频繁使用的功能

3. 软件的整体业务流程通畅

优点：节省成本；缺点：存在漏测的风险

回归策略有选择性重复测试，主要表现为这里有三个方法：(记结论就行，不用理解)

（1）覆盖修改法，针对发生错误的模块，选取这个模块的全部用例进行测试。这样只能验证本模块是否还存在缺陷，但不能保证周边与它有联系的模块不会因为这次改动而引发缺陷。

（2）周边影响法，除了把出错模块的用例执行之外，把周边和它有联系的模块的用例也执行一遍，保证回归测试的质量。当然我们还可以用量化的角度去分析模块的质量，比如：经过上面的一系列回归测试后，看看遗留的缺陷率是否已经在允许的范围之内了，那么我们以此为标准可以结束本次回归测试。

（3）指标达成法，在测试全部完成后，看看我们有没有达到既定的指标。

软件测试的四个活动

每个测试阶段都会有四个活动

• 计划：测试经理确认当前版本的工作范围、时间安排、人员分工、风险预估、工作规范，编写《测试计划》从管理的角度规划版本的软件测试工作，who what when（什么人员花多少时间做什么事），参照《项目计划书》和《需求规格说明书》（SRS）
• 设计：高级测试工程师根据需求和测试计划从技术角度规划当前版本的测试工作如何实现，测试关注点、测试策略、测试方法、测试用例设计、环境安排等，编写《测试方案》从技术的角度设计软件测试工作如何实现，how（规划测试工作怎么测,测试的方法，工具以及策略），参照《测试计划》和《需求规格说明书》（SRS）
• 实现：测试工程师根据软件需求、测试计划、测试方案，把需求转化为一个可执行的文档《测试用例》（描述在什么条件下使用什么数据做什么操作达到什么预期结果），参照《测试计划》、《测试方案》和《需求规格说明书》（SRS）
• 执行：搭建测试环境（操作系统、网络、数据库等技术）把软件客户端和服务端安装好，保证测试人员可以执行测试用例。

1. 冒烟测试：验证软件最基础的功能，确认当前版本的需求基本实现，保证测试用例可以正常执行，才会进行全面的系统测试，确认是否需要让测试人员进入到对新版本的测试工作,否则冒烟测试不过版本可以直接打回给开发进行重新修改后再提交测试，写好测试用例后，从中抽取20%左右的测试用例进行冒烟测试
2. 执行测试用例：按照测试用例中的操作步骤操作软件，对比软件的实际结果和用例的预期结果，不一致则有可能是Bug
3. 提交和跟踪bug：测试人员发现Bug，开发修复Bug，测试人员回归测试。期间需要测试协助开发重现和定位Bug
4. 选择性回归测试
5. 测试日报：，汇报每天的进度和阻塞性问题（测试经理/测试组长，需要根据组员每天反馈的进度来把控项目进度，需要了解组员遇到的问题及时去协调解决，保证组员能够顺利完成任务）

6. 测试报告：由测试经理/测试组长编写，汇总本版本的工作任务和成果，确认该版本测试是否通过，项目经理根据测试报告来判断软件是否可以发布