Национальный исследовательский ядерный университет «МИФИ»
Опубликован: 28.11.2007 | Доступ: свободный | Студентов: 5106 / 774 | Оценка: 4.53 / 3.65 | Длительность: 22:18:00
ISBN: 978-5-94774-825-3
Специальности: Программист, Тестировщик
Лекция 6:

Документация, сопровождающая процесс верификации и тестирования (тест-требования)

10.2. Стратегия и планы верификации

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

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

Для каждого этапа определяется:

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

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

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

Согласно разделу 4 стандарта IEEE 829 [15] основная задача плана тестирования как документа - определение границ тестирования, подхода к тестированию, требуемых для тестирования ресурсов, плана-графика тестирования. План тестирования определяет тестируемые элементы и функции системы, задачи, решаемые в ходе тестирования, сотрудников, ответственных за тестирование, и риски, связанные с этим планом. Такая форма плана тестирования является достаточно полной и включает в себя не только технические аспекты, связанные собственно с описанием тестовых примеров, но и организационные, связанные с общим управлением процессом тестирования. На практике объемы технических и организационных разделов планов тестирования могут достаточно сильно варьироваться. Однако, минимально необходимые элементы, которые рекомендуется включать в каждый план тестирования - это:

  • идентификатор плана тестирования и номер его версии, который позволяет однозначно находить нужный план тестирования и его последнюю актуальную версию в базе данных проекта;
  • общее описание тест-плана ;
  • трассировка на другие документы - стандарты, планы тестирования, тест-требования, результаты выполнения тестов;
  • определение тестируемых областей системы - указание частей проектной документации, исходных текстов, исполняемого кода, подвергаемых верификации с указанием типа верификации (автоматизированные тесты, формальные инспекции, тестирование на моделях, полунатурные испытания и т.п.);
  • определение подходов к тестированию - определение общих методик, которых следует придерживаться при тестировании системы. Несмотря на то, что большинство тестов могут довольно сильно различаться, общие методы и подходы к их построению могут быть едиными;
  • критерий успешности/неуспешности прохождения тестов (pass/fail criteria) - в данном разделе описывается то, каким образом определяется успешность прохождения тестов для различных частей системы;
  • тестовые документы - как правило, план тестирования содержит в качестве приложений все тестовые документы более низких уровней - тест-требования, тест-планы, результаты выполнения тестов, данные о сборе покрытия. В случае, если включать эти документы в состав плана тестирования представляется нецелесообразным (например, в случае их значительного объема), рекомендуется помещать ссылки на эти документы;
  • требования к среде тестирования - данный раздел описывает требования к аппаратным и программным средствам, необходимым для проведения тестирования. В случае встроенного программного обеспечения программная система обычно работает на специальном аппаратном обеспечении, а инструментальные средства для тестирования - на обычных PC общего назначения. Для выполнения тестирования в таких условиях требуется либо использование эмуляторов, либо программно-аппаратный комплекс для сопряжения специального аппаратного обеспечения с PC. Кроме того, как правило, в состав программных средств тестирования входят кросс-средства разработки. В случае, если тестируется система общего назначения, в данном разделе просто перечисляются требования к оборудованию, необходимому для тестирования, которые, как правило, несколько выше, чем требования к оборудованию, достаточному для работы системы;
  • людские ресурсы и уровень их подготовки - в данном разделе приводится состав группы тестирования, необходимый для успешного завершения тестирования в поставленные сроки, а также приводится необходимые знания для различных ролей в группе;
  • план-график тестирования - содержит сроки всех фаз тестирования;
  • риски - содержит список рисков, которые могут помешать завершить тестирование в срок или с необходимым уровнем качества. Как правило, для каждого риска оценивается вероятность его возникновения, а также приводятся общие пути, при помощи которых можно избежать возникновения риска или ликвидировать его последствия

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

10.3. Тест-требования

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

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

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

Место тест-требований среди проектной документации

Рис. 10.2. Место тест-требований среди проектной документации

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

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

Илья Макаренко
Илья Макаренко

Добрый день.

Вопрос №1

Какова стоимость получения диплома о мини-МБА по данному курсу? Или ориентироваться на указанную на сайте?

Вопрос №2

Возможно ли начать обучение без потери результатов, не отправив документы на зачисление, а отправку выполнить позже?

Александр Медов
Александр Медов

Здравствуйте, какова полная сумма предоставленной услуги с печатью документа и отправкой по почте?