我已经离开学校几年了，最近刚开始回去重新阅读我的一些教科书（我想保持新鲜感）。我实际上发现了我的软件工程教科书引人入胜并计划阅读整个事情 - 如果有趣的话，因为当我在学校时我发现它非常无聊。
所以有一个半章致力于集成测试。而且，就像学术界的大多数事情一样，这是所有理论，在阅读的任何地方都没有实际应用。但是，它让我思考。
我们使用 CruiseControl 进行持续集成测试，但是看到我们是一个大型开发团队并且我没有处理部署/构建/发布，我从来没有亲自动手。当我打破夜间构建时，我不时会收到一封电子邮件。两个技术导致我自己解释。
回答我的问题：我的旧教科书将集成测试称为组件之间的配对和测试，而不是针对1个特定类的单元测试。这可以通过“自上而下”或“自下而上”的方法完成，其中自上而下意味着将整个事物作为一个系统进行测试，然后递归地将系统分解为更小的子系统并对其进行测试;自下而上意味着相反（从小开始，变大）。
我的问题：
以下三个概念如何相互关联：
前两个中是否有“整合”这个词，这只是巧合吗？执行“夜间构建”与运行连续集成服务器（在晚上）相同，还是两个单独的概念？
如果持续集成测试＆amp;每晚建筑与学术集成测试绝对没有什么，那么集成测试如何在现实世界中真正体现出来呢？他们的框架像JUnit一样，但只关注集成测试吗？
我知道这些问题很多，但它们实际上只是归结为了解每个问题以及它们的使用方式。在线搜索每一个都会回退相当模糊，抽象的答案。
答案 0 :(得分：5)
在几行中解释得太过分了。
持续集成基本上是自动检出，构建，测试，代码质量检查，部署等等的循环。 它的测试部分包括单元测试（单元代码），集成测试（对数据库或外部资源的依赖）以及junit，rspec等工具和框架。
这些可以安排在夜间构建中并定期构建。
像cruisecontrol，hudson这样的连续集成工具可以帮助您配置此过程。 它更像是一个执行不同任务的调度程序，通过添加通知和工件管理来定义依赖项等等。
所有这些都是相互依存的。
更多信息@ http://martinfowler.com/articles/continuousIntegration.html
答案 1 :(得分：1)
＆＃34;集成测试＆＃34;有多种用途;使用＆＃34;整合＆＃34;在＆＃34;集成测试＆＃34;和＆＃34;持续整合＆＃34;是因为整合测试的意义和＃34;这在过去比较常见。
＆＃34;集成测试＆＃34;通常是指一次测试所有代码的测试，或者一次测试至少几个代码的测试。它是＆＃34;单元测试＆＃34;的补充，它一次测试一个代码的单个模块。在大多数项目中，单元和集成测试在同一测试套件中运行。在大型项目中，特别是在过去，当软件行业不擅长自动化测试时，集成测试可能在一个单独的过程中，在由不同团队的工作组装的系统上完成。 ＆＃34;整合＆＃34;在＆＃34;持续整合＆＃34;来自后一种用法。
＆＃34;持续整合＆＃34;是每次源代码更改时运行项目构建的做法。 ＆＃34;生成＆＃34;包括编译（如果您的语言需要编译），生成要部署的工件，以及运行自动化测试（包括单元和集成测试）。持续集成服务器通过观察源代码，开始构建和报告结果来支持此过程。
＆＃34;每晚构建＆＃34;是一夜之间运行项目构建的做法。在大多数情况下，它已经被持续集成所取代，因为最好知道你的构建会尽快被破坏。