Чем отличается компонентная и интеграционная разработка

Уровни тестирования программного обеспечения

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

Уровни Тестирования

1. Компонентное или Модульное тестирование (Component or Unit Testing)

Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.). Обычно компонентное (модульное) тестирование проводится вызывая код, который необходимо проверить и при поддержке сред разработки, таких как фреймворки (frameworks — каркасы) для модульного тестирования или инструменты для отладки. Все найденные дефекты, как правило исправляются в коде без формального их описания в системе менеджмента багов (Bug Tracking System).

Один из наиболее эффективных подходов к компонентному (модульному) тестированию — это подготовка автоматизированных тестов до начала основного кодирования (разработки) программного обеспечения. Это называется разработка от тестирования (test-driven development) или подход тестирования вначале (test first approach). При этом подходе создаются и интегрируются небольшие куски кода, напротив которых запускаются тесты, написанные до начала кодирования. Разработка ведется до тех пор, пока все тесты не будут успешно пройдены.

Разница между компонентным и модульным тестированием:

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

2. Интеграционное тестирование (Integration Testing)

Интеграционное тестирование предназначено для проверки связи между компонентами, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами).

Уровни интеграционного тестирования:

Подходы к интеграционному тестированию:

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

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

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

3. Системное тестирование (System Testing)

Можно выделить два подхода к системному тестированию:

4. Приемочное тестирование или приемо-сдаточное испытание (Acceptance Testing)

Приемочное тестирование или приемо-сдаточное испытание (Acceptance Testing) — формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:

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

Фаза приемочного тестирования длится до тех пор, пока заказчик не выносит решение об отправлении приложения на доработку или выдаче приложения.

Схема классификации тестирования:Рис. 2.2. Схема, на которой все способы классификации показаны одновременно

Источник

СРЕДЫ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ОРИЕНТИРОВАННЫЕ НА ПРОЦЕССЫ.

Компилятор — это такая программа, которая считывает исходные коды, написанные программистом и преобразует эти коды в программу.

Интерпретатор — это программа которая считывает команды, находящиеся в исходных кодах, сразу выполняя их.

Когда в среде разработки ПО присутствуют все вышеназванные компоненты, тогда такую среду называют интегрированной. Такие среды разработки увеличивают темп, а также удобность разработки за счёт: автоматизации, возможности производить весь цикл создания и разработки ПО.

Обычно среда разработки ПО предназначена для разработки только на одном языке программирования. А такая среда разработки как интегрированная, предоставляет право выбрать создателю программы язык программирования для разработки, удобный разработчику (из языков поддерживаемых данной средой). Примером тому служат: Visual Studio, Komodo, Geany, Kylix, NetBeans, Eclipse.

Рассмотрим каждую среду разработки по отдельности

MicrosoftVisualStudio — одна из интегрированных сред разработки, разработана на С++ и С#, поддерживается Windows OS. Данная среда разработки переведена на десять языков (также и на русский язык). В Visual Studio создатель может вести разработку вебсайтов, веб-служб, писать консольные приложения, а также приложения с графическим интерфейсом. Также VS поддерживает разного рода дополнений. Самые знаменитые дополнения — это Re Sharper (выполняет поиск ошибок в коде во время написания кода программы разработчиком, до компиляции); Visual Assist (в отличии от Re Sharper поддерживает также и С++); AnkhSVN (использует в Visual Studio систему контроля версий, которая носит название Subversion).

Пример разработки программы в Visual Studio:

Достоинства: Понятный интерфейс среды разработки, удобность, автоматическое обнаружение ошибок в коде.

Недостатки: Сложно для начинающих программистов.

Среда особенно распространена в англоговорящих странах, России, Китае, Германии, Франции, Португалии, Италии, Японии, Испании и Корее.

Geany также интегрированная среда разработки ПО. Поддерживается на ОС Linux, а также на Mac Os и на Windows. Работает с тридцатью двумя языками (также и с русским языком). В составе Geany отсутствует компилятор. Компилятор можно установить как дополнение. Поддерживает достаточно много языков программирования, среди которых присутствуют классический С. С++ и С#.

Пример работы в среде Geany, на Linux OS:

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

Недостатки: Не включает в свой состав компилятор.

Среда распространена во многих странах (Более чем в тридцати).

Komodo или ActiveStateKomodo — была написана на JavaScript, XUL, Python. Интерфейс данной среды только на aнглийском языке. Рaботает нa теx жe опeрационных систeмах как Geany: на Os Linux, Windоws и Mac Os.

Поддерживает десять языков программирования, среди которые присутствуют: PHP, Ruby, HTML5.

Пример разработки в среде Komodo:

Достоинства: Дополнение Code Explorer позволяет просматривать объектное дерево скрипта или библиотеки, среда является кроссплатформенной, удобный отладчик с возможностью удаленной отладки, возможность настроить интерфейс среды «под себя».

Недостатки: Высокая стоимость, поддерживает мало языков программирования, сильно загружает компьютер (а именно оперативную память), является сложным для понимания.

Распространена в основном в англоговорящих странах.

Kylix — интегрированная среда. Функционирует на OS Linux. Работает с С, С++ и ObjectPascal.

В данной среде есть возможность писать приложения веб-служб.

Kylix выпускался в трёх пакетах. Эти пакеты: Enterprise Edition — включал в себя сто девяносто компонентов (являлся самым большим и самим дорогим пакетом программы); Professional Edition (более дешевый вариант, который включал в себя около 165 компонентов); Open Edition — бесплатный пакет программы, содержащий в себе 75 компонентов, в нём отсутствует средства для работы с базами данных.

Обновленная версия Kylix 2, в отличии от Kylix работала гораздо быстрее. Например, Kylix 1 осуществлял сортировку пузырьком массива из 115 элементов полторы минуты, Kylix 2 — одну секунду.

В 2002 году данную среду разработки прекратил поддерживать разработчик.

Пример разработки в среде Kylix:

Достоинства: Удобен в переносе написанного с одной операционной системы на другую.

Недостатки: Данная среда больше не поддерживается разработчиком.

Распространена в основном в Европейских странах и США, из-за того что разработчик (Borland) перестал поддерживать Kylix — становится всё менее популярной и не востребованной.

Netbeans — интегрированная среда разработки ПО. Была реализована на программном языке Java. Эта среда разработки высокого качества. Умеет работать на нескольких операционных системах, то есть является кроссплатформенной. Работает более чем с пятью программными языками.

Пример разработки в среде NetBeans:

Достоинства: Является бесплатной, присутствует система контроля версий, подсветка синтаксиса, возможно переименовывать переменную/класс одним кликом, в том случае если вручную переименовывать слишком долго (автоматизированное переименование), имеется возможность форматирования кода по CodeStyle, разработчиком среда постоянно совершенствуется, улучшается.

Недостатки: Временами в среде разработки возникают проблемы с кодировкой, долгий запуск программы.

Распространена во многих странах, в силу того что является удобной и бесплатной.

Eclipse — ещё одна интегрированная среда разработки ПО. Написана на языке Java в две тысячи третьем году. Также является кроссплатформенной. За счёт присоединяемых к этой среде дополнений — имеется возможность создавать программные продукты более чем на пяти языках программного кода.

Пример разработки программы в IDE Eclipse:

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

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

Распространена во многих странах, пользуется популярностью.

Поддерживает более пяти языков программирования

Источник

Интеграции бояться — в аналитики не идти

Совсем недавно рассказывала об этом на AnalystDays’13. Интерес аудитории к моему докладу сподвиг обобщить мои мысли в виде статьи.

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

Что такое интеграционное взаимодействие?

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

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

Почему это сложно?

Попытку склеить в единый процесс то, что нарабатывалось годами, усложняет ряд факторов:

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

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

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

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

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

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

Как не наступить на грабли?

Готового шаблона быть не может. От задачи к задаче процесс изменяется. Но можно дать общие рекомендации. Для этого пройдемся по основным этапам разработки интеграционного взаимодействия.

Разработка технического задания

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

Однажды на проекте в сфере здравоохранения я столкнулась с такой ситуацией.

Кейс 1. А отменить?

Одной из первых моих интеграционных задач был обмен такими сущностями, как направление на оказание медицинской помощи. Мы интегрировались через шину данных, обмениваясь данными по SOAP протоколу. Наша система была источником данных, а получателем была медицинская ИС, разработанная внешним вендором. У нас на руках был согласованный государственным заказчиком пакет документов – ТЗ, ПМИ (программа и методика испытаний). И уже на приемке под конец бизнес-тестирования, когда заветные акты о выполненных работах были близки к подписанию, вдруг возникает вопрос заказчика: ”А давайте попробуем отменить направление?”.

И тут все, мягко говоря, позеленели. Казалось бы, такой необходимый процесс – отмена направления. Но в ТЗ было сказано «Обмен направлениями» без детализации. И об отмене напрочь забыли. Естественно, приемка закончилась не так, как ожидалось.

На что обратить внимание

Чтобы не столкнуться с подобными ситуациями, уже на этапе написания ТЗ необходимо учесть следующие моменты:

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

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

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

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

Проектирование взаимодействия

В качестве следующей иллюстрации к моему рассказу вспоминается еще один пример.

Кейс 2. Когда архитектора нет

На одном из моих прошлых проектов переходили от монолита к микросервисам. Задача была непростая, а архитектора у нас не было. Его функции закрывали product owner, тимлид команды и я, как аналитик.

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

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

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

Проект был условно поделен на 3 этапа по полгода каждый. Сначала внедрили реструктурированную БД, далее частично взаимодействие между сервисами. В конце полностью перенесли основной бизнес-функционал на микросервисную архитектуру. Таким образом проект успешно был реализован, а сам переход от монолита к микросервису занял примерно 1,5 года.

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

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

Обязательные навыки системного аналитика, которые помогут решать задачи интеграции

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

понимать, что такое API;

понимать, что такое интеграционная шина данных, как она работает и как она может облегчить задачу интеграции;

понимать, как из одной системы в другую дойдет сообщение, и что при этом произойдет, а значит требуется знать, как работают очереди сообщений (сейчас это один из наиболее популярных способов взаимодействия систем);

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

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

Разработка

И вот у вас на руках готовое ТЗ, выбран паттерн, пришло время реализации.

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

Тут напрашивается еще один пример…

Кейс 3. Трудности перевода

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

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

Вот такие бывают трудности перевода.

Роль аналитика на этапе разработки

Задача системного аналитика на этапе разработки – консультирование команды. Как бы обширно и максимально подробно не была расписана постановка, у разработчика обязательно возникнут вопросы. Не прекращается общение и с бизнес-заказчиком. Изменчивый характер требований никто, увы, не отменял.

Тестирование

После разработки пришла пора тестировать. А тестировать интеграцию не менее трудно, чем ее проектировать и разрабатывать. Хочу вспомнить пример на эту тему.

Кейс 4. А ты подготовил тесты?

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

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

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

На что обратить внимание

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

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

Заранее подготовленный документ сценариев тестирования – это отличное подспорье, которое может упростить сдачу проекта. Действуйте строго в рамках согласованных сценариев тестирования и ТЗ.

Может показаться, что все мои задачи интеграции в итоге закончились сорванными сроками и полным фиаско. Конечно, это не так. В статье мне хотелось подсветить именно провальные моменты и проиллюстрировать их примерами, чтобы читатель наглядно понимал, на что обратить внимание при работе с интеграцией.

Если же говорить об успешных кейсах, то тут мне есть чем гордится. Я работала над проектированием интеграционной шины данных для региональных проектов здравоохранения, чтобы обеспечивать работу Единой Государственной Системы в сфере здравоохранения (ЕГИСЗ).

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

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

Источник