关于测试管理的一点心得一

    从去年9月开始，才开始正式的考虑测试管理这个问题，一直到今天再次考虑时似乎有了一点思路。

    首先介绍一下我们测试部门的现状，大概也是大部分测试部门的现状。我们测试部门是有流程的，也有各个阶段需要出的模板文档，比如测试计划、测试用例、测试报告等。但是，现在的问题是，测试人员的工作量还是看不出来。由于我们经常出差，大家都不在一处办公，所以很难知道每个测试人员负责的测试项目的进度之类的东西。

    去年9月，领导让我针对某外地项目投诉我们测试完成后为什么还有很多问题这一事件，写一个测试流程。，当时是我第一次考虑测试管理这个问题。以前也是在CMM3的公司中工作过，不过也是没有彻底的解决此问题。所以我写了一个测试方案，其实就是针对该项目的一个测试流程。如下：

    测试需要出的文档：测试计划、测试用例

    测试阶段的控制：测试的准入规则、测试的准出规则（一级、二级bug必须全部关闭后才能结束）、bug等级的定义、每次上线需要复测所有的测试用例，测试必须要有3轮。

    开发环境与测试环境的一致性

    上面就是我上次写的测试方案也是流程。哈哈，让大家见笑了。其实现在看看真的洋洋洒洒的不少字，应该很不错的。其实，上面这个流程是失败的。为什么呢。因为上面这些东西看似挺多，也对测试人员进行了规定，这样就肯定不能偷懒了。可是大家想过没有，你只是规定了，但是测试人员执行没执行，你怎么能知道呢。造成了测试人员仍然是想怎么测就怎么测，测试用例也可以很久都不更新。呵呵，其实项目还是同原来一样，没有本质改变。

    本次我又考虑此问题，发现管理应该是越简单越好的。并不是你的流程越复杂，越好，但是最重要的是执行。再简单的内容，只要执行起来就是好的。但是如何确保他的执行呢。这个就是配置管理要做的事情。看到一个帖子将配置管理比喻为项目经理的眼睛，一点也不为过。因为我们整个的软件生命周期中，配置管理真的是很重要的。我们的工作量应该都体现在里面。如软件版本的更新，测试文档的更新。但是如何检查呢，可以定期检查，定期出审核表。看我下面想到的新的流程。

    对于测试计划、测试用例、测试记录、测试bug、测试报告要定期更新配置库，可以半个月，或一个星期。配置管理员定期对配置库进行审核，将审核结果形成审核记录，并公布给大家。上面的文档并不是所有的都必须要定时更新的，但是测试用例和测试bug一定要定期更新，这两个文档是必须要定时更新的。

     呵呵，上面就是我想到的新流程，虽然没有执行，也不知道以后还有机会执行么。也许还存在缺陷吧。但是我始终相信，好的流程并不是那种复杂的流程，而是很简单，很有执行力，很实用，一眼就能看出问题的流程。希望大家多多指教。