4. Другие вопросы

Назад Содержание Дальше

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

4.1 Окупаемость автоматизации

Насколько выгодно заниматься автоматизацией функционального тестирования с точки зрения бюджета? Окупается ли она и приносит ли желаемый результат?

Сначала дадим ответ: да, выгодно, но только при условии, что всё делается с умом.

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

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

Итак, предположим, что я тестировщик и зарабатываю $10/час.

У меня есть тест, в котором необходимо выполнить несколько действий и несколько проверок, на что у меня уходит 15 минут при ручном тестировании, т.е. стоимость прохождения теста составляет $2,5.

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

Если у нас есть 100 аналогичных тестов, их прохождение вручную требует 25 часов, т.е. около 3-х рабочих дней. Для того, чтобы автоматизировать эти тесты, понадобится 100 часов. Здесь лучше увеличить ожидаемое время раза в 1,5, чтобы предусмотреть возможные риски. Примем время, необходимое для автоматизации, равным 170 часов, т.е. 1 месяц.

Таким образом, стоимость разработки тестов будет равна $1700, после чего тесты можно запускать, предположив, что ту же работу, которую мы раньше выполняли вручную, выполняют тесты. Причем вместо 25-ти часов в неделю время на их прохождение занимает 100 минут (округлим до 2-х часов).

В итоге каждую неделю мы экономим 23 часа, что при стоимости моего времени $10 даёт $230 в неделю или около $900 в месяц.

Однако нельзя считать, что мы экономим именно $900, так как тесты необходимо поддерживать и в случае необходимости модифицировать, результаты их прохождения нужно проверять, иногда тесты приходится перезапускать. Пусть на это у нас уходит 1 день в неделю, т.е. 8 часов по $10 за 4 недели дает в итоге около $300. В результате мы получаем, что чистой экономии в месяц при использовании автоматизации выходит около $600.

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

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

Если вас или ваше руководство это не устраивает, можно рассмотреть другие вопросы, чью стоимость трудно учесть в расчетах:

  1. В нашем примере мы брали идеальный 8-ми часовой рабочий день, однако совершенно очевидно, что ни один человек не в состоянии продуктивно работать 8 часов подряд (если ваш руководитель не признаёт этот факт, мы рекомендуем поискать другое место работы). Если учесть перерывы на чай/кофе/перекуры/анекдоты, то можно смело уменьшить реальное рабочее время до 6-ти часов, что дает около 4-х реальных дней на прохождение 100 тестов и экономию около $1000 в месяц, что сокращает срок окупаемости в последнем примере до 11 месяцев вместо 18-ти.
  2. Скрипты не подвержены человеческому фактору и один раз написанные правильно, они никогда не ошибутся и не пропустят «случайно», как это может сделать человек (особенно уставший). Скрипты могут работать по ночам или на выходных, а могут работать на отдельном компьютере, в то время, пока тестировщик проверяет ту часть функционала, которая не покрыта тестами.
  3. Некоторые вещи невозможно или невероятно трудно проверить вручную. Чаще всего к таким задачам относят нагрузочное тестирование, но есть и другие примеры: сравнение изображений, перебор большого числа входных и выходных параметров, одновременная проверка работы сразу в нескольких частях приложения с разных компьютеров и другие. Всё это гораздо проще при использовании автоматизированных скриптов.

Пожалуй, остался лишь ещё один важный параметр, который мы не учли при расчетах. Если моя зарплата при ручном тестировании равна $10/час, то при переквалификации на автоматизацию компании придется платить мне больше (примерно раза в 1,5), так как круг моих обязанностей и ответственности, как и уровень знаний, возрастает.

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

4.2 Логи и отчёты в автоматизации

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

В разных инструментах, предназначенных для автоматизации тестирования, логи организованы по-разному. Например, в TestComplete лог хранится в формате XML, в SilkTest используется свой бинарный формат, в Selenium можно включить логи, содержащие отладочную информацию, а для генерации пользовательских логов необходимо подключать дополнительные библиотеки и т. д.

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

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

  1. Формат лога. Наиболее универсальным можно считать формат XML, наиболее простым — обычный текстовый файл, наиболее удобным для чтения — формат HTML. Кроме того, необязательно работать только с одним форматом. Лог, например, может формироваться в формате XML для внутренних нужд команды тестирования и разработчиков, после чего конвертироваться в формат HTML для предоставления их менеджменту или заказчику (в случае такой необходимости).
  2. Кодировка. Кодировку лучше использовать UTF-8.
  3. Снимки экрана (скриншоты). В случае возникновения ошибки в лог всегда необходимо помещать скриншот экрана (причем всего экрана, а не только приложения, так как на тестируемое приложение и инструмент автоматизации могут влиять и сторонние программы). При работе с веб-приложениями, когда странички в высоту могут быть длиннее высоты экрана, желательно делать снимок всей страницы (например, прокручивая ее в случае необходимости, а затем «склеивая» части).
  4. Фильтры отображения. Логи могут содержать огромное количество информации, однако чаще всего для анализа нам достаточно просмотреть лишь ошибки, возникшие во время работы скриптов. Очень удобным в таком случае может оказаться возможность отключения показа всех остальных типов сообщений (информационных, отладочных и т. п.).
  5. Информация о проверках. Когда в скриптах выполняются проверки (т. е. Сравнение эталонных значений со значениями, полученными в приложении), очень хорошей практикой считается помещать ожидаемый и полученный результат (expected и actual) в случае, если проверка не прошла.
  6. Сохранение лога. Насколько часто сохранять лог — это довольно сложный вопрос. Если делать это слишком часто, работа скриптов может замедлиться. Если делать только в конце запуска скриптов — есть вероятность того, что логи будут утеряны (например, если случился какой-то сбой работы инструмента или же попросту пропало электричество). Поэтому желательно предусмотреть сохранение лога на диск через определенные промежутки времени.
  7. Типы ошибок. Вполне вероятно, что в своих скриптах вы захотите выделить несколько типов ошибок (ошибки скрипта, ошибки функциональности, ошибки, связанные с тестовым окружением и т. п.). В таком случае каждый тип ошибки необходимо как-то выделять (иконкой, цветом или оформлением).
  8. Хранение логов. Логи (особенно со множеством скриншотов) могут занимать много места, поэтому необходимо продумать, где их хранить, чтобы с одной стороны они были постоянно доступны всем, кому они могут понадобиться, а с другой — не были обузой, занимая место на диске. Например, можно хранить все логи на отдельном сервере, специально для этого предназначенного. Кроме того, необходимо решить, так ли уж важны логи «промежуточных» запусков (например, ночных), или же достаточно будет сохранять логи быстрого (smoke) теста или приёмо-сдаточного для каждой версии. Кроме того, возможно, логи можно автоматически удалять по истечении какого-то времени.

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

4.3 Проверка отдельных дефектов

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

Это может происходить по нескольким причинам.

  1. Если проблема всплыла довольно быстро (в течение дня или недели), скорее всего произошли какие-то проблемы при слиянии разных веток в системе контроля версий. При подобном слиянии, особенно если изменений очень много, ошибки проявляются довольно часто, так как программист не всегда может точно определить, какие именно изменения являются более новыми или более правильными.
  2. Если проблема появилась снова через довольно продолжительное время (несколько месяцев), это может быть следствием того, что в первый раз для исправления проблемы программист использовал какой-то нестандартный подход. Через несколько месяцев этот код может быть изменен в результате рефакторинга, что потенциально вернёт старую проблему.
  3. Проблема на самом деле не была исправлена изначально и дефект был закрыт по ошибке.

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

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

  1. Автоматизируйте проверку только наиболее критичных и важных дефектов. Например, если ошибка заключалась в том, что размер шрифта одного единственного элемента отличался на 1 пиксель от того, что указано в спецификации, нет смысла писать для этого отдельный тест, так как это слишком мелкая проблема, которая к тому же вряд ли помешает конечному пользователю.
  2. Старайтесь делать эти проверки как можно быстрее. Например, создать тест, который будет работать полчаса и при этом проверит всего один дефект – это неудачный подход.
  3. По возможности встраивайте проверки дефектов в имеющиеся тесты. Зачастую старт и предварительная подготовка приложения занимают много времени, при этом уже есть тесты, которые работают с той функциональностью, в которой проявился дефект. Имеет смысл немного изменить код существующего скрипта и вставить проверку где-то в его середину отдельным шагом.
  4. Не занимайтесь автоматизацией дефекта, если для написания необходимого кода проверки у вас уйдет много времени (например, больше одного-двух часов). Отступать от этого правила можно, если дефект проявляется в критичном месте приложения и подобная трата времени оправдана, либо если дефект связан со множеством проверок (тогда это попросту равносильно новому тесткейсу).

4.4 Тестирование интерфейса и дизайна

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

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

4.5 Работа с изображениями

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

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

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

  • Сравнение изображений необходимо использовать только в самых крайних случаях, когда без этого не удается обойтись, либо когда задача тестирования заключается именно в работе с изображениями (например, тестирование графического редактора).
  • Сравнение изображений – задача трудоемкая как при написании кода, так и при выполнении скриптов (сравнение происходит медленно).
  • Мельчайшие изменения в тестируемом приложении (например, сдвиг на 1 пиксель, который незаметен для пользователя) обычно приводит к поломке тестовых скриптов и необходимости их переделывания.
  • В некоторых случаях изображения отличаются в разных версиях одной и той же операционной системы. В качестве примера можно привести Windows XP и Windows 7: в них элементы управления выглядят по-разному, что добавляет сложности при написании тестов.
  • Если уж работа с изображением – единственно возможный вариант, по крайней мере сравнивайте не весь экран целиком, а только ту часть, которую действительно необходимо проверить (окно, элемент управления или его часть).
  • Если вам нужно проверить изображение, а сделать это автоматически очень трудно, вы можете просто выводить изображение в лог и просматривать его вручную по окончании работы скриптов. Это, конечно, не будет полностью автоматизированным решением задачи, но лучше так, чем постоянно исправлять и улучшать код проверки.

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

В наших примерах мы используем TestComplete, в котором возможности для работы с изображениями весьма богаты: мы можем захватывать изображения отдельных элементов управления, сравнивать изображения и даже искать одно изображение внутри другого. Кроме того, мы можем задавать различные допуски при проверках, что также может существенно облегчить задачу. Если в вашем инструменте таких возможностей нет, вы можете попытаться реализовать их сами (что может оказаться довольно трудной задачей), или же воспользоваться сторонними утилитами.

В качестве примера приведем небольшой скрипт, выполненный с помощью TestComplete, и разберем результаты его работы. Этот скрипт рисует параллелограмм с двумя диагоналями в программе MS Paint, а затем пытается определить, что полученное изображение соответствует тому, что мы ожидаем. Для этого мы прдварительно нарисовали (также средствами TestComplete) и сохранили изображение параллелограмма в хранилище Regions. Вод код скрипта:

function TestImages()
{
  TestedApps.mspaint.Run();
  var  wPaint, toolbar, canvas;
  wPaint = Sys.Process("mspaint").Window("MSPaintApp", "*");
  wPaint.Restore();
  wPaint.Position(0, 0, 800, 600);
  toolbar = wPaint.Window("AfxWnd42u", "Tools");
  
  // Задаем размеры окна и области для рисования
  wPaint.Keys("^e");
  Sys.Keys("500[Tab]300[Enter]^a[Del]");
  canvas = wPaint.Window("Afx:1000000:8");
  toolbar.Click(20, 90); // click Pencil tool
  
  // рисуем параллелограмм с диагоналями
  canvas.Drag(50, 50, 100, 0);
  canvas.Drag(150, 50, 50, 50);
  canvas.Drag(200, 100, -100, 0);
  canvas.Drag(100, 100, -50, -50);
  canvas.Drag(50, 50, 150, 50);
  canvas.Drag(150, 50, -50, 50);
  wPaint.HoverMouse(1, 1);

  // Сохраняем изображение параллелограмма в Stores.Regions
  
  //Regions.AddPicture(canvas.Picture(50, 50, 151, 51), "parallelogram");
  
  // Пытаемся выполнить проверку правильности изображения
  var canvas_pic = canvas.Picture();
  if(Regions.FindRegion("parallelogram", canvas_pic) == null)
  {
    Log.Error("Parallelogram not found in canvas");
  }
  
  Regions.Compare(canvas.Picture(50, 50, 151, 51),
  Regions.GetPicture("parallelogram"));
  Regions.Compare(canvas.Picture(50, 50, 151, 51),
  Regions.GetPicture("parallelogram"), false, false, true, 30);
}

А вот так будет выглядеть лог работы скрипта.

Рис. 5.1. Лог работы скрипта, выполняющего сравнение изображений

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

Первая проверка (поиск изображения внутри другого с помощью метода FindRegion) просто вернула нам значение null, что говорит о том, что сохраненное ранее изображение не найдено в нарисованном нами. Хотя поиск изображения внутри другого и является удобной функцией, она не дает нам никакой визуальной информации.

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

И, наконец, третья проверка также завершилась неудачей, хотя мы воспользовались дополнительным параметром Tolerance (в нашем случае он равен 30). Этот параметр позволяет задать наибольшее количество отличающихся пикселей, при которых изображения будут считаться одинаковыми. В нашем примере количество таких пикселей равно 40 (хотя на вашем компьютере результаты могут немного отличаться), поэтому увеличение этого параметра до 40 приведёт к тому, что проверка пройдет успешно.

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

Кроме того, обратите внимание на дополнительные действия, которые нам пришлось сделать, чтобы корректно работать с изображениями: нам пришлось установить строго заданный размер окна и холста; после того, как мы закончили рисование изображения, нам пришлось убрать в сторону курсор мыши (с помощью метода HoverMouse, хотя в TestComplete есть встроенные средства для игнорирования курсора мыши при захвате изображения); и, наконец, нам пришлось указывать точные координаты для захвата изображения и передаче его методу Regions.Compare, что нельзя считать очень удобным подходом.

Именно поэтому мы рекомендуем избегать работы с изображениями в автоматизации тестирования.

4.6 Полезные советы (best practices)

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

  1. Не пользуйтесь средствами записи (Record & Play). Независимо от того, насколько хорош выбранный вами инструмент, встроенные средства записи в нем все равно сильно ограничены. Средства записи хороши лишь поначалу, когда вы знакомитесь с инструментом, так как они позволяют вам максимально быстро получить представление о том, как инструмент взаимодействует с тестируемым приложением. После того, как вы разработаете свой фреймворк и набор вспомогательных функций для работы с приложением, запись скрипта и его последующая модификация оказываются более долгим процессом по сравнению с обычным написанием кода.
  2. Пишите простой и понятный код. Не усложняйте код скриптов редкоиспользуемыми и малопонятными конструкциями или сложной структурой классов. Помните, что даже если вы – единственный, кто сейчас занимается автоматизацией на вашем проекте, то после вас с кодом будет работать кто-то другой. Есть такой тип людей, которые любят экспериментировать со всем подряд, углубляясь в решение задач, которых изначально даже не существовало, при этом забывая о цели собственно работы. Экспериментировать – это хорошо, но не на реальном проекте. Экспериментируйте дома в свободное время, а если из этих экспериментов получилось что-то полезное – внедряйте в проект.
  3. Используйте стандарты кодирования и другие правила, присущие используемому языку программирования. Их можно взять готовые (если используется популярный язык типа Javascript или VBscript) или создать свои, взяв за основу какой-нибудь похожий язык программирования. Используйте статические средства проверки кода, которые позволяют находить в скриптах расхождение со стандартами. Старайтесь не выкладывать в систему контроля версий код, не прошедший такую проверку.
  4. Следуйте тем же правилам, что и программисты. Написание скриптов – это тот же процесс программирования, а значит лучшим подходом при их написании будет следование тем же правилам, которым следуют разработчики кода. Обращайтесь к программистам за помощью, если вам что-то непонятно: чаще всего они с удовольствием делятся своими знаниями и правилам, которым сами следуют. Это не значит, что вы должны следовать абсолютно всем правилам, о которых вам расскажут, но знание этих подходов позволит вам быстрее выработать своё видение процесса разработки.
  5. Тестируйте свой код. Программисты для тестирования своего кода используют unit тесты. В случае с автоматическими скриптами этот подход не подходит, так как вызовы функций и методов зачастую подразумевают взаимодействие с тестируемым приложением. Так как же можно протестировать свои скрипты на предмет их правильности и стабильности?
    Самый простой способ: поменять в них ожидаемые значения на неправильные и прогнать скрипт в этом режиме. В результате в логе вы должны получить понятные сообщения об ошибках. Например, предположим, что у нас есть следующий код, проверяющий, что в текстовом поле находится определенный текст:

    var exp = "expected text";
    var act = Sys.Process(...).Window(...).wText;
    if(exp != act)
    {
      Log.Error("Incorrect text", "Expected: " + exp + "\nActual: " + act);
    }

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

    Другой способ проверки кода – это ручное взаимодействие с тестируемым приложением во время работы скрипта. Что будет, если какое-то окно не появится? Допустим, окно появляется после нажатия на кнопку. Поставьте в скрипте небольшую задержку после нажатия на кнопку (или поставьте в этом месте брекпоинт) и во время работы скрипта закройте это окно вручную, как только оно появится на экране. Как поведет себя в такой ситуации скрипт? Получим ли мы в логе понятную ошибку? Сможем ли воспроизвести ситуацию, не запуская скрипт заново, а просто читая лог?

  1. Автоматизируйте только устоявшуюся функциональность. Нет смысла автоматизировать тестирование функциональности, которая еще не прошла проверку заказчиком, так как в нее могут вноситься изменения. Кроме того, прежде чем автоматизировать какую-то часть приложения, необходимо протестировать ее вручную, чтобы убедиться, что в ней нет явных ошибок и что мы не будем проверять неправильное поведение приложения.
  2. Разрабатывайте независимые тесты. Каждый тест должен быть самостоятельным, то есть не должен зависеть от других тестов, и его должно быть возможно запустить отдельно. Если какой-то тест зависит от результатов другого теста, то в случае, если в первом тесте произошла какая-то ошибка и сгенерировались неправильные данные (или не сгенерировались вообще), то не отработает и второй тест, который вполне может быть работоспособным, и вам придется решать две проблемы вместо одной. Чтобы добиться такой независимости тестов, необходимо чтобы каждый тест стартовал с определенной точки (например, принудительно закрывал тестируемое приложение, если оно открыто, а затем открывал его заново). Никогда не используйте в новом тесте уже открытое приложение в новом тесте, так как неизвестно, что с ним происходило во время работы предыдущего скрипта.
  3. Не дублируйте в скриптах код приложения. Если, к примеру, в приложении производятся какие-то расчеты и вам необходимо проверить результат, не выполняйте эти же расчеты в скриптах.
    • Во-первых, вы рискуете внести ошибку в расчетах в своих тестах.
    • Во-вторых, в случае изменения формул расчета вам придется модифицировать скрипты.
    • В-третьих, в случае точных расчетов точность математических расчетов в языке, используемом для автоматизации, может отличаться от точности, используемой в языке, на котором написано приложение, что также может повлиять на результат.

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

  1. Не подгоняйте скрипты под приложение. Если в приложении есть ошибка и она отлавливается скриптом (например, неправильный текст ссылки) – не изменяйте скрипт только для того, чтобы он успешно отрабатывал. Во-первых, это приведет к тому, что ошибка так и останется неисправленной. Во-вторых, если она все же будет исправлена, скрипт снова придется менять. Лучше при каждом проходе скриптов видеть эту ошибку или же отключить временно этот скрипт, если другого решения нет.
  2. Запускайте скрипты как можно чаще. Для обеспечения стабильности скриптов их нужно запускать как можно чаще. Делать это можно, например, на отдельном build-сервере при каждом внесении изменений в исходный код приложения (для этого настраивается система continuous integration), или просто на отдельном компьютере (или виртуальной машине). Если в течение дня вы циклично запускаете скрипты на одной и той же сборке приложения – внимательно исследуйте каждую ошибку, которая появляется в результате прогона скриптов, и вносите соответствующие улучшения в свой код.

4.7 Мифы и заблуждения относительно автоматизации

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

    1. Автоматизация позволяет избавиться от ручного тестирования. Это в корне неправильное предположение. Автоматизация лишь дополняет ручное тестирование и упрощает некоторые задачи (например, избавляет от рутины регрессионного тестирования и от человеческого фактора при проведении различных проверок). Новую функциональность вообще невозможно протестировать иначе, как вручную, только после этого можно что-то автоматизировать. Даже если речь идет только об автоматизированном тестировании smoke тестов (т.е. самых простых и поверхностных), нам все равно придется иногда вносить изменения в скрипты в соответствии с изменениями в тестируемом приложении. В том случае, если у нас есть набор тестовых скриптов, которые никогда не меняются и проверяют только самую стабильную функциональность, и при этом запускаются автоматически, в обязанности тестировщиков все равно будет входить проверка того, что в отчетах нет ошибок. Именно поэтому многие специалисты утверждают, что говоря об автоматизации тестирования, мы имеем ввиду не «автоматическое» тестирование, а «компьютеризированное» (англ. computer-assisted).
    2. Внедрение автоматизации дает мгновенную выгоду. Прежде, чем мы начнем получать выгоду от автоматизации, нам придется составить план тестирования (даже если у нас есть план для ручного тестирования, его, скорее всего, придется переделать), написать тесты (а также все, что с ними связано, т.е. код фреймворка и код для работы с приложением) и отладить их. В дальнейшем нам постоянно придется поддерживать существующие тесты и писать новые. Всё это требует времени и соответствующей квалификации тестировщика (а значит, на обучение тоже, скорее всего, потребуется время). Поэтому автоматизация тестирования поначалу не только не дает выгоды, а создает убытки. Только со временем, постепенно, мы начнем получать выгоду от регрессионного тестирования, когда тестировщики смогут больше времени уделять ручному тестированию новой функциональности, практически не тратя время на проверку старого.
      В нашей практике был лишь один случай, когда автоматизация тестирования начала приносить реальную и ощутимую пользу всего через 2 недели после начала внедрения. Это случилось благодаря тому, что использовался инструмент, с которым мы работали на нескольких других проектах до этого и у нас было готово много наработок, которые просто пришлось подогнать под нужды нового проекта (т.е. мы использовали уже готовый фреймворк). Кроме того, существующие ручные тесты в этом проекте были написаны таким образом, что их было легко автоматизировать.Еще одним фактором такого быстрого внедрения было то, что для автоматизации не пришлось отрывать никого из задействованных в ручном тестировании, таким образом автоматизаторы могли полностью сосредоточиться на своей работе.
    3. Автоматизировать можно любой ручной сценарий. Это также неверно по нескольким причинам:
      • любой инструмент для автоматизации тестирования имеет свои ограничения. Например, в тестируемом приложении могут использоваться элементы управления, разработанные сторонними производителями, поддержка которых не обеспечивается инструментом (чаще всего подобные проблемы возникают с различными таблицами). В таких случаях от некоторых проверок придется отказаться и оставить их для ручного тестирования.
      • некоторые тестовые сценарии могут содержать задачи, которые проще выполнить вручную, чем пытаться автоматизировать (например, перезагрузка компьютера в середине теста или настройка удаленного сервера, включающая множество действий). Такие задачи можно либо оставить для ручной проверки, либо автоматизировать частично.
      • в некоторых случаях проверки невозможно автоматизировать вообще, так как они не поддаются количественному описанию. Примерами таких задач могут быть градиентная заливка объекта с переходом цвета или же просто внешний вид окна или веб-страницы, когда нужно убедиться, что дизайн «не режет глаз» или что цвет элемента нормально сочетается с цветом фона.
    4. Автоматическими тестами можно покрыть 100% функциональности приложения. Это невозможно, так как невозможно проверить все варианты входных и выходных параметров (это затруднительно даже для элементарных программ). Пожалуй, максимум, чего можно добиться в плане покрытия кода, – это того, что тестами будет покрыто 100% строк кода приложения, однако этот подход дает наименьшую точность покрытия (так как не проверяются различные условия и логические проверки).
    5. Универсальное средство автоматизации тестирования. Ни один из ныне существующих инструментов автоматизации не является универсальным и вряд ли появления подобной программы можно ожидать в ближайшем будущем. Для того, чтобы инструмент был универсальным, ему нужно было бы работать во всех операционных системах (Windows, MacOS, Unix), поддерживать огромное количество сред разработки (Java, .NET, Qt, Flash и т.д.), уметь работать со всеми сторонними компонентами (DevExpress, Infragistic и еще тысячами других) и предоставлять универсальные способы работы в различных браузерах (их как минимум 5). Естественно, это невозможно, так как подобный инструмент стоил бы слишком дорого, чтобы его купил хоть кто-то. В нашей книге для примеров мы используем TestComplete, который поддерживает максимальное количество сред разработки и сторонних компонентов (по сравнению с другими подобными инструментами), однако у него есть один большой минус: он работает только под Windows.

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

4.8 Автоматизация и Scrum

В последние годы всё большую популярность приобретают модели быстрой разработки программного обеспечения, в частности Scrum. Особенность этого подхода в том, что через определенные равные промежутки времени (так называемые «спринты», обычно они длятся от одной до четырех недель) мы должны иметь вполне работоспособный продукт.

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

  1. Переносить разработку автотестов на следующий спринт. У этого подхода есть два основных достоинства: во-первых, новая функциональность будет протестирована без спешки вручную, что позволит найти больше ошибок и вовремя их исправить; во-вторых, в начале следующего скрипта у вас все равно будет время, пока программисты напишут что-то, готовое для тестирования, и это время можно потратить на написание скриптов, тестирующих функциональность из прошлого спринта. Недостаток этого подхода в том, что фактически цель спринта с точки зрения тестирования не будет полностью достигнута.
  2. Разрабатывать тестовые скрипты одновременно с разработкой приложения. Так как приложение разрабатывается по спецификациям, мы вполне можем написать скрипты, исходя из информации о том, как должно работать приложение, а затем, когда новая функциональность будет доступна, лишь внести небольшие изменения в тесты в тех местах, где были допущены неточности.

Этот подход называется Behaviour-driven development, он получил распространение по мере внедрение Agile-подобных методологий и в целом согласуется с подходом TDD (Test-driven development, разработка через тестирование). Несмотря на то, что в целом этот подход более соответствует модели быстрой разработки, он является более сложным, так как требует дополнительных усилий как со стороны тестировщиков, так и со стороны разработчиков (строгое следование стандартам именования элементов управления, разработка «заглушек» для данных – mock’ов и т.п.).

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

Назад Содержание Дальше