zoukankan      html  css  js  c++  java
  • 大型.NET项目的目录、编译和版本管理实践 五

    测试

    现有问题

    “测试”这个章节被安排到最后才说,并不是他有多么的难,而是领导给我出了一个难题:

    在之前,程序员提交的代码未经过严格测试就提交到TFS服务器,所以我们很难时时刻刻可以获得一个稳定的版本。因此,领导希望程序员提交的代码必须由测试人员测试通过,才能真正提交到TFS。

    当前,我们是已经有一套流程来处理这样的需求的,做法是:

    • 程序员通过”项目工具“签出代码,此部分的代码会被锁定,其他人不能修改,签出的代码以某个业务单元为最小单位,例如一张销售订单;
    • 修改完毕并本机测试通过后,通过“项目工具”提交代码,而“项目工具”的内部实际做法是将本地的源代码搁置到TFS,然后回滚本地代码。
    • 业务设计师使用”项目工具“进行第一轮测试,工具实际做法是取消搁置集,并本地编译一个版本,完成测试后,进入下一轮测试;
    • 测试人员完成第二轮测试,方法同上,当测试通过后,执行”入库“动作,即将搁置的源代码真正签入TFS代码库,并解除锁定。

    此流程的确可以让测试完毕的代码才能进入代码库,但问题也很多:

    • 最显而易见的问题是,锁定时间太长了。从程序员签出开始加锁,到测试完成才能解锁,程序员经常需要费力的调整任务,以便防止等待他人解锁造成的等待。甚至我询问程序员,他们告诉我,如果我锁定了代码,那么另外一个人如果也需要改这个代码又不愿意等,那么他会拷贝代码给我,让我一并处理,晕死。
    • 另外一个问题是,以前的测试是基于同一个时间点的DLL,而现在测试基于不同时间点的源代码。程序员假设是1号完成的测试并提交(实际是搁置),他的环境是1号的总体代码+自己源代码。等到5号的时候测试开始工作时,测试获取的总体代码是5号的,但搁置集又是1号的,编译和测试的环境都不同了。
    • 编译不通过,还会引发责任不明确的问题,如果上面的例子中5号代码未编译通过了,程序员会认为我1号的时候测试通过的啊,而后续代码签入者更觉得与我无关。

    因此,我总想这个有个”万能钥匙“可以解开这个问题,而我,… … 没能找到。

    经典的持续集成步骤

    既然找不到新的方法,那么我们就来回顾经典的方法。下图展示了持续集成中开发人员级别的测试过程:

    image

    (图片摘自网络: http://www.slideshare.net/sagittatius/ss-8672114

    持续集成的步骤2中,在修改完毕后会自己增加测试,但如果你们的团队没有完全的自动化测试用例,那么可能会手动测试。步骤3和4都是完成自动化测试,通过快速而简单的测试,”立即“完成代码的签入过程。

    可以看出,持续集成并不追求绝对的“稳定”后才提交的原则,而是相对稳定就提交代码。测试工作主要通过测试用例快速的完成,当测试已经完成后,代码实际已经签入到代码库。为解决这个问题,测试驱动的开发就要求开发人员自己编写BUG测试用例,非常严谨,但在一个还很不成熟的团队来说,有些困难。

    在未进入最后发版前,我们都进行一种滚动式的测试,意思是,每天测试人员都获取最新的编译环境(如果有成功编译的环境的话),在此环境下进行测试,因为BUG总是很多,昨天发现的BUG很可能开发人员很快就修复了,测试人员熟悉这个BUG有利于快速再次测试,如果不幸这个BUG没有修复(我们当然不希望发生),再次要求修改,开发人员也很熟悉此BUG的情况,而不是一个长达一个月的测试完毕后再次测试时,程序员和测试人员都要费力的回忆这个BUG的情况(虽然BUG有完整的描述)。

    这种测试方法显然也是不是“绝对”正确的,很可能昨天已经修复的BUG,在今天的新版本下又重新出现,而我们因为已经“测试通过”,所以不会再测试他了,而遗漏了这个BUG。对于这个问题,最常见的办法是,为每个BUG编写测试用例,这个就可以在后面的编译版本中不断的进行测试,从而避免问题的复发。

    这种方式如果没有足够的测试用例,也不能防止某个“不负责任”的开发人员提交一个糟糕的代码,造成这个版本无法使用。当然,如果有足够的测试用例,会好些,至少能保证已测试的功能正常使用。所以,我给的答案是:无法完全的做到这个需求,只能通过建立大量的测试用例来尽力避免。

    项目工具总结

    我们在上面的文章中都提到项目工具,在这里总结一下,在VS的集成环境下,共包括以下功能:

    image

    这些功能,其“下载最新环境”、“依赖环境更新”和选项可以在独立的程序中使用,例如测试人员可以用他获取特定时间的环境,用于测试。

    一个完整的产品单元其\src\目录下应包含以下文件,用于支持上面的功能:

    • all.sln   包含所有项目定义的解决方案文件;
    • downloadEnv.proj    下载最新的环境;
    • debug.proj   启动调试;
    • build.proj   编译指定的解决方案并部署到环境;
    • updateRuntime.proj   部署最新组件到运行环境;
    • integration_One.proj   持续集成的第一个步骤;
    • integration_two.proj  持续集成的第二个步骤;

    通过这些一系列的MSBuild过程,配合软件的集成,完成对项目的管理。对于此项目工具有兴趣的话,可以留言是否建立一个开源项目。

  • 相关阅读:
    Scrapy入门教程
    清华申请退学博士作品:完全用Linux工作
    Linux 计划任务 Crontab 笔记与总结(5)crontab 常见错误与案例
    《一个民企CEO的职场阳谋》–读书总结(下)
    《一个民企CEO的职场阳谋》–读书总结(上)
    《一个民企CEO的职场阳谋》–读书总结(上)
    CSDN开博一周年--总结、感想和未来规划
    《程序员,你伤不起》–读书笔记-序
    《程序员,你伤不起》–读书笔记-序
    3位同学简历中的14个问题
  • 原文地址:https://www.cnblogs.com/tansm/p/2452205.html
Copyright © 2011-2022 走看看