回归测试用例的设计和挑选

 　　在我们的软件开发过程中，只要软件发生了改动，不管是功能的变更、模块的增加或者bug的修改，都会对现有的软件造成影响，也就可能带来问题。当软件的 bug被发现提交后，有可能发生以下几种情况：a、追踪系统不够完善，该bug被疏忽没有得到修改；b、开发对于bug的理解不同，造成修改后的结果与期望仍不一致；c、理解不够深入，只修改了bug描述的表面现象，深层原因没有找到； d、bug被修改，但没有考虑到与此问题关联的其他模块；e、本bug被修改，之前被本bug掩盖的其他错误得以显现出来。回归测试正是为了检查以上情况是否发生，检验已经被发现的缺陷有没有被正确的修改和修改过程中有没有引发新的缺陷，以确保修改达到了预期的目的。希望各位能够顺利通过2008年下半年全国计算机软件资格考试！
　　由此我们可以看出进行回归测试的必要性，但在每一次回归测试中遍历所有的用例又是不现实的，特别是在测试后期，所以选择正确的回归测试策略来改进回归测试的效率是非常有意义的，现在就回到我们本次的问题上来。
　　针对上面列出的几种情况，总结归纳出几种选取回归测试用例的方法：1、发现缺陷的用例，这些用例可以验证发现的缺陷是否得到正确修改，可以完全检测出上述 a、b中情况，在一定程度上也可以发现c；2、发现缺陷用例所在模块的其他用例；3、出错模块周边以及与其有联系模块的用例，这些模块的识别可以寻求开发人员的帮助；通过方法2、3，可以基本检测出c、d；另外，通过执行方法1、2、3选取的用例，也基本可以检测e的情况。4、软件的核心用例，这些用例应该在设计测试用例的时候就被定义出，它们体现整个软件的核心流程、必须实现、完成的重要功能点，回归测试时执行它们是为了确定本次修改对核心流程和重要功能是否造成影响；5、如果时间、精力、资源允许，可以再执行全部用例，不过一般很难碰到"时间、精力、资源允许"的实际情况。
　　回归测试一项很重要、但也很费时且重复性很多的活动，同时由于该阶段处于后期，也许错误都被正确的修复好了、也许没有引入新缺陷、执行了很多测试用例都没有再发现新问题（很遗憾，这些情况一般都不会发生），这当然是我们理想的状态，但也容易给测试人员带来疲惫感，所以我认为在回归测试中引用自动化是一项不错的选择，这里的自动化主要针对4中描述的软件核心用例，对于这些每一轮测试都必须执行的用例使用自动化，可以提高不少的效率！