Назад | Содержание | Дальше |
В этой главе мы обратимся к вопросам, с которых обычно начинается автоматизация тестирования. Выбор инструмента и его изучение, создание команды, организация кода – все эти вопросы очень важны, так как от них зависит, будет ли автоматизация тестирования в вашей компании успешной или нет. Кроме того, на данном этапе вам, возможно, также покажутся интересными глава 5 и главы 6.1-6.2.
Так как эта книга посвящена автоматизированному тестированию, мы практически не затрагиваем вопросы организации тестирования. Например, в этой главе предполагается, что вы точно знаете, что именно вы будете автоматизировать (т.е. у вас есть usecase’ы или testcase’ы, план тестирования и т.п.).
1.1 Команда, или «кто должен заниматься автоматизацией?»
Зачастую автоматизация тестирования в компании внедряется следующим образом. Команда тестировщиков не справляется с объемами работ и принимается решение о внедрении автоматизации для облегчения (или даже замены!) ручного тестирования. Эта задача возлагается на кого-то из тестировщиков, который подбирает инструмент, записывает скрипты с помощью средств записи, а через неделю выясняется, что скрипты работают неправильно, так как в приложение были внесены изменения. Скрипты записываются заново (что не было запланировано), потом эта ситуация повторяется несколько раз, на перезаписывание не хватает времени, и в итоге команда решает, что автоматизация слишком накладна и не решает задач, которые хотели решить с её помощью.
Этот подход может быть неправильным по нескольким причинам. Во-первых, тестировщики не всегда знакомы с программированием, а автоматизация – это написание кода, и чем код лучше, тем проще его поддерживать. Во-вторых, инструмент мог быть выбран неудачно для данного проекта. В-третьих, начальные ожидания от автоматизации могли быть попросту завышены. Таких причин может быть очень много.
Вот несколько советов по тому, какими навыками должны обладать автотестеры:
- Умение программировать – обязательно! Автоматизация – это написание кода, а это значит, что придется сталкиваться как с процедурным, так и с объектно-ориентированным программированием, заниматься рефакторингом, разбирать чужой код и многое другое.
- Понимание процесса тестирования. Вы должны понимать, что именно вы автоматизируете, и делать это нужно правильно и эффективно. Например, нет смысла автоматизировать функциональность, которой пользуется 1% пользователей, когда не автоматизированы другие части приложения, которыми пользуются 90% пользователей.
- Общее понимание разработки ПО и различных особенностей операционной системы. Занимаясь автоматизацией, вам вполне возможно придется сталкиваться с такими задачами, как работа с базами данных, вызовы системных функций, взаимодействие с другими приложениями и т.п. Естественно, для того, чтобы воспользоваться этими возможностями, необходимо иметь хотя бы общее представление о том, как это всё работает.
В целом можно сказать, что порог вхождения (т.е. набор навыков, необходимых для работы) в автоматизации тестирования выше, чем в ручном тестировании, но ниже, чем в программировании.
В случае, когда автоматизацией тестирования занимается несколько человек, лучше чтобы в команде были 1-2 автоматизатора или программиста уровня Senior для осуществления общего контроля, принятия решений, помощи новичкам и т.п. Кроме того, количество молодых специалистов не должно превышать количество опытных автоматизаторов, чтобы последним не приходилось тратить всё время на обучение и консультации.
С другой стороны, не стоит привлекать программистов к автоматизации тестирования:
- Во-первых, не всем программистам это нравится и в результате они попросту переходят работать в другие компании.
- Во-вторых, программисты обычно пишут автотесты на уровне кода (unit тесты) и нет смысла загружать их дополнительной работой.
- В-третьих, взгляд на программу с точки зрения программиста отличается от точки зрения тестировщика, а потому тесты могут оказаться менее качественными, чем тесты, написанные тестировщиком.
На первых порах также имеет смысл пригласить стороннего консультанта, который поможет с обучением, выбором инструмента, подходами и т.п. Почему-то этот подход не очень распространён в странах бывшего СССР, наши компании предпочитают иметь в штате постоянного сотрудника. Это не всегда является оптимальным выбором, так как для перекупки специалиста такого уровня потребуются довольно большие финансовые затраты, а как консультант такой человек может оказаться незаменимым.
1.2 Когда начинать автоматизацию?
Автоматизацию тестирования лучше начинать как можно раньше, чтобы с ростом приложения постоянно росло количество автотестов.
Однако автоматизировать стоит лишь стабильную функциональность, которая была протестирована вручную и одобрена заказчиком, когда известно, что кардинально эта часть приложения меняться в ближайшем будущем не будет. Иначе можно столкнуться с несколькими проблемами:
- Заказчик окажется недоволен и часть приложения будет сильно переделана. В этом случае придётся полностью переделывать и автоматические скрипты, тестирующие эту часть приложения.
- Если функциональность не была протестирована вручную, в автоматических скриптах мы рискуем делать проверки неправильного поведения программы (например, проверка появления неверного значения при расчетах), что в принципе недопустимо.
- В случае, если некоторая функциональность сделана не полностью, мы можем написать неполные скрипты, пропустив часть проверок. При этом либо придется время от времени возвращаться к уже написанному коду (что неудобно, так как постоянно появляются новые и новые задачи и придётся переключаться между старыми и новыми тестами), либо мы можем просто забыть, что часть проверок в этом месте приложения у нас не сделана, что чревато появлением ошибок, которые не будут отловлены.
Конечно, существует и другой подход. Можно разрабатывать тестовые скрипты одновременно или даже до того, как будет написан код приложения. Однако при этом программистам приходится более формально подходить к написанию кода (использовать строгие соглашения об именовании элементов управления и переменных) и в целом такой подход требует больше времени, чем написание тестов для уже готового функционала.
1.3 Выбор инструмента
Более подробно о выборе инструмента мы поговорим в Части 3 этой книги, сейчас же дадим общие указания и направление.
Прежде всего необходимо понять, что ни один инструмент автоматизации тестирования не удовлетворит ваших нужд на 100%. Это происходит потому, что проектов существует огромное количество и у каждого есть какие-то свои особенности. Производители ПО для автоматизации просто не смогут реализовать все пожелания всех пользователей, да еще и именно в том виде, в каком хочет каждый из них. Поэтому мы говорим о наиболее подходящем инструменте для вашей ситуации.
При выборе инструмента необходимо прежде всего поискать в интернете или спросить на подходящих форумах те, которые, как вам кажется, могут вам подойти. Каждый такой инструмент вы устанавливаете и пробуете с ним работать в течение какого-то времени (неделя, месяц — в зависимости от того, сколько инструментов вы подобрали и сколько времени у вас есть на изучение и выбор).
Вот некоторые параметры, которые стоит учитывать при выборе инструмента:
- Цена. Не всегда лучший инструмент стоит дорого, а бесплатный — вовсе не означает «худший». Сейчас есть большое количество инструментов, и среди бесплатных встречаются в том числе лидеры (например, Selenium – лидер среди средств тестирования веб-приложений).
- Поддерживаемые технологии. Если в вашей компании несколько отделов, в каждом из которых разрабатываются приложения под разные платформы (например, .NET, Java и PHP), и при этом вы хотите разрабатывать общий фреймворк для всех этих проектов, то инструмент должен поддерживать все технологии. Другой подход — использование в каждом проекте отдельного инструмента, со своими библиотеками и подходами.
- Удобство использования. Об этом можно судить по отзывам других пользователей и по своему опыту.
- Актуальность инструмента. Если программа, которую вы выбрали, давно не обновлялась, вполне возможно, что её разработка остановлена (либо будет остановлена в будущем). Это можно узнать у производителей или по отзывам на различных независимых форумах. Нет смысла начинать использовать инструмент, если через полгода его поддержка будет остановлена (особенно если инструмент коммерческий и вы не имеете доступа к его исходным кодам).
- Скорость изучения и понимания. Насколько хорошо организована в программе справочная система, есть ли курс «Для начинающих», является ли он интуитивно понятным и т.п. Если для понимания элементарных вещей вам приходится изучать исходный код и нет никакой справочной системы — в будущем вам придётся туго.
Это далеко не полный список того, на что стоит обращать внимание. Вы можете дополнить его в соответствии с особенностями вашего проекта и подбирать инструмент в соответствии с составленным списком.
1.4 Изучение инструмента (пилотный проект)
Как только вы выбрали один или несколько инструментов, которые кажутся вам подходящими, не торопитесь сразу же пускать его «в дело» и стартовать написание рабочих скриптов. Прежде всего необходимо ознакомиться с инструментом и попробовать его в деле (в конце концов для этого и существуют оценочные версии (evaluation version).
Для этих целей создают так называемый «пилотный» (пробный) проект. Его цель — создать простой проект, который будет тестировать небольшой кусок приложения. После этого у вас сложится определенное впечатление о продукте, который вы собираетесь использовать.
Обратите внимание на несколько важных моментов:
- Всегда есть вероятность того, что в результате написания пилотного проекта вы поймете, что данный инструмент вам не подходит. С одной стороны — не стоит принимать скоропалительных выводов через 2 часа использования и отказываться от инструмента. С другой — не стоит игнорировать проблемы, с которыми вы сталкиваетесь в пилотном проекте, так как эти проблемы в дальнейшем будут возникать во время работы. В этом нет ничего плохого, для этого пилотный проект и предназначен. Лучше обнаружить это раньше, чем через полгода после покупки инструмента.
- Код из пилотного проекта необязательно затем использовать в реальном проекте. Вполне вероятно, что после окончания пилотного проекта у вас будет совершенно другое видение того, как нужно подходить к автоматизации с использованием этого инструмента. Это вполне нормально. Весьма вероятно, что по окончании опробования вы просто удалите пилотный проект и реальный проект начнёте разрабатывать «с нуля». Задача на этом этапе — попробовать и принять решение об использовании.
- Выбор того, что автоматизировать в пилотном проекте. Так как на пилотный проект отводится сравнительно немного времени, необходимо тщательно подобрать сценарии, которые вы хотите автоматизировать. Они не должны быть ни сильно простыми, ни сильно сложными, чтобы с одной стороны не пропустить какие-то важные особенности, а с другой стороны — не зависнуть сильно на трудных задачах. Например, хорошо подойдет для автоматизации часть smoke-теста. Если в тестируемом приложении встречаются сложные элементы управления (таблицы, комбинированные списки, деревья и т.п.), стоит поработать с каждым из них хотя бы поверхностно, чтобы определить, может ли инструмент автоматизации работать с такими элементами вообще. Если не умеет — следует выяснить, есть ли возможность самому написать код для работы с такими элементами (например, в случае кастомных .NET элементов инструмент может предоставлять доступ к внутренним свойствам и методам элементов, с помощью чего можно написать свои функции для работы с ними).
- Не стоит сильно затягивать пилотный проект. Также не стоит углубляться в решение какой-то одной задачи, отставляя в сторону остальные, или начинать создавать многофункциональный фреймворк. Все эти задачи — не для пилотного проекта.
В результате двух последних активностей: выбор инструмента и создание пилотного проекта (или нескольких проектов), вы должны принять решение о том, какой инструмент будете использовать и начинать его серьёзное изучение.
На этапе изучения инструмента часто используется метод Record & Play, если таковой имеется в приложении для автоматизации, когда включается запись, выполняются действия над тестируемым приложением, после чего мы получаем готовый код скрипта. По мере более глубоко изучения инструмента необходимость в использовании записи постепенно отпадает. Подробнее об этом мы поговорим в главе 2.1 Запись и воспроизведение.
1.5 Создание фреймворка
Фреймворк — это набор функций и/или классов, которые облегчают создание тестовых скриптов и позволяют легко осуществлять действия, которые трудно сделать стандартными средствами инструмента. Фреймворк может включать в себя:
- Систему логирования (если выбранный инструмент не имеет таковой или же её возможности не удовлетворяют вашим нуждам)
- Функции для выполнения проверок (например, для сравнения сложных элементов типа массивов, объектов, таблиц и т.п.)
- Функции для работы с данными (базы данных, таблицы и т.п.)
- Функции для манипулирования с различными типами данных (например, преобразование одного объекта в другой), не предусмотренные возможностями языка программирования
- Функции для преобразования и выполнения ключевых слов (keywords) в код на языке программирования
- Функции, отвечающие за запуск тестов (в определенной последовательности или какого-то набора тестов)
- И многое-многое другое
По сути к фреймворку относится всё, что не имеет прямого отношения к тестам или другому коду, работающему с приложением.
Обычно разработка фреймворка не является отдельной задачей. В самом начале можно написать какие-то функции, которые нам точно понадобятся (например, класс лога или функции для работы с базами данных), однако это вовсе не значит, что на этом можно остановиться. Обычно основная работа по созданию фреймворка приходится на начало проекта, однако по мере написания тестов требования к фреймворку могут меняться, соответственно приходится менять и сам фреймворк.
Фреймворк может быть как очень простым (несколько функций или небольшой класс, позволяющие выводить лог в текстовый файл), который можно написать за один день, так и очень сложным (например, генерирующий отчеты в разных форматах, сохраняющий их в базу данных, позволяющий просматривать отчеты с различной степенью детализации и т.д.), на разработку которого можно потратить месяц и больше. Сложность фреймворка зависит от требований на вашем проекте или в вашей компании и от того, насколько выбранный инструмент соответствует этим требованиям.
После того, как создан фреймворк, можно приступать к написанию тестов.
1.6 Создание тестовых скриптов
Прежде всего необходимо решить, что автоматизировать в первую очередь, а что оставить на потом. Обычно имеет смысл прежде всего автоматизировать наиболее критичные для приложения и простые тесты (они обычно включены в smoke тест), а затем переходить к более экзотичным и сложным задачам. Это имеет смысл по двум причинам:
- Автоматизация наиболее критичных тестов позволит сэкономить время и силы при проведении регрессионного тестирования.
- Более сложные задачи могут потребовать лучшего знания инструмента автоматизации. Эти знания будут приобретены в процессе написания более простых начальных тестовых скриптов.
Собственно написание тестов состоит из двух частей:
- Создание общего кода (common code) приложения
- Написание тестов
Под общим кодом имеются ввиду любые действия, которые приходится выполнять больше одного раза. Например, процесс логина (открытие странички или запуск приложения, ввод имени пользователя и пароля, проверка успешного входа в систему) – это очень хороший пример действий, которые стоит вынести в отдельную функцию или метод.
В зависимости от сложности приложения, таких примеров может быть много. Более того, в больших системах общий код, в свою очередь, также может разделяться на подуровни. Например, создание активного пользователя может состоять из нескольких этапов (создание учетной записи, первый вход пользователя в приложение и заполнение им дополнительных полей, не созданных на первом этапе). В таком случае мы можем разделить код на 2 уровня. На первом уровне будут функции низкого уровня (создание пользователя; вход в приложение; заполнение информации), а на втором уровне – одна функция, которая будет вызывать 3 предыдущие, в том числе осуществляя дополнительные действия между ними (например, переход на страницу входа после создания учетной записи).
Такой подход называется «функциональной декомпозицией», более подробно он описан в главе 2.2 Декомпозиция.
При написании тестов и общего кода стоит сразу же придерживаться определенных правил именования и написания кода (coding standards). Можно взять существующие правила, написать свои или же дополнить чьи-то готовые правила своими, специфичными для вашего проекта. Подробнее об этом мы поговорим в главе 4.6 Полезные советы.
1.7 Запуск тестов
Перед тем, как добавлять написанный тест в набор выполняемых тестов, необходимо убедиться в том, что он работает, причем работает правильно.
- Работает. Чтобы убедиться, что тест работает, необходимо несколько раз запустить его и убедиться в том, что он отрабатывает до конца. Бывает так, что тест работает сам по себе, но не работает в связке с другими тестами (например, предыдущий тест оставляет открытым тестируемое приложение, а новый тест пытается открыть его снова). Поэтому лучше запустить несколько раз тест в одиночном режиме, а затем несколько раз в связке с другими тестами, чтобы убедиться, что новый тест «вписывается» в существующий набор тестовых скриптов.
- Работает правильно. В тестах мы выполняем различные проверки, для этого мы их и пишем. Поэтому новый тест необходимо также проверить на корректность работы. Например, если где-то в тесте мы нажимаем кнопку и проверяем, что появилось сообщение, можно поставить задержку на несколько секунд сразу после нажатия кнопки и закрыть появившееся окно вручную При этом тест должен выдать ошибку. Другой пример – проверки (verifications). Если мы выполняем в тесте проверку того, что в текстовом поле находится определённый текст, можно в скрипте изменить проверяемый текст и убедиться, что скрипт выдаёт в логе ошибку.
После выполнения всех проверок не забывайте убирать временные изменения, которые добавляли для проверки правильной работоспособности скрипта.
Теперь можно перейти к запускам тестов. Как и когда их запускать? Ответ на этот вопрос сильно зависит от количества автоматических тестов и того, как у вас в проекте построен процесс разработки. Вот примеры того, как можно выполнять запуски.
- Запуск всех тестов вручную. Одной командой запускается весь набор тестов. Обычно это обязательно делать перед релизом, чтобы полностью проверить работоспособность тестируемого приложения.
- Запуск тестов частями вручную. Можно разбить все тесты на группы по функциональности и запускать только те группы, чью функциональность необходимо проверить в данный момент.
- Smoke test. Запуск поверхностного теста, который проверяет общую работоспособность приложения. Обычно эти тесты проходят быстро и проверяют, что основные модули приложения доступны пользователю, но не выполняют каких-либо специальных проверок функциональности. Такой тест можно запускать после каждого билда автоматически (например, сделав его частью плана continuous integration).
- Автоматический запуск всех тестов. Можно на отдельном компьютере настроить автоматический запуск тестов (с помощью встроенных средств инструмента либо с помощью возможностей операционной системы) в определенное время. Здесь огромное пространство для фантазии: можно запускать все тесты по ночам, можно запускать тесты непрерывно (т.е. после прохождения всех тестов скачивать с репозитория последнюю версия приложения и тестов и запускать их снова), можно каждую ночь запускать набор основных тестов, а по выходным – всего набора скриптов и т.д.
Кроме всего вышеперечисленного, некоторые инструменты автоматизации позволяют делать распределенный запуск на нескольких компьютерах сразу. Например, вы можете запускать один и тот же набор тестов на разных версиях операционной системы или же распределять тесты между разными компьютерами. Даже если инструмент не обладает подобными встроенными возможностями, такую схему запусков можно настроить самим (например, создав несколько файлов запуска, каждый из которых запускается на отдельном компьютере, а набор тестов для каждого компьютера определять самостоятельно). В случае распределенных запусков, логии скриптов могут складываться куда-то каждым компьютером, или же один компьютер может выполнять роль сервера, собирая логии со всех рабочих машин в сети.
Если компьютер один, а тестов много, можно установить на него виртуальные машины (с помощью программ типа Virtual Box, VMware Workstation или MS Virtual PC) и запускать тесты там.
1.8 Просмотр и анализ результатов
После того, как скрипты отработали, нам необходимо знать результаты пройденных тестов. Для просмотра этих результатов используются логи – отчеты, в которых отображается информация по всем тестам.
Логи должны содержать всю информацию о пройденных шагах: какие опции выбирались, какие данные вводились, какие результаты были получены и т.п., однако самое главное, что должно быть в логе – ошибки. Ошибки должны быть легко обнаруживаемы и к ним должна прилагаться вся необходимая информация для воспроизведения (шаги, данные и т.д.).
Ошибка в логе скрипта – это не всегда ошибка приложения. Довольно часто ошибки в логе свидетельствуют о каких-то недоработках в самих скриптах, поэтому будьте осторожны с такими вещами, как автоматическая регистрация ошибок в багтрекере (по крайней мере нет смысла сразу же отправлять такие ошибки программистам). Бывает так, что достаточно просто перезапустить скрипт с ошибкой и он отработает.
Кроме того, логи должны быть настраиваемыми. Например, тестировщику может быть нужна информация, которая будет совершенно излишней для менеджера, заказчику информации может понадобиться еще меньше, чем менеджер, а программист, наоборот, потребует подробностей, которые совершенно не нужны тестировщику.
Хранить логи лучше всего там, где к ним могут получить доступ все желающие (например, на файловом сервере). В конце работы скриптов логи также могут быть отправлены по почте всем заинтересованным лицам.
В главе 4.2 Логи и отчёты в автоматизации мы более подробно поговорим о генерации логов скриптов.
1.9 Заключение
На этом мы заканчиваем вступительную часть и переходим к рассмотрению практических подходов, которые используются в автоматизации тестирования. Для продолжения ознакомления с теоретической частью автоматизации, обратитесь к главе 4. Другие вопросы, в которой рассмотрены различные хорошие и плохие практики, а также к главе 6, где рассматриваются вопросы выбора и использования инструментов автоматизации тестирования.
Назад | Содержание | Дальше |