集成测试是一个总括术语吗？如果是，它包括哪些类型的测试？
我发现“集成测试”的概念令人困惑。似乎有相当多的解释和范围：
- 功能/验收测试（例如使用 Selenium 测试用户界面）
- 测试不同类/模块的集成软件一起（简单地一起测试两个或多个类，而不需要它们做任何特殊的事情，例如数据库调用之类的事情）
- 测试系统配置功能/功能独立（数据库集成有效，依赖项正确注入，安全基础类工作）
- 测试整个系统（运行使用数据库、Web 服务等的服务）
- 等等。
我开始将集成测试视为一个总括术语（而不是在编程中定义它）谈话，其中通常赋予它特定/严格的含义）：
- 集成测试包含：
- 单元集成测试（在不调用外部库的情况下测试同一包中不同类的集成）
- 功能/验收测试（例如，通过 Selenium 测试软件的最终输出）
- 系统测试（包括 维基百科文章)
在 Maven 默认生命周期中，只有“测试”和“集成测试”阶段。这似乎将测试大致分为两类，并且符合这些假设。
一般而言，有许多现有的问题和答案正在寻找单元测试、功能测试、回归测试等之间的差异。但是，我正在寻找有关集成测试的更具体的答案：如何对集成测试进行分类以及其中包含哪些内容？另外，您是否像我一样避免将软件测试大致分为两类：单元测试（1 个单元）与集成测试（2 个以上单元）？
I find the concept of 'integration testing' confusing. There seems to be quite a few explanations and scopes:
- Functional/acceptance testing (e.g. testing the user interface with for example, Selenium)
- Testing the integration of different classes/modules of software together (simply testing two or more classes together, without them doing anything special like db calls and stuff)
- Testing the system configuration function/feature-independently (database integration works, dependencies are correctly injected, security base classes work)
- Testing the system as whole (running services that use databases, web services, etc.)
- etc. etc.
I begin to see integration testing as an umbrella term (as opposed to defining it in programming talks, where specific/strict meaning is often given to it):
- Integration testing contains:
- Unit integration testing (test integration of different classes within the same package without calling external libraries)
- Functional/acceptance testing (test final output of the software through Selenium, for example)
- System testing (includes various, more technical & non-feature related tests as listed in Wikipedia article)
In Maven default lifecycle, there is only 'test' and 'integration-test' phases. This seems to split the tests into roughly two categories and would go along with these assumptions.
There are many existing questions and answers looking for differences between unit testing, functional testing, regression testing, etc. in general. However, I am looking for more specific answer regarding integration tests: how do you categorize integration testing and what do you include inside it? Also, do you shun splitting software testing roughly into two categories as I have done: unit tests (1 unit) vs. integration tests (2+ units)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
计算充满了重载的术语，这些术语对于与您交谈的任何程序员来说都有轻微（有时不是那么轻微）的不同含义。集成测试就是其中之一。
我倾向于支持您将集成测试解释为测试两个或多个插入在一起的单元。但这仍然相当模糊，因为我们对“单位”的定义可能不同。
我认为更重要的是，开发团队就集成测试的含义达成一致，而不是找到集成测试的真正定义。
Computing is full of overloaded terms that have a slightly (and sometimes not so slight) different meaning to any programmer you talk to. Integration testing is one of those.
I tend to favour your interpretation of integration testing as testing 2 or more units plugged together. But this is still rather fuzzy as we may have different definitions of what a 'unit' is.
I think it's more important that a team of developers agree on what they mean by integration testing rather than finding the one true definition of integration testing.
我的团队认为（用你的话），集成测试涵盖
，仅此而已。我们将系统测试和验收测试视为不同的系列。
我们对此进行了长时间的讨论，以确保我们在谈论测试时都使用相同的语言。
我并不是强烈反对您对集成测试的定义，但我只是说，如果与您一起工作的所有人都同意分类，那就太好了。
My team sees (using your words), integration testing as covering
and nothing else. System tests and acceptance tests we see as different families.
we had some lengthy discussions on this, to make sure that we were all speaking the same language when we talked about tests.
I'm not strongly disagreeing with what you define as integration tests, but I'm just saying that it's nice if all the people you're working with agree on a classification.
好吧，您有单元测试，其精确定义各不相同，但肯定包含使用类似 JUnit 的工具定义的所有测试，并以与源代码相同的方式组织。如果对于任何源代码文件，您只能找到一个测试，那么您找到的就是单元测试。
然后是系统测试，以尽可能接近客户能够看到的方式测试整个系统。
任何存在于这两件事之间的测试都是集成测试——既不与源代码同构，也不代表最终用户体验。
这两个类别之间存在相当大的差距，而这两个类别本身在实践中差异很大。这个差距可能包含许多潜在有用的测试，但这些测试的性质自然会有很大差异。
Well, you have unit testing, the precise definition of which varies, but certainly contain all those tests defined with a JUnit-like tool and organised in the same way as the source code. If for any source code file, you can find one and only one test, then the thing you found is a unit test.
And then there is system testing, which tests the complete system in as close as possible a way to a customer will see it.
Any testing that lives in the gap between those two things is an integration test - neither isomorphic with the source code nor representative of an end user experience.
That's a pretty big gap between two categories that themselves vary a lot in practise. That gap can contain a lot of potentially useful tests, but the nature of those tests will naturally vary pretty dramatically.