软件的测试与发布

前言

看见有同学讨论公司产品开发过程中的单元测试、集成测试、代码审查、签入、发布等问题,我来说说我以前服务过的公司的做法。

最差的情况是,没有测试、审查,直接签入、发布,所以系统不稳定。

最好的情况,我详细说说。

编码规范

某个我服务过的公司,把代码规范做到近乎极致:严格使用FxCop:多一个空格、空行、private关键字都不允许,条件判断后一行代码必须{}等等、等等,自己实现一套更严格的代码检测:所有字符串必须支持多语言除非写例外禁止、代码全局全文拼写错误检测,等等等等。

另外,namespace必须顺序而且System必须前面,static readonly顺序不能掉转,全局变量不允许_,引用dll不允许copy local,不允许“”只能String.Empty,所有警告视为错误,必须打开overflow check,参试列表要么同一行要么全部分列。

一般新人来会被这些要求逼疯。

代码维护

该系统比较大,2200万行代码,几千个项目,所以自己搞了一套系统,整合了TFS,自动做各种shelf/取所有项目最新版本等事情,自动判断某个项目已经最近被编译,如果是就从缓存取出来无需再编译。

单元测试/整合测试 (Unit Testing/Integration Testing)

该系统有60多万个单元/整合测试,每个项目,不管什么类型的程序(Web页面/console/windows 服务/窗体界面),不过什么什么业务,都带有测试,而且这个测试还有大量的各种严格、智能的玩法,譬如实现类要测,基类都自动测;又譬如数据库相关的测试,强制打开事务/snapshot,完成测试自动回滚,然后判断是否有差异就报错。

签入(Shelf/Check-in)

这套系统禁止手工签入(check-in),这个禁止是系统根本不允许开发人员签入,任何开发人员必须通过shelf把代码提交到下面的自动化分布式编译/测试系统。这个好处是避免了任何人都可以随意把代码搞爆。

自动化分布式编译/测试(CI)

因为测试数量巨大,自己搞了一套分布式编译/测试系统。因为开发人员的机器配置相当高,譬如i9+1TB SSD,所以充分利用了几百台的开发人员机器,都给安装上了2个Hyper-V实例,在里面做CI。

大家可能没理解好,觉得市面上的Team City等都能分布式编译/测试,但是他们这种一般是一个提交只能在一个worker上编译和跑所有测试。但这套东西能把任意测试根据最优解自由组合,然后分布式到几百台*2个Hyper-V里面去做编译CI。譬如60万个测试里面,某几千个,是在机器001跑。

还有,这个测试不会盲目地跑所有60多万个测试,会自动判断代码的改变会影响到那些测试,才去跑相关的测试。

而且最关键的是,这套系统能最优解合并最近大家提交的shelf,然后再去做CI,都成功的话大家都pass,如果失败,再拆开单独跑失败的测试,这样就能节省大量时间。

代码审查(Review)和可用性测试

当上述的自动化分布式编译/测试通过之后,代码审阅者对代码分析、实际跑过之后,才标识该shelf通过,然后开发人员才能交给自动化分布式编译系统去签入代码。

 

版权所有

所有文章内容版权所有,任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

发表评论