测试
现有问题
“测试”这个章节被安排到最后才说,并不是他有多么的难,而是领导给我出了一个难题:
在之前,程序员提交的代码未经过严格测试就提交到TFS服务器,所以我们很难时时刻刻可以获得一个稳定的版本。因此,领导希望程序员提交的代码必须由测试人员测试通过,才能真正提交到TFS。
当前,我们是已经有一套流程来处理这样的需求的,做法是:
- 程序员通过”项目工具“签出代码,此部分的代码会被锁定,其他人不能修改,签出的代码以某个业务单元为最小单位,例如一张销售订单;
- 修改完毕并本机测试通过后,通过“项目工具”提交代码,而“项目工具”的内部实际做法是将本地的源代码搁置到TFS,然后回滚本地代码。
- 业务设计师使用”项目工具“进行第一轮测试,工具实际做法是取消搁置集,并本地编译一个版本,完成测试后,进入下一轮测试;
- 测试人员完成第二轮测试,方法同上,当测试通过后,执行”入库“动作,即将搁置的源代码真正签入TFS代码库,并解除锁定。
此流程的确可以让测试完毕的代码才能进入代码库,但问题也很多:
- 最显而易见的问题是,锁定时间太长了。从程序员签出开始加锁,到测试完成才能解锁,程序员经常需要费力的调整任务,以便防止等待他人解锁造成的等待。甚至我询问程序员,他们告诉我,如果我锁定了代码,那么另外一个人如果也需要改这个代码又不愿意等,那么他会拷贝代码给我,让我一并处理,晕死。
- 另外一个问题是,以前的测试是基于同一个时间点的DLL,而现在测试基于不同时间点的源代码。程序员假设是1号完成的测试并提交(实际是搁置),他的环境是1号的总体代码+自己源代码。等到5号的时候测试开始工作时,测试获取的总体代码是5号的,但搁置集又是1号的,编译和测试的环境都不同了。
- 编译不通过,还会引发责任不明确的问题,如果上面的例子中5号代码未编译通过了,程序员会认为我1号的时候测试通过的啊,而后续代码签入者更觉得与我无关。
因此,我总想这个有个”万能钥匙“可以解开这个问题,而我,… … 没能找到。
经典的持续集成步骤
既然找不到新的方法,那么我们就来回顾经典的方法。下图展示了持续集成中开发人员级别的测试过程:
(图片摘自网络: http://www.slideshare.net/sagittatius/ss-8672114)
持续集成的步骤2中,在修改完毕后会自己增加测试,但如果你们的团队没有完全的自动化测试用例,那么可能会手动测试。步骤3和4都是完成自动化测试,通过快速而简单的测试,”立即“完成代码的签入过程。
可以看出,持续集成并不追求绝对的“稳定”后才提交的原则,而是相对稳定就提交代码。测试工作主要通过测试用例快速的完成,当测试已经完成后,代码实际已经签入到代码库。为解决这个问题,测试驱动的开发就要求开发人员自己编写BUG测试用例,非常严谨,但在一个还很不成熟的团队来说,有些困难。
在未进入最后发版前,我们都进行一种滚动式的测试,意思是,每天测试人员都获取最新的编译环境(如果有成功编译的环境的话),在此环境下进行测试,因为BUG总是很多,昨天发现的BUG很可能开发人员很快就修复了,测试人员熟悉这个BUG有利于快速再次测试,如果不幸这个BUG没有修复(我们当然不希望发生),再次要求修改,开发人员也很熟悉此BUG的情况,而不是一个长达一个月的测试完毕后再次测试时,程序员和测试人员都要费力的回忆这个BUG的情况(虽然BUG有完整的描述)。
这种测试方法显然也是不是“绝对”正确的,很可能昨天已经修复的BUG,在今天的新版本下又重新出现,而我们因为已经“测试通过”,所以不会再测试他了,而遗漏了这个BUG。对于这个问题,最常见的办法是,为每个BUG编写测试用例,这个就可以在后面的编译版本中不断的进行测试,从而避免问题的复发。
这种方式如果没有足够的测试用例,也不能防止某个“不负责任”的开发人员提交一个糟糕的代码,造成这个版本无法使用。当然,如果有足够的测试用例,会好些,至少能保证已测试的功能正常使用。所以,我给的答案是:无法完全的做到这个需求,只能通过建立大量的测试用例来尽力避免。
项目工具总结
我们在上面的文章中都提到项目工具,在这里总结一下,在VS的集成环境下,共包括以下功能:
这些功能,其“下载最新环境”、“依赖环境更新”和选项可以在独立的程序中使用,例如测试人员可以用他获取特定时间的环境,用于测试。
一个完整的产品单元其\src\目录下应包含以下文件,用于支持上面的功能:
- all.sln 包含所有项目定义的解决方案文件;
- downloadEnv.proj 下载最新的环境;
- debug.proj 启动调试;
- build.proj 编译指定的解决方案并部署到环境;
- updateRuntime.proj 部署最新组件到运行环境;
- integration_One.proj 持续集成的第一个步骤;
- integration_two.proj 持续集成的第二个步骤;
通过这些一系列的MSBuild过程,配合软件的集成,完成对项目的管理。对于此项目工具有兴趣的话,可以留言是否建立一个开源项目。