Тестовая модель в тестировании форм. RUP. Тестирование. Проблема: требования не атомарны

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

Д. Гантер, С. Барнет, Л. Гантер.
Интеграция Windows NT и Unix

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

Что и зачем тестируется

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

Итак, какие факторы учитываются в таких случаях, что является объектом исследований и какого рода испытания наиболее популярны?

Критерии тестирования обычно таковы:

• функциональные возможности продукта;
• простота освоения;
• легкость установки;
• качество документации и поддержки;
• производительность;
• для аппаратуры иногда учитывается конструктивное исполнение.

Встречаются и весьма двусмысленные критерии. Не так давно в одном из обзоров Web-серверов при выставлении общей оценки в качестве положительного фактора рассматривалась "высокая степень интеграции с операционной системой". Но если сбой приложения вызывает сбой операционной системы (вероятность чего пропорциональна степени интегрированности) — то такое ли уж это преимущество?

Равна ли сотня кроликов одному тигру?

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

Типичный пример — сравнение старших моделей систем на процессорах Intel с младшими в линии RISC-платформ. Да, действительно, в заданном ценовом диапазоне машины с Intel-архитектурой сопоставимы или, в некоторых случаях, даже превосходят RISC-системы. Однако то, что является потолком для одних платформ, — лишь начальный уровень для других и т. д.

Выводы: относитесь критически к критериям, по которым оценивается продукт, — у вас и у тестеров могут оказаться разные вкусы. Попробуйте сказать приверженцам Unix, что ради удобства графического интерфейса конфигурирования системы стоит смириться с необходимостью перезагрузки после изменения IP-параметров. Что же касается компактности исполнения системного блока, то это хорошо до тех пор, пока вам не понадобится вставить в slim-корпус дополнительный винчестер.

Одним словом — переосмысливайте результаты тестов в соответствии со своими нуждами.

Специфика тестирования серверов

Если компьютер не включается — он неисправен.
Если не выключается — он сервер.
Народная примета

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

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

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

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

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

Условия проведения тестирования

Для начала немного теории. Гленфорд Майерс в своей работе "Надежность программного обеспечения" приводит несколько "аксиом тестирования". Попробуем, следуя им, рассмотреть, что и как надо тестировать.

Время от времени в компьютерной прессе появляются сообщения почти спортивного характера: продукт фирмы N показал рекордное быстродействие в тесте M. Насколько информативны тесты, проведенные фирмами-производителями?

Невозможно тестировать свою собственную программу

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

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

С таким явлением автор столкнулся, пытаясь настроить Netscape Enterprise Web Server под Solaris (SPARC). Производительность сервера по http-протоколу удалось поднять почти в 6 (!) раз (по данным тестирования с MS InetLoad), однако на комплексном тесте увеличение оказалось трехкратным, в то время как быстродействие POP3-сервера возросло вдвое, News-сервера — осталось неизменным, а SMTP показал в два раза худшие результаты, чем до внесения изменений.

Кроме того, производители, зная характеристики того или иного тестового набора, могут оптимизировать параметры системы именно под него. Пример тому — Web-страничка Netscape, где приведены рекомендации, как настроить Netscape Enterprise Server для проведения тестирования с помощью SPECweb96 .

Тестирование проводится для обнаружения ошибок

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

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

Здесь уместны два примечания:

1. Модель поведения пользователя.

По отношению к пользователям администратор должен быть пессимистом. Соответственно должно строиться и тестирование "на выживание".

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

2. Сервис перестал справляться с обработкой запросов: возможные варианты.

По степени серьезности такие отказы можно разделить на 4 группы:

• снижение производительности — сервис не успевает провести обработку, но отвечает корректно (возвращает соответствующий код ошибки — "Too many connections" и т. п.);
• аварийное завершение работы сервиса, не влекущее за собой негативных последствий для системы: соответствующая программа завершила работу, выгружена из памяти, системные ресурсы освобождены;
• аварийное завершение работы сервиса, отрицательно влияющее на производительность системы. Программа либо "висит" в списке процессов, не высвобождая ресурсы, либо в процессе завершения захватывает дополнительные ресурсы;
• крах системы — в лучшем случае с последующей перезагрузкой, в худшем — с зависанием.

Готовьте тесты как для правильных, так и для неправильных входных данных

Эта аксиома детализирует предыдущую с точки зрения входных информационных потоков.

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

Совет, взятый из той же книги Г. Майерса: "старайтесь, чтобы система не рассердила пользователя, ибо это может привести к некоторым неожиданным ситуациям на входе — правило # 5 минимизации ошибок пользователя в диалоговых системах. Быть пессимистом — не значит быть мизантропом!".

А как насчет news-сервера — установлен ли там максимальный размер статьи?

Может ли кто-то, вознамерившись загрузить половину вашего FTP-сайта, открыть три десятка параллельных ftp-сессий, и если да, то как это повлияет на ваш канал и работу других желающих посетить FTP?

В качестве примера, подтверждающего корректность такого подхода, можно упомянуть инцидент с ракетным крейсером Yorktown, где ошибка ввода оператора повлекла за собой отказ системы управления двигателями . Или еще один, приведенный самим Майерсом: "Операторы Нью-Йоркской системы диспетчеризации полицейских машин SPRINT в свободное время развлекались тем, что пытались вывести ее из строя, вводя заведомо неправильные сообщения". Это происходило в начале 70-х. Может, с тех пор нравы и смягчились, но это маловероятно.

Избегайте невоспроизводимых тестов

В случае тестирования серверов и серверного ПО эта аксиома особенно актуальна. Во-первых, для их тестирования необходимо наличие аппаратно разделенных генераторов нагрузки (Client-Side Load Generators, CSLG) — обычно это группы рабочих станций, выполняющих клиентскую часть теста и обеспечивающих поток запросов на сервер. Во-вторых, на результаты может повлиять состояние сети, соединяющей сервер и CSLG. Кроме того, во многих случаях производительность зависит от предыстории обращений к серверу. Большинство серверных приложений использует кэширование. Скорость обращения к кэш-памяти значительно выше скорости обращения к дисковой подсистеме. Кэш приложения может наполняться вследствие предварительных или отладочных прогонов тест-программ — и соответственно могут меняться результаты. Более того, при комплексном тестировании возможно перекрестное влияние приложений — так, количество обработанных за единицу времени сложных запросов к POP3- или IMAP-серверам зависит от размера почтового спула, который может быть увеличен предыдущим проведением SMTP-теста. И наконец, на производительность влияют настройки операционной системы.

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

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

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

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

Самый лучший способ оценить, хорошо ли мы протестировали продукт – проанализировать пропущенные дефекты. Те, с которыми столкнулись наши пользователи, внедренцы, бизнес. По ним можно многое оценить: что мы проверили недостаточно тщательно, каким областям продукта стоит уделить больше внимания, какой вообще процент пропусков и какова динамика его изменений. С этой метрикой (пожалуй, самой распространённой в тестировании) всё хорошо, но… Когда мы выпустили продукт, и узнали о пропущенных ошибках, может быть уже слишком поздно: на “хабре” появилась про нас гневная статья, конкуренты стремительно распространяют критику, клиенты потеряли к нам доверие, руководство недовольно.

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

Зачем оценивать?

1. Поиск своих слабых зон. Естественно, это нам нужно? не чтобы просто погоревать, а чтобы знать, где требуются улучшения. Какие функциональные области не покрыты тестами? Что мы не проверили? Где наибольшие риски пропуска ошибок?
2. Редко по результатам оценки покрытия мы получаем 100%. Что улучшать? Куда идти? Какой сейчас процент? Как мы его повысим какой-либо задачей? Как быстро мы дойдём до 100? Все эти вопросы приносят прозрачности и понятности нашему процессу , а ответы на них даёт оценка покрытия.
3. Фокус внимания. Допустим, в нашем продукте около 50 различных функциональных зон. Выходит новая версия, и мы начинаем тестировать 1-ю из них, и находим там опечатки, и съехавшие на пару пикселей кнопки, и прочую мелочь… И вот время на тестирование завершено, и эта функциональность проверена детально… А остальные 50? Оценка покрытия позволяет нам приоритезировать задачи исходя из текущих реалий и сроков.

Как оценивать?

Оцениваем покрытие требований тестами

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

Проблема: требования не атомарны.

Таким образом, наличие теста на требование нам вообще ничего не гарантирует! Что значит в таком случае наша статистика покрытия? Примерно ничего! Придётся решать!

1. Автоматический расчёт покрытия требований тестами в таком случае можно убрать – он смысловой нагрузки всё равно не несёт.
2. По каждому требованию, начиная с наиболее приоритетных, готовим тесты. При подготовке анализируем, какие тесты потребуются этому требованию, сколько будет достаточно? Проводим полноценный тест-анализ, а не отмахиваемся «один тест есть, ну и ладно».
3. В зависимости от используемой системы, делаем экспорт/выгрузку тестов по требованию и… проводим тестирование этих тестов! Достаточно ли их? В идеале, конечно, такое тестирование нужно проводить с аналитиком и разработчиком этой функциональности. Распечатайте тесты, заприте коллег в переговорке, и не отпускайте, пока они не скажут «да, этих тестов достаточно» (такое бывает только при письменном согласовании, когда эти слова говорятся для отписки, даже без анализа тестов. При устном обсуждении ваши коллеги выльют ушат критики, пропущенных тестов, неправильно понятых требований и т.д. – это не всегда приятно, но для тестирования очень полезно!)
4. После доработки тестов по требованию и согласования их полноты, в системе этому требованию можно проставить статус «покрыто тестами». Эта информация будет значить значительно больше, чем «тут есть хотя бы 1 тест».

Конечно, такой процесс согласования требует немало ресурсов и времени, особенно поначалу, до наработки практики. Поэтому проводите по нему только высокоприоритетные требования, и новые доработки. Со временем и остальные требования подтянете, и все будут счастливы! Но… а если требований нет вообще?

Проблема: требований нет вообще.

1. Создаём фичелист (feature list). Сами! В виде google-таблички, в формате PBI в TFS – выбирайте любой, лишь бы не текстовый формат. Нам ещё статусы собирать надо будет! В этот список вносим все функциональные области продукта, и постарайтесь выбрать один общий уровень декомпозиции (вы можете выписать объекты ПО, или пользовательские сценарии, или модули, или веб-страницы, или методы API, или экранные формы…) – только не всё это сразу! ОДИН формат декомпозиции, который вам проще и нагляднее всего позволит не пропустить важное.
2. Согласовываем ПОЛНОТУ этого списка с аналитиками, разработчиками, бизнесом, внутри своей команды… Постарайтесь сделать всё, чтобы не потерять важные части продукта! Насколько глубоко проводить анализ – решать вам. В моей практике всего несколько раз были продукты, на которые мы создали более 100 страниц в таблице, и это были продукты-гиганты. Чаще всего, 30-50 строк – достижимый результат для последующей тщательной обработки. В небольшой команде без выделенных тест-аналитиков большее число элементов фичелиста будет слишком сложным в поддержке.
3. После этого, идём по приоритетам, и обрабатываем каждую строку фичелиста как в описанном выше разделе с требованиями. Пишем тесты, обсуждаем, согласовываем достаточность. Помечаем статусы, по какой фиче тестов хватает. Получаем и статус, и прогресс, и расширение тестов за счёт общения с командой. Все счастливы!

Но… Что делать, если требования ведутся, но не в трассируемом формате?

Проблема: требования не трассируемы.

1. Создаём фичелист (см. выше), но без детального описания требований.
2. По каждой фиче собираем воедино ссылки на ТЗ, спецификации, инструкции, и прочие документы.
3. Идём по приоритетам, готовим тесты, согласовываем их полноту. Всё то же самое, только благодаря объединению всех документов в одну табличку повышаем простоту доступа к ним, прозрачные статусы и согласованность тестов. В итоге, у нас всё супер, и все счастливы!

Но… Ненадолго… Кажется, за прошлую неделю аналитики по обращениям заказчиков обновили 4 разные спецификации!!!

Проблема: требования всё время меняются.

1. Допустим, у вас уже собраны ссылки на ТЗ и спецификации в виде фичелиста-таблицы, PBI, требований, заметок в Wiki и т.д. Допустим, у вас уже есть тесты на эти требования. И вот, требование меняется! Это может означать изменение в RMS, или задачу в TMS (Task Management System), или письмо в почте. В любом случае, это ведёт к одному и тому же следствию: ваши тесты неактуальны! Или могут быть неактуальны. А значит, требуют обновления (покрытие тестами старой версии продукта как-то не очень считается, да?)
2. В фичелисте, в RMS, в TMS (Test Management System – testrails, sitechco, etc) тесты должны быть обязательно и незамедлительно помечены как неактуальные! В HP QC или MS TFS это можно делать автоматически при обновлении требований, а в google-табличке или wiki придётся проставлять ручками. Но вы должны видеть сразу: тесты неактуальны! А значит, нас ждёт полный повторный путь: обновить, провести заново тест-анализ, переписать тесты, согласовать изменения, и только после этого пометить фичу/требование снова как «покрыто тестами».

В этом случае мы получаем все бенефиты оценки тестового покрытия, да ещё и в динамике! Все счастливы!!! Но…
Но вы так много внимания уделяли работе с требованиями, что теперь вам не хватает времени либо на тестирование, либо на документирование тестов. На мой взгляд (и тут есть место религиозному спору!) требования важнее тестов, и уж лучше так! Хотя бы они в порядке, и вся команда в курсе, и разработчики делают именно то, что нужно. НО НА ДОКУМЕНТИРОВАНИЕ ТЕСТОВ ВРЕМЕНИ НЕ ОСТАЁТСЯ!

Проблема: не хватает времени документировать тесты.

1. Вам всё равно нужны требования, как полноценные требования или как фиче-лист, поэтому какой-то из вышеописанных разделов, в зависимости от работы аналитиков на проекте, будет всё равно необходим. Получили требования / фичелист?
2. Описываем и устно согласовываем вкратце стратегию тестирования, без документирования конкретных тестов! Эта стратегия может быть указана в столбце таблицы, на странице вики или в требовании в RMS, и она должна быть опять же согласована. В рамках этой стратегии проверки будут проводиться по-разному, но вы будете знать: когда это последний раз тестировалось и по какой стратегии? А это уже, согласитесь, тоже неплохо! И все будут счастливы.

Но… Какое ещё «но»? Какое???

Говорите, все обойдём, и да пребудут с нами качественные продукты!

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

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

Каскадная модель (Линейная последовательная модель жизненного цикла ПО)

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

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

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

Узнайте больше о каскадной модели из предыдущей статьи .

V-Model (Модель верификации и валидации)

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

Схема данной модели показывает принцип разделения задач на две части. Те, которые относятся к дизайну и разработке, размещены слева. Задачи, относящиеся к тестированию ПО, размещены справа:

Основные этапы этой методологии могут изменяться, однако обычно они включают следующие:

• Этап определения требований . Приемочное тестирование относится к этому этапу. Его основная задача состоит в оценке готовности системы к финальному использованию
• Этап, на котором происходит высокоуровневое проектирование, или High-Level Design (HDL) . Этот этап относится к системному тестированию и включает оценку соблюдения требований к интегрированным системам
• Фаза детального дизайна (Detailed Design) параллельна фазе интеграционного тестирования, во время которой происходит проверка взаимодействий между различными компонентами системы
• После этапа написания кода начинается другой важный шаг — юнит-тестирование. Очень важно убедиться в том, что поведение отдельных частей и компонентов ПО корректно и соответствует требованиям

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

Инкрементная модель

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

1. дизайн и разработка
2. тестирование
3. реализация.

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

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

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

Спиральная модель

Спиральная модель это методология тестирования ПО, которая основана на инкрементном подходе и прототипировании. Она состоит из четырех этапов:

1. Планирование
2. Анализ рисков
3. Разработка
4. Оценка

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

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

Читайте подробнее o спиральной модели в предыдущем блог посте .

Agile

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

Узнайте больше об Agile (прим. — статья на английском языке) .

Экстремальное программирование (XP, Extreme Programming)

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

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

Scrum

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

• Участие в Scrum планировании
• Поддержка в юнит-тестировании
• Тестирование пользовательских историй
• Сотрудничество с заказчиком и владельцем продукта для определения критериев приемлемости
• Предоставление автоматического тестировании

Более того, участники QA-отдела должны присутствовать на всех ежедневных собраниях, как и другие члены команды, чтобы обсудить, что было протестировано и сделано вчера, что будет протестировано сегодня, а также общий прогресс тестирования.

В то же время принципы Agile методологии в Scrum к появлению специфических особенностей:

• Оценка усилий, необходимых для каждой пользовательской истории является обязательной
• Тестировщик должен быть внимательным к требованиям, поскольку они могут постоянно изменяться
• Риск регрессии возрастает вместе с частыми изменениями в коде
• Одновременность планирования и выполнения тестов
• Недопонимание между членами команды в случае если требования заказчика не до конца ясны

Узнайте больше о методологии Scrum из предыдущей статьи .

Заключение

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

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

Аннотация: Основные понятия тестирования. Фазы и этапы тестирования. Типы тестов. Разработка, управляемая тестами (Test Driven Development)

Введение

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

С технической точки зрения тестирование заключается в выполнении приложения на некотором множестве исходных данных и сверке получаемых результатов с заранее известными (эталонными) с целью установить соответствие различных свойств и характеристик приложения заказанным свойствам. Как одна из основных фаз процесса разработки программного продукта ( Дизайн приложения - Разработка кода - Тестирование), тестирование характеризуется достаточно большим вкладом в суммарную трудоемкость разработки продукта. Широко известна оценка распределения трудоемкости между фазами создания программного продукта: 40%-20%-40%.

С точки зрения математики тестирование можно рассматривать как интерпретацию некоторой формулы и проверки ее истинности на некоторых множествах. Действительно, программу можно представить в виде формулы f = f1* f2* f3*... * fn , где f1 , f 2 , ... fn - операторы языка программирования, а их суперпозиция - программа .

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

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

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

Динамическое тестирование (собственно тестирование) осуществляет выявление ошибок только на выполняющейся программе с помощью специальных инструментов автоматизации тестирования - Testbed или Testbench.

Основы тестирования

Классы критериев тестирования

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

• Условие критерия тестирования команд (критерий С0) - набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза.
• Условие критерия тестирования ветвей (критерий С1) - набор тестов в совокупности должен обеспечить прохождение каждой ветви не менее одного раза.
• Условие критерия тестирования путей (критерий С2) - набор тестов в совокупности должен обеспечить прохождение каждого пути не менее 1 раз.

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

Выделяют следующие частные виды функциональных критериев :

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

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

Мутационные критерии ориентированы на проверку свойств программного изделия на основе подхода Монте-Карло.

Метод мутационного тестирования состоит в том, что в разрабатываемую программу P вносят мутации (мелкие ошибки), т.е. искусственно создают программы- мутанты P1, P2... . Затем программа P и ее мутанты тестируются на одном и том же наборе тестов (X, Y).

Если на наборе (X, Y) подтверждается правильность программы P и, кроме того, выявляются все внесенные в программы- мутанты ошибки, то набор тестов (X, Y) соответствует мутационному критерию, а тестируемая программа объявляется правильной. Если некоторые мутанты не выявили всех мутаций, то надо расширять набор тестов (X, Y) и продолжать тестирование.

Фазы тестирования

При тестировании как правило выделяют три фазы: модульное, интеграционное и системное тестирование.

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

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

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

Системное тестирование производится над проектом в целом с помощью метода "черного ящика". Структура программы не имеет никакого значения, для проверки доступны только входы и выходы, видимые пользователю. Тестированию подлежат коды и пользовательская документация.

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

Этапы тестирования

Каждая фаза тестирования включает в себя следующие этапы:

1. Определение целей (требований к тестированию), включающее следующую конкретизацию: какие части системы будут тестироваться, какие аспекты их работы будут выбраны для проверки, каково желаемое качество и т. п.
2. Планирование : создание графика (расписания) разработки тестов для каждой тестируемой подсистемы; оценка необходимых человеческих, программных и аппаратных ресурсов; разработка расписания тестовых циклов . Важно отметить, что расписание тестирования обязательно должно быть согласовано с расписанием разработки создаваемой системы.
3. Разработка тестов (тестового кода для тестируемой системы).
4. Выполнение тестов : реализация тестовых циклов .
5. Анализ результатов .

Тестовый цикл - это цикл исполнения тестов, включающий фазы 4 и 5 тестового процесса. Тестовый цикл заключается в прогоне разработанных тестов на некотором однозначно определяемом срезе системы (состоянии кода разрабатываемой системы). Обычно такой срез системы называют build .

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

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

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

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

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

Типы тестов

В тестовом плане определяются и документируются различные типы тестов .

Типы тестирования по виду подсистемы или продукта таковы:

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

Типы тестирования по способу выбора входных значений:

1. Функциональное тестирование, при котором проверяется:
   • покрытие функциональных требований;
   • покрытие сценариев использования.
2. Стрессовое тестирование, при котором проверяются экстремальные режимы использования продукта.
3. Тестирование граничных значений.
4. Тестирование производительности.
5. Тестирование на соответствие стандартам.
6. Тестирование совместимости с другими программно-аппаратными комплексами.
7. Тестирование работы с окружением.
8. Тестирование работы на конкретной платформе.

Test Driven Development

Рассмотрим подход к тестированию, несколько отличающийся от приведенного выше. Разработка через тестирование ( Test Driven Development - TDD) - процесс разработки программного обеспечения, который предусматривает написание и автоматизацию модульных тестов еще до момента написания соответствующих классов или модулей. Это гарантирует, что все обязанности любого элемента программного обеспечения определяются еще до того, как они будут закодированы.

TDD задает следующий порядок этапов программирования:

• Красный - напишите небольшой тест, который не работает, а возможно, даже не компилируется.
• Зеленый - заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал.
• Рефакторинг - удалите из написанного вами кода любое дублирование.
• Освоив TDD, разработчики обнаруживают, что они пишут значительно больше тестов, чем раньше, и двигаются вперед маленькими шагами, которые раньше могли показаться бессмысленными.

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

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

Итоги

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

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

Кроме того, продолжаются исследования в области тестов, ориентированных на конкретную модель разработки (водопадную, спиральную) или на конкретную парадигму программирования. Например, для тестирования компонентно-ориентированных систем предлагается тестирование при помощи агентов. Для тестирования активных Java-апплетов предлагают использовать нейросети. Для тестирования агентов, существующих в web (роботы, пауки), предлагают использовать системы, основанные на знаниях.

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

Традиционный подход к автоматическим тестам выглядит примерно так - тестописатель изучает тестируемую систему и после этого руками пишет каждый отдельный сценарий для проверки искомой системы. Кто-то может написать тут гордое слово "handcrafted", а я называю это словом "handjob". А все потому, что обычно этот подход к созданию и написанию тестов страдает от двух проблем:

• "Парадокс пестицида", описанный Борисом Бейзером в 1990-м году. Заключается он в том, что тесты все менее и менее эффективны в отлове багов, так как баги, для обнаружения которых эти тесты написаны, уже найдены и починены. Если же этого не происходит, то возникают серьезные вопросы к написанному коду и к рабочим процессам
• Тесты статичны и их сложно менять, в то время как тестируемая система имеет свойство постоянно эволюционировать, обрастать новым функционалом и менять поведение старого. И тесты нужно менять каждый раз, когда функционал изменяет внешний вид программы или ее поведение. И с ростом сложности обновления тестов оправдывать чудовищные издержки на поддержку тестов становиться все сложнее.

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

Что такое модель?

Модель - это описание тестируемой системы. Формальная спецификация вполне сойдет. Модель должна быть сильно проще описываемой системы и как-то помогать нам понимать и предсказывать поведение тестируемого продукта.

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

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

Что такое Model-Based Testing?

Это довольно немолодая идея использовать формально описанные модели для того, чтобы сделать тестирование ПО более дешевым и простым занятием. Само Model-Based Testing это такая "продвинутая" техника тестирования через "черный ящик". У нее есть ряд бонусов перед традиционными методами:

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

И самое важное - формально описанные модели в комбинации с зачатками теории графов помогает легко и непринужденно генерировать сотни тестов.

Зоркий поклонник Agile может воскликнуть "эй! у нас есть BDD и оно покрывает первые три пункта и еще это спецификация!". Я же отвечу "нихрена подобного - ваши примеры станут нормальной спецификацией только тогда, когда короля Шака Зулу можно будет считать спецификацией на все человечество".

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

Короткий ликбез по теории графов

Теория графов зародилась в 1736-м году в стареньком Прусском городе Кёнингсберге. Город стоял на двух берегах реки и попутно занимал еще и пару островов посреди этой самой реки. Жители этого города от безделья пытались придумать как посетить все семь мостов не проходя ни по одному дважды. Решали на практике, во время прогулок, и в теории, во время кухонных посиделок. Долгое время никто не мог доказать или опровергнуть возможность существования данного маршрута, пока не пришел зануда Эйлер и не испортил горожанам праздник.

Эйлер придумал изобразить каждый кусок суши как вершину графа, а мосты - ребрами графа.

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

С тех пор граф, в котором все вершины имеют четное количество ребер называется "Эйлеровым Графом". А полный обход этого графа носит гордое имя "Эйлерова пути".

И после этого жителям Кёнингсберга пришлось найти себе другое развлечение. Только один китайский математик Мэй-Ку Куан все морочил себе голову этими мостами. А беспокоил его следующий вопрос:

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

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

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

И в честь Куана эту задачку назвали "задачей китайского почтальона".

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

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

И если в случае Эйлерова Пути или Проблемы Китайского Почтальона мы оперировали дугами касающимися вершин, то тут приходится принимать во внимание еще и направление движения. И доля "Эйлеризации" такого графа нам требуется чтобы количество входящих в вершину дуг равнялось количеству исходящих. И считая каждую входящую дугу как "+1", а исходящую как "-1" мы можем вычислять "полярность" каждой вершины орграфа. Например вершина в двумя входящими и одной исходящей дугой имеет полярность "2 - 1 = 1".

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

Причем тут тестирование?

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

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

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

Такой подход как раз активно использовался для тестирования конечных автоматов. К тому же это требование естественно вытекает из комбинаторной техники дизайна тестов под названием "все пары".

Решение предложил некий де Брюийн. Алгоритм выглядит примерно так:

• Рисуем сбоку граф, где каждое ребро исходного графа является вершиной.
• Там где у исходного графа дуга "1" входит в вершину, откуда выходит дуга "2" рисуем в свежеиспеченном графе дугу из вершины "1" в вершину "2".
• Эйлеризуем полученный граф.
• Рисуем Эйлеров путь на данном графе.

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

Про то, зачем сюда добавляют Цепи Маркова, и как обычно решается распараллеливание таких тестов я напишу позже. А пока подведем краткие итоги.

Итого

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

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

И, поскольку Теория Графов позволяет нам работать непосредственно с моделью:

• Новые обходы можно автоматически генерировать при изменении модели
• Наши тесты могут легко и непринужденно меняться в рамках одной и той же модели
• Различные алгоритмы обхода могут удовлетворять различным потребностям тестирования
• Полученные алгоритмы обхода легко можно переиспользовать в совершенно новой среде