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

Як виміряти коробку

Чи потрібно вимірювати?

Вся метрика тестування - це лише марна трата часу та енергії. За цей час ми можемо проаналізувати продукт, знайти баги, написати автоматизовані тести тощо.

Але все ж таки, яке “магічне” значення має метрика тестового покриття, на яку тестувальники іноді витрачають величезну кількість свого робочого часу?

• Пошук “мертвих” зон. Звичайно, кожен хоче знати, в якій частині програмного забезпечення є проблеми;
• За результатами тестування ми рідко отримуємо 100% ефективність розробки. Але що тоді “виправляти” і що покращувати? Який підхід кращий? Наскільки підвищився рівень ефективності? Як скоро нам скажуть про 100%? Всі ці висновки так чи інакше пов’язані з чіткістю та зрозумілістю процесу тестування, а відповіді на них приховані в забезпеченні якості;
• Звертаємо увагу. Уявімо, що ваша збірка має близько 40 функціональних рівнів. Коли виходить нова версія, ви починаєте потихеньку тестувати перший і одразу ж знаходите в ньому баги, зміщені пікселі та інші дивні речі. Час на тестування пройшов, цей функціонал ретельно перевірений, але що робити з рештою 40? І саме оцінка повного покриття допомагає нам повністю розставити пріоритети між завданнями в залежності від обсягу роботи та часу, визначеного клієнтом.

Логіка тестового висвітлення

Як правильно вимірювати?

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

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

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

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

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

Найпопулярнішими є наступні інструменти:

• Покриття “Бичаче око“;
• AQTime;
• Прикриття;
• Компілятор Intel;
• Шашка для перевірки кордонів.

Завдяки аналізу покриття коду ми можемо повністю створити “товсту” базу автоматизованих тестів для тестування програмних компонентів, яка передається в QA відділ для ретельного аналізу та тестування. Створюючи базу автоматизованих тестів, ми можемо точно виміряти товщину покриття виконуваного коду утиліти, що тестується (це відповідь на питання - який обсяг тестування я виконую автоматизованим тестуванням).

Процес висвітлення тесту

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

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

Тестове покриття коду - це робота, яка чітко показує, який відсоток написаного програмного коду був протестований.

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

Типи вимірювання тестового покриття продукту

На сьогоднішній день існує декілька типів вимірювання тестового покриття, і основні з них такі:

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

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

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

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

Реалізація

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

Такий звіт дозволяє проводити повністю якісний аналіз, щоб з’ясувати, чи є в продукті невиконані частини коду. Якщо такі є, то покриття тестів розширюється і все письмове тестування виконується вдруге.

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

Межа покриття написаного коду тестами виражається у співвідношенні готової та протестованої функціональності.

Наприклад, “ми провели тестування 60% коду”. Сенс такого виразу полягає в тому, яким чином був використаний критерій забезпечення якості продукту. Наприклад, 60% тестування шляхів буде краще, ніж 60% роботи операторів.

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

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

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

Парасольки

Контрольне тестування

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

Основою для такого підходу є розробка діаграм потоків управління, яка складається з таких частин:

• Блок робіт - 1 точка входу та 1 точка виходу;
• Альтернативна точка - 1 точка виходу і більше двох точок виходу;
• Точка злиття - 2 і більше точок входу, 1 точка виходу.

Для того, щоб виконати тестування потоків управління, QA використовують наступні рівні тестованого покриття:

Працюючи з такою таблицею (методом), ви, як QA, можете якісно спланувати свій майбутній рівень тестового покриття.

Отже, завершуючи аналіз “ідеального” тестового покриття, ми можемо виділити аспекти, на які завжди слід звертати увагу:

• Загальна функціональність;
• Юзабіліті;
• Технічна безпека;
• Надійність;
• Акомпанемент.

Звісно, кожен згаданий критерій має низку додаткових пунктів та підпунктів. І ми можемо додати до цього переліку різноманітні характеристики та досягнення, які були враховані у вашому проекті.

Кожна розробка є унікальною і потребує повного індивідуального підходу до процесу створення повного тестового покриття. І все ж не існує універсального посібника з розробки багатофункціонального тестового покриття.

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