Верификация программного обеспечения

Тестирование в Microsoft Solutions Framework

Разбить на страницы
Показывать лекцию целиком

27.1. Тест

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

  • При использовании какого метода интеграционного тестирования сначала все программные модули, входящие в состав системы, тестируются и только затем объединяются для интеграционного тестирования?

  • восходящего
  • монолитного
  • нисходящего
  • с поздней интеграцией
  • с постоянной интеграцией
  • с регулярной интеграцией
    •

    Ответ: 1

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

  • восходящего
  • монолитного
  • нисходящего
  • с поздней интеграцией
  • с постоянной интеграцией
  • с регулярной интеграцией

    • Ответ: 5

  • Для каких видов интеграционного тестирования нужен драйвер?

  • восходящего
  • монолитного
  • нисходящего
  • с поздней интеграцией
  • с постоянной интеграцией
  • с регулярной интеграцией

    • Ответ: 1, 5, 6

  • Для каких видов интеграционного тестирования нужны заглушки?

  • восходящего
  • монолитного
  • нисходящего
  • с поздней интеграцией
  • с постоянной интеграцией
  • с регулярной интеграцией

    • Ответ: 1, 3, 6

  • Для каких видов интеграционного тестирования при разработке часто выполняется интеграция?

  • восходящего
  • монолитного
  • нисходящего
  • с поздней интеграцией
  • с постоянной интеграцией
  • с регулярной интеграцией

    • Ответ: 3, 5, 6

    27.2. Проверка домашнего задания

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

    27.3. Роль тестировщика в команде разработчиков ПО

    27.3.1. Введение

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

    В конце курса мы поговорим о роли, обязанностях и задачах тестировщика в команде разработчиков программного обеспечения на примере методологии ведения проектов и разработки программного обеспечения Microsoft Solutions Framework (MSF) for Agile Software Development.

    27.3.2. Microsoft Solutions Framework

    Замечание. Подробнее о подходе MSF можно почитать по адресу http://www.microsoft.com/rus/msdn/msf/ или по адресу http://msdn.microsoft.com/vstudio/teamsystem/msf

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

    MSF — это методология ведения проектов и разработки решений, которая базируюется на принципах работы над продуктами как самой фирмы Microsoft, так и других компаний, работающих в области IT-индустрии.

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

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

    Главными принципами MSF можно назвать производительность, интегрируемость и расширяемость:

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

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

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

    (рис 27.1) Жизненный цикл в MSF

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

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

    (рис 27.2) Треугольник приоритетов в MSF

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

    Microsoft выпустила среду разработки, в полной мере поддерживающей основные идеи MSF – Microsoft Visual Studio 2005 Team System. Это первый программный комплекс, представляющий собой не среду разработки для индивидуальных членов коллектива, а комплексное средство поддержки коллективной работы (рис. 27.3).

    (рис 27.3) Структура Microsoft Visual Studio 2005 Team System

    Замечание. В состав Visual Studio Team Edition входит специальная редакция для тестировщиков – Team Edition for Software Testers, с которой мы и работали на протяжении всего курса.

    Также Visual Studio 2005 Team System включает в себя два шаблона методологий MSF, которые можно применять "как есть", настраивать под соответствие своим собственным потребностям или использовать как основу для создания своего собственного подхода для организации и управления процессом разработки программного обеспечения:

  • MSF for Agile Software Development
  • MSF for CMMI® Process Improvement
    •

    27.3.3. Тестировщик в MSF for Agile Software Development

    27.3.3.1. MSF for Agile Software Development

    Microsoft Solutions Framework (MSF) for Agile Software Development — управляемый сценариями, основанный на окружении, быстрый процесс разработки программного обеспечения для создания .NET и других объектно-ориентированных приложений. MSF for Agile Software Development включает в себя подходы по управлению требованиями к качеству, такими, как требования к оборудованию или требования к безопасности. На основании окружения MSF помогает решить, как управлять проектом. Этот подход помогает создавать адаптивный процесс, который, преодолевая трудности большинства быстрых процессов разработки программного обеспечения, достигает целей, поставленных при создании проекта перед командой разработчиков.

    27.3.3.2. О ролях

    В MSF for Agile Software Development собрана вместе команда равных разработчиков (рис. 27.4), которая обеспечивает полный набор необходимых составляющих, связанных с созданием, использованием и обслуживанием создаваемого продукта. Каждый член команды, или роль, отвечает за удовлетворения нужд своей клиентуры, причем ни один клиент не является важнее другого. MSF for Agile Software Development содержит все необходимые методики и подходы для уверенности в том, что команда разработчиков принимает правильные решения.

    (рис 27.4) Команда разработчиков MSF for Agile Software Development

    Подробную информацию об MSF for Agile Software Development и ролях в этом подходе можно найти на сайте Microsoft в соответствующем разделе.

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

    27.3.3.4. О роли тестировщика

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

    Далее будет описана последовательность работы тестировщика по подходу MSF for Agile Software Development.

    27.3.3.4.1. Проверка сценария

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

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

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

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

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

    Если это сделано, то выполняются следующие действия.

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

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

    Далее необходимо написать валидационные тесты.

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

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

    Если это сделано, то выполняются следующие действия.

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

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

    Далее необходимо произвести выбор и запуск тестового примера.

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

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

    Если это сделано, то выполняются следующие действия.

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

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

    Далее необходимо произвести выявление ошибки.

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

    Этот этап производится, если тестирование выявило неожиданное поведение системы.

    Если это так, то выполняются следующие действия.

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

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

    Далее необходимо произвести исследовательское тестирование.

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

    Этот этап производится, если сборка готова к тестированию на новые требования или ошибки и роли опубликованы на портале проекта..

    Если это выполнено, то выполняются следующие действия.

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

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

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

    27.3.3.4.2. Тестирование требований к качеству

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

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

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

    Далее необходимо написать тесты на производительность.

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

    Если это сделано, то выполняются следующие действия.

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

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

    Далее необходимо написать тесты безопасности.

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

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

    Если это сделано, то выполняются следующие действия.

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

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

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

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

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

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

    27.3.3.4.3. Стрессовое тестирование

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

    27.3.3.4.4. Закрытие ошибок

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

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

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

    Сначала необходимо провести исправление ошибки.

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

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

    Если это сделано, то выполняются следующие действия.

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

    Далее необходимо провести собственно закрытие ошибки.

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

    Если это сделано, то выполняются следующие действия.

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

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

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

    Страницы:

    27.1. Тест

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

  • При использовании какого метода интеграционного тестирования сначала все программные модули, входящие в состав системы, тестируются и только затем объединяются для интеграционного тестирования?

  • восходящего
  • монолитного
  • нисходящего
  • с поздней интеграцией
  • с постоянной интеграцией
  • с регулярной интеграцией
    •

    Ответ: 1

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

  • восходящего
  • монолитного
  • нисходящего
  • с поздней интеграцией
  • с постоянной интеграцией
  • с регулярной интеграцией

    • Ответ: 5

  • Для каких видов интеграционного тестирования нужен драйвер?

  • восходящего
  • монолитного
  • нисходящего
  • с поздней интеграцией
  • с постоянной интеграцией
  • с регулярной интеграцией

    • Ответ: 1, 5, 6

  • Для каких видов интеграционного тестирования нужны заглушки?

  • восходящего
  • монолитного
  • нисходящего
  • с поздней интеграцией
  • с постоянной интеграцией
  • с регулярной интеграцией

    • Ответ: 1, 3, 6

  • Для каких видов интеграционного тестирования при разработке часто выполняется интеграция?

  • восходящего
  • монолитного
  • нисходящего
  • с поздней интеграцией
  • с постоянной интеграцией
  • с регулярной интеграцией

    • Ответ: 3, 5, 6

    27.2. Проверка домашнего задания

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

    27.3. Роль тестировщика в команде разработчиков ПО

    27.3.1. Введение

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

    В конце курса мы поговорим о роли, обязанностях и задачах тестировщика в команде разработчиков программного обеспечения на примере методологии ведения проектов и разработки программного обеспечения Microsoft Solutions Framework (MSF) for Agile Software Development.

    27.3.2. Microsoft Solutions Framework

    Замечание. Подробнее о подходе MSF можно почитать по адресу http://www.microsoft.com/rus/msdn/msf/ или по адресу http://msdn.microsoft.com/vstudio/teamsystem/msf

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

    MSF — это методология ведения проектов и разработки решений, которая базируюется на принципах работы над продуктами как самой фирмы Microsoft, так и других компаний, работающих в области IT-индустрии.

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

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

    Главными принципами MSF можно назвать производительность, интегрируемость и расширяемость:

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

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

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

    (рис 27.1) Жизненный цикл в MSF

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

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

    (рис 27.2) Треугольник приоритетов в MSF

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

    Microsoft выпустила среду разработки, в полной мере поддерживающей основные идеи MSF – Microsoft Visual Studio 2005 Team System. Это первый программный комплекс, представляющий собой не среду разработки для индивидуальных членов коллектива, а комплексное средство поддержки коллективной работы (рис. 27.3).

    (рис 27.3) Структура Microsoft Visual Studio 2005 Team System

    Замечание. В состав Visual Studio Team Edition входит специальная редакция для тестировщиков – Team Edition for Software Testers, с которой мы и работали на протяжении всего курса.

    Также Visual Studio 2005 Team System включает в себя два шаблона методологий MSF, которые можно применять "как есть", настраивать под соответствие своим собственным потребностям или использовать как основу для создания своего собственного подхода для организации и управления процессом разработки программного обеспечения:

  • MSF for Agile Software Development
  • MSF for CMMI® Process Improvement
    •

    27.3.3. Тестировщик в MSF for Agile Software Development

    27.3.3.1. MSF for Agile Software Development

    Microsoft Solutions Framework (MSF) for Agile Software Development — управляемый сценариями, основанный на окружении, быстрый процесс разработки программного обеспечения для создания .NET и других объектно-ориентированных приложений. MSF for Agile Software Development включает в себя подходы по управлению требованиями к качеству, такими, как требования к оборудованию или требования к безопасности. На основании окружения MSF помогает решить, как управлять проектом. Этот подход помогает создавать адаптивный процесс, который, преодолевая трудности большинства быстрых процессов разработки программного обеспечения, достигает целей, поставленных при создании проекта перед командой разработчиков.

    27.3.3.2. О ролях

    В MSF for Agile Software Development собрана вместе команда равных разработчиков (рис. 27.4), которая обеспечивает полный набор необходимых составляющих, связанных с созданием, использованием и обслуживанием создаваемого продукта. Каждый член команды, или роль, отвечает за удовлетворения нужд своей клиентуры, причем ни один клиент не является важнее другого. MSF for Agile Software Development содержит все необходимые методики и подходы для уверенности в том, что команда разработчиков принимает правильные решения.

    (рис 27.4) Команда разработчиков MSF for Agile Software Development

    Подробную информацию об MSF for Agile Software Development и ролях в этом подходе можно найти на сайте Microsoft в соответствующем разделе.

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

    27.3.3.4. О роли тестировщика

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

    Далее будет описана последовательность работы тестировщика по подходу MSF for Agile Software Development.

    27.3.3.4.1. Проверка сценария

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

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

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

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

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

    Если это сделано, то выполняются следующие действия.

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

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

    Далее необходимо написать валидационные тесты.

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

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

    Если это сделано, то выполняются следующие действия.

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

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

    Далее необходимо произвести выбор и запуск тестового примера.

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

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

    Если это сделано, то выполняются следующие действия.

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

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

    Далее необходимо произвести выявление ошибки.

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

    Этот этап производится, если тестирование выявило неожиданное поведение системы.

    Если это так, то выполняются следующие действия.

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

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

    Далее необходимо произвести исследовательское тестирование.

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

    Этот этап производится, если сборка готова к тестированию на новые требования или ошибки и роли опубликованы на портале проекта..

    Если это выполнено, то выполняются следующие действия.

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

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

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

    27.3.3.4.2. Тестирование требований к качеству

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

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

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

    Далее необходимо написать тесты на производительность.

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

    Если это сделано, то выполняются следующие действия.

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

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

    Далее необходимо написать тесты безопасности.

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

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

    Если это сделано, то выполняются следующие действия.

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

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

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

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

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

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

    27.3.3.4.3. Стрессовое тестирование

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

    27.3.3.4.4. Закрытие ошибок

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

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

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

    Сначала необходимо провести исправление ошибки.

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

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

    Если это сделано, то выполняются следующие действия.

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

    Далее необходимо провести собственно закрытие ошибки.

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

    Если это сделано, то выполняются следующие действия.

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

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

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

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^