ТЕСТИРОВАНИЕ
Сегодня автоматизация тестирования (далее АТ) приобретает все большую популярность у отечественных производителей ПО. Для учебного центра компании VDI, в котором я работаю, эта тенденция проявляется в увеличении числа заказов на обучение. Начиная новый курс по АТ, я обычно рассказываю о преимуществах и недостатках этой методики и даю ряд замечаний и рекомендаций, которые могут пригодиться тестировщикам в их работе. В данной статье я постарался по возможности доступно их изложить.
Если говорить о том, зачем вообще нужно автоматизированное тестирование, то следует помнить, что АТ для компании - это инвестиции в будущее. Если предприятие решило значительно повысить качество своей продукции и перейти на новый уровень производства ПО, то оно с большой вероятностью займется АТ. Переход с ручного тестирования на автоматическое требует много времени и денег, а также серьезной корректировки бизнес-процессов. Однако эти затраты с лихвой окупаются, когда фирма начинает выпускать более качественное ПО, чем у конкурентов, да еще и намного быстрее. А для тестировщика АТ - это инвестиции в настоящее. Средняя зарплата специалиста по АТ в два раза превышает зарплату тестировщика, не обладающего такими навыками. Кроме того, проведение АТ требует от специалиста общего видения проекта, умения планировать и распределять ресурсы, что, несомненно, благотворно сказывается на его карьере.
Теперь немного теории. Автоматизированным называется тестирование с применением средств автоматизации. Существуют три типа тестирования, которые можно автоматизировать: функциональное (в том числе модульное, или unit-тестирование), регрессионное (проверка работоспособности старого функционала и отсутствия ранее исправленных дефектов в новых версиях) и нагрузочное (поведение приложения под рабочей и стрессовой нагрузкой, влияние работающего приложения на системное окружение). Но здесь следует подчеркнуть, что если автоматизацию применить можно, то это далеко не всегда означает, что применять ее нужно. Как и в любом деле, принимая решение об автоматизации, необходимо руководствоваться принципом выгоды.
Если вы рассчитываете выгоду автоматизации для компании, то можно использовать такую формулу:
K= NT х P/(L + T’ х P’),
где K - коэффициент выгоды; N - количество версий программного продукта, которое планируется выпустить в ходе реализации проекта; T - время на ручное выполнение тест-плана тестировщиком; P - зарплата тестировщика; L - стоимость лицензии на средство автоматизации; T’ - время на разработку, поддержку и выполнение автотестов специалистом по АТ; P’ - зарплата специалиста по АТ.
Автоматизация имеет смысл, если K>1. Как видно, это условие будет выполняться только в том случае, если величины N или T достаточно велики. То есть если в компании хорошо поставлен процесс производства ПО (выпускается и предполагается, что и в дальнейшем будет выпускаться, много версий программного продукта) либо специфика производимого ПО такова, что тестировать его вручную сложно (например, какие-нибудь банковские приложения со множеством полей для ввода критических данных). Однако эти условия смягчаются, если вдруг окажется, что L=0.
Рис. 1. Варианты тестирования
Для тестировщика, свободно владеющего средствами автоматизации и не заботящегося о лицензиях, главный критерий принятия решения об автоматизации - возможность сэкономить время. При этом не важно, каков процесс разработки в компании и какой продукт она производит: если у вас есть под рукой знакомое средство АТ и вы понимаете, что с его помощью гораздо быстрее выполните тест, то пользуйтесь им. Скажем, в каком-нибудь простом графическом приложении, обычно тестируемом вручную, появилось поле, для которого надо проверять ввод сотни различных значений. В этом случае автоматизация - разумный выход.
Преимущества автоматизации
Но чем же так хороша автоматизация тестирования?
Во-первых, АТ экономит время. Программа-робот гораздо быстрее "щелкает по кнопкам" или посылает запросы по протоколу, чем любой человек. Значит, программисты быстрее узнают об ошибках и исправят их. И компания получит преимущество перед конкурентами.
Во-вторых, она исключает человеческий фактор. Когда вы целый день выполняете одни и те же или очень похожие действия, то вероятность ошибок к вечеру резко возрастает. Поручите рутинные операции роботу, он не ошибется, а сами займитесь чем-то более творческим, например планированием.
В-третьих, АТ дает возможность работать без графического пользовательского интерфейса. Часто бывает так, что на ранних этапах развития программного продукта этот интерфейс еще не согласован и ПО представляет собой по сути набор каких-то модулей и элементов, которые тем не менее должны правильно работать. Или, например, на одной из итераций добавляют функцию в почти готовый продукт, так что доступа через интерфейс к ней нет. Что уж говорить об обмене данными по протоколам, который может происходить вообще незаметно для пользователя. Хорошие средства АТ могут существенно помочь в таких случаях.
В-четвертых, средства автоматизации позволяют эмулировать многопользовательскую работу для нагрузочного тестирования. Если ваша программа не поддерживает многопользовательский режим, то ее можно запустить на несколько суток и посмотреть, что по прошествии их будет и с программой, и с компьютером. Если же поддерживает и рабочей нормой считается одновременное обращение к вашему приложению нескольких тысяч пользователей, то средства АТ являются единственным способом решить проблему нагрузочного тестирования. Конечно, можно попробовать посадить за компьютеры весь тестовый отдел или даже всю фирму, но согласитесь, что это будет крайне трудоемко. Средства же для нагрузочного АТ позволяют гибко эмулировать многопользовательскую работу так, как вам нужно.
Наконец, практически все средства АТ имеют инструментарий фиксации ошибок и результатов. Они позволяют моделировать различные ошибочные ситуации, строить любые отчеты и диаграммы по вашему вкусу. Иногда это бывает очень удобно, но все же увлекаться этим не стоит, так как результаты вашей деятельности будет оценивать человек, которому обычно нужен минимум четкой и ясной информации.
Проблемы автоматизации
Однако не нужно обольщаться: несмотря на множество преимуществ, АТ имеет ряд ограничений и недостатков, которые необходимо принимать во внимание.
Так, автоматизация требует времени на создание, поддержку и тестирование (!) тестов. Как ни странно, автоматизированное тестирование всегда начинается с тестирования вручную. Вам просто необходимо показать роботу, как, что и с чем он должен делать. Не забывайте, что любое средство АТ - это всего лишь инструмент. Оно не будет писать за вас тест-план, а будет только выполнять то, что вы его попросите, и только так, как попросите. Определили задачу недостаточно четко - робот вас не поймет. Запрограммировали сделать глупость - сделает. Поэтому автотест, как и любая обычная программа, требует бережного отношения - аккуратного создания, постоянной поддержки и тестирования. На все это нужно время, и подчас не многим меньшее, нежели на разработку самого программного продукта.
Кроме того, АТ требует от тестировщика программистских навыков. Обычно считается, что тестировщик - это антипод программиста, и действительно, тестеры часто совсем не умеют программировать. И это даже хорошо, если пользоваться методологией "черного ящика". Но когда речь идет об автоматизации, тут ситуация меняется. Можно, конечно, попробовать создавать автотесты, не прибегая к работе с кодом тестовых скриптов, но с этим скорее всего ничего не получится. Большинство современных средств АТ предлагают широкие возможности для простого и легкого создания автотестов исключительно с помощью GUI-инструментария самого средства - остается только записывать свои действия. Но настоящая профессиональная автоматизация тестирования невозможна без работы непосредственно с кодом тестового скрипта и без отличного знания объектно-ориентированного программирования. Поэтому любой специалист по АТ рано или поздно становится настоящим программистом. Если таковым не является сразу.
Автоматизированные тесты очень чувствительны к среде - программному и даже аппаратному окружению тестируемого приложения. Вы можете очень удивиться, увидев, что один и тот же тест одной и той же версии сегодня проходит совершенно иначе, нежели вчера. Лишние открытые экземпляры приложения, системные процессы, незначительные изменения в описании объектов - все эти незаметные человеку факторы учитываются средством АТ. Поэтому ваша задача - создать фиксированную тестовую среду, максимально подробно описав используемые объекты и выделив для тестирования отдельный компьютер. В общем, позаботиться о чистоте эксперимента. Запомните: совершенно недопустимо применять автоматизацию для непрерывно изменяющегося продукта (над которым, например, спонтанным образом работают программисты). Данное правило справедливо и для тестирования вообще (см. рис. 1). Нельзя этого делать и тогда, когда нет уверенности в том, что тестируется один и тот же объект в одних и тех же условиях (красная линия на рисунке). Поэтому процесс производства ПО должен предусматривать некие периоды, когда изменения не вводятся и тестировщики могут спокойно работать (ступеньки на черном графике).
Наконец, АТ нельзя использовать применительно к объектам, которые может тестировать только человек. Средство АТ можно рассматривать как робота, обладающего неким подобием искусственного интеллекта. Как известно, основная проблема искусственного интеллекта - в распознавании сложных образов и моделей поведения. То есть с помощью автомата нельзя протестировать, например, эргономику (субъективное удобство) интерфейса приложения или корректность фотографии.
Итак, вас не пугают обозначенные выше трудности и вы готовы применять АТ в своем проекте. Однако для начала следует решить некоторые проблемы. Прежде всего - хорошенько продумать, какие тесты нужно автоматизировать, а какие нет. Как и любое принятие решения, это весьма нетривиальная проблема, которая требует учитывать не только мнение тестировщика, но и политику компании. Решая, применять АТ или нет, тестировщик должен четко представлять себе процесс разработки в компании и даже ее планы на будущее, чтобы потом не пришлось объяснять начальству, почему за день до конца проекта еще ничего не протестировано, а только разработаны автотесты.
Следующее, на что нужно обратить внимание, - это качество тест-планов. Как уже говорилось выше, АТ - всего лишь инструмент, не более того. Если вы создали неадекватный тест-план и потом потратили кучу времени на его автоматизацию, то не удивляйтесь, когда у вас начнут гореть все сроки. Аккуратное и адекватное планирование - залог успеха автоматизации.
Немалую проблему при автотестировании составляет также работа с различными платформами и протоколами. Не все инструменты АТ одинаково хорошо работают (если вообще работают) со всеми известными технологиями создания приложений и обмена данными. Например, WinRunner нипочем не захочет тестировать ПО, написанное на .NET, а WebLoad не станет генерировать нагрузку для протокола ODBC. Хороший специалист по автотестированию должен знать всю линейку современных средств в этой области, знать их преимущества и недостатки и уметь выбрать подходящий инструмент в нужный момент, а также подобрать плагин, расширяющий его возможности.
Рис. 2. Схема работы с
инструментами функционального АТ
Отдельно следует сказать о планировании АТ. Для функционального тестирования все просто: здесь основа - требования, явные и неявные. В тестировании не должно быть ничего, кроме проверки требований. Разделяем их по степени критичности и начинаем планировать тесты самых критичных пользовательских бизнес-прецедентов (UseCase). Разумеется, не забываем о балансе между пользой АТ и затратами на нее. Если можно избежать автоматизации, то лучше так и сделать. Ну а дальше - все как в обычном тестировании: соблюдаем максимальное тестовое покрытие требований и неизбыточность тестов.
Для нагрузочного тестирования дело обстоит немного сложнее. Вообще этот вид тестирования имеет три основные цели. Первая - убедиться, что при той или иной нагрузке приложение не сбоит, т. е. отсутствуют ошибки. Вторая - проверить, сохраняется ли с ростом нагрузки удобство (эргономика) приложения. Например, проверяем время отклика сервера на требование "клиент не должен ждать открытия страницы более восьми секунд". Третья - поиск опасных тенденций для системных ресурсов клиента и сервера. Скажем, попытка определить, что происходит с памятью при увеличении количества клиентов или при их длительной работе, нет ли утечек, способных достичь критического значения. Уровней нагрузки тоже три. Минимальная нагрузка (один пользователь) позволяет проверить, что приложение в принципе работоспособно. Рабочая (некоторое количество клиентов, считающееся штатным) - когда приложение должно вести себя безукоризненно. И наконец, стрессовая, или пиковая, нагрузка, которую приложение должно выдерживать в принципе. Конкретные цифры определяет ваш бизнес-аналитик, или менеджер проекта, или даже вы сами, опираясь на статистику. Для разных UseCase эти цифры могут сильно различаться. Не следует забывать и о том, что существует системное тестирование - когда надо проверять общую работоспособность приложения при разнообразной нагрузке.
Средства автоматизации
Теперь, когда мы понимаем основные идеи автоматизации тестирования, его достоинства и недостатки и знаем, на что обращать внимание при планировании, можно приступать к изучению конкретных средств АТ. Хотя на рынке их имеется великое множество, все они в чем-то похожи, поэтому прежде чем обращаться к частным продуктам, следует рассмотреть общие принципы работы с ними.
Для инструментов функционального АТ имеет место схема "с чем - что - как". Чтобы робот мог делать то, что вам нужно, ему надо "объяснить", с чем работать, - построить репозиторий (библиотеку) с подробным описанием всех используемых в тесте объектов; что конкретно делать - записать библиотеку функций, методов или элементарных действий с объектами (если вас не устраивают стандартные методы) - и как делать, в какой последовательности - создать скрипт, содержащий описание тестовых шагов, логики теста и глобальных переменных. Эту схему можно изобразить в виде треугольника со взаимосвязанными вершинами (см. рис. 2).
Для нагрузочного тестирования добавляются варианты многопользовательской и многопротокольной работы. Вы имеете возможность задавать последовательность доступа виртуальных пользователей, указывать, что и когда им нужно делать, - прямо как режиссер. Наверное, поэтому нагрузочные тесты часто называются сценариями. К тому же ваши виртуальные актеры (actor - стандартное название пользователя в универсальном языке моделирования UML) могут говорить на разных языках, т. е. обмениваться данными одновременно по разным протоколам.
В заключение сделаем краткий обзор наиболее известных средств АТ.
Функциональное и регрессионное тестирование
Mercury QuickTest. Из достоинств этого мощного средства компании Mercury (www.mercury.com) следует выделить удобный и понятный пользовательский интерфейс для создания тестов без ручной правки скрипта, из недостатков - необходимость лицензий для расширений и неудобство работы с нестандартными объектами.
Mercury WinRunner. Уже начинающее устаревать средство той же компании. От QuickTest оно отличается тем, что вам приходится много вручную работать с кодом, написанным на специальном языке TSL.
Segue SilkTest. Интересное и относительно удобное средство, предлагаемое компанией Segue Software (www.segue.com), предоставляет широкие возможности для ручной работы со стандартными и нестандартными объектами на объектно-ориентированном языке 4Test.
Rational Robot. Уже почти устаревшее средство от компании IBM (www.ibm.com/ru) с весьма неудобным языком.
Нагрузочное тестирование
Mercury LoadRunner. Очень удобный инструмент - однозначный лидер, обладающий широчайшим спектром возможностей.
Segue SilkPerformer. Хорошее средство со своими достоинствами и недостатками.
RadView WebLoad. Неплохая программа компании RadView Software (www.radview.com) для тестирования Web-приложений, но не более того.
С автором статьи, ведущим тренером по направлению QA учебного центра компании VDI, можно связаться по адресу: alexanderm@moscow.vdiweb.com.
