теория_7 (Методичка и инструкции на ЛР №8)

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

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

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

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

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

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

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

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

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

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

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

• влияние остаточных данных от предыдущих тестовых примеров, ранее остававшееся незамеченным.

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

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

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

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

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

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

1. Анализ изменений в системе

2. Выбор тестовых примеров для проверки системы

3. Выполнение тестовых примеров

4. Анализ результатов выполнения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

21.2.1.1. На примере "Калькулятора"

Рассмотрим повторяемость тестирования на примере нашего "Калькулятора".

Рассмотрим свойство CalcClass.lastError:

/// <summary>

/// Последннее сообщение об ошибке.

/// </summary>

private static string _lastError = "";

public static string lastError

{

get

{

}

}

Оно хранит последнее сообщение об ошибке. При этом "Калькулятор", вычисляя выражение после каждой арифметической операции, проверяет значение переменной и, если оно не равно пустой строке, выдает сообщение об ошибке и прерывает работу. Однако у свойства lastError нет аксессора set, и значит, никакой внешний модуль не может поменять его значения. Напрашивается вопрос – а как же сбрасывается это значение? Проведем три теста подряд на методе сложения:

try

{

richTextBox1.Text = "";

richTextBox1.Text += "Test Case 1\n";

richTextBox1.Text += "Входные данные: a= 78508, b = -304\n";

richTextBox1.Text += "Ожидаемый результат: res = 78204 &&

error = \"\"" + "\n";

int res = CalcClass.Add(78508, -304);

string error = CalcClass.lastError;

richTextBox1.Text += "Код ошибки: " + error + "\n";

richTextBox1.Text += "Получившийся результат: " + "res = " +

res.ToString() + " error = " + error.ToString() + "\n";

if (res == 78204 && error == "")

{

richTextBox1.Text += "Тест пройден\n\n";

}

else