Главная Партнеры Контакты  
Юридическая компания — «Основной закон», консультации и помощь в возвращении депозитов, защита по кредиту

ЮК
"ОСНОВНОЙ ЗАКОН"  

г. Киев, бул. Пушкина, 2а                
тел.: (044) 334-99-77                               
         (095) 407-407-3
         (096) 703-11-82

график работы: пн.- пт. с 9:00 до 18:00
          
                           

 












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


Держреєстрація речових прав на нерухоме майно та їх обтяжень у 2014 році буде здійснюватись за новою - удосконаленою та спрощеною - процедурою.
Постанова Кабінету Міністрів "Про затвердження порядку державної реєстрації прав на нерухоме майно та їх обтяжень і Порядку надання інформації з Держа...




Система Orphus


Безперервна інтеграція і функціональне тестування: два ключові чинники розробки якісної інформаційної системи

Cnews - 14 липня 2011 року - Владислав Жидков, Дмитро Змітраченок, Ольга Полстюк, EPAM

Застосування методики безперервної інтеграції в рамках розробки ПО дозволяє автоматизувати етапи створення, збирання та встановлення програмного коду. Завдяки цьому можна постійно контролювати його якість, вже на ранніх етапах створення ІТ-системи виявляти помилки і швидко усувати їх. Подальше функціональне тестування забезпечить ретельну перевірку готового рішення і зробить ПО максимально відповідним вимогам замовника. В кінцевому підсумку це гарантує високу якість і надійність інформаційної системи.

Бізнес багатьох сучасних компаній досить сильно залежить від роботи інформаційних систем, які застосовуються для обслуговування клієнтів, підтримки роботи бек-офісу, ведення управлінського обліку і ряду інших завдань. Прикрі помилки в ІТ-додатках або некоректне виконання функцій може привести до фінансових або репутаційних втрат. Так, в березні 2011 року технологічний збій в ІТ-рішення порушив роботу практично всіх відділень і банкоматів банку ВТБ24, а двома роками раніше через неполадки в комп'ютерній системі була паралізована діяльність майже третини московських філій Ощадбанку. Які кроки потрібно зробити, щоб знизити ризики появи подібного роду проблем при використанні інформаційних систем?

Один з можливих варіантів - застосувати комбінований підхід: використовувати методологію безперервної інтеграції (continuous integration, CI) при розробці ІТ-рішення в поєднанні з традиційними інструментами функціонального тестування.

Як правило, при розробці інформаційної системи програмний код пишуть різні групи фахівців. Потім ці частини збираються в більш великі модулі, які в свою чергу об'єднуються в систему і далі тестуються. Однак процес складання починається тільки тоді, коли модулі практично повністю готові. Відповідно, якщо на цьому етапі в коді виявляються помилки або виникають проблеми з взаємодією окремих компонентів, переписувати доводиться дуже багато.

Навпаки, практика безперервної інтеграції передбачає, що збірка коду починає проводитися якомога раніше і повторюється якомога частіше (як мінімум - при появі кожної нової частини коду). Чому такий варіант ефективніше? Тут з'являється можливість знайти помилки або протиріччя в різних компонентах ще на ранніх стадіях створення інформаційної системи. А чим раніше виявляється помилка, тим легше і швидше її можна виправити. В результаті знижуються ризики затягування термінів розробки рішення і забезпечується висока якість програмного коду.

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

Тим самим поєднання практики CI (при створенні інформаційної системи) і функціонального тестування дає впевненість в якості інформаційної системи, дозволяє однозначно підтвердити, що всі вимоги замовника були реалізовані, система їм повністю відповідає і не має помилок у програмному коді.

Як побудувати процес безперервної інтеграції?

У практиці безперервної інтеграції можна виділити кілька основних етапів розробки ІТ-рішення: створення різних частин вихідного програмного коду, їх збірка (компіляція і компонування), оформлення в інсталяційний пакет, установка на сервер і підготовка до тестування.

Етапи процесу безперервної інтеграції

Етапи процесу безперервної інтеграції

Створення вихідного коду

Програмний код майбутньої інформаційної системи може створюватися кількома групами фахівців, причому перебувати вони можуть в різних офісах компанії-розробника. Для підвищення якості та ефективності спільної роботи над кодом часто використовуються спеціальні ІТ-рішення - системи контролю версій (Version Control System, VCS). До числа найбільш поширених з них належать open source-додатки Subversion (SVN) і Git. Подібні системи дозволяють програмістам складати код, реалізуючи новий функціонал, і при цьому не заважати один одному. Крім того, завжди є можливість подивитися і проаналізувати історію коду, в будь-який момент повернутися до попереднього вдалому варіанту.

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

Життєвий цикл гілки коду

Щоб отримати готове рішення, потрібно зібрати різні частини програмного коду. Це можна виконати вручну, що добре для невеликої програми, хоча і не завжди. Але краще це зробити автоматично.

Компіляція і компоновка

Команда програмістів, як правило, одночасно веде відразу кілька потоків розробки, періодично змінюючи або навіть видаляючи їх. З точки зору ефективності для об'єднання результатів роботи програмістів раціонально застосовувати спеціальний інструмент - планувальник, який дозволить створювати, зберігати і автоматично запускати завдання по складанню програмного коду. Як приклад планувальників можна привести рішення CruiseControl, TeamCity, Hudson (і його спадкоємець Jenkins) та інші.

В рамках виконання кожної такого роду завдання планувальник із заданою періодичністю (наприклад, за правилом «поява нового зміни» або в строго певний час) отримує частини коду з потрібних гілок сховища та запускає їх складання так, як це було попереднього налаштоване білд-інженером. Найчастіше такі завдання однотипні, так що немає нічого складного в тому, щоб їх автоматично створювати за певним шаблоном.

Під час складання коду (компіляції і компоновки) паралельно може бути запущено і юніт-тестування (unit tests): виклик частини коду з певними параметрами, який повинен привести до строго визначеного результату. Це дозволить перевірити код ще до його включення в кінцеву програму (систему), подивитися, чи викликають тести все рядки коду, перевірити його на логічні помилки і т.д. Тим самим з'являється можливість виявити дефекти, які є в вихідному коді і які виникають при взаємодії компонентів програми, а також перевірити, як були виправлені знайдені помилки.

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

При виявленні помилки у розробника є можливість відразу ж внести виправлення, при цьому всі зміни будуть автоматично збережені в репозиторії. Тоді планувальник, отримавши сигнал, що код був трансформований, автоматично ініціює нову ітерацію збірки, і всі операції будуть повторені. У цьому полягає одна з головних переваг підходу безперервної інтеграції - все зміни програмного коду фіксуються, після кожного з них рішення автоматично збирається заново і ще раз перевіряється. В результаті серйозно знижуються ризики виникнення в майбутньому будь-яких помилок в роботі створеної ІТ-системи.

Крім того, це дозволяє уникнути затримок в роботі в тому випадку, якщо в проекті беруть участь команди, які знаходяться в різних регіонах і часових поясах і працюють позмінно. Без використання CI програміст, написавши свою частину коду і не отримавши підтвердження (нотифікації) по електронній пошті про відсутність помилок, спокійно йде додому. Але його колеги, які в цей момент в іншому регіоні тільки починають свій робочий день, будуть змушені витратити свій час на виявлення дефектів і їх виправлення. Терміни розробки системи збільшаться. У разі коли розробка ведеться в рамках безперервної інтеграції, подібні ситуації виключені.

На деяких проектах іноді додатково застосовується так званий «аналіз коду» (code review). Його сенс полягає в тому, що програміст, закінчивши розробку частини функціоналу, яку він хоче включити в загальний потік розробки, спочатку передає її для аналізу своєму колезі, який спеціалізується в тій же або суміжній галузі. Такий погляд з боку часто дозволяє швидко знайти потенційні проблеми, а іноді і способи їх вирішення. Незайвим може бути і застосування інструментів статистичного аналізу коду (PMD, FindBugs) - вони допомагають автоматично виявити стандартні і найбільш поширені помилки, які можуть допускатися розробниками.

Крім того, на даному етапі перевіряється стилістика коду: його відповідність тим правилам оформлення і формату, які діють на проекті. Це дозволяє зробити код «читабельним», що значно полегшує подальшу роботу з ним. Подібне тестування проводиться в автоматичному режимі (наприклад, з використанням програми Checkstyle). Частково помилки виправляються також автоматично, але іноді це доводиться робити вручну (визначаються конкретні рядки коду, де були зроблені помилки, і далі вносяться виправлення). Варто зауважити, що провести подібну перевірку можна тільки в рамках практики continuous integration. В інших випадках, коли тестування піддаються вже готові системи, QA-фахівці фокусуються на приведення коду у відповідність до вимог замовника і не дивляться, написаний він в єдиному стилі чи ні.

В результаті після закінчення етапу у проектної команди з'являється готова програма, яка за своєю структурою, покриттю юніт-тестами, документованості і іншим параметрам повністю відповідає ключовим стандартам якості.

Підготовка інсталяційного пакета

Скомпільований код повинен бути запакований відповідним чином: це може бути zip-архів, установча програма Windows або пакет для Unix / Linux дистрибутива. Для зберігання готового пакета найчастіше використовується файл-сервер (FTP, NFS, загальна папка в мережі і т.д.), який може бути як локальним (розміщений в компанії-розробника системи), так і віддаленим (наприклад, розташовуватися у замовника) .

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

У будь-якому випадку кращою практикою буде зберігання відразу декількох версій готової програми або її модулів (в цьому випадку зазвичай номер версії включається в назву пакета або в назву папки на файл-сервері, де зберігається цей пакет).

Автоматична установка і підготовка до тестування

Хорошим тоном при розробці програми вважається передбачити в ній варіант так званої «безшумною» (silent) установки, коли система ставиться на комп'ютер або сервер, не вимагаючи будь-яких дій від ІТ-фахівців (без спливаючих вікон і запитів). При цьому вона може використовувати як задані розробником параметри «за замовчуванням», так і файл, наданий замовником, з аналогічними параметрами, але вже спеціально підібраними під конкретну ІТ-середовище компанії. Штатні пакети для Unix / Linux- систем мають таку можливість за визначенням. Все це дозволяє автоматизувати установку рішень, знизити вплив людського фактора на цей процес і істотно заощадити час.

Для автоматичної установки готового рішення на сервер або групу серверів, де потім буде проводитися його тестування, може також використовуватися планувальник. Він відстежить факт приміщення рішення в сховище і запустить процес його установки. Останнім часом у зв'язку з широкою популярністю віртуалізації і обчислювальних «хмар» поширена практика, коли програма ставиться на спеціально створену віртуальну машину. І, що важливо, цей віртуальний сервер теж може бути створений автоматично - за допомогою планувальника. Наприклад, цей процес можна прив'язати до запуску завдання по складанню коду, який регулюється планувальником. Тоді від попадання програми в репозиторій до її установки на сервер для подальшого тестування будуть проходити лічені хвилини.

Окремо варто згадати про один з перспективних напрямків розвитку практики continuous integration, коли весь процес повністю - від написання коду до запуску готового рішення в експлуатацію - вибудовується як «хмарний» сервіс. Замовник позначає свої вимоги - і після завершення проекту отримує готову систему. Всі питання, пов'язані з термінами і ризиками розробки та підтримки рішення, випуску релізів, регулюються за допомогою укладення SLA (Service Level Agreement - угода про рівень послуг) між виконавцем і замовником. Наприклад, SLA допомагає знизити залежність успішного проведення розробки і тестування від конкретних фахівців, які керують процесом безперервної інтеграції. Навіть в разі їх тимчасової відсутності на проекті буде забезпечено виконання всіх запланованих операція точно у встановлені терміни.

Отже, програмний код скомпільовано, запакований і встановлений. Що далі? Функціональне тестування.

Як провести функціональне тестування?

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

аналіз вимог

Практика показує, що чим раніше фахівець з тестування підключається до процесу розробки ІТ-системи, тим швидше досягається необхідна якість цього рішення і тим менше витрат вимагає його створення. Ще перед початком розробки команда тестування аналізує вимоги, які були сформульовані замовником: виявляються протиріччя, уточнюються неясні моменти, додаються відсутні, але явно необхідні вимоги. Як правило, при цьому тестувальники працюють в тісній взаємодії з бізнес-аналітиками та розробниками, задіяними в проекті. Крім того, на цьому ж етапі оцінюється тестованих вимог (чи можна в принципі буде перевірити їх виконання), що важливо для успішного проведення наступних етапів.

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

Розробка функціональних тест-кейсів

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

Ступінь деталізації тест-кейсів залежить від життєвого циклу і потреб проекту. На даному етапі часто залучаються бізнес-аналітики: їх участь допомагає забезпечити більш точне і повне покриття тестами різних сценаріїв майбутнього використання інформаційної системи.

Проведення автоматизованого функціонального тестування

Після того, як готовий програмний код був зібраний і встановлений на сервер, починається наступний етап функціонального тестування - запуск автоматизованих тестів. На відміну від юніт тестів, які застосовувалися після складання коду для перевірки його працездатності, ці тести використовуються для автоматичної перевірки функціоналу та інтерфейсів ІТ-системи.

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

Надалі результати автоматизованих тестів аналізуються, визначаються дефекти, які призвели до отримання негативних результатів. Якщо в проекті використовується гнучка модель розробки програмного забезпечення, то знайдені помилки негайно усуваються, і процес тестування запускається знову. В інших випадках дефекти реєструються в системі для фіксації помилок (bag tracking system) і виправляються після завершення всього тестування.

Ручне функціональне тестування

Обсяг ручного тестування багато в чому залежить від того, з яким ступенем деталізації і повноти автоматичні тести охопили функціональність створюваної ІТ-системи. Якщо вони були опрацьовані недостатньо детально, то спочатку в ручному режимі проводиться перевірка працездатності всіх компонентів рішення - за допомогою «тестування на дим» (Smoke-тести). Потім знайдені дефекти виправляються і перевіряються ще раз - на предмет відповідності тим вимогам, які були сформульовані спочатку. За розробленим функціональним тест-кейсів прогоняются основні сценарії використання майбутньої системи.

Однак при наявності досить повних і докладних автоматизованих тестів ці етапи, як правило, опускаються. У такій ситуації завдання функціонального тестування можна позначити так: з максимальною широтою охопити можливі бізнес-сценарії використання програми, а також протестувати логіку взаємодії продукту зі сторонніми компонентами.

Аналіз результатів тестування і зворотний зв'язок із замовником

Дані, отримані за підсумками автоматизованого і ручного тестування, обробляються і аналізуються. Потім приймається рішення або про необхідність доопрацювання програмного коду (і тоді процес розробки і безперервної інтеграції запускається знову), або про передачу ІТ-системи замовнику.

Підведення підсумків

На фінальному етапі - після завершення розробки і тестування інформаційної системи - виникає необхідність видалити «залишки виробництва»: прибрати з планувальника завдання по складанню, стерти непотрібні установчі пакети, звільнити вже не експлуатованих віртуальну машину і т.д. Для зручності і зниження витрат ці операції можуть виконуватися автоматично.

Варто відзначити, що одна з переваг використання практики безперервної інтеграції полягає в тому, що протягом усього процесу розробки на одному з серверів завжди присутній найсвіжіша робоча версія створюваної системи. Причому, як показує практичний досвід, це програмний код такої якості, роботу якого можна в будь-який момент часу продемонструвати замовникові (так званий production quality code). В результаті є можливість показати готові або готуються компоненти ІТ-додатки клієнту і отримати від нього зворотний зв'язок - відгуки, які допоможуть швидко внести в код необхідні зміни.

При застосуванні методики безперервної інтеграції (в рамках розробки програмного забезпечення) в поєднанні з традиційними інструментами функціонального тестування з'являється можливість автоматизувати етапи складання, установки і тестування програмного коду. Це допомагає постійно контролювати якість коду, вже на ранніх етапах створення ІТ-системи виявляти помилки і швидко усувати їх. Глибока опрацювання функціональних вимог, розробка детальних і повних тест-кейсів, використання різних засобів ручного та автоматичного тестування забезпечує ретельну перевірку готового рішення.

В кінцевому підсумку це дозволяє забезпечити максимально високу якість і надійність інформаційної системи і її відповідність очікуванням замовника.

оригінал Публікації

Які кроки потрібно зробити, щоб знизити ризики появи подібного роду проблем при використанні інформаційних систем?
Чому такий варіант ефективніше?
Як побудувати процес безперервної інтеграції?
Що далі?
Як провести функціональне тестування?
Главная Партнеры Контакты    
Cистема управления сайта от студии «АртДизайн»