Month: October 2023

Тестування чорної скриньки

Тестування чорної скриньки базується на специфікаціях і одержує тести з зовнішньої документації щодо об’єкта тестування. Основна мета тестування чорної скриньки — перевірити поведінку системи на відповідність її специфікаціям. Тому в англомовній літературі можна зустріти термін specification-based (той що базується на специфікації), який є синонімом black-box.

Функціональне та нефункціональне

Функціональне тестування оцінює функції, які повинен виконувати компонент або система. Функції – це «те, що» повинен робити тестовий об’єкт. Основною метою функціонального тестування є перевірка функціональної повноти, функціональної правильності та функціональної відповідності.

Нефункціональне тестування оцінює атрибути, відмінні від функціональних характеристик компонента або системи. Нефункціональне тестування — це перевірка того, «наскільки добре поводиться система». Основною метою нефункціонального тестування є перевірка нефункціональних характеристик якості програмного забезпечення.

Стандарт ISO/IEC 25010 надає таку класифікацію нефункціональних характеристик якості програмного забезпечення:

• Ефективність виконання/продуктивності (Performance efficiency)
• Сумісність (Compatibility)
• Зручність використання (Usability)
• Надійність (Reliability)
• Безпека (Security)
• Зручність супроводу (Maintainability)
• Портативність (Portability)

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

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

Функціональне тестування

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

Функціональні тести слід виконувати на всіх рівнях тестування (наприклад, тести для компонентів можуть базуватися на специфікації компонентів), хоча фокус на кожному рівні різний.

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

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

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

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

Usability і функціональне

Зручність використання (Usability) є нефункціональною характеристикою. І відповідно тестування зручності використання (Usability testing) є нефункціональним типом тестування.

Однак в ряді випадків можна побачити, що до функціонального тестування відносять тестування базової зручності використання (Basic usability testing) чи тестування базового чи мінімально необхідного інтерфейсу користувача (Basic user interface testing).

Більш коректним є другий варіант (про базовий інтерфейс). Тим не менше важко провести межу між базовим інтерфейсом та зручністю використання. Низка авторів відносить тестування інтерфейсу користувача (user interface testing) до функціонального тестування. Однак під час тестування зручності використання також оцінюється робота користувацького інтерфейсу. Якщо в ході тестування нас цікавить працездатність, функціональність елементів інтерфейсу, то можна вважати таке тестування функціональним. Якщо ж нас цікавить питання оптимальності розміщення елементів інтерфейсу, їхня доступність, читабельність шрифтів тощо, то це вже парафія Usability тестування.

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

• Зрозуміти функціональні вимоги
• Визначити тестові вхідні дані
• Визначити очікувані результати
• Виконати тестові кейси
• Порівняти фактичні та очікувані результати

Класи еквівалентності

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

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

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

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

Кожне значення має належати одному й лише одному розділу еквівалентності.

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

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

Аналіз граничних значень

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

Наприклад, припустімо, що поле введення приймає одне ціле значення як вхід, використовуючи клавіатуру для обмеження введення таким чином, щоб інші варіанти були неможливі. Допустимий діапазон – від 1 до 5 включно. Отже, є три розділи еквівалентності: недійсний (занадто низький); дійсний; недійсний (занадто високий). Для дійсного розділу еквівалентності граничними значеннями є 1 і 5. Для недійсного (занадто високого) розділу граничне значення дорівнює 6. Для недійсного (занадто низького) розділу існує лише одне граничне значення, 0, оскільки це розділ лише з одним членом.

У наведеному прикладі ми визначаємо два граничні значення на межу. Межа між недійсним (занадто низьким) і дійсним дає тестові значення 0 і 1. Межа між дійсним і недійсним (занадто високим) дає тестові значення 5 і 6. Деякі варіанти цього методу визначають три граничні значення на межу: значення перед, на та безпосередньо за межею. У попередньому прикладі з використанням трьохточкових граничних значень нижні граничні тестові значення становлять 0, 1 і 2, а верхні граничні тестові значення – 4, 5 і 6.

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

Аналіз граничних значень можна застосовувати на всіх рівнях тестування. Ця техніка зазвичай використовується для перевірки вимог, які вимагають діапазону чисел (включаючи дати та час). Граничне покриття для розділу вимірюється як кількість протестованих граничних значень, поділена на загальну кількість визначених граничних тестових значень, зазвичай виражених у відсотках.

Приклад 1

В цьому прикладі у нас 5 класів еквівалентності: до 10 грамів, від 11 до 50 грамів, від 51 до 75 грамів, від 76 до 100 грамів та більше 100 грамів. Себто відповіді А та С не підходять оскільки містять лише 4 класи. Відповідь D є неправильною оскільки не тестує 5 клас. А правильна відповідь В.

Приклад 2

Правильна відповідь в даному прикладі 33501 (4000+1500+28000).

Тестування таблиці рішень

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

Загальні позначення в таблицях рішень такі:

Для умов:

• Y означає, що умова виконується (також може відображатися як T або 1)
• N означає, що умова хибна (також може відображатися як F або 0)
• — означає, що значення умови не має значення (також може відображатися як N/A)

Для дій:

• lX означає, що дія має відбутися (також може відображатися як Y, T або 1)
• Порожнє означає, що дія не повинна відбуватися (також може відображатися як – або N, або F, або 0)

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

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

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

Приклад 3

Правила роботи:

• Кредит не надається безробітним
• Кредит надається особам, які мають постійну легальну роботу без обмежень

Вікові правила:

• Особам до 18 років кредит не надається
• Цільовою групою для отримання кредиту є люди 18-40 років
• Для осіб старше 40 років кредит не надається

Правила по доходу:

• Кредит не надається людям з доходом менше 1000 доларів США на місяць
• Кредит надається особам з доходом 1000-5000 USD/місяць, сума кредиту < 2000 USD
• Кредит надається людям з доходом понад 5000 доларів США на місяць, сума кредиту > 2000 доларів США

Спробуйте визначити очікуваний результат для наступних тест кейсів:

• Student, unemployed, 17 years old, income is 100 USD/month
• Post graduate, unemployed, 25 years old, no income
• Retired, unemployed, 60 years old, income is 200 USD/month
• Manager, legally employed, 50 years old, income 1500 USD/month
• Lawyer, legally employed, 45 years old, income 5000 USD/month
• Worker, legally employed, 35 years old, income 950 USD/month
• Accountant, legally employed, 28 years old, income 2500 USD/month
• Sales manager, legally employed, 37 years old, income 4500 USD/month

Тестування переходу стану

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

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

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

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

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

Відомий приклад-ілюстрація для демонстрації переходу станів. В даному випадку для покриття всіх станів знадобиться 2 тест кейси. А для покриття всіх дійсних переходів – 4 тест кейси.

Тестування варіантів використання

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

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

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

Приклад UML діаграми та сценарію використання логіну.

В цьому відео поговоримо про функціональне тестування:
00:00:03 Тестування чорної скриньки
00:03:20 Функціональне та нефункціональне тестування
00:05:58 Функціональне тестування
00:13:19 Usability і функціональне тестування
00:19:20 Процес виконання функціонального тестування
00:19:47 Техніка розподілу на класи еквівалентності
00:23:33 Техніка аналізу граничних значень
00:46:50 Техніка тестування таблиці рішень
01:08:35 Тестування переходу стану
01:15:33 Тестування варіантів використання

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

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

Structure-based or White-box

В англомовній літературі терміни structure-based та white-box є синонімами, тому якщо зустрічаєте їх, то мова йде про тестування білої скриньки.

Тестування на основі структури або білої скриньки базується на визначеній структурі програмного забезпечення або системи і включає наступні техніки:

• Тестування операторів, заяв і покриття (Statement testing)
• Тестування рішень і покриття (Decision Tetsing)
• Тестування умов (Condition Testing)
• Тестування множинних умов (Multiple Condition Testing)
• Тестування шляхів та покриття (Path Coverage)

Тестування операторів

Тестування операторів (Statement testing) перевіряє потенційні виконувані оператори в коді.

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

Тестування рішень

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

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

Приклад 1

Нижче наводиться приклад коду і потрібно визначити скільки тестів забезпечить 100% покриття операторів (statements), а скільки відповідно – рішень (decisions).

• Disc = 0 //statement буде зображуватися у вигляді прямокутника
• Order –qty = 0 //statement буде зображуватися у вигляді прямокутника
• Read Order-qty //statement буде зображуватися у вигляді прямокутника
• If Order-qty >= 20 then //condition буде зображуватися у вигляді ромба
• Disc = 0.05 //statement буде зображуватися у вигляді прямокутника
• If Order-qty>=100 then //condition буде зображуватися у вигляді ромба
• Disc = 0.1 //statement буде зображуватися у вигляді прямокутника
• End If //закінчення блоку буде зображуватися у вигляді малого прямокутника
• End If //закінчення блоку буде зображуватися у вигляді малого прямокутника

З прикладу видно, що для покриття операторів знадобиться лише один тест кейс, який слід спроєктувати таким чином, щоб він пройшов в обох випадках по гілках true і таким чином пройшов через усі оператори (statements) в даному прикладі коду. А от для покриття рішень знадобиться 3 тест кейси: 1 тест кейс у в першій умові обере true і в другій умові також true, 2 тест кейс у в першій умові обере true, а в другій умові обере false, 1 тест кейс у в першій умові обере false. Таким чином будуть виконані всі гілки, тобто рішення в даному прикладі.

Приклад 2

Нижче наводиться приклад коду і аналогічно до попереднього прикладу потрібно визначити скільки тестів забезпечить 100% покриття операторів (statements), а скільки відповідно – рішень (decisions).

• Ask: “What type of ticket do you require, single or return?” //statement буде зображуватися у вигляді прямокутника
• If the customer wants ‘return’ //condition буде зображуватися у вигляді ромба
• Ask: “What rate, Standard or Cheap-day”? //statement буде зображуватися у вигляді прямокутника
• If the customer replies ‘Cheap-day’ //condition буде зображуватися у вигляді ромба
• Say: “That will be $11.20” //statement буде зображуватися у вигляді прямокутника
• Else // блок else для найближчого if означає, що гілка false матиме вміст
• Say: “That will be $19.50” //statement буде зображуватися у вигляді прямокутника
• Endif //закінчення блоку буде зображуватися у вигляді малого прямокутника
• Say: ”That will be $9.75” //statement буде зображуватися у вигляді прямокутника
• Endif //закінчення блоку буде зображуватися у вигляді малого прямокутника

З прикладу видно що для покриття операторів і рішень знадобиться однакова кількість тест кейсів, а саме три. Це особливий випадок, оскільки частіше для покриття операторів потрібно менше тест кейсів ніж для покриття рішень. Для того, щою пройти через усі оператори доведеться спроєктувати три тест кейси: 1 тест кейс в першій умові пройде по гілці true і у вкладеній умові обере також true, 2 тест кейс в першій умові пройде по гілці true, а у вкладеній умові обере false, 3 тест кейс в першій умові піде по гілці false. Це забезпечить також і покриття рішень.

Приклад 3

Нижче наводиться приклад коду і знову потрібно визначити скільки тестів забезпечить 100% покриття операторів (statements), а скільки відповідно – рішень (decisions).

• If width>length //condition буде зображуватися у вигляді ромба
• Then biggest_dimension=width //statement буде зображуватися у вигляді прямокутника
• If height>width //condition буде зображуватися у вигляді ромба
• Then biggest_dimension=height //statement буде зображуватися у вигляді прямокутника
• End_if //закінчення блоку буде зображуватися у вигляді малого прямокутника
• Else biggest_dimension=length //statement буде зображуватися у вигляді прямокутника
• If height>length //condition буде зображуватися у вигляді ромба
• Then biggest_dimension=height //statement буде зображуватися у вигляді прямокутника
• End_if //закінчення блоку буде зображуватися у вигляді малого прямокутника
• End_if //закінчення блоку буде зображуватися у вигляді малого прямокутника

В цьому прикладі для покриття операторів знадобиться 2 тест кейси: 1 тест кейс пройде по гілці true у першій умові і далі у вкладеній умові обере також true, 2 тест кейс пройде по гілці false першої умови і далі у вкладеній умові обере true. Таким чином будуть виконані всі оператори statements. А от для покриття рішень знадобиться всього 4 тест кейси, оскільки потрібно покрити гілки false у вкладених умовах.

Цикломатична складність Маккейба

Цикломатична складність Маккейба — це максимальна кількість лінійних незалежних шляхів у програмі. Формула цикломатичної складності:

M = L – N + 2*P

Де L – кількість ребер/ланок у графі, N – кількість вузлів у графі, P – кількість з’єднаних компонентів.

Наведемо приколад розрахунку цього показника за допомогою зразка коду нижче.

• IF A=575 //condition буде зображуватися у вигляді ромба
• THEN IF B>C //condition буде зображуватися у вигляді ромба
• THEN A=B //statement буде зображуватися у вигляді прямокутника
• ELSE A=C //statement буде зображуватися у вигляді прямокутника
• ENDIF //закінчення блоку буде зображуватися у вигляді малого прямокутника
• ENDIF //закінчення блоку буде зображуватися у вигляді малого прямокутника
• Print A //statement буде зображуватися у вигляді прямокутника

Потік керування показує сім вузлів (фігур) і вісім ребер (лінії), таким чином, використовуючи формальну формулу, цикломатична складність становить 8-7 + 2*1=3.

Цінність White Box

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

Методи білого ящика можна використовувати у статичному тестуванні (наприклад, під час пробних прогонів). Вони добре підходять для перегляду коду, який ще не готовий до виконання (Hetzel 1988), а також псевдокоду та іншої логіки високого рівня або низхідної логіки, яку можна моделювати за допомогою графа потоку керування.

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

Коли досягнуто 100% охоплення операторів (statements), це гарантує, що всі виконувані оператори в коді були протестовані принаймні один раз, але це не гарантує, що перевірено всю логіку прийняття рішень. З двох методів білої скриньки, які розглядалися, тестування операторів може забезпечити менше покриття, ніж тестування рішень.

Коли досягнуто 100% покриття рішень, то виконуються всі результати рішення, що включає перевірку справжнього результату, а також хибного результату, навіть якщо немає явного хибного оператора (наприклад, у випадку оператора IF без else в коді).

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

Досягнення 100% покриття рішень гарантує 100% покриття заяв (але не навпаки).

В цьому відео поговоримо про тестування білої скриньки:
00:05 Тестування білої скриньки
10:22 Structure-based or White-box
16:42 Тестування операторів (Statement Testing)
17:28 Тестування рішень (Decision testing)
18:52 Приклад 1 Statement and Decision Testing
26:38 Приклад 2 Statement and Decision Testing
34:51 Приклад 3 Statement and Decision Testing
43:00 Цикломатична складність Маккейба
48:20 Цінність White Box

Загалом можна виділити дві великі групи технік статичного тестування – це перевірки або перегляди (Reviews) та статичний аналіз.

Процес перевірки документації

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

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

Стандарт ISO (ISO/IEC 20246) містить більш поглиблений опис процесу перевірки робочих продуктів, включаючи ролі та методи перевірки.

Процес перевірки (reviews) включає такі основні дії:

• Планування
• Початок перегляду
• Індивідуальна підготовка
• Комунікація проблем та аналіз
• Виправлення та звітування

Планування

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

Початок перегляду

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

Індивідуальна підготовка

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

Комунікація проблем та аналіз

• Повідомлення про виявлені потенційні дефекти (наприклад, на оглядовій зустрічі)
• Аналіз потенційних дефектів, визначення права власності та статусу
• Оцінка та документування характеристик якості
• Оцінка результатів перевірки за критеріями виходу для прийняття рішення про перевірку (відхилити; необхідні значні зміни; прийняти, можливо, з незначними змінами)

Виправлення та звітування

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

Ролі у формальній перевірці

Типов формальна перевірка (formal review) документаці включатиме такі ролі:

• Автор (Author)
• Менеджмент (Management)
• Модератор (Moderator)
• Керівник (лідер) перевірки (Review leader)
• Рецензенти (Reviewers)
• Секретар (Scribe)

Автор

• Створює робочий продукт, що перевіряється
• Виправляє дефекти робочого продукту, що перевіряється (при необхідності)

Менеджмент

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

Модератор

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

Керівник (лідер) перевірки

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

Рецензенти

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

Секретар

• Зіставляє потенційні дефекти, виявлені під час індивідуальної перевірки
• Записує нові потенційні дефекти, відкриті питання та рішення наради з перегляду (якщо вона проводиться)

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

Типи перевірок документації

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

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

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

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

Неформальна перевірка (informal review, e.g., buddy check, pairing, pair review)

• Основне призначення: виявлення потенційних дефектів
• Можливі додаткові цілі: генерація нових ідей або рішень, швидке вирішення незначних проблем
• Не базується на офіційному (задокументованому) процесі
• Може не включати нараду з перевірки (review meeting)
• Може виконуватись колегою автора (buddy check) або кількома людьми
• Результати можуть бути задокументовані
• Корисність залежить від рецензентів
• Використання контрольних списків необов’язкове
• Дуже часто використовується в гнучкій розробці

Наскрізне проходження (Walkthrough)

• Основні цілі: виявлення дефектів, вдосконалення програмного продукту, розгляд альтернативних реалізацій, оцінка відповідності стандартам і специфікаціям
• Можливі додаткові цілі: обмін ідеями щодо технік чи варіацій стилю, навчання учасників, досягнення консенсусу
• Індивідуальна підготовка перед нарадою з перевірки (review meeting) необов’язкова
• Нараду з перевірки (review meeting) зазвичай проводить автор робочого продукту
• Секретар обов’язковий
• Використання контрольних списків необов’язкове
• Може мати форму сценаріїв, пробних прогонів або моделювання
• Створюються журнали потенційних дефектів і звіти про перевірку
• На практиці може варіюватися від досить неформального до дуже офіційного

Технічний огляд (Technical review)

• Основні цілі: досягнення консенсусу, виявлення потенційних дефектів
• Можливі додаткові цілі: оцінка якості та зміцнення довіри до робочого продукту, генерація нових ідей, мотивація та надання можливості авторам покращувати майбутні робочі продукти, розгляд альтернативних реалізацій
• Рецензенти мають бути технічними колегами автора та технічними експертами в тій самій чи інших дисциплінах
• Необхідна індивідуальна підготовка перед оглядовою зустріччю
• Нарада з перевірки (review meeting) є необов’язковою, в ідеалі її проводить навчений модератор (зазвичай не автор)
• Секретар обов’язковий, в ідеалі не автор
• Використання контрольних списків необов’язкове
• Створюються журнали потенційних дефектів і звіти про перевірку

Інспекція (Inspection)

• Основні цілі: виявлення потенційних дефектів, оцінка якості та формування довіри до робочого продукту, запобігання майбутнім подібним дефектам шляхом навчання автора та аналізу першопричини
• Можливі подальші цілі: мотивація та надання можливості авторам покращувати майбутні робочі продукти та процес розробки програмного забезпечення, досягнення консенсусу
• Дотримується визначеного процесу з офіційно задокументованими результатами на основі правил і контрольних списків
• Використовує чітко визначені ролі та може включати спеціального читача (який читає продукт роботи вголос, часто перефразовуючи, тобто описуючи його своїми словами, під час оглядової зустрічі)
• Необхідна індивідуальна підготовка перед оглядовою зустріччю
• Рецензенти є або колегами автора, або експертами в інших дисциплінах, які стосуються робочого продукту
• Використовуються визначені критерії входу та виходу
• Секретар обов’язковий
• Оглядову зустріч проводить навчений модератор (не автор)
• Автор не може виступати в ролі керівника перевірки, читача чи секретаря
• Створюються журнали потенційних дефектів і звіт про перевірку
• Показники збираються та використовуються для вдосконалення всього процесу розробки програмного забезпечення, включаючи процес перевірки

Техніки перевірок документації

lІснує ряд методів перевірки, які можна застосувати під час індивідуальної підготовки для виявлення дефектів. Ці методи можна використовувати в описаних вище типах перевірок. Ефективність методів може відрізнятися залежно від типу огляду, який використовується. Серед методів перевірок документації виділяють:

• Ad hoc
• На основі контрольного списку
• Сценарії та пробні прогони
• На основі переспективи (поглядів)
• На основі ролей (рольовий)

Ad hoc

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

Контрольний список

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

Сценарії та пробні прогони

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

На основі перспективи

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

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

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

Рольовий

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

Фактори успіху перевірок

Для успішної перевірки необхідно розглянути відповідний тип огляду та використані методи. Крім того, існує низка інших факторів, які впливатимуть на результат перевірки.

Організаційні фактори успіху для оглядів включають:

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

Пов’язані з людьми фактори успіху перевірок включають:

• Для досягнення цілей рецензування залучаються потрібні люди, наприклад, люди з різними навичками або перспективами
• Тестувальники вважаються цінними рецензентами, які роблять внесок у рецензування та дізнаються про робочий продукт, що дає їм змогу готувати більш ефективні тести та готувати ці тести раніше
• Учасники приділяють достатньо часу та уваги до деталей
• Огляди проводяться невеликими частинами, щоб рецензенти не втрачали концентрації під час індивідуального огляду або зустрічі з перевірки (якщо вона проводиться)
• Виявлені дефекти визнаються, оцінюються та розглядаються об’єктивно
• Зустріч добре організована
• Перевірка проводиться в атмосфері довіри; результат не використовуватиметься для оцінки учасників
• Учасники уникають мови тіла та поведінки, які можуть вказувати на нудьгу, роздратування або ворожість до інших учасників
• Забезпечується адекватне навчання, особливо для більш формальних видів перевірок
• Пропагується культура навчання та вдосконалення процесу

Статичний аналіз

Метою статичного аналізу є пошук дефектів у вихідному коді програмного забезпечення та моделях програмного забезпечення.

Потік керування (Control flow) — це послідовність подій (шляхів) після запуску компонента або системи на виконання.

Потік даних (Data flow) — це абстрактне представлення послідовності та можливих змін стану об’єктів даних: створення, використання або видалення.

Метрики коду

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

• Частота коментарів
• Глибина вкладення
• Цикломатичне число
• Кількість рядків коду

Показники складності ідентифікують зони з високим ризиком і складність.

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

Цінність статичного аналізу

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

Типові дефекти

• Типові дефекти, виявлені інструментами статичного аналізу:
• Посилання на змінну з невизначеним значенням
• Непослідовні інтерфейси між модулями та компонентами
• Змінні, які не використовуються або оголошені неправильно
• Недосяжний (мертвий) код
• Відсутня та помилкова логіка (потенційно нескінченні цикли)
• Надто складні конструкції
• Порушення стандартів програмування
• Вразливі місця безпеки
• Порушення синтаксису коду та моделей програмного забезпечення

Інструменти статичного аналізу

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

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

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

Інструменти статичного аналізу: CodeScene, Parasoft, Code Compare, Sourcemeter, Understand.

В цьому відео поговоримо про техніки статичного тестування:
00:06 Статичне тестування
00:46 Процес перевірки документації
08:30 Ролі у формальній перевірці
12:25 Типи перевірок документації
14:02 Неформальна перевірка
15:16 Наскрізне проходження
17:31 Технічна перевірка
20:03 Інспекція
23:44 Техніки перевірок документації
24:39 Ad hoc
26:06 Контрольний список
27:59 Сценарії та пробні прогони
30:25 На основі перспективи
33:52 Рольовий
36:11 Фактори успіху перевірок
40:09 Статичний аналіз
41:06 Метрики коду
42:01 Цінність статичного аналізу
42:39 Типові дефекти, які виявляються статичним аналізом
43:45 Інструменти статичного аналізу