“集成测试”、“持续集成服务器”和“集成测试”之间的关系是什么？和“夜间构建”？
我已经离开学校几年了，最近才开始回去重新阅读一些教科书（我想保持新鲜感）。事实上，我发现我的软件工程教科书令人着迷，并计划阅读整本书 - 这很有趣，因为当我在学校时，我发现它非常无聊。
所以有半章专门讨论集成测试。而且，就像学术界的大多数事情一样，这都是理论，在阅读中几乎没有实际应用性。但是，这引起了我的思考。
我们使用 CruiseControl 进行持续集成测试，但由于我们是一个大型开发团队，而且我不处理部署/构建/发布，因此我从未亲自使用过它。当我打破夜间构建时，我只是时不时地收到一封电子邮件。两位技术主管需要向我解释一下。
继续我的问题：我的旧教科书将集成测试称为组件之间的配对和测试，而不是针对 1 个特定类的单元测试。这可以通过“自上而下”或“自下而上”的方法来完成，其中自上而下意味着将整个系统作为一个系统进行测试，然后递归地将系统分解为更小的子系统并对其进行测试；自下而上意味着相反的情况（从小处开始，逐渐扩大）。
我的问题：
以下三个概念如何相互关联：
- 集成测试的学术解释；以及
- 所谓的“持续集成服务器”，例如 Hudson、Jenkins 或 CruiseControl；以及
- “夜间构建”的概念，其中代码从 SCM 中检出并自动编译，
前两个中包含“集成”一词只是巧合吗？执行“夜间构建”与运行持续集成服务器（夜间）相同，还是它们是两个不同的概念？
如果持续集成测试& Nightly Building 与学术集成测试完全无关，那么集成测试在现实世界中实际上是如何表现的呢？他们的框架（例如 JUnit）是否已经退出，但只专注于集成测试？
我知道这些问题很多，但归根结底只是了解它们是什么以及如何使用它们。对这些问题的在线搜索都会得出相当模糊、抽象的答案。
I've been out of school for a few years now, and just recently started going back and re-reading some of my textbooks (I want to stay fresh). I've actually found my software engineering textbook fascinating and plan on reading the whole thing - which if funny, because when I was in school I found it horrifically boring.
So there's a half-chapter dedicated to integration testing. And, like most things in academia, it's all theory with very little practical applicability anywhere in the reading. But, it got me thinking.
We use CruiseControl for continuous integration testing, but seeing that we are a large development team and I don't handle deployments/builds/releases, I've never worked with it hands-on. I just get an email every now and again when I break the nightly build. And two tech leads to explain myself to.
Getting on to my question: my old textbook refers to integration testing as the pairing and testing of components with each other, as opposed to unit tests which target 1 particular class. This can be done in a "top-down" or "bottom-up" approach, where top-down implies testing the whole things as a system, and then recursively breaking down the system into smaller subystems and testing them; bottom-up implies the opposite (start small, grow big).
My question:
How do the following threee concepts relate to each other:
- This academic explanation of integration testing; and
- So-called "continuous integration servers" like Hudson, Jenkins or CruiseControl; and
- The concept of having a "Nightly Build" where code is checked out of a SCM and compiled automatically
Is it just coincidence that the first two have the word "integration" in them? Is performing a "nightly build" the same as running a continuous integration server (at night), or are they two separate concepts?
And if continuous integration testing & nightly building have absolutely nothing to do with academic integration testing, then how does integration testing actually manifest itself in the real world? Are their frameworks like JUnit out their but that only concentrate on integration testing?
I know these are a lot of questions, but they really just boil down to understanding what each of these are and how they are used. Online searches for each of these pull back pretty vague, abstract answers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
内容过于庞大，无法用几行文字来解释。
持续集成基本上是自动检查、构建、测试、代码质量检查、部署等的循环。
其中的测试部分将包括单元测试（单元代码）、使用 junit、rspec 等工具和框架的集成测试（依赖数据库或外部资源）。
这些可以安排为每晚构建并定期构建。
像 Cruisecontrol、Hudson 这样的持续集成工具可以帮助您配置此过程。
它更像是执行不同任务的计划，定义依赖关系以及通知和工件管理等等。
所有这些几乎都是相互依赖的。
更多信息@http://martinfowler.com/articles/continuousIntegration.html
Too vast to explain in few lines.
Continuous integration is basically the cycle for automated checkouts, build, tests, code quality checks, deploy and much more.
The tests part of it would include the Unit testing (unit code), integration testing (with dependecies on database or external resources) with tools and frameworks like junit, rspec.
These can be scheduled for nightly builds and build on regular intervals.
Continous integration tools like cruisecontrol, hudson help you to configure this process.
Its more like a schedular to do different task, define dependencies with addition to notifications and artifact management and much more.
All of these are pretty much interdependent.
More info @ http://martinfowler.com/articles/continuousIntegration.html
“集成测试”有多种使用方式； “集成测试”和“持续集成”中使用“集成”一词是由于过去更常见的“集成测试”的含义。
“集成测试”通常是指一次测试所有代码的测试，或者至少一次测试几段代码的测试。它是“单元测试”的补充，“单元测试”一次测试代码的单个模块。在大多数项目中，单元测试和集成测试在同一个测试套件中运行。在大型项目中，特别是在过去，当软件行业不擅长自动化测试时，集成测试可能会在一个单独的过程中，在由不同团队的工作组装而成的系统上完成。 “持续集成”中的“集成”就来自于后一种用法。
“持续集成”是每次源代码更改时运行项目构建的做法。 “构建”包括编译（如果您的语言需要编译）、生成要部署的工件以及运行自动化测试（包括单元和集成测试）。持续集成服务器通过观察源代码、启动构建并报告结果来支持此过程。
“夜间构建”是连夜运行项目构建的做法。在大多数情况下，它已被持续集成所取代，因为最好尽快知道您的构建是否被破坏。
"Integration testing" is used in several ways; the use of the word "integration" in "integration testing" and "continuous integration" is due to a meaning of "integration testing" that was more common in the past.
"Integration testing" generally refers to tests that test all of one's code at once, or at least several pieces of one's code at once. It is the complement of "unit tests", which test a single module of one's code at a time. In most projects unit and integration tests run in the same test suite. In large projects, especially in the past when the software industry wasn't as good at automating tests, integration tests might be done in a separate process, on a system assembled from the work of different teams. The "integration" in "continuous integration" came from this latter usage.
"Continuous integration" is the practice of running your project's build every time the source code changes. "Build" includes compiling (if your language needs compiling), generating artifacts to deploy, and running automated tests (including unit and integration tests). Continous integration servers support this process by watching the source code, starting the build and reporting the results.
"Nightly build" is the practice of running your project's build overnight. It has been replaced in most cases by continuous integration, because it's better to know your build is broken as soon as possible.