Інформаційні системи і технології на підприємствах - Плескач В.Л. - 3.3. Тестування програм та систем

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

Основні види робіт з тестування:

o верифікація результатів розроблення програмного продукту на кожному етапі життєвого циклу;

o упорядкування плану тестування і підготовки тестів для перевірки окремих елементів розробленої програми та програми в цілому;

o керування виконанням тестів та аналіз результатів тестування;

o повторне тестування.

Тестування - оцінка якості ПЗ методом експериментальної перевірки - шляхом виконання тестів. Мета тестування - виявити наявність помилок/неузгодженостей. Іншими словами, це знаходження помилок (локалізація - задача діагностики), досягнення відсутності помилок (відладка).

Кінцевою метою тестування промислових ІТ-проектів є отримання сертифіката на розроблений програмний продукт.

Тестування становить від ЗО до 50 % трудомісткості робіт зі створення коду.

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

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

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

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

Функціональному тестуванню передує аналіз функцій, до завдань якого входять:

o ідентифікація множини функціональних вимог;

o ідентифікація зовнішніх функцій у реалізації програмного забезпечення і побудова послідовностей функцій відповідно до використання їх у ПЗ;

o ідентифікація множини вхідних даних кожної функції і визначення напрямків їх зміни;

o побудова тестових наборів і сценаріїв тестування функцій;

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

Основна мета тестування - забезпечення повноти й узгодженості реалізованих у програмних компонентах функцій та інтерфейсів між ними.

Методи доведення правильності програм з'явилися ще у 80-ті роки. Техніка символьного виконання включає моделювання виконання коду, використовуючи символи замість змінних даних.

Верифікація - перевірка відповідності реалізації системи специфікаціям результатів проектування й опису компоненти,

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

3.4. Помилки та причини їх появи на етапах життєвого циклу

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

o помилкової специфікації або пропущеної вимоги (специфікація точно не відображає припущення користувача);

o наявність вимоги, яку неможливо виконати на цій апаратурі і ПЗ;

o помилки у проекті програми (приміром, базу даних спроектовано без захисту від несанкціонованого доступу користувача, а захист потрібен);

o помилки в алгоритмі.

Помилки у ПЗ можна класифікувати відповідно до їхнього розподілу за етапами життєвого циклу і джерел їхнього виникнення:

1) ненавмисне відхилення розробників від робочих стандартів або планів реалізації;

2) специфікації функціональних та інтерфейсних вимог без дотримання стандартів розроблення;

3) недосконала організація процесу розроблення.

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

1. Етап аналізу вимог. У визначенні вхідної концепції системи та опису вхідних вимог замовника виникають помилки аналітиків, коли вони формулюють специфікації верхнього рівня і будують концептуальну модель ПрО.

Характерні помилки:

o неадекватність опису специфікаціям вимог кінцевих користувачів;

o некоректність специфікації взаємодії програмного забезпечення із середовищем функціонування або з користувачами;

o невідповідність вимог замовника окремим і загальним властивостям програмного забезпечення;

o некоректність опису функціональних характеристик;

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

2. Етап проектування компонент. Помилки під час проектування компонент можуть виникати при описі алгоритмів, логіки управління, структур даних, інтерфейсів, логіки моделювання потоків даних, форматів введення-виведення тощо. В основі цих помилок лежать дефекти специфікацій аналітиків та помилок проектувальників.

Помилки можуть виникати під час:

o визначення інтерфейсу користувача із середовищем;

o опису функцій (неадекватності формулювань у проекті мети та завдань окремих компонентів, що виявляються при перевірці проекту);

o визначення процесу опрацювання інформації або зв'язків між процесами (наслідок некоректного визначення взаємозв'язків компонентів та процесів);

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

o опису алгоритмів модулів та їхньої логіки, що некоректно визначені в поданому проекті модуля;

o визначення умов виникнення можливих помилок у програмі;

o порушення прийнятих для проекту стандартів та технологій.

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

Характерні помилки:

o безконтрольність допустимості значень вхідних та вихідних параметрів, ділення на 0 тощо;

o неправильна обробка нетипових ситуацій під час аналізу кодів повернення від підпрограм;

o порушення стандартів кодування (неадекватні коментарі, нераціональне виділення модулів і компонентів тощо);

o використання одного імені для позначення кількох об'єктів або кількох імен на позначення одного об'єкта;

o неузгоджене внесення змін у програму кількома розробниками.

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

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

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

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

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

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

Види тестування програм з метою перевірки:

o повноти функцій;

o узгодженості інтерфейсів;

o структури програми;

o обчислення і коректності виконання функцій;

o правильності функціонування в заданих умовах;

o надійності виконання програм;

o ефективності захисту від збоїв апаратури і невиявлених помилок;

o зручності застосування та супроводження.

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

Команда тестувачів

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

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

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

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

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

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

Типові причини, які можуть зумовити потребу змін:

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

o з'ясування замовником під час експлуатації ІС, що вимоги до системи були висловлені недостатньо або неповно, і тому вона не відповідає окремим потребам замовника (зміни, за які несе відповідальність постановник задачі);

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

Як засвідчують експерти, процес внесення змін досить дорогий - оцінки його вартості сягають 60-80 % від загальної вартості розроблення.

Види супроводження:

o коригувальне - внесення коректив для усунення помилок, які було знайдено після передачі системи до експлуатації;

o адаптивне - адаптація продукту до змінених обставин використання після передачі системи в експлуатацію;

o попереджувальне - діяльність із забезпечення адаптивного супроводження на старті розроблень.