Ієрархія й відповідність між критеріями інтеграційного тестування

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

Представлені критерії не є повністю незалежними, вони можуть бути зв'язані в ієрархічну структуру, представлену на Рис. 3.

Рис. 3. Ієрархія зв'язків між запропонованими критеріями.

Тема 6. Регресивне тестування

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

Регресивне тестування включає:

new bug-fix – перевірка виправлення знайдених дефектів;

old bug-fix – перевірка, що виявлені раніше й виправлені дефекти не відтворюються в системі знову;

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

Зазвичай вживані методи регресивного тестування включають повторні прогони попередніх тестів, а також перевірки, чи не потрапили регресивні помилки в чергову версію внаслідок злиття коду.

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

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

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

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

Фундаментальна проблема супроводу програм полягає в тому, що виправлення однієї помилки з великою ймовірністю (20-50%) спричиняє появу нової. Тому весь процес йде за принципом «два кроки вперед, один крок назад».

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

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

Багтрекери

Багтрекер – прикладне ПЗ, призначене, щоб допомогти тестерам та програмістам відстежувати історію звітів про баги під час своєї роботи.

Багато багтрекерів, зокрема, використовувані більшістю open source software проектів, дозволяють користувачам вводити звіт про помилку безпосередньо. Інші системи використовуються лише всередині компаній чи організацій, що займаються розробкою ПЗ. Здебільшого багтрекери постачаються з іншими програмами керування проектами програмного забезпечення. Наявність багтрекера вкрай важлива у розробці ПЗ, і його використання вважається однією з «ознак хорошої команди програмістів».

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

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

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

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

Локальний багтрекер – звичайно комп'ютерна програма, використовувана командою професійних підтримувачів додатку (часто служба технічної підтримки) для відстежування розробниками програмного забезпечення. Використання локальних БТ дозволяє спеціалістам зі служби підтримки відстежувати баги на «своїй власній мові», а не на «мові розробників.» Крім того, використання локальних БТ дозволяє команді підтримки відстежувати інформацію про користувачів, що висловили скарги, неважливі для процесу розробки.

Деякі багтрекери розроблено для роботи з програмами розподіленого контролю версій. Ці розподілені багтрекери дозволяють легко читати, додаватити до бази даних чи оновлювати звіти про помилки, поки розробник не в мережі. Останнім часом комерційні багтрекери також почали об'єднуватись з розподіленим контролем версій.