Відмінності між версіями «Software-testing»
| (Не показані 4 проміжні версії цього користувача) | |||
| Рядок 10: | Рядок 10: | ||
* відповідність задачам замовника. | * відповідність задачам замовника. | ||
| − | Зазвичай, якість обмежується такими поняттями як коректність, надійність, практичність, безпечність, але може містити більше технічних вимог, котрі описані у стандарті '''ISO 9126''. Склад та зміст супутньої документації процесу тестування визначається стандартом '''IEEE 829–1998''' Standard for Software Test Documentation. Існує багато підходів до тестування програмного забезпечення, але ефективне тестування складних продуктів – це по суті дослідницький та творчий процес. | + | Зазвичай, якість обмежується такими поняттями як коректність, надійність, практичність, безпечність, але може містити більше технічних вимог, котрі описані у стандарті '''ISO 9126'''. Склад та зміст супутньої документації процесу тестування визначається стандартом '''IEEE 829–1998''' Standard for Software Test Documentation. Існує багато підходів до тестування програмного забезпечення, але ефективне тестування складних продуктів – це по суті дослідницький та творчий процес. |
| − | '''Тест'' – контрольна задача для перевірки коректності функціонування ПЗ. Основна ідея тестування – запустити ПЗ і спостерігати за його роботою та її наслідками. | + | '''Тест''' – контрольна задача для перевірки коректності функціонування ПЗ. Основна ідея тестування – запустити ПЗ і спостерігати за його роботою та її наслідками. |
Якщо збій в роботі ПЗ відбувся, то аналізується звіт з метою виявлення місцезнаходження помилки, яка його викликала. «Вдалим» тестом є той, при якому виконання програми закінчилось з помилкою. | Якщо збій в роботі ПЗ відбувся, то аналізується звіт з метою виявлення місцезнаходження помилки, яка його викликала. «Вдалим» тестом є той, при якому виконання програми закінчилось з помилкою. | ||
== Рівні тестування == | == Рівні тестування == | ||
# '''Компонентне або модульне тестування''' Перевіряє функціональність і шукає дефекти в частинах програми, які доступні і можуть бути протестовані окремо в силу своєї автономності (модулі програми, об’єкти, функції і т.д.). | # '''Компонентне або модульне тестування''' Перевіряє функціональність і шукає дефекти в частинах програми, які доступні і можуть бути протестовані окремо в силу своєї автономності (модулі програми, об’єкти, функції і т.д.). | ||
| − | # '''Інтеграційне тестування''' Призначено для перевірки зв’язків між компонентами програми, а також дослідження взаємодії додатку | + | # '''Інтеграційне тестування''' Призначено для перевірки зв’язків між компонентами програми, а також дослідження взаємодії додатку з середовищем, в рамках якого воно буде виконуватися. |
| − | # '''Системне тестування''' направлено на дослідження функціональних і нефункціональних особливостей системи в цілому. При цьому виявляються | + | # '''Системне тестування''' направлено на дослідження функціональних і нефункціональних особливостей системи в цілому. При цьому виявляються дефекти, такі як невірне використання ресурсів системи, непередбачені комбінації даних рівня користувача, несумісність з оточенням, непередбачені сценарії використання, відсутня або невірна функціональність, незручність використання і т.д. |
| − | дефекти, такі як невірне використання ресурсів системи, непередбачені комбінації даних рівня користувача, несумісність з оточенням, непередбачені сценарії використання, відсутня або невірна функціональність, незручність використання і т.д. | ||
# '''Приймальне тестування''' проводиться на фінальному етапі розробки та спрямовано на з’ясування того, чи відповідає система приймально/здавальним критеріям до вимог замовника. | # '''Приймальне тестування''' проводиться на фінальному етапі розробки та спрямовано на з’ясування того, чи відповідає система приймально/здавальним критеріям до вимог замовника. | ||
| Рядок 62: | Рядок 61: | ||
* '''Відмова (Failure)''' – це більш серйозний прояв дефекту в системі (або підсистеми), при якому вся система або її частина виходять з ладу, виходячи при цьому з працездатного стану, тобто стану в якому всі аспекти функціонування системи відповідають вимогам. | * '''Відмова (Failure)''' – це більш серйозний прояв дефекту в системі (або підсистеми), при якому вся система або її частина виходять з ладу, виходячи при цьому з працездатного стану, тобто стану в якому всі аспекти функціонування системи відповідають вимогам. | ||
* '''Аварія''' – відмова системи, при якому система виходить з ладу таким чином, що відновлення її працездатного стану або неможливо, або займає значний час. У разі програмних систем можна уникнути виникнення аварійних ситуацій за допомогою повного дублювання системи як виконуваного програмного коду, так і даних. | * '''Аварія''' – відмова системи, при якому система виходить з ладу таким чином, що відновлення її працездатного стану або неможливо, або займає значний час. У разі програмних систем можна уникнути виникнення аварійних ситуацій за допомогою повного дублювання системи як виконуваного програмного коду, так і даних. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Поточна версія на 18:12, 9 вересня 2022
Зміст
Тестування програмного забезпечення
Тестування програмного забезпечення (англ. Software Testing) – техніка контролю якості, що перевіряє відповідність між реальною і очікуваною поведінкою програми завдяки кінцевому набору тестів, які обираються певним чином.
Може оцінюватись:
- відповідність вимогам, якими керувалися проектувальники та розробники;
- правильна відповідь для усіх можливих вхідних даних;
- виконання функцій за прийнятний час;
- практичність;
- сумісність з програмним забезпеченням та операційними системами;
- відповідність задачам замовника.
Зазвичай, якість обмежується такими поняттями як коректність, надійність, практичність, безпечність, але може містити більше технічних вимог, котрі описані у стандарті ISO 9126. Склад та зміст супутньої документації процесу тестування визначається стандартом IEEE 829–1998 Standard for Software Test Documentation. Існує багато підходів до тестування програмного забезпечення, але ефективне тестування складних продуктів – це по суті дослідницький та творчий процес.
Тест – контрольна задача для перевірки коректності функціонування ПЗ. Основна ідея тестування – запустити ПЗ і спостерігати за його роботою та її наслідками. Якщо збій в роботі ПЗ відбувся, то аналізується звіт з метою виявлення місцезнаходження помилки, яка його викликала. «Вдалим» тестом є той, при якому виконання програми закінчилось з помилкою.
Рівні тестування
- Компонентне або модульне тестування Перевіряє функціональність і шукає дефекти в частинах програми, які доступні і можуть бути протестовані окремо в силу своєї автономності (модулі програми, об’єкти, функції і т.д.).
- Інтеграційне тестування Призначено для перевірки зв’язків між компонентами програми, а також дослідження взаємодії додатку з середовищем, в рамках якого воно буде виконуватися.
- Системне тестування направлено на дослідження функціональних і нефункціональних особливостей системи в цілому. При цьому виявляються дефекти, такі як невірне використання ресурсів системи, непередбачені комбінації даних рівня користувача, несумісність з оточенням, непередбачені сценарії використання, відсутня або невірна функціональність, незручність використання і т.д.
- Приймальне тестування проводиться на фінальному етапі розробки та спрямовано на з’ясування того, чи відповідає система приймально/здавальним критеріям до вимог замовника.
Види тестуванн
- Функціональні види тестування пов’язані з дослідженням зовнішньої поведінки системи, тобто виконуваних нею функцій. До них належать:
- функціональне тестування
- тестування безпеки
- тестування взаємодії
- Нефункціональні
- тестування встановлення
- тестування зручності використання
- тестування на відмову і відновлення
- конфігураційне тестування,
- тестування продуктивності (навантаження)
Мета і задачі тестування
- виявлення дефектів на різних етапах життєвого циклу додатку (у процесі розробки, під час супроводження тощо);
- перевірка того, чи був виявлений дефект успішно усунутий; з’ясування того, що зміни, пов’язані з усуненням виявленого дефекту.
- виявлення дефектів моделі системи;
- виявлення дефектів кодування;
- виявлення помилок і недоліків взаємодії системи з оточенням, а також зовнішніми компонентами і системами;
- виявлення дефектів інтеграції програмного забезпечення;
- виявлення недоліків продуктивності системи;
- виявлення нестійкості програмного забезпечення до перевантажень;
- виявлення нестійкості програмного забезпечення до введення помилкових даних і відмови при збільшенні обсягів даних, що оброблюються;
- виявлення вразливостей в системі безпеки програми і можливостей несанкціонованого доступу до конфіденційних даних;
- контроль виправлення виявлених у процесі тестування дефектів;
- виявлення регресії системи в процесі розробки.
Термінологія
Помилка, баг, дефект
- Помилка (Еrror) – хибне значення величини на виході системи або підсистеми, що викликане несправностями або збоями, яке, в свою чергу,
може викликати відмову.
- Несправність, дефект (Fault) – визнана або передбачувана причина помилки; наслідок відмови деякої системи, що обслуговувала або обслуговує в даний момент часу розглянуту систему. Дефекти також часто називають «багами» (від англ. bugs – жучки).
- «Гейзінбаг» (англ. heisenbug) – це програмна помилка, яка зникає або змінює свої характеристики при спробі її виявити.
- «Борбаг» (англ. bohrbug) – це така програмна помилка, поведінку якої визначено деякою кількістю певних (але, можливо, невідомих) умов.
- «Шредінбаг» (англ. schrodinbug ) – це програмна помилка, яка ніяк не проявляється (або є невідомою), до тих пір, поки хто-небудь не виявить її, прочитавши вихідний код або використавши програми в незвичайних (не передбачених) умовах.
- «Статистичний баг» (англ. statistical bug ) – це така програмна помилка, яка може бути виявлена тільки при агрегації досить великої кількості результатів тестів. Іншими словами, окремі випробування (і навіть їх невелика кількість) не виявляють помилки – вона стає видна, тільки якщо розглядати велику кількість результатів одночасно.
Збій, відмова, аварія
- Збій (Malfunction) – перший прояв дефекту в роботі системи (проява несправності, зазвичай в роботі устаткування).
- Відмова (Failure) – це більш серйозний прояв дефекту в системі (або підсистеми), при якому вся система або її частина виходять з ладу, виходячи при цьому з працездатного стану, тобто стану в якому всі аспекти функціонування системи відповідають вимогам.
- Аварія – відмова системи, при якому система виходить з ладу таким чином, що відновлення її працездатного стану або неможливо, або займає значний час. У разі програмних систем можна уникнути виникнення аварійних ситуацій за допомогою повного дублювання системи як виконуваного програмного коду, так і даних.