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

21.1. Тест

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

1. Полная система тестов позволяет утверждать, что:

   1. система реализует всю функциональность, указанную в требованиях
   2. система работает корректно
   3. система не реализует функциональность, которая не указана в требованиях
   4. система работает правильно
   5. система реализует функциональность, которая не указана в требованиях
   6. система не реализует функциональность, которая указана в требованиях

   Ответ: 1, 3

2. Выберите верные утверждения:

   1. Полное покрытие по веткам дает полное покрытие по строкам.
   2. Полное покрытие по веткам не дает полного покрытия по строкам.
   3. Полное покрытие по строкам без ветвления дает полное покрытие кода по веткам.
   4. Полное покрытие по MC\DC не дает полного покрытия по строкам.

   Ответ: 1, 3

3. Какие условия должны быть выполнены для обеспечения полного покрытия по методу MC\DC?

   1. должно быть показано зависимое влияние каждой из компонент на значение логического условия
   2. каждое логическое условие должно принимать все возможные значения
   3. каждая компонента логического условия должна хотя бы один раз принимать все возможные значения
   4. любая часть логического условия должна принимать хотя бы раз все возможные значения
   5. должно быть показано независимое влияние каждой из компонент на значение логического условия

   Ответ: 2, 3, 5

4. Согласно методу MC\DC для тестирования логической функции с тремя входами и одним выходом достаточно:

   1. 3-х тестовых примеров
   2. 4-х тестовых примеров
   3. 5-х тестовых примеров
   4. 6-х тестовых примеров

   Ответ: 2

5. Одной из основных задач анализа полноты покрытия кода является:

   1. выявление участков кода, которые выполняются при выполнении тестовых примеров
   2. выявление участков кода, которые содержат ошибки
   3. выявление участков кода, которые не выполняются при выполнении тестовых примеров
   4. выявление участков кода, которые не содержат ошибок

   Ответ: 3

21.2. Повторяемость тестирования

21.2.1. Теоретическое вступление

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Анализ изменений в системе
2. Выбор тестовых примеров для проверки системы
3. Выполнение тестовых примеров
4. Анализ результатов выполнения
5. Модификация тестового окружения, тестовых примеров или уведомление разработчиков о дефекте системы.

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

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

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

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

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

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

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

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

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

На практике часто возникает ситуация в которой друг за другом следует несколько десятков тестовых примеров, а при регрессионном тестировании требуется выполнить, например, тестовые примеры с номерами от 25 по 40. Первый тестовый пример при этом инициализирует систему, а остальные работают с уже стартовавшей системой. Если просто выполнять тестовые примеры 25-40, то их выполнение окажется невозможным – они не инициализируют систему. Разумным выходом из этой ситуации является выполнение тестовых примеров 1, 25-40.