unit test ：已知应用程序中单个模块或独立组件的测试是单元测试，单元测试将由开发人员完成 .
integration test ：组合所有模块并测试应用程序以验证通信和模块之间的数据流是否正常工作，此测试也由开发人员执行 .
smoke test 在烟雾测试中，他们以浅薄和广泛的方式检查应用程序，在冒烟测试中他们检查应用程序的主要功能，如果应用程序中有任何阻止程序问题，他们将向开发团队报告，开发团队将修复它并纠正缺陷，并将其交还给测试团队，现在测试团队将检查所有模块，以验证在一个模块中进行的更改是否会影响其他模块 . 在SMOKE测试中，测试用例是脚本化的
20 回答
Unit test ：自动测试以测试类的内部工作方式 . 它应该是一个独立的测试，与其他资源无关 .
Integration test ：在环境中完成的自动测试，类似于单元测试，但具有外部资源（db，磁盘访问）
Regression test ：在实施新功能或错误修复后，您将重新测试过去有效的方案 . 在这里，您将了解新功能是否会破坏现有功能的可能性 .
Smoke testing ：首先测试哪些测试人员可以继续测试 .
集成测试：集成测试是集成另一个元素
烟雾测试：烟雾测试也称为构建版本测试 . 烟雾测试是初步测试过程，用于检查被测软件是否已准备好/稳定以进行进一步测试 .
回归测试：回归测试是重新测试 . 新软件是否在另一个模块中实现 .
单元测试：这是一个白盒测试 . 只有开发人员参与其中
已有一些好的答案，但我想进一步完善它们：
单元测试是此处唯一的白盒测试形式 . 其他是黑盒测试 . 白盒测试意味着您知道输入，您知道机制的内部工作方式并且可以检查它并且您知道输出 . 使用黑盒测试，您只知道输入是什么以及输出应该是什么 .
所以很明显，单元测试是这里唯一的白盒测试 .
单元测试测试特定的代码片段 . 通常的方法 .
集成测试测试您的新功能软件是否可以与其他所有功能集成 .
回归测试 . 这是测试，以确保您没有破坏任何东西 . 过去工作的一切仍然有用 .
进行烟雾测试作为快速测试，以确保在您参与更有力的测试之前一切正常 .
这里已经解释了烟雾测试并且很简单 . 回归测试在集成测试下进行 .
自动化测试可分为2个 .
Unit test and Integration Test. （这一切都很重要）
我会打电话给所有测试使用短期“长测试”（LT），如集成测试，功能测试，回归测试，UI测试等 . 单元测试为“短测试” .
LT示例可以是，自动加载网页，登录帐户和购买书籍 . 如果测试通过，则更有可能以相同的方式在实时站点上运行（因此“更好的睡眠”参考） . 长=网页（开始）和数据库（结束）之间的距离 .
这是一篇很好的文章讨论integration testing(long test) over unit testing的好处
我刚刚意识到的一个新的测试类别是：
金丝雀测试
Canary test 是一个自动的，非破坏性的测试，在 LIVE 环境中是 run on a regular basis ，如果它失败了，就会发生一些非常糟糕的事情 .
例子可能是：
只有在DEV / TEST中可用的数据才会出现在LIVE中 .
后台进程无法运行
用户可以登录吗？
Unit test ：指定并测试一个类的单个方法的 Contract 的一个点 . 这应该有一个非常狭窄和明确的范围 . 复杂的依赖关系和与外界的互动是stubbed or mocked .
Integration test ：测试多个子系统的正确互操作 . 那里有完整的范围，从测试两个类之间的集成，到测试与 生产环境 环境的集成 .
Smoke test (aka Sanity check) ：一个简单的集成测试，我们只检查当被调用的系统被调用时，它会正常返回并且不会爆炸 .
烟雾测试与电子产品类似，第一次测试发生在为电路供电时（如果它抽烟，那就太糟糕了！）......
...和apparently，带有plumbing，其中管道系统实际上由烟雾填充，然后在视觉上进行检查 . 如果有什么东西抽烟，系统就会漏水 .
Regression test ：修复错误时编写的测试 . 它确保不会再次发生此特定错误 . 全名是"non-regression test" . 它也可以是在更改应用程序之前进行的测试，以确保应用程序提供相同的结果 .
对此，我将补充：
Acceptance test ：测试是否正确实现了功能或用例 . 它类似于集成测试，但重点关注用例而不是涉及的组件 .
System test ：将系统测试为黑匣子 . 在测试期间，通常会对其他系统的依赖性进行模拟或存根（否则它将更多的是集成测试） .
Pre-flight check ：在 生产环境 环境中重复的测试，以减轻'builds on my machine'综合症 . 通常，这是通过在类似环境的 生产环境 中进行验收或烟雾测试来实现的 .
回归测试 -
“回归测试重新运行以前针对已更改软件的测试，以确保当前软件中所做的更改不会影响现有软件的功能 . ”
unit test ：已知应用程序中单个模块或独立组件的测试是单元测试，单元测试将由开发人员完成 .
integration test ：组合所有模块并测试应用程序以验证通信和模块之间的数据流是否正常工作，此测试也由开发人员执行 .
smoke test 在烟雾测试中，他们以浅薄和广泛的方式检查应用程序，在冒烟测试中他们检查应用程序的主要功能，如果应用程序中有任何阻止程序问题，他们将向开发团队报告，开发团队将修复它并纠正缺陷，并将其交还给测试团队，现在测试团队将检查所有模块，以验证在一个模块中进行的更改是否会影响其他模块 . 在SMOKE测试中，测试用例是脚本化的
regression testing 重复执行相同的测试用例，以确保未更改的模块不会导致任何缺陷 . 回归测试属于功能测试
在这个帖子中似乎值得一提的一种测试是压力/性能/负载测试，可以简单地找出某个软件断开的限制 . 请注意，就工具而言，必须从系统角度精确确定建议进行压力测试的范围 . 例如，在"web application"压力测试的情况下，测试可以在其范围内包括Web服务器应用程序本身，因此工具可以在此方面进行干预 . 这是关于http load testing的好文章
回归测试 - 是一种软件测试，我们试图覆盖或检查错误修复 . 由于提供了修复，因此不应更改或更改错误修复的功能 . 在此过程中发现的问题称为回归问题 .
烟雾测试：是否进行了一种测试以决定是否接受构建/软件以进行进一步的QA测试 .
每个人的定义都会略有不同，通常都有灰色区域 . 然而：
单元测试：这一点（尽可能隔离）工作吗？
集成测试：这两个（或更多）组件一起工作吗？
烟雾测试：这整个系统（尽可能接近 生产环境 系统）是否能够很好地挂在一起？ （即我们有理由相信它不会造成黑洞吗？）
回归测试：我们是否无意中重新引入了我们之前修复过的任何错误？
单元测试：验证特定组件（即类）是否按设计创建或修改了功能 . 此测试可以是手动或自动的，但不会超出组件的边界 .
集成测试：验证特定组件的交互是否按设计运行 . 可以在单元级别或系统级别执行集成测试 . 这些测试可以是手动或自动的 .
回归测试：验证新缺陷未引入现有代码 . 这些测试可以是手动或自动的 .
根据您的SDLC（瀑布，rup，敏捷等），可以在“阶段”中执行特定测试，或者可以同时或多或少地执行所有测试 . 例如，单元测试可能仅限于开发人员，然后他们将代码转交给测试人员进行集成和回归测试 . 然而，另一种方法可能是开发人员进行单元测试和某种程度的集成和回归测试（使用TDD方法以及持续集成和自动化单元和回归测试） .
伪造的历史琐事：“烟雾测试”来自潜艇工程（继承自管道），在那里将字面的烟雾泵入船体，看它是否有任何一次出现，这对于潜艇而言将是一次戏剧性的失败！
单元测试：验证特定组件（即类）是否按设计创建或修改了功能 . 此测试可以是手动或自动的，但不会超出组件的边界 .
集成测试：验证特定组件的交互是否按设计运行 . 可以在单元级别或系统级别执行集成测试 . 这些测试可以是手动或自动的 .
回归测试：验证新缺陷未引入现有代码 . 这些测试可以是手动或自动的 .
根据您的SDLC（瀑布，rup，敏捷等），可以在“阶段”中执行特定测试，或者可以在或多或少地执行所有测试 . 同时 . 例如，单元测试可能仅限于开发人员，然后他们将代码转交给测试人员进行集成和回归测试 . 然而，另一种方法可能是开发人员进行单元测试和某种程度的集成和回归测试（使用TDD方法以及持续集成和自动化单元和回归测试） .
工具集在很大程度上取决于代码库，但有许多用于单元测试的开源工具（JUnit） . HP的（汞）QTP或Borland的Silktest都是自动集成和回归测试的工具 .
单元测试： - 单元测试通常由开发人员方完成，其中测试人员在这种类型的测试中部分演变，其中测试是逐个单元完成的 . 在java Junit测试用例中也可以测试编写的代码是否完美设计 .
集成测试： - 在单元测试之后，当集成所有/某些组件时，可以进行这种类型的测试 . 这种类型的测试将确保在组件集成时，它们是否会影响彼此的工作能力或功能 .
烟雾测试： - 当系统成功集成并准备进入 生产环境 服务器时，此类测试最后完成 . 这种类型的测试将确保从头到尾的每个重要功能都能正常工作，并且系统已准备好在 生产环境 服务器上部署 .
回归测试： - 当开发人员修复某些问题时，此类测试对于测试系统中不存在意外/不需要的缺陷非常重要 . 此测试还确保成功解决所有错误，因此没有发生其他问题 .
Unit testing:
单元测试是一种软件开发过程，其中应用程序的最小可测试部件（称为单元）被单独和独立地仔细检查以便正确操作 . 单元测试通常是自动化的，但也可以手动完成 .
Integration testing:
（有时称为集成和测试，缩写为I＆T）是软件测试阶段，其中各个软件模块组合并作为一组进行测试 . 它发生在单元测试之后和验证测试之前 .
System testing:
通常是最终测试，以验证要交付的系统是否符合规范及其目的 .
Regression test:
在实现新功能或错误修复之后，您将重新测试过去有效的方案 . 在这里，您将了解新功能是否会破坏现有功能的可能性 .
Smoke Testing:
目标不是进行详尽的测试，而是要验证系统的关键功能是否正常工作 . 例如，典型的冒烟测试是 - 验证应用程序是否成功启动，检查GUI是否响应，等等 .
Unit testing 针对可能的实现的最小部分 . 在java中，这意味着您正在测试单个类 . 如果该类依赖于其他类，则这些类是伪造的 .
当你的测试调用多个类时，它是一个 integration test .
完整的测试套件可能需要很长时间才能运行，因此在更改之后，许多团队会快速完成一些测试以检测严重的破损 . 例如，您已将URI分解为必要资源 . 这些是 smoke tests .
Regression tests 在每个构建上运行，并允许您通过捕获您所破坏的内容来有效地重构 . 任何类型的测试都可以进行回归测试，但我发现单元测试最有助于找到故障源 .
在构建软件之后执行烟雾和健全性测试以确定是否开始测试 . 在进行烟雾测试后，可能会或可能不会执行理智 . 它们可以单独执行或同时执行 - 在冒烟后立即执行 .
Because sanity testing is more in-depth and takes more time, in most cases it is well worthed to be automated.
烟雾测试通常不会超过5-30分钟执行 . 它更为通用：它检查整个系统的少量核心功能，以验证软件的稳定性是否足以进行进一步测试，并且没有问题，阻止了计划测试用例的运行 .
Health 测试比烟雾更详细，可能需要15分钟到一整天，具体取决于新建筑的规模 . 它是一种更专业的验收测试类型，在进展或重新测试后执行 . 它可以检查某些新功能和/或错误修复的核心功能以及与它们密切相关的功能，以便在回归测试可以更大规模执行之前验证它们是否符合所需的操作逻辑 .
Answer from one of the best Websites for Software Testing Techniques:
Types of Software Testing – Complete List Click Here
Hope it'll be helpful :)
单元测试：开发人员在开发完成后始终执行它，以便在他们为QA做出任何准备之前从他们的测试方面找出问题 .
集成测试：它意味着测试人员当一些数据/功能输出驱动到一个模块到另一个模块时，必须验证模块到子模块的验证 . 或者在您的系统中使用第三方工具，使用您的系统数据进行集成 .
烟雾测试：执行测试程序以验证系统的高级测试，并尝试在更改或代码生效之前找出显示阻塞错误 .
回归测试：由于系统中为新增强或系统更改而实施的更改，测试程序执行回归以验证现有功能 .