Модулі користувача

Якщо вони не автоматизовані, звичайно, що розробник здійснює їх відразу після розробки функції (до commitem в репозиторій). Запис про те, як виконувався тест Unit, не мав би сенсу і непомірно обтяжував би роботу. Але пам'ятайте, що якщо розробка відбувається відповідно до стандартів, таких як ASPICE, то документація unit-тестів є обов'язковою.

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

Як уніфікувати тести для документування

Для тестів повинна бути методика, яку потрібно перевірити тестом. Тестер підтверджує дотримання.

Приклад unit-тестів для програмного забезпечення:
Стандарти вимагають статичної перевірки коду. Це включає в себе

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

Приклад обладнання (електроніки):

Перевірка всіх сигнальних шляхів
Аналіз в конструкторському програмному забезпеченні шляхом моделювання потоків струму
Перевіряючи, що апаратне забезпечення робить те, що має, наприклад, завантажує програмне забезпечення в пам'ять, воно скидає програмне забезпечення, яке не реагує («watch dog») тощо.

Приклад для мехатроніки:

Тест на міцність компонентів через напругу
Перевірка опорів рухомих деталей (наприклад, тросики у вигині)

Інтеграційні тести

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

Інтеграційні тести, як правило, багаторівневі для поступової інтеграції.

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

Вступом для інтеграційних тестів є системні вимоги.

Прийняття / кваліфікаційне тестування

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

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

Інші типи тестів

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

Найчастіше обов'язкові тести

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

Методики, що визначають тестування

Типи тестів ми не вигадали, вони точно визначені багатьма методологіями. Найбільш доступною методологією є SPICE, або його варіант для автомобільної промисловості, ASPICE. Чимало уваги приділяється і стандарту розробки програмного забезпечення, ISO/IEC 12204.

Ви запитуєте або що Вас цікавить тестування

Які типи тестів ми повинні робити?

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

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

Ми не зобов'язані дотримуватися якоїсь норми, тому ми не зобов'язані

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

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

#Куди далі
Загалом [про тести в AyMINE пишеться тут](/doc/uk/tsk/tsk Test).

Навчання з тестування

Якщо ви не впевнені в тестуванні, ми рекомендуємо вам Тестування навчання, де ви дізнаєтеся все.

Тестування – це останній крок якості

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