Руководство по автоматизированному тестированию

Во многих организациях качество является главным приоритетом. Если вы окажетесь в такой организации, но в ней все еще не будет формального процесса автоматизации тестирования, вы можете стать тем человеком, который его внедрит.

С ним ваша организация сможет создавать более качественные продукты за меньшее время и соответственно раньше будет выводить их на рынок.

В третьей части «Руководства по автоматизации тестирования», я расскажу вам о том, что такое процесс автоматизации тестирования и как начать автоматизацию тестирования в вашей организации. Важно понимать, какой шаг нужно сделать первым и почему.

Выполнение этих шагов поможет вам внедрить автоматизацию без проблем и позволит избежать распространенных ошибок, которые приводят с сбоям автоматизации. 

10 шагов на пути к внедрению автоматизации тестирования

В этой статье процесс автоматизации тестирования представлен пошагово, поэтому вы получаете руководство, которое поможет вам внедрить автоматизированное тестирование.

Итак, начнем.

Шаг 1. Убедите руководителей

Независимо от того, насколько вам хочется внедрить автоматизацию тестирования в вашей организации, вы ничего сможете сделать, если руководство не видит в нем преимуществ. Все знают, что автоматизация тестирования – это дорого. Инструменты – это дорого (лицензия HP QTP/UFT стоит около 8 тысяч долларов на машину). Есть и стоимость работы архитектора или инженера по автоматизации (которая, кстати, тоже немалая). После всего этого преимущества автоматизации тестирования уже не кажутся такими очевидными. Должно пройти 2-3 месяца, прежде чем скрипты будут готовы, проверены и будут хорошо работать, а только после этого вы сможете начать тестирование вашего приложения.

 Вам нужно убедить руководство, что нужно понести все эти расходы и подождать, прежде чем автоматизация тестирования выдаст какой-то результат.

Так как же их убедить? Вам нужно показать им анализ рентабельности. Например, вы можете задаться вопросом, сколько вы тратите на тестирование BAT (Build Acceptance Testing) вашего приложения? Если оно занимает день, то вы сможете сказать, что с автоматизацией тестирования сможете протестировать его за 2 часа. Стоимость будет состоять из приобретения инструментов, обучения персонала и ожидания результатов в течение двух месяцев. Через два месяца мы сможем проводить BAT за два часа. Каждый раз при выпуске нового билда вы будете экономить 6 часов. Если билд выпускается 4 раза в месяц, то вы сэкономите 24 часа или 3 рабочих дня ручного тестирования!

Тем не менее, это не значит, что ручные тестировщики не будут ничего делать. Они используют свои 6 освободившихся часов, чтобы сосредоточиться на новых и важных функциях приложения, в то время как автоматизация позаботится о задачах регрессии. Такая установка в целом улучшит качество продукта в десятки раз.

Если ваше руководство не готово платить за качество своей продукции, то никто не заставит его это сделать. Они поймут это сами, когда клиенты будут жаловаться на продукт. Качество влияет на все. Оно влияет на ваши продажи, на ваши отношения с клиентами, на восприятие вас в глазах пользователей. Таким образом, грамотное руководство всегда будет инвестировать в качество своих продуктов.

Итак, пять пунктов, которые нужно запомнить, чтобы убедить свое руководство: 

  1. Подробно расскажите им о преимуществах автоматизации тестирования.

  2. Скажите, что автоматизация тестирования как таковая – это дорого, и по началу будет стоить много, но затем стоимость будет снижаться, когда скрипты будут готовы и начнут работать.

  3. Скажите им, что нужно будет подождать около трех месяцев, прежде чем появится какой-то результат от автоматизации тестирования. 

  4. Расскажите, что автоматизация тестирования не имеет целью заменить ручных тестировщиков, а наоборот помогает им, поскольку вместе они могут покрывать большие объемы задач.

  5. Автоматизация тестирования — не значит увеличение объемов тестирования и уменьшение количества времени, затраченного на него, она значит, что вы сможете делать больше задач одновременно. (Если ручные тестировщики проводили BAT за 8 часов, теперь они смогут протестировать BAT и другой функционал за те же 8 часов при наличии автоматизации.)

Помните, что убедить руководство – это самый первый и самый важный шаг на пусти внедрения автоматизации тестирования в вашей организации. Если они не будут уверены в целесообразности, то про вашу идею с внедрением автоматизации можно забыть или уйти в другую организацию :)

Шаг 2: Поиск экспертов по работе с инструментами автоматизации

Есть два вида экспертов по автоматизации:

  1. Архитекторы по автоматизации

  2. Инженеры по автоматизации

Архитектор по автоматизации – редкий зверь. Их непросто найти, они дорого стоят, но при этом они крайне необходимы для успеха проекта автоматизации. Эти специалисты обычно отвечают за создание систем автоматизации. (Фреймворки автоматизации мы подробно обсудим в отдельной статье).

Архитекторы по автоматизации работают с различными инструментами и обычно знают сильные и слабые стороны каждого из них. Такой специалист может помочь руководству выбрать правильный инструмент для автоматизации, тщательно проанализировав приложение и технологии, используемые для его создания. Также они могут построить фреймворк, разработать соглашение об именовании и правила для скриптов. Архитекторы по автоматизации помогут выбрать какие тест-кейсы автоматизировать в первую очередь.

Если вы найдете правильного человека на должность архитектора по автоматизации, то уже полдела по внедрению автоматизации тестирования будет сделано.

С другой стороны, появятся инженеры по автоматизации – это люди, которые переводят ручные тест-кейсы в автоматизированные скрипты. Они будут работать под руководством архитектора автоматизации и будут отвечать за создание и выполнение скриптов.

Одни компании нанимают инженеров по автоматизации извне, а другие воспитывают самостоятельно, обучая ручных тестировщиков. Как бы то ни было, человек должен хорошо владеть программированием. Он/она должны хорошо знать ООП. Команда из одного архитектора по автоматизации и двух инженеров по автоматизации отлично подойдет для работы над большинством продуктов.

Шаг 3: Использование правильного инструмента для автоматизации

Этот шаг заслуживает отдельной статьи (и позже я ее напишу). Он является сложным этапом в процессе внедрения автоматизации. Рынок изобилует различными инструментами, но вам нужно выбрать те, которые будут лучше всего подходить для вашего приложения.

Короче говоря, в этом пункте я опишу самые важные мысли о выборе инструмента. Процесс выбора инструмента я подробно распишу в отдельной статье.

Наиболее важные аспектами, которые следует учитывать при выборе правильных инструментов:

  1. Инструмент должен отвечать вашему бюджету. Средства автоматизации – это дорого. Поэтому у компании под них должен быть заложен бюджет.

  2. Инструмент должен поддерживать технологии, используемые в вашем приложении. Если в нем используется Flash или Silverlight, инструмент должен их поддерживать. Если ваше приложение работает на мобильном устройстве, инструмент должен уметь выполнять скрипты на нем. Вы можете приобрести один инструмент, поддерживающий все технологии, используемые в вашем приложении, или приобрести отдельные инструменты под каждую технологию. Например, для веб-приложений вы можете использовать Selenium, для приложений на Android взять Robotium, а MS Coded UI для десктопных приложений. Каким бы ни было решение, оно должно вписываться в ваш бюджет.

  3. У вас должны быть все необходимые квалифицированные специалисты, которые умеют пользоваться этим инструментом или могут изучить его в кратчайшие сроки. Например, если вы наняли архитектора по автоматизации, у которого есть только опыт работы с QTP, и покупаете лицензию MS Coded UI, то специалист может работать неэффективно. Инструменты – это как хорошие автомобили, но у вас должны быть хорошие водители, чтобы водить их.

  4. У инструмента должен быть хороший механизм генерации отчетов, чтобы можно было показать результаты работы заинтересованным сторонам. 

При выборе инструмента нужно учитывать и другие факторы, о которых мы подробно поговорим в отдельной статье.

Шаг 4: Анализ различных приложений и определение тех, которые лучше подходят для автоматизации

Если ваша организация работает над 5 приложениями, нет необходимости автоматизировать каждое из них. Вам нужно учитывать различные факторы при выборе приложения для автоматизации.

Приложение, которое нужно автоматизировать, должно обладать следующими факторами:

  1. Приложение не должно находиться на ранних стадиях жизненного цикла. (В приложении все или основные модули должны работать стабильно и уже быть протестированы вручную.)

  2. Пользовательский интерфейс приложения должен быть неизменным. (Он не должен часто меняться.)

  3. Ручные тесты для этого приложения должны быть задокументированы.

Основная цель автоматизации состоит в том, чтобы убедиться, что если в одном билде нет каких-то определенных ошибок, то их не должно быть и в следующем. Ручной тестировщик не должен тратить свое время на поиск регрессионных проблем, они должны быть выявлены с помощью автоматизации.

Таким образом, чтобы обнаружить регрессию, нам нужно стабильное приложение и несколько собственных тест-кейсов. Команда автоматизации преобразует эти тест-кейсы в скрипты и будет запускать их при каждой сборке, чтобы убедиться, что регрессия не появляется. 

Шаг 5: Обучение команды

После выбора инструмента и найма необходимых специалистов, следующим шагом должно быть их обучение.

Если ручные тестировщики превращаются в инженеров по автоматизации, они должны знать терминологию и концепции автоматизации. Если архитектор по автоматизации нанят извне, он должен получить информацию о тестируемом продукте, существующем процессе ручного тестирования и о том, что от него ждет руководство.

Дайте сотрудникам некоторое время, чтобы опробовать различные подходы, пока они, наконец, не придумают выигрышную стратегию автоматизации. Обучите их инструментам, которые организация уже использует для отслеживания ошибок и управления требованиями. 

Хорошая подготовка и коммуникация между ручными тестировщиками, разработчиками и командой автоматизации действительно необходимы.

Шаг 6: Создание фреймворка автоматизации тестирования

Самая большая задача для архитектора по автоматизации – это разработать фреймворк автоматизации, который должен поддерживать автоматизированное тестирование в долгосрочной перспективе.

Фреймворк автоматизации – это набор правил и тщательное планирование скриптов, которые нужны, чтобы уменьшить количество требуемого обслуживания. Если что-то меняется в приложении, скрипты практически не нужно менять, чтобы удовлетворить этим изменениям. В этом и заключается прелесть системы автоматизации.

Есть пять типов фреймворков автоматизации: линейный, модульный, управляемый данными, управляемый ключевыми словами и гибридный. Все эти фреймворки с примерами мы подробно рассмотрим в отдельной статье этой серии.

Вы можете узнать больше о фреймворках автоматизации из следующих источников:

  • Зачем нужен фреймворк автоматизации тестирования?

  • Примеры QTP Framework

  • Примеры Selenium Framework

Шаг 7: Разработка плана выполнения

План выполнения подразумевает под собой выбор среды, в которой будут выполняться скрипты. Среда включает в себя операционную систему, браузер и различные аппаратные конфигурации.

Например, если тест-кейс требует проверки веб-сайта в трех браузерах, а именно Chrome, Firefox и IE, то команда автоматизации напишет скрипт таким образом, чтобы он мог выполняться в каждом браузере.

Об этом всегда следует упоминать перед тем, как писать скрипты, потому что тогда команда автоматизации обязательно об этом позаботится. В плане выполнения также нужно указать, кто будет выполнять их. Обычно команда автоматизации выполняет скрипты на каждой сборке, но тут все зависит от компании. Некоторые менеджеры поручают разработчикам выполнить скрипты на сборке перед релизом, а в некоторых компаниях даже есть отдельная команда, которая их выполняет. Также какие-то компании запускают скрипты в автоматическом режиме, на что, конечно, требуются дополнительные ресурсы.

Шаг 8: Написание скриптов

Когда фреймворк готов, план выполнения утвержден, а специалисты обучены работе с новым инструментом, самое время начинать писать скрипты.

Скрипты должны писаться организованно с применением соглашения об именовании. Исходный код должен храниться в системе управления версиями, чтобы не потеряться. Должен присутствовать контроль версий и история изменений. Автоматизация тестирования похожа на разработку программного обеспечения. При написании скриптов нужно учитывать все лучшие практики программирования.

Шаг 9: Отчеты

Функция создания отчетов обычно предоставляется инструментом. Но мы можем создать собственные механизмы генерации отчетов, например, отправлять результаты тестирования по электронной почте руководству автоматически.

Мы можем создавать отчеты после каждого выполнения в виде диаграмм и таблиц, если это необходимо руководству. Руководство всегда должно быть проинформировано о покрытии тест-кейсами, то есть о том, какие ручные операции охвачены автоматизацией, а какие так и остались ручными.

Шаг 10: Обслуживание скриптов

Если вы следуете лучшим практикам программирования и используете хороший фреймворк, то техническое обслуживание не должно стать проблемой.

Техническое обслуживание обычно необходимо, когда есть потребность в изменении приложения. Скрипты нужно обновлять, чтобы учесть изменения в коде и обеспечить безупречное выполнение.

Например, если раньше вы с помощью скрипта вводили текст в текстовое поле, а в новой версии приложения это текстовое поле стало выпадающим списком, то скрипт необходимо немедленно обновить.

Другие изменения могут возникнуть, если раньше ваши скрипты работали на английской версии приложения, а теперь их нужно менять, поскольку приложение будет поддерживать и китайский. Ваш фреймворк должен позволять вам обновлять скрипты без особых усилий, чтобы ваше приложение хорошо работало и на китайском! Именно поэтому архитекторы по автоматизации стоят дорого. :)

Если фреймворк получился не очень хорошим, а лучшие практики не используются, то техническое обслуживание станет вашим кошмаром. Большинство проектов по автоматизации терпят неудачу из-за плохого обслуживания наборов скриптов.

Заключение

В этой статье мы поговорили о том, что такое процесс автоматизированного тестирования и как шаг за шагом ввести практику автоматизированного тестирования в вашей организации. Если вы сможете выполнить все эти шаги, надеюсь, что у вас получится успешно внедрить автоматизацию.

Есть некоторые моменты (например, выбор инструментов автоматизации и фреймворков), о которых можно написать отдельные статьи. В следующих руководствах по автоматизации тестирования мы их обязательно рассмотрим. 

Я постарался охватить все аспекты и использовал свой собственный опыт для написания этой статьи.

Если вы считаете, что я упустил что-то важное или какая-то часть этой статьи нуждается в дополнении, расскажите об этом в комментариях. 


Перевод статьи подготовлен в преддверии старта курса Python QA Engineer.

Узнать о карьерных перспективах профессии.

Записаться на бесплатный демо-урок.

Читать ещё:

  • Тестирование скриншотами

What is Automation Testing and How Does It Work?

Automation Testing, often known as Test Automation, is a software testing
approach that involves the execution of a test case collection using particular
automated testing software tools. On the other hand, manual testing is carried
out by a person sitting in front of a computer, methodically carrying out the test
processes.

In addition to entering test data into the System Under Test, the automated
testing software may analyze predicted and actual outcomes and provide
complete test reports. Software Test Automation necessitates significant financial
and human resources.

Continuous implementation of the same test suite will be required in subsequent
development cycles. This test suite may be recorded and replayed as needed
using a test automation tool. There is no need for human interaction after the test
suite has been automated. Test Automation’s return on investment has increased
as a result of this. The purpose of automation is to minimize the number of test
cases that must be done by humans, not to completely remove human testing.

In this automated software testing course, you’ll master the fundamentals of test
automation, including −

  • What are Automation Testing and How Does It Work?

  • What Are the Benefits of Automated Testing?

  • What Test Cases Should Be Automated?

  • Method of Automated Testing

  • Choosing a test tool

  • Describe the automation’s scope.

  • Planning, Design, and Development are all important aspects of any
    project.

  • Implementation of the Test

  • The Automation Framework

  • Best Practices for Automation Tools

  • Advantages of Automated Testing

  • Automated Testing Types

  • What Should You Look for in an Automation Tool?

  • Automated Testing Software

What are the benefits of test automation?

Test automation is the most effective technique to improve software testing
effectiveness, test coverage, and execution speed. The importance of automated
software testing may be summed up as follows −

  • Manual testing takes time and money to test all procedures, fields, and bad
    cases.

  • Manually testing for multilingual sites is challenging.

  • In software testing, test automation eliminates the need for human
    interaction. Unattended automated testing is possible (overnight)

  • Test automation accelerates the execution of tests.

  • Increased Test Coverage is aided by automation.

  • Manual testing may become tedious and, as a result, prone to errors.

What Test Cases Should Be Automated?

To maximize the automation ROI, test cases to be automated might be chosen
based on the criteria below.

  • High-risk – critical-to-business test scenarios

  • Test scenarios that are run on a regular basis

  • Manually doing test cases that are time consuming or challenging

  • Test Cases that take a long time to complete

Test cases in the following categories are not appropriate for automation −

  • Newly developed test cases that have not been personally performed at least once

  • Test cases in which the requirements change regularly

  • Test cases that are run on an as-needed basis.

Process of Automated Testing

In an Automation Process, the stages are as follows −

Step 1 − Choose a test tool

Step 2 − Define the Automation Scope

Step 3 − Design, Planning, and Development

Step 4 − Execution of the Test

Step 5 − Maintenance

Choosing a test tool

The technology that the Application under Test is based on has a big impact on
the Test Tool you choose. QTP, for example, does not support Informatica. As a
result, QTP will not be able to test Informatica apps. Conducting a Proof of
Concept of Tool on AUT is an excellent idea.

Define the automation’s scope

The area of your Application Under Test that will be automated is referred to as
the scope of automation. The following factors aid in determining scope −

  • The elements that are critical to the company’s success

  • Scenarios with a significant quantity of data

  • Functionalities that are shared across apps

  • Possibility from a technical standpoint

  • The percentage of business components that are reused

  • The difficulty of the test cases

  • Cross-browser testing using the same test scenarios is possible.

Planning, Design, and Development are all important aspects of any project.

You establish an Automation strategy and plan at this phase, which includes the
following details −

  • Tools for automation have been chosen.

  • The design of the framework and its characteristics

  • Automation things that are both in-scope and out-of-scope

  • Preparation of an automation testbed

  • Scripting and execution schedules and timelines

  • Automation Testing Deliverables

Execution of the Test

Automation During this phase, scripts are run. Before they may be configured to
run, the scripts need input test data. They generate extensive test results after
they’ve been run.

The automation tool may be used directly or via the Test Management tool, which
will launch the automation tool.

For instance, Quality Center is a Test Management solution that, in turn, invokes
QTP to run automation scripts. Scripts may run on a single system or across
several machines. To save time, the execution might be carried out at night.

Maintenance Methodology for Test Automation

The Test Automation Maintenance Approach is a step of automation testing that
is used to see whether the new features introduced to the program are operating
properly. When new automation scripts are introduced, they must be evaluated
and maintained in order to enhance the efficacy of automation scripts with each
release cycle.

The Automation Framework

A framework is a collection of automation principles that aid in the automation
process.

  • Maintaining Testing Consistency

  • Enhances the structure of tests

  • Code use is kept to a minimum.

  • Code maintenance is reduced.

  • Reusability should be improved.

  • Involvement of non-technical testers in coding is possible.

  • The time it takes to learn how to use the instrument may be cut in half.

  • Uses data when it’s appropriate

In automated software testing, there are four kinds of frameworks −

  • Framework for Data-Driven Automation

  • Framework for Keyword-Driven Automation

  • Framework for Modular Automation

  • Framework for Hybrid Automation

Best Practices for Automation Tools

Keep the following in mind if you want to get the most out of automation.

  • Prior to the commencement of the project, the scope of Automation must
    be specified in detail. This is a good way to establish expectations for
    Automation.

  • Choose the correct automation tool: A tool should not be chosen primarily
    on its popularity, but rather on its ability to meet the automation needs.

  • Select a suitable framework.

  • Scripting Standards — When creating automation scripts, standards must be
    observed. Some of them include −

    • Create code with consistent scripts, comments, and indentation.

    • Appropriate Exception Handling — How errors are handled in the
      event of a system failure or unexpected application behavior.

    • For Error Logging, user-defined messages should be codified or
      standardized so that testers can interpret them.

  • Measure metrics — The success of automation cannot be judged just by
    comparing the manual and automated efforts, but rather by collecting the
    data listed below.

    • Percentage of faults discovered

    • The amount of time necessary for each release cycle’s automated testing.

    • Release takes the least amount of time possible.

    • Customer Satisfaction Index (CSI) is a measure of how satisfied
      customers are with

    • Enhancement of productivity

If you follow the above recommendations, your automation will be a huge
success.

Advantages of Automated Testing

The following are some of the advantages of test automation −

  • Testing is 70% quicker than manual testing.

  • More application functionalities are tested.

  • dependable in terms of outcomes

  • Maintain Consistency

  • Saves both time and money

  • Enhances precision

  • During the execution, no human intervention is necessary.

  • Enhances Productivity

  • Improved test execution speed

  • Test scripts that may be reused

  • Frequently and thoroughly test

  • Automation allows for a longer cycle of execution.

  • Earlier delivery to market

Automated Testing Types

  • Testing for Smoke

  • Testing at the unit level

  • Integrity Checking

  • Testing of Functionality

  • Keyword Research

  • Testing for Regression

  • Data-Informed Testing

  • Testing in a Black Box

What Should You Look for in an Automation Tool?

Choosing the appropriate instrument might be difficult. The criteria listed below
will assist you in choosing the right tool for your needs −

  • Support for the Environment

  • User-friendliness

  • Database Validation

  • Object recognition

  • Image Evaluation

  • Testing for Error Recovery

  • Mapping of Objects

  • Used Scripting Language

  • Support for a variety of test kinds, such as functional, test management,
    mobile, and so on…

  • Multiple testing frameworks are supported

  • The automation software scripts are simple to debug.

  • The ability to distinguish items in a variety of settings.

  • Test reports and findings that are extensive

  • Reduce the cost of training for chosen tools.

One of the most difficult difficulties to overcome before automating is tool
selection. Identify the needs first, then investigate potential tools and their
capabilities, create expectations for the tool, then do a Proof Of Concept.

Automated Testing Software

On the market, there are a plethora of Functional and Regression Testing Tools.
Here are the greatest test automation solutions that our experts have
recommended.

1. Ranorex Studio

Ranorex Studio, an all-in-one test automation solution, is used by over
14,000 people across the globe to speed up testing. For novices, Ranorex
offers simple click-and-go codeless tools and a comprehensive IDE and
open APIs for automation specialists.

Features

  • End-to-end testing and functional UI on PC, web, and mobile

  • Cross-browser testing is a method of determining how well a website
    works

  • SAP, ERP, Delphi, and legacy systems are just a few examples.

  • Apple’s iOS and Google’s Android

  • Run tests in parallel on actual or virtual computers, locally or
    remotely.

  • Playback of the test execution on video

  • Reporting capabilities built-in

  • For a full testing toolchain, Ranorex connects with top technologies
    like as Jira, Git, Azure DevOps, Jenkins, Bamboo, Bugzilla, SpecFlow,
    NeoLoad, TestRail, and more.

Kobiton

The Kobiton mobile device testing platform supports both scripted and
script less test automation. Users may develop manual tests that are
automatically re-run on a range of real-world devices. Kobiton fully
supports test automation frameworks like Appium, Espresso, and XCTest, as
well as providing its own scriptless test automation using NOVA AI.

Features

  • Kobiton’s device lab management allows you to connect to cloudbased
    devices, on-premises devices, and on-desk devices.

  • Manual test sessions may be converted into scripts that can be run
    on many devices, allowing users to generate test scripts automatically.

  • When a test fails, easily link your defect management system to
    immediately record tickets with debug sessions attached.

  • Appium Anywhere technology from Kobiton guarantees fewer flaky
    test scripts by ensuring that your test executes the same on all
    devices.

  • Kobiton’s scriptless test automation provides open-source Appium
    code that may be used in a variety of ways.

ZAPTEST

ZAPTEST is a Software Automation solution for any company that utilizes
software for operations or development and wants to automate back-office
operations or software testing procedures while also developing a revolving
automation framework.

Features

  • Automated Functional and Performance Testing

  • RPA stands for Robotic Process Automation (Robotic Process
    Automation)

  • RPA Software Automation + Seamless Testing

  • Execution on Multiple Platforms (Parallel)

  • Automated DevOps (Mock-ups)

  • API Evaluation

  • Auto-Documentation

LambdaTest

LambdaTest is a popular tool for doing automated cross-browser testing.
They provide a selenium grid that is ultra-fast, scalable, and secure,
allowing customers to conduct tests on over 2000 browsers and operating
systems. It works with all modern and older browsers.

Features

  • Test execution is quick and flawless thanks to the newest tech stack

  • To reduce test cycles, parallel test execution is used.

  • Simple connection with CI/CD, project management, and team
    communication systems.

  • Users may test their geo location as well as their locally hosted website.

  • Users may use a variety of APIs to get all of the information they need.

  • All major languages and frameworks are supported.

Conclusion

Test Automation is a software testing approach that executes a test case set
utilizing particular automated testing software tools.

Test automation is the most efficient technique to improve software testing
productivity, test coverage, and computational efficiency.

The technology that the Application under Test is based on has a big impact on
the Test Tool you choose.
Maintenance of Test Automation Approach is a kind of automated testing that is
used to see whether the new features introduced to the program are operating
properly.

For automation to be effective, the correct automation technology, testing
procedure, and team must all be in place. For effective testing, manual and
automated approaches should be used together.

На связи команда Айтигро. В статье подробно расскажем, что такое автотесты, когда и как их нужно и не нужно использовать, а также на конкретном примере разберем опыт внедрения автотестов в проекте «Наигру».

Автотесты в веб-сервисы Наигру: сценарии

Что такое автотесты простым языком?

Если совсем просто, то это когда вместо человека тестирование производит программа. Первые автотесты появились в эпоху бородатых систем DOS. В общем технология не новая и человечество в этом вопросе набило немало шишек.

В интернете встретили хорошую аналогию: представьте что мост — это программа (или в нашем случае веб-сервис). По мосту запускаем полностью нагруженный товарный состав (виртуальный трафик). Когда поезд едет по мосту, на котором установлены датчики, мы получаем информацию о трещинах, деформации балок, разрушении железнодорожного полотна. Это есть end-to-end тестирование (подробнее описано ниже). А вот если добавить, что после каждого изменения моста (добавление балки, изменение геометрии опор и т.д.) поезд запускается автоматически, а датчики, улавливая ошибку, не пропускают его дальше – то это уже автоматическое end-to-end тестирование.

Простое тестирование – это когда после изменения конструкции моста мы запускаем поезд вручную и смотрим, оцениваем, выдержит ли мост поезд или нет (и ставим под мост тестировщиков и разработчиков, ха-ха).

С определениями разобрались. Поехали дальше.

Что и как можно автоматически тестировать?

Автоматически можно тестировать программный код или пользовательский интерфейс. В статье мы будем говорить про автотесты через пользовательский интерфейс.

Если говорить совсем точно, статья будет про автоматическое end-to-end (E2E, сквозное) тестирование, имитирующее пользовательскую среду и поэтапно моделирующие действия пользователей.

Автоматическое end-to-end (E2E) тестирование — это процесс автоматического тестирования с подробной эмуляцией действий пользователя: кликаньем мышки, переходами по страницам, заполнения форм и так далее. Цель E2E тестирования — удостовериться, что программа работает именно так, как задумано для конечного пользователя.

E2E тестирования обычно проводится в самом конце перед «выкаткой» изменений или доработок на рабочие версии продуктов. Поэтому ошибки, возникающие при некачественном E2E тестировании, могут быть очень дорогими.

Пример. Мы «выкатываем» приложение с потенциалом 10 000 регистраций в месяц. Предположим, мы не заметили, что после изменения одной из функций пользователи не видят модальное окно об успешной регистрации и это снижает общую конверсию на 5%. Стоимость одной регистрации составляет 15 долларов. За первый месяц мы потеряем 7 500 долларов.

Типы E2E тестирования: черный и белый ящик

Метод черного ящика — метод тестирования, при котором проверяется только интерфейс. Ошибки в логике не отслеживаются.

Метод белого ящика — метод тестирования, при котором проверяется сопоставление работы программы с эталоном.

Мы в проекте использовали метод белого ящика и проверяем правильность работы не только блоков интерфейса, но и логики.

Как мы пришли к автотестам в проекте Наигру

Наигру – это веб-сервис для организации спортивных игр, помогающий организаторам создавать тренировки, а участникам записываться на них.

Когда в проект добавилось множество механик, из-за которых структура проекта стала разрастаться, на проекте стали возникать ошибки там, где мы их совсем не ожидали. Возникла классическая проблема: дорабатывая дополнительный функционал начал ломаться базовый.

Например, перестала работать кнопка «Записаться на игру» после доработки механизма перехода игроков из резерва в основной состав. Или при создании регулярных игр возникали баги в обычных разовых играх – например, при записи на игру не показывалось модальное окно об успешном действии и пользователь не мог понять, записан ли он.

Наигру: Ошибка «Не показывается модальное окно»

Эти функции не являются взаимосвязанными, поэтому отследить такие ошибки ручным тестированием было сложно и удавалось не сразу.

Ручное тестирование

Сначала проблему решали введением регулярного классического ручного регрессионного тестирования — проверяли, чтобы ранее созданный и проверенный функционал продолжал корректно работать после добавления нового.

Регрессионное тестирование делится на 3 уровня: проверка нового блока, проверка ранее добавленных блоков, а также проверка связанных и не связанных сторонних блоков после добавления или изменения блока. В среднем одно такое тестирование занимало два рабочих дня.

Стало понятно, что с течением времени такое тестирование станет сильно тормозить ход развития проекта, а именно добавление новых функций.

Подготовка к автоматическому тестированию

Пришли к выводу, что рациональнее будет автоматизировать проверку всех основных сценариев. В описываемом проекте примерами таких сценариев являются:

  • Регистрация/авторизация пользователей

  • Создание и редактирование игры
  • Запись на игру
  • Отписка игрока от тренировки
  • Запись в резерв, переход в основной состав

Сформировали алгоритмы поведения пользователей

Например, проверка регистрации: сайт открывается → выбор чекбокса города Москва → нажатие «Сохранить» → нажатие на «Войти или создать аккаунт» → проверка ошибки неправильно заполненного телефона → ввод сгенерированного номера → нажатие «Войти» → проверка наличия авторизации после регистрации и выход из профиля.

Созданные алгоритмы поведения пользователей использовали в тестах критически важных функций сайта: авторизация, создание игры, приглашение на игру, запись на тренировку, отписку от тренировки, механизм перевода игрока из резерва в основной состав и т.д.

Затем подготовленные тесты разбили так, чтобы разные алгоритмы можно было проверять независимо друг от друга. Таким образом, мы создали систему автотестов, которую легко поддерживать – при добавлении функционала достаточно добавить новые файлы спецификаций в готовую структуру.

Наигру: проверка алгоритма действий организатора
Наигру: проверка алгоритма действий игрока

Что получили в итоге?

После сборки проекта любые изменения при переносе кода на последний шаг перед публикацией автоматически запускают автотест, а результат отправляется на почту ответственным за проект сотрудникам – в том числе разработчикам проекта.

То есть новые функции или изменения в принципе не могут быть запущены на рабочем сайте без прохождения автотестов. Это последний рубеж защиты от программных ошибок и экономических потерь бизнеса.

Отчет об автоматическом тестировании (пайплайн)

Email с отчетом по итогу автотестирования

Дополнительно настроено регулярное тестирование базовых функций сайта: регистрации, ввод телефонов и так далее. Проверка запускается по таймеру независимо от внесения изменений в проект.

Было/стало

Ручное тестирование:

  • Тестировали только функционал, который дорабатываем – пропускали непрогнозируемые ошибки базового функционала
  • Узнавали о проблемах по факту – тратили много времени на поиск причины и на ее устранение

Автотесты:

  • Без полной проверки базового функционала на рабочий сайт не попадает ни одна доработка
  • Узнаем о проблеме заблаговременно и затрачиваем меньше ресурсов на устранение

В итоге мы создали инструмент помощи разработчикам — теперь мы находим баги на раннем этапе разработки и устраняем их раньше, чем их найдет тестировщик или пользователь.

Про инструментарий (Внимание! Начинается техническая часть)

Опробовав сначала сервис Селениум для написания автотестов, остановились на Сайпрес – он имеет подробнейшую документацию и оказался для наших тестировщиков более удобным для написания тестов и отладки.

Селениум:

  • Не user-friendly
  • Сложнее отследить, на каком моменте тест провален – отсутствует система репортов

Сайпрес:

  • Удобен для написания тестов и отладки – продуманный интерфейс
  • Наглядно показано (информация и скриншот), на каком моменте и по какой причине тест провален

У каждого инструмента есть свои нюансы

Например, Cypress, на котором остановились мы, не сохраняет Cookie и LocalStorage между тестами. В нашем случае это влияет на сохранение данных о пользователе между тестами (данные об авторизации), чтобы алгоритм работал так, будто действия создает один и тот же пользователей. Для устранения этой проблемы мы подобрали плагин (cypress-localstorage-commands), который сохраняет необходимые данные между тестами, а также настраивали файл конфигурации, чтобы сохранялись Cookie.

Файл конфигурации: сохранение Cookie

Но если вы выбираете развивающийся инструмент, такой как Cypress, то часть подобных проблем может быть закрыта в следующих обновлениях ПО (так было и в нашем случае – после обновления мы стали использовать экспериментальные функции сессий).

Экспериментальные функции сессий: сохранение Cookie

Отдельные элементы кода

Капча (CAPTCHA) тоже может мешать запуску автотестов – в рамках тестов настроили авторизацию по POST-GET запросу к API, минуя интерфейс авторизации.

Авторизация по POST-GET запросу к API

Разновидность сайта

Есть и свои нюансы автотестов для разных типов сайтов. Наигру реализован как Single Page Application – для такого рода сайтов “скриптовые” ошибки, которые не являются критичными для работы сервиса, мешают работе теста. Их приходилось отключать, чтобы предотвращать провалы теста, так как инструмент не пропускал алгоритм дальше.

Скриптовая ошибка

Структура кода

Когда код писался без оглядки на то, что будут настраиваться автотесты, может возникнуть несогласованность архитектуры необходимым требованиям для построения механизма теста.

В проекте Наигру подобной проблемой стало расположение селекторов в структуре HTML-древа. Как итог – невозможно настроить тест таким образом, чтобы он понимал, какому конкретному организатору принадлежит игра. Этот момент необходимо учитывать при построении алгоритма тестирования

Необходимые навыки для создания автотестов

С автоматизаций тестирования вполне справится опытный тестировщик.

Для этого специалисту необходимо:

  • базовые навыки программирования и знание JavaScript (преимущественно автотесты пишутся именно на нем)
  • знание Node.js – помогут при установке плагинов и настройке связей между спецификациями
  • понимание особенностей построения архитектуры HTML-древа и работы селекторов
  • знание Git – для более эффективного взаимодействия с командой разработки, поможет создавать “коммиты” и загружать их в проект

Чтобы специалисту за довольно короткое время освоить автотестирование понадобится документация выбранного инструмента автоматизации и парочка роликов на youtube. Наш тестировщик вдохновлялся каналом Глеба Бахмутова.

Со сложными для понимания вопросами можно обратиться к коллеге-программисту уровня мидл и выше.

Важно: для корректной работы автотестов их нужно включить в общий процесс разработки. Для этого потребуется пара часов времени программиста проекта.

Реализация автоматического тестирования – гармоничный путь развития тестировщика. Таким образом специалист все больше наращивает знания программирования и уходит от ручного тестирования в сторону более сложного и перспективного. С таким бэкграундом дальше он сможет двигаться к квалификации разработчика.

Золотое соотношение в видах тестирований

В отрасли применяют разные соотношения между ручными и автотестами. Например, в Google автотесты занимают около 10% от всего вида тестирования, а остальные тесты выполняются специалистами вручную.

Главное правило звучит так: автотестов должно быть существенно меньше, чем обычных – иначе это приведет к существенному удорожанию поддержки проекта.

Мы не советуем покрывать автотестами более 10-15% функционала.

Заключение

С точки зрения реализации – автоматическое тестирование можно сделать под любой проект.

Преимущества автотестов:

  • Быстро находят критичные ошибки
  • Нет человеческого фактора – непредвзятые
  • Накапливают сценарии для регресс-тестирования

Слабые места:

  • Требуют постоянной доработки
  • Могут возникнуть сложности при разработке теста, если изначально на проекте не предполагалось использовать автоматическую проверку
  • Польза от автотестов не всегда окупает затраты на их подготовку (если базовый функционал проекта постоянно изменяется, то и автотесты придется менять каждый раз вместе с ним – в таком случае это будет занимать больше времени и сил, чем ручное тестирование)

На наш взгляд, автотесты наиболее актуальны для крупных и быстроразвивающихся веб-сервисов. Если на сайте сложная логика и высокие риски багов, которые повлияют на работоспособность системы в целом, но при этом стабильный базовый функционал – автотесты лучшее решение.

Довольно сложно создать и поддерживать сценарий, который покроет весь функционал и будет корректно проверять максимально много. Но это и не нужно. Цель автотестов – быстро проверять работу основных механизмов, ошибки в которых являются критичными и могут повлечь за собой снижение производительности.

Если вы запускаете крупный проект либо активно развиваете уже существующий, и хотите избежать критичных ошибок, рекомендуем рассмотреть к внедрению автотесты.

Пожалуйста, поставьте статье upvote (стрелочка вверх), мы старались :)

Мы будем использовать Selenium совместно с Python версий 3.x.x. Цель статьи – не дать фундаментальные знания по теории программирования и написания автотестов, а заинтересовать в этой области и показать, как они пишутся в целом.

1. Установка необходимых компонентов

Для начала работы нам потребуется установить Python на рабочую машину.

Переходим на официальный сайт Python и качаем установщик для вашей ОС (мы будем использовать Windows). В процессе инсталляции поставьте галочки на добавлении компонентов в системные переменные PATH. Дождитесь завершения процесса, и если программа попросит перезагрузки, перезагрузитесь. Если у вас Linux, интерпретатор может уже присутствовать в системе, в противном случае стоит установить его из репозитория пакетов вашего дистрибутива.

Проверьте корректность установки, перейдите в терминал (в Windows нажмите Win+R и запустите cmd или Alt+Ctrl+T в графической среде Linux). Выполните следующую команду:

        python --version
    

<i>Рис. 1. Должна быть выведена версия, а если что-то не получилось, проверьте выполнение по шагам и повторите попытку</i>

Рис. 1. Должна быть выведена версия, а если что-то не получилось, проверьте выполнение по шагам и повторите попытку

Далее нам понадобится сам Selenium:

        pip install selenium
    

Дождитесь завершения установки. Поскольку мы будем писать тест, воспользуемся популярной библиотекой pytest. Устанавливается она аналогично:

        pip install pytest
    

Для создания приложений нужна интегрированная среда разработки или IDE (integrated development environment), но можно писать код и в обычном текстовом редакторе. Я выбрал самую популярную и удобную среду PyCharm от компании JetBrains.

Чтобы работать с браузером, помимо Selenium потребуется веб-драйвер: в нашем случае ChromeDriver – по сути это связующее звено в цепочке. Обратите внимание, что версия драйвера должна соответствовать версии браузера и вперед – к созданию проекта и написанию первого скрипта.

2. Первый скрипт с использованием драйвера

Все компоненты готовы, давайте создадим новый проект. Для
этого запускаем PyCharm и в открывшимся окне выбираем New Project.

<i>Рис. 2</i>

Рис. 2

Указываем
имя проекта и нажимаем Create.

Рис. 3

Рис. 3

Напишем первый тест, чтобы проверить работоспособность драйвера.

<i>Рис. 4. Пример кода в файле main.py</i>

Рис. 4. Пример кода в файле main.py

В качестве примера ресурса для тестирования возьмем
популярный сайт для практики автоматизированного тестирования: https://www.saucedemo.com.

Кейс:

  • Зайти на страницу.
  • Найти элемент по id.
  • Вывести в консоль сообщение с результатом поиска.
main.py
        from selenium import webdriver

options = webdriver.ChromeOptions()
options.add_experimental_option("excludeSwitches", ["enable-logging"])
driver = webdriver.Chrome(options=options, executable_path=r'C:/Users/.../.../chromedriver.exe')
driver.get("https://www.saucedemo.com/")
input_username = driver.find_element_by_id("user-name")
if input_username is None:
   print("Элемент не найден")
else:
   print("Элемент найден")

    

После
ввода кода необходимо установить библиотеку Selenium в наш проект.

Для
этого нажмите на подсвеченный текст в редакторе, нажмите Alt + Enter и далее
выберите Install package selenium. Это нужно делать для
каждого неустановленного пакета.

<i>Рис. 5. Пример установки пакета в проект</i>

Рис. 5. Пример установки пакета в проект

Запустить сценарий можно во встроенном эмуляторе терминала IDE или в любом другом:

        python main.py
    

<i>Рис. 6. <span>Пример
запуска скрипта из IDE</span></i>

Рис. 6. Пример
запуска скрипта из IDE

Если все установлено правильно, должен запуститься браузер,
который откроет страницу. Результатом запуска нашего сценария на Python, будет
сообщение: “Элемент найден”.

Рис. 7. Результат выполнения скрипта.

Рис. 7. Результат выполнения скрипта.

3. Поиск элементов

В нашем скрипте присутствует следующая строка:

        input_username = driver.find_element_by_id("user-name")
    

Метод find_element_by_id позволяет процессу найти элемент в разметке HTML по наименованию атрибута id. В реализации драйвера есть несколько способов поиска элементов на странице: по name, xpath, css, id. Поиск по css и xpath являются более универсальным, но он сложнее для начинающих. Использование поиска по name и id намного удобнее, но в практической разработке используется редко. Далее я буду использовать только xpath.

Теперь
давайте напишем кейс аутентификации пользователя на странице входа:

  • Шаг 1: пользователь вводит корректный username и password.
  • Шаг 2: нажимает кнопку ввода.
  • Ожидаемый результат: пользователь попадает на главную страницу магазина. Проверка заголовка на соответствие “PRODUCTS”.
main.py
        import time

from selenium import webdriver
from selenium.webdriver.common.keys import Keys


def first_test():
    options = webdriver.ChromeOptions()
    options.add_experimental_option("excludeSwitches", ["enable-logging"])
    driver = webdriver.Chrome(options=options, executable_path=r'C:/Users/.../.../chromedriver.exe')
    driver.get("https://www.saucedemo.com/")

    # Поиск элементов и присваивание к переменным.
    input_username = driver.find_element_by_xpath("//*[@id="user-name"]")
    input_password = driver.find_element_by_xpath("//*[@id="password"]")
    login_button = driver.find_element_by_xpath("//*[@id="login-button"]")

    # Действия с формами
    input_username.send_keys("standard_user")
    input_password.send_keys("secret_sauce")
    login_button.send_keys(Keys.RETURN)

    # Поиск и проверка попадания на главную страницу
    title_text = driver.find_element_by_xpath("//*[@id="header_container"]/div[2]/span")
    if title_text.text == "PRODUCTS":
        print("Мы попали на главную страницу")
    else:
        print("Ошибка поиска элемента")

    time.sleep(5)


if __name__ == '__main__':
    first_test()

    

Разберем
пример пошагово:

  • Для работы с формой найдем и присвоим элементы переменным input_username, input_password и login_button с помощью xpath.
  • Далее вызовем для элемента метод send_keys с данными, которые хотим передать в текстовое поле. В нашем случае в username отправляем «standart_user», в password«secret_sauce». Проецируя поведение пользователя нажимаем Enter для ввода данных, используя метод send_keys для найденной кнопки с переданным аргументом Keys.RETURN. Этот аргумент позволяет работать с действиями клавиатуры в Selenium, аналогично нажатию на Enter на клавиатуре.
  • На главном экране нам необходимо найти и присвоить переменной элемент текста Products. Как я говорил раннее, не всегда есть возможность найти элемент по id – здесь как раз тот случай.
        title_text = driver.find_element_by_xpath("//*[@id="header_container"]/div[2]/span")
    
  • Путь xpath до элемента: //*[@id="header_container"]/div[2]/span.
  • Чтобы найти путь xpath, зайдите на https://www.saucedemo.com и нажмите F12, чтобы открыть инструменты разработчика. Затем выберите стрелку-указатель и кликните по элементу до которого хотите найти путь. В нашем случае до Products.

<i>Рис 8. Поиск xpath элемента в инструментах разработчика</i>

Рис 8. Поиск xpath элемента в инструментах разработчика
  • Откроется код элемента в дереве HTML, далее нужно открыть контекстное меню выделенной строки и скопировать xpath.

<i>Рис 9. Копирование пути xpath</i>

Рис 9. Копирование пути xpath

Если кратко рассматривать путь, то //* обозначает, что будут найдены все элементы на странице, а [@id="header_container"] обозначает условие поиска (будут найдены все элементы на странице с тэгом id = "header_container").И далее /div[2]/span – спускаемся на второй дочерний элемент div и далее на дочерний элемент span. Сравните полученный xpath с деревом элемента в инструментах разработчика – сразу станет понятно что к чему.

  • Тут мы просто сравниваем текст найденного элемента с ожидаемым значением и выводим в консоль сообщение.
main.py
        if title_text.text == "PRODUCTS":
    print("Мы попали на главную страницу")
else:
    print("Ошибка поиска элемента")

    

При выполнении скрипта получили следующий результат:

Рис 10. Результат выполнения скрипта

Рис 10. Результат выполнения скрипта

4. Первый тест с поиском и переходом по странице

Кейс:

  • Введем логин и пароль пользователя и зайдем на главную страницу.
  • Найдем позицию с названием «Sauce Labs Fleece Jacket».
  • Перейдем на страницу товара и нажмем кнопку добавления в корзину.
  • Перейдем в корзину и проверим что там присутствует 1 позиция с названием «Sauce Labs Fleece Jacket».
main.py
        import time

from selenium import webdriver
from selenium.webdriver.common.keys import Keys


def first_test():
    options = webdriver.ChromeOptions()
    options.add_experimental_option("excludeSwitches", ["enable-logging"])
    driver = webdriver.Chrome(options=options, executable_path=r'C:/Users/…/…/chromedriver.exe')
    driver.get("https://www.saucedemo.com/")

    # Поиск элементов и присваивание к переменным.
    input_username = driver.find_element_by_xpath("//*[@id="user-name"]")
    input_password = driver.find_element_by_xpath("//*[@id="password"]")
    login_button = driver.find_element_by_xpath("//*[@id="login-button"]")

    # Действия с формами
    input_username.send_keys("standard_user")
    input_password.send_keys("secret_sauce")
    login_button.send_keys(Keys.RETURN)

    # Поиск ссылки элемента позиции магазина и клик по ссылке
    item_name = driver.find_element_by_xpath("//*[@id="item_5_title_link"]/div")
    item_name.click()

    # Поиск кнопки добавления товара и клик по этой кнопке
    item_add_button = driver.find_element_by_xpath("//*[@id="add-to-cart-sauce-labs-fleece-jacket"]")
    item_add_button.click()

    # Поиск кнопки коризины и клик по этой кнопке
    shopping_cart = driver.find_element_by_xpath("//*[@id="shopping_cart_container"]/a")
    shopping_cart.click()

    # Еще один поиск ссылки элемента позиции магазина
    item_name = driver.find_element_by_xpath("//*[@id="item_5_title_link"]/div")
    if item_name.text == "Sauce Labs Fleece Jacket":
        print("Товар пристутствует в корзине")
    else:
        print("Товар отсутствует")

    time.sleep(5)


if __name__ == '__main__':
    first_test()

    

Из
нового тут добавился только метод click(), который просто кликает по
найденному элементу.

После прохождения всех шагов в консоль выводится результат, что в
корзине имеется товар.

Ожидания в selenium: что нужно знать?

В предыдущем кейсе с большой вероятностью можно столкнуться с проблемой, когда при нажатии на позицию мы сразу кликаем на корзину. При медленном интернете или долгом ответе от сервера в корзину может ничего не добавиться. Для таких случаев предусмотрены ожидания.

Selenium driver поддерживает два вида ожиданий: явное (explicit) и неявное (implicity). Для явных ожиданий есть специальные методы, которые помогут рационально использовать время выполнения теста: например, можно установить минимальное время ожидания и возвращать элемент, если он прогрузился раньше предполагаемого времени.

Пример явного ожидания:

        element = WebDriverWait(driver, 10).until(
    EC.element_to_be_clickable(
        (By.XPATH, '//*[@id="page_wrapper"]/footer/ul/li[2]/a')
    )
)

    

Процесс ждет 10 секунд пока элемент станет доступным, чтобы по
нему можно было кликнуть. Если элемент так и не прогрузился и недоступен для
клика, генерируется исключение TimeoutException.

Неявные ожидания в свою очередь устанавливаются один раз для
драйвера, а не для каждого элемента. Включается неявное ожидание, когда Selenium не может найти элемент: он ждет установленное время и если не дождется, тоже возвращает TimeoutException. В отличии от явного ожидания, этот тип менее гибок и может оказать плохое влияние на общее время прогона
тестов.

Пример неявного ожидания:

        driver.implicitly_wait(10)
    

Ожидать действия можно и с помощью time.sleep(5). У нас в
примерах есть использование этого метода, но оно считается плохой практикой и обычно применяется только для дебага.

5. Рефакторинг теста, добавление ожиданий

Чтобы
pytest понял, что перед ним именно тестовая, а не обычная функция, сама тестовая функция
должна начинаться с test_.

Обновим наш тест, добавим необходимые ожидания для
стабильности тестовых функций.

Также я вынес отдельную функцию под ожидания, куда мы просто
передаем xpath и driver в виде аргументов.

main.py
        from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.by import By
from selenium.webdriver.support.wait import WebDriverWait
import time

from selenium import webdriver
from selenium.webdriver.common.keys import Keys


# Функция ожидания элементов
def wait_of_element_located(xpath, driver):
    element = WebDriverWait(driver, 10).until(
        EC.presence_of_element_located(
            (By.XPATH, xpath)
        )
    )
    return element


def test_add_jacket_to_the_shopcart():
    options = webdriver.ChromeOptions()
    options.add_experimental_option("excludeSwitches", ["enable-logging"])
driver = webdriver.Chrome(options=options, executable_path=r'C:/Users/…/…/chromedriver.exe')
    driver.get("https://www.saucedemo.com/")

    # Поиск и ожидание элементов и присваивание к переменным.
    input_username = wait_of_element_located(xpath='//*[@id="user-name"]', driver=driver)
    input_password = wait_of_element_located(xpath='//*[@id="password"]', driver=driver)
    login_button = wait_of_element_located(xpath='//*[@id="login-button"]', driver=driver)

    # Действия с формами
    input_username.send_keys("standard_user")
    input_password.send_keys("secret_sauce")
    login_button.send_keys(Keys.RETURN)

    # Поиск и ождиание прогрузки ссылки элемента товара магазина и клик по ссылке
    item_name = wait_of_element_located(xpath='//*[@id="item_5_title_link"]/div', driver=driver)
    item_name.click()

    # Поиск и ожидание кнопки добавления товара и клик по этой кнопке
    item_add_button = wait_of_element_located(xpath='//*[@id="add-to-cart-sauce-labs-fleece-jacket"]', driver=driver)
    item_add_button.click()

    # Ждем пока товар добавится в корзину, появится span(кол-во позиций в корзине) и кликаем по корзине чтобы перейти
    wait_of_element_located(xpath='//*[@id="shopping_cart_container"]/a/span', driver=driver).click()

    # Еще один поиск ссылки элемента позиции магазина
    item_name = wait_of_element_located(xpath='//*[@id="item_5_title_link"]/div', driver=driver)
    if item_name.text == "Sauce Labs Fleece Jacket":
        print("Товар пристутствует в корзине")
    else:
        print("Товар отсутствует")

    time.sleep(5)


if __name__ == '__main__':
    test_add_jacket_to_the_shopcart()

    

Для запуска теста с помощью pytest в терминале введите
pytest main.py. После прохождения всех этапов должен отобразиться результат
прохождения.

6. Проверки, проверки, проверки

Мы плавно перешли к заключительному этапу написания теста – проверке вывода по известному ответу. Хотя тест выполняется успешно, он ничего
не проверяет и является бессмысленным. Будем использовать
стандартные инструкции assert или утверждения. Суть инструмента – проверить, что результат соответствует наши ожиданиям. Если соответствует, наш тест будет
считаться пройденным, а в противном случае – проваленным.

Добавим в тест проверки. Будем проверять, что название
куртки «Sauce Labs Fleece Jacket» и описание как в магазине.

main.py
        from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.by import By
from selenium.webdriver.support.wait import WebDriverWait

from selenium import webdriver
from selenium.webdriver.common.keys import Keys


# Функция ожидания элементов
def wait_of_element_located(xpath, driver):
    element = WebDriverWait(driver, 10).until(
        EC.presence_of_element_located(
            (By.XPATH, xpath)
        )
    )
    return element


def test_add_jacket_to_the_shopcart():
    options = webdriver.ChromeOptions()
    options.add_experimental_option("excludeSwitches", ["enable-logging"])
    driver = webdriver.Chrome(options=options, executable_path=r'C:/Users/…/…/chromedriver.exe')
    driver.get("https://www.saucedemo.com/")

    # Поиск и ожидание элементов и присваивание к переменным.
    input_username = wait_of_element_located(xpath='//*[@id="user-name"]', driver=driver)
    input_password = wait_of_element_located(xpath='//*[@id="password"]', driver=driver)
    login_button = wait_of_element_located(xpath='//*[@id="login-button"]', driver=driver)

    # Действия с формами
    input_username.send_keys("standard_user")
    input_password.send_keys("secret_sauce")
    login_button.send_keys(Keys.RETURN)

    # Поиск и ождиание прогрузки ссылки элемента товара магазина и клик по ссылке
    item_name = wait_of_element_located(xpath='//*[@id="item_5_title_link"]/div', driver=driver)
    item_name.click()

    # Поиск и ожидание кнопки добавления товара и клик по этой кнопке
    item_add_button = wait_of_element_located(xpath='//*[@id="add-to-cart-sauce-labs-fleece-jacket"]', driver=driver)
    item_add_button.click()

    # Ждем пока товар добавится в корзину, появится span(кол-во позиций в корзине) и кликаем по корзине чтобы перейти
    wait_of_element_located(xpath='//*[@id="shopping_cart_container"]/a/span', driver=driver).click()

    # Еще один поиск ссылки элемента позиции магазина
    item_name = wait_of_element_located(xpath='//*[@id="item_5_title_link"]/div', driver=driver)

    item_description = wait_of_element_located(
        xpath='//*[@id="cart_contents_container"]/div/div[1]/div[3]/div[2]/div[1]',
        driver=driver
    )

    assert item_name.text == "Sauce Labs Fleece Jacket"
    assert item_description.text == "It's not every day that you come across a midweight quarter-zip fleece jacket capable of handling everything from a relaxing day outdoors to a busy day at the office."

    driver.close()


if __name__ == '__main__':
    test_add_jacket_to_the_shopcart()

    

Теперь при расхождении результата и ожидаемого
условия будет возвращена ошибка прохождения. Укажем название куртки «Sauce Labs Fleece Jacket1». Результат выполнения скрипта будет следующим:

Рис 11. Результат выполнения теста.

Рис 11. Результат выполнения теста.

Теперь причешем код, распределив логику по
методам, как, например, было с wait_of_element_located. Разбивать логику необходимо
для написания множества тестов.

main.py
        import pytest
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.by import By
from selenium.webdriver.support.wait import WebDriverWait

from selenium import webdriver
from selenium.webdriver.common.keys import Keys


# Функция ожидания элементов
def wait_of_element_located(xpath, driver_init):
    element = WebDriverWait(driver_init, 10).until(
        EC.presence_of_element_located(
            (By.XPATH, xpath)
        )
    )
    return element


# Вынесем инициализцию драйвера в отдельную фикстуру pytest
@pytest.fixture
def driver_init():
    options = webdriver.ChromeOptions()
    options.add_experimental_option("excludeSwitches", ["enable-logging"])
    driver = webdriver.Chrome(options=options, executable_path=r'C:/Users/…/…/chromedriver.exe')
    driver.get("https://www.saucedemo.com/")
    yield driver
    driver.close()


# Вынесем аутентификацию юзера в отдельную функцию
def auth_user(user_name, password, driver_init):
    # Поиск и ожидание элементов и присваивание к переменным.
    input_username = wait_of_element_located(xpath='//*[@id="user-name"]', driver_init=driver_init)
    input_password = wait_of_element_located(xpath='//*[@id="password"]', driver_init=driver_init)
    login_button = wait_of_element_located(xpath='//*[@id="login-button"]', driver_init=driver_init)

    # Действия с формами
    input_username.send_keys(user_name)
    input_password.send_keys(password)
    login_button.send_keys(Keys.RETURN)



def add_item_to_cart(xpath_item, driver_init):
    # Поиск и ождиание прогрузки ссылки элемента товара магазина и клик по ссылке
    item_name = wait_of_element_located(
        xpath=xpath_item,
        driver_init=driver_init)
    item_name.click()

    # Поиск и ожидание кнопки добавления товара и клик по этой кнопке
    item_add_button = wait_of_element_located(
        xpath='//*[@id="add-to-cart-sauce-labs-fleece-jacket"]',
        driver_init=driver_init)
    item_add_button.click()

    # Ждем пока товар добавится в корзину, появится span(кол-во позиций в корзине)
    # Возвращаем True или False в зависимости добавлися товар или нет
    shop_cart_with_item = wait_of_element_located(
        xpath='//*[@id="shopping_cart_container"]/a/span',
        driver_init=driver_init)
    return shop_cart_with_item


def test_add_jacket_to_the_shopcart(driver_init):
    # Аутентификация пользователя
    auth_user("standard_user", "secret_sauce", driver_init=driver_init)

    # Добавление товара в корзину и если товар добавлен переход в корзину
    add_item_to_cart(xpath_item='//*[@id="item_5_title_link"]/div',
                     driver_init=driver_init).click()
    # Поиск корзины и клик
    wait_of_element_located(xpath='//*[@id="shopping_cart_container"]/a',
                            driver_init=driver_init).click()

    # Поиск ссылки элемента позиции магазина
    item_name = wait_of_element_located(xpath='//*[@id="item_5_title_link"]/div',
                                        driver_init=driver_init)

    # Поиск описания товара
    item_description = wait_of_element_located(xpath='//*[@id="cart_contents_container"]/div/div[1]/div[3]/div[2]/div[1]',
                                               driver_init=driver_init)

    assert item_name.text == "Sauce Labs Fleece Jacket"
    assert item_description.text == "It's not every day that you come across a midweight quarter-zip fleece jacket" 
                                    " capable of handling everything from a relaxing day outdoors to a busy day at " 
                                    "the office."


if __name__ == '__main__':
    test_add_jacket_to_the_shopcart(driver_init=driver_init)

    

В этом примере логика поделилась на функциональные компоненты (фикстуры). Теперь аутентификация пользователя будет происходить в отдельной функции, что позволит не производить одни и те же действия и дублировать код при каждом тесте, в котором нужно проходить аутентификацию. В качестве примера использования фикстур сделана инициализация драйвера, что позволит использовать инстанс драйвера во всех тестах, не пересоздавая его. Логика добавления товара в корзину тоже была вынесена в отдельный функциональный компонент для дальнейшего использования.

Суть разнесения логики заключается в принципе конструктора: собирать тесты из отдельных частей, подставляя только необходимые данные при переиспользовании функций в разных тестах.

При желании можно и дальше проводить рефакторинг кода.

Рекомендации по архитектуре

  • Очевидно, что в одном файле хранить все вспомогательные функции и тесты неудобно. После добавления еще нескольких тестов даже с распределенной логикой скрипт будет похож на полотно с трудночитаемым кодом. К тому же если вы разрабатываете тесты с коллегами, без конфликтов в коде не обойтись. Для начала нужно разделить проект на модули: в одном будут находиться файлы с тестами, в другом частичная логика, в третьем – ресурсы, в четвертом – утилиты и т.д.
  • Далее следует переходить на разработку автотестов с использованием объектно-ориентированного программирования. Это сэкономит массу времени и поможет в написании сложного и лаконичного кода.
  • Стоит также обратить внимание на паттерны проектирования, особенно на PageObject и PageFactoroy. В эффективном тестировании UI они играют большую роль.
  • Все тестовые данные лучше хранить в неизменяемых классах, константах или в отдельных файлах (json, csv).

Заключение

На этом создание первого автотеста закончено. Некоторые
моменты были рассмотрены поверхностно, что дает возможность пытливым умам
поглотить информацию из других источников. Удачи!

Выбор инструмента тестирования

Выбор средства тестирования во многом зависит от технологии, на которой построено тестируемое приложение. Например , QTP не поддерживает Informatica. Таким образом, QTP нельзя использовать для тестирования приложений Informatica . Хорошая идея – провести Proof of Concept of Tool (демонстрация практической осуществимости) на AUT.

Определяем объем автоматизации

Объем автоматизации – это область тестируемого приложения, которая будет автоматизирована. Его помогают определить следующие пункты:

  • Функции, важные для бизнеса
  • Сценарии с большим объемом данных
  • Общие функции приложений
  • Техническая осуществимость
  • Частота повторного использования бизнес-компонентов
  • Сложность тестовых случаев
  • Возможность использовать одни и те же тестовые сценарии для кросс-браузерного тестирования

Планирование, проектирование и разработка

На этом этапе вы создаете стратегию и план автоматизации, которые содержат следующие детали:

  • Выбранные инструменты автоматизации
  • Конструкция каркаса и его особенности
  • Входящие и выходящие за рамки элементы автоматизации
  • Подготовка стендов автоматизации
  • График и временная шкала сценариев и выполнения
  • Результаты тестирования автоматизации


Выполнение теста

На этом этапе выполняются сценарии автоматизации. Сценариям необходимо ввести тестовые данные, прежде чем они будут запущены. После выполнения они предоставляют подробные отчеты об испытаниях.

Выполнение может быть выполнено с использованием инструмента автоматизации напрямую или с помощью инструмента управления тестированием, который вызовет инструмент автоматизации.

Пример: Центр качества – это инструмент управления тестированием, который, в свою очередь, вызывает QTP для выполнения сценариев автоматизации. Скрипты могут выполняться на одной машине или на группе машин. Для экономии времени тестирование можно проводить ночью.

Обслуживание автоматизированного тестирования

Этот этап автоматизированного тестирования проводится для проверки того, как работают новые функции, добавленные в программное обеспечение: нормально или нет. Сопровождение в автотестировании выполняется, когда добавляются новые сценарии автоматизации, и их необходимо проверять и поддерживать, чтобы повышать эффективность сценариев автоматизации с каждым последующим циклом выпуска.

Платформа для автоматизации

Фреймворк – это набор руководств по автоматизации, которые:

  • поддерживают последовательность тестирования;
  • улучшают структурирование теста;
  • позволяют использовать минимальное количество кода;
  • уменьшают затраты на обслуживания кода;
  • повышают удобство повторного использования;
  • дают возможность нетехническим тестировщикам участвовать в кодировании тестов;
  • помогают сократить срок обучения использованию инструмента;
  • включают данные везде, где это необходимо.

Для автоматизации тестирования программного обеспечения используют четыре типа фреймворков:

  1. платформа автоматизации на основе данных;
  2. фреймворк автоматизации на основе ключевых слов;
  3. модульная платформа автоматизации;
  4. гибридная среда автоматизации.


Рекомендации для эффективной автоматизации тестирования


Чтобы получить максимальную рентабельность инвестиций в автоматизацию, соблюдайте следующие правила:

  • Объем автоматизации необходимо детально определить до начала проекта. Это позволит убедиться, что ожидания от автоматизации будут оправданы.
  • Определите правильный инструмент автоматизации: инструмент не должен выбираться на основании его популярности, он должен соответствовать требованиям автоматизации на конкретном проекте.
  • Выберите подходящий фреймворк.
  • Стандарты создания сценариев. При написании сценариев для автоматизации необходимо соблюдать стандарты. Вот некоторые из них:
    • cоздайте единые скрипты, комментарии и отступы кода;
    • разработайте правила наименования тестовых сценариев;
    • прикладывайте необходимые документы, если, например, сложно понять прохождение тестового сценария без скриншота и/или спецификации.
  • Определите метрики и следите за ними. Успех автоматизации нельзя определить лишь путем сравнения затраченных усилий, на тот или иной вид тестирования. Вот основные показатели:
    • процент обнаруженных дефектов;
    • время, необходимое для тестирования автоматизации выпуска каждого нового цикла;
    • минимальное время требуемое для выпуска;
    • индекс удовлетворенности клиентов;
    • улучшение производительности.

Приведенные выше рекомендации, если их соблюдать, позволят качественно выполнить автоматизацию тестирования.

Преимущества автоматизации тестирования

  • На 70% быстрее, чем при ручном тестировании.
  • Более широкий тестовый охват функций приложения.
  • Надежные в результаты.
  • Обеспечивает согласованность тестовых моделей.
  • Экономит время и деньги.
  • Повышает точность.
  • Позволяет исполнять процесс тестирования без вмешательства человека.
  • Повышает эффективность .
  • увеличивает скорость исполнения тестирования.
  • Повторно использует тестовые скрипты.
  • Позволяет тестировать часто и тщательно.
  • Больший цикл выполнения может быть достигнут за счет автоматизации.
  • Сокращает время выхода продукта на рынок


Типы автоматизированного тестирования

  • Смоук тестирование
  • Модульное тестирование
  • Интеграционное тестирование
  • Функциональное тестирование
  • Проверка ключевых слов
  • Регрессионное тестирование
  • Тестирование на основе данных
  • Тестирование черного ящика

Как выбрать инструмент автоматизации?

Выбор подходящего инструмента может оказаться сложной задачей. Следующие критерии помогут вам выбрать лучший инструмент для ваших требований:

  • поддержка окружающей среды;
  • легкость использования;
  • тестирование базы данных;
  • идентификация объекта;
  • тестирование изображений;
  • тестирование восстановления после ошибок;
  • отображение объектов;
  • используемый язык сценариев;
  • поддержка различных типов тестирования, в том числе функционального, тестового управления, мобильного и т. д.;
  • поддержка нескольких фреймворков тестирования;
  • легко отлаживать сценарии программного обеспечения автоматизации;
  • умение распознавать предметы в любой среде;
  • обширные отчеты об испытаниях и их результаты;
  • минимизация затрат на обучение выбранным инструментам.

Выбор инструмента – одна из самых серьезных проблем, которую необходимо решить, прежде чем приступать непосредственно к автоматизации. Во-первых, определите требования, изучите различные инструменты и их возможности, установите ожидания от инструмента и сделайте Proof Of Concept.

Инструменты автоматизации тестирования

На рынке доступно множество инструментов для функционального и регрессионного тестирования. В следующих выпусках расскажем в пользу чего делают выбор наши практикующие специалисты.

Ranorex StudioЭто универсальный инструмент для автоматизации функциональных тестов пользовательского интерфейса, регрессионных тестов, тестов на основе данных и многого другого. Ranorex Studio включает простой в использовании интерфейс для автоматизации тестирования веб-приложений, настольных и мобильных приложений.

Особенности:

  • Функциональный пользовательский интерфейс и сквозное тестирование на ПК, в Интернете и на мобильных устройствах
  • Кроссбраузерное тестирование
  • SAP, ERP, Delphi и унаследованные приложения.
  • iOS и Android
  • Запускайте тесты локально или удаленно, параллельно или распределяйте в Selenium Grid
  • Надежная отчетность

Testim

«Самый быстрый путь к отказоустойчивым сквозным тестам – без кода, с кодированием или и тем, и другим. Testim позволяет создавать удивительно стабильные тесты без кода, которые используют наш ИИ, а также гибкость для экспорта тестов в виде кода. Такие клиенты, как Microsoft, NetApp, Wix и JFrog, ежемесячно проводят миллионы тестов на Testim.

Особенности

  • Вы можете использовать современный JavaScript API от Testim и свою IDE для отладки, настройки или рефакторинга тестов.
  • Храните тесты в своей системе управления версиями, чтобы синхронизировать их с ветвями и запускать тесты при каждой фиксации.
  • Интеграция с популярными инструментами»


21 Labs

«Это сложная самообучающаяся платформа автоматизации тестирования и аналитики для приложений iOS и Android.

Особенности:

  • Быстрая и интеллектуальная разработка – создание с помощью ИИ дает пользователям возможность создавать автоматизированные функциональные тесты и тесты пользовательского интерфейса за считанные минуты.
  • Результаты, которым вы доверяете – бесшовная система алгоритмических локаторов обеспечивает стабильные результаты во всех средах.
  • Устранение проблем с обслуживанием и нестабильных результатов – самообучающееся обслуживание автоматически обновляет тесты и гарантирует, что ваша команда может сосредоточиться на разработке новых функций, полагаясь на результаты тестов.
  • Выпускайте с уверенностью – производственная интеграция закрывает цикл обратной связи и анализирует фактическое покрытие. Используйте данные при выпуске.
  • Полностью SaaS, не требует установки или устройств для создания или выполнения тестов. Предлагает беспрепятственный доступ к десяткам устройств».

Selenium Это инструмент тестирования программного обеспечения, используемый для регрессионного тестирования. Это инструмент тестирования с открытым исходным кодом, который предоставляет возможность воспроизведения и записи для регрессионного тестирования. Селен IDE поддерживает только Mozilla Firefox веб – браузер.

Особенности:

  • Он обеспечивает возможность экспорта записанного скрипта на других языках, таких как Java, Ruby, RSpec, Python, C# и т. д.
  • Его можно использовать с такими фреймворками, как JUnit и TestNG.
  • Он может выполнять несколько тестов одновременно
    Автозаполнение для общих команд Selenium
  • Пошаговые тесты
  • Идентифицирует элемент с помощью идентификатора, имени, X-пути и т. Д.
    Храните тесты как Ruby Script, HTML и любой другой формат
  • Он предоставляет возможность утверждать заголовок для каждой страницы
  • Он поддерживает файл selenium user-extensions.js
  • Это позволяет вставлять комментарии в середину скрипта для лучшего понимания и отладки.

QTP (MicroFocus UFT)

Широко используется для функционального и регрессионного тестирования, он касается всех основных программных приложений и сред. Чтобы упростить создание и обслуживание тестов, в нем используется концепция тестирования, управляемого ключевыми словами. Это позволяет тестировщику создавать тестовые примеры прямо из приложения.

Особенности:

  • Нетехническому человеку проще адаптироваться и создавать рабочие тестовые примеры.
  • Он быстрее устраняет дефекты, тщательно документируя и воспроизводя дефекты для разработчика.
  • Сверните создание тестов и документацию по тестам на одном сайте
  • Параметризация проще, чем в WinRunner
  • QTP поддерживает среду разработки .NET
  • У него лучший механизм идентификации объекта
  • Он может улучшить существующие сценарии QTP без доступности «Тестируемого приложения», используя активный экран.

Rational Functional Tester Это объектно-ориентированный инструмент автоматизированного функционального тестирования , способный выполнять автоматическое функциональное, регрессионное тестирование, тестирование на основе данных и тестирование графического интерфейса. Основные особенности этого инструмента:

Особенности:

  • Поддерживает широкий спектр протоколов и приложений, таких как Java, HTML, NET, Windows, SAP, Visual Basic и т. д.
  • Может записывать и воспроизводить действия по запросу
  • Он хорошо интегрируется с инструментами управления исходным кодом, такими как Rational Clear Case и Rational Team Concert.
    Он позволяет разработчикам создавать скрипт, связанный с ключевыми словами, чтобы его можно было использовать повторно.
    Редактор Eclipse Java Developer Toolkit
  • Помогает команде кодировать тестовые сценарии на Java с помощью Eclipse.
  • Поддерживает настраиваемые элементы управления через прокси SDK (Java / .Net)
  • Поддерживает управление версиями, чтобы обеспечить параллельную разработку тестовых сценариев и одновременное использование географически распределенной командой.

Watir

Это программное обеспечение с открытым исходным кодом для регрессионного тестирования. Это позволяет вам писать тесты, которые легко читать и поддерживать. Watir поддерживает только Internet Explorer в Windows, а веб-драйвер Watir поддерживает Chrome, Firefox, IE, Opera и т. д.

Особенности:

  • Он поддерживает несколько браузеров на разных платформах.
  • Вместо того, чтобы использовать собственный сценарий поставщика, он использует полнофункциональный современный язык сценариев Ruby.
  • Он поддерживает ваше веб-приложение независимо от того, на чем оно разработано.

SilkTestSilk Test предназначен для выполнения функционального и регрессионного тестирования. Для приложений электронного бизнеса шелковый тест является ведущим продуктом для функционального тестирования. Это продукт поглощения Segue Software компанией Borland в 2006 году. Это объектно-ориентированный язык, как и C ++. Он использует концепцию объекта, классов и наследования. Его основная особенность включает

Особенности:

  • Он состоит из всех файлов исходных скриптов.
  • Он преобразует команды сценария в команды графического интерфейса. На одном компьютере команды могут выполняться на удаленном или хост-компьютере.
  • Чтобы идентифицировать движение мыши вместе с нажатиями клавиш, можно запустить Silktest. Он может использовать как методы воспроизведения и записи, так и методы описательного программирования для получения диалогов.
  • Он определяет все элементы управления и окна тестируемого приложения как объекты и определяет все атрибуты и свойства каждого окна.

Заключение

Правильный выбор инструмента автоматизации, процесса тестирования и команда – основные составляющие успеха автоматизации. Для успешного тестирования ручные методы и автоматизация идут рука об руку.

Понравилась статья? Поделить с друзьями:
  • Мануал на фольксваген гольф плюс
  • Nice era flor инструкция на русском
  • Руководство dallas lock linux
  • Цистифлюкс инструкция по применению цена отзывы аналоги таблетки цена
  • Xspider руководство администратора