1 : C
Дипломная работа
19 янв 2023
10 страниц

Готовая работа №8. Повторяемость тестирования

8. Повторяемость тестирования
8.1. Теоретическое вступление
8.1.1. Задачи и цели обеспечения повторяемости тестирования при промышленной разработке программного обеспечения
Как уже было сказано в предыдущих темах, тестирование программной системы – не разовое мероприятие, а постоянный процесс, активный в течение всего жизненного цикла разработки системы. В течение этого процесса система неизбежно изменяется – либо в результате исправления ошибок, либо в результате расширения ее функциональности. Задача тестировщика в такой ситуации – подтвердить, что новая или исправленная функциональность не вызвала новые ошибки, а если ошибки все-таки возникли – определить причины их возникновения.
Самый простой, но в то же время действенный способ такого подтверждения – полное выполнение всех тестовых примеров после каждого существенного изменения системы и сравнение результатов выполнения тестов до и после изменения.
Если результаты выполнения тестов до внесения изменений были положительными (все тесты проходили успешно), то появление неуспешно пройденных тестов может означать, что в системе появились новые дефекты, вызванные исправлением старых.
В общем случае повторное выполнение тестов может завершиться одним из трех способов.
1. Все тесты пройдены успешно. В этом случае изменения не затрагивают уже протестированные функции, но может потребоваться разработка новых тестовых примеров для новых функций системы.
2. Часть тестов, ранее выполнявшихся успешно, завершается с отрицательным результатом. Причины этого могут быть следующие:
o корректное изменение функциональности тестируемой системы, в результате которого тестовый пример перестал соответствовать требованиям;
o некорректное изменение функциональности системы, в результате которого тестовый пример выявил расхождение с требованиями;
o влияние остаточных данных от предыдущих тестовых примеров, ранее остававшееся незамеченным.
Первые две причины различимы только при помощи анализа изменений в функциональных требованиях и тест-требованих, а также текущего состояния тест-планов и тестового окружения. По результатам этого анализа в первом случае тестировщик вносит изменения в тестовый пример (и, возможно, разрабатываются новые тестовые примеры), во втором случае тестировщик уведомляет разработчиков о наличии дефекта.
3. Выполнение тестов аварийно завершается в самом начале или при выполнении определенного тестового примера.
Данная проблема чаще всего связана с изменением внешнего окружения тестируемой части системы, которое моделирует тестовое окружение. Из-за таких изменений могут меняться внешние интерфейсы, а также состав и формат входных и выходных данных. В результате тестовое окружение перестает обеспечивать необходимую для выполнения тестов инфраструктуру и возникает сбой процесса тестирования. Например, такой сбой может возникнуть в тестовом окружении при попытке обработать данные, выдаваемые системой в новом формате.
Если для выполнения тестов требуется сборка программных модулей тестового окружения и тестируемой системы в единый исполняемый код, то при изменении интерфейсов системы может возникнуть ситуация, когда невозможно не только выполнение тестов, а даже сборка окружения и системы. В этом случае также необходимо провести анализ изменений, внесенных в систему, и модифицировать в соответствии с ними тестовое окружение.
Иногда повторное выполнение всех тестов невозможно. Это может быть связано с большим временем выполнения всех тестов и ограниченным временем, отведенным на процесс тестирования. В этом случае часто применяется практика выборочного тестирования отдельных частей системы, затронутых изменениями. Полное тестирование при таком подходе проводится только после накопления достаточно большого количества изменений или на ключевых стадиях проекта.
Процесс, включающий в себя повторное выполнение всех тестов, называют регрессионным тестированием. Регрессионное тестирование включает в себя следующие стадии:
1. Анализ изменений в системе
2. Выбор тестовых примеров для проверки системы
3. Выполнение тестовых примеров
4. Анализ результатов выполнения
5. Модификация тестового окружения, тестовых примеров или уведомление разработчиков о дефекте системы.
Таким образом можно определить следующие основные задачи повторяемости тестирования при внесении изменений.
• Обеспечение возможности полного выполнения всех тестов, проверяющих функциональность системы или проведение анализа, позволяющего выявить тесты, которые должны быть повторно выполнены для тестирования изменившейся функциональности.
• Разработка тестовых примеров и тестового окружения с использованием методик, облегчающих модификацию при изменениях в тестируемой системе.
• Разработка тестовых примеров, структура которых полностью исключает их взаимное влияние по остаточным данным.
Целью повторяемости тестирования является постоянное обеспечение тестировщиков и разработчиков актуальной информацией о текущем состоянии системы и корректности изменений, внесенных в ходе разработки системы.
8.1.2. Предусловия для выполнения теста, настройка тестового окружения, оптимизация последовательностей тестовых примеров
Как уже было сказано ранее, входные данные в каждом тестовом примере явно задают начальное состояние тестируемой системы и режимы ее работы при выполнении тестового сценария.
Однако неявное влияние на выполнение теста оказывает и состояние тестового окружения. Под состоянием здесь понимается набор параметров, изменение любого из которых может повлиять либо на результат выполнения тестового примера, либо на возможность его корректной работы и завершения.
Например, для выполнения тестового примера тестируемой системе может потребоваться значительный объем дисковой или оперативной памяти. Если перед выполнением теста тестовое окружение выделит эту память под свои нужды, выполнение теста окажется невозможным. Та же самая ситуация может возникнуть и в случае, если окружение не освободит память после выполнения предыдущего тестового примера.
Эта информация обычно отсутствует в тест-планах, однако требуемое для выполнения тестов состояние тестового окружения необходимо учитывать при разработке тестовых примеров.
Хорошей практикой является оформление проверок на допустимость состояния тестового окружения в виде предусловий для выполнения теста. Это позволяет диагностировать ситуации, возникающие при выборочном тестировании и приводящие к отказам тестового окружения.
На практике часто возникает ситуация в которой друг за другом следует несколько десятков тестовых примеров, а при регрессионном тестировании требуется выполнить, например, тестовые примеры с номерами от 25 по 40. Первый тестовый пример при этом инициализирует систему, а остальные работают с уже стартовавшей системой. Если просто выполнять тестовые примеры 25-40, то их выполнение окажется невозможным – они не инициализируют систему. Разумным выходом из этой ситуации является выполнение тестовых примеров 1, 25-40.
8.1.3. Зависимость между тестовыми примерами, настройки по умолчанию для тестовых примеров и их групп
Для облегчения проведения регрессионного тестирования (и тестирования вообще) тестовые примеры часто разбивают на группы. Каждая группа содержит набор тестовых примеров, проверяющих отдельную замкнутую часть функциональности тестируемой системы. При отборе тестовых примеров для частичного регрессионного тестирования их можно отбирать сразу группами.
Разбиение тестовых примеров на группы удобно и с точки зрения установки начального состояния тестового окружения для выполнения тестов – так, перед выполнением группы тестов можно инициализировать значения переменных или состояние системы, необходимое для выполнения всей группы. Например, если система работает в двух режимах – нормальном и сервисном, то перед выполнением группы тестов для нормального режима работы системы нужно устанавливать нормальный режим, а перед выполнением тестов для сервисного режима – сервисный. Такие установки называются настройками группы тестов по умолчанию (group defaults, test group defaults).
Перед выполнением каждого тестового примера может потребоваться установка одних и тех же переменных в одни и те же значения. Для того, чтобы не дублировать эти установки в описании каждого тестового примера, в тест-плане можно определить настройки по умолчанию для каждого теста (test case defaults).
Как видно из предыдущего раздела, для облегчения проведения выборочного регрессионного тестирования каждый тестовый пример должен быть полностью автономным – ход его выполнения и тем более, результат не должны зависеть от предыдущих тестовых примеров. Тем самым, при выборочном тестировании результат тестирования не зависит от выбранного набора тестовых примеров (тестового набора). Однако, на практике создание автономных тестов зачастую невозможно по различным причинам (как правило – из-за длительного времени выполнения таких тестов).
В случае, когда в наборе тестовых примеров тесты не являются автономными, говорят о тестовой зависимости. Тестовая зависимость бывает двух видов – предусмотренная структурой тестовых примеров и паразитная.
Пример предусмотренной тестовой зависимости был рассмотрен в предыдущем разделе – корректность выполнения тестов определялась порядком их выполнения. Такая тестовая зависимость требует документирования и сопровождения, как и сами описания тестовых примеров. Существует два вида документирования тестовых зависимостей:
• явное определение допустимого порядка выполнения тестовых примеров. Такой способ удобен при сравнительно небольшом общем количестве тестовых примеров, либо, при разбиении на группы – при небольшом размере групп тестовых примеров;
• определение допустимого порядка выполнения тестовых примеров при помощи предусловий. При таком способе корректность порядка выполнения тестовых примеров определяется при помощи проверки того, что либо тестируемая система, либо тестовое окружение находятся в необходимом состоянии для выполнения тестового примера.
Паразитные тестовые зависимости обычно вызваны некорректным составлением тест-плана. Проявляются они, как и предусмотренные зависимости, в том, что один (или более) тестовых примеров корректно работает только в том случае, если до него были выполнены другие тестовые примеры. Причем такая зависимость не является предусмотренной тестировщиком. Природа паразитной тестовой зависимости схожа с природой ошибок использования неинициализированных или остаточных данных в динамической памяти при программировании.
8.2.1. На примере "Калькулятора"
Рассмотрим повторяемость тестирования на примере нашего "Калькулятора".
Рассмотрим свойство CalcClass.lastError:
///
/// Последннее сообщение об ошибке.
///
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
{
richTextBox1.Text += "Тест не пройден\n\n";
}
}
catch (Exception ex)
{
richTextBox1.Text += "Перехвачено исключение: " +
ex.ToString() + "\nТест не пройден.\n";
}

try
{
richTextBox1.Text += "Test Case 2\n";
richTextBox1.Text += "Входные данные: a= -2850800078, b = 3000000000\n";
richTextBox1.Text += "Ожидаемый результат: res = 0 && error =
\"Error 06\"\n";
int res = CalcClass.Add(-2850800078, 3000000000);
string error = CalcClass.lastError;
richTextBox1.Text += "Код ошибки: " + error + "\n";
richTextBox1.Text += "Получившийся результат: " + "res = " +
res.ToString() + " error = " + error.ToString() + "\n";
if (res == 0 && error == "Error 06")
{
richTextBox1.Text += "Тест пройден\n\n";
}
else
{
richTextBox1.Text += "Тест не пройден\n\n";
}
}
catch (Exception ex)
{
richTextBox1.Text += "Перехвачено исключение: " +
ex.ToString() + "\nТест не пройден.\n";
}

try
{
richTextBox1.Text += "Test Case 3\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
{
richTextBox1.Text += "Тест не пройден\n\n";
}
}
catch (Exception ex)
{
richTextBox1.Text += "Перехвачено исключение: " +
ex.ToString() + "\nТест не пройден.\n";
}
8.1.
Результат:
Test Case 1
Входные данные: a= 78508, b = -304
Ожидаемый результат: res = 78204 && error = ""
Код ошибки:
Получившийся результат: res = 78204 error =
Тест пройден

Test Case 2
Входные данные: a= -2850800078, b = 3000000000
Ожидаемый результат: res = 0 && error = "Error 06"
Код ошибки: Error 06
Получившийся результат: res = 0 error = Error 06
Тест пройден

Test Case 3
(повторный тест)Входные данные: a= 78508, b = -304
Ожидаемый результат: res = 78204 && error = ""
Код ошибки: Error 06
Получившийся результат: res = 78204 error = Error 06
Тест не пройден

Как видно, несмотря на то, что третий тест операции сложения должен быть выполнен, он не проходит, хотя по первому тесту видно, что сложение работает правильно, а значение lastError точно такое же, что и во втором тесте. Это может свидетельствовать, например, о том, что при вызове метода Add в начале своей работы не очищается поле _lastError. Проведем тестирование всех функций:
try
{
richTextBox1.Text += "Test Case 2\n";
richTextBox1.Text += "Входные данные: a= -2850800078, b = 3000000000\n";
richTextBox1.Text += "Ожидаемый результат: res = 0 && error =
\"Error 06\"\n";
int res = CalcClass.Add(-2850800078, 3000000000);
string error = CalcClass.lastError;
richTextBox1.Text += "Код ошибки: " + error + "\n";
richTextBox1.Text += "Получившийся результат: " + "res = " +
res.ToString() + " error = " + error.ToString() + "\n";
if (res == 0 && error == "Error 06")
{
richTextBox1.Text += "Тест пройден\n\n";
}
else
{
richTextBox1.Text += "Тест не пройден\n\n";
}
}
catch (Exception ex)
{
richTextBox1.Text += "Перехвачено исключение: " +
ex.ToString() + "\nТест не пройден.\n";
}

try
{
richTextBox1.Text += "Test Case 3\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
{
richTextBox1.Text += "Тест не пройден\n\n";
}
}
catch (Exception ex)
{
richTextBox1.Text += "Перехвачено исключение: " +
ex.ToString() + "\nТест не пройден.\n";
}

try
{
richTextBox1.Text += "Test Case 4 - проверяем вычитание на корректных данных";
richTextBox1.Text += "Входные данные: a= 78508, b = -304\n";
richTextBox1.Text += "Ожидаемый результат: res = 78812 &&
error = \"\"" + "\n";
int res = CalcClass.Sub(78508, -304);
string error = CalcClass.lastError;
richTextBox1.Text += "Код ошибки: " + error + "\n";
richTextBox1.Text += "Получившийся результат: " + "res = " +
res.ToString() + " error = " + error.ToString() + "\n";
if (res == 78508 && error == "")
{
richTextBox1.Text += "Тест пройден\n\n";
}
else
{
richTextBox1.Text += "Тест не пройден\n\n";
}
}
catch (Exception ex)
{
richTextBox1.Text += "Перехвачено исключение: " +
ex.ToString() + "\nТест не пройден.\n";
}

try
{
richTextBox1.Text += "Test Case 5 - проверяем произведение на корректных данных";
richTextBox1.Text += "Входные данные: a= 78508, b = -304\n";
richTextBox1.Text += "Ожидаемый результат: res = 23866432 &&
error = \"\"" + "\n";
int res = CalcClass.Mult(78508, -304);
string error = CalcClass.lastError;
richTextBox1.Text += "Код ошибки: " + error + "\n";
richTextBox1.Text += "Получившийся результат: " + "res = " +
res.ToString() + " error = " + error.ToString() + "\n";
if (res == 23866432 && error == "")
{
richTextBox1.Text += "Тест пройден\n\n";
}
else
{
richTextBox1.Text += "Тест не пройден\n\n";
}
}
catch (Exception ex)
{
richTextBox1.Text += "Перехвачено исключение: " +
ex.ToString() + "\nТест не пройден.\n";
}
8.2.
Результат
Test Case 2
Входные данные: a= -2850800078, b = 3000000000
Ожидаемый результат: res = 0 && error = "Error 06"
Код ошибки: Error 06
Получившийся результат: res = 0 error = Error 06
Тест пройден

Test Case 3
(повторный тест) Входные данные: a= 78508, b = -304
Ожидаемый результат: res = 78204 && error = ""
Код ошибки: Error 06
Получившийся результат: res = 78204 error = Error 06
Тест не пройден

Test Case 4 — проверяем вычитание на корректных данных
Входные данные: a= 78508, b = -304
Ожидаемый результат: res = 78812 && error = ""
Код ошибки: Error 06
Получившийся результат: res = 78812 error = Error 06
Тест не пройден

Test Case 5 — проверяем произведение на корректных данных
Входные данные: a= 78508, b = -304
Ожидаемый результат: res = 23866432 && error = ""
Код ошибки: Error 06
Получившийся результат: res = -23866432 error = Error 06
Тест не пройден
Мы видим, что ни один из методов не очищает поле _lastError. Это может быть либо ошибкой проектирования, либо неправильной реализацией свойства lastError. Можно либо отправить на доработку все методы и функциональные требования, указав в них, что методы должны перед началом работы очищать свойство lastError, либо доработать свойство следующим образом:
public static string lastError
{
get
{
string temp = _lastError;
_lastError = "";
return temp;
}
}
Таким образом, после любого чтения этой переменной, её значение снова будет равняться пустой строке.
Замечание. Несмотря на кажущуюся "притянутость" этого примера, он очень характерен. Можно вернуться к предыдущим лабораторным работам и удалить строки в тестовом модуле, очищающие значение _lastError. При запуске тестов третий тест вместо перехвата исключения сообщит, что метод закончил работу с кодом ошибки 3. Причина как раз в том, что после выполнения теста 2 значение _lastError не было очищено. Это еще раз свидетельствует о том, что тестам надо созавать корректное тестовое окружение. Дальше будет приведен еще один пример неправильного построения тестового окружения.
Рассмотренный пример является довольно простым, и ошибка будет легко выявлена при тестировании. В четвертом семинаре, при написании тестового драйвера для метода RunEstimate(), мы подключали сборку My.dll:
System.IO.BinaryReader reader = new System.IO.BinaryReader
(new System.IO.FileStream(Application.StartupPath +
+ "\\My.dll", System.IO.FileMode.Open,
System.IO.FileAccess.Read));
Byte[] asmBytes = new Byte[reader.BaseStream.Length];
reader.Read(asmBytes, 0, (Int32) reader.BaseStream.Length);
reader.Close();
reader = null;
System.Reflection.Assembly assm =
System.Reflection.Assembly.Load(asmBytes);
Может показаться, что мы выполняем лишние действия, и вместо всех этих строк кода легче применить методSystem.Reflection.Assembly.LoadFile, который сразу подключит необходимую сборку по пути библиотеки.
Замечание. В Framework 2.0 метод LoadFile() объявлен как устаревший.
Дальше мы можем проводить сколько угодно тестов методов класса AnalaizerClass.
Но если нам понадобится поменять заглушку класса CalcClass (например, на ту, которая выводит на экран какие-то дополнительные сведения), то мы получим ошибку access denied, т.к. сборка уже загружена и используется процессом, и перекомпилировать её не получится.
Это другая проблема регрессионного тестирования. Здесь уже ошибка не в тестируемой программе, а в самом построении тестов и тестового окружения. Как было сказано во вступлении, нужно либо для каждого теста заново проводить инициализацию тестового окружения, либо объединять тесты в группы с общей инициализацией, но следя за тем, чтобы тесты не запускались по отдельности.
8.3. Задание
Написать тесты для методов работы с памятью калькулятора, используя списки воспроизведения и расположив тесты в таком порядке, чтобы как можно реже проводить подготовку тестового окружения. Обосновать свой выбор.

Vladimir.Burdak Vladimir.Burdak
3500 р