© Новичков Александр, Ематин Виктор, Закис Алексей, Шкляева Наталья, Подоляк Ольга
Статья была опубликована на сайте www.citforum.ru
Как показывает наша практика построения жизненного цикла разработки ПО и внедрения технологий IBM Rational Software, в России (последние 1-1,5 года) идет лавинообразный всплеск интереса у разрабатывающих ПО организаций к правильному построению процессов жизненного цикла разработки ПО, и особенно к процессу тестирования.
Руководители и разработчики начинают понимать важность процесса тестирования, для повышения качества программных систем. Становится очевидным, что чем позже начать тестировать программную систему, тем выше риски, тем менее надежной она может получиться. Нам приятно осознавать, что тестирование из прикладного процесса с невысоким приоритетом переходит в разряд особо важных процессов, чей жизненный цикл начинается параллельно с разработкой программных систем.
Всем, кто хочет поднять свой профессиональный уровень в тестировании, а также всем, кого интересуют технологии IBM Rational, предназначен данный материал.
Представленный Вашему вниманию материал является нашей попыткой объединить все разрозненные материалы по тестированию воедино, а также передать частицу нашего опыта в этой области. Опираясь на методологию IBM Rational и ее программные средства, для поддержки и осуществления процесса тестирования, мы расскажем что, как и когда использовать при тестировании программных систем.
Очень часто при разработке программного обеспечения приходится сталкиваться с одной из двух проблем. Либо качество разработанного продукта много ниже самых минимальных разумных требований, либо затраты на тестирование превосходят все разумные пределы. К сожалению, бывает и так, что обе проблемы существуют одновременно. И денег на тестирование истрачено много, а качества достичь так и не удалось.
Увы, для большинства фирм низкое качество выпускаемого ПО — верный путь если не к полному исчезновению фирмы, то, по крайней мере, к потере клиентов и существенным финансовым потерям.
Кому нужно не оттестированное ПО, которое может подвести в любой самый неподходящий момент!
Одной из причин такой ситуации является объективная сложность процесса тестирования ПО. Ведь под словом Тестирование может скрываться множество самых различных действий, направленных на решение множества разнообразных задач. Тут и запуск и исполнение программы с целью проверки отсутствия ошибок, и оценка производительности, и контроль наличия и полноты документации и даже качества принятых проектных решений.
Как же наладить процесс тестирования? Какими инструментами лучше воспользоваться? Какой подход выбрать?
Надеемся, что предлагаемая читателям серия статей поможет им найти ответы на эти и многие другие вопросы.
В частности, мы планируем уделить большое внимание таким вопросам, как роль тестирования в Rational Unified Process и требования ГОСТ к процессу тестирования.
Первая статья представляет собой краткий обзор содержания серии и знакомит читателей с кругом вопросов, которые будут обсуждаться в последующих статьях.
Прежде, чем разбираться с деталями, необходимо определить, что же такое тестирование. Даже этот, казалось бы простой вопрос не так прост. Разные источники определяют тестирование его по-разному.
В соответствие с RUP Тестирование — одна из дисциплин RUP. Она ориентирована в первую очередь на оценку качества с помощью следующих методов:
В соответствие с IEEE Std 829-1983 Тестирование — это процесс анализа ПО, направленный на выявление отличий между его реально существующими и требуемыми свойствами (дефект) и на оценку свойств ПО.
По ГОСТ Р ИСО МЭК 12207-99 в жизненном цикле ПО определены среди прочих вспомогательные процессы верификации, аттестации, совместного анализа и аудита. Процесс верификации является процессом определения того, что программные продукты функционируют в полном соответствии с требованиями или условиями, реализованными в предшествующих работах. Данный процесс может включать анализ, проверку и испытание (тестирование). Процесс аттестации является процессом определения полноты соответствия установленных требований, созданной системы или программного продукта их функциональному назначению. Процесс совместного анализа является процессом оценки состояний и, при необходимости, результатов работ (продуктов) по проекту. Процесс аудита является процессом определения соответствия требованиям, планам и условиям договора.
В сумме эти процессы и составляют то, что обычно называют тестированием.
Как не запутаться в этих определениях, на какое из них лучше опираться в ежедневной деятельности — этому будет посвящен следующий выпуск. (следите за обновлениями)
Далее предполагается рассмотреть понятие Тестируемости. Почему одни продукты можно протестировать существенно быстрее, полнее и надежнее, чем другие? Какие проектные решения упрощают, а какие усложняют качественное тестирование? Как связаны Тестирование и Управление рисками?
При выполнении проекта необходимо учитывать, в соответствии с какими стандартами и требованиями будет проводиться тестирование продукта. Какие инструментальные средства будут (если будут) использоваться для поиска и для документирования найденных дефектов. Если помнить о тестировании с самого начала выполнения проекта, тестирование разрабатываемого продукта не доставит неприятных неожиданностей. А значит и качество продукта, скорее всего, будет достаточно высоким.
Все чаще в наше время используются итеративные процессы разработки ПО. Одним из примеров такого подхода является RUP. При использовании такого подхода Тестирование перестает быть процессом "на отшибе", который запускается после того, как программисты написали весь необходимый код. Тестирование оказывается вовлеченным в гущу событий буквально с самого начала работы над проектом. Работа над тестами начинается с самого начального этапа выявления требований к будущему продукту и тесно интегрируется с текущими задачами. И это предъявляет новые требования к тестировщикам. Их роль не сводится просто к выявлению ошибок как можно полнее и как можно раньше. Они должны участвовать в общем процессе выявления и устранения наиболее существенных рисков проекта. Для этого на каждую итерацию определяется цель тестирования и методы ее достижения. А в конце каждой итерации определяется, насколько эта цель достигнута, нужны ли дополнительные испытания, и не нужно ли изменить принципы и инструменты проведения тестов.
В свою очередь, каждый обнаруженный дефект должен пройти через свой собственный жизненный цикл. Дефект заносится в базу дефектов. Аналитик определяет, не является ли он повтором внесенного ранее дефекта. Действительно ли он является дефектом? Руководитель утверждает исполнителя, который приступает к устранению дефекта в соответствие с назначенным дефекту приоритетом. Тестировщик повторяет выполнение теста и убеждается (или не убеждается) в устранении дефекта. Строгое соблюдение жизненного цикла дефекта позволяет существенно улучшить управление проектом, а также избежать "расползания" требований под видом исправления ошибок. И избежать ненужной работы по излишней "полировке" продукта.
Тестирование обычно проводится циклами, каждый из которых имеет конкретный список задач и целей. Цикл тестирования может совпадать с итерацией или соответствовать ее определенной части. Как правило, цикл тестирования проводится для конкретной сборки системы.
RUP предполагает частую сборку разрабатываемой системы. И каждая сборка, как правило, должна быть проверена. В зависимости от задач, которые ставились перед сборкой, проверка может быть более или менее полной. Но, как минимум, она должна включать некоторый набор тестов "на дым", проверяющих, что основная функциональность системы не нарушена, и при ее запуске от компьютера не "валит дым", как из негерметичного трубопровода (для которых исходно такие тесты и применялись).
Типовой цикл тестирования приведен на следующем рисунке.
Рисунок 1. Цикл тестирования
Ниже приведены краткие описания задач, входящих в цикл тестирования.
Определить цели тестирования. Включает выбор тестируемых фрагментов и формулирование задач тестирования (например, определить пригодность архитектуры, проверить реализацию основной функциональности конкретного Сценария использования или проверить выполнение требований Заказчика в полном объеме).
Верифицировать метод тестирования. Настройка среды и инструментов тестирования, выполнение отдельных тестов, подтверждение возможности реализовать задачи и цели тестирования.
Подтвердить правильность сборки. Прежде, чем приступить к детальному тестированию выбранной сборки, проводятся ее тесты "на дым". Эти тесты должны показать, что сборка не содержит явных ошибок, делающих ее дальнейшее тестирование просто нецелесообразным. Для "проходных" сборок, в которых не реализован достаточный объем новой функциональности, тестирование может на этом и заканчиваться.
Тестировать и оценивать. Разрабатываются (уточняются) необходимые тесты, после чего тесты выполняются в ручном или автоматическом режиме, и проводится оценка результатов. Достичь приемлемого уровня достижения целей тестирования. Оценивается, с одной стороны, качество и эффективность тестирования, а, с другой стороны, качество тестируемой системы и ее соответствие требованиям, предъявляемым на данном этапе разработки проекта.
Улучшить набор тестов и другие активы для дальнейшего использования. Описать и сохранить тесты, наборы тестовых данных, настройки среды и инструментальных средств, которые можно использовать в последующих тестовых циклах.
Выполнение задач жизненного цикла сопровождается разработкой различных артефактов (документов, моделей и других материалов проекта). Как обычно в RUP, разработка артефактов может проводиться в разной форме с разными требованиями к способу выполнения, рецензированию и качеству оформления. Например, вы может посмотреть на описание артефакта и решить, что вам в этом проекте он просто не нужен. Если же он вам необходим, вы можете набросать небольшую схему или несколько предложений на обороте старого документа. Правда, по современным представлениям лучше для этого использовать белую доску и фломастеры. В этом случае проще подключить к работе всех заинтересованных лиц или, по крайней мере, довести результаты до их сведения (прежде, чем их стерли). А можно разработать несколько диаграмм, используя инструменты визуального моделирования. Дополнить их сопроводительным текстом, набранным в мощном текстовом редакторе вроде Word, тщательно отредактированным и отформатированным. А потом все это распечатать и переплести. Но на такое оформление стоит тратить время только тогда, когда вы твердо уверены, что это необходимо. Например, если такое оформление оговорено условиями договора.
Ниже представлены основные рабочие артефакты тестировщиков, в той или иной форме связанные со Сценариями использования. Эти документы, если это не оговорено особо, стоит готовить в достаточно аккуратном виде, поскольку, скорее всего, вам придется неоднократно к ним возвращаться самим, а часто еще и передавать их Заказчику или группе сопровождения и технической поддержки системы.
Сценарий тестирования (тест кейс). Это один из основных документов, с которыми имеет дело тестировщик. По сути, упрощенное описание теста. То есть входной информации, условий и последовательности выполнения действий и ожидаемого выходного результата. Учитывая, что даже успешно прошедшие тесты в RUP выполняются неоднократно в ходе регрессионного тестирования, наличие таких описаний необходимо. Однако уровень формальных требований к их оформлению может меняться в очень широких пределах. Одно дело, если вы собираетесь использовать тесты в ходе приемочных испытаний, проводимых Заказчиком, и другое — в ходе внутреннего тестирования коробочного продукта.
Тест скрипт. Обычно говорят о программной реализации теста, хотя скрипт может описывать и ручные действия, необходимые для выполнения конкретного тест кейса.
Набор тестов. Как правило, Сценарии тестирования объединяются в пакеты или наборы. Во-первых, это просто способ группирования тестов со сходными задачами, а, во-вторых, в такой набор можно включать зависимые тесты, которые должны выполняться в определенном порядке (поскольку последующие тесты используют данные, сформированные в ходе выполнения предыдущих).
Список идей тестов. Использование в RUP для анализа и проектирования Системы Сценариев использования существенно упрощает задачу разработки необходимого набора тестов. Основной объем тестов строится как проверка различных вариантов выполнения каждого сценария использования. Однако тесты не сводятся к Сценариям использования, как и задачи тестирования не сводятся только лишь к проверке функциональных требований к системе. Проверка нефункциональных требований может потребовать использования специальных приемов и подходов. Соответствующие тесты не всегда очевидны. Для таких ситуаций и создается Список идей тестов. В него все желающие могут записать Что и/или Как стоит еще проверить. Этот список является внутренним рабочим документом группы тестирования. Наиболее разумная форма его ведения — электронный документ с минимальными формальными требованиями к оформлению.
Модель нагрузки. Сценарии использования, как правило, описывают взаимодействие с системой одного пользователя. Часто этого бывает мало. При тестировании систем необходимо учитывать возможность параллельной работы большого числа пользователей, решающих различные задачи. Модель реальной нагрузки описывает характеристики типового "потока заявок", которые должны использоваться для нагрузочного тестирования, имитирующего работу системы в реальных условиях. Также могут быть созданы стрессовые модели нагрузки для тестирования отказоустойчивости системы.
Дефекты. Основополагающие артефакты процесса тестирования – описывают обнаруженные факты несоответствия системы предъявляемым требованиям. Являются одним из подтипов запросов на изменение, описывающих найденную ошибку или несоответствие на всех этапах тестирования. Хотя базу данных дефектов можно вести в текстовом файле или Excel таблице, предпочтительным является использования специализированного инструментального средства, которое позволяет передавать информацию об обнаруженных дефектах от тестировщиков к разарботчикам, а в обратную сторону – сведения об устранении дефектов. А также формировать необходимые отчеты о тенденциях изменения количества обнаруживаемых и устраняемых дефектов.
Различие задач тестирования приводит, естественным образом, к необходимости использовать весьма разнообразные типы тестирования. По объему проверяемого ПО или его части различают автономное или модульное, сборочное и системное тестирование.
Важную роль в процессе разработки ПО играет приемосдаточное тестирование. В зависимости от специфики проекта оно может производиться с разной степенью формализма и в различных формах.
Как говорят, тестировать нужно чуть-чуть меньше, чем слишком много. Как найти эту грань? Ведь недостаток тестирования может вести к выпуску продукта с существенными недостатками. А "лишнее" тестирование может стоить достаточно дорого, задерживать выпуск продукта и отвлекать тестировщиков от других работ.
Чтобы принять решение о прекращении тестирования, чтобы выбрать оптимальный набор тестов и для многих других целей используются метрики тестирования и качества. Они позволяют оценить покрытие кода продукта тестами, спрогнозировать число ненайденных дефектов, оценить характеристики тестируемой системы.
Различие задач и целей тестирования на протяжении жизненного цикла продукта приводит к необходимости разрабатывать и реализовывать различные стратегии тестирования. Каждая такая стратегия определяет:
Тесты существенно различаются по задачам, которые с их помощью решаются, и по используемой технике. Их можно классифицировать в соответствие с традиционными показателями качества, которые проверяются с их помощью.
Для проверки функциональности ПО используются собственно функциональные тесты, а также тесты безопасности, объема и другие.
Тесты удобства использования (usability) включают тесты на человеческий фактор, эстетику интерфейса и его непротиворечивость, наличие и качество оперативной и контекстной помощи, руководств и учебных материалов. Тестирование надежности ПО производится с помощью интеграционных тестов, тестов структуры и стрессовых тестов и так далее... Различные типы тестов требуют дополнительного рассмотрения.
Приемосдаточные испытания оформляют процесс передачи продукта от Разработчика Заказчику. В зависимости от особенностей продукта и от требований Заказчика они могут проводиться в различной форме. Например, в виде альфа- или бета-тестирования. Или в виде формальных испытаний, проводимых строго в соответствие с утвержденной программой и методиками.
Тестирование производительности включает оценку временных профилей, времени отклика, операционной надежности и некоторых других. Различные тесты на производительность разрабатываются и проводятся на протяжении всего цикла разработки и во время сопровождения программного обеспечения. На стадии "Технический проект" (подробнее о стадиях будет рассказано в следующих выпусках — следите за обновлениями) разработки, при проектировании, тесты проводятся для определения и устранения узких мест в архитектуре программного обеспечения с точки зрения производительности.
На последующих стадиях разработки и в процессе сопровождения тесты на производительность разрабатываются и выполняются для:
Концепция структурного тестирования связана с тестированием внутренней структуры исходного кода программного обеспечения и тестированием Web-сайтов.
Тесты структуры Web-сайтов разрабатываются и выполняются для проверки всех типов связей/ссылок.
В соответствие с RUP при тестировании удобства использования особое внимание следует уделить тестированию пользовательского интерфейса, то есть учету человеческих факторов. Для оценки пользовательского интерфейса следует привлекать членов проектной команды, экспертов и конечных пользователей.
Рекомендуется предъявлять прототип пользовательского интерфейса конечным пользователям системы как можно раньше.
В соответствие с RUP в процессе тестирования создается и используется много различных документов и моделей. Ключевые документы и модели и их назначение перечислены ниже:
Итерационная разработка ПО, на которой базируется RUP, позволяет существенно повысить качество разрабатываемых продуктов. Действительно, программное обеспечение при такой разработке проходит несколько циклов тестирования. За счет этого повышается вероятность обнаружения ошибок. Причем в наибольшей степени это касается наиболее критических модулей и функций, которые в соответствие с RUP разрабатываются первыми.
Итерационная разработка в сочетании с явным определением стратегии тестирования на каждую итерацию позволяют сконцентрироваться на наиболее критических требованиях к ПО. Так на первых итерациях основное внимание уделяется проверке качества и стабильности выбранных архитектурных решений. Определяется, обеспечивает ли выбранная архитектура требуемую производительность системы и выполнение других нефункциональных требований. На последующих итерациях больше внимания уделяется проверке функциональных требований, а также проведению интеграционных и системных тестов.
Использование сценариев использования при выявлении требований, анализе и проектировании ПО позволяет тестировщикам получить с самого начала работы над проектом качественное начальное приближение для разработки тестов.
В соответствие с RUP жизненный цикл программного продукта (не важно, информационной системы, графического редактора или очередной версии популярной компьютерной игры. Но в целях единообразия мы дальше будем говорить, как правило, о системе) состоит из серии относительно коротких итераций.
Рисунок 2. Итерационный жизненный цикл программного продукта
Итерация — это законченный цикл разработки, приводящий к выпуску конечного продукта или некоторой его сокращенной версии, которая расширяется от итерации к итерации, чтобы, в конце концов, стать законченной системой.
Каждая итерация включает, как правило, задачи планирования работ, анализа, проектирования, реализации, тестирования и оценки достигнутых результатов. Однако соотношения этих задач может существенно меняться. В соответствие с соотношением различных задач в итерации они группируются в фазы. В первой фазе — Начало — основное внимание уделяется задачам анализа. В итерациях второй фазы — Разработка — основное внимание уделяется проектированию и опробованию ключевых проектных решений. В третьей фазе — Построение — наиболее велика доля задач разработки и тестирования. А в последней фазе — Передача — решаются в наибольшей мере задачи тестирования и передачи системы Заказчику (хотя форма "передачи" Заказчику существенно различается для заказных систем и коробочных продуктов).
Каждая фаза имеет свои специфические цели в жизненном цикле продукта и считается выполненной, когда эти цели достигнуты.
Так целями Начала является определение назначения и границ разрабатываемой системы.
Целями Разработки являются построение и проверка архитектуры системы, то есть тех типовых решений, на которых будет основываться вся последующая разработка системы. Это и технологические решения (используемые языки и средства разработки, готовые средства), и используемые шаблоны (вплоть до типовых приемов обработки ошибок), и просто код, реализующий ключевые функции системы.
Целями Построения является быстрое и экономичное построение законченной системы. К концу фазы система должна быть готова к бета тестированию (на площадке заказчика). Построение предполагает активное использование и развитие разработанной архитектуры.
Передача нацелена на завершение работ над проектом, включая тестирование, окончательную наладку и передачу системы Заказчику в постоянную эксплуатацию.
Все итерации, кроме, может быть, итераций фазы Начало, завершаются созданием функционирующей версии разрабатываемой системы.
Рисунок 3. Процессы, стадии и итерации в RUP
Исторически предшественниками RUP являются структурные методологии, основанные на использовании так называемого каскадного подхода или водопада. При использовании каскадного подхода тестирование проводится только на завершающих стадиях разработки. При этом тестированию, как правило, подвергаются завершенные модули, а затем полностью собранная система.
Основным недостатком каскадного подхода с точки зрения тестирования считается то, что тестирование начинается на завершающих стадиях проекта, и у разработчиков часто уже не остается времени на устранение обнаруженных дефектов, особенно, если они связаны с ошибками в проектировании архитектуры системы.
В качестве метода описания функциональных требований к системе, а также в качестве естественной единицы для дальнейшего планирования и оценки выполнения работ в RUP используются сценарии использования. Сценарий использования описывает выполнение одной из значимых для пользователя функций (значимая для пользователя, попросту говоря, означает, что реализация ее одной уже позволяет использовать систему с некоторой пользой для Заказчика). Один Сценарий использования может реализовываться в ходе нескольких итераций и даже нескольких фаз. При этом сначала реализуются только основные варианты выполнения сценария, затем дополнительные и только после этого реализуется обработка ошибок и других исключительных ситуаций.
Еще одной важной и одновременно принципиальной особенностью RUP является его ориентация в первую очередь на архитектурные задачи. Разработка системы начинается с создания архитектурного базиса или каркаса. Этот каркас представляет собой исполняемую программу (исполняемую архитектуру), содержащую образцы решения всех принципиальных и/или типовых задач разрабатываемой системы. Подобный подход позволяет устранять наиболее тяжелые риски – архитектурные – на ранних стадиях разработки. Завершение разработки исполняемой архитектуры означает, что далее перед участниками проекта осталась, в основном, задача наращивания "мышечной массы" проекта по проверенным шаблонам и образцам. Кроме того, ориентация на архитектуру означает большое внимание таким вопросам как разработка и строгое следование архитектурным шаблонам, за счет чего существенно повышаются качество и скорость реализации системы.
Перечисленные выше особенности RUP позволяют перейти к изложению основных подходов к тестированию в RUP. Начнем с самого главного — с формулировки концепции качества продукта в RUP.
RUP не ставит своей целью добиться абсолютного качества разрабатываемого продукта. RUP вообще не призывает к достижению недостижимых целей. В частности, этим объясняются и принятая в RUP концепция фаз. В идеале, хорошо бы сначала все проанализировать, потом спроектировать и только потом взяться за программирование. И быть уверенным, что ничего не придется переделывать, потому, что все качественно проанализировано и спроектировано. К сожалению, это недостижимый идеал, как и абсолютное качество программного обеспечения. Как гласит программистская мудрость, каждая обнаруженная в программе ошибка, в лучшем случае, предпоследняя...
Значит ли это, что можно сдавать Заказчику систему "как есть", не задумываясь о том, может ли он ею воспользоваться или ошибки не позволяют этого? Нет, ни в коем случае! RUP предлагает использовать при оценке качества произведенного продукта понятие "достаточно хорошего качества". Использование этого понятия означает, что Разработчик с открытыми глазами оценивает качество продукта, который он представляет Заказчику. И, как минимум, уверен, что поиск и устранение следующей ошибки сейчас обойдутся дороже, чем возможные потери Заказчика при проявлении ошибки и затраты на ее устранение в будущем. Впрочем, для критических систем критерий качественного продукта может быть и более жестким. Важно, что критерий есть, и что он должен быть выполнен. И что при этом качественный продукт — это не обязательно продукт БЕЗ ЕДИНОЙ ошибки.
Достижение достаточно хорошего качества невозможно без тщательного анализа статистических характеристик результатов тестирования. И это тоже одна из принципиальных особенностей подхода RUP.
Теперь, зная, "что такое хорошо и что такое плохо", прейдем к тому, как же "делать хорошо и не делать плохо".
Как следует из особенностей RUP, тестирование должно проводиться практически во всех итерациях. Однако цели и задачи группы тестирования на различных итерациях и, тем более, в различных фазах разработки могут существенно различаться.
В фазе Начало задача группы тестирования — подготовиться к последующей работе по проекту. Понять назначение системы и ориентировочный объем задач тестирования. Подготовить необходимый инструментарий. Продумать критерии качества и критерии завершения тестирования, которые необходимо применить в данном случае.
Есть еще одна работа, о которой часто забывают. В этой фазе тестировщики должны оценить в наиболее общих чертах подход к созданию системы и сформулировать требования, которые необходимо выполнять всем участникам разработки для обеспечения простоты тестирования системы. Например, подготовка специальных имитирующих программ, генераторов тестовых данных или использование инструментальных средств и сред, поддерживаемых имеющимися инструментами тестирования.
В фазе Разработка, как правило, не создаются полностью завершенные фрагменты системы. Поэтому нет смысла тратить время на проверку чистоты графического интерфейса, отработку всех исключительных ситуаций и другие проблемы, которые еще не решались. Тем не менее, их имеет смысл фиксировать и сообщать о них проектировщикам и программистам. Возможно, это поможет.
Основной задачей тестирования в этой фазе является тестирование архитектуры системы. Проводятся наиболее принципиальные проверки производительности системы, ее устойчивости к нагрузкам, надежности выбранного метода взаимодействия между компонентами системы и т.п. Если, как часто бывает в жизни, отложить эти вопросы "на потом", на тот момент, когда система будет уже практически готова то в результате за неделю до сдачи системы Заказчику может оказаться, что она явно не удовлетворяет требованиям к производительности. Нужно переделывать всю схему обработки информации, а времени и ресурсов на это нет.
Фаза Построение — это фаза, в которой тестировщики должны в каждой итерации проверять все более полное выполнение системой требований Заказчика. Основной особенностью работы тестировщиков на этой фазе является необходимость многократно (обычно, в каждой итерации) проверять практически все модули разрабатываемой системы. Ведь в них самих были внесены изменения и дополнения, либо они должны взаимодействовать с измененными или доработанными модулями. Таким образом, в условиях итерационной разработки существенно возрастает необходимый объем тестирования. При этом наиболее массовым становится регрессионное тестирование, на которое приходится основной объем выполняемых тестов. Однако регрессионное тестирование во многом сводится к повторению ранее разработанных тестов. Это позволяет эффективно использовать для регрессионного тестирования средства автоматизации, позволяющие проводить тестирование с минимальным участием тестировщиков. В результате из недостатка большой объем регрессионного тестирования превращается в достоинство. Наиболее принципиальные фрагменты системы, разрабатываемые первыми, проходят несколько циклов тестирования и передаются Заказчику более качественными.
Программный продукт создается в последовательных итерациях. В каждой итерации коллектив разработчиков выполняет несколько сборок программы. Каждая сборка является потенциальным кандидатом для тестирования. Итерация завершается выпуском внутренней версии программы. Эта версия проходит обязательное тестирование. Для каждой версии могут разрабатываться или уточняться тесты. Поскольку процесс разработки является инкрементным (каждая новая итерация добавляет новые возможности разрабатываемой системы), тесты, используемые на ранних итерациях, как правило, могут быть использованы и на последующих для регрессионного тестирования, то есть для проверки того, что ранее реализованная функциональность системы сохранилась в новой итерации. Таким образом, каждая новая итерация подразумевает повторное тестирование всех компонентов, разработанных в предыдущих итерациях, плюс тестирование новых компонентов.
Рисунок 4. Пример тестируемых компонент на различных итерациях
Итерационный подход позволяет повысить качество системы за счет многократного регрессионного тестирования ключевых компонентов системы. Так как на каждой итерации нужно повторять ранее проводившиеся тесты, то желательно иметь определенный набор инструментальных средств, которые обеспечивают автоматизированное тестирование ранее разработанных компонентов.
Еще одна существенная особенность работы в этой и последующей фазах, как уже упоминалось — необходимость собирать статистику обнаруженных и исправленных дефектов. Именно эта статистика, с одной стороны, позволяет оптимально перераспределить силы разработчиков и тестировщиков между модулями и компонентами системы. А с другой стороны, она служит основой для принятия обоснованных решений о достижении продуктом требуемого качества. Сбор достаточного объема статистики, как правило, требует использования средств автоматизации тестирования.
Также уже в фазе Построение желательно наладить активное взаимодействие с Заказчиком и будущими пользователями системы. Без обратной связи с будущими пользователями вряд ли вам удастся разработать не то, что "великую", но хотя бы "приличную" систему. Какой родитель скажет, что у его ребенка столько недостатков, сколько их видит сосед!?
В начале фазы такое взаимодействие может происходить в форме демонстрации системы "из своих рук". По мере совершенствования системы следует предоставлять пользователям все большую свободу в обращении с системой. Конечно, это потребует от всех разработчиков, и от тестировщиков в частности, дополнительных усилий по, хотя бы, минимальному обучению пользователей и сбору и анализу их предложений и замечаний, но результат обычно того стоит.
Передача. В этой фазе тестирование может приобретать специфические формы. Это могут быть и формальные приемочные испытания, и бета тестирование в той или иной форме. Проводить эти виды тестирования в той или иной мере (полностью или частично) может сам Заказчик или третья фирма по поручения Заказчика.
К сожалению, даже при самом высоком качестве разработки редко удается избежать в фазе Передачи внесения изменений в разрабатываемую систему. Хотя в этой фазе желательно ограничиваться минимальными доработками, связанными скорее с "отсечением" недостаточно качественных фрагментов кода, иногда приходится возвращаться и к анализу и проектированию, не говоря уж про разработку. В этом случае приходится возвращаться к автономным и комплексным проверкам доработанных модулей и системы в целом. Более того, придется вернуться к отладке модуля. Отладка модуля, которую наиболее эффективно может провести разработчик, не является тестированием по RUP.
Наверное, можно сколь угодно долго говорить о технологии и об инструментах, поддерживающих ее. Но для того чтобы конечного потребителя окончательно склониться к правильному выбору, приведем реальные цифры и графики эффективности использования предлагаемой технологии и инструментальных средств. В России очень много компаний, которые, так или иначе используют технологии IBM Rational, но это, скорее использование отдельных инструментов, а не процесса. Хотя такое использование и дает эффект, но он не так велик, как было бы при полном переходе на технологию IBM Rational. Для иллюстрации эффективности технологии мы приведем реальные данные по одной из компаний, где полностью внедрили процесс тестирования по RUP в большой проект разработки нескольких последовательных версий большой системы (из области коммуникации).
Рисунок 5 демонстрирует то, каким образом снижается число ошибок в версиях программного продукта при применении технологии IBM Rational. В данном случае речь идет о применении регрессионных тестов. Обратите внимание на точку "пика". Это точка обозначает одновременно максимальную нагрузку, максимальное число найденных ошибок и максимальную задействованность тестировщиков, так как трудоемкость на данном шаге достаточно большая, так как сценарным языком тестирования необходимо сымитировать весь спектр функциональных возможностей тестируемого ПО. Как видно из графика, во всех последующих версиях программного продукта количество найденных ошибок уменьшается. А поскольку процесс тестирования автоматизирован, то сокращаются трудозатраты тестировщиков, соответственно, возрастает объем тестов, и, как следствие программное обеспечение тестируется все более и более полно.
Рисунок 5. Число ошибок, найденных в версиях программного обеспечения.
Следующий рисунок демонстрирует рост числа тестов в ходе разработки. Отправной точкой были 50 ручных тестов, по которым тестировалось программное обеспечение. Ручной труд, как известно, не очень производителен. Автоматизация тестирования позволила кардинально увеличить число тестов (теперь тестировать не только самые главные функции) и довести его число до 450. Разумеется, ручное выполнение такого количества тестов потребовало бы огромных ресурсов. При автоматизации тестирования удалось обойтись прежним количеством тестировщиков.
Рисунок 6. Число тестов во времени.
И в заключении еще несколько характеристик объема тестирования. 50 тестов выполнялись изначально для одной версии, сейчас же проводится тестирование 4-х версий для 30 заказчиков. При этом затраты на тестирование каждой версии уменьшились. К сожалению, в рамках одной статьи мы не можем более полно рассказать о видах тестов, например, о нагрузочных тестах моделирования нагрузок на клиент-серверные системы (снова же из практики: одна из компаний отказалась от разработки своей перспективной коммуникационной системы после проведения всего комплекса нагрузочных тестов, так как система не была готова к реальной нагрузке. Компания оценила риски, сделала выводы, и основываясь на полученных знаниях по другому спроектировала и реализовала систему).
Давайте подведем итоги. Использование RUP обеспечивает:
Внедрение любой методологии существенно упрощается, если есть поддерживающий ее набор инструментов, позволяющий избежать тяжелого рутинного ручного труда. Методология RUP в этом смысле является одной из наиболее "благополучных", поскольку ее поддерживает набор инструментов IBM Rational. Ниже перечислены инструментальные средства непосредственно предназначенные для автоматизации процесса тестирования:
В таблице 1 приведены краткие характеристики инструментов тестирования.
Таблица 1 - Продукты тестирования IBM Rational Software Group
Название продукта |
Краткая характеристика |
| IBM Rational Purify | Инструмент для отслеживания трудно обнаружимых ошибок времени исполнения (например, утечка памяти, выходы за границы массивов при чтении и записи). |
| IBM Rational PureCoverage | Инструмент для отслеживания кода тестируемого приложения (какие именно классы, методы, вызовы функций были протестированы, а какие нет). Это позволяет автоматизировать процесс измерения метрик полноты тестирования (охвата), если для оценки полноты тестирования используется охват кода, а не охват функциональных требований. |
| IBM Rational Quantify | Инструмент анализа производительности работающего приложения. Позволяет выявить фрагменты кода, в наибольшей мере оказывающие влияние на характеристики производительности системы ("бутылочное горлышко"). |
| IBM Rational Robot | Инструмент для автоматизации записи и воспроизведения сценариев тестов. Сценарии тестов записываются на специальном языке программирования и могут быть получены либо автоматически (путем записи действий пользователя при работе с системой), либо вручную. Rational Robot является основой для проведения тестирования функций системы, а также широко используется в инструментах тестирования производительности. |
| IBM Rational TestManager | Средство планирования тестов. Используется для воспроизведения функциональных и нагрузочных тестов, созданных в Rational Robot. Используется для сетевого многоплатформенного тестирования. |
| IBM Rational TestFactory | Инструмент, позволяющий автоматизировать процесс тестирования графических компонентов. Используется для построения карты компонентов приложения. Способен на основе ручного тестирования формировать скрипты для автоматизированного тестирования с использованием Rational Robot. |
| IBM Rational ManualTest | Средство планирования тестов, не поддающихся автоматизации |
| IBM Rational ClearQuest | Средство управления запросами на изменение. В процессе тестирование может использоваться как хранилище дефектов, найденных при тестировании. |
| IBM Rational RequisitePro | Средство для управления требованиями. Позволяет фиксировать связь тестов и проверяемых с их помощью требований. Упрощает оценку полноты тестирования, а также выявление тестов, которые необходимо доработать и провести при изменении требований к системе. |
Использование перечисленных выше инструментальных средств позволяет существенно повысить эффективность тестирования в любом проекте. Однако, тестирование – это не изолированный процесс. Он тесно связан с другими процессами, входящими в состав RUP. Эта интеграция поддерживается также интеграцией соответствующих инструментов.
Основным источником исходных данных для тестирования являются функциональные и нефункциональные требования к разрабатываемой системе. Эти требования могут создаваться в различной форме. Например, это может быть Техническое Задание (по любому из ГОСТов) или артефакты RUP (документ VISION – Концепция, описания сценариев использования и т.д.). Для разработки и сопровождения требований IBM Rational предлагает инструментальное средство IBM Rational RequisitePro. Оно позволяет формировать требования различных типов, отслеживать из изменения и хранить сведения об их важности для системы, сложности выполнения и других атрибутах. Для тестировщиков RequisitePro не только позволяет получить актуальную версию требований к системе, оно также позволяет:
Интеграция RequisitePro и TestManager позволяет легко получать информацию о ходе и результатах тестирования конкретных требований.
Выше уже упоминалось, что для документирования дефектов эффективно применять средство управления изменениями ClearQuest. Оно позволяет организовывать и контролировать выполнение заданий всеми участниками проекта. Для тестировщиков оно не только позволяет сохранять информацию об обнаруженных дефектах, но также определять приоритет дефектов, назначать их для исправления конкретным исполнителям, отслеживать, когда они готовы к повторному тестированию и т.д. При этом ClearQuest позволяет также формировать автоматически различные отчеты о количестве и статусе обнаруженных дефектов, ушедшего на это времени.
Для формирования боле сложных отчетов, которые также могут быть очень полезными для управления процессом тестирования, можно использовать средство IBM Rational SoDA. Основным его назначением является автоматическое формирование проектной документации на основе имеющихся моделей и других артефактов. Оно способно "выбирать" информацию из других инструментальных средств в соответствие с весьма сложными правилами и формировать на ее основе документы в форматах MS Word, MS Excel и HTML.
И последнее по порядку, но не по своему влиянию на весь процесс разработки ПО инструментальное средство IBM Rational ClearCase. Это средство управления версиями. Оно позволяет создавать для разработчиков безопасные рабочие пространства, где все изменения, которые они сделали, но еще не успели отладить, не мешают остальным участникам проекта. При этом оно позволяет вести параллельную разработку нескольких версий продукта (например, для различных платформ). И оно гарантирует возможность вернуться к любой из промежуточной версий любого файла. И даже к той самой, в которой "вчера все работало", как обычно говорят разработчики. При этом можно вернуться не просо к версии одного файла, но к "слепку" или, как это иногда называют, "базовой линии" всей разрабатываемой системы. То есть к согласованному состоянию всех файлов в проекте. А также к соответствующему состоянию требований, моделей и других вспомогательных артефактов.
Следующий рисунок демонстрирует логическую связь между инструментальными средствами IBM Rational. Это очень простая, но в то же время и показательная схема, на которой видно, как происходит взаимодействие между инструментами (в том числе, и не описанными выше, но которые также оказывают свое влияние на процесс тестирования).
Рисунок 7. Интеграция средств Rational
Инструментальные средства Rational глубоко интегрированы друг с другом. Выходная информация одного инструмента является входной для другого. На рисунке показано, какие инструменты и как используются в проекте. Ко всем перечисленным элементам следует добавить IBM Rational Unified Process, как основу описания процессов, IBM Rational SoDA, как основной инструмент формирования проектной документации для всех инструментов IBM Rational, и, самое главное - IBM Rational Project Console – средство визуализации проектных метрик.
За дополнительной информацией обращайтесь в компанию Interface Ltd.
Обсудить на форуме IBM Rational Software
| INTERFACE Ltd. |
| ||||
