挑选有效的回归测试用例

　　随着系统的逐步成熟，每个版本包含的新特性越来越少，但是新功能对原系统的影响有多大是我们在测试时需要重点考虑的问题。此时，就势必要进行回归测试。而且系统越成熟，回归测试的比重也会越大。这将会对测试工作带来不小的挑战。

　　在实际工作中，经常是一方面求全，希望覆盖面尽量广，避免漏测。另一方面求产出，大量的回归测试用例，可能只发现很少的问题，投入与产出不太匹配，会影响测试人员的士气，甚至测试管理者也会对这种投入产出有所质疑。并且，设计大量的自动化测试脚本，会占用大量的时间。

　　引子就说这么多，看看大家对这一普遍问题有什么看法和建议。

　　回答：

　　最近刚到新公司上班，面临的比较突出的问题是人力紧张，由于公司的产品用在Windows mobile，MTK，Kjava，Symbian，website几部分，测试人员<5(+上我)，如何高效的组织测试团队确实是个挑战?回归测试属于软件测试环节比较重要的部分，所以花费了一些时间总结此文，希望能给测试人员稀少，产品或项目众多的公司，提供一些建议:

　　所谓回归测试，即就是在软件生命周期中，只要软件发生了改变，就可能给该软件产产生问题;所以，每当软件发生变化时，

　　我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否破坏原有的正常功能。

　　其实仅单纯从英文单词Regress很好理解:return to a worse or less developed state.即是退化，衰退的意思， 检查软件从正常的稳定状态退化或是衰退到不正常工作的不稳定状态。

　　注意：回归测试不仅仅是针对在系统测试阶段，而是在软件生命周期中^_^

　　如果以上的定义均明确后，有效的回归测试应从这几方面：

　　其实最有效的回归测试方法建立在开发测试库的基础上;开发在创建测试库，每次生成程序的新版本时都可以运行这些用例。

　　只有有效的从源头避免风险才能有效的进行回归测试(目前国内的公司，能从事此级别的，太少)

　　1 强调单元测试时加强回归测试，引入代码评审，引入自动测试;

　　2 集成和系统级的测试时，加强测试用例评审，回归测试用例的选择;

　　具体的选择可以参考以下几点：

　　1 开发设计测试用例时制定优先级，如高，中，低，方便以后自动化或是策略选择;

　　2 配置管理时，引入测试用例基线管理，有效管理测试用例;

　　3 定期维护测试用例增，删，保持最新状态;

　　回归测试时需考虑效率和覆盖度有效配合，通常的策略有以下几种：

　　基于风险选择测试：

　　哪些功能是软件的特色?

　　哪些功能是用户最常用的?

　　哪些功能出错将导致用户不满?

　　哪些程序是最复杂、最容易出错的?

　　哪些程序最容易扩散错误?

　　哪些程序是开发者最没有信心的?

　　备注：只有有效的避免最大的风险，用户反感的问题，回归测试可以说达到了70%任务!

　　基于Regress衰退概念的测试：

　　开发人员修改的局部程序时，可能已经处理了症状，所以主要测试其被改变的模块和它的接口上;

　　但是也可能存在未触及到根本原因，所以需要测试周边程序及相互依赖性的部分;

　　错误本身可能得到了修复，但修复也可能造成其他错误，所以有必要为每个修复的错误，设计回归测试。

　　基于全面测试策略：

　　如果时间充足，资源齐全，可以进行全面测试,最低的遗漏回归错误的风险，但测试成本最高，非上策!

　　其它的回归测试：

　　1 基于GUI方式的自动化回归测试技术

　　2 基于Ad Hoc 回归测试：增加随机测试，避免回归测试肓点

　　3 基于交叉测试：多人互动的回归测试，尤其在核心的功能点，交互性比较的

原文转自：http://www.uml.org.cn/Test/200810236.asp