工具集很大程度上取决于代码库，但有许多用于单元测试的开源工具（JUnit）。 HP (Mercury) QTP 或 Borland 的 Silk Test 都是自动化集成和回归测试的工具。
Unit test: Verifying that particular component (i.e., class) created or modified functions as designed. This test can be manual or automated, but it does not move beyond the boundary of the component.
Integration test: Verifying that the interaction of particular components function as designed. Integration tests can be performed at the unit level or the system level. These tests can be manual or automated.
Regression test: Verifying that new defects are not introduced into existing code. These tests can be manual or automated.
Depending upon your SDLC (waterfall, RUP, agile, etc.) particular tests may be performed in 'phases' or may all be performed, more or less, at the same time. For example, unit testing may be limited to developers who then turn the code over to testers for integration and regression testing. However, another approach might have developers doing unit testing and some level of integration and regression testing (using a TDD approach along with continuous integration and automated unit and regression tests).
The tool set will depend largely on the codebase, but there are many open source tools for unit testing (JUnit). HP's (Mercury) QTP or Borland's Silk Test are both tools for automated integration and regression testing.
"A regression test re-runs previous tests against the changed software to ensure that the changes made in the current software do not affect the functionality of the existing software."
I just wanted to add and give some more context on why we have these levels of test, what they really mean with examples
Mike Cohn in his book “Succeeding with Agile” came up with the “Testing Pyramid” as a way to approach automated tests in projects. There are various interpretations of this model. The model explains what kind of automated tests need to be created, how fast they can give feedback on the application under test and who writes these tests. There are basically 3 levels of automated testing needed for any project and they are as follows.
Unit Tests- These test the smallest component of your software application. This could literally be one function in a code which computes a value based on some inputs. This function is part of several other functions of the hardware/software codebase that makes up the application.
For example - Let’s take a web based calculator application. The smallest components of this application that needs to be unit tested could be a function that performs addition, another that performs subtraction and so on. All these small functions put together makes up the calculator application.
Historically developer writes these tests as they are usually written in the same programming language as the software application. Unit testing frameworks such as JUnit and NUnit (for java), MSTest (for C# and .NET) and Jasmine/Mocha (for JavaScript) are used for this purpose.
The biggest advantage of unit tests are, they run really fast underneath the UI and we can get quick feedback about the application. This should comprise more than 50% of your automated tests.
API/Integration Tests- These test various components of the software system together. The components could include testing databases, API’s (Application Programming Interface), 3rd party tools and services along with the application.
For example - In our calculator example above, the web application may use a database to store values, use API’s to do some server side validations and it may use a 3rd party tool/service to publish results to the cloud to make it available across different platforms.
Historically a developer or technical QA would write these tests using various tools such as Postman, SoapUI, JMeter and other tools like Testim.
These run much faster than UI tests as they still run underneath the hood but may consume a little more time than unit tests as it has to check the communication between various independent components of the system and ensure they have seamless integration. This should comprise more that 30% of the automated tests.
UI Tests- Finally, we have tests that validate the UI of the application. These tests are usually written to test end to end flows through the application.
For example - In the calculator application, an end to end flow could be, opening up the browser-> Entering the calculator application url -> Logging in with username/password -> Opening up the calculator application -> Performing some operations on the calculator -> verifying those results from the UI -> Logging out of the application. This could be one end to end flow that would be a good candidate for UI automation.
Historically, technical QA’s or manual testers write UI tests. They use open source frameworks like Selenium or UI testing platforms like Testim to author, execute and maintain the tests. These tests give more visual feedback as you can see how the tests are running, the difference between the expected and actual results through screenshots, logs, test reports.
The biggest limitation of UI tests is, they are relatively slow compared to Unit and API level tests. So, it should comprise only 10-20% of the overall automated tests.
The next two types of tests can vary based on your project but the idea is-
Smoke Tests
This can be a combination of the above 3 levels of testing. The idea is to run it during every code check in and ensure the critical functionalities of the system are still working as expected; after the new code changes are merged. They typically need to run with 5 - 10 mins to get faster feedback on failures
Regression Tests
They usually are run once a day at least and cover various functionalities of the system. They ensure the application is still working as expected. They are more details than the smoke tests and cover more scenarios of the application including the non-critical ones.
Integration testing: Integration testing is the integrate another element
Smoke testing: Smoke testing is also known as build version testing. Smoke testing is the initial testing process exercised to check whether the software under test is ready/stable for further testing.
Regression testing: Regression testing is repeated testing. Whether new software is effected in another module or not.
Unit testing: It is a white box testing. Only developers involve in it
Unit testing is directed at the smallest part of the implementation possible. In Java this means you are testing a single class. If the class depends on other classes these are faked.
When your test calls more than one class, it's an integration test.
Full test suites can take a long time to run, so after a change many teams run some quick to complete tests to detect significant breakages. For example, you have broken the URIs to essential resources. These are the smoke tests.
Regression tests run on every build and allow you to refactor effectively by catching what you break. Any kind of test can be regression test, but I find unit tests are most helpful finding the source of fault.
Unit testing is usually done by the developers side, whereas testers are partly evolved in this type of testing where testing is done unit by unit. In Java JUnit test cases can also be possible to test whether the written code is perfectly designed or not.
Integration Testing:
This type of testing is possible after the unit testing when all/some components are integrated. This type of testing will make sure that when components are integrated, do they affect each others' working capabilities or functionalities?
Smoke Testing
This type of testing is done at the last when system is integrated successfully and ready to go on production server.
This type of testing will make sure that every important functionality from start to end is working fine and system is ready to deploy on production server.
Regression Testing
This type of testing is important to test that unintended/unwanted defects are not present in the system when developer fixed some issues. This testing also make sure that all the bugs are successfully solved and because of that no other issues are occurred.
Smoke and sanity testing are both performed after a software build to identify whether to start testing. Sanity may or may not be executed after smoke testing. They can be executed separately or at the same time - sanity being immediately after smoke.
Because sanity testing is more in-depth and takes more time, in most cases it is well worth to be automated.
Smoke testing usually takes no longer than 5-30 minutes for execution. It is more general: it checks a small number of core functionalities of the whole system, in order to verify that the stability of the software is good enough for further testing and that there are no issues, blocking the run of the planned test cases.
Sanity testing is more detailed than smoke and may take from 15 minutes up to a whole day, depending on the scale of the new build. It is a more specialized type of acceptance testing, performed after progression or re-testing. It checks the core features of certain new functionalities and/or bug fixes together with some closely related to them features, in order to verify that they are functioning as to the required operational logic, before regression testing can be executed at a larger scale.
Unit Testing: It always performs by developer after their development done to find out issue from their testing side before they make any requirement ready for QA.
Integration Testing: It means tester have to verify module to sub module verification when some data/function output are drive to one module to other module. Or in your system if using third party tool which using your system data for integrate.
Smoke Testing: tester performed to verify system for high-level testing and trying to find out show stopper bug before changes or code goes live.
Regression Testing: Tester performed regression for verification of existing functionality due to changes implemented in system for newly enhancement or changes in system.
Regression test - Is a type of software testing where we try to cover or check around the bug fix. The functionality around the bug fix should not get changed or altered due to the fix provided. Issues found in such process are called as regression issues.
Smoke Testing: Is a kind of testing done to decide whether to accept the build/software for further QA testing.
There are some good answers already, but I would like further refine them:
Unit testing is the only form of white box testing here. The others are black box testing. White box testing means that you know the input; you know the inner workings of the mechanism and can inspect it and you know the output. With black box testing you only know what the input is and what the output should be.
So clearly unit testing is the only white box testing here.
Unit testing test specific pieces of code. Usually methods.
Integration testing test whether your new feature piece of software can integrate with everything else.
Regression testing. This is testing done to make sure you haven't broken anything. Everything that used to work should still work.
Smoke testing is done as a quick test to make sure everything looks okay before you get involved in the more vigorous testing.
Smoke tests have been explained here already and is simple. Regression tests come under integration tests.
Automated tests can be divided into just two.
Unit tests and integration tests (this is all that matters)
I would call use the phrase "long test" (LT) for all tests like integration tests, functional tests, regression tests, UI tests, etc. And unit tests as "short test".
An LT example could be, automatically loading a web page, logging in to the account and buying a book. If the test passes it is more likely to run on live site the same way(hence the 'better sleep' reference). Long = distance between web page (start) and database (end).
Unit test: Specify and test one point of the contract of single method of a class. This should have a very narrow and well defined scope. Complex dependencies and interactions to the outside world are stubbed or mocked.
Integration test: Test the correct inter-operation of multiple subsystems. There is whole spectrum there, from testing integration between two classes, to testing integration with the production environment.
Smoke test (akasanitycheck): A simple integration test where we just check that when the system under test is invoked it returns normally and does not blow up.
Smoke testing is both an analogy with electronics, where the first test occurs when powering up a circuit (if it smokes, it's bad!)...
... and, apparently, with plumbing, where a system of pipes is literally filled by smoke and then checked visually. If anything smokes, the system is leaky.
Regression test: A test that was written when a bug was fixed. It ensures that this specific bug will not occur again. The full name is "non-regression test". It can also be a test made prior to changing an application to make sure the application provides the same outcome.
To this, I will add:
Acceptance test: Test that a feature or use case is correctly implemented. It is similar to an integration test, but with a focus on the use case to provide rather than on the components involved.
System test: Tests a system as a black box. Dependencies on other systems are often mocked or stubbed during the test (otherwise it would be more of an integration test).
Pre-flight check: Tests that are repeated in a production-like environment, to alleviate the 'builds on my machine' syndrome. Often this is realized by doing an acceptance or smoke test in a production like environment.
Unit test: an automatic test to test the internal workings of a class. It should be a stand-alone test which is not related to other resources.
Integration test: an automatic test that is done on an environment, so similar to unit tests but with external resources (db, disk access)
Regression test: after implementing new features or bug fixes, you re-test scenarios which worked in the past. Here you cover the possibility in which your new features break existing features.
Smoke testing: first tests on which testers can conclude if they will continue testing.
Everyone will have slightly different definitions, and there are often grey areas. However:
Unit test: does this one little bit (as isolated as possible) work?
Integration test: do these two (or more) components work together?
Smoke test: does this whole system (as close to being a production system as possible) hang together reasonably well? (i.e. are we reasonably confident it won't create a black hole?)
Regression test: have we inadvertently re-introduced any bugs we'd previously fixed?
A new test category I've just become aware of is the canary test. A canary test is an automated, non-destructive test that is run on a regular basis in a live environment, such that if it ever fails, something really bad has happened.
Examples might be:
Has data that should only ever be available in development/testy appeared live?
Unit test: testing of an individual module or independent component in an application is known to be unit testing. The unit testing will be done by the developer.
Integration test: combining all the modules and testing the application to verify the communication and the data flow between the modules are working properly or not. This testing also performed by developers.
Smoke test In a smoke test they check the application in a shallow and wide manner. In smoke testing they check the main functionality of the application. If there is any blocker issue in the application they will report to developer team, and the developing team will fix it and rectify the defect, and give it back to the testing team. Now testing team will check all the modules to verify that changes made in one module will impact the other module or not. In smoke testing the test cases are scripted.
Regression testing executing the same test cases repeatedly to ensure tat the unchanged module does not cause any defect. Regression testting comes under functional testing
发布评论
评论（17）
单元测试：验证特定组件（即类）按设计创建或修改的功能。 该测试可以是手动的或自动的，但它不会超出组件的边界。
集成测试：验证特定组件的交互是否按设计运行。 集成测试可以在单元级别或系统级别执行。 这些测试可以是手动的或自动的。
回归测试：验证现有代码中没有引入新的缺陷。 这些测试可以是手动的或自动的。
取决于您的 SDLC (瀑布, RUP, < a href="https://en.wikipedia.org/wiki/Agile_software_development" rel="nofollow noreferrer">敏捷等）特定测试可以分“阶段”执行，也可以全部执行，更多或更少，同时。 例如，单元测试可能仅限于开发人员，然后开发人员将代码移交给测试人员进行集成和回归测试。 然而，另一种方法可能让开发人员进行单元测试以及某种程度的集成和回归测试（使用 TDD 方法以及持续集成和自动化单元和回归测试）。
工具集很大程度上取决于代码库，但有许多用于单元测试的开源工具（JUnit）。 HP (Mercury) QTP 或 Borland 的 Silk Test 都是自动化集成和回归测试的工具。
Unit test: Verifying that particular component (i.e., class) created or modified functions as designed. This test can be manual or automated, but it does not move beyond the boundary of the component.
Integration test: Verifying that the interaction of particular components function as designed. Integration tests can be performed at the unit level or the system level. These tests can be manual or automated.
Regression test: Verifying that new defects are not introduced into existing code. These tests can be manual or automated.
Depending upon your SDLC (waterfall, RUP, agile, etc.) particular tests may be performed in 'phases' or may all be performed, more or less, at the same time. For example, unit testing may be limited to developers who then turn the code over to testers for integration and regression testing. However, another approach might have developers doing unit testing and some level of integration and regression testing (using a TDD approach along with continuous integration and automated unit and regression tests).
The tool set will depend largely on the codebase, but there are many open source tools for unit testing (JUnit). HP's (Mercury) QTP or Borland's Silk Test are both tools for automated integration and regression testing.
回归测试-
“回归测试针对更改的软件重新运行以前的测试，以确保当前软件中所做的更改不会影响现有软件的功能。”
REGRESSION TESTING-
"A regression test re-runs previous tests against the changed software to ensure that the changes made in the current software do not affect the functionality of the existing software."
我只是想补充并提供更多背景信息，说明为什么我们有这些级别的测试，它们的真正含义是什么？
迈克·科恩（Mike Cohn）在他的书《敏捷的成功》中提出了“测试金字塔”作为实现自动化测试的一种方法在项目中。 对于这个模型有多种解释。 该模型解释了需要创建哪种类型的自动化测试、他们可以多快地对被测应用程序提供反馈以及由谁编写这些测试。
任何项目基本上都需要 3 个级别的自动化测试，如下所示。
单元测试-
这些测试软件应用程序的最小组件。 从字面上看，这可能是代码中的一个函数，它根据某些输入计算一个值。 此函数是构成应用程序的硬件/软件代码库的几个其他函数的一部分。
例如 - 让我们看一个基于 Web 的计算器应用程序。 该应用程序中需要进行单元测试的最小组件可能是执行加法的函数、执行减法的函数等等。 所有这些小功能组合在一起就构成了计算器应用程序。
从历史上看，开发人员编写这些测试是因为它们通常是用与软件应用程序相同的编程语言编写的。 JUnit 和 NUnit（针对 java）、MSTest（针对 C# 和 .NET）以及 Jasmine/Mocha（针对 JavaScript）等单元测试框架均用于此目的。
单元测试的最大优点是，它们在 UI 下运行得非常快，我们可以快速获得有关应用程序的反馈。 这应该占自动化测试的 50% 以上。
API/集成测试-
这些一起测试软件系统的各个组件。 这些组件可能包括测试数据库、API（应用程序编程接口）、第三方工具和服务以及应用程序。
例如 - 在上面的计算器示例中，Web 应用程序可能使用数据库来存储值，使用 API 进行一些服务器端验证，并且可能使用第 3 方工具/服务将结果发布到云，以使其在不同的环境中可用平台。
从历史上看，开发人员或技术 QA 会使用各种工具（例如 Postman、SoapUI、JMeter 和 Testim 等其他工具）编写这些测试。
这些测试比 UI 测试运行得快得多，因为它们仍然在底层运行，但可能比单元测试消耗更多的时间，因为它必须检查系统的各个独立组件之间的通信并确保它们具有无缝集成。 这应占自动化测试的 30% 以上。
用户界面测试-
最后，我们进行了验证应用程序 UI 的测试。 这些测试通常是为了测试应用程序中的端到端流程而编写的。
例如 - 在计算器应用程序中，端到端流程可以是打开浏览器-> 输入计算器应用程序 url -> 使用用户名/密码登录 -> 打开计算器应用程序 -> 在计算器上执行一些操作-> 从 UI 验证这些结果 -> 注销应用程序。 这可能是一个端到端的流程，非常适合 UI 自动化。
从历史上看，技术 QA 或手动测试人员编写 UI 测试。 他们使用 Selenium 等开源框架或 Testim 等 UI 测试平台来编写、执行和维护测试。 这些测试提供了更多的视觉反馈，因为您可以通过屏幕截图、日志、测试报告看到测试的运行情况、预期结果与实际结果之间的差异。
UI 测试的最大限制是，与单元和 API 级别测试相比，它们相对较慢。 因此，它应该只占整体自动化测试的 10-20%。
接下来的两种类型的测试可能会根据您的项目而有所不同，但其想法是 -
冒烟测试
这可以是上述 3 个级别的测试的组合。 这个想法是在每次代码签入期间运行它，并确保系统的关键功能仍然按预期工作； 合并新代码更改后。 它们通常需要运行 5 - 10 分钟才能更快地获得故障反馈
回归测试
它们通常至少每天运行一次，涵盖系统的各种功能。 他们确保应用程序仍按预期运行。 它们比冒烟测试更详细，涵盖了更多应用场景，包括非关键场景。
I just wanted to add and give some more context on why we have these levels of test, what they really mean with examples
Mike Cohn in his book “Succeeding with Agile” came up with the “Testing Pyramid” as a way to approach automated tests in projects. There are various interpretations of this model. The model explains what kind of automated tests need to be created, how fast they can give feedback on the application under test and who writes these tests.
There are basically 3 levels of automated testing needed for any project and they are as follows.
Unit Tests-
These test the smallest component of your software application. This could literally be one function in a code which computes a value based on some inputs. This function is part of several other functions of the hardware/software codebase that makes up the application.
For example - Let’s take a web based calculator application. The smallest components of this application that needs to be unit tested could be a function that performs addition, another that performs subtraction and so on. All these small functions put together makes up the calculator application.
Historically developer writes these tests as they are usually written in the same programming language as the software application. Unit testing frameworks such as JUnit and NUnit (for java), MSTest (for C# and .NET) and Jasmine/Mocha (for JavaScript) are used for this purpose.
The biggest advantage of unit tests are, they run really fast underneath the UI and we can get quick feedback about the application. This should comprise more than 50% of your automated tests.
API/Integration Tests-
These test various components of the software system together. The components could include testing databases, API’s (Application Programming Interface), 3rd party tools and services along with the application.
For example - In our calculator example above, the web application may use a database to store values, use API’s to do some server side validations and it may use a 3rd party tool/service to publish results to the cloud to make it available across different platforms.
Historically a developer or technical QA would write these tests using various tools such as Postman, SoapUI, JMeter and other tools like Testim.
These run much faster than UI tests as they still run underneath the hood but may consume a little more time than unit tests as it has to check the communication between various independent components of the system and ensure they have seamless integration. This should comprise more that 30% of the automated tests.
UI Tests-
Finally, we have tests that validate the UI of the application. These tests are usually written to test end to end flows through the application.
For example - In the calculator application, an end to end flow could be, opening up the browser-> Entering the calculator application url -> Logging in with username/password -> Opening up the calculator application -> Performing some operations on the calculator -> verifying those results from the UI -> Logging out of the application. This could be one end to end flow that would be a good candidate for UI automation.
Historically, technical QA’s or manual testers write UI tests. They use open source frameworks like Selenium or UI testing platforms like Testim to author, execute and maintain the tests. These tests give more visual feedback as you can see how the tests are running, the difference between the expected and actual results through screenshots, logs, test reports.
The biggest limitation of UI tests is, they are relatively slow compared to Unit and API level tests. So, it should comprise only 10-20% of the overall automated tests.
The next two types of tests can vary based on your project but the idea is-
Smoke Tests
This can be a combination of the above 3 levels of testing. The idea is to run it during every code check in and ensure the critical functionalities of the system are still working as expected; after the new code changes are merged. They typically need to run with 5 - 10 mins to get faster feedback on failures
Regression Tests
They usually are run once a day at least and cover various functionalities of the system. They ensure the application is still working as expected. They are more details than the smoke tests and cover more scenarios of the application including the non-critical ones.
单元测试针对可能实现的最小部分。 在 Java 中，这意味着您正在测试单个类。 如果该类依赖于其他类，则这些类是伪造的。
当您的测试调用多个类时，它就是集成测试。
完整的测试套件可能需要很长时间才能运行，因此在更改后，许多团队会运行一些快速完成的测试来检测重大损坏。 例如，您已将 URI 分解为重要资源。 这些是冒烟测试。
回归测试在每个构建上运行，并允许您通过捕获破坏的内容来有效地重构。 任何类型的测试都可以是回归测试，但我发现单元测试最有助于查找故障根源。
Unit testing is directed at the smallest part of the implementation possible. In Java this means you are testing a single class. If the class depends on other classes these are faked.
When your test calls more than one class, it's an integration test.
Full test suites can take a long time to run, so after a change many teams run some quick to complete tests to detect significant breakages. For example, you have broken the URIs to essential resources. These are the smoke tests.
Regression tests run on every build and allow you to refactor effectively by catching what you break. Any kind of test can be regression test, but I find unit tests are most helpful finding the source of fault.
单元测试
单元测试通常由开发人员完成，而测试人员部分是在这种类型的测试中发展起来的，其中测试是逐个单元完成的。
在Java中 JUnit 测试用例也可以测试编写的代码是否设计完美。
集成测试：
当所有/一些组件集成时，可以在单元测试之后进行这种类型的测试。 此类测试将确保组件集成时是否会影响彼此的工作能力或功能？
冒烟测试
这种类型的测试是在系统成功集成并准备好在生产服务器上运行时最后完成的。
此类测试将确保每个重要功能从开始到结束都正常工作，并且系统已准备好在生产服务器上部署。
回归测试
这种类型的测试对于测试开发人员修复某些问题时系统中是否不存在意外/不需要的缺陷非常重要。
此测试还确保所有错误均已成功解决，因此不会发生其他问题。
Unit Testing
Unit testing is usually done by the developers side, whereas testers are partly evolved in this type of testing where testing is done unit by unit.
In Java JUnit test cases can also be possible to test whether the written code is perfectly designed or not.
Integration Testing:
This type of testing is possible after the unit testing when all/some components are integrated. This type of testing will make sure that when components are integrated, do they affect each others' working capabilities or functionalities?
Smoke Testing
This type of testing is done at the last when system is integrated successfully and ready to go on production server.
This type of testing will make sure that every important functionality from start to end is working fine and system is ready to deploy on production server.
Regression Testing
This type of testing is important to test that unintended/unwanted defects are not present in the system when developer fixed some issues.
This testing also make sure that all the bugs are successfully solved and because of that no other issues are occurred.
冒烟测试和健全性测试都是在软件构建后执行的，以确定是否开始测试。 冒烟测试后可能会或可能不会执行理智。 它们可以单独执行，也可以同时执行——烟雾后立即恢复理智。
由于健全性测试更深入且需要更多时间，因此在大多数情况下非常值得实现自动化。
冒烟测试的执行时间通常不超过 5-30 分钟。 它更通用：它检查整个系统的少量核心功能，以验证软件的稳定性是否足够好以进行进一步测试，并且不存在阻碍计划测试用例运行的问题。
健全性测试比烟雾测试更详细，可能需要 15 分钟到一整天的时间，具体取决于新构建的规模。 这是一种更专业的验收测试，在进展或重新测试后进行。 它检查某些新功能和/或错误修复的核心功能以及与它们密切相关的一些功能，以便在大规模执行回归测试之前验证它们是否按照所需的操作逻辑运行。
Smoke and sanity testing are both performed after a software build to identify whether to start testing. Sanity may or may not be executed after smoke testing. They can be executed separately or at the same time - sanity being immediately after smoke.
Because sanity testing is more in-depth and takes more time, in most cases it is well worth to be automated.
Smoke testing usually takes no longer than 5-30 minutes for execution. It is more general: it checks a small number of core functionalities of the whole system, in order to verify that the stability of the software is good enough for further testing and that there are no issues, blocking the run of the planned test cases.
Sanity testing is more detailed than smoke and may take from 15 minutes up to a whole day, depending on the scale of the new build. It is a more specialized type of acceptance testing, performed after progression or re-testing. It checks the core features of certain new functionalities and/or bug fixes together with some closely related to them features, in order to verify that they are functioning as to the required operational logic, before regression testing can be executed at a larger scale.
单元测试：它总是由开发人员在开发完成后执行，以便在为 QA 准备任何要求之前从测试方面找出问题。
集成测试：这意味着当某些数据/功能输出驱动到一个模块到另一模块时，测试人员必须验证模块到子模块的验证。 或者在您的系统中，如果使用使用您的系统数据进行集成的第三方工具。
冒烟测试：测试人员执行以验证系统进行高级测试，并尝试在更改或代码上线之前找出显示停止的错误。
回归测试：测试人员执行回归以验证由于系统中新增强或系统更改而实施的更改而导致的现有功能。
Unit Testing: It always performs by developer after their development done to find out issue from their testing side before they make any requirement ready for QA.
Integration Testing: It means tester have to verify module to sub module verification when some data/function output are drive to one module to other module. Or in your system if using third party tool which using your system data for integrate.
Smoke Testing: tester performed to verify system for high-level testing and trying to find out show stopper bug before changes or code goes live.
Regression Testing: Tester performed regression for verification of existing functionality due to changes implemented in system for newly enhancement or changes in system.
回归测试 - 是一种软件测试，我们尝试覆盖或检查错误修复。 错误修复相关的功能不应因提供的修复而发生更改或变更。 在这个过程中发现的问题被称为回归问题。
冒烟测试：是一种测试，用于决定是否接受构建/软件以进行进一步的 QA 测试。
Regression test - Is a type of software testing where we try to cover or check around the bug fix. The functionality around the bug fix should not get changed or altered due to the fix provided. Issues found in such process are called as regression issues.
Smoke Testing: Is a kind of testing done to decide whether to accept the build/software for further QA testing.
已经有一些很好的答案，但我想进一步完善它们：
单元测试是这里白盒测试的唯一形式。 其他都是黑盒测试。 白盒测试意味着您知道输入； 你知道该机制的内部工作原理，可以检查它，并且知道输出。 通过黑盒测试，您只知道输入是什么以及输出应该是什么。
显然，单元测试是这里唯一的白盒测试。
There are some good answers already, but I would like further refine them:
Unit testing is the only form of white box testing here. The others are black box testing. White box testing means that you know the input; you know the inner workings of the mechanism and can inspect it and you know the output. With black box testing you only know what the input is and what the output should be.
So clearly unit testing is the only white box testing here.
冒烟测试已经在这里解释过并且很简单。 回归测试属于集成测试。
自动化测试可以分为两种。
单元测试和集成测试（这才是最重要的）
我会为所有测试（如集成测试、功能测试、回归测试、UI 测试等）使用短语“长测试”（LT）。并将单元测试称为“简短测试”。
LT 示例可以是自动加载网页、登录帐户并购买书籍。 如果测试通过，则更有可能以相同的方式在实时站点上运行（因此有“更好的睡眠”参考）。 Long = 网页（开始）和数据库（结束）之间的距离。
这是一篇很棒的文章，讨论了 集成测试（长测试）优于单元测试。
Smoke tests have been explained here already and is simple. Regression tests come under integration tests.
Automated tests can be divided into just two.
Unit tests and integration tests (this is all that matters)
I would call use the phrase "long test" (LT) for all tests like integration tests, functional tests, regression tests, UI tests, etc. And unit tests as "short test".
An LT example could be, automatically loading a web page, logging in to the account and buying a book. If the test passes it is more likely to run on live site the same way(hence the 'better sleep' reference). Long = distance between web page (start) and database (end).
And this is a great article discussing the benefits of integration testing (long test) over unit testing.
单元测试：指定并测试类的单个方法的契约的一点。 这应该有一个非常狭窄且明确定义的范围。 与外界的复杂依赖关系和交互是存根或模拟。
集成测试：测试多个子系统的正确互操作。 那里有完整的范围，从测试两个类之间的集成，到测试与生产环境的集成。
冒烟测试（又名 理智 检查）：一个简单的集成测试，我们只检查当被测系统被调用，它正常返回并且不会崩溃。
回归测试：修复错误时编写的测试。 它确保这个特定的错误不会再次发生。 全称是“非回归测试”。 它也可以是在更改应用程序之前进行的测试，以确保应用程序提供相同的结果。
为此，我将添加：
验收测试：测试功能或用例是否已正确实现。 它类似于集成测试，但重点关注要提供的用例，而不是涉及的组件。
系统测试：将系统作为黑匣子进行测试。 在测试过程中经常会模拟或存根对其他系统的依赖关系（否则它更像是集成测试）。
飞行前检查：在类似生产的环境中重复进行测试，以缓解“在我的机器上构建”综合症。 通常，这是通过在类似生产的环境中进行验收或冒烟测试来实现的。
Unit test: Specify and test one point of the contract of single method of a class. This should have a very narrow and well defined scope. Complex dependencies and interactions to the outside world are stubbed or mocked.
Integration test: Test the correct inter-operation of multiple subsystems. There is whole spectrum there, from testing integration between two classes, to testing integration with the production environment.
Smoke test (aka sanity check): A simple integration test where we just check that when the system under test is invoked it returns normally and does not blow up.
Regression test: A test that was written when a bug was fixed. It ensures that this specific bug will not occur again. The full name is "non-regression test". It can also be a test made prior to changing an application to make sure the application provides the same outcome.
To this, I will add:
Acceptance test: Test that a feature or use case is correctly implemented. It is similar to an integration test, but with a focus on the use case to provide rather than on the components involved.
System test: Tests a system as a black box. Dependencies on other systems are often mocked or stubbed during the test (otherwise it would be more of an integration test).
Pre-flight check: Tests that are repeated in a production-like environment, to alleviate the 'builds on my machine' syndrome. Often this is realized by doing an acceptance or smoke test in a production like environment.
每个人的定义都会略有不同，并且常常存在灰色地带。 但是：
Everyone will have slightly different definitions, and there are often grey areas. However:
我刚刚意识到的一个新测试类别是金丝雀测试。 金丝雀测试是一种自动化的、非破坏性的测试，它在实时环境中定期运行，这样，如果它失败，则表明发生了非常糟糕的事情。
示例可能是：
A new test category I've just become aware of is the canary test. A canary test is an automated, non-destructive test that is run on a regular basis in a live environment, such that if it ever fails, something really bad has happened.
Examples might be:
软件测试技术最佳网站之一的回答：
软件测试类型 - 完整列表点击此处
Answer from one of the best websites for software testing techniques:
Types of software testing – complete list click here
单元测试：对应用程序中的单个模块或独立组件进行测试称为单元测试。 单元测试将由开发人员完成。
集成测试：将所有模块组合起来并对应用程序进行测试，以验证模块之间的通信和数据流是否正常工作。 此测试也是由开发人员执行的。
冒烟测试 在冒烟测试中，他们以浅而广泛的方式检查应用程序。 在冒烟测试中，他们检查应用程序的主要功能。 如果应用程序中存在任何阻塞问题，他们将向开发团队报告，开发团队将修复它并纠正缺陷，并将其返回给测试团队。 现在测试团队将检查所有模块，以验证一个模块中所做的更改是否会影响其他模块。 在冒烟测试中，测试用例是编写脚本的。
回归测试重复执行相同的测试用例，以确保未更改的模块不会导致任何缺陷。 回归测试属于功能测试
Unit test: testing of an individual module or independent component in an application is known to be unit testing. The unit testing will be done by the developer.
Integration test: combining all the modules and testing the application to verify the communication and the data flow between the modules are working properly or not. This testing also performed by developers.
Smoke test In a smoke test they check the application in a shallow and wide manner. In smoke testing they check the main functionality of the application. If there is any blocker issue in the application they will report to developer team, and the developing team will fix it and rectify the defect, and give it back to the testing team. Now testing team will check all the modules to verify that changes made in one module will impact the other module or not. In smoke testing the test cases are scripted.
Regression testing executing the same test cases repeatedly to ensure tat the unchanged module does not cause any defect. Regression testting comes under functional testing