Перевод:
Анна Радионова
Существует много видов ПО тестов. Практики BDD можно применять в любых аспектах тестирования, но BDD фреймворки используются далеко не во всех типах тестов. Поведенческие сценарии, по сути, являются функциональными тестами - они проверяют, что тестируемый продукт работает корректно. Для тестирования производительности могут использоваться инструменты, в то время как BDD фреймворки не предназначены для этих целей. Задача данной статьи, в основном, состоит в описании роли BDD автоматизации в Пирамиде Тестирования. Прочитайте статью BDD 101: Manual Testing для того, чтобы понимать как BDD применяется при ручном тестировании. (Всю информацию по BDD можно найти на странице Automation Panda BDD page)
Пирамида Тестирования
Тем не менее, BDD практики могут применяться для юнит-тестов. Каждый юнит-тест должен быть направлен на основную составляющую: один вызов, единичная вариация, определенная комбинация ввода; на поведение .В дальнейшем при разработке спецификация поведения фичи четко отделяет юнит тесты от тестов более высокого уровня. Разработчик функционала также ответственен за написание юнит-тестов, в то время как за интеграционные и end-to-end тесты несет ответственность другой инженер. Спецификация поведения является, своего рода, джентльменским соглашением о том, что юнит-тесты будут являться отдельной сущностью.
Интеграционное и End-to-End тестирование
Тестовые BDD фреймворки наиболее ярко проявляют себя на интеграционных и end-to-end уровнях тестирования .
Поведенческие спецификации однозначно и лаконично описывают, на что именно ориентирован тест-кейс. Шаги могут быть написаны на интеграционном или end-to-end уровне. Тесты сервиса могут быть написаны с помощью поведенческих спецификаций, как, например в Karate . End-to-end тесты фактически представляют собой многошаговые интеграционные тесты. Обратите внимание на следующий пример, который, на первый взгляд, кажется базовой моделью взаимодействия с пользователем, но, по сути, является объемным end-to-end тестом:
Given
a user is logged into the social media site
When
the user writes a new post
Then
the user"s home feed displays the new post
And
the all friends" home feeds display the new post
Простая публикация в социальной сети включает процессы взаимодействия с интерфейсом, вызовы сервисов бекенда и внесение изменений в базу данных в режиме реального времени. Описан полный путь прохождения в системе. Автоматизированные шаги могут покрывать эти уровни явно или неявно, но они совершенно точно покрыты тестом.
Длительные End-to-End тесты
Термины часто понимаются разными людьми по-разному. Когда люди говорят “end-to-end тесты,” они подразумевают продолжительные последовательные тесты: тесты, которые покрывают различное поведение продукта одно за другим . Это утверждение заставляет содрогнуться приверженцев BDD, т.к это противоречит основному правилу BDD: один сценарий, одно поведение. Конечно, с помощью BDD фреймворков можно составлять длительные end-to-end тесты, но нужно хорошо подумать, стоит ли это делать и как именно.
Существует пять основных принципов написания длительных end-to-end сценариев в BDD:
- Не стоит беспокоиться на этот счет . Если BDD процесс поставлен правильно, то каждое отдельное поведение уже полностью покрыто тестовыми сценариями. Каждый сценарий должен покрывать все классы эквивалентности вводимых и выводимых данных. Таким образом, длительные end-to-end сценарии будут являться, в основном, дублированием тестового покрытия. Вместо того, чтобы тратить время на разработку, лучше отказаться от автоматизации длительных end-to-end сценариев, как от тех, которые не представляют большой ценности и уделить больше времени ручному и исследовательскому тестированию .
- Объединить существующие сценарии в новые . Каждая When-Then пара представляет собой индивидуальное поведение. Шаги из существующих сценариев могут быть переопределены в другие сценарии и для этого потребуется лишь незначительный рефакторинг. Это нарушает хорошие практики Gherkin и может привести к появлению длительных сценариев, но это наиболее практичный способ переиспользовать шаги для обширных end-to-end сценариев. Большинство BDD фреймворков не поддерживают пошаговый порядок, а если поддерживают, то шаги должны быть переписаны, чтобы код работал. (Этот подход является наиболее практичным, но менее традиционным .)
- Встраивайте проверки в Given и When шаги . Данная стратегия позволяет избежать дуплицирования When-Then пар и убедиться, что проверки производятся. Корректность каждого шага проверяется на протяжении всего процесса с помощью Gherkin текста. Однако, может потребоваться ряд новых шагов.
- Воспринимайте последовательность поведений как уникальное отдельное поведение . Это наилучший способ обдумывания длительных end-to-end сценариев, т.к. он усиливает поведенческое мышление. Продолжительный сценарий имеет ценность только в том случае, если он расценивается как уникальное поведение. Сценарий должен быть написан с целью подчеркнуть эту уникальность. В противном случае это не тот сценарий, который стоит использовать. Такие сценарии часто являются декларативными и высокоуровневыми.
- Не используйте BDD фреймворки и пишите тесты исключительно с помощью средств автоматизации . Gherkin предназначен для совместной работы в отношении поведения, в то время как продолжительные end-to-end тесты решают проблемы интенсивности работы QA. Бизнес может предоставить поведенческие спецификации, но никогда не станет писать end-to-end тесты. Переписывание поведенческих спецификаций в длинные end-to-end сценарии может блокировать разработку. Гораздо лучшим решением является сосуществование: приемочные тесты могут быть написаны при помощи Gherkin, а продолжительные end-to-end тесты - средствами программирования. Для автоматизации обоих наборов тестов можно использовать одну и ту же базу кода, у них могут быть единые модули поддержки и даже методы определения шагов.
Выберите подход, наиболее подходящий вашей команде.
Ни одна разработка программного обеспечения не обходится без тестирования исполняемого кода. Фактически, на это уходит половина всего времени, затраченного на разработку, и более половины стоимости проекта. Однако это неотъемлемая часть процесса создания новых приложений, программ, систем.
Интеграционное тестирование как часть большой работы
Один из способов контроля качества программного обеспечения - интеграционное тестирование, на вход которого подаются отдельно взятые модули, протестированные на предыдущем этапе.
В отличие от модульного варианта, в ходе которого выявляются ошибки, локализованные в каждой отдельно взятой функции или классе, интеграционное тестирование - это поиск дефектов, связанных с реализацией взаимодействия между отдельными частями создаваемого продукта. Интеграционное функциональное тестирование использует метод «белого ящика», то есть инженеру по качеству доступны и известны тексты каждого отдельного модуля, а также принципы взаимодействия между ними.
Методы сборки модулей
Монолитный метод означает, что все модули, которые в будущем будут подвергнуты интеграционному тестированию, собираются воедино одновременно. Почти наверняка возникают ситуации, когда часть тестируемого комплекса еще не готова.
В таком случае ее заменяют дополнительно разработанными "заглушками", или драйверами.
Наряду с монолитным методом выделяют инкрементальный (его еще называют пошаговым), так как объем тестируемого кода наращивается постепенно, давая локализовать участки с дефектами во взаимосвязях между отдельными частями.
Инкрементальный метод включает в себя два способа добавления модулей:
- сверху-вниз или восходящий,
- снизу-вверх - нисходящий.
Особенности монолитного и инкрементального тестирования
Главный недостаток монолитного вида сборки - большое количество времени и трудозатрат уходит на имитацию недостающих частей тестируемого комплекса. Казалось бы, заглушки - достаточно удобный инструмент тестирования, однако возникают ситуации, когда в процессе приходится создавать заново имитационные части программы. Например, в случае изменения состава тестируемых модулей. Кроме того, эффективность поиска дефектов не так высока, когда работа ведется не с реальным продуктом, а лишь с фиктивным компонентом. Этот же недостаток сопровождает и инкрементальное тестирование с восходящим способом сборки.
В то же время одним из недостатков пошагового метода является необходимость организации и создания среды для исполнения модулей в заданной последовательности. А также практически невозможна параллельная разработка верхних и нижних уровней.
Конечно же, оба способа сборки, монолитный и инкрементальный, имеют не только недостатки, но и достоинства. В первом случае появляются отличные возможности для параллельной разработки всех классов и функций, участвующих в тестировании, как на начальном этапе, так и после доработки. Пошаговый же метод менее трудозатратен: модули присоединяются постепенно, и так же постепенно обнаруживаются ошибки и дефекты. Это, как известно, позволяет сократить время на поиск таковых.
Преимущества проведения интеграционного тестирования
На этом этапе проводится колоссальная работа проверки взаимосвязей всех уровней, без чего, конечно же, невозможно дальнейшее тестирование.
Интеграционное тестирование программного обеспечения имеет ряд преимуществ:
- проверка интерфейса взаимодействия между отдельными модулями программы;
- контроль взаимосвязей тестируемого комплекса со сторонними программными решениями;
- тестирование работы внешних компонентов решения;
- контроль соответствия документации по проекту в части взаимодействия отдельных модулей.
Исправление дефектов
Интеграционное тестирование завершено, однако это еще не все. Найденные ошибки фиксируются и отправляются разработчику для исправления, после чего процесс начинается заново.
Во-первых, необходимо проверить, были ли устранены выявленные дефекты. Во-вторых, во время изменения исходного кода могли возникнуть новые ошибки в работе программы и взаимодействии со сторонним ПО.
Хотя в настоящее время и существует большое количество методов контроля качества, по-прежнему немаловажную роль играет интеграционное тестирование. Пример такого вида проверки может наглядно продемонстрировать «узкие» места при разработке программного обеспечения и документации.
Автоматизация тестирования
В зависимости от объема исходного комплекса данных и предметной области разработки может вставать проблема времени тестирования и трудоемкости мероприятия в целом.
Для наиболее эффективной проверки разработки необходимо использовать огромное количество входных данных и условий, с чем "вручную" справиться невозможно. Для решения этой проблемы используется автоматизация тестирования. Как и другие виды, интеграционное тестирование также может быть автоматизировано. Это позволит сократить время разработки в целом, а также повысит эффективность процесса обнаружения ошибок.
Однако автоматизация тестирования не может полностью заменить труд инженера по качеству, а лишь дополнить его.
Итак, интеграционное тестирование - это неотъемлемая часть разработки любого программного обеспечения и один из этапов всего процесса проверки качества продукта. Как и любой метод, он имеет ряд достоинств и недостатков, но без его применения становится невозможной качественная разработка ПО.
Интеграционное тестирование - это тестирование части системы, состоящей из двух и более модулей. Основная задача интеграционного тестирования - поиск дефектов, связанных с ошибками в реализации и интерпретации интерфейсного взаимодействия между модулями.
С технологической точки зрения интеграционное тестирование является количественным развитием модульного, поскольку так же, как и модульное тестирование, оперирует интерфейсами модулей и подсистем и требует создания тестового окружения, включая заглушки (Stub) на месте отсутствующих модулей. Основная разница между модульным и интеграционным тестированием состоит в целях, то есть в типах обнаруживаемых дефектов, которые, в свою очередь, определяют стратегию выбора входных данных и методов анализа. В частности, на уровне интеграционного тестирования часто применяются ме тоды, связанные с покрытием интерфейсов, например, вызовы функций или методов, или анализ использования интерфейсных объектов таких, как глобальные ресурсы, средства коммуникаций, предоставляемые операционной системой.
На Рис. 15 приведена структура комплекса программ K, состоящего из оттестированных на этапе модульного тестирования модулей M1, M2, M11, M12, M21, M22. Задача, решаемая методом интеграционного тестирования, - тестирование межмодульных связей, реализующихся при исполнении программного обеспечения комплекса K.
Рис. 15. Пример структуры комплекса программ
Интеграционное тестирование использует модель «белого ящика» на модульном уровне. Поскольку тестировщику текст программы известен с детальностью до вызова всех модулей, входящих в тестируемый комплекс, применение структурных критериев на данном этапе возможно и оправдано.
Интеграционное тестирование применяется на этапе сборки модульно оттестированных модулей в единый комплекс. Известны два метода сборки модулей:
Монолитный, характеризующийся одновременным объединением всех модулей в тестируемый комплекс;
Инкрементальный, характеризующийся пошаговым (помодульным) наращиванием комплекса программ с пошаговым тестированием собираемого комплекса.
В инкрементальном методе выделяют две стратегии добавления модулей:
1) «Сверху вниз» и соответствующее ему восходящее тестирование.
2) «Снизу вверх» и соответственно нисходящее тестирование.
Особенности монолитного тестирования заключаются в следующем: для замены неразработанных к моменту тестирования модулей, кроме самого верхнего (модуль К на Рис. 15), необходимо дополнительно разрабатывать драйверы (test driver) и/или заглушки (stub), замещающие отсутствующие на момент сеанса тестирования модули нижних уровней.
Сравнение монолитного и интегрального подхода дает следующее.
1. Монолитное тестирование требует больших трудозатрат, связанных с дополнительной разработкой драйверов и заглушек и со сложностью идентификации ошибок, проявляющихся в пространстве собранного кода.
2. Пошаговое тестирование связано с меньшей трудоемкостью идентификации ошибок за счет постепенного наращивания объема тестируемого кода и соответственно локализации добавленной области тестируемого кода.
Особенности нисходящего тестирования заключаются в следующем: организация среды для исполняемой очередности вызовов оттестированными модулями тестируемых модулей, постоянная разработка и использование заглушек, организация приоритетного тестирования модулей, содержащих операции обмена с окружением, или модулей, критичных для тестируемого алгоритма.
Например, порядок тестирования комплекса K (Рис. 15) при нисходящем тестировании может быть таким, как показано ниже, где тестовый набор, разработанный для модуля Mi, обозначен как XYi = (X, Y)i.
K->XYk
M1->XY1
M11->XY11
M2->XY2
M22->XY22
M21->XY21
M12->XY12
К недостаткам нисходящего тестирования следует отнести:
Проблему разработки достаточно «интеллектуальных» заглушек, т.е. заглушек, способных к использованию при моделировании различных режимов работы комплекса, необходимых для тестирования;
Сложность организации и разработки среды для реализации исполнения модулей в нужной последовательности;
Не всегда эффективную реализацию модулей из-за подстройки (специализации) еще не тестированных модулей нижних уровней к уже оттестированным модулям верхних уровней при параллельной разработке модулей верхних и нижних уровней.
Особенности восходящего тестирования заключаются в организации порядка сборки и перехода к тестированию модулей, соответствующему порядку их реализации.
Например, порядок тестирования комплекса K (Рис. 15) при нисходящем тестировании может быть следующим:
M11->XY11
M12->XY12
M1->XY1
M21->XY21
M2(M21, Stub(M22))->XY2
K(M1, M2(M21, Stub(M22)) ->XYk
M22->XY22
M2->XY2
K->XYk
А к недостаткам восходящего тестирования можно отнести:
Запаздывание проверки концептуальных особенностей тестируемого комплекса;
Необходимость в разработке и использовании драйверов.
Лекция является второй из трех рассматривающих уровни процесса верификации. Тема данной лекции - процесс интеграционного тестирования, его задачи и цели. Рассматриваются организационные аспекты интеграционного тестирования - структурная и временная классификации методов интеграционного тестирования, планирование интеграционного тестирования. Цель данной лекции: дать представление о процессе интеграционного тестирования, его технической и организационной составляющих
Задачи и цели интеграционного тестирования
Результатом тестирования и верификации отдельных модулей, составляющих программную систему, должно быть заключение о том, что эти модули являются внутренне непротиворечивыми и соответствуют требованиям. Однако отдельные модули редко функционируют сами по себе, поэтому следующая задача после тестирования отдельных модулей - тестирование корректности взаимодействия нескольких модулей, объединенных в единое целое. Такое тестирование называют интеграционным. Его цель удостовериться в корректности совместной работы компонент системы.
Интеграционное тестирование называют еще тестированием архитектуры системы. С одной стороны, это название обусловлено тем, что интеграционные тесты включают в себя проверки всех возможных видов взаимодействий между программными модулями и элементами, которые определяются в архитектуре системы - таким образом, интеграционные тесты проверяют полноту взаимодействий в тестируемой реализации системы. С другой стороны, результаты выполнения интеграционных тестов - один из основных источников информации для процесса улучшения и уточнения архитектуры системы, межмодульных и межкомпонентных интерфейсов. Т.е., с этой точки зрения, интеграционные тесты проверяют корректность взаимодействия компонент системы.
Примером проверки корректности взаимодействия могут служить два модуля, один из которых накапливает сообщения протокола о принятых
Синицын С.В., Налютин Н.Ю. Верификация программного обеспечения
файлах, а второй выводит этот протокол на экран. В функциональных требованиях к системе записано, что сообщения должны выводиться в обратном хронологическом порядке. Однако, модуль хранения сообщений сохраняет их в прямом порядке, а модуль вывода использует стек для вывода в обратном порядке. Модульные тесты, затрагивающие каждый модуль по отдельности, не дадут здесь никакого эффекта - вполне реальна обратная ситуация, при которой сообщения хранятся в обратном порядке, а выводятся с использованием очереди. Обнаружить потенциальную проблему можно только проверив взаимодействие модулей при помощи интеграционных тестов. Ключевым моментом здесь является то, что в обратном хронологическом порядке сообщения выводит система в целом, т.е., проверив модуль вывода и обнаружив, что он выводит сообщения в прямом порядке, мы не сможем гарантировать, что мы обнаружили дефект.
В результате проведения интеграционного тестирования и устранения всех выявленных дефектов получается согласованная и целостная архитектура программной системы, т.е. можно считать, что интеграционное тестирование - это тестирование архитектуры и низкоуровневых функциональных требований.
Интеграционное тестирование, как правило, представляет собой итеративный процесс, при котором проверяется функциональной все более и более увеличивающейся в размерах совокупности модулей.
100 р бонус за первый заказ
Выберите тип работы Дипломная работа Курсовая работа Реферат Магистерская диссертация Отчёт по практике Статья Доклад Рецензия Контрольная работа Монография Решение задач Бизнес-план Ответы на вопросы Творческая работа Эссе Чертёж Сочинения Перевод Презентации Набор текста Другое Повышение уникальности текста Кандидатская диссертация Лабораторная работа Помощь on-line
Узнать цену
В статье третьей (УШ № 32) говорилось о традиционных тестах. Там же приводились определения гомогенных и гетерогенных тестов. В сегодняшней статье - материал о нетрадиционных тестах, к которым можно отнести тесты интегративные, адаптивные, многоступенчатые и так называемые критериально-ориентированные тесты.
Интегративным можно назвать тест, состоящий из системы заданий, отвечающих требованиям интегративного содержания, тестовой формы, возрастающей трудности заданий, нацеленных на обобщенную итоговую диагностику подготовленности выпускника образовательного учреждения. Диагностика проводится посредством предъявления таких заданий, правильные ответы на которые требуют интегрированных (обобщенных, явно взаимосвязанных) знаний двух и большего числа учебных дисциплин. Создание таких тестов дается только тем преподавателям, которые владеют знаниями ряда учебных дисциплин, понимают важную роль межпредметных связей в обучении, способны создавать задания, правильные ответы на которые требуют от учащихся знаний различных дисциплин и умений применять такие знания.
Интегративному тестированию предшествует организация интегративного обучения. К сожалению, существующая сейчас классно-урочная форма проведения занятия, в сочетании с чрезмерным дроблением учебных дисциплин, вместе с традицией преподавания отдельных дисциплин (а не обобщенных курсов), ещё долго будут тормозить внедрение интегративного подхода в процессы обучения и контроля подготовленности. Преимущество интегративных тестов перед гетерогенными заключается в большей содержательной информативности каждого задания и в меньшем числе самих заданий. Потребность создания интегративных тестов возрастает по мере повышения уровня образования и числа изучаемых учебных дисциплин. Поэтому попытки создания таких тестов отмечаются, в основном, в высшей школе. Особенно полезны интегративные тесты для повышения объективности и эффективности проведения итоговой государственной аттестации учащихся и студентов.
Методика создания интегративных тестов сходна с методикой создания традиционных тестов, за исключением работы по определению содержания заданий. Для отбора содержания интегративных тестов использование экспертных методов является обязательным. Это связано с тем, что только эксперты могут определить адекватность содержания заданий целям теста. Но, прежде всего, самим экспертам важно будет определиться с целями образования и изучения тех или иных образовательных программ, а затем и договориться между собой по принципиальным вопросам, оставив для экспертизы лишь вариации в понимании степени значимости отдельных элементов в общей структуре подготовленности. Согласованный, по принципиальным вопросам, отобранный состав экспертов в зарубежной литературе нередко панелью. Или учитывая различия в смысле последнего слова, в русском языке, такой состав можно назвать представительной экспертной группой. Группа подбирается так, чтобы адекватно представлять подход, используемый при создании соответствующего теста.
