目标确定后，我第一步要做的就是找资料，找资料的工作都是春节在家里完成的（其间还带爸妈浏览了一下公司的网站），找开源的工具，主要是看大众的评价和普及度。

软件的易用度很重要，否则无法达到优化测试管理的目的。……（此处省略n字baidu和google），主流的开源测试管理工具如下：

缺陷管理工具

1．    Mantis（http://mantisbt.sourceforge.net/）

2．    Bugzilla（http://www.mozilla.org/projects/bugzilla/

3．    Bugfree (http://www.bugfree.cn/)

测试管理工具

1．    TestLink（http://testlink.sourceforge.net/docs/testLink.php）

2．    Bugzilla Test Runner （http://sourceforge.net/projects/testrunner/）

最开始的时候特别侵向于2&2，因为Bugzilla Test Runner 就是基于Bugzilla的测试用例管理系统。本打算把前者改造一下让它支持更多测试计划（上篇提到的需求1），可惜工作量有点大，另外它的网络支持也较少，决定Pass。

到这时，测试管理工具就剩下Testlink了，缺陷管理工具开始也是想用2，比较熟悉，这个没有兑现则纯粹是缘分问题，现在怀疑是当时下载的Bugzilla的包是个坏的，感兴趣的同学可以再试试。

最终Testlink和Bugfree的结合就是顺理成章了。这样确定的时候，有点无奈，因为二者是PHP＋mysql＋Apache的，我对PHP了解太少，没有写过程序，不知道遇到问题能不能改。新发布的Bugfree2.0增加了测试用例和测试结果的管理，“冗余”了，还是用1.1.

 服务器启来，Testlink和Bugfree分别执行了一下，总的来说挺幸运，除了Testlink的乱码比较多，两个都能独立顺利跑起来。乱码的问题最后改，根据经验，这一定是个minor的bug，应该就是配置的问题。先尝试能把两个连接起来重要些。

找到配置文件，链接按钮也照着葫芦画瓢编码进去并且正确显示了，只是点击按钮后就会异常退出。找Bug是咱测试人员的强项，分析跟这个bug相关的第一嫌疑是testlink和bugfree的主程序，次嫌疑是相关的两个配置文件，主程序很短，两个index.php 从头至尾看过一遍，最可能出bug的就是几个if语句了，分支走错了退出，太常见了。果然就是少了一个！的问题。乱码是键值没有内容，逐个配置上就解决了。

试着模拟了一次CCI回归测试，从建计划到执行到指派相关人员处理临时问题，可以满足上篇的需求，也可以胜任小型项目的测试管理工作。CCI的同学可以连到我的机器玩玩http://10.1.1.187/testlink/index.php test/123456(senior tester). 目前自动化测试管理剩下一些修补的工作，像是邮件配置，明确权限管理、测试流程等，需要在业余时间慢慢做完，只是繁琐，应该不难。另外计划在4月份可以准备一次《基于Testlink&Bugfree的测试管理工具UserGuide》的内部交流。

最后总结一下整个自动化测试管理的过程，最大的感触就是“选择比努力更重要”，和人生一样，永远不只是A和B的选择，应该还有C。另外一个感触是，很多实验没有做彻底有些遗憾（主要是时间成本），无法确切定位问题，疏漏难免，因此非常欢迎大家的建议和指导！来电来函均有来必复～

自动化测试的测试管理这一块，一开始的时候先是想用TD(TestDirect测试届很流行的一款测试管理软件，比较成熟，包括测试需求、计划管理，Bug管理，报告生成等)的，QC（Quality Center，其实和TD是一家，目前TD已经不再升级了）直接淘汰，主要是目前为止，我还没有看见过unlimited的破解码，而没有看到效果直接让公司掏钱买当然更不合理。

经过仔细评估，TD也淘汰了。因为我们CCI的工作流程已经非常成熟，早就有了一整套的开发测试的工作流程，也有管理bug的软件。所以自动化的测试管理实际上CCI已经做到够用，当然从长远来看，有一个稳定且强大的自动化测试管理系统是非常必要的。而目前改革的必要则不大。不要为了自动化而自动化，就是这个道理啦！

需要进行自动化测试管理的范围最终缩小在回归测试，这是测试工作最辛苦的部分。回归测试需要保证测试环境的稳定，保证新增功能正常，还要验证旧的功能，主要原因是在于永远都是一个非常紧迫的Deadline，枯燥而又紧张，能否充分测试是个永远的问题。不光是在我们部门，整个测试界都为之头痛。而我考虑这个问题也真的是很久很久了，假期的某一天我突然想到，为什么不用开源的工具来为CCI的回归测试定制一套自动化的管理工具呢？

这样做的好处有很多，首先是免费，因为免费，公司就不需要承担用盗版软件侵权的风险，也便于给其他的部门推广；第二是开源，因为开源，就可以定制真正适合我们的管理工具；第三还是开源，使用的时候有什么问题，或软件有Bug，都可以通过改写调试来解决。

我同样考虑了这样做的风险，最大的自然就是技术上的，能不能找到合适的开源软件是第一个问题，毕竟开源的工具不会像主流的商业工作做得那样完善。能不能去改代码适应我们是第二个问题，如果将来多数的功能没有现成的全部要自己来写，成本会不会太高？至于第三个也是最关键的问题，在CCI使用后会不会有我预期的效果，我倒是不太担心，如果不好用，就没有使用的必要了，最差也就是维持现状。所以我觉得还是值得一试，只要遇到问题尽最大努力去解决。

再下面我就仔细考虑回归测试中的具体问题了，以争取在后面的工作中能够全部或者大部分的改进。在这里再一次给大家推荐“思维导图”的方法，和很多同事分享过，这一次我又使用这个方法快速地锁定要解决的问题。画了好多，经过筛选，按照角色挑出来三个主要问题：

1、测试组长：现阶段回归测试的任务管理是测试组长独立承担，通过发送邮件给大家分配工作；工作进行后会通过询问跟进每个人的完成情况，了解存在问题等；全凭组长的责任心记清问题，提交给相关人员解决。弊端显而易见，耗时，费事，任务较繁重时难免焦头烂额。

2、网管：要保证测试环境的稳定真的不是一件轻松的工作，特别是我们这样一个功能完善的系统，有这么多人使用，有些配置被改动可能就会影响正常的测试；回归测试中很常见这样的情况，一个又一个测试工程师给网管说，“给我看看XX配置，我等着测哪！”“那个XX功能还没好，先给我看看好不好？”“啊，那个功能改好了，怎么不告诉我一声，等半天了。”同样的，如果配置不稳定，网管的工作效率很容易成为整个回归测试的瓶颈。

3、项目经理：需要了解进度时也是通过询问的方式；还有如果测试组需要项目经理协调解决一些问题时，同样是询问。

将测试工程师排除出来不是说没有问题，而是1，2，3已经包括。针对1，需建立测试计划分配、以及任务跟进的机制。针对2，需要包括任务优先级定义设置；针对3，需要建立自动生成测试进度报告；1，2，3都需要建立自动通知的机制。

因为服务器的原因，我提交的Test Case没有更新，美国的工程师照着旧的Test Case将该单元fail了。

这件事完全由于我的失误，作为一名测试工程师，一定要在Pass之前Confirm所有相关的内容。

这应该是最起码的责任心。

之所以写在这里，是我希望自己一定要记住这点，不要忘了！切记！

＝＝＝

2008年1月10日 追加

第二点，还是今天实实在在发生的哦！差一点犯错～记住！
上一轮的回归测试之中，发现了不少bug，有好多是serious的，
而这一个是medium的级别，开发工程师Confirm的时候，说是一个配置的原因
如果配置项修改了，就不会出现，所以不是bug。并且说他尝试了多组数据，都没有再出现。

于是我按照他说的，用了几组数据来试，看上去真的是配置的问题。
因为在测试的时候，确实没有注意到这个配置项是相关的。
幸好自己又多试了一组数据，只是一组，发现这个配置根本不起作用！！！
然后后面再试的，就是又证明了而已！原来这还是个bug啊！
我都差一点给Close了！

于是跟工程师道歉，告诉他测试的时候确实没有关注到这个配置项，他能给指出真是很了不起。
同时也跟他讲，可能这个问题还需要我们一起进一步来研究看问题出现在什么地方，于是他很爽快地答应了！！！