关于长期运行的项目的测试用例的维护的问题
先提出一个问题！
我们的测试用例需要维护么？需要将所有的用例都整合成为基线用例，以备以后调用么？
关于测试用例的维护，我想对任何一个长期运行的，有正规的软件测试流程的项目，都是一个非常头痛的问题。
最初我们想将这些用例全部的整合到一个基线用例中，然后以后就可以轻松的调用了，只需要做一些简单的修改就可以使用了。但是执行了一段时间后我们做不下去了。
首先，我们的每一个版本都会产生数百到上千不等的用例。这些用例通常是根据当时的需求来写出的，而且设计者的人不同，风格也不同。合入基线的难度很高。
其次，基线用例，需要大量的维护工作。因为每一次的需求变更都会带来大量的用例更改，而这些无疑都需要大量的时间进行维护，但是这个维护是否值得呢？
再次，由于我们不能随时的维护基线用例，基线用例在使用的时候，就不再是简单的修改那么轻松了。
这样基线用例的维护工作量太大，用例合入基线用例代价也太大，用例的引用代价也不小，而且当我们大量的使用基线用例的时候我们对需求的分析，将无疑被限制在老的用例思维中，对于测试思路也就没有创新科研
那么我们到底是不是需要基线用例呢？如何去维护？如何去使用？
不知道哪位大牛，或者是遇到同样问题的朋友，我们可以一同讨论这个问题
[解决办法]
首先我说说我的看法吧。
测试用例的风格不一致也是我们测试组遇到的问题之一。
趁着产品很忙的时候，派出2个人按照模块划分测试用例，分为N个大组。
列举出最重要的核心功能点。
列出标准测试案例的模板，写Sample Code。
在项目组不忙的时候，全员改进自动化案例。
由于我们产品所有的东西全是可配置的，不可能分为一个基线，就划分为了2个基线，以其中一个为主。
由于每个测试案例的粒度大小不一致，把测试案例划分为最小的粒度。
经过3-4个月后，所有的Core Regression完成了模板化管理。
经过6-8个月，75%的自动化率。
经过10个月，开始扩展现有的测试用例。
只能说需要人和时间的大额投入。
现在的项目只需要之前的一半的人工来处理，由于很规范，只需要到学校去找Intern来维护就行了。
大大的降低了成本....
[解决办法]
http://blog.csdn.net/crazypeter2005/archive/2010/04/19/5502119.aspx
看看我的博客，由于产品是只做加法，GUI改动已经限定在了很小的范围。
每次GUI的改动，我只需要修改Framework里面的Task和Wizard，我的Case完全不用修改。
这就把修改的文件数目从几千个限制在一百个以内。
若干个稳定版本的测试案例对应稳定的Framework。
一个测试执行者发现测试跑不过，他需要做的就是判断是产品的问题还是测试案例的问题，然后开缺陷给对应的人...
这也是需要人和时间的投入。
任何的节省就是就是对品质的伤害...
