很久没有写东西了，都是金融危机惹的祸，说说个人想法，最近正在整理一些流程规范的东西，回归测试正是需要考虑的部分。
说到回归测试，可以说每个做测试的人都做过，重复，无聊，消耗时间等可能是大家做回归测试的记忆。也许实施自动化测试可以解决一部分回归测试，但不是所有的测试都可以自动化，也不是所有的公司都有能力实施自动化，下面写的内容不涉及自动化内容。
从三方面来讨论做回归测试：
一、测试流程方面
一般通用的测试流程都是“测试计划”—“测试设计”—“测试执行/分析”—“测试报告”，贯穿与整个项目，和开发流程相对应。由于本人做游戏测试方面，需求变更对游戏行业来说是很频繁，很正常的，在做游戏行业测试不能和通用软件测试流程一样，游戏测试流程应该是螺旋式的，单元测试，模块功能测试，集成测试，系统测试，性能测试，压力测试等是测试的一个过程，“测试计划”—“测试设计”—“测试执行/分析”—“测试报告”应该实施在每个阶段，实施在单元测试阶段，实施在模块功能测试阶段等，这样才能达到螺旋效果。而在每一次螺旋测试结束后，实施下一次螺旋测试前都应该进行回归测试，回归测试在螺旋测试中应该贯穿与每个螺旋阶段，而不是只贯穿与项目测试。
二、测试用例设计方面
有了上面的回归测试流程计划，下面要实施的就是回归测试的重点——测试用例。在设计测试用例中就应该把回归测试用例考虑进去，可以通过设置用例优先级做为后期回归测试用例的挑选条件，也可以是其他的。
测试用例一般在项目中分为三种，单元测试用例，功能测试用例，性能测试用例。
1、 在不能阶段设计测试用例，挑选回归测试用例是不同的，单元测试用例设计一般选择具有编程能力的测试人员设计，功能测试用例设计选择熟悉业务知识的测试人员设计，性能测试用例设计一般需要与开发人员商讨才能设计。也就是说只有选对设计测试用例的人员，才有可能在后期挑选出好的回归测试用例。
2、 项目中的拳头功能，亮点，用户大量使用的功能应该是重点保护的地方，这方面可以交给小组核心人员进行设计。
3、 测试用例设计一定要设置优先级(依靠测试人员个人水平，用例评审等进行设置)。
三、测试管理方面
现在的团队都讲究团队精神，可以说，一个测试团队的水平发挥，一半以上可以说和管理的好坏有关，这也就是为什么回归测试会和测试管理有关系了，也就需要一个好管理者来进行管理了。
1、 单单有计划还不行，还得靠执行，上面的测试流程应该在制定后严格执行，每一轮的螺旋测试后和下一轮螺旋测试之前都应该进行回归测试，如单元测试之后，模块功能测试之前，应该挑选单元测试用例进行回归测试，只有保证单元测试通过才能进入下一轮螺旋测试。
2、 测试管理人员在测试开始之前要非常熟悉项目，才能在后期安排任务时把不同的测试安排给合适的人选，发挥最大的力量，这就需要管理者具备良好的沟通力和分析能力
3、 执行测试用例评审——重点模块，亮点模块的测试用例必须经过评审
4、 回归测试重点地方——BUG修改，关联功能，新增加，修改功能，上一轮测试BUG多的功能。
5、 做好每轮螺旋回归测试工作——分析上一轮螺旋测试缺陷，找出缺陷比较多的地方是下轮回归测试重点，需要重新挑选回归用例。
6、 编写每轮螺旋测试报告——分析缺陷，测试方法等，为下一轮螺旋测试做修改，准备。
7、 持续改进——每一轮的螺旋测试后都应该分析，计划，团队，用例设计等是否需要改进，做到螺旋测试持续改进。
脑袋有点乱，思路可能没表达清楚，以后再修改，个人认为回归测试方法不是一成不变的，也应该是持续改进。不同阶段需要的回归测试都是不一样的。回归测试不能仅仅只和测试用例相关。
