logo标签列表

你正在使用哪些自动化构建系统？你的构建需要多长时间？

build-automationautomated-tests
3

我的当前项目有5个独立的自动化构建，每次检入后都会启动：
单元测试（DB调用被模拟）：约6分钟
集成测试（只针对DB）：约40分钟
网站1 UI（Selenium，从UI到DB）：约80分钟
网站2 UI1（Selenium，从UI到DB）：约90分钟
网站2 UI2（Selenium，从UI到DB）：约100分钟

我们使用Maven2、JUnit和Selenium。

我认为一种可以极大地减少集成测试时间的策略是尽可能将多余的集成测试移入到单元测试中，并仅使用集成项目来测试与DB的持久性。

我想知道您发现了哪些有助于减少大型项目构建时间的策略。

8个回答
2
我们的构建运行时间几乎相同，可能在Selenium上略微少一些（我会说大约是Firefox、IE和Opera上同一站点测试的3x50分钟运行时间）。我们的解决方案是投入更多的CPU资源，我们有一个由7个双核节点组成的bamboo集群环境。
我们发现将Selenium-RC和浏览器与Web容器/Selenium测试分开在不同的机器上运行可以显著提高Selenium的运行时间。
1

我使用GNU make来自动化一切。根据项目的不同，它可能需要2分钟到30分钟不等的时间。

0

团队系统：一小时内完成所有事情

0
我假设你的项目由几个子项目组成。如果不是这样，你可能想要重构代码库，使其成为这样。这样，你可以选择只构建整个应用程序的特定部分，测试单个部分，然后在你解决正在处理的子项目上的错误后运行集成测试。
0
我们使用Hudson来构建一个包含一些Windows服务、Web服务和可执行文件的大型C#解决方案。通过MSTest.exe进行约800个测试，每次构建需要大约12-15分钟。由于MSTest速度较慢，测试占用了很大一部分时间。
为了缩短时间，我们尝试限制运行通过MSTest生成的程序集的数量，因为安装和拆卸似乎需要一段时间。
编辑：我们的构建还部署到我们的证书环境，其中包括Web服务、Windows服务、可执行文件和数据库部署。这只是为了让您了解范围。
0

Erlang通用测试 - 主要关注系统测试而不是单元测试。

0

我们所有的自动化构建都是使用Team City完成的。

我们最自动化的项目实际上是一个编译器。我们的测试套件包括大约20000个测试查询，这些查询被编译和运行，并在每次检入时运行。这曾经需要大部分时间，但是将完整的测试套件保存在构建机器的RAM驱动器中（而不是每次检出）可以将其缩短到几分钟。

每晚会触发第二个构建，运行相同的测试，但在4个不同的配置文件下运行，同时在NCover下运行，生成代码覆盖率报告。这种情况需要几个小时，因此它作为夜间构建来完成。同时还会生成其他内部报告，以确保一切正常。

测试套件本身的更新是单独触发并检出到RAM驱动器中，准备进行下一次运行。否则，检出测试需要大部分构建时间。测试套件的一部分来自于一个我们无法控制的远程CVS存储库，即使查询此存储库的更新也会增加几分钟的构建时间，因此这也是在“更新测试”构建中完成的。这种松散耦合意味着我们必须将此项目的构建限制在一台机器上，但由于反馈非常快，这不是一个大问题。

保持“常规”测试构建尽可能快，同时保持代码库的高覆盖率已被证明非常有帮助。任何慢速测试（超过一秒钟左右）都已被推迟到夜间构建。在我们的情况下，将测试保存在RAM驱动器中确实有所帮助，尽管我们的场景相当专业化。我想模拟数据库是最接近的等效方法。我的建议是通过删除任何“笨重”或缓慢的测试来保持一个构建“精简而高效”，从而允许快速响应以知道您可能没有破坏任何东西。其他构建可以在单独的机器上运行，或者在晚上运行，以便从快速构建中快速响应。
为了更好地理解，我们有另一个项目的最长自动化构建有时需要超过一天的时间，尽管幸运的是它不需要经常运行。
0

在我目前的客户那里，不幸的是，BuildForge（来自ClearCase SCC）需要一到三天的时间。真的。我不知道他们在构建过程中做了什么，也不知道为什么需要这么长时间。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接