Методические указания по выполнению практических работ по мдк

86 
Если для выполнения тестов требуется сборка программных модулей тестового 
окружения и тестируемой системы в единый исполняемый код, то при изменении интерфейсов 
системы может возникнуть ситуация, когда невозможно не только выполнение тестов, а даже 
сборка окружения и системы. В этом случае также необходимо провести анализ изменений, 
внесенных в систему, и модифицировать в соответствии с ними тестовое окружение. 
Иногда повторное выполнение всех тестов невозможно. Это может быть связано с 
большим временем выполнения всех тестов и ограниченным временем, отведенным на 
процесс тестирования. В этом случае часто применяется практика выборочного тестирования 
отдельных частей системы, затронутых изменениями. Полное тестирование при таком 
подходе проводится только после накопления достаточно большого количества изменений 
или на ключевых стадиях проекта. 
Процесс, включающий в себя повторное выполнение всех тестов, называют 
регрессионным тестированием. Регрессионное тестирование включает в себя следующие 
стадии: 
1.
Анализ изменений в системе 
2.
Выбор тестовых примеров для проверки системы 
3.
Выполнение тестовых примеров 
4.
Анализ результатов выполнения 
5.
Модификация тестового окружения, тестовых примеров или уведомление 
разработчиков о дефекте системы. 
Таким образом можно определить следующие основные задачи повторяемости 
тестирования при внесении изменений. 

Обеспечение возможности полного выполнения всех тестов, проверяющих 
функциональность системы или проведение анализа, позволяющего выявить тесты, 
которые должны быть повторно выполнены для тестирования изменившейся 
функциональности. 

Разработка тестовых примеров и тестового окружения с использованием методик, 
облегчающих модификацию при изменениях в тестируемой системе. 

Разработка тестовых примеров, структура которых полностью исключает их 
взаимное влияние по остаточным данным. 
Целью повторяемости тестирования является постоянное обеспечение тестировщиков и 
разработчиков актуальной информацией о текущем состоянии системы и корректности 
изменений, внесенных в ходе разработки системы. 
Предусловия для выполнения теста, настройка тестового окружения, оптимизация 
последовательностей тестовых примеров 
Как уже было сказано ранее, входные данные в каждом тестовом примере явно задают 
начальное состояние тестируемой системы и режимы ее работы при выполнении тестового 
сценария. 
Однако неявное влияние на выполнение теста оказывает и состояние тестового 
окружения. Под состоянием здесь понимается набор параметров, изменение любого из 
которых может повлиять либо на результат выполнения тестового примера, либо на 
возможность его корректной работы и завершения. 
Например, для выполнения тестового примера тестируемой системе может 
потребоваться значительный объем дисковой или оперативной памяти. Если перед 
выполнением теста тестовое окружение выделит эту память под свои нужды, выполнение 
теста окажется невозможным. Та же самая ситуация может возникнуть и в случае, если 
окружение не освободит память после выполнения предыдущего тестового примера. 
Эта информация обычно отсутствует в тест-планах, однако требуемое для выполнения 
тестов состояние тестового окружения необходимо учитывать при разработке тестовых 
примеров. 
Хорошей практикой является оформление проверок на допустимость состояния 
тестового окружения в виде предусловий для выполнения теста. Это позволяет 

87 
диагностировать ситуации, возникающие при выборочном тестировании и приводящие к 
отказам тестового окружения. 
На практике часто возникает ситуация в которой друг за другом следует несколько 
десятков тестовых примеров, а при регрессионном тестировании требуется выполнить, 
например, тестовые примеры с номерами от 25 по 40. Первый тестовый пример при этом 
инициализирует систему, а остальные работают с уже стартовавшей системой. Если просто 
выполнять тестовые примеры 25-40, то их выполнение окажется невозможным – они не 
инициализируют систему. Разумным выходом из этой ситуации является выполнение 
тестовых примеров 1, 25-40. 
Зависимость между тестовыми примерами, настройки по умолчанию для тестовых 
примеров и их групп 
Для облегчения проведения регрессионного тестирования (и тестирования вообще) 
тестовые примеры часто разбивают на группы. Каждая группа содержит набор тестовых 
примеров, проверяющих отдельную замкнутую часть функциональности тестируемой 
системы. При отборе тестовых примеров для частичного регрессионного тестирования их 
можно отбирать сразу группами. 
Разбиение тестовых примеров на группы удобно и с точки зрения установки начального 
состояния тестового окружения для выполнения тестов – так, перед выполнением группы 
тестов можно инициализировать значения переменных или состояние системы, необходимое 
для выполнения всей группы. Например, если система работает в двух режимах – нормальном 
и сервисном, то перед выполнением группы тестов для нормального режима работы системы 
нужно устанавливать нормальный режим, а перед выполнением тестов для сервисного режима 
– сервисный. Такие установки называются настройками группы тестов по умолчанию (group 
defaults, test group defaults). 
Перед выполнением каждого тестового примера может потребоваться установка одних 
и тех же переменных в одни и те же значения. Для того, чтобы не дублировать эти установки 
в описании каждого тестового примера, в тест-плане можно определить настройки по 
умолчанию для каждого теста (test case defaults). 
Как видно из предыдущего раздела, для облегчения проведения выборочного 
регрессионного тестирования каждый тестовый пример должен быть полностью автономным 
– ход его выполнения и тем более, результат не должны зависеть от предыдущих тестовых 
примеров. Тем самым, при выборочном тестировании результат тестирования не зависит от 
выбранного набора тестовых примеров (тестового набора). Однако, на практике создание 
автономных тестов зачастую невозможно по различным причинам (как правило – из-за 
длительного времени выполнения таких тестов). 
В случае, когда в наборе тестовых примеров тесты не являются автономными, говорят о 
тестовой зависимости. Тестовая зависимость бывает двух видов – предусмотренная 
структурой тестовых примеров и паразитная. 
Пример предусмотренной тестовой зависимости был рассмотрен в предыдущем разделе 
– корректность выполнения тестов определялась порядком их выполнения. Такая тестовая 
зависимость требует документирования и сопровождения, как и сами описания тестовых 
примеров. Существует два вида документирования тестовых зависимостей: 

явное определение допустимого порядка выполнения тестовых примеров. Такой 
способ удобен при сравнительно небольшом общем количестве тестовых примеров, 
либо, при разбиении на группы – при небольшом размере групп тестовых примеров; 

определение допустимого порядка выполнения тестовых примеров при помощи 
предусловий. При таком способе корректность порядка выполнения тестовых 
примеров определяется при помощи проверки того, что либо тестируемая система, 
либо тестовое окружение находятся в необходимом состоянии для выполнения 
тестового примера. 
Паразитные тестовые зависимости обычно вызваны некорректным составлением тест-
плана. Проявляются они, как и предусмотренные зависимости, в том, что один (или более) 
тестовых примеров корректно работает только в том случае, если до него были выполнены 

88 
другие тестовые примеры. Причем такая зависимость не является предусмотренной 
тестировщиком. Природа паразитной тестовой зависимости схожа с природой ошибок 
использования неинициализированных или остаточных данных в динамической памяти при 
программировании. 
На примере "Калькулятора" 
Рассмотрим повторяемость тестирования на примере нашего "Калькулятора". 
Рассмотрим свойство 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 

89 
{ 
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"; 
} 
Результат: 
Test Case 1 
Входные данные: a= 78508, b = -304 

90 
Ожидаемый результат: 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"; 

91 
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); 

92 
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"; 
} 
Результат 
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; 

93 
_lastError = ""; 
return temp; 
} 
} 
Таким образом, после любого чтения этой переменной, её значение снова будет 
равняться пустой строке. 
Замечание. Несмотря на кажущуюся "притянутость" этого примера, он очень характерен. 
Можно вернуться к "Тестовые примеры. Классы эквивалентности. Ручное тестирование в 
MVSTE" и удалить строки в тестовом модуле, очищающие значение _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, 
т.к. сборка уже загружена и используется процессом, и перекомпилировать её не получится. 
Это другая проблема регрессионного тестирования. Здесь уже ошибка не в тестируемой 
программе, а в самом построении тестов и тестового окружения. Как было сказано во 
вступлении, нужно либо для каждого теста заново проводить инициализацию тестового 
окружения, либо объединять тесты в группы с общей инициализацией, но следя за тем, чтобы 
тесты не запускались по отдельности. 
Упорядоченные тесты (ordered tests) в MVSTE 
Замечание. 
Подробнее 
об 
упорядоченных 
тестах 
можно 
почитать 
по 
адресу http://msdn2.microsoft.com/en-us/library/ms182629.aspx 
Упорядоченный тест содержит в себе другие тесты и предназначается для того, чтобы 
запускать их в указанном порядке. Упорядоченный тест появляется как отдельный тест в 
окне Test View, а результаты его выполнения появляются одной строкой в окне Test Results. 
Замечание. Упорядоченный тест может содержать тесты любого типа кроме 
нагрузочных тестов. Ещё одной особенностью упорядоченного теста является то, что, если мы 
запустим его удаленно или из командной строки, будет показано предупреждение о том, что, 
чтобы запустить тест, все ручные тесты, которые содержатся в нем, будут временно из него 
удалены. 
Замечание. Прежде чем Вы начнете создавать упорядоченные тесты, у Вас должны быть 
в наличии другие тесты, которые можно будет включить в упорядоченный тест. 

94 
Рассмотрим сначала создание упорядоченного теста. 
Для начала откроем BaseCalculator, с которым мы работали на "Тестовые примеры. 
Классы эквивалентности. Ручное тестирование в MVSTE" и "Тестирование программного 
кода (покрытия)" . Он уже содержит тесты. 
Добавим в тестовый проект упорядоченный тест. Для этого в меню Test выберем New 
Test. В появившемся диалоговом окне Add New Test выбираем Ordered Test. В поле Test 
Name введем название теста, например, OrderedTest.orderedtest, а в пункте Add to Test 
Project выберем наш тестовый проект BaseCalculator.Test. Для добавления теста в проект 
нажимаем OK.
Рисунок 43 
В Solution 
Explorer добавится файл OrderedTest.orderedtest и 
откроется 
окно 
редактирования упорядоченного теста OrderedTest.orderedtest. Мы будем использовать это 
окно, чтобы выбирать и включать тесты в наш упорядоченный тест. 
Рисунок 44 
Рассмотрим подробнее работу с окном редактирования нашего упорядоченного 
теста OrderedTest.orderedtest. 
В ниспадающем меню Select Test List to View можно выбрать список тестов: Lists of 
Tests, Tests Not in a List, All Loaded Tests или определенный тестовый список. Выберем All 
Loaded Tests. В Available tests отобразятся все созданные нами ранее тесты. 
Чтобы добавить тесты в упорядоченный тест, нужно в Available tests выделить те тесты, 
которые вы хотите добавить (например, используя SHIFT+click и CTRL+click ), и нажать на 
стрелку вправо
. Тесты добавлены в упорядоченный тест. 
Замечание. Можно добавлять одни и те же тесты многократно к одному и тому же 
упорядоченному тесту. 

95 
Чтобы удалить тест из упорядоченного теста, нужно в Selected tests выделить те тесты, 
которые вы хотите удалить (например, используя SHIFT+click и CTRL+click ), и нажать на 
стрелку влево
. Тесты удалены из упорядоченного теста. 
Чтобы изменить порядок тестов в упорядоченном тесте, нужно в Selected tests выделить 
те 
тесты, 
порядок 
которых 
вы 
хотите 
изменить 
(например, 
используя SHIFT+click и CTRL+click ), и нажать на стрелку вверх
или вниз
. Порядок 
тестов в упорядоченном тесте будет изменен. 
Рисунок 45 
Замечание. Выставленный флаг Continue after failure указывает на то, что 
упорядоченный тест продолжит работать независимо от того, закончатся ли один или 
несколько входящих в его состав тестов неудачей. Если флаг Continue after failure не будет 
выставлен, то упорядоченный тест прекратит свою работу при первом же возникновении 
неудачного теста 
Упорядоченный тест готов для запуска. Следующий этап – запуск теста тестировщиком. 
В окне Test View нажмем правой кнопкой мыши по созданному нами упорядоченному 
тесту ( OrderedTest ) и выберем Run Selection (или нажмем в окне Test View на кнопку ). 
Откроется окно Test Results, в котором после выполнения упорядоченного теста 
отобразятся результаты его выполнения Passed или Failed
Рисунок 46 
Чтобы увидеть результаты выполнения каждого из тестов, входящих в упорядоченный 
тест, в окне Test Results нужно щелкнуть два раза на строке для упорядоченного теста. Эти 
результаты появятся в окне OrderedTest [Results]. 

96 
Рисунок 47 
Чтобы увидеть детальные результаты отдельных тестов, нужно щелкнуть два раза на них 
в окне OrderedTest [Results]. 
Замечание. Если бы перед запуском теста не был выставлен флаг Continue after failure, 
то упорядоченный тест прекратил бы свою работу при первом же возникновении неудачного 
теста.
Рисунок 48 
Замечание. Результаты выполнения тестов можно экспортировать в отдельный файл. 
Для этого в окне Test Result надо выбрать Export Test Run Results и указать имя и 
местоположение файла. 
Программа 
Будут выданы исходные тексты программы BaseCalculatorNew для тестирования 
методом "белого ящика" средствами MVSTE и пример тестового драйвера. 
Написать тесты для методов работы с памятью калькулятора, используя упорядоченные 
тесты (ordered Tests) и расположив тесты в таком порядке, чтобы как можно реже проводить 
подготовку тестового окружения. Обосновать свой выбор. 

жүктеу/скачать 2,59 Mb.

Достарыңызбен бөлісу: