Статичне тестування — це техніка тестування програмного забезпечення, яка використовується для перевірки дефектів програмного забезпечення без виконання коду.
Статичне тестування проводиться, щоб уникнути помилок на ранній стадії розробки, оскільки легше виявити помилки та вирішити їх.
Це також допомагає знаходити помилки, які не можуть бути знайдені динамічним тестуванням.
Основи статичного тестування
На відміну від динамічного тестування, яке вимагає запуск на виконання програмного забезпечення, що тестується, статичне тестування спирається на перевірку робочих продуктів вручну (тобто огляди) або керовану інструментами оцінку коду чи інших робочих продуктів (тобто статичний аналіз). Обидва типи статичного тестування оцінюють код або інший робочий продукт, що тестується, без фактичного виконання коду або робочого продукту, що тестується.
Статичний аналіз важливий для сейфті-крітікал комп’ютерних систем (наприклад, авіаційного, медичного або ядерного програмного забезпечення), але статичний аналіз також став важливим і поширеним в інших середовищах. Наприклад, статичний аналіз є важливою частиною тестування безпеки. Статичний аналіз також часто включається в автоматизовані інструменти створення та розповсюдження програмного забезпечення, наприклад, у гнучкій розробці, безперервній доставці та безперервному розгортанні.
Цінність статичного тестування
При застосуванні на ранніх стадіях життєвого циклу розробки програмного забезпечення статичне тестування дозволяє завчасно виявити дефекти до виконання динамічного тестування (наприклад, під час перегляду вимог або специфікацій дизайну, уточнення невиконаних завдань тощо).
Дефекти, виявлені на ранній стадії, часто набагато дешевше усунути, ніж дефекти, виявлені пізніше в життєвому циклі, особливо порівняно з дефектами, виявленими після розгортання програмного забезпечення та його активного використання.
Використання методів статичного тестування для пошуку дефектів і подальшого негайного усунення цих дефектів майже завжди набагато дешевше для організації, ніж використання динамічного тестування для пошуку дефектів в об’єкті тестування та їх подальшого усунення, особливо якщо враховувати додаткові витрати, пов’язані з оновленням інших робочих продуктів і проведення підтверджувального та регресійного тестування.
Переваги статичного тестування
До переваг статичного тестування відносять:
Більш ефективне виявлення та виправлення дефектів до виконання динамічного тестування
Виявлення дефектів, які нелегко виявити динамічним тестуванням
Запобігання дефектам у дизайні чи кодуванні шляхом виявлення невідповідностей, двозначностей, протиріч, упущень, неточностей і надмірностей у вимогах
Підвищення продуктивності розробки (наприклад, за рахунок покращеного дизайну, більш зручного обслуговування коду)
Зменшення витрат і часу розробки
Зменшення вартості та часу тестування
Зменшення загальної вартості якості протягом усього терміну служби програмного забезпечення завдяки меншій кількості збоїв у подальшому життєвому циклі або після введення в експлуатацію
Покращення комунікації між членами команди під час участі в оглядах
Статичне і динамічне тестування
Статичне тестування та динамічне тестування можуть мати однакові цілі, наприклад, забезпечити оцінку якості робочих продуктів і виявити дефекти якомога раніше. Статичне та динамічне тестування доповнюють одне одного, виявляючи різні типи дефектів.
Однією з головних відмінностей є те, що статичне тестування виявляє дефекти в робочих продуктах безпосередньо, а не визначає збої, викликані дефектами під час запуску програмного забезпечення. Дефект може існувати в робочому продукті протягом дуже тривалого часу, не викликаючи збою. Дефект у робочому продукті може тривалий час ніяк не проявлятися (наприклад через рідкісність набору умов, які можуть призвести до його прояву), тому буде непросто побудувати та виконати динамічний тест, який його виявить. Статичне тестування може виявити дефект із набагато меншими зусиллями.
Інша відмінність полягає в тому, що статичне тестування можна використовувати для покращення узгодженості та внутрішньої якості робочих продуктів, тоді як динамічне тестування зазвичай зосереджується на зовнішніх видимих поведінках.
Статичне тестування і дефекти
У порівнянні з динамічним тестуванням типові дефекти, які легше та дешевше знайти та виправити за допомогою статичного тестування, включають:
Дефекти вимог (наприклад, невідповідності, двозначності, протиріччя, упущення, неточності та надмірності)
Дефекти дизайну (наприклад, неефективні алгоритми або структури бази даних, високий зв’язок, низька зв’язність)
Дефекти кодування (наприклад, змінні з невизначеними значеннями, змінні, які оголошені, але ніколи не використовуються, недоступний код, повторюваний код)
Відхилення від стандартів (наприклад, недотримання стандартів кодування)
Неправильні специфікації інтерфейсу (наприклад, інші одиниці вимірювання, що використовуються системою)
Вразливості системи безпеки (наприклад, сприйнятливість до переповнення буфера)
Прогалини або неточності в простежуваності бази тестів або покритті (наприклад, відсутність тестів для критерію прийнятності)
Статичне тестування
В цьому відео поговоримо про статичне тестування: 00:05 Статичне тестування 01:03 Основи Статичного тестування 02:31 Цінність статичного тестування 04:10 Переваги статичного тестування 05:20 Статичне і динамічне тестування 07:01 Статичне тестування і дефекти
Серія міжнародних стандартів ISO/IEC 25000, також відомих як Системні та програмні вимоги якості і оцінка (System and Software Quality Requirements and Evaluation), визначає характеристики, якими оцінюється якість програмного продукту.
Стандарт ISO/IEC 25010 містить термінологію для визначення, вимірювання та оцінки якості систем та програмних продуктів. Він визначає вісім характеристик якості програмного забезпечення, серед яких: функціональна придатність, рівень продуктивності, сумісність, зручність використання, надійність, безпека, зручність супроводу, портативність.
Стандарт ISO/IEC 25010 є ґрунтовним переглядом стандарту ISO/IEC 9126. У новий стандарт додано додаткові характеристики та підхарактеристики, які детальніше описують процес якості програмного продукту, а також введені уточнення та перегрупування характеристик для більш ясного їх розуміння.
Якість програмного забезпечення – це здатність програмного продукту, згідно з вказаними умовами, задовольняти встановлені потреби. (ISO 25000:2014).
Ефектиність продуктивності (Performance efficiency) включає часові характеристики, використання ресурсів, місткість.
Часові характеристики (Time behaviour) — ступінь відповідності вимогам про час відповіді, час обробки і показники пропускної здатності продукта або системи.
Використання ресурсів (Resource utilization) — ступінь задоволення вимог про споживання обсягів і видів ресурсів продуктом або системою при виконанні їх функцій.
Місткість (Capacity) — ступінь відповідності вимогам граничних значень параметрів продукта або системи.
Сумісність (Compatibility)
Сумісність (Compatibility) включає співіснування та функціональну сумісність.
Співіснування (Co-existence) — здатність продукта сумісно функціонувати з іншими незалежними продуктами у спільній середі з розділенням спільних ресурсів і без негативного впливу на будь-який інший продукт.
Функціональна сумісність (Interoperability) — здатність двох або більше систем, продуктів або компонентів обмінюватис даними і використовувати такі дані.
Зручність використання (Usability)
Зручність використання (Usability) включає можливість визначення придатності, можливість вивчення, керованість, захист від помилок користувача, естетика користувацкого інтерфейсу, доступність.
Можливість визначення придатності (Appropriateness recognizability) — можливість користувача зрозуміти чи підходить продукт або система для їхніх потреб.
Можливість вивчення (Learnability) — можливість використання продукта або системи певними користувачами для досягнення конкретних цілей навчання для експлуатації продукта або системи з ефективність, результативністю, без ризику і у відповідності з вимогами у вказаному контексті використання.
Керованість (Operability) — наявність в продукті або системі атрибутів, які забезпечують просте управління та контроль.
Захист від помилок користувача (User error protection) — рівень системного захисту користувачів від помилок.
Доступність (Accessibility) — можливість викорситання продукту або системи для досягнення певної мети у вказаному контексті використання широким колом осіб з різними можливостями.
Надійність (Reliability)
Надійність (Reliability) включає зрілість, готовність, відмовостійкісь, відновлюваність.
Зрілість (Maturity) — ступінь відповідності системи, продукта або компонента при нормальній роботі вимогам надійності.
Готовність (Availability) — ступінь працездатності і доступності системи, продукта або компонента.
Відмовостійкість (Fault tolerance) — здатність системи, продукта або компонента працювати як призначено, не дивлячись на наявність дефектів програмного забезпечення або апаратниї засобів.
Відновлюваність (Revoverability) — здатність продукта або системи відновити дані та необхідний стан системи у випадку переривання або збою.
Безпека (Security)
Безпека (Security) включає неможливість заперечення, цілісність, конфіденційність, відстежуваність, автентичність.
Неможливість заперечувати (Non-repudiation) — впевненість, що хтось не може заперечувати дійсність чогось. Себто можливісь беззаперечно довести факт події або дії таким чином, що цей факт не можна заперечити.
Цілісність (Integrity) — ступінь запобігання системою, продуктом або компонентом несанкціоноваго доступу до модифікацій даних.
Конфіденційність (Confidentiality) — забезпечення продуктом або системою обмеження доступу до даних тільки для тих, кому доступ довзволено.
Відстежуваність (Accountability) — ступінь, до якої дії об’єкта можуть бути відстежені однозначно.
Автентичність (Authenticity) — ступінь достовірності, відповідності об’єкта або ресурса необхідному об’єкту або ресурсу.
Зручність супроводу (Maintainability)
Зручність супроводу (Maintainability) включає модульність, можливість багаторазового використання, можливість аналізу, можливість модифікацій, можливість тестування.
Модульність (Modularity) — ступінь представлення системи або програми у вигляді окремих блоків таким чином, щоб зміна одного компонента здійснювала мінімальний вплив на інші компоненти.
Можливість багаторазового використання (Reusability) — ступінь, в якій актив може бути використаний в декількох системах чи при створенні інших активів.
Можливість аналізу (Analysability) — ступінь простоти оцінки впливу змін однієї або більше частин на продукт або систему або простоти діагностики продукта для виявлення недоліків та причин відмов, або простоти ідетифікації частин, які порібно змінювати.
Можливість модифікацій (Modifiability) — ступінь простоти ефективної та раціональної зміни продукту або системи без додавання дефектів та зниження якості продукта.
Можливість тестування (Testability) — ступінь простоти ефективного та раціонального визначення для системи, продукта або компонента критеріїв тестування, а також простоти виконання тестування з метою визначення відповідності цим критеріям.
Портативність (Portability)
Портативність (Portability) включає можливість адаптації, можливість встановлення, можливість заміни.
Можливість адаптації (Adаptability) — ступінь простоти ефективної та раціональної адаптації для удосконалених апаратних засобів, програмного забезпечення, інших операційних середовищ або умов використання.
Можливість встановлення (Installability) — ступінь простоти ефективного, раціонального, успішного встановлення або видалення продукта або системи в заданому середовищі.
Можливість заміни (Replaceability) — здатність продукта замінити інший конкретний програмний продукт для досягнення тих самих цілей в тих же умовах.
Вимоги до програмного забезпечення
Вимоги до програмного забезпечення – це опис характеристик і функцій цільової системи. Вимоги передають очікування користувачів від програмного продукту. Вимоги можуть бути очевидними або прихованими, відомими або невідомими, очікуваними або неочікуваними з точки зору клієнта.
Розробка вимог
Процес збору вимог до програмного забезпечення від клієнта, їх аналізу та документування відомий як розробка вимог.
Метою розробки вимог є розробка та підтримка складного, описового документа “Специфікація системних вимог”.
Процес розробки вимог включає наступні стадії:
Техніко-економічне обґрунтування
Збір вимог
Специфікація вимог до програмного забезпечення
Перевірка вимог програмного забезпечення
ТЕО (техніко-економічне обґрунтування)
Коли клієнт звертається до організації за розробкою бажаного продукту, у нього виникає приблизне уявлення про те, які функції має виконувати програмне забезпечення та які функції очікуються від програмного забезпечення.
Посилаючись на цю інформацію, аналітики детально вивчають, чи можливо розробити бажану систему та її функціональність.
Це техніко-економічне обґрунтування спрямоване на досягнення мети організації. У цьому дослідженні аналізується, чи можна практично матеріалізувати програмний продукт з точки зору впровадження. Досліджуються технічні аспекти проєкту та продукту, такі як зручність використання, ремонтопридатність, продуктивність та здатність до інтеграції.
Результатом цього етапу має бути звіт про техніко-економічне обґрунтування, який повинен містити адекватні коментарі та рекомендації для керівництва щодо того, чи слід розпочинати проєкт.
Збір вимог
Якщо техніко-економічний звіт є позитивним для реалізації проєкту, наступний етап починається зі збору вимог від користувача. Аналітики та інженери спілкуються з клієнтом і кінцевими користувачами, щоб дізнатися їхні ідеї щодо того, що має надавати програмне забезпечення та які функції вони хочуть включати в програмне забезпечення.
Специфікація вимог до програмного забезпечення
SRS — це документ, створений системним аналітиком після збору вимог від різних зацікавлених сторін.
SRS визначає, як передбачене програмне забезпечення взаємодіятиме з апаратним забезпеченням, зовнішніми інтерфейсами, швидкістю роботи, часом відгуку системи, переносимістю програмного забезпечення на різні платформи, зручністю обслуговування, швидкістю відновлення після збою, безпекою, якістю, обмеженнями тощо.
Вимоги, отримані від клієнта, написані природною мовою. Системний аналітик відповідає за документування вимог технічною мовою, щоб вони могли бути зрозумілими та корисними групі розробників програмного забезпечення.
Перевірка вимог програмного забезпечення
Після розробки специфікацій вимог, починається перевірка цих вимог. Користувач може попросити незаконне, непрактичне рішення або експерти можуть неправильно витлумачити вимоги. Це призвести до суттєвих збитків, якщо не внести виправлення. Вимоги можна перевірити на такі умови:
Чи можливо їх практично реалізувати
Чи вони коректні та відповідають функціям і домену програмного забезпечення
Чи є якісь неясності
Чи вони повні
Чи можна їх продемонструвати
Процес виявлення вимог
Процес виявлення вимоги містить наступні фази:
Збір вимог – розробники обговорюють їх із клієнтом і кінцевими користувачами та знають їхні очікування від програмного забезпечення.
Організація вимог – розробники встановлюють пріоритети та впорядковують вимоги в порядку важливості, терміновості та зручності.
Обговорення. Якщо вимоги є неоднозначними або є деякі конфлікти у вимогах різних зацікавлених сторін, якщо вони є, тоді це обговорюється із зацікавленими сторонами. Щоб усунути двозначність і конфлікти, вони обговорюються для ясності та коректності. Нереалістичні вимоги доцільно відхилити чи модифікувати.
Документація. Усі формальні та неофіційні, функціональні та нефункціональні вимоги систематизуються та документуються.
Методи виявлення вимог
Виявлення вимог — це процес з’ясування вимог до системи програмного забезпечення шляхом спілкування з клієнтом, кінцевими користувачами, користувачами системи та іншими, хто зацікавлений у розробці системи програмного забезпечення.
Існують різні способи виявити вимоги: інтерв’ю (співбесіди), опитування, анкетування, розбір задачі, аналіз домену, мозковий штурм, прототипування, спостереження.
Інтерв’ю (співбесіди)
Співбесіди є сильним засобом збору вимог. Організація може проводити кілька типів співбесід, таких як:
Структуровані (закриті) інтерв’ю, де кожна окрема інформація, яку потрібно зібрати, вирішується заздалегідь, вони чітко слідують шаблону та предмету обговорення.
Неструктуровані (відкриті) інтерв’ю, де інформація для збору не вирішується заздалегідь, більш гнучкі та менш упереджені.
Усні опитування
Письмові інтерв’ю
Індивідуальні співбесіди, які проводяться між двома людьми за столом.
Групові інтерв’ю, які проводяться між групами учасників. Вони допомагають виявити будь-які відсутні вимоги, оскільки задіяно багато людей.
Опитування
Організація може проводити опитування серед різних зацікавлених сторін, запитуючи про їхні очікування та вимоги щодо майбутньої системи.
Анкети
Документ із заздалегідь визначеним набором об’єктивних запитань і відповідних варіантів передається всім зацікавленим сторонам для відповіді.
Розбір задачі
Команда інженерів і розробників може проаналізувати роботу, для якої потрібна нова система. Якщо у клієнта вже є програмне забезпечення для виконання певної операції, воно вивчається та збираються вимоги до запропонованої системи.
Аналіз домену
Кожне програмне забезпечення належить до певної категорії домену. Експерти у цій галузі можуть надати велику допомогу для аналізу загальних і конкретних вимог.
Мозковий штурм
Між різними зацікавленими сторонами проводяться неформальні дебати, і всі їхні внески записуються для подальшого аналізу вимог.
Прототипування
Прототипування — це створення користувальницького інтерфейсу без додавання детальної функціональності, щоб користувач міг інтерпретувати особливості запланованого програмного продукту. Це допомагає краще уявити вимоги. Відгуки клієнтів служать вхідними даними для збору вимог.
Спостереження
Команда експертів відвідує організацію або робоче місце клієнта. Вони спостерігають за фактичною роботою існуючих встановлених систем. Вони спостерігають за робочим процесом у клієнта та за тим, як вирішуються проблеми виконання. Команда сама робить деякі висновки, які допомагають сформувати вимоги, які очікуються від програмного забезпечення.
Характеристики вимог до програмного забезпечення
Збір вимог до програмного забезпечення є основою всього проєкту розробки програмного забезпечення. Тому вони мають бути чіткими, правильними та чітко визначеними.
Повна специфікація вимог до програмного забезпечення має бути:
Ясною
Правильною
Послідовною
Зрозумілою
Можливою для внесення модифікацій, змін
Можливою для перевірки
Пріоритизованою
Однозначною
Відстежуваною
Функціональні та нефункціональні вимоги
Функціональні вимоги. До цієї категорії належать вимоги, пов’язані з функціональним аспектом програмного забезпечення.
Нефункціональні вимоги. До цієї категорії відносяться вимоги, не пов’язані з функціональним аспектом програмного забезпечення. Це неявні або очікувані характеристики програмного забезпечення, про які користувачі роблять припущення (сумісність, продуктивність, портативність, безпека, зручність використання тощо).
Якість ПЗ та вимоги
В цьому відео поговоримо про якість ПЗ та вимоги 00:06 Якість ПЗ 06:17 Функціональна придатність 07:34 Ефектиність продуктивності 08:32 Сумісність 09:40 Зручність використання 12:21 Надійність 13:37 Безпека 17:25 Зручність супроводу 19:43 Портативність 20:45 Вимоги до ПЗ 22:11 Розробка вимог 23:18 Техніко-економічне обґрунтування 24:44 Збір вимог 25:10 Специфікація вимог до ПЗ 26:31 Перевірка вимог до ПЗ 27:48 Процес виявлення вимог 29:25 Методи виявлення вимог 33:22 Функціональні і нефункціональні вимоги