自动化测试还称为冒烟测试吗？
如果没有，是否仍使用冒烟测试？
If not, is smoke testing still used?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
如果没有，是否仍使用冒烟测试？
If not, is smoke testing still used?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（8）
这有点像维恩图。 一些自动化测试是冒烟测试，而一些冒烟测试是自动化的（只要它们由计算机程序运行）。 烟雾测试是对“哪里有烟，哪里通常就有火”这个术语的起飞（如果我没记错的话）。 这是程序必须通过的一组初步测试，才能考虑进行“真正”（即火灾）测试。
冒烟测试可以是手动的，因为测试人员有一个他遵循的步骤列表，但这些步骤不是通过计算机程序自动化的。
冒烟测试仍在使用——在我工作过的地方，它通常是自动化的。
It's sort of a Venn Diagram. Some Automated tests are Smoke tests, and some smoke tests are Automated (inasfar as they are ran by a computer program). A Smoke test is a take off (if I recall correctly) on the term "Where there's smoke, there's usually fire." It's a set of preliminary tests that the program must pass to be considered for 'real' (viz. fire) testing.
A smoke test can be manual insomuch as a tester has a list of steps he follows, but these aren't automated with a computer program.
Smoke testing is still used -- in places I've worked, it's usually automated.
自动化测试可以进行冒烟测试（浅、宽），但它也可以进行其他测试，例如回归测试 和单元测试。 基本上自动化测试可以是任何可重复的测试。
是的，冒烟测试仍在使用。 我通常见过两种情况。 首先是确定软件是否准备好进行更深入的测试。 第二种，在我看来更常见，是忽略对不应受到新版本更改影响的功能的全面测试。
Automated testing can do smoke testing (shallow, wide), but it can also do other testing like regression testing, and unit testing. Basically automated testing can be any repeatable test.
Yes, smoke testing is still being used. I've generally seen two scenarios. The first is to determine whether the software is ready for more in depth testing. The second, and IMO more common, to skimp on fully testing functionality that should not have been affected by the changes to the new build.
我认为冒烟测试通常不是自动化的。 根据我的经验，冒烟测试实际上只是一个基本的健全性测试，以确保后续测试实际上可以运行，并且没有像启动代码或菜单条目这样的基本内容被破坏。 这通常由人手动完成。 我想它可以是自动化的，但通常它涉及添加新功能，因此自动化测试也必须进行更改，并且您仍然会遇到同样的问题，您需要一个人来验证自动化测试是否正确修改以正确测试新功能。 相比之下，自动化测试（如单元测试）代表回归测试套件，旨在测试成熟的功能，这些功能在不同版本之间不应有太大变化，尽管您当然也可以添加单元测试来涵盖新功能。
I don't think smoke tests are usually automated. The smoke test in my experience is really just a basic sanity test to make sure that subsequent tests can actually be run, and that nothing basic got broken like startup code or menu entries. This would usualy be done manually by a person. I suppose it could be automated, but usually it involves the addition of new features so the automated tests would have to be changed as well and you'd still have the same problem that you'd need a person to verify that the automated tests were modified to test the new feature properly. In contrast, automated tests (like unit tests) represent a regression test suite and are created to test well-established functionality that should not change much from release to release, although of course you would add unit tests to cover new functionality as well.
可能更多是在具有硬件背景的公司中，烟雾测试是按字面意思进行的。 现在很少有人这么称呼他们了。 它通常只是更大的验收或系统测试套件的一个小而广泛的子集。 这些 tet 是自动化的，并且在提交代码之前或提交到源代码控制时自动针对代码运行。
Probably more in companies from a hardware background where the smoke test was taken literally. Few people call them that anymore. It's usually just a small yet broad subset of a larger acceptance or system test suite. These tets are automated and are automatically run against code before it is submitted or on submission to source code control.
我不确定我们可以比较烟雾测试和自动化测试。 冒烟测试是一种在构建上运行一组基本测试的方法，涵盖所有基本功能，但不深入任何功能。 目的是确定构建是否可以用于更详细的测试。 这也是一组即使在开发人员构建上也可以快速运行的步骤，以确定是否由于构建中即将进行的某些重大或核心更改而出现任何问题。 我们认为冒烟测试是我们的“测试计划”之一，但会在每个版本上运行。
自动化测试并不特定于冒烟测试，但也可以应用于那里。 这样做是为了“自动化”测试人员为了节省时间而经常执行的冗余或重复步骤。 这是自动化的主要目的。 它允许测试人员花更多的时间来做其他测试。
它永远无法取代真实大脑的测试，也无法实现一切自动化。 这是一项补充现有测试流程的活动，而不是取代它。
由于冒烟测试可能在每个构建上运行，因此自动化它具有很大的价值。 如果手动运行冒烟测试需要 4 小时，而自动化后需要 1 小时，那么您就节省了 3 工时 * 构建次数的工作量。
市场上有多种用于自动化测试的工具 - AutoIT 和 SilkTest 等。
I am not sure we can compare Smoke and Automated testing. Smoke testing is a way to run a set of basic tests on a build, covering all the basic features but not going in depth on any. The purpose is to determine whether a build can be used for more detailed testing or not. It is also a set of steps that can be run quickly even on a developer build to determine if there are any issues due to some significant or core changes that are about to go in a build. We consider Smoke test to be one of our 'test plans' but one that is run on every build.
Automated testing is not specific to Smoke tests but can be applied there as well. It is done to 'automate' redundant or repetitive steps that a tester always does to save time. That is the primary purpose of automation. It is allowes a tester to spend more time to do other tests.
It can never be replacement of testing by a real brain nor everything can be automated. It is an activity that supplements the testing process in place, not replace it.
Since Smoke test is potentially run on every build, there is a good value in automating it. If a smoke test run manually takes 4 hours, and after automation it takes 1 hour, you have saved an effort of 3 man-hours * number of builds.
There are several tools in market for automation testing - AutoIT and SilkTest to name a few.
简而言之，我们可以说冒烟测试可以自动化，但自动化测试并不总是冒烟测试。
是的，冒烟测试是测试任何应用程序/软件的一种流行方法。
In very simple words we can say that Smoke testing can be automated but it is not like automated testing is always smoke testing.
Yes, smoke testing is a popular way of testing any application/software.
我对“冒烟测试”的理解与维基百科文章不同。 我将冒烟测试理解为开发人员打开应用程序并测试基本功能以验证应用程序看起来正确和正确。 正在做基础工作。 所以我一直认为这是一个手动过程，而不是自动化过程。
My understanding of "smoke testing" is different than the wikipedia article. I understand smoke testing to be the developer opening the app and testing the basic functionality to verify that the app looks right & is doing the basics. So I always thought it was a manual process, not an automated one.
测试自动化套件包含各种级别，如冒烟测试、验收测试、夜间构建等。 由测试人员决定每个级别需要运行哪个测试用例。 每个测试用例都根据它们应该运行的级别进行编号。 假设有 2 个自动化测试用例，分别用 1 和 2 编号来表示级别，并且您在配置文件中将测试级别定义为 2，那么它只会运行第二个测试用例并给出结果。 与验收测试相比，冒烟测试的测试用例数量通常较少。
冒烟测试可以自动化，但并非所有自动化测试都是冒烟测试。
Test automation suite contains various levels like smoke test, acceptance test, nightly build, so on. Its up to the tester to decide which test case needs to be run in each level. Each test case is numbered depending upon the levels at which they should be run. Say if there are 2 test cases automated, numbered with 1 and 2 respectively to indicate the levels, and you define test level as 2 in configuration file, its gonna run only the second test case and gives you the result. Smoke test generally has less number of test cases compared to acceptance test.
Smoke test can be automated but not all automated tests are smoke tests.