回归测试思考

最近，测试工作又临近节点发布任务，又到了所谓工作任务紧张冲刺阶段，又有些感想：

（1）节点发布的质量如何保证？

（2）如何合理地科学去规化这个测试过程？

（3）一个合格的回归测试需要具备什么？

（4）为什么只有到了这种节点发布前一个月时间，大家才会有那种紧迫感，问题及一些不顺的事情又专门在这种时机发生，会有测试时间不够用的感觉？

那些问题来了：如何做好回归测试，保证节点发布质量？

个人自己的一些感觉：

（1）确认本次发布合入功能或新开发功能范围，并需要在正式进入回归测试前进行一轮测试

在进入版本发布节点回归阶段前，首先应该明确本次发布范围（重点是本次合入新功能、合入修改点等），在进入回归测试前这些范围应该是经过一轮的初步测试，提前已经把改动大的地方问题暴露了出来了。而不应把这次改变未经任何测试统一在回归测试阶段进行，这样会导致一旦这个过程不顺，会不断返修不断重复回归。

（2）回归测试应该有一定的测试策略或测试方案，不能盲目地回归测试

A.回归范围是哪些（即涉及到产品模块，产品覆盖范围，产品需求（哪些是沿用以前产品需求，哪些是本次重点优化或新开发的需求）

B.产品部署方式具体有哪些？是否要升级测试？

C.哪些人参加，分别负责什么模块？（应该安排清楚并落实到位）

D.测试执行：是按测试用例执行什么（用例范围，用例执行管理方式）

E.测试进度汇报（汇报粒度、汇报形式、汇报内容规则）

F.缺陷管理（缺陷提交规则（重点主要是进行如何区分是本次节点发布范围内缺陷），跨团队缺陷如何处理，缺陷验证时效要求，遗留缺陷的评估）

G.风险管理（风险汇报要求，风险快速处理方式（如阻塞测试BUG处理））

H.测试时间节点（Smoke测试、回归测试几轮等每轮测试时间节点等）

看看大家对如何做回归测试一些好的建议？

----提炼关键点的测试：重要功能流程（客户使用最核心、最频繁的功能；本次新增功能、修改功能点；）

-----问题爆发多的模块

测试人员方面：-----变换测试人员，相互交叉轮流测试

B/S架构：

浏览器版本要求：要覆盖哪些版本，覆盖策略？是否支持自动化测试浏览器兼容性测试？无自动化下，无人力下，如何保证：最低版本、最高版本、用户使用最多的版本

部署方式有哪些：单体、多负载？

升级方式：全新版本，低版本（具体覆盖哪几个低版本）到高版本升级？

测试数据要求：