Типы тестирования по способу выбора входных значений

Виды тестирования и подходы к их применению

Блочное (модульное, unit testing) тестирование наиболее понятное для программиста. Фактически это тестирование методов какого-то класса программы в изоляции от остальной программы.

Не всякий класс легко покрыть unit тестами. При проектировании нужно учитывать возможность тестируемости и зависимости класса делать явными. Чтобы гарантировать тестируемость можно применять TDD методологию, которая предписывает сначала писать тест, а потом код реализации тестируемого метода. Тогда архитектура получается тестируемой. Распутывание зависимостей можно осуществить с помощью Dependency Injection. Тогда каждой зависимости явно сопоставляется интерфейс и явно определяется как инжектируется зависимость — в конструктор, в свойство или в метод.

Для осуществления unit тестирования существуют специальные фреймворки. Например, NUnit или тестовый фреймфорк из Visual Studio 2008. Для возможности тестирования классов в изоляции существуют специальные Mock фреймворки. Например, Rhino Mocks. Они позволяют по интерфейсам автоматически создавать заглушки для классов-зависимостей, задавая у них требуемое поведение.

По unit тестированию написано много статей. Мне очень нравится MSDN статья Write Maintainable Unit Tests That Will Save You Time And Tears, в которой хорошо и понятно рассказывается как создавать тесты, поддерживать которые со временем не становится обременительно.

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

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

Если к нему подходить как к unit-тестированию, у которого в тестах зависимости не заменяются mock-объектами, то получаем проблемы. Для хорошего покрытия нужно написать много тестов, так как количество возможных сочетаний взаимодействующих компонент — это полиномиальная зависимость. Кроме того, unit-тесты тестируют как именно осуществляется взаимодействие (см. тестирование методом белого ящика). Из-за этого после рефакторинга, когда какое-то взаимодействие оказалось выделенным в новый класс, тесты рушатся. Нужно применять менее инвазивный метод.

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

Хорошая статья по интеграционному тестированию мне попалась лишь однажды — Scenario Driven Tests. Прочтя ее и книгу Ayende по DSL DSLs in Boo, Domain-Specific Languages in .NET у меня появилась идея как все-таки устроить интеграционное тестирование.

Идея простая. У нас есть входные данные, и мы знаем как программа должна отработать на них. Запишем эти знания в текстовый файл. Это будет спецификация к тестовым данным, в которой записано, какие результаты ожидаются от программы. Тестирование же будет определять соответствие спецификации и того, что действительно находит программа.

Проиллюстрирую на примере. Программа конвертирует один формат документа в другой. Конвертирование хитрое и с кучей математических расчетов. Заказчик передал набор типичных документов, которые ему требуется конвертировать. Для каждого такого документа мы напишем спецификацию, где запишем всякие промежуточные результаты, до которых дойдет наша программа при конвертировании. 1) Допустим в присланных документах есть несколько разделов. Тогда в спецификации мы можем указать, что у разбираемого документа должны быть разделы с указанными именами: $SectionNames = Введение, Текст статьи, Заключение, Литература 2) Другой пример. При конвертировании нужно разбивать геометрические фигуры на примитивы. Разбиение считается удачным, если в сумме все примитивы полностью покрывают оригинальную фигуру. Из присланных документов выберем различные фигуры и для них напишем свои спецификации. Факт покрываемости фигуры примитивами можно отразить так: $IsCoverable = true

Понятно, что для проверки подобных спецификаций потребуется движок, который бы считывал спецификации и проверял их соответствие поведению программы. Я такой движок написал и остался доволен данным подходом. Скоро выложу движок в Open Source. (UPD: Выложил)

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

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

Системное — это тестирование программы в целом. Для небольших проектов это, как правило, ручное тестирование — запустил, пощелкал, убедился, что (не) работает. Можно автоматизировать. К автоматизации есть два подхода.

Первый подход — это использовать вариацию MVC паттерна — Passive View (вот еще хорошая статья по вариациям MVC паттерна) и формализовать взаимодействие пользователя с GUI в коде. Тогда системное тестирование сводится к тестированию Presenter классов, а также логики переходов между View. Но тут есть нюанс. Если тестировать Presenter классы в контексте системного тестирования, то необходимо как можно меньше зависимостей подменять mock объектами. И тут появляется проблема инициализации и приведения программы в нужное для начала тестирования состояние. В упомянутой выше статье Scenario Driven Tests об этом говорится подробнее.

Второй подход — использовать специальные инструменты для записи действий пользователя. То есть в итоге запускается сама программа, но щелканье по кнопкам осуществляется автоматически. Для .NET примером такого инструмента является White библиотека. Поддерживаются WinForms, WPF и еще несколько GUI платформ. Правило такое — на каждый use case пишется по скрипту, который описывает действия пользователя. Если все use case покрыты и тесты проходят, то можно сдавать систему заказчику. Акт сдачи-приемки должен подписать.

Источник

Особенности индустриального тестирования

Планирование тестирования

Тестовый план

Тестовый план — это документ, или набор документов, содержащий следующую информацию:

1. Тестовые ресурсы.
2. Перечень функций и подсистем, подлежащих тестированию.

Тестовую стратегию , включающую:

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

Типы тестирования

В тестовом плане определяются и документируются различные типы тестов. Типы тестов могут быть классифицированы по двум категориям: по тому, что подвергается тестированию (по виду подсистемы) и по способу выбора входных данных.

Типы тестирования по виду подсистемы или продукта:

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

Типы тестирования по способу выбора входных значений:

Функциональное тестирование, при котором проверяется:

• Покрытие функциональных требований.
• Покрытие сценариев использования.

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

Источник

Особенности индустриального тестирования

Планирование тестирования

Тестовый план

Тестовый план — это документ, или набор документов, содержащий следующую информацию:

1. Тестовые ресурсы.
2. Перечень функций и подсистем, подлежащих тестированию.

Тестовую стратегию , включающую:

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

Типы тестирования

В тестовом плане определяются и документируются различные типы тестов. Типы тестов могут быть классифицированы по двум категориям: по тому, что подвергается тестированию (по виду подсистемы) и по способу выбора входных данных.

Типы тестирования по виду подсистемы или продукта:

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

Типы тестирования по способу выбора входных значений:

Функциональное тестирование, при котором проверяется:

• Покрытие функциональных требований.
• Покрытие сценариев использования.

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

Источник

Классификация видов тестирования

Учил студентов предмету «Тестирование и отладка программного обеспечения» в ИжГТУ. Структуру курса обучения построил на основе классификации видов тестирования.

Карту можно скачать тут.

Карта с видами тестирования на каждое занятие

Пословица разных народов мира.

Виды тестирования сгруппированы на mind-карте по:

• целям;
• хронологии выполнения;
• формальности;
• позитивности;
• .

Каждое занятие выбирали:

• Тестируемое приложение или сервис: почтовый клиент, видео-хостинг, .
• Опорный вид тестирования, например, основное функциональное ручное позитивное … тестирование
• Несколько видов тестирования для сравнения с опорным: повторное, автоматическое, негативное

Начинали выполнять тестовые работы в рамках выбранного опорного вида тестирования.

Состав тестовых работ выбирался из опорного списка:

1. Планирование.
2. Подготовка сценариев.
3. Подготовка тестового окружения.
4. Выполнение тестов.
5. Анализ результатов тестирования.
6. Отчёты.
7. Отслеживание дефектов.

Каждый раз для выбора вида тестирования использовалась карта. Каждый раз использовался опорный список видов работ.

Попарное сравнение

Всё познаётся только в правильно выполненном сравнении.

Автор мне неизвестен, возможно, Фридрих Ницше или Рене Декарт.

На конкретных примерах рассматривали, какая техника тест-дизайна при подготовке сценариев более применима к функциональному тестированию, а какая к конфигурационному. Разбирали в чём отличия выполнения тестов для основного функционального исследовательского тестирования, от основного функционального тестирования по тестам. Чем будут отличаться планы тестирования. Как при этом, выглядят проекты тестов (чеклист или mind-карта, против инструкций с порядком действий и ожидаемым результатом). Что является общим — процесс отслеживания дефектов.

Рассматривали, чем отличаются отчёты по конфигурационному тестированию и тестрованию масшабируемости, или отчёты по нагрузочному и объёмному.

Приносил примеры отчётов, несекретных и старых, сокращал их до 3-х страниц, удалив конфиденциальную информацию. Разбирали, что в отчётах общего (структура: цели, основа, краткие результаты, детали). В чём отличия. Как их читать. Как составлять. Как формировать автоматически.

Так, перебирая попарно виды тестирования формировал представление о выборе инструментов, подходов, целей и задач изучаемой деятельности.

Список работ по тестированию взял из SWEBOK (v3), глава 4 «Software Testing», раздел «Test Process», подраздел «Test Activities».

Эти виды работ выполняют инженеры по тестированию постоянно. Каждый вид работ важен. Для каждого есть хорошие и плохие рекомендации, инструменты, техники. Целью лекционных занятий было донесение до студентов видов тестирования и видов работ по тестированию. Относительно небольшой перечень знаний, и этих знаний достаточно, чтобы начать улучшать качество программного обеспечения.

Зачем карта

Нам не дано предугадать, как слово наше отзовется .

Фёдор Иванович Тютчев, 27 февраля 1869.

Карта является опорным конспектом для преподавателя. Напоминает о чём, надо успеть сказать. Помогает не сказать лишнего. Ведь времени так мало, а рассказать надо так много.

Ранее преподавал в учебном классе, где были только парты доска и мел. На занятия приходил точно к началу, доску не готовил. Стоять спиной и рисовать изучаемую предметную область во время занятий не хотел. Объяснить взаимосвязи на схемах удобно. Поэтому для каждой темы делал mind-карту. Распечатывал в нескольких экземплярах, раздавал студентам на занятии. Доску и мел использовал для изображения примеров. Рисовали как байтики движутся по схеме системы и приводят к SQL-инъекции, или как работает горизонтальное масшабирование. Так сформировалась привычка готовить mind-карты.

Карта позволяет:

• запоминать материал быстрее;
• экономить время при начале занятия;
• использовать официально разрешенную шпаргалку как для преподавателя так и для студента.

Ведя занятие, читаешь по бумаге, но чтение между строк допустимо.

Студенты, имея перед глазами карту, имеют больший выбор:

• просто слушать;
• коспектировать;
• рисовать.

Больше думают, легче находят аналогии, увереннее отвечают на вопросы. Готовишь карту к каждому занятию, студенты начинают ждать очередной материал. И если, вдруг, не подготовить схему, то занятие начнётся с вопроса: «А что, принтер сломался?», — смеются, уже хорошо.

Особенность этой карты с видами тестирования — наличие определений для каждого узла. Если сохранить карту в формате html, получится объёмное чтиво.

Есть ограничения использования mind-карт в подготовке темы занятия. При большом количестве узлов, карта плохо читается на формате альбомного листа. И тогда лучше использовать доску и мел — дублировать части схемы на доске.

О доске и меле

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

Потом стал стараться писать и рисовать, как в начальных классах. Ровно, красиво, чётко («как слоги в пионерской речёвке»). Студенты стали задавать больше вопросов. Стало понятнее, что занятия стали понятнее.

О преподавании

Готовился основательно. Случались технические сбои и заминки, не всё удавалось показать и объяснить. О каждом случае можно отдельную историю рассказать. Так подготовка лабораторных работ по тестированию — дорога на Эверест, уложенная граблями. Отладить работу автоматического теста в идеальном окружении, бывает, непросто. А если окружение неидеальное, на каждом учебном компьютере оно своё, и тест написан студентом на скорую руку, то лишь телепатия и «эффект разработчика», в которого ты перевоплощаешься, могут помочь.

Преподавание позволяет научиться лучше рассказывать, писать, видеть. Выбирать основное и простое. И будет, что вспомнить, с улыбкой.
Стоит попробовать.

Источник