Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Экзамен. Вопросы. Майданюк.docx
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
812.17 Кб
Скачать
  1. Тестування правильності.

После окончания тестирования интеграции программная система собрана в единый корпус, интерфейсные ошибки обнаружены и откорректированы. Теперь начинается последний шаг программного тестирования — тестирование правильности. Цель — подтвердить, что функции, описанные в спецификации требований к ПС, соответствуют ожиданиям заказчика [64], [69].

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

Важным элементом подтверждения правильности является проверка конфигурации ПС. Конфигурацией ПС называют совокупность всех элементов информации, вырабатываемых в процессе конструирования ПС. Минимальная конфигурация ПС включает следующие базовые элементы:

  1. системную спецификация;

  2. План программного проекта;

  3. спецификацию требований к ПС; работающий или бумажный макет;

  4. Предварительное руководство пользователя

  5. спецификация проектирования;

  6. листинги исходных текстов программ;

  7. план и методику тестирования; тестовые варианты и полученные результаты;

  8. Руководства по работе и инсталляции;

  9. ехе-код выполняемой программы;

  10. описание базы данных;

  11. руководство пользователя по настройке;

  12. документы сопровождения; отчеты о проблемах ПС; запросы сопровождения; отчеты о конструкторских изменениях;

  13. стандарты и методики конструирования ПС.

Проверка конфигурации гарантирует, что все элементы конфигурации ПС правильно разработаны, учтены и достаточно детализированы для поддержки этапа сопровождения в жизненном цикле ПС.

Разработчик не может предугадать, как заказчик будет реально использовать ПС. Для обнаружения ошибок, которые способен найти только конечный пользователь, используют процесс, включающий альфа- и бета-тестирование.

Альфа-тестирование проводится заказчиком в организации разработчика. Разработчик фиксирует все выявленные заказчиком ошибки и проблемы использования.

Бета-тестирование проводится конечным пользователем в организации заказчика. Разработчик в этом процессе участия не принимает. Фактически, бета-тестирование — это реальное применение ПС в среде, которая не управляется разработчиком. Заказчик сам записывает все обнаруженные проблемы и сообщает о них разработчику. Бета-тестирование проводится в течение фиксированного срока (около года). По результатам выявленных проблем разработчик изменяет ПС и тем самым подготавливает продукт полностью на базе заказчика.

  1. Системне тестування .

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

Мета системного тестування

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

Тестування всієї системи

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

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

  • невірне використання ресурсів системи,

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

  • несумісність із оточенням,

  • непередбачувані сценарії використання,

  • відсутня або невірна функціональність,

  • незручність у застосуванні тощо.

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

Категорії тестів системного тестування:

Повнота рішення функціональних завдань.

Стресове тестування — на граничних обсягах навантаження вхідного потоку.

Коректність використання ресурсів (витік пам’яті, повернення ресурсів).

Оцінка продуктивності.

Ефективність захисту від спотворення даних і некоректних дій.

Перевірка інсталяції й конфігурації на різних платформах.

Коректність документації.

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

Тестування модулів в системному тестуванні

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

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

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

Типи тестування, що включає в себе системне тестування:

  • Тестування графічного інтерфейсу

  • Тестування зручності

  • Тестування продуктивності ПЗ

  • Тестування сумісності

  • Тестування навантаження

  • Стресове тестування

  • Тестування безпеки

  • Тестування масштабованості

  • Димчасте тестування

  • Регресійне тестування

  • Інсталяційне тестування

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