前言

冒烟测试和可用性测试都有自己的目标和执行的优先顺序。这两种类型的测试对于项目的成功起着关键的作用。对于新人来说，这两种类型通常会弄混淆。希望在本文结束时，可以对理智和烟雾测试有一个清晰的概念。

什么是冒烟测试

冒烟测试是为了确保我们从开发团队收到的软件功能是否可测试。也称为“第0天”测试（先导测试），这是在“构建软件功能级别”完成的。

如果对应的关键功能不起作用或关键错误尚未修复时，在不浪费测试时间的前提现，来简单地测试整个应用程序是有帮助的。在这里，我们关注的重点是主要和核心软件工作流程。

如何进行冒烟测试？

为了进行冒烟测试，我们不必编写特定的测试用例。我们只是从已经编写好的测试用例中，选择必要的测试用例即可。

我们真的为所有测试类型编写测试用例吗？在本文中，我们对选择测试类型来编写测试用例给出了明确的想法。

如前所述，在冒烟测试中，我们主要关注的是核心应用程序的工作流程。因此，我们从我们的测试集合中选择测试用例，它涵盖了应用程序的主要功能。一般来说，我们选择的测试用例数量最少，执行时间不会超过半小时。

假设您正在为一个电子商务网站工作。当发布一个新的构建进行测试时，作为一个测试人员，您必须确保核心功能是否正常工作。因此，您尝试访问电子商务网站，并添加一个项目到您的购物车下订单。这是大多数电子商务网站的主要流程。如果此流有效，则可以说此生成已通过。您可以继续在同一个构建上进行功能测试。

冒烟测试需要自动化吗？

是的，我们需要它。它节省了很多测试时间假设你有50-100个冒烟测试用例。为了执行这些50-100个测试用例，大约需要4-6个小时的时间。如果您有这些测试用例的自动化脚本，那么您可以在发布构建后执行它们，并在手动执行冒烟测试测试用例所花费的时间内确认是否通过了冒烟测试。因此，大多数团队都自动化了冒烟测试用例。

什么是可用性测试

可用性测试在发布阶段进行，以检查应用程序的主要功能，而不必深入。它也被称为回归测试的子集。这是在“发布级别”完成的。

有时由于发布时间限制，无法对构建进行严格的回归测试，而可用性测试则通过检查主要功能来完成这一部分。

大多数时候，我们没有足够的时间来完成整个测试。特别是在敏捷方法论中，我们会受到产品负责人的压力，要求在几小时内或一天结束时完成测试。在这种情况下，我们选择可用性测试。在这种情况下，可用性测试起着关键作用。

如何进行可用性测试？

和冒烟测试一样，我们不为可用性测试编写单独的测试用例。我们只是从已经编写好的测试用例中选择必要的测试用例。

它是回归测试的一个子集。当涉及到可用性测试的时候，主要考虑的是功能能否按照需求文档的要求工作。

假设你在一个电子商务网站工作。发布了一个与搜索功能相关的新功能。在这里，你的主要精力应该放在搜索功能上。一旦你确定搜索功能运行良好，然后你转移到其他主要功能，如支付流。

可用性测试需要自动化吗？

是的，我们也需要它。它节省了很多测试时间假设你有50-100个可用性测试用例。那么您可以在收到稳定构建后执行它们，而不是人为去手动执行这些可用性测试，而是把精力放在其他的测试上去。

冒烟测试VS可用性测试

在一个项目的开发发布过程中，开发团队构建软件给测试人员测试，测试拿到构建完成的软件后，首先检查产品的基本状况和功能，我们称之为冒烟测试。如果测试人员，在冒烟测试后觉得产品可以延展更多的测试，例如登录页面包含管理员，员工和一般用户。测试人员针对主要的功能进行测试而不延展更多的测试，我们称之为可用性测试。

总结

冒烟测试和可用性测试都是回归测试的子集，具体的目标不尽相同，冒烟测试为了确保构建的稳定，可用，可用性测试则是保证目标功能可以正常使用。希望上面的内容可以帮助理清冒烟测试和可用性测试的区别。如果有关于冒烟测试和可用性测试的相关话题，也请大家评论区留言。