В каждом тестовом задании может быть несколько вариантов ответа. После проведения теста, студенты могут попробовать обосновать свои неверные ответы.
Тестовое окружение может использоваться для:
Ответ: 1, 2, 4, 5
Тестовое окружение для программного кода на структурных языках программирования состоит из:
Ответ: 1, 3
Модульное тестирование проводится для того, чтобы:
Ответ: 3
Модуль – это (с точки зрения наших семинарских занятий):
Ответ: 2
Какие основные задачи решаются в ходе модульного тестирования?
Ответ: 1, 2, 4, 6
Студенты приносят заполненные отчеты об ошибках для тех модулей, которые они тестировали. Преподаватель оценивает их тест-планы, тестовые модули и смотрит, удалось ли студентам найти все допущенные в методах ошибки.
Замечание. Подробнее о модульном тестировании можно почитать по адресу http://msdn2.microsoft.com/en-us/library/ms182515(VS.80).aspx
До сих пор мы выполняли часть работы вручную. Но при написании тестов тестировщик также может ошибиться, из-за чего в программе могут остаться различные ошибки. В случае, если программисты ведут разработку по методике экстремального программирования (XP), следуя практике написания тестов перед кодом (
К моменту написания тестов мы уже имеем полностью готовый код. Можем приступить к созданию тестов.
Для создания теста нажимаем правой кнопкой мыши на методе Add() и выбирая пункт меню Create Unit Tests... (рис. 12.1). Появится диалоговое окно, позволяющее создать тесты в другом проекте (рис. 12.2). По умолчанию, создаваемый проект — новый проект на Visual Basic, но также доступны тестовые проекты на C# и C ++. Выбираем Visual C# и нажимаем кнопку OK, перед тем введя имя проекта BaseCalculator.Test.

(рис 12.2) Пункт контекстного меню " Create Unit Tests ..." в методе Add()(рис 12.1) Диалоговое окно "Create Unit tests"Созданный тестовый проект содержит четыре файла, связанных с тестированием.
| Имя файла | Примечание |
|---|---|
| AuthoringTest.txt | Примечания о создании тестов, включающие инструкции по добавлению дополнительных тестов к проекту |
| CalcClassTest.cs | Включает в себя сгенерированный тест для тестирования метода Add () наряду с методами для тестовой инициализации и очистки |
| ManualTest1.mht | Шаблон, который заполняется инструкциями при |
| UnitTest1.cs | Пустая структура unit test класса, куда помещаются дополнительные тесты |
Так как ручное тестирование мы уже провели, и файл для тестов у нас уже есть, то мы удалим ManualTest1.mht и UnitTest1.cs.
В раздел References при генерации тестового проекта добавляется ссылки на Microsoft.VisualStudio.QualityTools.UnitTestFramework и проект BaseCalculator, который и будет тестироваться. Первое – сборка, которую использует "движок" модульного тестирования при выполнении тестов. Второе — это ссылка на ту сборку, которую мы тестируем.
По умолчанию, сгенерированный тест-метод – это шаблон со следующей реализацией:
/// <summary>
///A test for Add (long, long)
///</summary>
[DeploymentItem("BaseCalculator.exe")]
[TestMethod()]
public void AddTest()
{
long a = 0; // TODO: Initialize to an appropriate value
long b = 0; // TODO: Initialize to an appropriate value
int expected = 0;
int actual;
actual = BaseCalculator.Test.
BaseCalculator_CalcClassAccessor.Add(a, b);
Assert.AreEqual(expected, actual,
"BaseCalculator.CalcClass.Add did not return
the expected value.");
Assert.Inconclusive("Verify the correctness of this test method.");
}
Замечание. Сгенерированный код теста будет сильно зависеть от типа и сигнатуры того метода, который планируется тестировать. Например, мастер сгенерирует код, основанный на технологии reflection ("отражение"), для тестирования private функций. В нашем конкретном случае это не потребовалось, так как метод Add() объявлен как public().
Прежде всего, отметим, что сгенерированный код помечен атрибутом TestMethod типа TestMethodAttribute, а сам класс помечен атрибутом TestClassAttribute, которые объявлены в Microsoft.VisualStudio.QualityTools.UnitTesting.Framework. При помощи технологии Reflection движок модульного тестирования находит все тестовые классы в проекте, помеченные соответствующим атрибутом, а внутри все необходимые для тестирования методы.
Замечание. Об атрибутах можно почитать подробнее по адресу http://msdn2.microsoft.com/en-us/library/system.attribute(VS.80).aspx
В начале теста объявляется значение всех необходимых переменных, а также ожидаемое выходное значение. Затем происходит вызов нужного метода, которому передаются необходимые параметры. В нашем случае это
actual = BaseCalculator.Test.BaseCalculator_CalcClassAccessor.Add(a, b);
Затем идет вызов двух методов класса Assert. Прежде всего рассмотрим второй метод.
Assert.Inconclusive("Verify the correctness of this test method.");
Наличие этого метода в тесте говорит о том, что реализация теста еще не закончена. Сделаем реализацию нашего метода:
/// <summary>
///A test for Add (long, long)
///</summary>
[DeploymentItem("BaseCalculator.exe")]
[TestMethod()]
public void AddTest()
{
long a = 150;
long b = 350;
int expected = 500;
int actual;
actual = BaseCalculator.
Test.BaseCalculator_CalcClassAccessor.Add(a, b);
Assert.AreEqual(expected, actual,
"BaseCalculator.CalcClass.
Add did not return the expected value.");
}
Чтобы запустить все тесты в рамках проекта, необходимо просто запустить тестовый проект. Один из возможных способов сделать это — кликнуть правой кнопкой мыши на проекте BaseCalculator.Test в Solution explorer и выбрать Set as StartUp Project. Затем используем пункты меню Debug->Start (F5) или Debug->Start Without Debugging (Ctrl+F5), чтобы начать запуск тестов.
В окне Test Results будет показан список со всеми тестами проекта. В момент начала выполнения теста в нашем проекте содержалось два теста: один полностью реализованный тест AddTest, второй – неоконченный AddTest1. В момент запуска оба теста будут в состоянии "неоконченный" ( Pending ), но как только тесты будет выполнены, появятся результаты выполнения Passed и Inconcluiseve, которые мы и ожидали (Рис. 12.3).
(рис 12.3) Окно Test Results после выполнения всех тестовЗамечание. Рис. 12.3 показывает окно Test Results. На этом скриншоте в дополнение к колонкам по умолчанию изображена колонка Error Message. Колонки могут быть добавлены или удалены правым щелчком мыши по меню на заголовках колонки и выборе пункта меню Add/Remove Columns... .
Чтобы посмотреть дополнительные детали о тесте, мы можем дважды щелкнуть на нем в окне Test Results и открыть окно AddTest[Result] (рис. 12.4). В нем можно узнать информацию о скорости выполнения теста, его результате, возникшей ошибке и прочее.
(рис 12.4) Окно детального описания теста AddTest [Results]Кроме того, мы можем кликнуть правой кнопкой мыши на отдельных тестах и выбирать пункт меню Open Test, чтобы переместиться на код теста.
На прошлом семинаре мы обнаружили, что метод RunEstimate() класса AnalaizerClass не достаточно хорошо проверяет объекты, с которыми он работает. Если инициализировать список opz значением {2,2,+,+}, то выполнение метода RunEstimate() приводит к генерации исключения. Действительно, реализуем тест:
/// <summary>
///A test for RunEstimate ()
///</summary>
[DeploymentItem("BaseCalculator.exe")]
[TestMethod()]
public void RunEstimateTest()
{
string expected = null;
string actual;
// Подготовка тестового окружения
BaseCalculator.Test.BaseCalculator_CalcClassAccessor._lastError = "";
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz =
new System.Collections.ArrayList();
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz.Add("2");
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz.Add("2");
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz.Add("+");
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz.Add("+");
actual = BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.RunEstimate();
Assert.AreEqual(expected, actual,
"BaseCalculator.AnalaizerClass.RunEstimate did not return the expected value.");
}
Замечание. Для работы этого теста необходимо создать начальное тестовое окружение, при этом значение _lastError необходимо очистить, так как оно будет "испорчено" тестом AddTest1(). Подробнее о зависимости тестов от порядка выполнения и тестового окружения мы поговорим на девятом семинаре.
Несмотря на то, что явных блоков try-catch не стоит, сгенерированное исключение не приведет к прекращению работы тестов, а будет корректно обработано. В этом можно убедиться, загляну в окно на RunEstimateTest[Result] (рис. 12.5).
(рис 12.5) Результат работы RunEstimateTestПредположим теперь, что при неверных входных параметрах метод RunEstimate() действительно должен генерировать исключение, которое будет перехватываться в другом месте. Создадим еще один тест:
/// <summary>
///A test for RunEstimate ()
///</summary>
[DeploymentItem("BaseCalculator.exe")]
[TestMethod()]
[ExpectedException(typeof(ArgumentOutOfRangeException),
"Была обработана неверная синтаксическая конструкция")]
public void RunEstimateTest1()
{
BaseCalculator.Test.BaseCalculator_CalcClassAccessor._lastError = "";
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz =
new System.Collections.ArrayList();
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz.Add("2");
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz.Add("2");
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz.Add("+");
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz.Add("+");
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.RunEstimate();
}
Отметим, что, опять же, нет блока try-catch с явным тестом на ArgumentOutOfRangeException. Вместо этого тест включает дополнительный атрибут, ExpectedException, который принимает тип параметра, и произвольное сообщение об ошибке, которое будет показано, если исключение не было брошено. Когда тесты выполняются, среда будет явно следить за тем, чтобы исключение ArgumentException было сгенерировано, и если метод не будет генерировать такое исключение, то тест будет провален.
Будут выданы исходные файлы модулей для тестирования методом "белого ящика" средствами MVSTE, пример тестового драйвера.
Составить тест-план и провести модульное тестирование (средствами MVSTE) следующих методов:
public static int Mod(long a, long b) public static bool CheckCurrency()
public static int ABS(long a) public static string Format()
public static int IABS(long a) public static string Format()
public static int Sub(long a, long b) public static System.Collections.ArrayList CreateStack()
public static int Mult(long a, long b) public static System.Collections.ArrayList CreateStack()
public static int Div(long a, long b) public static bool CheckCurrency()
В каждом тестовом задании может быть несколько вариантов ответа. После проведения теста, студенты могут попробовать обосновать свои неверные ответы.
Тестовое окружение может использоваться для:
Ответ: 1, 2, 4, 5
Тестовое окружение для программного кода на структурных языках программирования состоит из:
Ответ: 1, 3
Модульное тестирование проводится для того, чтобы:
Ответ: 3
Модуль – это (с точки зрения наших семинарских занятий):
Ответ: 2
Какие основные задачи решаются в ходе модульного тестирования?
Ответ: 1, 2, 4, 6
Студенты приносят заполненные отчеты об ошибках для тех модулей, которые они тестировали. Преподаватель оценивает их тест-планы, тестовые модули и смотрит, удалось ли студентам найти все допущенные в методах ошибки.
Замечание. Подробнее о модульном тестировании можно почитать по адресу http://msdn2.microsoft.com/en-us/library/ms182515(VS.80).aspx
До сих пор мы выполняли часть работы вручную. Но при написании тестов тестировщик также может ошибиться, из-за чего в программе могут остаться различные ошибки. В случае, если программисты ведут разработку по методике экстремального программирования (XP), следуя практике написания тестов перед кодом (
К моменту написания тестов мы уже имеем полностью готовый код. Можем приступить к созданию тестов.
Для создания теста нажимаем правой кнопкой мыши на методе Add() и выбирая пункт меню Create Unit Tests... (рис. 12.1). Появится диалоговое окно, позволяющее создать тесты в другом проекте (рис. 12.2). По умолчанию, создаваемый проект — новый проект на Visual Basic, но также доступны тестовые проекты на C# и C ++. Выбираем Visual C# и нажимаем кнопку OK, перед тем введя имя проекта BaseCalculator.Test.

(рис 12.2) Пункт контекстного меню " Create Unit Tests ..." в методе Add()(рис 12.1) Диалоговое окно "Create Unit tests"Созданный тестовый проект содержит четыре файла, связанных с тестированием.
| Имя файла | Примечание |
|---|---|
| AuthoringTest.txt | Примечания о создании тестов, включающие инструкции по добавлению дополнительных тестов к проекту |
| CalcClassTest.cs | Включает в себя сгенерированный тест для тестирования метода Add () наряду с методами для тестовой инициализации и очистки |
| ManualTest1.mht | Шаблон, который заполняется инструкциями при |
| UnitTest1.cs | Пустая структура unit test класса, куда помещаются дополнительные тесты |
Так как ручное тестирование мы уже провели, и файл для тестов у нас уже есть, то мы удалим ManualTest1.mht и UnitTest1.cs.
В раздел References при генерации тестового проекта добавляется ссылки на Microsoft.VisualStudio.QualityTools.UnitTestFramework и проект BaseCalculator, который и будет тестироваться. Первое – сборка, которую использует "движок" модульного тестирования при выполнении тестов. Второе — это ссылка на ту сборку, которую мы тестируем.
По умолчанию, сгенерированный тест-метод – это шаблон со следующей реализацией:
/// <summary>
///A test for Add (long, long)
///</summary>
[DeploymentItem("BaseCalculator.exe")]
[TestMethod()]
public void AddTest()
{
long a = 0; // TODO: Initialize to an appropriate value
long b = 0; // TODO: Initialize to an appropriate value
int expected = 0;
int actual;
actual = BaseCalculator.Test.
BaseCalculator_CalcClassAccessor.Add(a, b);
Assert.AreEqual(expected, actual,
"BaseCalculator.CalcClass.Add did not return
the expected value.");
Assert.Inconclusive("Verify the correctness of this test method.");
}
Замечание. Сгенерированный код теста будет сильно зависеть от типа и сигнатуры того метода, который планируется тестировать. Например, мастер сгенерирует код, основанный на технологии reflection ("отражение"), для тестирования private функций. В нашем конкретном случае это не потребовалось, так как метод Add() объявлен как public().
Прежде всего, отметим, что сгенерированный код помечен атрибутом TestMethod типа TestMethodAttribute, а сам класс помечен атрибутом TestClassAttribute, которые объявлены в Microsoft.VisualStudio.QualityTools.UnitTesting.Framework. При помощи технологии Reflection движок модульного тестирования находит все тестовые классы в проекте, помеченные соответствующим атрибутом, а внутри все необходимые для тестирования методы.
Замечание. Об атрибутах можно почитать подробнее по адресу http://msdn2.microsoft.com/en-us/library/system.attribute(VS.80).aspx
В начале теста объявляется значение всех необходимых переменных, а также ожидаемое выходное значение. Затем происходит вызов нужного метода, которому передаются необходимые параметры. В нашем случае это
actual = BaseCalculator.Test.BaseCalculator_CalcClassAccessor.Add(a, b);
Затем идет вызов двух методов класса Assert. Прежде всего рассмотрим второй метод.
Assert.Inconclusive("Verify the correctness of this test method.");
Наличие этого метода в тесте говорит о том, что реализация теста еще не закончена. Сделаем реализацию нашего метода:
/// <summary>
///A test for Add (long, long)
///</summary>
[DeploymentItem("BaseCalculator.exe")]
[TestMethod()]
public void AddTest()
{
long a = 150;
long b = 350;
int expected = 500;
int actual;
actual = BaseCalculator.
Test.BaseCalculator_CalcClassAccessor.Add(a, b);
Assert.AreEqual(expected, actual,
"BaseCalculator.CalcClass.
Add did not return the expected value.");
}
Чтобы запустить все тесты в рамках проекта, необходимо просто запустить тестовый проект. Один из возможных способов сделать это — кликнуть правой кнопкой мыши на проекте BaseCalculator.Test в Solution explorer и выбрать Set as StartUp Project. Затем используем пункты меню Debug->Start (F5) или Debug->Start Without Debugging (Ctrl+F5), чтобы начать запуск тестов.
В окне Test Results будет показан список со всеми тестами проекта. В момент начала выполнения теста в нашем проекте содержалось два теста: один полностью реализованный тест AddTest, второй – неоконченный AddTest1. В момент запуска оба теста будут в состоянии "неоконченный" ( Pending ), но как только тесты будет выполнены, появятся результаты выполнения Passed и Inconcluiseve, которые мы и ожидали (Рис. 12.3).
(рис 12.3) Окно Test Results после выполнения всех тестовЗамечание. Рис. 12.3 показывает окно Test Results. На этом скриншоте в дополнение к колонкам по умолчанию изображена колонка Error Message. Колонки могут быть добавлены или удалены правым щелчком мыши по меню на заголовках колонки и выборе пункта меню Add/Remove Columns... .
Чтобы посмотреть дополнительные детали о тесте, мы можем дважды щелкнуть на нем в окне Test Results и открыть окно AddTest[Result] (рис. 12.4). В нем можно узнать информацию о скорости выполнения теста, его результате, возникшей ошибке и прочее.
(рис 12.4) Окно детального описания теста AddTest [Results]Кроме того, мы можем кликнуть правой кнопкой мыши на отдельных тестах и выбирать пункт меню Open Test, чтобы переместиться на код теста.
На прошлом семинаре мы обнаружили, что метод RunEstimate() класса AnalaizerClass не достаточно хорошо проверяет объекты, с которыми он работает. Если инициализировать список opz значением {2,2,+,+}, то выполнение метода RunEstimate() приводит к генерации исключения. Действительно, реализуем тест:
/// <summary>
///A test for RunEstimate ()
///</summary>
[DeploymentItem("BaseCalculator.exe")]
[TestMethod()]
public void RunEstimateTest()
{
string expected = null;
string actual;
// Подготовка тестового окружения
BaseCalculator.Test.BaseCalculator_CalcClassAccessor._lastError = "";
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz =
new System.Collections.ArrayList();
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz.Add("2");
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz.Add("2");
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz.Add("+");
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz.Add("+");
actual = BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.RunEstimate();
Assert.AreEqual(expected, actual,
"BaseCalculator.AnalaizerClass.RunEstimate did not return the expected value.");
}
Замечание. Для работы этого теста необходимо создать начальное тестовое окружение, при этом значение _lastError необходимо очистить, так как оно будет "испорчено" тестом AddTest1(). Подробнее о зависимости тестов от порядка выполнения и тестового окружения мы поговорим на девятом семинаре.
Несмотря на то, что явных блоков try-catch не стоит, сгенерированное исключение не приведет к прекращению работы тестов, а будет корректно обработано. В этом можно убедиться, загляну в окно на RunEstimateTest[Result] (рис. 12.5).
(рис 12.5) Результат работы RunEstimateTestПредположим теперь, что при неверных входных параметрах метод RunEstimate() действительно должен генерировать исключение, которое будет перехватываться в другом месте. Создадим еще один тест:
/// <summary>
///A test for RunEstimate ()
///</summary>
[DeploymentItem("BaseCalculator.exe")]
[TestMethod()]
[ExpectedException(typeof(ArgumentOutOfRangeException),
"Была обработана неверная синтаксическая конструкция")]
public void RunEstimateTest1()
{
BaseCalculator.Test.BaseCalculator_CalcClassAccessor._lastError = "";
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz =
new System.Collections.ArrayList();
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz.Add("2");
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz.Add("2");
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz.Add("+");
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.opz.Add("+");
BaseCalculator.Test.BaseCalculator_AnalaizerClassAccessor.RunEstimate();
}
Отметим, что, опять же, нет блока try-catch с явным тестом на ArgumentOutOfRangeException. Вместо этого тест включает дополнительный атрибут, ExpectedException, который принимает тип параметра, и произвольное сообщение об ошибке, которое будет показано, если исключение не было брошено. Когда тесты выполняются, среда будет явно следить за тем, чтобы исключение ArgumentException было сгенерировано, и если метод не будет генерировать такое исключение, то тест будет провален.
Будут выданы исходные файлы модулей для тестирования методом "белого ящика" средствами MVSTE, пример тестового драйвера.
Составить тест-план и провести модульное тестирование (средствами MVSTE) следующих методов:
public static int Mod(long a, long b) public static bool CheckCurrency()
public static int ABS(long a) public static string Format()
public static int IABS(long a) public static string Format()
public static int Sub(long a, long b) public static System.Collections.ArrayList CreateStack()
public static int Mult(long a, long b) public static System.Collections.ArrayList CreateStack()
public static int Div(long a, long b) public static bool CheckCurrency()
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.