Простейший пример модульного (Unit) тестирования
В качестве примера для наглядности и лучшего понимания возьмём простейший класс.
C#
| 1 2 3 4 5 6 7 8 9 10 11 | public class MyClass { public int Method1(int a, int b) { return a * b; } public void Method2() { throw new Exception(); } } |
Данный класс содержит только два метода.
Первый из них имитирует работу некоторого алгоритма. Для примера взято простое умножение двух принимаемых аргументов и возврат результата.
Второй имитирует ошибку, заложенную в программе в процессе написания.
Создадим модульный тест для этого класса.
Для этого добавим в имеющееся решение проект модульного теста, в котором, в свою очередь добавим ссылку на сборку, которая содержит тестируемый класс.
Пусть первоначально тест будет включать также два метода. Тестовые случаи также будут предельно просты. Создаётся экземпляр тестируемого класса и вызывается его соответствующий метод.
C#
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | using System; using Microsoft.VisualStudio.TestTools.UnitTesting; using MyWindowsFormsApplication; namespace MyUnitTestProject { [TestClass] public class UnitTest1 { [TestMethod] public void TestMethod1() { MyClass myClass = new MyClass(); myClass.Method1(3, 4); } [TestMethod] public void TestMethod2() { MyClass myClass = new MyClass(); myClass.Method2(); } } } |
Запустим тест на выполнение. Для этого в главном меню Visual Studio выберем «Тест» — «Выполнить» — «Все тесты».
На экране появится панель «Обозреватель тестов», в которой спустя некоторое время будут отображены результаты тестирования.
В данном случае тестирование завершилось неудачно, так как один из методов тестируемого класса содержал ошибку (имитируемую).
|
|
|
Если изменить этот метод, устранив ошибку. Например, так:
C#
| 1 2 3 4 | public void Method2() { return; } |
Тестирование будет завершено успешно.
Важно отметить, что при повторном тестировании вовсе не обязательно запускать все тесты. В целях экономии времени можно выбрать пункт «Неудачные тесты» вместо пункта «Все тесты». Тогда будут выполнены только тесты, которые завершились с ошибкой.
Усложним задачу.
Добавим в наш модульный тест третий тестовый метод, в котором будет выполняться проверка правильности значения возвращаемого первым методом тестируемого класса. Напомним, что этот метод возвращает результат умножение двух аргументов.
C#
| 1 2 3 4 5 6 7 8 9 | [TestMethod] public void TestMethod3() { MyClass myClass = new MyClass(); if (myClass.Method1(3, 4) != 12) { throw new Exception(); }; } |
Первоначально все тесты проходят успешно.
Теперь внесём в тестируемый метод ошибку. Причём это будет ошибка, которая сама по себе не вызывает исключения. Например:
C#
| 1 2 3 4 | public int Method1(int a, int b) { return a * b * 10; } |
Таким образом, при тех же самых исходных данных результат будет уже не 12, а 120.
|
|
|
В результате повторное тестирование выдаст ошибку.
Как уже говорилось в самом начале, всё это лишь самые простейшие примеры.
На самом деле при помощи модульных тестов можно выполнять тестирование практически любой сложности в соответствии с решаемой задачей.
Документация по тестированию
Цель работы
9.1.1 Овладение навыками документирования результатов тестирования.
Приборы и оборудование
9.2.1 Методические указания по выполнению практического занятия.
Порядок выполнения работы
9.3.1 Изучите теоретические сведения.
9.3.2 Задокументировать все результаты тестирования. Для выполнения работы использовать тестовые случаи из предыдущих работ.
9.3.3 Оформите отчет и сдайте его преподавателю.
Контрольные вопросы
9.4.1 Какова структура итогового отчета о результатах тестирования?
9.4.2 Для чего используется графическое представление результатов тестирования в итоговом отчете?
9.4.3 Тестовые артефакты?
Приложение О
ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ
Каждый дефект, обнаруженный в процессе тестирования, должен быть задокументирован и отслежен. При обнаружении нового дефекта его заносят в базу дефектов. При занесении нового дефекта рекомендуется указывать, как минимум, следующую информацию:
|
|
|
1) Наименование подсистемы, в которой обнаружен дефект.
2) Версия продукта (номер build), на котором дефект был найден.
3) Описание дефекта.
4) Описание процедуры (шагов, необходимых для воспроизведения дефекта).
5) Номер теста, на котором дефект был обнаружен.
6) Уровень дефекта, то есть степень его серьезности с точки зрения критериев качества продукта или заказчика.
Тестовый отчет обновляется после каждого цикла тестирования и должен содержать следующую информацию для каждого цикла:
1) Перечень функциональности в соответствии с пунктами требований, запланированный для тестирования на данном цикле, и реальные данные по нему.
2) Количество выполненных тестов – запланированное и реально исполненное.
3) Время, затраченное на тестирование каждой функции, и общее время тестирования.
4) Количество найденных дефектов.
5) Количество повторно открытых дефектов.
6) Отклонения от запланированной последовательности
ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ
Введение
Существующие на сегодняшний день методы тестирования ПО не позволяют однозначно и полностью выявить все дефекты и установить корректность функционирования анализируемой программы, поэтому всесуществующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого ПО.
|
|
|
Такой процесс формальной проверки, или верификации, может доказать, что дефекты отсутствуют с точки зрения используемого метода. (То есть нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапах жизненного цикла ПО).
Существует множество подходов к решению задачи тестирования и верификации ПО, но эффективноетестирование сложных программных продуктов – это процесс в высшей степени творческий, не сводящийся кследованию строгим и чётким процедурам или созданию таковых.
С точки зрения ISO 9126, качество программного обеспечения можно определить как совокупнуюхарактеристику исследуемого ПО с учётом следующих составляющих:
· Надёжность
· Сопровождаемость
· Практичность
· Эффективность
· Мобильность
· Функциональность
Более полный список атрибутов и критериев можно найти в стандарте ISO 9126 Международной организации по стандартизации. Состав и содержание документации, сопутствующей процессу тестирования, определяется стандартом IEEE 829 – 1998 Standard for Software Test Documentation.
Дата добавления: 2021-02-10; просмотров: 173; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!