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

Содержание

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

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

Модульное

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

Тестирование JavaScript от А до Я (Jest, React Testing Library, e2e, screenshot)

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

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

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

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

Unit тестирование в С#. Как создать Unit тест в C#

Являясь по способу исполнения структурным тестированием или тестированием «белого ящика», модульное тестирование характеризуется степенью, в которой тесты выполняют или покрывают логику программы (исходный текст). Тесты, связанные со структурным тестированием, строятся по следующим принципам:

На основе анализа потока управления . В этом случае элементы, которые должны быть покрыты при прохождении тестов, определяются на основе структурных критериев тестирования С0, С1,С2. К ним относятся вершины, дуги, пути управляющего графа программы (УГП), условия, комбинации условий и т. п.
На основе анализа потока данных , когда элементы, которые должны быть покрыты, определяются при помощи потока данных , т. е. информационного графа программы.

Тестирование на основе потока управления. Особенности использования структурных критериев тестирования С0,С1,С2 были рассмотрены в лекции 3. К ним следует добавить критерий покрытия условий, заключающийся в покрытии всех логических (булевских) условий в программе. Критерии покрытия решений (ветвей — С1) и условий не заменяют друг друга, поэтому на практике используется комбинированный критерий покрытия условий/решений, совмещающий требования по покрытию и решений, и условий.

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

Тестирование на основе потока данных. Этот вид тестирования направлен на выявление ссылок на неинициализированные переменные и избыточные присваивания (аномалий потока данных ). Как основа для стратегии тестирования поток данных впервые был описан в [ 14 ] . Предложенная там стратегия требовала тестирования всех взаимосвязей, включающих в себя ссылку (использование) и определение переменной, на которую указывает ссылка (т. е. требуется покрытие дуг информационного графа программы). Недостаток стратегии в том, что она не включает критерий С1, и не гарантирует покрытия решений.

Стратегия требуемых пар [ 15 ] также тестирует упомянутые взаимосвязи. Использование переменной в предикате дублируется в соответствии с числом выходов решения, и каждая из таких требуемых взаимосвязей должна быть протестирована. К популярным критериям принадлежит критерий СР, заключающийся в покрытии всех таких пар дуг v и w, что из дуги v достижима дуга w, поскольку именно на дуге может произойти потеря значения переменной, которая в дальнейшем уже не должна использоваться. Для «покрытия» еще одного популярного критерия Cdu достаточно тестировать пары ( вершина , дуга ), поскольку определение переменной происходит в вершине УГП, а ее использование — на дугах, исходящих из решений, или в вычислительных вершинах.

Пример модульного тестирования

Предлагается протестировать класс TCommand , который реализует команду для склада. Этот класс содержит единственный метод TCommand.GetFullName() , спецификация которого описана (Практикум, Приложение 2 HLD) следующим образом:

Операция GetFullName() возвращает полное имя команды, соответствующее ее допустимому коду, указанному в поле NameCommand . В противном случае возвращается сообщение «ОШИБКА : Неверный код команды». Операция может быть применена в любой момент.

Разработаем спецификацию тестового случая для тестирования метода GetFullName на основе приведенной спецификации класса (Табл. 5.1):

Ожидаемый результат:

Перечисленным входным значениям должны соответствовать следующие выходные:

Коду команды -1 должно соответствовать сообщение «ОШИБКА: Неверный код команды»

Коду команды 1 должно соответствовать полное название команды «ПОЛУЧИТЬ ИЗ ВХОДНОЙ ЯЧЕЙКИ»

Коду команды 2 должно соответствовать полное название команды «ОТПРАВИТЬ ИЗ ЯЧЕЙКИ В ВЫХОДНУЮ ЯЧЕЙКУ»

Коду команды 4 должно соответствовать полное название команды «ПОЛОЖИТЬ В РЕЗЕРВ»

Коду команды 6 должно соответствовать полное название команды «ПРОИЗВЕСТИ ЗАНУЛЕНИЕ»

Коду команды 20 должно соответствовать полное название команды «ЗАВЕРШЕНИЕ КОМАНД ВЫДАЧИ»

Для тестирования метода класса TCommand.GetFullName() был создан тестовый драйвер — класс TCommandTester . Класс TCommandTester содержит метод TCommandTest1() , в котором реализована вся функциональность теста. В данном случае для покрытия спецификации достаточно перебрать следующие значения кодов команд: -1, 1, 2, 4, 6, 20, (-1 — запрещенное значение) и получить соответствующее им полное название команды с помощью метода GetFullName() (Пример 5.1 ). Пары значений (X, Yв) при исполнении теста заносятся в log-файл для последующей проверки на соответствие спецификации.

После завершения теста следует просмотреть журнал теста, чтобы сравнить полученные результаты с ожидаемыми, заданными в спецификации тестового случая TСommandTest1 (Пример 5.2).

class TCommandTester:Tester // Тестовый драйвер < . TCommand OUT; public TCommandTester() < OUT=new TCommand(); Run(); >private void Run() < TCommandTest1(); >private void TCommandTest1() < int[] commands = ; for(int i=0;i <=5;i++) < OUT.NameCommand=commands[i]; LogMessage(commands[i].ToString()+ » : «+OUT.GetFullName()); >> . >
Пример 5.1. Тестовый драйвер
-1 : ОШИБКА : Неверный код команды 1 : ПОЛУЧИТЬ ИЗ ВХОДНОЙ ЯЧЕЙКИ 2 : ОТПРАВИТЬ ИЗ ЯЧЕЙКИ В ВЫХОДНУЮ ЯЧЕЙКУ 4 : ПОЛОЖИТЬ В РЕЗЕРВ 6 : ПРОИЗВЕСТИ ЗАНУЛЕНИЕ 20 : ЗАВЕРШЕНИЕ КОМАНД ВЫДАЧИ

Источник: intuit.ru

6_Основы тестирования программного обеспечения

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

Виды и методы тестирования на разных стадиях разработки ПО

1. Виды и методы тестирования на разных стадиях разработки ПО

2. Уровни и виды тестирования

Модульное тестирование (component testing)
Интеграционное тестирование (integration testing)
Системное тестирование (system testing)
Приемочное тестирование (acceptance testing) – польз-ли
smoke testing
регрессионное тестирование
См. с. 144 Савина.

3. Взаимосвязь разработки и тестирования (V-диаграмма)

4. 5. Взаимосвязь разработки и тестирования (V-диаграмма)

Павловская Т.А. (СПбГУ ИТМО)
5

6. Модульное тестирование (Unit testing)

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

7. Обнаруживаемые ошибки

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

8. Интеграционное тестирование

Интеграционное тестирование (тестирование
сборки) — тестирование части системы, состоящей из
двух и более модулей.
Основная задача — поиск дефектов, связанных с
ошибками в реализации и интерпретации
взаимодействия между модулями.
Так же, как и модульное тестирование, оперирует
интерфейсами модулей и подсистем и требует создания
тестового окружения
Основная разница между модульным и интеграционным
тестированием состоит в типах обнаруживаемых
дефектов. В частности, на уровне интеграционного
тестирования часто применяются методы, связанные с
покрытием интерфейсов
Интеграционное тестирование использует модель
«белого ящика» на модульном уровне.

9. Методы сборки модулей

Монолитный, характеризующийся одновременным
объединением всех модулей в тестируемый комплекс.
Для замены неразработанных к моменту тестирования модулей
необходимо дополнительно разрабатывать драйверы (test driver) и/или
заглушки (stub)
Инкрементальный, характеризующийся помодульным
наращиванием комплекса программ с пошаговым
тестированием собираемого комплекса.
В инкрементальном методе выделяют две стратегии
добавления модулей:
«Сверху вниз» (нисходящее тестирование)
«Снизу вверх» (восходящее тестирование)
«Сэндвич»

10. Сравнение методов

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

11. Недостатки нисходящего тестирования

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

12. Недостатки восходящего тестирования

Запаздывание проверки концептуальных
особенностей тестируемого комплекса
Необходимость в разработке и использовании
драйверов

13. Системное тестирование

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

14. Категории тестов системного тестирования

1.
Полнота решения функциональных задач.
2.
Тестирование целостности (соответствие
документации, комплектность).
3.
Проверка инсталляции и конфигурации на разных
платформах.
4.
Оценка производительности.
5.
Стрессовое тестирование — на предельных объемах
нагрузки входного потока.
6.
Корректность использования ресурсов (утечка памяти,
возврат ресурсов).
7.
Эффективность защиты от искажения данных и
некорректных действий.
8.
Корректность документации и т.д.
Объемы данных на этом уровне таковы, что обычно более
эффективным подходом является полная или
частичная автоматизация тестирования

15. Другой пример разделения на категории:

Функциональное тестирование (functional testing)
Тестирование производительности (performance testing)
Стрессовое тестирование (stress testing)
Нагрузочное тестирование (load testing)
HP LoadRunner
Тестирование удобства использования (usability testing)
Тестирование интерфейса пользователя (UI testing)
Тестирование безопасности (security testing)
Тестирование локализации (localization testing)
Тестирование совместимости (compatibility testing)

16. Регрессионное тестирование

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

17. Исправление дефекта

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

18. Комбинирование уровней тестирования

В каждом конкретном проекте должны быть определены
задачи, ресурсы и технологии для каждого уровня
тестирования.
Задача тестировщиков и менеджеров — оптимально
распределить ресурсы между тремя уровнями
тестирования так, чтобы каждый из возможных типов
дефектов был «адресован» (в наборе тестов должны
иметься тесты, направленные на выявление дефектов
этого типа).
Например, перенесение усилий на поиск фиксированного
типа дефектов из области системного в область
модульного тестирования может существенно снизить
сложность и стоимость всего процесса тестирования.

19.

Модульное
Интеграцион
ное
Системное
Локальные
дефекты
Интерфейсные
дефекты
Отсутствующая
функциональность,
ошибки
совместимости,
документации,
переносимости,
проблемы
производительности,
инсталляции и т.п.
Да
Да
Нет*
Цена разработки
системы
тестирования
Низкая
Низкая до
умеренной
Умеренная до
высокой или
неприемлемой
Цена процесса
тестирования
Низкая
Низкая
Высокая
Типы дефектов
Необходимость в
системе
тестирования

20. Приемочное тестирование

Приемочное тестирование
(Acceptance testing) тестирование готового продукта
конечными пользователями в
реальном окружении.
Приемочные тесты
разрабатываются
пользователями (обычно в виде
сценариев).
Acceptance
Testing
System
Testing
Integration
Testing
Unit
Testing

21. Эвристические методы создания тестов

22. Простейший пример

Программа выполняет ввод трех целых чисел
и выводит сообщение о том, является ли треугольник с такими
сторонами неравносторонним, равнобедренным или
равносторонним
1.
правильный неравносторонний
2.
правильный равносторонний
3.
правильный равнобедренный
4.
по крайней мере 3 теста, представляющих правильные равнобедренные, полученные как
переставновки двух разных сторон
5.
длина одной из сторон 0
6.
длина одной из сторон 7.
три положительных числа, сумма двух из сторон равна третьей
8.
по крайней мере 3 теста со всеми тремя перестановками, когда сумма двух сторон равна третьей
9.
три положительных числа, сумма двух из сторон < третьей
10.
по крайней мере 3 теста из категории 9
11.
все стороны = 0
12.
по крайней мере один тест, содержащий нецелые значения
13.
по крайней мере один тест, содержащий неверное кол-во значений
14.
и вообще: указаны ли ожидаемые результаты каждого теста?

23. Подход к созданию тестов на примере

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

24.

Первый тест — базовый
Проблемы:
Ввод запрашивается с помощью знака «?»
— ош-ка пр-я: нет сопровод. инф-и, что вводить
как остановить
что за программа
— ош-ка кодир-я: ответ в стороне от исх. дан

25.

99 +
99
-99 + -99
99 + -14
198
-198
85 большое первое может повлиять
на интерпр-ю второго
-38 + 99
56 + 99
9+
0 + 0
0 + 23
-78 + 0
61
-и+
9
( каждая цифра встречается 1 раз)

26. Классы тестов

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

27.

серия недопустимых значений
серия проверки редактирования (стрелки, BS, Del)
граничные условия
100 + 100
цифра ли: коды от 48 до 57 (мб опечатка 75).
границы / (47) 0 9 : (58)
Фантазии:
Enter + Enter
123456 + 0
+1 + ___2
(пробелы – до и после числа)
1,2 + 5
a + b
Ctrl-A + Ctrl-B
F1 + esc

28. Характеристики хорошего теста

существует обоснованная вероятность выявления тестом
ошибок
не избыточен
тестовый набор дб наилучшим в своей категории
не дб слишком простым или слишком сложным
Некорректное поведение программы должно проявляться с
достаточной очевидностью
Дорогие друзья! Взращивайте и лелейте в себе неисправимый
пессимизм в отношении идеи о коде, свободном от багов.
Смотрите на код как на виртуальную вещь, которая в процессе
тестирования послужит еще одним доказательством постулата о
несовершенстве мира. (Р. Савин)

29.

Классы эквивалентности
граничные условия
тестирование переходов между состояниями
все меню и опции (трудно) => все вероятные
последовательности действий пользователей
Условия гонок и другие временнЫе зависимости
запуск параллельно многих задач
нажатие клавиш не вовремя
тестирование производительности
нагрузочное тестирование
прогнозирование ошибок (не явл. границами, но могут
вызвать сбой; интуиция) – error-guess testing

30. Виды тестов

Базовый тест — smoke test
(простой тестовый пример)
Инвентаризация
(определить различные категории данных и создать тесты
для каждого элемента категории)
Комбинированные тесты
(скомбинировать различные входные данные)
Граничные оценки
(оценить поведение программы при граничных значениях
данных)
Ошибочные данные
(оценить отклик системы на ввод неправильных данных)
Нагрузочные тесты, создание напряжений
(попытаться вывести систему из строя)

31. Из Савина:

Методы генерирования тестов:
1. Черновик-чистовик (dirty list-white list);
2. Матричная раскладка (matrices);
3. Блок-схемы (flowchart).
Методы отбора тестов:
1. Оценка риска (risk estimate);
2. Эквивалентные классы (equivalent classes);
3. Пограничные значения (boundary values).

Источник: ppt-online.org