положу сюда копии

http://www.software-testing.ru/library/around-testing/processes/462-automation-myths
Автор: Дмитрий Ручко

Данная статья была подготовлена на основе доклада, сделанного автором на конференции SQA-2 (http://sqa2conf.blogspot.com/) в октябре 2007 года.

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

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

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

Один из наиболее популярных мифов состоит в том, что:

Миф 1. Автоматизированное тестирование – это только проверка регресса.

Вместе с ним часто встречается ещё одно заблуждение, сводящее автоматизацию только к тестированию через пользовательский интерфейс:

Миф 2. Автоматизированное тестирование – это только функциональное тестирование через GUI.

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

«Автоматизация – это комплекс мероприятий, направленный на повышение производительности труда человека посредством замены части этого труда работой машин.» Информатика. Энциклопедический словарь-справочник [1].

Из данного определения очевидно, что автоматизированное тестирование, это не только и не просто выполнение тестов. Автоматизация может быть представлена в большинстве процессов тестирования, начиная от планирования и заканчивая тем самым запуском тестов. Посмотрим на основные процессы, не упоминая конкретных продуктов, так как какие-то элементы вы можете автоматизировать и самостоятельно, с помощью например MS Excel, не прибегая к покупке серьёзных дорогих инструментов.

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

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

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

Создание тестов. Имеется в виду предварительная автогенерация: на основе кода - для unit-тестов, на основе функциональных требований - для ручных тестов, генерация по принципу record’n’play и т.п.

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

Выполнение тестов. Запуск тестовых скриптов и анализ полученных результатов.

Данный список каждый может продолжить сам в зависимости от специфики своей работы.

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

Для каких же целей может применяться автоматизированное тестирование?

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

Следующим идёт регрессионное тестирование. Что означает проверку ПО на корректность функциональности, выпущенной и тщательно протестированной в предыдущей версии. Выполняется с регулярной частотой, задаваемой в зависимости от условий: у кого-то с каждым новым билдом, у кого-то с каждой версией для заказчика.

Конфигурационное тестирование – выполнение одних и тех же тестов в разных условиях. То есть когда один или несколько компонентов архитектуры системы требуется проверить в разном окружении, обычно заявленном в изначальных требованиях. Например: поддержка СУБД от разных производителей, работа в разных клиентских браузерах, использование в нескольких ОС и т.п. То есть некий аналог регрессионного тестирования, но в рамках одной версии системы. Кроме средств контроля за выполнением работ, в данном случае, нелишней бывает возможность автоматического сравнения полученных результатов выполнения сценариев в разных конфигурациях.

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

Установочное тестирование, как понятно из названия, выполняется для проверки условий инсталляции (и настройки) продукта с учётом тех или иных требований к системе от заказчика. В данном случае автоматизировать тесты удобно не только для проверки, как таковой, но и для их последующего использования ручными тестировщиками с целью уменьшить объём работ при установке очередного билда.

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

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

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

Тестирование API (программных интерфейсов, в которые входят как публичные методы для локальных вызовов от обычных dll, так и для COM+, win- и web- сервисы, обращения через очередь и т.п). Обычно применяется на уровне модульного тестирования продукта и позволяет не отвлекаться на исследование характеристик методов при последующей интеграции.

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

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

Тестирование GUI (пользовательского интерфейса) – то, о чём обычно идёт больше всего разговоров. И что далеко не всегда удается успешно внедрить. Обычно применяется на уровне системного тестирования для поиска регрессионной зависимости.

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

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

Следующее заблуждение свойственно людям, желающим счастья и сразу:

Миф 3. В автоматизированном тестировании всё выполняется само

Вспоминается закон Мёрфи: «Создай систему, которую сможет использовать даже дурак. И только дурак захочет ей пользоваться».

Посмотрим снова в словарь Информатики [1]:

«Автоматизированный технический объект: это устройство, система или процесс, в котором используются автоматы или другие средства автоматизации. В отличие от понятия "автоматический" в работе указанных средств или в выполняемом ими процессе предполагается участие человека.»

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

1. Выбор скриптов для запуска. При большом объёме вполне может возникнуть ситуация, что все их одновременно запускать не нужно. Вполне техническая – когда инструмент пишет весь лог в память, и значит при длинном сценарии очень вероятно её переполнение. Или функциональная – когда выполнение части тестов не требуется из-за ещё неисправленных ошибок. Чисто ручная работа.
2. Подготовка тестовых данных. Может быть как автоматической, так и ручной. В удачном случае данные могут остаться неизменными от предыдущего запуска, если тесты просто не меняют данные либо по окончанию тестирования приводят их в исходное состояние. В неудачном – перед каждым запуском данные нужно готовить заново.
3. Собственно запуск и выполнение скриптов. Данный этап может быть полностью автоматическим, если фреймворк позволяет настроить планировщик для запуска тестов при сохранении созданного списка.
4. Анализ полученных результатов. Чисто ручная работа, которая может быть слегка автоматизирована в плане сравнения результатов с иными запусками или фильтрации изучаемых логов.
5. Публикация результатов. Если напрячься, также поддается автоматизации. Но обычно выполняется вручную с использованием данных, полученных на предыдущем этапе.

Сколько стоит

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

Миф 4. Автоматизация позволяет сократить расходы

Миф 5. Автоматизация решает проблему с нехваткой ресурсов

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

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

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

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

И при расчёте расходов нужно учитывать следующие элементы:

* Инструмент;
* Обучение/наём опытных сотрудников;
* Разработка;
* Сопровождение;
* Выполнение;
* Новые задачи, связанные с автоматизацией (по сравнению с ручным тестированием).

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

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

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

Если команда тестировщиков никак не меняется, то это значит что при внедрении автоматизированного тестирования меняется как список решаемых задач, так и их приоритеты. Никогда не будет такого, что будет выполняться прежний объём ручных тестов и плюс к этому набор автоматизированных. (Перманентную переработку в учёт давайте не брать, так как это скорее уже способ увеличения бюджета за счёт сотрудников.)

Так что объём задач в одном и другом случае просто не сравним. Это означает, что при ручном тестировании продукт был недоисследован с одного бока, а при автоматизированном – забудут про другой. Или осмотрят с каждой стороны, но совсем коротенько.

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

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

Миф 6. Автоматизация позволяет найти больше ошибок.

Миф 7. Автоматизация уменьшает количество человеческих ошибок.

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

Канер, Бах, Петтикорд в своей книге [7], приводят следующую статистику: «при любом виде автоматизированного тестирования находится не более 30% ошибок в самом удачном случае. И только при конфигурационном тестировании можно найти до 80% от общего числа ошибок.»

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

Автоматизированное тестирование всегда имеет как плюсы:

* Большее покрытие кода;
* Тест не будет пропущен;
* Тесты содержит одни и те же шаги;

так и минусы:

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

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

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

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

Миф 8. Чем больше автотестов, тем лучше.

В результате возникает стремление закодировать как можно больше ручных тестов. А лучше все. Это неправильно. В реальности объём автоматизации определяется контекстом проекта. Какова архитектура системы? Какие требования к качеству у заказчика? Какой бюджет проекта, в том числе и сроки?

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

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

* сложной алгоритмизации проверки;
* нестандартной конфигурации стенда, которую нужно менять для разных тестов;
* стороннее ПО, создающее дополнительные проблемы;
* и прочие причины…

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

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

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

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

Что почитать

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

1. Воройский Ф. С.
Информатика. Энциклопедический словарь-справочник: введение в современные информационные и телекоммуникационные технологии в терминах и фактах.
2006, ФИЗМАТЛИТ.
2. Elfried Dusting, Jeff Rashka, John Paul.
Automated Software Testing: Introduction, Management and Performance.
1999, Addison-Wesley.
Выпущена в русском переводе:
Элфрид Дастин, Джефф Рэшка, Джон Пол.
Автоматизированное тестирование программного обеспечения: Внедрение, управление и эксплуатация.
2003, Лори.
3. Mark Fewster, Dorothy Graham.
Software Test Automation: effective use of test execution tools.
1994, Addison-Wesley.
4. Kanglin Li, Mengqi Wu.
Effective GUI Test Automation: Developing an Automated GUI Testing Tool.
2005, SYBEX.
5. Jerry Zeyu Gao, H.-S. Jacob Tsao, Ye Wu.
Testing and quality assurance for component-based software.
2003, Artech House.
6. James D. McCaffrey.
.NET Test Automation Recipes: A Problem-Solution Approach.
2006, Apress.
7. Cem Kaner, James Bach, Bret Pettichord.
Lessons Learned in Software Testing: a context driven approach.
2002 г., Wiley Computer Publishing.

http://www.aplana.ru/publications_171.htm Средства автоматизированного тестирования
[30.04.09]
Петр Можаев, Открытые системы, №3, 28 апреля 2009 г.

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

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

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

На рынке средств функционального тестирования сегодня представлены главным образом продукты следующих компаний: HP (QuickTest Professional, WinRunner), IBM (Robot, Functional Tester), Borland (SilkTest) и AutomatedQA (TestComplete), представляющие собой средства разработки приложений. Причем часть из них использует «промышленные» языки программирования (например, QTP используется в качестве языка разработки скриптов VB, а Functional Tester реализован в среде Eclipse и позволяет создавать скрипты на Java), а часть применяет «диалекты» или свои собственные специальные языки (например, Robot использует язык SQABasic, а TestComplete – язык 4Test). Большинство инструментов ориентировано на работу с Web-приложениями либо с обычными приложениями, написанными на .Net или Java. При этом поддержку «старых» платформ, таких как Centura или PowerBuilder, обеспечивают в основном крупнейшие разработчики средств тестирования, HP и IBM.

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

Инструменты нагрузочного тестирования являются более сложными – они фактически «перехватывают» трафик между тестируемым приложением и сервером и представляют его в виде, удобном для работы. Практически все производители продуктов для автоматизированного тестирования предлагают средства нагрузочного тестирования, поскольку в современном виде функциональное тестирование в чистом виде мало кого интересует. Лидерами на рынке средств автоматизированного нагрузочного тестирования являются HP с продуктом LoadRunner и IBM с продуктами Robot
и Performance Tester, поддерживающими множество протоколов (включая терминальные протоколы). Большинство средств нагрузочного тестирования работают лишь с Web-приложениями.

Помимо собственно средств тестирования существуют так называемые средства поддержки процесса тестирования, позволяющие вести учет требования и тест-кейсов, проводить анализы покрытия требования тестами, управлять ходом выполнения тестирования, вести учет обнаруженных дефектов и т.п. Лидирует в данной области Web-приложение HP Quality Center – единый инструмент управления процессом тестирования (включая управление требованиями и дефект-менеджмент), интегрируемый со средствами функционального и нагрузочного тестирования HP QuickTest Professional и LoadRunner. С данным инструментом конкурирует продукт Rational Quality Manager (RQM) от IBM, представляющий собой Web-приложение на платформе Jazz.

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

Автоматизация тестирования

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

Автоматизация тестирования позволяет если не избежать, то значительно уменьшить синдром «замыленного глаза», когда тестировщик перестает замечать ошибки при выходе новых версий. Благодаря автоматизации можно не просто ускорить процесс тестирования, но и увеличить тестовое покрытие за счет большего количества перебираемых комбинаций входных данных, что в свою очередь позволяет снизить требования к квалификации разработчиков – с большей вероятностью их ошибки будут обнаружены на этапе тестирования. Если раньше для того, чтобы гарантировать, что с вероятностью 99% в программе не будет критических ошибок, мы должны были использовать команду из 10 высококлассных разработчиков, то теперь мы обходимся командой из 10 разработчиков, среди которых только 2-3 высококлассных специалиста.

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

А зачем компаниям, оказывающим услуги по тестированию и разработке программного обеспечения, пропагандировать использование средств автоматизации? Затраты на средства автоматизации несопоставимы с возможными потерями от сбоев системы, вызванных как функциональными ошибками, так и неудовлетворительной производительностью, – экономия на тестировании приведет к потерям на этапе эксплуатации подобного программного обеспечения. Центр тестирования компании «Аплана» уже давно занимается аутсорсингом функционального и нагрузочного тестирования, и, выполнив множество проектов с использованием различных средств автоматизации, мы можем с уверенностью сказать, что сегодня нет одного инструмента, который полностью удовлетворил бы всех заказчиков. Однако можно выбрать инструмент, максимально соответствующий предъявляемым требованиям.

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

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

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

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

Мы предпочитаем работать со средствами тестирования компаний HP и IBM, хотя у нас есть опыт использования инструментов других производителей и собственные средства автоматизированного тестирования. Прежде чем начинать разработку автоматизированных тестов, мы выполняем анализ и готовим отчет, на основании которого заказчик принимает решение о том, какой инструмент тестирования ему больше подходит, однако часто встречаются ситуации, когда инструмент выбран заранее. На мой взгляд, практически каждую задачу можно решить с помощью любого инструмента тестирования, однако трудоемкость и стоимость решения будут сильно отличаться. Например, если используемый инструмент автоматизации тестирования не имеет собственного отладчика скриптов, то разработка и отладка скриптов увеличит на 30-40% время, необходимое на тестирование. Отсутствие средств анализа результатов и построения отчетов о тестировании может привести к потере преимущества автоматизации функционального тестирования перед тестированием вручную – если время, которое требуется для анализа результатов автоматизированного тестирования, сопоставимо со временем, требуемым для проведения ручного тестирования, то о выгоде говорить уже не приходится.

Средства от IBM Rational

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

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

IBM Rational Performance Tester – инструмент нагрузочного и стрессового тестирования, с помощью которого можно выявлять проблемы системной производительности и их причины. Позволяет создавать тесты без написания кода и не требуя навыков программирования. Обеспечивает гибкие возможности моделирования и эмуляции различных пользовательских нагрузок. Выполняет сбор и интеграцию данных о серверных ресурсах с данными о производительности приложений, получаемыми в режиме реального времени.

IBM Rational Functional Tester – набор средств автоматизированного тестирования, позволяющих выполнять функциональное и регрессионное тестирование, тестирование пользовательского интерфейса и тестирование, управляемое данными. Инструмент применяет технологию ScriptAssure (бесшовная проверка достоверности динамических данных) и функции поиска соответствия по шаблону, позволяющие повысить устойчивость сценариев тестирования в условиях частых изменений пользовательских интерфейсов приложений. Тестировщики могут выбрать язык сценариев для разработки и настройки тестов: Java в среде Eclipse или Microsoft Visual Basic .Net в среде Visual Studio .Net.

IBM Rational Quality Manager – решение для реализации процессов управления тестированием и качеством, поддерживает сотрудничество участников групп по разработке программных продуктов, предоставляя им возможность обмениваться информацией, применять средства автоматизации для сокращения графиков выполнения проектов, а также составлять отчеты по проектным показателям для принятия обоснованных решений. Rational Quality Manager может быть дополнен средством управления ресурсами тестирования Rational Test Lab, обеспечивающим учет ресурсов тестирования (серверов), их бронирование, автоматизацию развертывания тестовой среды на сервере и запуск скриптов тестирования, а также отчетность по использованию ресурсов тестирования.

Rational Quality Manager и Rational Test Lab созданы на базе открытой платформы Jazz, которая предоставляет стандартные интерфейсы и удобные возможности для интеграции с решениями партнеров и других производителей.

Наследие Mercury

В ноябре 2006 года в состав компании HP вошла компания Mercury Interactive – известная своими разработками в области тестирования, что позволило существенно дополнить портфель решений HP BTO Software (Business Technology Optimization).

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

HP QuickTest Professional – набор средств автоматизации функционального и регрессионного тестирования программных систем, созданных с помощью основных платформ разработки. Продукт поддерживает такие среды, как Windows Presentation Foundation, Macromedia Flex, Ajax, Delphi, PowerBuilder, .Net, J2EE, обеспечивает работу с Web-сервисами, а также учитывает особенности ERP- и CRM-приложений.

HP LoadRunner – программный продукт для автоматизации нагрузочного тестирования широкого набора программных сред и протоколов. Поддерживает SOA, работу с Web-сервисами, Ajax, RDP, SQL, продуктами Citrix, платформы Java, .Net, а также все основные ERP- и CRM-приложения от PeopleSoft, Oracle, SAP и Siebel. Пакет HP LoadRunner включает в себя более 60 мониторов сбора данных о тестируемой инфраструктуре и предоставляет детальную диагностику по работе приложений.

Примеры

Средства автоматизированного тестирования активно применяются в практике компании «Аплана», помогая, в ряде случаев существенно повысить качество проекта.

Разработка системы автоматизированных функциональных тестов (САФТ) и системы нагрузочных тестов (СНТ) для корпоративного портала одного из крупнейших банков России. Помимо выполнения собственно разработки для заказчика потребовалось выстроить процесс тестирования и выбрать инструмент его управления. По требованию заказчика выбор был ограничен инструментальными средствами компаний HP и IBM. После проведения анализа и получения комплексной оценки предпочтение было отдано продуктам HP QuickTest Professional (QTP) – функциональное тестирование, HP LoadRunner (LR) и Quality Center (QC) – поддержка процесса тестирования. Преимуществом QTP было наличие возможности работы с внутренней структурой Web-приложения (получение полного доступа к свойствам и методам тестовых объектов на уровне, имеющемся у разработчиков приложения) и всесторонняя поддержка работы с таблицами. Основное преимущество LR состояло в наличии специального протокола для тестирования Web-приложений – web click&script. Этот протокол позволяет записывать нагрузочные скрипты в виде взаимодействия с элементами интерфейса (нажатия на кнопки, выбор из списков и т.п.), а не в виде отправки команд на сервер. Был развернут и настроен тестовый репозиторий, который использовался не только для хранения скриптов автоматизированного тестирования и тест-кейсов, но и для учета требований и дефектов. Встроенные отчеты QC позволяют быстро и наглядно получать информацию о покрытии функциональности автоматизированными скриптами, а также отслеживать динамику обнаружения/исправления дефектов.

Разработка системы автоматизированного функционального тестирования Web-сервисов и хранимых процедур для системы Internet-трейдинга одного из крупных российских банков. Приложение должно было обеспечить возможность передачи различных наборов данных тестируемым Web-сервисам и хранимым процедурам, а также получение выходных данных и их автоматический анализ (оценивать правильность работы Web-сервисов и процедур). На момент начала работ на рынке еще не было средств тестирования Web-сервисов (например, таких, как HP Service Test и IBM Rational Functional Tester), поэтому было принято решение о разработке собственной программы для проведения автоматизированного тестирования Web-сервисов. В результате была написана утилита, позволявшая с помощью специального файла, содержащего входные тестовые наборы данных и ожидаемый результат работы Web-сервисов и хранимых процедур, вызывать Web-сервисы и хранимые процедуры с заданными тестовыми данными, а также формировать собственный лог-файл, в котором зафиксированы все расхождения, выявленные во время тестирования. Важно отметить, что анализ результатов, полученных в ходе функционального тестирования, не занял много времени, поскольку вся необходимая информация с заданным уровнем детализации уже содержалась в лог-файле, который мог быть сразу же передан разработчикам Web-сервисов и хранимых процедур и не требовал дополнительной модификации или редактирования. Если бы данный проект выполнялся сейчас, то, вероятнее всего, удалось бы воспользоваться существующими продуктами