持续集成和自动化测试策略

| 我在一家使用持续集成(TeamCity)的公司工作。每当有人在CI软件中进行检查时,都会开始构建并运行所有的Unit / Automated Test。问题是我们获得了7000多个单元测试+ 756个自动化测试(用于测试JavaScript,因为我们获得了非常复杂的UI逻辑来进行计算等)。正如您可以想象的那样,每当有人在所有过程中进行检查时,都要花两个多小时才能完成所有步骤(构建单元自动测试),因此我需要等待那么多时间才能得出结果,以了解是否我的签到可能破坏了自动测试或单元测试。最糟糕的情况是,当不止一个人签入某些东西,以便TeamCity开始排队进行构建时,在我无法获得有效结果之前,我最多要等半天!我们应该采取什么策略来加快这个过程?最好的做法是即使稍作改动即可运行所有自动化测试?     
已邀请:
        我将以两种方式来分解您的测试套件-目的是使它套件化,以便您和您的团队可以签到,喝杯咖啡,并在回到办公桌前从Team City获得一些有意义的反馈。 确定每次提交时您真正想要测试的内容,将其余测试移至按计划的时间间隔运行的套件(每小时,每晚-对您有用)。 如果同意运行每个提交的测试集仍然很大,请打破该设置并将其分布在并行运行的多个节点上。 您可能还想增强CI机器,这取决于您的东西的性质,将测试的工作目录保存在tmpfs(RAM磁盘)中。     
        我将在理论上进行讨论,我尚未将其付诸实践,但CI的目标是在夏季结束之前变得忙碌起来。 从我在开发人员中赢得了我最大尊重的人们所作的陈述中,我看到关于CI的最常见的测试策略就是将测试分为长期测试和短期测试。 然后,您将需要配置标准签入启动短期运行测试,以对解决方案进行基本验证。然后,在每晚的构建中,对于部署构建,则是您唯一需要运行完整的测试套件以对回归测试进行验证的时间。 旁白/替代答案:鉴于我尚未为自己设置CI,所以我从未理解他们基于构建代理进行定价的TeamCity业务模型。现在,我明白了如果您的测试套件花费这么长时间,为什么多个构建代理真正开始变得重要,因此能够一次运行5个构建就变得更加重要。因此,一种选择可能就是花更多的钱,暂时在子弹孔上贴上创可贴。     
        持续集成最适合与Git或Mercurial等分布式版本控制系统一起使用。 每个开发人员都可以经常签入本地存储库,而无需始终触发整个集成和UI测试仪式。 在本地完成功能后,可以将其签入中央存储库。因此,只有在添加了新功能和/或修复后,CI服务器才会运行所有耗时的测试。     
        您是否考虑过使用预先测试的提交?如果运行远程运行构建(不提交到VCS),则可以确保没有破坏VCS中的任何内容(只是因为您尚未提交)。而且您可以继续工作而不会出现问题。如果构建成功,则可以提交更改(即使您在同一文件中进行了其他更改)-如果通过TeamCity的插件提交,它将完全提交发送到服务器进行测试的代码。 这样,您不必等到TeamCity的构建完成就可以继续使用它。 免责声明:我是TeamCity开发人员。     

要回复问题请先登录注册