大家好！ 下周，我们将在
“自动化Web测试”课程中启动一个新线程。 这将是今天材料的主题。
本文讨论了各种测试软件的方法，例如单元测试，集成测试，功能测试，验收测试等。
您可以应用多种不同类型的测试来确保对代码所做的更改已编写脚本。 并非所有类型的测试都是相同的，尽管在这里我们看一下主要测试实践之间的差异。
测试：手动还是自动？首先，您需要了解手动测试和自动测试之间的区别。 手动测试直接由单击应用程序中的按钮或使用必要工具与软件或API交互的人员执行。 这是相当昂贵的，因为它要求测试人员安装开发环境并手动运行测试。 由于人为因素（例如输入错误或测试用例中的跳过步骤）而可能导致错误。
另一方面，自动测试是由运行预先编写的测试脚本的计算机执行的。 此类测试可能会因复杂性而有很大差异，从测试类中的单个方法到在UI中制定一系列复杂的操作以确保其正常工作。 该方法被认为更可靠，但是其性能仍然取决于测试脚本的编写质量。
自动化测试是
持续集成和持续交付的关键组成部分，也是扩展质量检查流程同时向应用程序添加新功能的好方法。 但是，手动测试仍有其自身的价值。 因此，在本文中，我们一定会讨论探索性测试。
不同类型的测试单元测试单元测试被认为是低级的，接近于应用程序的源代码。 它们旨在测试类中的各个方法和功能，测试程序所使用的组件和模块。 通常，单元测试不需要特殊的自动化成本，并且如果使用连续集成服务器，则可以非常快速地进行工作。
整合测试集成测试检查您的应用程序使用的服务和模块是否一起正常工作。 例如，他们可以测试与数据库的集成，或者确保微服务彼此正确交互。 这些测试需要更高的成本，因为它们需要应用程序的许多部分才能同时工作。
功能测试功能测试基于应用程序的业务需求。 它们仅在执行动作后检查输出，而在动作再现期间不检查系统的中间状态。
有时集成测试和功能测试之间存在矛盾，例如 它们都要求相互交互的多个组件。 区别在于，集成测试只能确保数据库可访问，而功能测试则希望从数据库中获得一定的价值，以检查最终产品的需求之一。
端到端测试端到端测试在与软件交互时模拟用户行为。 它检查各种用户遵循应用程序预期方案的准确性如何，并且可能非常简单，例如，看起来像是加载网页或进入网站，或者在更复杂的情况下，是确认电子邮件地址，在线付款等。
端到端测试非常有用，但是生产它们很昂贵，并且可能很难实现自动化。 建议使用几种跨领域测试，但仍然更多地依赖于低级测试（单元测试和集成测试），以便能够快速识别重大更改。
验收测试验收测试是进行正式测试，以确保系统满足业务需求。 它们要求应用程序可以运行，并且可以模拟用户操作。 如果尚未达到最终的开发目标，则验收测试可以走得更远并衡量系统性能，并拒绝最近的更改。
性能测试性能测试用于测试系统在负载较大时的行为。 这些测试是无功能的，可以采取多种形式来测试平台的可靠性，稳定性和可用性。 例如，它可以在执行大量请求时监视响应时间，或者观察与大数据进行交互时系统的行为。
性能测试本来就很昂贵，但是它们可以帮助您了解哪些外部因素会导致系统性能下降。
烟雾测试冒烟测试是测试应用程序基本功能的基本测试。 他们的工作速度足够快，目标是明确表明系统的主要功能可以正常工作，仅此而已。 此类测试旨在识别明显的错误。
生成新版本后立即进行冒烟测试很有用，以检查您是否可以运行更昂贵的测试，或者在部署后立即进行冒烟测试，以确保应用程序在新环境中可以正常运行。
如何自动化测试测试人员可以手动执行上面提到的所有测试，但这将非常昂贵且无济于事。 因为人们在执行可靠的测试的同时执行大量重复操作的能力有限。 但是，本机可以轻松地重现相同的操作并检查，例如，用户名/密码组合可以百分百工作，而不会产生任何投诉。
要使测试自动化，您首先必须使用适合您的应用程序的测试框架以某些编程语言编写它们。
PHPUnit ，
Mocha和
RSpec是分别可用于PHP，Javascript和Ruby的测试框架的示例。 它们对于每种语言都有许多
功能 ，因此您应该自己进行一些研究，并咨询开发人员社区以找出最适合您的框架。
如果可以使用终端中的脚本运行测试，则可以使用Bamboo风格的持续集成服务器或Bitbucket Pipelines云服务器将其自动化。 一旦将新更改推送到主存储库中，这些工具将监视您的存储库并运行测试套件。
如果您不熟悉测试，请查看我们的持续
集成指南以创建您的第一个测试套件。
研究测试向代码中添加的功能和改进越多，测试需求就越多，因为在每个阶段都需要确保系统正确运行。 另外，每次修复错误时都将需要它，因为确保它在多个发行版本后不会再次出现并不是多余的。 自动化是使之成为可能的关键。 迟早编写测试将成为开发人员实践的一部分。
问题是，在这种情况下是否有必要进行手动测试？ 简短的答案是肯定的，应该集中在所谓的探索性测试上，这有助于识别细微的错误。
研究测试课程不应超过两个小时，并且应该有明确定义的范围，以帮助测试人员专注于软件的特定区域。 在将所有测试限制告知所有测试人员之后，他们将自行决定检查系统性能的动作。 这种测试本质上是昂贵的，但是对于识别用户界面问题或为用户验证复杂工作流的运行状况非常有用。 重要的是，每当向应用程序中添加了一个全新的功能时，都必须进行此类测试，以了解其在临界条件下的行为。
测试注意事项在完成本文之前，我想谈谈测试的目的。 一方面，确保用户可以使用您的应用程序（“我无法登录”，“我无法保存数据”等）非常重要，但另一方面，验证您的系统也同样重要输入不正确的数据或意外操作时不会中断。 您需要预期当用户输入错误，尝试保存不完整的表格或使用错误的API时会发生什么。 您需要检查其中一个用户是否可以轻松地破坏数据，访问他不应该访问的特定资源。 一组很好的测试应尝试破坏您的应用程序，并帮助您了解其功能的局限性。
最后，测试也是代码！ 因此，在代码审查期间不要忘记它们，因为它们可能是将产品发布到消费者市场之前的最后一步。
根据既定的惯例，我们正在等待您的评论，并邀请所有人参加
开放日 ，该日将由我们的老师，Group-IB的首席测试自动化工程师
Mikhail Samoilov于3月18日举行。