Автоматизация процесса тестирования при помощи методологии и инструментальных средств IBM Rational

Всем, кто хочет поднять свой профессиональный уровень в тестировании, а также всем, кого интересуют технологии IBM Rational, предназначен данный материал. Материал представляет из себя набор статей в тематике тестирования, которые будут пополняться практической информацией. Обновления Вы можете отследить по рассылке.
Автор: Новичков Александр, Костиков Александр, Ематин Виктор, Закис Алексей, Шкляева Наталья, Подоляк Ольга

О данном материале

Как показывает наша практика построения жизненного цикла разработки ПО и внедрения технологий IBM Rational, в России (последние 1-1,5 года) идет лавинообразный всплеск интереса у разрабатывающих ПО организаций к правильному построению процессов жизненного цикла разработки ПО, и особенно к процессу тестирования.

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

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

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

Соответственно, на протяжении всего времени, мы будем не только писать новые части, но и изменять и дополнять существующие (например, практически постоянно будет обновляться ГЛОССАРИЙ и введение).

Материал будет состоять из 4-5 больших частей: из введения, описания инструментов автоматизации тестирования, глоссария и приложений.

Часть 1 — введение в процесс тестирования

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

Кому нужно не оттестированное ПО, которое может подвести в любой самый неподходящий момент!

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

Надеемся, что предлагаемая читателям серия статей поможет им найти ответы на эти и многие другие вопросы.

В частности, мы планируем уделить большое внимание таким вопросам, как роль тестирования в Rational Unified Process и требования ГОСТ к процессу тестирования.

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

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

В соответствие с RUP Тестирование — одна из дисциплин RUP. Она ориентирована в первую очередь на оценку качества с помощью следующих методов:

В соответствии с IEEE Std 829-1983 Тестирование — это процесс анализа ПО, направленный на выявление отличий между его реально существующими и требуемыми свойствами (дефект) и на оценку свойств ПО.

По ГОСТ Р ИСО МЭК 12207-99 в жизненном цикле ПО определены среди прочих вспомогательные процессы верификации, аттестации, совместного анализа и аудита. Процесс верификации является процессом определения того, что программные продукты функционируют в полном соответствии с требованиями или условиями, реализованными в предшествующих работах. Данный процесс может включать анализ, проверку и испытание (тестирование). Процесс аттестации является процессом определения полноты соответствия установленных требований, созданной системы или программного продукта их функциональному назначению. Процесс совместного анализа является процессом оценки состояний и, при необходимости, результатов работ (продуктов) по проекту. Процесс аудита является процессом определения соответствия требованиям, планам и условиям договора.

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

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

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

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

В свою очередь, каждый обнаруженный дефект должен пройти через свой собственный жизненный цикл. Дефект заносится в базу дефектов. Аналитик определяет, не является ли он повтором внесенного ранее дефекта. Действительно ли он является дефектом? Руководитель утверждает исполнителя, который приступает к устранению дефекта в соответствие с назначенным дефекту приоритетом. Тестировщик повторяет выполнение теста и убеждается (или не убеждается) в устранении дефекта. Строгое соблюдение жизненного цикла дефекта позволяет существенно улучшить управление проектом, а также избежать “расползания“ требований под видом исправления ошибок. И избежать ненужной работы по излишней “полировке» продукта.

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

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

Ниже приведены краткие описания задач, входящих в цикл тестирования.

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

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

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

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

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

Тестирование и сценарии использования.
Выполнение задач жизненного цикла сопровождается разработкой различных артефактов (документов, моделей и других материалов проекта). Как обычно в RUP, разработка артефактов может проводиться в разной форме с разными требованиями к способу выполнения, рецензированию и качеству оформления. Например, вы может посмотреть на описание артефакта и решить, что вам в этом проекте он просто не нужен. Если же он вам необходим, вы можете набросать небольшую схему или несколько предложений на обороте старого документа. Правда, по современным представлениям лучше для этого использовать белую доску и фломастеры. В этом случае проще подключить к работе всех заинтересованных лиц или, по крайней мере, довести результаты до их сведения (прежде, чем их стерли). А можно разработать несколько диаграмм, используя инструменты визуального моделирования. Дополнить их сопроводительным текстом, набранным в мощном текстовом редакторе вроде Word, тщательно отредактированным и отформатированным. А потом все это распечатать и переплести. Но на такое оформление стоит тратить время только тогда, когда вы твердо уверены, что это необходимо. Например, если такое оформление оговорено условиями договора.

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

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

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

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

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

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

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

Инструментальная поддержка RUP. Инструменты тестирования и смежные инструменты | к оглавлению
Внедрение любой методологии существенно упрощается, если есть поддерживающий ее набор инструментов, позволяющий избежать тяжелого рутинного ручного труда. Методология RUP в этом смысле является одной из наиболее «благополучных», поскольку ее поддерживает набор инструментов IBM Rational. Ниже перечислены инструментальные средства непосредственно предназначенные для автоматизации процесса тестирования:

В таблице 1 приведены краткие характеристики инструментов тестирования.
Таблица 1 — Продукты тестирования фирмы IBM Rational
Название продукта Краткая характеристика

IBM Rational Purify Инструмент для отслеживания трудно обнаружимых ошибок времени исполнения (например, утечка памяти, выходы за границы массивов при чтении и записи).
IBM Rational PureCoverage Инструмент для отслеживания кода приложения, подвергнутого тестированию (какие именно классы, методы, вызовы функций были протестированы, а какие нет). Это позволяет автоматизировать процесс оценки полноты охвата кода в ходе тестирования.
IBM Rational Quantify Инструмент анализа производительности работающего приложения. Позволяет выявить фрагменты кода, в наибольшей мере оказывающие влияние на характеристики производительности системы.
IBM Rational Robot Инструмент для автоматизации записи и воспроизведения сценариев тестов. Сценарии тестов записываются на специальном языке программирования и могут быть получены либо автоматически (путем записи действий пользователя при работе с системой), либо вручную. IBM Rational Robot позволяет проводить функциональное тестирование системы, а также широко используется при тестировании производительности.
IBM Rational TestManager Инструмент планирования тестов. Используется для планирования и воспроизведения функциональных и нагрузочных тестов, созданных в IBM Rational Robot. Используется для сетевого многоплатформенного тестирования.
IBM Rational ManualTest Средство планирования тестов, не поддающихся автоматизации

Использование перечисленных выше инструментальных средств позволяет существенно повысить эффективность тестирования в любом проекте. Однако, тестирование – это не изолированный процесс. Он тесно связан с другими процессами, входящими в состав 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. Это очень простая, но в то же время и показательная схема, на которой видно, как происходит взаимодействие между инструментами (в том числе, и не описанными выше, но которые также оказывают свое влияние на процесс тестирования).

Инструментальные средства Rational глубоко интегрированы друг с другом. Выходная информация одного инструмента является входной для другого. На рисунке показано, какие инструменты и как используются в проекте. Ко всем перечисленным элементам следует добавить IBM Rational Unified Process, как основу описания процессов, IBM Rational SoDA, как основной инструмент формирования проектной документации для всех инструментов IBM Rational, и, самое главное — IBM Rational Project Console – средство визуализации проектных метрик.

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

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

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

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

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

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

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

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

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

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

На последующих стадиях разработки и в процессе сопровождения тесты на производительность разрабатываются и выполняются для:

Структурное тестирование
Концепция структурного тестирования связана с тестированием внутренней структуры исходного кода программного обеспечения и тестированием Web-сайтов.
Тесты структуры Web-сайтов разрабатываются и выполняются для проверки всех типов связей/ссылок.

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

Рекомендуется предъявлять прототип пользовательского интерфейса конечным пользователям системы как можно раньше.

Основные артефакты, создаваемые в процессе тестирования

В соответствие с RUP в процессе тестирования создается и используется много различных документов и моделей. Ключевые документы и модели и их назначение перечислены ниже:

Принципиальные достоинства RUP в части тестирования ПО

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

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

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

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

Также использование инструментальных средств позволяет существенно упростить проверку полноты охвата тестирования.
IBM Rational Software Group предлагает большой спектр продуктов, предназначенных для автоматизации различных аспектов процесса тестирования. В таблице 1 приведен список продуктов, применение которых позволяет автоматизировать различные аспекты тестирования, и их краткая характеристика. Детально все программные продукты IBM Rational будут рассмотрены в следующих выпусках.

Таблица 1 — Продукты тестирования IBM Rational Software Group

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

Рисунок 1. Итерационный жизненный цикл программного продукта

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

Каждая итерация включает, как правило, задачи планирования работ, анализа, проектирования, реализации, тестирования и оценки достигнутых результатов. Однако соотношения этих задач может существенно меняться. В соответствие с соотношением различных задач в итерации они группируются в фазы. В первой фазе — Начало — основное внимание уделяется задачам анализа. В итерациях второй фазы — Разработка — основное внимание уделяется проектированию и опробованию ключевых проектных решений. В третьей фазе — Построение — наиболее велика доля задач разработки и тестирования. А в последней фазе — Передача — решаются в наибольшей мере задачи тестирования и передачи системы Заказчику (хотя форма «передачи» Заказчику существенно различается для заказных систем и коробочных продуктов).

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

Так целями Начала является определение назначения и границ разрабатываемой системы.

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

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

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

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

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

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

Ориентация на архитектуру.
Еще одной важной и одновременно принципиальной особенностью RUP является его ориентация в первую очередь на архитектурные задачи. Разработка системы начинается с создания архитектурного базиса или каркаса. Этот каркас представляет собой исполняемую программу (исполняемую архитектуру), содержащую образцы решения всех принципиальных и/или типовых задач разрабатываемой системы. Подобный подход позволяет устранять наиболее тяжелые риски – архитектурные – на ранних стадиях разработки. Завершение разработки исполняемой архитектуры означает, что далее перед участниками проекта осталась, в основном, задача наращивания «мышечной массы» проекта по проверенным шаблонам и образцам. Кроме того, ориентация на архитектуру означает большое внимание таким вопросам как разработка и строгое следование архитектурным шаблонам, за счет чего существенно повышаются качество и скорость реализации системы.

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

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

Значит ли это, что можно сдавать Заказчику систему «как есть», не задумываясь о том, может ли он ею воспользоваться или ошибки не позволяют этого? Нет, ни в коем случае! RUP предлагает использовать при оценке качества произведенного продукта понятие «достаточно хорошего качества». Использование этого понятия означает, что Разработчик с открытыми глазами оценивает качество продукта, который он представляет Заказчику. И, как минимум, уверен, что поиск и устранение следующей ошибки сейчас обойдутся дороже, чем возможные потери Заказчика при проявлении ошибки и затраты на ее устранение в будущем. Впрочем, для критических систем критерий качественного продукта может быть и более жестким. Важно, что критерий есть, и что он должен быть выполнен. И что при этом качественный продукт — это не обязательно продукт БЕЗ ЕДИНОЙ ошибки.

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

Теперь, зная, «что такое хорошо и что такое плохо», прейдем к тому, как же «делать хорошо и не делать плохо».

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

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

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

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

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

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

Рисунок 3. Пример тестируемых компонент на различных итерациях

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

Еще одна существенная особенность работы в этой и последующей фазах, как уже упоминалось — необходимость собирать статистику обнаруженных и исправленных дефектов. Именно эта статистика, с одной стороны, позволяет оптимально перераспределить силы разработчиков и тестировщиков между модулями и компонентами системы. А с другой стороны, она служит основой для принятия обоснованных решений о достижении продуктом требуемого качества. Сбор достаточного объема статистики, как правило, требует использования средств автоматизации тестирования.
Также уже в фазе Построение желательно наладить активное взаимодействие с Заказчиком и будущими пользователями системы. Без обратной связи с будущими пользователями вряд ли вам удастся разработать не то, что «великую», но хотя бы «приличную» систему. Какой родитель скажет, что у его ребенка столько недостатков, сколько их видит сосед!?

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

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

К сожалению, даже при самом высоком качестве разработки редко удается избежать в фазе Передачи внесения изменений в разрабатываемую систему. Хотя в этой фазе желательно ограничиваться минимальными доработками, связанными скорее с «отсечением» недостаточно качественных фрагментов кода, иногда приходится возвращаться и к анализу и проектированию, не говоря уж про разработку. В этом случае приходится возвращаться к автономным и комплексным проверкам доработанных модулей и системы в целом. Более того, придется вернуться к отладке модуля. Отладка модуля, которую наиболее эффективно может провести разработчик, не является тестированием по RUP.

Выгоды от использования технологии IBM Rational в цифрах и фактах.

Наверное, можно сколь угодно долго говорить о технологии и об инструментах, поддерживающих ее. Но для того чтобы конечного потребителя окончательно склониться к правильному выбору, приведем реальные цифры и графики эффективности использования предлагаемой технологии и инструментальных средств. В России очень много компаний, которые, так или иначе используют технологии IBM Rational, но это, скорее использование отдельных инструментов, а не процесса. Хотя такое использование и дает эффект, но он не так велик, как было бы при полном переходе на технологию IBM Rational. Для иллюстрации эффективности технологии мы приведем реальные данные по одной из компаний, где полностью внедрили процесс тестирования по RUP в большой проект разработки нескольких последовательных версий большой системы (из области коммуникации).

Рисунок 5 демонстрирует то, каким образом снижается число ошибок в версиях программного продукта при применении технологии IBM Rational. В данном случае речь идет о применении регрессионных тестов. Обратите внимание на точку «пика». Это точка обозначает одновременно максимальную нагрузку, максимальное число найденных ошибок и максимальную задействованность тестировщиков, так как трудоемкость на данном шаге достаточно большая, так как сценарным языком тестирования необходимо сымитировать весь спектр функциональных возможностей тестируемого ПО. Как видно из графика, во всех последующих версиях программного продукта количество найденных ошибок уменьшается. А поскольку процесс тестирования автоматизирован, то сокращаются трудозатраты тестировщиков, соответственно, возрастает объем тестов, и, как следствие программное обеспечение тестируется все более и более полно.

Рисунок 6. Число ошибок, найденных в версиях программного обеспечения.

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

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

Давайте подведем итоги. Использование RUP обеспечивает:

Часть 2. Инструментальные средства поддержки процесса тестирования

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

Программные продукты будут описаны в порядке применения в проектах. Сначала рассмотрим средства тестирования для разработчиков (Quantify, Purify, PureCoverage). Данные средства неразрывно связаны с языком реализации и со средой разработки. Примеры, приведенные в книги ориентированы на язык программирования С++ и частично на С#. В связи с тем, что на момент написания была доступна только бета-версия Visual Stu-dio. NET, то мы в основном ориентировались на версию 6.0, лишь изредка демонстрируя возможности новой среды. Тоже касается и языка реализации C#. Примеры его использования также будут встречаться, но все же основное внимание будет уделено языку реализации С++, имеющем наивысший рейтинг среди языков для реализации крупных программных систем. К сожалению, за бортом остались Java и Basic, но мы надеемся, что разработчики воспримут все написанное здесь как модель реализации, подходы которой совместимы со многими языками программирования.

В следующей части перейдем к функциональному и нагрузочному тестированию. Начнем рассмотрение функционального тестирования с его планирования, чьи данные неразрывно связаны с требованиями, полученными на этапе определения требований к системе. Test Manager, в этом разрезе является как средством планирования тестирования, так средством реализации различных видов тестирования, так и средством предоставления финальной, пост — тестовой, отчетности. Далее воспользуемся продуктом Robot, который осуществляет физическую запись скриптов тестирования, с их последующим воспроизведением.

Ознакомимся с визуальными и ручными режимами составления тестов посредством Robot. Научимся составлять как функциональные скрипты так и варианты нагрузочных скриптов. Рассмотрим различные режимы работы продукта. Для полного понимания возможностей, опишем основные синтаксические нотации скриптовых языков SQA Basic.

В завершении опишем связи средств тестирования с остальными программными продуктами Rational.

Часть 2. Средства тестирования для разработчиков

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

Подобные первоначальные ошибки сводят на «нет» дальнейшее функциональное тестирование, так как низкокачественный код не позволяет тестерам быстро писать скрипт, реализующий тестирование новой формы, так как она полна странностей. Доработка, доработка, доработка…

Интересная деталь: процессоры работают быстро, шины работают быстро, память тоже быстро, а вот программное обеспечение из года в год, от версии к версии работает все медленнее и медленнее, потребляя при этом на порядок больше ресурсов, нежели чем предыдущие версии. Не спасают положение даже оптимизирующие компиляторы! Вторая не менее интересная деталь заключается в скорости разработки. Вы не обращали внимания на то, что аппаратные продукты (процессоры и прочее) обновляются гораздо чаще и выпускаются с меньшим числом ошибок?

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

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

Вот и получается, что при вопросе согласны ли вы, чтобы ваш телефон работал на основе обычной операционной системы (Windows, Unix… иже с ними) традиционно следует -— «нет»!
Поскольку этап тестирования кода приложения можно отнести к тестированию «прозрачного ящика», когда важен код приложения, то мы попробуем описать основные рекомендации по тестированию для данного этапа, которые почерпаны из личного опыта и основаны на здравом смысле и принципах разумной достаточности. То есть, мы сначала рассмотрим общие требования к качеству кода, а потом проведем ассоциацию с инструментами Rational, которые позволят решить проблемы данного участка.

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

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

На код накладываются дополнительные особые ограничения, а именно: тестируемый код должен быть получен при помощи компиляции с опцией «Debug», то есть должен содержать отладочную информацию. В противном случае Quantify, Purify и PureCoverage не смогут правильно отображать (вообще не смогут отображать) имена функций внутренних модулей тестируемого приложения. Исключения могут составлять только вызовы внешних модулей из dll-библиотек, поскольку метод компоновки динамических библиотек позволяет узнавать имена функций.

Отсюда можно сделать простой вывод: тестировать приложения можно даже не имея отладочной информации в модуле и при отсутствии исходных текстов, но в этом случае разработчик получает статистику исключительно по внешним вызовам.
Все три продукта способны проводить особые виды тестирования, такие как тестирование сервисов NT\2000\XP.

Программные продукты могут работать в трех режимах:

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

Средства анализа, строенные в Quantify, Purify и PureCoverage позволяют удовлетворить детально контролировать все нюансы в исполнении тестируемого приложения. Здесь и сравнение запусков, и создание слепков в ходе тестирования и экспорт в Excel для построения точных графиков множественных запусков.
Особо хочется отметить языковую «всеядность» продуктов.

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

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

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

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

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

Рисунок 1 показывает действия после выбора «File→Run», в результате которого можно выбрать имя внешнего модуля и аргументы его вызова.

В качестве параметров настройки можно выбрать метод вставки отладочного кода:

По умолчанию Quantify собирает статистическую информацию в модуле тестируемого продукта и во всех внешних библиотеках.

Начало насыщения тестируемого приложения сопровождается появлением окна инструментирования, в котором построчно отображаются все модули, вызываемые основным. Данные модули, как говорилось выше, насыщаются отладочным кодом и помещаются в специальную директорию «cache» по адресу «\rational\quantify\cache». Отметим, что первоначальный запуск инструментирвания процесс длительный, но каждый последующий вызов сокращает общее время ожидания в силу того, что вся необходимая информация уже есть в Кеше.

С точки зрения дисковой емкости, файл (кэшируемый) с отладочной информацией от Quantify вдвое длиннее своего собрата без отладочной информации.

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

Рисунок 3 демонстрирует фрагмент окна «Summary», в котором производится запись состояния тестируемого приложения. Причем, что очень примечательно, тестирование производится не только для простого приложения, но и для много поточного. В последнем случае (см. рисунок 3), тестируется каждый поток отдельно. В любом случае, даже если приложение однопоточное, то имя основного (единственного) потока именуется как «.main_0», что представляется вполне логичным.

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

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

Следующие два примера показывают статистическую информацию:
(1) Общий отчет — «Details»:

Program Name: C:\projects\aa\Debug\aa.exe
Program Arguments:
Working Directory: C:\projects\aa\Debug
User Name: Alex
Product Version: 2002.05.00 4113
Host Name: ALEX-GOLDER
Machine Type: Intel Pentium Pro Model 8 Stepping 10
# Processors: 1
Clock Rate: 847 MHz
O/S Version: Windows NT 5.1.2600
Physical Memory: 382 MBytes
PID: 0xfbc
Start Time: 24.04.2002 14:17:38
Stop Time: 24.04.2002 14:17:52
Elapsed Time: 13330 ms
# Measured Cycles: 191748 (0 ms)
# Timed Cycles: 2489329 (2 ms)
Dataset Size (bytes): 0x4a0001.

(2) «Log»
Quantify for Windows,
Copyright © 1993-2001 Rational Software Corporation All rights reserved.
Version 2002.05.00; Build: 4113;
WinNT 5.1 2600 Uniprocessor Free
Instrumenting:
Far.exe 620032 bytes
ADVAPI32.DLL 549888 bytes
ADVAPI32.DLL 549888 bytes
USER32.DLL 561152 bytes
USER32.DLL 561152 bytes
SHELL32.DLL 8322560 bytes
SHELL32.DLL 8322560 bytes
WINSPOOL.DRV 131584 bytes
WINSPOOL.DRV 131584 bytes
MPR.DLL 55808 bytes
MPR.DLL 55808 bytes
RPCRT4.DLL 463872 bytes
RPCRT4.DLL 463872 bytes
GDI32.DLL 250880 bytes
GDI32.DLL 250880 bytes
MSVCRT.DLL 322560 bytes
MSVCRT.DLL 322560 bytes
SHLWAPI.DLL 397824 bytes
SHLWAPI.DLL 397824 bytes

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

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

Обратите внимание на количество и последовательность вызова различных модулей потока «main». Жирная линия показывает наиболее длительные ветви (содержащие либо часто вызываемые функции, либо функции, выполнявшиеся дольше остальных). Для демонстрации возможностей Quantify было сконструировано простое приложение, состоящее из функции «main» и двух дополнительных «recursive» и «outside» (см. листинг 1).

Листинг 1. Пример тестируемого приложения, сконструированном в виде консольного приложения из Visual Studio 6.0. Язык реализации «С».

//Создаем функцию-заглушку
void outside (void)
{
static int v=0;
v++;
}

//Создаем рекурсивную функцию, исполняющуюся 100 раз
int recursive (void)
{
static int i=0;
int oo;

outside ();//Вызываем функцию заглушку
if (i==100){i=1;return 0;}//Обнуляем счетчик и выходим
i++;
recursive ();
}

int main (int argc, char* argv[])
{
int i;
for (i=0;i<100;i++)recursive ();
//Вызываем 100 раз рекурсивную функцию 100х100
return 0;
}

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

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

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

Более подробно о статистике будет рассказано в следующем материале.

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

На рисунке приведены цифры соответствующие машинным циклам.

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

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

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

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

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

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

Можно, конечно, дать общие рекомендации по улучшению производительности кода и его эффективности:

Использовать конструкцию «I++» вместо «I=I+1», так как компиляторы транслируют первую конструкцию в более эффективный код. К сожалению, этот эффективность примера ограничена настройками используемого компилятора, и иногда бывает равнозначной по быстродействию;

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

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

то его лучше преобразовать в такой:
mn= x * y;
for (sr = 0; sr < 1000; sr++)
{
a[sr] = mn;
}

поскольку мы избавляемся от лишней операции умножения в простом цикле;

Там где возможно при работе с многомерными массивами, обращаться с ними как с одномерными. То есть, если есть необходимость в копировании или инициализации, например, двумерного массива, то вместо кода:
int sr[400][400];
int j, i;

лучше использовать конструкцию, в которой нет вложенного цикла:

for (int i = 0; i < 400*400; i++)
p[sr] = 0; // или *p++=0, что для большинства компиляторов одно и тоже

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

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

Короткие функции в классах лучше оформлять встроенными (inline);

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

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

Использовать инструкции сдвига вместо умножений и делений там, где это позволяет делать логика программы. Например, инструкция S=S<<1 всегда эффективнее, чем S=S*2;

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

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

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

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

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

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

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

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

Сравнение запусков позволяет проводить сравнительный анализ между базовым запуском (base – том, с которого все началось) и новым (new).

Результаты сравнения также остаются в проекте Quantify и сохраняются на протяжении жизненного цикла разработки проектов.

Наравне со сравнением запуск можно воспользоваться суммированием, нажав на кнопку

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

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

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

Для получения доступа к API необходимо выполнить ряд действий по подключению «puri.h» файла с определением функций и с включением «pure_api.c» файла в состав проекта. Единственное ограничение, накладываемое API — рекомендации по постановке точек останова после вызовов Quantify при исполнении приложения под отладчиком.

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

QuantifyAddAnnotation ( «Тестирование проводится под Quantify с использованием API»);
QuantifySetThreadName ( «Основной поток приложения»);
for (i=0;i<12;i++){
QuantifySaveData ();
recursive ();
}
return 0;
}

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

Рис. Данный рисунок демонстрирует вид окна после выполнения команды снятия слепка или вызова функции API QuantifySaveData ()

Рис. У Quantify отсутствуют сложности с русскими буквами

Традиционные операции над файлами присущи и программе Quantify. Дополнительные особенности заключаются в том, что сохранять данные можно как во встроенном формате (qfy), для каждого отдельного запуска, так и в текстовом виде, для последующего использования в текстовых редакторах, либо для дальнейшей обработки скриптовыми языками типа perl (более подробно смотрите об этом в разделах по ClearCase и ClearQuest).
Quantify позволит переносить таблицы через буфер обмена в Microsoft Excel, что открывает безграничные возможности по множественному сравнению запусков, по построению графиков и различных форм. Все что необходимо сделать — это только скопировать данные из одной программы и поместить в другую известным способом.

Начать описание возможностей продукта Rational Purify хочется перефразированием одного очень известного изречения: «с точностью до миллиБАЙТА». Данное сравнение не случайно, ведь именно этот продукт направлен на разрешение всех проблем, связанных с утечками памяти. Ни для кого не секрет, что многие программные продукты ведут себя «не слишком скромно», замыкая на себя во время работы все системные ресурсы без большой на то необходимости. Подобная ситуация может возникнуть вследствие нежелания программистов доводить созданный код «до ума», но чаще подобное происходит не из за лени, а из-за невнимательности. Это понятно — современные темпы разработки ПО в условиях жесточайшего прессинга со стороны конкурентов не позволяют уделять слишком много времени оптимизации кода, ведь для этого необходимы и высокая квалификация, и наличие достаточного количества ресурсов проектного времени. Как мне видится, имея в своем распоряжении надежный инструмент, который бы сам в процессе работы над проектом указывал на все черные дыры в использовании памяти, разработчики начали бы его повсеместное внедрение, повысив надежность создаваемого ПО. Ведь и здесь не для кого не секрет, что в большинстве сложных проектов первоочередная задача, стоящая перед разработчиками заключается в замещении стандартного оператора «new» в С++, так как он не совсем адекватно себя ведет при распределении памяти.
Вот на создании\написании собственных велосипедов и позволит сэкономить Purify.

Рисунок демонстрирует внешний вид программы после проведения инструментирования (тестирования) программного модуля.

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

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

Работа с Purify возможна как при наличии исходных текстов и отладочной информации, так и без нее. В случае отсутствия debug-информации анализ ошибок ведется только по ip-адресам. Так же как и в случае с Quantify, возможен детальный просмотр функций из dll-библиотек. В этом случае наличие отладочной информации не является необходимостью.

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

Отметим разницу между ошибкой и потенциальной ошибкой и опишем:

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

Список ошибок и потенциальных ошибок достаточно объемен и постоянно пополняется. Кратко опишем основные сообщения, выводимые после тестирования:

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

Отметим категории и принадлежность к ним различных сообщений:

Многие статические ошибки могут вылавливать компиляторы на этапе разработки программного модуля или приложения. На этом этапе преимущества Purify не очень видны.

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

Рассмотрим более подробно список отлавливаемых ошибок, определив их принадлежность к категориям с примерами на C++/C:

ABR: Array Bounds Read. Выход за пределы массива при чтении.
Известная болезнь всех разработчиков — неправильно поставленное условие в цикле. Соответственно, ошибка, которая имеет место быть в программе, связанная с чтением лишней информации, может проявить себя, а может и не проявить. Но она является потенциальной ошибкой.

#include <iostream.h>
#include <windows.h>
int main (int, char **)
{
char *ptr = new char[5];//Выделяем память под массив из 5 символов

ptr[0] = ‘e’;
ptr[1] = ‘r’;
ptr[2] = ‘r’;
ptr[3] = ‘o’;
ptr[4] = ‘r’;
for (int i=0; i ≤ 5; i++) {
//Ошибка, при i=5 – выход за пределы массива
cerr << «ptr[„ << i << „] == „ << ptr[i] << '\n';
}
delete[] ptr;
return (0);
}

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

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

По умолчанию, Purify успешно справляется только с динамическим распределением, четко выводя сообщение об ошибке. В случае статического распределения, все зависит от размеров «кучи» и настроек компилятора.

#include <iostream.h>
#include <windows.h>
int main (int, char **)
{
char * ptr = new char[5];//Выделяем память под массив из 5символов
for (int i=0; i ≤ 5; i++) {
//Ошибка, при i=5 — выход за пределы массива
ptr[i] = ‘!’;
cerr << „ptr[„ << i << „] == «<< ptr[i] << '\n'; //ABW + ABR when i is 5
}
delete[] ptr;
return (0);
}

ABWL: Late Detect Array Bounds Write. Cообщение указывает, что программа записала значение перед началом или после конца распределенного блока памяти

#include <iostream.h>
#include <windows.h>
int main (int, char **)
{
char * ptr = new char[5];//Выделяем память под массив из 5 символов
for (int i=0; i ≤ 5; i++) {
//Ошибка – попытка записи после блока выделенной памяти
ptr[i] = ‘!’;
cerr << «ptr[ «<< i << «] == «<< ptr[i] << '\n';
}
delete[] ptr; //ABWL: ОШИБКА
return (0);
}

BSR: Beyond Stack Read. Сообщение указывает, что функция в программе собирается читать вне текущего указателя вершины стека

#include <windows.h>
#include <iostream.h>
#define A_NUM 100
char * create_block (void)
{
char block[A_NUM];//Ошибка: массив должен быть статическим
for (int i=0; i < A_NUM; i++) {
block[i] = ‘!’;
}
return (block);//Ошибка: неизвестно, что возвращать
}

int main (int, char **)
{
char * block;
block = create_block ();
for (int i=0; i < A_NUM; i++) {
//BSR: нет гарантии, что элементы из «create_block“ до сих пор находятся в стеке

FFM: Freeing Freed Memory. Попытка освобождения свободного блока памяти.

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

#include <iostream.h>
#include <windows.h>
int main (int, char **)
{
char *ptr1 = new char;
char *ptr2 = ptr1;//Ошибка: должен дублировать объект, а не копировать указатель
*ptr1 = ‘a’;
*ptr2 = ‘b’;
cerr << „ptr1“ << «is „ << *ptr1 << '\n';
cerr << «ptr2“ << «is „ << *ptr2 << '\n';
delete ptr1;
delete ptr2;//Ошибка – освобождение незанятой памяти
return (0);
}

FIM: Freeing Invalid Memory. Попытка освобождения некорректного блока памяти.

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

int main (int, char **)
{
char a;
delete[] &a;//FIM: в динамической памяти нет объектов для уничтожения
return (0);
}

FMM: Freeing Mismatched Memory. Сообщение указывает, что программа пробует освобождать память с неправильным ВЫЗОВОМ API для того типа памяти

int main (int, char **)
{
HANDLE heap_first, heap_second;
heap_first = HeapCreate (0, 1000, 0);
heap_second = HeapCreate (0, 1000, 0);
char *pointer = (char *) HeapAlloc (heap_first, 0, sizeof (int));
HeapFree (heap_second, 0, pointer);
//Ошибка – во второй куче не выделялась память

FMR: Free Memory Read. Попытка чтения уже освобожденного блока памяти

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

#include <iostream.h>
#include <windows.h>
int main (int, char **)
{
char *ptr = new char[2];
ptr[0] = ‘!’;
ptr[1] = ‘!’;
delete[] ptr;//Ошибка – освобождение выделенной памяти
for (int i=0; i < 2; i++) {
//FMR: Ошибка- попытка чтения освобождённой памяти
cerr << «element #“ << i << «is „ << ptr[i] << '\n';
}
return (0);
}

FMW: Free Memory Write. Попытка записи уже освобожденного блока памяти

#include <iostream.h>
#include <windows.h>
int main (int, char **)
{
char *ptr = new char[2];
ptr[0] = ‘!’;
ptr[1] = ‘!’;
delete[] ptr;//специально освобождаем выделенную память
for (int i=0; i < 2; i++) {
ptr[i] *= ‘A’; //FMR + FMW: память для *ptr уже освобождена
cerr << «element #“ << i << «is „ << ptr[i] << '\n'; //FMR
}
return (0);
}

HAN: Invalid Handle. Операции над неправильным дескриптором

#include <iostream.h>
#include <windows.h>
#include <malloc.h>
int main (int, char **)
{
int i=8;
(void) LocalUnlock ( (HLOCAL)i);//HAN: i – не является описателем объекта памяти
return (0);
}

HIU: Handle In Use. Индикация утечки ресурсов. Неправильная индикация дескриптора.

#include <iostream.h>
#include <windows.h>
static long GetAlignment (void)
{
SYSTEM_INFO desc;
GetSystemInfo (&desc);
return (desc.dwAllocationGranularity);
}
int main (int, char **)
{
const long alignment = GetAlignment ();
HANDLE handleToFile = CreateFile ( «file.txt“,
GENERIC_READ|GENERIC_WRITE, 0, NULL, CREATE_ALWAYS,
FILE_ATTRIBUTE_NORMAL, NULL);
if (handleToFile == INVALID_HANDLE_VALUE) {

cerr << «Ошибка открытия, создания файла\n“;
return (1);
}
HANDLE handleToMap = CreateFileMapping (handleToFile, NULL, PAGE_READWRITE, 0, alignment, «mapping_file“);
if (handleToMap == INVALID_HANDLE_VALUE) {
cerr << «Unable to create actual mapping\n“;
return (1);
}
char * ptr = (char *) MapViewOfFile (handleToMap, FILE_MAP_WRITE, 0, 0, alignment);

if (ptr == NULL) {
cerr << «Unable to map into address space\n“;
return (1);
}
strcpy (ptr, «hello\n“);
//HIU: handleToMap до сих пор доступен и описывает существующий объект
return (0);
}

IPR: Invalid Pointer Read. Ошибка обращения к памяти, когда программа пытается произвести чтение из недоступной области

#include <windows.h>
int main (int, char **)
{
char * pointer = (char *) 0xFFFFFFFF;
//Ошибка — указатель на зарезервированную область памяти

for (int i=0; i < 2; i++) {
//IPR: обращение к зарезервированной части адресного пространства
cerr << «pointer[„ << i << „] == «<< pointer[i] << '\n';
}
return (0);
}

IPW: Invalid Pointer Write. Ошибка обращения к памяти, когда программа пытается произвести запись из недоступной области

#include <iostream.h>
#include <windows.h>
int main (int, char **)
{
char *pointer = (char *) 0xFFFFFFFF;
//Ошибка — указатель на зарезервированную область памяти

for (int i=0; i < 2; i++) {
//IPW + IPR: обращение к зарезервированной части адресного пространства
pointer[i] = ‘!’;
cerr << «ptr[ «<< i << «] == «<< ptr[i] << '\n';
}
return (0);
}

MAF: Memory Allocation Failure. Ошибка в запросе на распределение памяти. Возникает в случаях, когда производится попытка распределить слишком большой блок памяти, например, когда исчерпан файл подкачки.

#include <iostream.h>
#include <windows.h>
#define BIG_BLOCK 3000000000 //размер блока
int main (int, char **)
{
char *ptr = new char[BIG_BLOCK / sizeof (char)];
//MAF: слишком большой размер для распределения
if (ptr == 0) {
cerr << «Failed to allocating, as expected\n“;
return (1);
} else {
cerr << «Got „ << BIG_BLOCK << «bytes @“ << (unsigned long)ptr << '\n';
delete[] ptr;
return (0);
}
}

Распространенный вариант ошибки. Многие современные приложения грешат тем, что не отдают системе распределенные ресурсы по окончании своей работы.

#include <windows.h>
#include <iostream.h>
int main (int, char **)
{
(void) new int[1000];
(void) new int[1000];
//результат потери памяти
return (0);
}

MPK: Potential Memory Leak. Потенциальная утечка памяти
Иногда возникает ситуация, в которой необходимо провести инициализацию массива не с нулевого элемента. Purify считает это ошибкой. Но разработчик, пишущий пресловутый текстовый редактор может инициализировать блок памяти не с нулевого элемента.

#include <iostream.h>
#include <windows.h>
int main (int, char **)
{
static int *pointer = new int[100000];
pointer += 100;//MPK: потеряли начало массива
return (0);
}

NPR: Null Pointer Read. Попытка чтения с нулевого адреса
Бич всех программ на С\С++. Очень часто себя ошибка проявляет при динамическом распределении памяти приложением, так как не все разработчики ставят условие на получение блока памяти, и возникает ситуация, когда система не может выдать блок указанного размера и возвращает ноль. По причине отсутствия условия разработчик как не в чем не бывало начинает проводить операции над блоком, адрес в памяти которого 0.

#include <iostream.h>
#include <windows.h>
int
main (int, char **)
{
char * pointer = (char *) 0x0; //указатель на нулевой адрес
for (int i=0; i < 2; i++) {
//NPR: попытка чтения с нулевого адреса
cerr << «pointer[„ << i << «] == «<< pointer[i] << '\n';
}
return (0);
}

NPW: Null Pointer Write. Попытка записи в нулевой адрес

#include <iostream.h>
#include <windows.h>
int
main (int, char **)
{
char * pointer = (char *) 0x0; //указатель на нулевой адрес
for (int i=0; i < 2; i++) {
//NPW: ошибка доступа
pointer[i]=’!’;
cerr << «pointer[ «<< i << «] == «<< pointer[i] << '\n';
}
return (0);
}

UMC: Uninitialized Memory Copy. Попытка копирования непроинициализированного блока памяти

int main (int, char **)
{
int * pointer = new int[10];
int block[10];
for (int i=0; i<10;i++)
{
pointer[i]=block[i]; //UMC предупреждение
cerr<<block[i]<<“\n“;

UMR: Uninitialized Memory Read. Попытка чтения непроинициализированного блока памяти

#include <iostream.h>
#include <windows.h>
int main (int, char **)
{
char *pointer = new char;
cerr << «*pointer is „ << *pointer << '\n';
//UMR: pointer указывает на непроинициализированный элемент
delete[] pointer;
return (0);
}

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

Фильтры создаются и назначаются и модифицируются через верхнее меню (View→CreateFilter и View→FilterManager). По умолчанию Purify выводит все сообщения и предупреждения.

Рисунок показывает внешний вид окна создания фильтра (View→CreateFilter). Здесь мы имеем возможность по выбору сообщений, которые нужно отфильтровывать.

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

Выше упоминалось, что Purify не ограничивает число фильтров. Следует понимать, что не ограничивается не только общее число фильтров, но и их количество на одно протестированное приложение.

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

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

Функции установки статуса распределенных блоков:

Функции тестирования состояний распределенных блоков

Purify позволяет сохранять результаты тестирования (file→save copy as) в четырех различных представлениях, позволяющих наиболее эффективным образом получить информацию о ходе тестирования.

При установленном MS Outlook, возможно отправление отчета почтой через пункт file→send из верхнего меню Purify.

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

Запуск приложения производится точно также как и в случае с Quantify (по F5 или file→Run). Параметры настройки находятся пункте Settings, появившегося окна.

Первая страница диалога представлена на рисунке

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

Закладка PowerCheck позволит настроить уровень анализа каждого отдельно взятого модуля. Существует два способа инструментирования тестируемого приложения: Precise и Minimal. В первом случае проводится детальное инструментирование кода, но при этом модуль работает относительно медленно. Во втором случае, проводится краткое инструментирование, при котором Purify вносит в модуль меньше отладочной информации, и, как следствие, способна отловить меньшее число ошибок. Последний подход оправдан, когда приложение вызывает массу внешних библиотек от третьих фирм, которые не будут подвергаться правке.

Основное назначение продукта — выявление участков кода, пропущенного при тестировании приложения — проверка области охвата кода.

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

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

Понятие «полностью протестированный» определяет руководство компании в числовом, процентном значении. То есть, при оформлении требований указано, что область охвата кода 70%. Соответственно, по достижении данной цифры дальнейшие проверки кода можно считать нецелесообразными. Конечно, вопрос области охвата, очень сложный и неоднозначный. Единственным утешением может служить то, что 100% области охвата в крупных проектах не бывает.

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

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

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

Система отчетности представлена 4 различными видами отчетов:

На рисунке показана статистическая выкладка, выведенная Coverage по окончании тестирования приложения.

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

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

Поле %Lines Hit показывает процентное отношение протестированных строк кода для отдельной функции.

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

Как и Quantify с Purify, данный инструмент имеет функции расширения интерфейса. Рассмотрим их краткое описание.

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

CoverageData WinMain Function D:\xp\Rational\Coverage\Samples\hello.c D:\xp\Rational\Coverage\Samples\hello.exe 0 1 1 100.0 5 5 10 50.00 36 1

SourceLines D:\xp\Rational\Coverage\Samples\hello.c D:\xp\Rational\Coverage\Samples\hello.exe
LineNumber LineCoverage
18.1 0
23.1 0
26.1 0
26.1 0
27.1 0
27.1 0

PureCoverage также как и Quantify может переносить табличные данные в Microsoft Excel.

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

Дополнительные возможности средств тестирования для разработчиков

Все инструментальные средства могут работать на 3 уровнях исполнения:

Одно из важных преимуществ перед конкурентами — возможность тестирования специальных приложений, таких как сервисы.

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

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

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

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

Основные свойства средств Purify, Quantify и PureCoverage

Часть 3. Планирование функционального и нагрузочного тестирования

Планирование функционального и нагрузочного тестирования

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

На основе IBM Rational вы можете создать тестовую лабораторию с центром активности, который будет эмулировать сотни и тысячи пользователей, посылающих и получающих информацию, воспроизводя тем самым сложное взаимодействие между вашим клиентским приложением и базами данных, другими приложениями и Web серверами. В такой лаборатории командным пунктом становится компьютер, который при инсталляции PerformanceStudio был определен как Мастер. С этого компьютера вы организуете тестирование, наблюдаете за процессом и анализируете результаты выполнения тестов сэмулированными пользователями графического интерфейса (GUI) и виртуальными пользователями (VU).

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

При организации работы вашей тестовой лаборатории вы можете загрузить сам Мастер-компьютер работой по воспроизведению скриптов, а можете перераспределить задачи выполнения скриптов между несколькими компьютерами — Агентами, которые высвободят ресурсы Мастера. Используя компьютер Мастер в сочетании с его Агентами для воспроизведения скриптов можно создать значительно более мощную и реалистичную нагрузку при тестировании характеристик производительности серверов. Агенты могут воспроизводить различные комбинации VU и GUI скриптов, обеспечивая тем самым дополнительную гибкость и масштабирование при организации тестов в сложных гетерогенных сетевых структурах. Если Мастер-компьютер работает только на MS Windows NT, то Агенты могут быть установлены на различные платформы MS Windows и UNIX.

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

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

Тесты производительности (Performance Tests) позволяют определить, работает ли многопользовательская система в соответствии с требуемыми стандартами при изменяющихся нагрузках. В результате выполнения тестов измеряются времена отклика системы на какой-либо из запросов, и на основе собранной статистической информации делаются заключения о характеристиках системы. Тесты производительности выполняются с помощью программы LoadTest. При этом тестировании типично используется нагрузка сервера большим количеством виртуальных пользователей. Например, вы можете установить таймер для одного VU, чтобы определить, сколько времени займет выполнение запроса, когда тысячи других VU посылают запросы на тот же самый сервер в то же самое время. Термин 'тесты производительности' включает нагрузочные, стрессовые, конкурирующие и конфигурационные тесты. Совокупность этих тестов позволяет ускорить цикл тестирования производительности и достигнуть значимых и точных результатов.

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

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

Стрессовое тестирование (Stress Test) — это проверка работы системы в экстремальных условиях, т.е., когда испытуемая система искусственно ставится в условия, которые могут привести к сбою в работе как клиентской или серверной части приложений, так и всей системы в целом.

Способов организации стрессового тестирования может быть великое множество, например:

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

Конкурирующее тестирование (Contention Test) выполняется как комбинация GUI и VU на одном или нескольких компьютерах, для того чтобы эмулировать действительное многопользовательское окружение. Например, можно создать тест, когда несколько GUI пользователей и множество виртуальных пользователей в одно и тоже время будут обращаться к той же самой базе данных для обнаружения проблем в управлении многозадачностью или блокировках. Без автоматизированного средства тестирования такие тесты, требующие точной синхронизации действий большого количества пользователей, выполнить практически невозможно.

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

Конфигурационное тестирование (Configuration Testing). Каждый пользовательский компьютер может иметь различную смесь аппаратных и программных особенностей, которые создают риск того, что создаваемое программное обеспечение будет работать на одном из них, а на другом не будет. Снизить вероятность возникновения таких ситуаций можно применением конфигурационных тестов, когда один раз созданные скрипты для GUI и VU пользователей будут выполняться на компьютерах с различными OS или конфигурациями программных и аппаратных средств. Например, если вы используете несколько типов сетевых карт, вы можете выполнить серию тестов для каждой из них с тем, чтобы определить, какая обладает лучшими характеристиками.

Распределенное функциональное тестирование (Distributed Functional Testing).

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

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

Средства тестирования IBM Rational поддерживают три режима интерактивной записи скриптов:

API – Записывает API вызовы из клиентских приложений и клиентских библиотек к серверам. API режим записи является рекомендуемым подходом для всех клиентов, работающих на платформе Windows NT. В этом режиме и PerformanceStudio и клиентское приложение оба устанавливаются на клиентский компьютер.

Network – записывает трафик по TCP/IP протоколу на уровне сетевого интерфейса. Этот тип записи рекомендован тогда, когда клиент не поддерживает API режим записи.

Proxy – в этом режиме записывается тот же самый трафик, что и в режиме записи Network, но для передачи пакетов между клиентом и сервером используется машрутизация через proxy компьютер. Этот специализированный тип записи применяется в высокоскоростных сетях и сетях с коммутаторами.

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

TestManager, являясь средством планирования тестирования, отвечает за их корректное исполнение. Нелишне напомнить, что созданием скриптов (библиотеки скриптов) занимается Rational Robot, физически осуществляющий запись и воспроизведение скриптов. Полученный набор скриптов преобразуется в план тестирования, а затем в сценарий тестирования непосредственно в TestManager

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

Рассмотрим подробно основные виды тестов, дополнительные условия тестирования, требования к тестам и критерии завершения.

Функциональное тестирование объекта-тестирования планируется и проводится на основе требований к тестированию, заданных на этапе определения требований. В качестве требований выступают диаграммы use-case, бизнес-функции и бизнес-правила. Цель функциональных тестов состоит в том, чтобы проверить соответствие разработанных графических компонентов установленным требованиям.

В основе функционального тестирования лежит методика «черного ящика“. Идея тестирования сводится к тому, что группа тестировщиков проводит тестирование, не имея доступа к исходным текстам тестируемого приложения. При этом во внимание принимается только входящие требования и соответствие им тестируемым приложением.

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

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

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

Убедиться в надлежащем функционировании объекта тестирования. Тестируется правильность навигации по объекту, а также ввод, обработку и вывод данных.

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

Все запланированные действия по тестированию выполнены.

Все найденные дефекты были соответствующим образом обработаны (документированы и помещены в базу дефектов).

Тестирование целостности данных и баз данных

Цель Тестирования:
Убедиться в надежности методов доступа к базам данных, в их правильном исполнении, без нарушения целостности данных.

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

Оценить правильность внесения данных и убедиться в корректной обработке базой входящих значений.

Все способы доступа функционируют, в соответствии с требованиями.

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

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

Цель тестирования:
Проверить правильность функционирования объекта тестирования и связанных с ним процессов на соответствие требованиям бизнес моделей и расписаний.

Методика:
Тестирование будет моделировать несколько бизнес циклов, с выполнением следующего:

Критерии завершения:
Все запланированные тесты выполнены. Все выявленные дефекты обработаны и документированы.

Тестирование пользовательского интерфейса

Цель Тестирования:
Проверить правильность навигации по объекту тестирования (в том числе межоконные переходы, переходы между полями, правильность обработки клавиш «enter» и «tab», работа с мышью, функционирование клавиш-акселераторов и полное соответствие индустриальным стандартам);

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

Методика:
Создается или дорабатываются тесты для каждого из окон, на предмет соответствия навигации и состояний каждого из объектов;

Критерии завершения:
Каждое окно протестировано и удовлетворяет, базовой линии поведения, требованиям стандартов и не противоречит проектным требованиям;

Все выявленные дефекты обработаны и документированы.

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

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

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

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

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

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

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

Критерии завершения:
Одиночная Транзакция или единичный пользователь: Успешное завершение теста без каких либо сбоев в течение ожидаемого или требуемого периода времени выполнения транзакции;

Все выявленные дефекты обработаны и документированы.

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

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

Методика:
Использовать тесты, разработанные для функционального тестирования или тестирования бизнес-циклов.

Изменять состав данных, их число и сложность для увеличения времени отклика

Критерии завершения:
Множественные транзакции от множества пользователей исполнены без проблем (правильно, в определенном временном интервале)

Все выявленные дефекты обработаны и документированы.

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

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

Цель Тестирования:
Убедиться в том, что целевые тесты выполнены без ошибок при следующих условиях проведения тестирования:

Методика:
Использовать тесты, созданные для нагрузочного тестирования и тестирования производительности;

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

Критерии завершения:
Все запланированные тесты выполнены, системные пределы достигнуты и не выявлено сбоев в тестируемом приложении;

Все выявленные дефекты обработаны и документированы.

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

Цель Тестирования:
Проверить правильность функционирования объекта тестирования при следующих сценариях:

Методика:
Использовать тесты, созданные для нагрузочного тестирования и тестирования производительности;

Имитировать максимальное число клиентов для прохождения наиболее худшего сценария работы системы;

Создать максимальную базу и поддерживать обращения клиентов к ней на протяжении длительного времени.

Критерии завершения:
Все запланированные тесты выполнены;

Специфические системные ограничения достигнуты или превышены без ошибок;

Все выявленные дефекты обработаны и документированы.

Тестирование управления доступом. Тестирование безопасности

Данный вид тестирования фокусируется на исполнении двух ключевых уровнях безопасности:

Безопасность на уровне приложения, доступ к данным или бизнес-функциям;

Безопасность на уровне системы, регистрация (аутентификация) или удаленный вход в систему;

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

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

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

Цель Тестирования:
(Безопасность на уровне приложения). Проверить, что пользователь может обращаться только к тем функциям или данным, к которым он имеет доступ.

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

Методика:
Определить список пользователей и функции (или данные) к которым каждый имеет доступ имеется доступ;

Создать тесты для каждого пользовательского объекта тесты доступа с проверкой транзакций;

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

Проверить корректно ли отклонены дополнительные функции или данные, которые были ограничены.

Критерии завершения:
По каждому пользователю выводится список доступных функций или данных.

Все действия происходят в строгом соответствии с полученными правами.

Все выявленные дефекты обработаны и документированы.

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

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

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

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

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

Методика:
Использовать функциональные тесты и тесты бизнес циклов;

Смоделировать в процессе тестирования следующие ситуации:

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

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

Все выявленные дефекты обработаны и документированы.

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

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

RUP имеет разветвленный механизм по планированию и одновременному запуску конфигурационных тестов на различных платформах одновременно.

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

Цель Тестирования:
Проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм.

Методика:
Используются скрипты функционального тестирования;

До начала тестирования открыть максимальное число общеизвестных приложений;

Тестирование проводится на разных платформах.

Критерии завершения:
Тестируемое приложение правильно в любой аппартно-программной среде.

Все выявленные дефекты обработаны и документированы.

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

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

Цель Тестирования:
Удостовериться в том, что объект тестирования правильно инсталлируется на систему, удовлетворяющую всем программно-аппаратным требованиям из инструкции по инсталляции. Особое внимание уделяется следующим видам установки:

Методика:
Разработать скрипты для проверки всех перечисленных комбинаций.

Критерии завершения:
Установка, обновление и деинсталляция происходят корректно;

Исключительные ситуации обрабатываются корректно.

Все выявленные дефекты обработаны и документированы.

Добавить комментарий (анонимные комментарии не публикуются!!!)

Новости и пресс-релизы СМ-Консалт

08.05.2012 18:00:34
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» состоится 28-30 мая в Москве
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» состоится 28-30 мая в Москве. Проводится совместными усилиями компаний СМ-Консалт итренинговым центром КарьерЛаб. Место проведения тренинга - ул. Восьмого Марта, вл. 1, стр. 12 (схема проезда).

Продолжительность тренинга составляет 2 или 3 дня по выбору. Целевая аудитория: начальники отделов, менеджеры проектов, директора, руководители проектов внедрения, бизнес-аналитики, специалисты команды внедрения.

21.02.2012 14:21:11
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» состоится 14-16 марта в Санкт-Петербурге
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» состоится 14-16 марта в Санкт-Петербурге. Проводится совместными усилиями компаний СМ-Консалт, тренинговым центром КарьерЛаб и Legal SoftWave. Место проведения тренинга в данный момент уточняется.

21.02.2012 12:42:20
Новая статья: IT и психология. Человеческий фактор в парном программировании: почему многие не получают желаемого от его внедрения?
Статья, находящаяся перед вами, открывает цикл статей о человеческом факторе, Agile-практиках и других полезных приемах, используемых при управлении командами в ИТ. Объединяет рассматриваемые практики и приемы одно – они позволяют проявиться положительным эффектам, связанным с человеческим фактором. И мы объясняем, почему с точки зрения психологии, это происходит. Так сказать, подводим теоретическую и экспериментальную базу под то, что себя уже давно зарекомендовало и работает. Или под то, что работает не у всех, и потому является предметом оживленных споров и дискуссий. И начинаем мы наши исследования с рассмотрения эффекта парного программирования через призму экспериментов социальной психологии. Отдельную благодарность за рецензию и время, потраченное на прочтение первого варианта статьи, выражаем Асхату Уразбаеву, ценные замечания которого позволили не только улучшить данную статью, но и позволили убедиться в необходимости и востребованности именно цикла статей!
Читать -->

16.01.2012 20:09:00
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» состоится 14-16 февраля в Новосибирске
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» состоится 14-16 февраля в Новосибирске. Проводится совместными усилиями компаний СМ-Консалт, тренинговым центром КарьерЛаб. Место проведения тренинга в данный момент уточняется.

27.12.2011 16:15:27
Компания "СМ-Консалт" получила отзыв о работах в Федеральной Налоговой Службе (ГНИВЦ ФНС)
Специалистами ООО «СМ-Консалт» в 2010-2011г. был выполнен проект по настройке и внедрению системы управления жизненным циклом разработки программных систем в части управления изменениями и конфигурациями на основе Microsoft Visual Studio Team Foundation Server 2010 для Филиала Федерального государственного унитарного предприятия «Главный научно-исследовательский вычислительный центр Федеральной налоговой службы» в Приволжском Федеральном округе (Филиал ФГУП ГНИВЦ ФНС России в ПФО).

26.12.2011 21:05:28
Успешное проведение тренинга по коммуникациям и психологии для ИТ-руководителей в Санкт-Петербурге

В блоге Новичкова Александа доступен отчет авторов тренинга «Коммуникации и психология межличностных отношений в ИТ-проектах». В целом, тренинг завершился положительно - средний балл за интересность по 5 бальной шкале - 4,2 балла.
В отчете дается развернутый комментарий, подводятся итоги, рассматриваются как положительные моменты, так и элементы критики и пожеланий, собранные на основе анкет слушателей.
Читать -->

28.11.2011 20:09:21
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» состоится 19-21 декабря в Санкт-Петербурге
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» состоится 19-21 декабря в Санкт-Петербурге. Проводится совместными усилиями компаний СМ-Консалт, тренинговым центром КарьерЛаб и Legal SoftWave. Место проведения тренинга в данный момент уточняется.

28.11.2011 18:31:55
Компания «СМ-Консалт» сообщает об успешном завершении нового тренинга, проведенного совместно с компанией «Карьерлаб»!
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» прошел 17-18 ноября в Москве.
Слушатели проявили большой интерес и подтвердили важность выбранного направления. Контакт с аудиторией был установлен сразу. Были проработаны такие важные аспекты необходимых навыков из области психологии и коммуникаций, как умение управлять группой, говорить с заказчиком, как донести до оппонента свое решение и многое другое, что очень важно при разработке или внедрении ИТ-проектов.

28.11.2011 15:05:11
Новая статья: "Всегда ли «Да» – это «Да»? Или как нас вынуждают принимать решения"
Мы предлагаем вашему вниманию цикл статей, в основу которых положены психологические практики и приемы, позволяющие влиять на решения, принимаемые людьми. Эта идея была логическим продолжением ряда выступлений с докладами о коммуникациях в проектах разработки и внедрения ПО. Давайте, не откладывая в долгий ящик, начнем с самого простого приема убеждения, с которым сталкиваемся ежедневно в магазинах, в транспорте, в разговорах с коллегами… да мало ли где еще!
Авторы: Новичков Александр и Карабанова Галина.
Читать -->

10.10.2011 11:16:06
Компания «СМ-Консалт» открывает новое направление продаж - ПО Adobe Connect
Программное обеспечение Adobe Connect является гибкой системой web-коммуникации с высоким уровнем информационной безопасности. Adobe Connect предоставляет такие важнейшие функции корпоративного взаимодействия, как деловое общение и совместная работа сотрудников на уровне предприятий, дистанционное обучение, организация широкомасштабных сетевых семинаров и презентаций. Система Adobe Connect базируется на технологии Adobe Flash, а также Air, и поэтому позволяет подключать сотрудников к единому пространству взаимодействия через web-браузер с любых устройств.

17.09.2011 21:40:22
Новая статья: "Разработка прикладного программного обеспечения с использованием Rational Unified Process на Иркутском Авиационном заводе"

На сайте СМ-Консалт открыт новый раздел Статьи наших заказчиков об успешных внедрениях IBM Rational и Microsoft. Статьи для данного раздела пишутся нашими заказчиками и рассказывают о сути проектов внедрения технологий IBM и Microsoft. Первая статья, представленная вашему вниманию написана сотрудниками Иркутского Авиационного Завода (ИАЗ).

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

С целью повышения качества программного обеспечения собственной разработки и сокращения сроков разработки руководство Управления информационных технологий (УИТ) Иркутского Авиационного Завода в 2006г. приняло решение о внедрении технологии разработки ПО на базе методологии Rational Unified Process и с использованием инструментов автоматизации IBM Rational.

13.09.2011 12:07:29
Новый тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах»

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

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

25.08.2011 13:46:04
Компания СМ-Консалт сообщает об открытии нового направления деятельности: консалтинг и внедрение систем аналитической обработки информации (Business Intelligence)

Наша компания специализируется на консалтинге и внедрении инструментов и методологий IBM Rational, Microsoft и др. для повышения эффективности процессов разработки и сопровождения программного обеспечения.
Методы и технологии Business Intelligence являются прекрасным дополнением к ряду специализированных инструментальных средств, используемых для поддержки ЖЦ разработки ПО и управления ИТ-проектами. Инструменты BI играют роль недостающего промежуточного звена между основным бизнесом организации и ИТ-процессами, и, таким образом, способствуют повышению эффективности ключевых бизнес-процессов и достижению стратегических целей компании.

03.08.2011 14:05:11
На сайте размещены мультимедиа материалы докладов семинара «Повышение эффективности IT подразделений и качества разрабатываемого ПО с использованием современных методологий и технологий»
Компании СМ-Консалт , Legal SoftWaveTM и DNA провели бесплатный семинар-вебинар, посвященный обзору технологий и методологий, которые позволяют повысить эффективность ИТ подразделений. На семинаре были рассмотрены технологии IBM Rational, Microsoft TFS, а также системы аналитической обработки информации (Business Intelligence).
На нашем сайте размещены все мультимедийные материалы с семинара: презентации и видео-ролики с демонстрацией отдельных функций ПО IBM и Microsoft.
Перейти к просмотру: 14 июля 2011г. Семинар «Повышение эффективности IT подразделений и качества разрабатываемого ПО с использованием современных методологий и технологий»

01.08.2011 17:44:25
Наша компания получила отзыв о сотрудничестве с ОАО «Нордеа Банк»

В 2010-2011 гг. наши специалисты провели в Нордеа Банке проект по предварительному обследованию, развертыванию инструментальных средств и ряд тренингов по обучению методологии и работе с продуктами IBM Rational: «Методология разработки программных систем IBM Rational Unified Process», «Управление требованиями с использованием IBM Rational RequisitePro», «Управление изменениями в IBM Rational ClearQuest».

24.06.2011 01:27:57
Бесплатный семинар-вебинар «Повышение эффективности IT подразделений и качества разрабатываемого ПО с использованием современных методологий и технологий»
Компании СМ-Консалт , Legal SoftWaveTM и DNA приглашают Вас посетить бесплатный семинар-вебинар, посвященный обзору технологий и методологий, которые позволяют повысить эффективность ИТ подразделений. На семинаре рассматриваются технологии IBM Rational, Microsoft TFS, а также системы аналитической обработки информации (Business Intelligence) (IBM SPSS, Deductor, QlikView и другие).

Планируемая продолжительность семинара - 8 академических часов.

Место проведения: Санкт-Петербург (очно) и Интернет (для всех желающих: приходите сами и приглашайте друзей!).

Дата и время: 14 июля 2011 в 9 00.

ВНИМАНИЕ: если вы не сможете очно приехать на семинар - это не страшно, так как семинар будет транслироваться через интернет в формате вебинара и к нему, после регистрации, смогут присоединиться все желающие. Трансляция будет осуществляться посредством технологии Adobe Connect Pro , это позволит Вам присоединяться к конференции без установки дополнительного ПО - только интернет браузер.

Смотреть программу -->

07.06.2011 13:02:44
Компания "СМ-Консалт" провела серию успешных семинаров для ГНИВЦ ФНС России

Проведенные семинары были посвящены средствам разработки и тестирования программного обеспечения компании Майкрософт для сотрудников ГНИВЦ ФНС России. Слушатели семинаров отметили высокую квалификацию тренеров компании "СМ-Консалт" по организации учебного процесса и повышению квалификации специалистов, прошедших обучение.
Индивидуальный подход при решении любых вопросов, возникающих в процессе обучения, оперативность принятия решений, гарантированное выполнение взятых на себя обязательств и профессионализм позволили провести обучение на самом высоком уровне.

07.12.2010 12:28:15
Мы идем в Твиттер!

Наша компания открыла аккаунт в системе микроблоггинга Twiter.Теперь все официальные и неофициальные новости будут появляться в нашей ленте в Twitter.
Там же возможно будет задать прямые вопросы специалистам СМ-Консалт, по всем вопросам, связанным как с деятельностью компании, так и с техническими аспектов продуктов IBM и собственных решений СМ-Консалт.

Следуйте за нами!

https://twitter.com/cmconscom

11.11.2010 14:14:14
Осенний марафон Microsoft ALM Road Show
Компания СМ-Консалт совместно с образовательным центром Careerlab провели серию семинаров в рамках мероприятий ALM Roadshow 2.0 в крупнейших городах, расположенных на Волге, – крупных научных центрах, в которых ИТ технологии находятся на высоком уровне. Семинары прошли в Самаре, Нижнем Новгороде и Казани. Cеминары были посвящены использованию новых инструментов MS Visual Studio Team System в проектах разработки ПО.
В семинарах принимали участие представители различных ролей процесса разработки ПО: от разработчиков до руководителей предприятий различного уровня. Темы, обсуждаемые в ходе семинара, вызвали большой интерес аудитории и немалое количество вопросов, на которые были предоставлены исчерпывающие ответы. В процессе семинара также было показано большое количество примеров, которые дают представление о возможностях инструментов MS Team System. Средняя оценка за семинар составила 4,6 балла по пятибальной шкале

09.09.2010 16:11:03
Компания СМ-Консалт предлагает бесплатную настройку своих флагманских решений GanttChart и ProjectTracker.

Если вы хотите сэкономить время или у вас не получается сразу и эффективно настроить наши решения на вашу схему ClearQuest, то вы можете прислать свою схему ClearQuest нам и специалисты СМ-Консалт бесплатно в течение 3х рабочих дней:

Проведут анализ схемы и дадут заключение по настройке схемы ClearQuest своими силами*;
Предоставят ознакомительные лицензии на решения GanttChart и ProjectTracker сроком на один месяц;
Предоставят файлы настроек для GanttChart и ProjectTracker, адаптированные под вашу схему.

08.09.2010 18:37:52
Скидки до 30% на программное обеспечение IBM Rational

Компания СМ-Консалт предлагает для всех желающих на льготных условиях приобрести программное обеспечение IBM Rational. Снижение цен связано с тем, что мы стараемся быть как можно ближе к нашим клиентам, многие из которых постепенно начали преодолевать последствия финансового кризиса.Наше предложение поможет с минимальными издержками приобрести ПО IBM Rational, что является хорошим капиталовложением.
Скидки до 1 декабря 2010 года:

20% скидки при покупке IBM Rational ClearCase, ClearQuest, CearCase LT, при приобретении пяти и более лицензий*;
30% скидки при покупке пяти любых продуктов IBM Rational + решение или тренинг СМ-Консалт*.

Для получения деталей обязательно свяжитесь с нашими менеджерами

07.09.2010 13:53:40
Успешное внедрение уникального решения компании «СМ-Консалт» - GanttChart for ClearQuest в страховой компании «HUK-COBURG», Германия.
Компания «СМ-Консалт» и компания «HUK-COBURG» объявляют об успешном завершении проекта по поставке и внедрению решения «СМ-Консалт» - GanttChart for ClearQuest. Руководство «HUK-COBURG» обратилось в «СМ-Консалт» с просьбой поставки, адаптации и последующего сопровождения GanttChart for ClearQuest. С учетом требований Заказчика специалистами компании «СМ-Консалт» была выпущена и внедрена адаптированная версия GanttChart for ClearQuest, учитывающая особенности схемы процессов ClearQuest, применяемой в «HUK-COBURG», и дополнительные пожелания к функционированию GanttChart.

02.09.2010 14:41:12
Успешное внедрение Уникального решения СМ-Консалт - GanttChart for ClearQuest в Федеральном Национальном банке Бразилии

Компания СМ-Консалт и Федеральный Национальный банк Бразилии (ФНББ) объявляют об успешном завершении проекта по поставке и внедрению решения СМ-Консалт - GanttChart for ClearQuest. Руководство ФНББ, понимая ограничения использования IBM Rational ClearQuest в части проектного управления, обратилось в СМ-Консалт с просьбой поставки и адаптации GanttChart for ClearQuest под свои потребности.
С учетом требований Заказчика специалистами компании СМ-Консалт была выпущена и внедрена обновленная версия GanttChart for ClearQuest, учитывающая все особенности схемы процессов ClearQuest, применяемой в ФНББ.
По истечении срока опытной эксплуатации ФНББ приняло решение о принятии GanttChart for ClearQuest в промышленную эксплуатацию.

02.09.2010 14:17:23
Компания «СМ-Консалт» объявляет об успешном завершении обучения и консультирования IBM Rational сотрудников ЗАО «Промышленная Группа Метран» г. Челябинск.

В августе 2010 года специалистами компании «СМ-Консалт» были выполнены работы по обучению и консультированию сотрудников компании «Метран» методологии и инструментальным средствам процесса управления конфигурациями – IBM Rational Software ClearCase и ClearQuest. Был проведен тренинг-консультация «Практика и технология внедрения процесса конфигурационного управления и управления изменениями на основе IBM RUP, ClearCase и ClearQuest».

В тренинге принимали участие ведущие специалисты и руководители отделов компании «Метран».

29.06.2010 13:07:07
Успех семинара "Программное обеспечение IBM Rational для улучшения процессов разработки и сопровождения ПО" 15 июня 2010 г.
Компании "СМ-Консалт", IBM и DNA провели бесплатный семинар по теме "ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ IBM RATIONAL ДЛЯ УЛУЧШЕНИЯ ПРОЦЕССОВ РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПО" 15 июня 2010 года. На семинаре специалисты СМ-Консалт, IBM и UML2.RU рассказали о технологиях IBM Rational и поделились практическим опытом использования и внедрения методологии Rational Unified Process. Также были представлены отдельные решения СМ-Консалт, расширяющие функциональные характеристики IBM Rational.

Реклама:

Наши партнёры:

Наша рассылка: