29. Жизненный цикл тестирования. Стратегии тестирования, критерии тестирования. План тестирования, тест-CASE, покрытия критерия, оценка полноты тестирования ПО. Метрики и критерии тестирования. Метод «черного ящика». Метод «белого ящика».

Способы

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

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

23(1). Модульное/интеграционное/системное тестирование (unit / integration / system testing). Модульное тестирование (Unit Testing) Заключается в изолированной проверке каждого отдельного элемента путем запуска тестов в искусственной среде. Идея в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок. Оценивая каждый элемент изолированно и подтверждая корректность его работы, точно установить проблему значительно проще чем, если бы элемент был частью системы. Интеграционное тестирование. Предназначено для проверки связи между компонентами, а также взаимодействия с различными частями системы (операционной системой, оборудованием и т.п) Уровни интеграционного тестирования: ● Компонентный интеграционный уровень (Component Integration testing). Проверяется взаимодействие между компонентами системы. ● Системный интеграционный уровень (System Integration Testing). Проверяется взаимодействие между разными системами. Подходы к интеграционному тестированию:

  1. Снизу вверх (Bottom Up Integration) - Все низкоуровневые модули, процедуры или функции собираются воедино и тестируются. Подход полезный, если практически все разрабатываемые модули, готовы.
  2. Сверху вниз (Top Down Integration) - Вначале тестируются высокоуровневые модули, и постепенно добавляются низкоуровневые. Модули более низкого уровня симулируются заглушками с   23(2). Модульное/интеграционное/системное тестирование (unit / integration / system testing). аналогичной функциональностью, затем по мере готовности заменяются реальными компонентами.
  3. Большой взрыв (“Big Bang” Integration) - Разработанные модули собираются в виде законченной системы, проводится интеграционное тестирование. Подход хорош для сохранения времени. Если тест кейсы и их результаты записаны неверно, процесс интеграции осложнится. Системное тестирование Основной задачей является проверка функциональных и нефункциональных требований в системе. Выявляются дефекты, такие как неверное использование ресурсов системы, не предусмотренные комбинации данных пользовательского уровня, несовместимость с окружением и т.д. Для минимизации рисков, связанных с особенностями поведения системы в той или иной среде, во время тестирования рекомендуется использовать окружение максимально приближенное к тому, на которое будет установлен продукт после выдачи. Подхода к системному тестированию: ● на базе требований (requirements based). Для каждого требования пишутся тестовые случаи (test cases), проверяющие выполнение данного требования. ● на базе случаев использования (use case based). На основе представления о способах использования продукта создаются случаи использования системы (Use Cases). По конкретному случаю использования можно определить один или более сценариев. На проверку каждого сценария пишутся тест кейсы (test cases), которые должны быть протестированы.

 

  1. Дымовое тестирование/тестирование критического пути/расширенное тестирование (smoke testing/ critical path/extended test)

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

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

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

  1. Альфа-тестирование (alpha testing), Бета-тестирование (beta testing), Гамма-тестирование (gamma testing).

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

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

Гамма тестирование Третья стадия тестирования программного продукта (после альфа и бета тестирования) перед его коммерческим выпуском. На этапе гамма тестирования не в окончательном виде могут быть только документация и упаковка проекта. Гамма тестирование считается законченным тогда когда ПО готово к выпуску и все требования выполнены. К сожалению гамма-тестирование отходит в прошлое из-за сокращения циклов работы и конкуренции.   26(1). Метрики тестирования

Множество метрик процесса тестирования делятся на два класса:

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

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

26(2). Метрики тестирования

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

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

  1. Периодичность тестирования

• Оперативное тестирование (unit) Чаще всего выражено в виде модульного тестирования. Проводится самим разработчиком. • Ежедневное тестирование (daily/nightly) Служит для контроля текущей работоспособности приложения. • Еженедельное тестирование (weekly) В основном предназначено для тестирования новой функциональности (модуля), разработанной за текущий отрезок времени. • Версионное тестирование (release) Тестирование новой версии продукта  

  1. Чек-листы. Тест-кейсы. Характеристики хорошего теста

Чек-лист (check list) — это документ, описывающий что должно быть протестировано. При этом чек-лист может быть абсолютно разного уровня детализации. Насколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта. Как правило, чек-лист содержит только действия (шаги), без ожидаемого результата. Чек-лист менее формализован чем тестовый сценарий. Его уместно использовать тогда, когда тестовые сценарии будут избыточны. Тест-кейс — это такое описание проверки работы системы, которое может выполнить любой человек из команды, Стандартные атрибуты тест-кейса Номер — уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь Название — краткое описание сути проверки. Должно помещаться в заголовок и быть понятным! Кратко, но емко. Предварительные шаги — описание действий, которые необходимо выполнить, но прямого отношения к проверке они не имеют (например, зарегистрироваться в системе для проверки создания элемента). Если предварительных шагов нет, то секция не заполняется. Шаги — описание действий, необходимых для проверки (например, создание элемента). Ожидаемый результат (ОР) — сама проверка: что мы ожидаем получить после выполнения шагов (“Элемент создан”). характеристики хорошего теста каждый тест кейс включает в себя стандартные атрибуты(см. выше) каждый выполненный тест-кейс, дает нам один из трех результатов: 1.Положительный результат, если фактический результат равен ожидаемому результату, 2.Отрицательный результат, если фактический результат не равен ожидаемому результату. В этом случае, найдена ошибка. 3.Выполнение теста блокировано, если после одного из шагов продолжение теста невозможно. В этом случае так же, найдена ошибка. Чего не должно быть в тест-кейсе

  1. Зависимостей от других тест-кейсов;
  2. Нечеткой формулировки шагов или ожидаемого результата;
  3. Отсутствия необходимой для прохождения тест-кейса информации;
  4. Излишней детализации.