Предисловие Описанные ниже советы и рекомендации сформированы на основе опыта создания тестирования и автоматизации с нуля в двух компаниях и начала аналогичных работ в третьей.
Соответственно, на лавры всезнающего специалиста претензий нет; скорее, это попытка поделиться опытом, сформированная в виде пошагового руководства по трендовой в последнее время теме — автоматизации тестирования в компании.
Если вы решили это прочитать, то вам следует сразу принять во внимание, что теме создания автотестов на языке программирования и выбора инструментов для вашего конкретного проекта здесь будет уделено мало места в связи с невозможностью их унифицировать и дать вам строгую список того, какие проекты будут лучше для каких инструментов.
.
Здесь, конечно, придется покопаться самому.
А вот о том, как подойти к тестированию вообще, с чего начать, как продумать план тестирования и начать создавать тест-кейсы, как выбрать тесты для дальнейшей автоматизации, оценить время работы и нужна ли автоматизация вообще, речь пойдет ниже.
P.S.: И наконец, этот текст никогда бы не сформировался, если бы не полезные лекции Алексея Баранцева и Натальи Руколь, а также бездна информации, написанной добрыми людьми в последние годы на эту тему.
Вот и все, вас предупредили – можно начинать рассказ.
Часть 1. Развертывание автоматизации тестирования
1. Выбор стратегии автоматизации тестирования (далее АТ).
Существует несколько часто используемых вариантов стратегии AT. Порядок и интенсивность той или иной работы АТ зависит от выбора конкретной стратегии.
Выбор стратегии — не самая важная задача, но процесс внедрения автоматизации лучше всего начинать с нее.
Я приведу 3 варианта стратегий, типичных для самого начала внедрения автоматизации.
Конечно, вариантов стратегии больше; полный список можно найти на семинарах Натальи Руколь.
1.1 Стратегия «Давай попробуем» Используется в том случае, когда ни на проекте, ни в компании никогда не было АТ и планируется осторожный старт с умеренным распределением ресурсов.
Стратегию имеет смысл использовать, когда:
- Точных целей автоматизации (охват 40% кода конкретного модуля к определенной дате, снижение стоимости ручного тестирования и т. д.) нет.
- AT никогда раньше не использовался в проекте.
- У тестировщиков нет (или очень мало) опыта работы с AT.
- Выделенные ресурсы средние или низкие.
- Уделите больше внимания подготовительным этапам тестирования (составлению тест-планов, тест-кейсов и т. д.).
- Уделите больше внимания инструментам, которые можно использовать при ручном тестировании.
- Больше экспериментируйте с технологиями и методологиями AT. Никто не ожидает немедленных результатов, и вы можете экспериментировать.
- Работайте с проектом начиная с верхнего уровня, не углубляясь в автоматизации конкретных модулей на первых порах.
Стратегию имеет смысл использовать, когда:
- Когда предварительная работа над проектом уже проведена, есть некоторая предыстория в виде планов тестирования, тест-кейсов и, в оптимальном случае, автотестов предыдущего этапа АТ.
- Есть конкретная цель АТ (не глобальная - 80% автотестов за полгода, а 50% автотестов по конкретному модулю за месяц)
- Для достижения конкретной цели подбираются конкретные инструменты, оптимально, если специалисты имеют определенный технический опыт работы с инструментами.
- Прогрессивная стратегия, чем-то напоминающая методологии разработки Agile. Продвигаемся поэтапно.
Покрытие автотестами модуль за модулем, до полного выполнения мета-задач типа (80% за полгода).
- На каждом этапе ставится новая цель (скорее всего, продолжение последней выполненной цели, но не обязательно) и выбираются инструменты для реализации этой цели.
- Глубокая концентрация на конкретной цели, написание тест-кейсов, автотестов не на весь проект, а исключительно под конкретную задачу.
Оптимально, чтобы над автоматизацией постоянно работал человек, который особо не отвлекается на сторонние задачи.
Стратегию имеет смысл использовать, когда:
- Конкретных целей нет, есть лишь общее пожелание «чтобы все было хорошо».
Если «Вот цель» напоминает принцип работы Agile, то эта стратегия по духу близка к методологии «Водопад».
- Есть ресурс в виде как минимум одного человека, постоянно работающего над проектом, вплотную занятого задачей автоматизации.
- Четко выраженных целей АТ нет, но есть пожелания (приоритеты), которые можно расставить на достаточно длительный период времени (эти модули важнее тех, которые традиционно имеют больше ошибок в бэкенде/фронтенде, поэтому следует прилагать больше усилий).
направлено на это).
- Идея стратегии описана выше, постоянная и методичная работа с учетом поставленных приоритетов.
- В начале нужно сосредоточиться на базовой части, так как так или иначе в рамках этой стратегии автоматизируется весь проект, без полной фокусировки на конкретных модулях.
тесты и глубокая специфика модулей.
По завершению этого этапа у нас будет готовая основа для дальнейшей работы.
А дальше нужно выбрать, как будет удобно работать дальше — грубо говоря, водопад или Agile. И продолжать действовать в соответствии с выбранной стратегией.
2. Распараллеливание задач
Этот момент имеет смысл, если над тестированием проекта работают или будут работать несколько человек.Тогда возникает существенный момент распараллеливания задач в команде.
Если в вашей команде над AT работает всего один человек, можете смело пропустить этот пункт. С точки зрения компетенций и связанных с ними знаний процесс автоматизации тестирования можно разделить на роли, инкапсулирующие различные однотипные задачи.
Роли Архитектура
- Выбор инструментов
- Выбор подходов
- Разработка и отладка тестов
- Поддержка, обновление
- Исправление ошибки
- Выбор теста
- Тестовый дизайн
- Проектирование тестовых данных
- Планирование
- Сбор метрик
- Образование
- Локализация ошибок
- Ошибаясь
- Подготовка тестовых данных
В этом случае имеет смысл назначить роль «Управление» одному человеку, разделить на всех роли «Тестовый дизайн» и «Тестирование», а на одного-двух героев роли «Архитектура» и «Разработка».
Логика этого заключается в следующем.
- У этого проекта есть четкий менеджер по тестированию, который планирует, определяет сроки и несет ответственность в случае их несоблюдения.
- Существует два основных типа тестировщиков — ручные тестеры и автоматизированные тестеры.
При этом задачи ролей «Дизайн Тестирования» и «Тестирование» одинаково актуальны для обоих типов.
Соответственно, все тестировщики пишут и разрабатывают тесты, которые впоследствии можно использовать как при ручном тестировании, так и при автоматизации.
- Далее ручные тестировщики проводят ручное тестирование на основе созданных тест-планов и тест-кейсов, а специалисты по автоматизации доводят необходимые тесты до формы, удобной для разработки, и занимаются автоматизацией.
3. Создание плана тестирования
После выбора АТ-стратегии следующим важным моментом станет отправная точка работы — создание плана тестирования.План тестирования необходимо согласовывать с разработчиками и менеджерами продукта, так как ошибки на этапе создания плана тестирования могут аукнуться вам гораздо позже.
По-хорошему, план тестирования должен быть составлен для любого относительно крупного проекта, над которым работают тестировщики.
Я описываю менее формализованный план тестирования, чем тот вариант, который обычно используется в крупных офисах, но для внутреннего использования нет необходимости в большом количестве формальностей.
План испытаний состоит из следующих пунктов: 3.1 Объект испытаний.
Краткое описание проекта, основные характеристики (веб/десктоп, пользовательский интерфейс на iOS, Android, работает в конкретных браузерах/операционных системах и т. д.).
3.2 Состав проекта.
Логически разбитый список отдельных компонентов и модулей проекта, изолированных друг от друга (с возможной декомпозицией, но без детализации), а также функций вне крупных модулей.
В каждом модуле перечислите набор доступных функций (не вдаваясь в подробности).
Менеджер и тест-дизайнер будут использовать этот список как отправную точку при определении задач по тестированию и автоматизации для нового спринта (например: «внесены изменения в модуль редактирования данных, затронут модуль загрузки файлов, функция отправки уведомлений».
в клиенте был полностью переработан»).
3.3 Стратегия тестирования и планируемые виды тестирования на проекте.
Стратегии описаны в пункте 1. В случае автоматизации обычно используется только один вид тестирования — регрессионное (глубокое тестирование всего приложения, запуск ранее созданных тестов).
По большому счету автотесты можно использовать и в других видах тестирования, но пока они не достигнут хотя бы 40% охвата, принципиальной пользы от этого не будет. Однако если план тестирования планируется использовать не только специалистами по автоматизации, но и ручными тестировщиками, то вам необходимо продумать всю стратегию тестирования (не автоматизации), выбрать или отметить виды используемого/необходимого тестирования и написать ее.
вниз и в этот момент. 3.4 Последовательность испытательных работ. Как будет проходить подготовка к тестированию, оценка сроков выполнения заданий, сбор и анализ статистики тестирования.
Если вы понятия не имеете, что написать в этом пункте, можете смело его пропустить.
3.5 Критерии завершения теста Кратко опишите, когда тестирование данного выпуска считается завершенным.
Если есть какие-то конкретные критерии, опишите их.
Обобщить: Обязательно нужно написать план тестирования; без него вся дальнейшая автоматизация будет хаотичной и бессистемной.
Если при ручном тестировании (при очень плохом ручном тестировании) можно обойтись без плана тестирования, тест-кейсов и с относительным успехом использовать мок-тестеры, то в автоматизации это не сработает.
4. Определение основных целей
После выбора стратегии и составления плана тестирования стоит выбрать набор задач, с которых начать автоматизацию тестирования.Наиболее распространенные типы задач, которые ставятся перед автоматизацией:
- Полная автоматизация приемочного тестирования (Smoke-тестирование) — вид тестирования, проводимый отделом тестирования в первую очередь после получения сборки.
В рамках дымового тестирования тестируется тот функционал, который должен работать всегда и при любых условиях, и если он не работает, по согласованию с разработчиками считается, что сборка не может быть принята на тестирование.
- Максимизация количества обнаруженных дефектов.
В этом случае необходимо сначала выбрать те модули (или аспекты функциональности) системы, которые чаще всего подвергаются изменениям в логике работы, а затем выбрать наиболее рутинные тесты (то есть тесты, где повторяются одни и те же шаги с небольшими вариациями).
выполняются с большим объемом данных).
- Минимизация «человеческого фактора» при ручном тестировании.
Далее снова выбираются самые рутинные тесты, те, которые требуют наибольшего внимания со стороны тестировщика (при этом они легко автоматизируются).
Например, тестирование пользовательского интерфейса (например, проверка названий 60 столбцов в таблице), проверка содержимого поля со списком со 123 элементами, проверка экспорта таблицы на веб-страницу в Excel и т.д.
- Обнаружение большинства системных сбоев.
Здесь можно использовать «случайные» тесты.
При этом решение проблемы позволит запустить приемочное тестирование на следующей принятой сборке.
Главным критерием дымовых тестов должна быть их относительная простота и в то же время обязательная проверка критической функциональности проекта.
Также предполагается, что дымовые тесты будут положительными (проверка корректности поведения системы, а отрицательные тесты проверят, будет ли система работать некорректно), чтобы не тратить время на ненужные проверки.
Обобщить: При составлении списка первоочередных задач для автоматизации логично было бы первым описать и автоматизировать дымовые тесты.
В дальнейшем их можно будет включить в проект и запускать при каждой сборке.
Из-за их ограниченного количества запуск этих тестов не должен особенно замедлять сборку, но каждый раз вы сможете точно знать, работают ли еще критические функции.
5. Написание тест-кейсов для выбранных задач
Что касается тест-кейсов, то процесс тестирования принято делить на две части: тестирование с использованием готовых сценариев (тест-кейсов) и исследовательское тестирование.Что касается исследовательского тестирования, то здесь все совершенно ясно; он существует в двух вариациях: либо исследование нового функционала без особой предварительной подготовки, либо в виде банального макетного тестирования обезьянами-тестировщиками.
Тестирование по сценариям подразумевает, что потрачено время и созданы сценарии тестирования, исходя из функциональности проекта, охватывающие как можно большую его область.
Наиболее разумным, с моей точки зрения, является разумное сочетание подходов, при котором новые функции и модули тестируются в исследовательском стиле, пытаясь протестировать возможные и маловероятные сценарии, а по завершении тестирования создаются тест-кейсы, которые впоследствии используются для регрессионного тестирования.
Три варианта дальнейшего использования тест-кейсов, помимо очевидного:
- Создавайте чек-листы для модулей проекта из тест-кейсов, это ускорит проверку, но будут проверены основные проблемные места.
- Обучение новичков — пришедший на проект тестировщик может изучить проект с точки зрения тест-кейсов, поскольку они фиксируют многие неочевидные аспекты приложения.
- Дальнейшее использование как основа для автотестов.
Если при развертывании АТ используется системный подход, то написание и дальнейшее использование тест-кейсов вполне логично — по сути, тест-кейс — это готовый скрипт автотестирования.
Хороший тестовый пример состоит из следующих пунктов:
- Название (Описание) — очень краткое описание того, что тестирует тест.
- Предварительное состояние системы — это описание состояния системы, в котором она должна находиться на момент начала выполнения тестового примера.
- Последовательность шагов – последовательно описанные действия, подтверждающие заявленную в Заголовке цель.
- Ожидаемый результат — это состояние системы, которое мы ожидаем после прохождения последовательности шагов тестового примера.
тестовых случаев.
Обобщить: Для дальнейшего АТ необходимо написать тест-кейсы для задач, поставленных на шаге 4. Они одновременно послужат началом создания нормального регрессионного тестирования и послужат основой для дальнейших автоматизированных тестов.
В качестве рекомендации тестировщику, планирующему писать тестовые примеры, я рекомендую прочитать о парной технике, классах эквивалентности и методах проектирования тестов.
Изучив эти темы хотя бы поверхностно, писать хорошие и полезные тест-кейсы станет гораздо проще.
6. Выбор инструментов для автоматизации
Очевидно, что инструменты для АТ выбираются в зависимости от платформы, на которой работает приложение.Приведу пример выбора инструментов для проекта, состоящего из двух частей — Backend на AngularJS и Frontend — клиента для планшетов и телефонов на базе iOS. 1.Бэкэнд Карма+Транспортир(Жасмин).
Плюсы: я рекомендую использовать инструмент «Транспортир» в качестве оболочки; он идеально подходит для приложений, написанных на AngularJS. Protractor имитирует взаимодействие пользователя и позволяет создавать автотесты, созданные с использованием BDD-фреймворка Jasmine. Что ж, Karma позволяет запускать эти тесты в разных браузерах.
Минусы: Тестировщик должен уметь писать хотя бы простые скрипты на JS. Либо программист должен за него написать эти скрипты, что с развитием АТ может стать дорогим.
Селеновый веб-драйвер.
Плюсы: Удобные, простые и надежные инструменты для автоматизации тестирования веб-приложений с графическим интерфейсом.
Много документации, много примеров, в общем — удобно.
В самом примитивном варианте он не требует от тестировщика никаких знаний программирования.
Минусы: Protractor написан командой AngularJS для тестирования AngularJS, а Selenium является универсальным.
С моей точки зрения, писать тесты для Protractor+Jasmine на проекте AngularJS будет удобнее.
Если планируется серьезное автотестирование, а не просто помощь ручным тестировщикам, то тестировщику все равно потребуется знание языка программирования (java, python, Ruby, C#), так как гибкая настройка тестирования требует знаний программирования.
2.Фронтенд Калабаш+Огурец.
По большому счету, наиболее удобным инструментом для автоматизации iOS-приложений на планшетах и телефонах является комбинация Calabash + Cucumber. Calabash — это фреймворк для автоматизации функционального тестирования, который по сути представляет собой драйвер, управляющий работой приложения на устройстве или симуляторе.
Cucumber предоставляет инфраструктуру тестирования (запуск тестов, анализ сценариев, создание отчетов).
Стоит учитывать, что Calabash — платное решение ( https://xamarin.com/test-cloud ).
Обобщить: Инструменты для автоматизации тестирования описаны выше, однако это далеко не единственные доступные инструменты, и я бы рекомендовал всем, кто настраивает всю эту инфраструктуру и разворачивает АТ в компании, вдумчиво покопаться в сети; возможно, появится что-то новое и более удобное, чем те инструменты, которые я выбрал.
7. Выбор тестов для автоматизации
Итак, на текущем этапе мы создали план тестирования и описали часть функционала модулей как тест-кейсы.Следующей задачей будет выбор необходимых тестов из доступного множества тест-кейсов.
Сейчас у вас есть только подготовленные тест-кейсы для дымового тестирования, но после нескольких итераций разработки тест-кейсов в проекте станет значительно больше, и не все из них имеет смысл автоматизировать.
1. Очень сложно автоматизировать следующие вещи:
- Проверка открытия файла в сторонней программе (например, проверка корректности отправленного на печать документа)
- Проверка содержимого изображения (есть программы, которые могут частично решить эту проблему, но в простых задачах такие тесты лучше не автоматизировать, а оставить для ручного тестирования)
- Проверки, связанные с ajax-скриптами (эту проблему решить проще, в разных приложениях есть свои решения, но в целом ajax автоматизировать гораздо сложнее).
Как показывает практика, для тестирования одной функции может потребоваться несколько тест-кейсов (например, у нас есть поле ввода, в которое можно ввести любое двузначное число.
Его можно проверить 1-2 тестами, «2 символа», «1».
Если проверять более щепетильно - то добавить тест на отсутствие значения, нуля, граничного значения и отрицательный тест с вводом символов).
Преимущество автоматизированных тестов перед ручным тестированием в данном случае как раз и заключается в том, что если у нас есть один тест, проверяющий введенные в поле данные, мы легко можем увеличить их количество, изменив входные параметры.
По большому счету, автотесты должны охватывать самую утомительную и монотонную часть тестирования, оставляя тестировщикам место для исследовательского тестирования.
Соответственно, при выборе тест-кейсов для автоматизации это тоже следует учитывать.
3. Простота тестов.
И последний важный критерий выбора тест-кейсов для автоматизации — относительная простота тестов.
Чем разнообразнее шаги в тесте, тем хуже сам тест-кейс, тем сложнее его будет автоматизировать и тем сложнее будет найти ошибку, если этот автотест завершится неудачно при запуске.
Старайтесь выбирать небольшие тест-кейсы для автоматизации, постепенно набираясь опыта и автоматизируя все более сложные тест-кейсы, пока не решите, какая длина теста оптимальна для вас.
8. Разработка тестов для автоматизации Отобранные для автоматизации тест-кейсы, скорее всего, придется дополнять и корректировать, так как тест-кейсы, как правило, пишутся простым человеческим языком, а тест-кейсы для дальнейшей автоматизации необходимо дополнять необходимыми техническими деталями для удобства перевода в код. (со временем вы поймете, какие тесты нужно описывать живым языком, а какие подробно и понятно на этапе создания тест-кейсов).
Соответственно, можно сформулировать следующие рекомендации по содержанию тест-кейсов, предназначенных для автоматизации: 1. Ожидаемый результат в автоматизированных тестовых примерах должен быть описан очень четко и конкретно.
- Плохо: Результат — открывается страница Формы.
- Хорошо: Результат - открывается страница Формы, на странице есть форма поиска.
, есть элемент css=div.presentations_thumbnail_box и link=Notes.
Допустим, тест говорит, что нажмите на ссылку, и следующий шаг действия будет на новой странице.
В этом случае страница может долго загружаться, и приложение, не дождавшись загрузки необходимого элемента для запуска, вылетит с ошибкой.
Эту проблему часто можно легко решить, установив параметр ожидания загрузки элемента.
- Плохо: Нажмите на ссылку «Формы» в верхнем меню.
Подтвердите внесенные изменения.
- Хорошо: нажмите ссылку «Формы» в верхнем меню.
Дождитесь формы с текстом «Хотите сохранить измененияЭ» появиться.
Нажмите кнопку «ОК».
Только если в этом нет необходимости.
В большинстве случаев при создании тестовой среды определяются подходящие данные, поэтому оптимально выбирать значения при создании автотеста.
- Плохо: открыть слайд «слайд 1_11».
- Хорошо: первый слайд презентации открыт.
Из любого правила есть исключения, но в подавляющем большинстве случаев следует исходить из того, что мы не знаем, какие тестовые примеры будут выполняться до и после нашего тестового примера.
- Плохо: Из файла, созданного в ходе предыдущего теста.
Таким образом вы сможете избежать ситуации, когда из-за неправильно выбранной команды тест-кейс становится ложноположительным, т.е.
успешно проходит ситуацию, когда приложение работает некорректно.
Обобщить: Правильно написанный тест-кейс, предназначенный для автоматизации, будет гораздо больше похож на миниатюрное техническое задание на разработку небольшой программы, чем на удобочитаемое описание правильного поведения тестируемого приложения.
Ниже я укажу несколько тест-кейсов, переработанных для автоматизации.
Остальное, думаю, может переделать сам тестер проекта по описанным выше правилам.
9. Настройка стека приложений для автоматизации
Следующим шагом (или параллельной задачей в случае работы нескольких специалистов) станет развертывание стека приложений, которые мы будем использовать в дальнейшей работе по созданию и запуску автотестов.Подробно описывать те или иные варианты установки я не буду, вся информация есть в интернете, к каждому варианту приложу 1-2 ссылки для начала поиска решения.
Бэкэнд 1. Карма+Транспортир(Жасмин) — Карма + Транспортир — Отличное руководство по развертыванию инструментов — mherman.org/blog/2015/04/09/testing-angularjs-with-protractor-and-karma-part-1/#.
VpY21vmLSUk — Транспортир + Жасмин — Установка и настройка Жасмин Engineering.wingify.com/posts/e2e-testing-with-webdriverjs-jasmine Если вы выберете эту схему, для автоматического запуска тестов потребуется «подружить» с Кармой и одной из систем непрерывной интеграции.
Предлагаю два варианта, которые показались мне наиболее интересными — Jenkins и Teamcity. — Teamcity — Решение довольно простое, заключается в установке плагина карма-бегун-репортер ; - Jenkins - Аналогично - простое решение, установка плагина Карма-Дженкинс-репортер .
2. Селеновый веб-драйвер Само решение не очень элегантное, но оно описано выше.
Если вы все же решили пойти простым путем, то просто введите: — Селен IDE ; — Принципы работы с Selenium Webdriver в случае, если тестов, полученных из IDE, явно недостаточно.
После установки инструментов остается только запустить их в системе непрерывной интеграции.
И снова предлагаю два самых (на мой взгляд) удобных варианта — Teamcity и Jenkins. — Teamcity — переводим тесты из IDE в тесты на языке (C#, Java, Python, Ruby) и настраиваем их запуск в Teamcity. Одним из решений является в статье .
- Дженкинс (скажу прямо - труднее ).
Внешний интерфейс 1. Калабаш+Огурец — Первый вариант установки; — Второй вариант установки; Далее наступает самое интересное — заставить Calabash работать совместно с системой непрерывной интеграции.
— Teamcity — наверное, лучший вариант, который я видел, описано здесь .
— Дженкинс тоже совсем не простой, как вариант для начала .
Обобщить: И опять же, специфика настройки средств автоматизации — это тема совсем другой статьи — я привел пример того, как настроить стек приложений, выбранный под конкретное решение.
И, если общие методики тестирования достаточно стабильны, то выбор конкретного приложения и языка автоматизации — задача, полностью зависящая от специфики вашего проекта.
10. Подготовка тестовых данных
В этом контексте тестовые данные означают состояние приложения на момент начала тестов.Учитывая, что значения и параметры, используемые в автотестах, почти всегда «жестко запрограммированы» и очень редко являются гибкими, логичным выводом было бы предположить, что они вряд ли смогут выполниться в любом состоянии приложения.
Например, маловероятно, что вы запустите автотест, проверяющий редактирование общих статей в производственной системе, где эти статьи видят клиенты, или в полностью чистой системе, где статей для редактирования просто нет. В первом случае автотест может добавить ненужное раздувание; во втором его просто невозможно выполнить.
Соответственно, чтобы правильно использовать автотесты, необходимо сначала привести приложение в состояние, соответствующее этим тестам.
Особых правил здесь нет, все интуитивно понятно на основе тестов, единственное замечание — автотесты обычно запускаются как изолированные наборы независимых тестов.
При этом тесты одного набора часто запускаются в случайном порядке.
Соответственно, при написании автотестов старайтесь писать их так, чтобы по завершении одного теста еще можно было выполнить любой другой тест из набора.
- Плохо — тест обращается к изначально подготовленному файлу и удаляет его в процессе работы.
Следующий тест также должен получить доступ к уже удаленному файлу.
Возникает ошибка.
- Хорошо — тест, удаляющий файл, либо создаёт его в начале своей работы, либо создаёт в конце своей работы.
Таким образом, файл существует до начала теста и после его завершения.
11. Разработка и запуск автотестов
Пожалуй, это будет самая короткая глава из всех — о том, как писать автотесты, имея готовый шаблон на человеческом языке и развернутый стек инструментов — подробно описано по следующим ссылкам:- Транспортир + Жасмин - angular.github.io/protractor/#/tutorial
- Селен IDE - forworktests.blogspot.ru/2013/03/selenium.html
- Селен веб-драйвер — www.seleniumhq.org/docs/03_webdriver.jsp
- Калабаш - habrahabr.ru/post/219655
Удачи!
Подведение итогов 11 глав руководства
Выполнив все описанное Теги: #автоматизация качества #тестирование программного обеспечения #автоматизация тестирования #тестирование ИТ-систем #Тестирование веб-сервисов #Тестирование мобильных приложений-
Арон, Реймон
19 Oct, 24 -
Концепция Коворкинг-Центра
19 Oct, 24 -
Myspace Запускается В Японии
19 Oct, 24
