Тема.  Основні поняття процесу тестування

План

1.   Термінологія тестування.

2.   Види тестувань.

3.   Поняття дефекту, збою та відмови.

4.   Типи дефектів, їх класифікація та статистика виникнення.

 

1.   Термінологія тестування

Тестування (software testing) — діяльність, що виконується для оцінки та вдосконалення програмного забезпечення. Ця діяльність, в загальному випадку, базується на виявленні дефектів і проблем в програмних системах.

Тестування програмних систем складається з динамічної верифікації поведінки програм на кінцевому (обмеженому) наборі тестів (set of test cases), обраних відповідним чином з зазвичай виконуваних дій прикладної області і забезпечують перевірку відповідності очікуваної поведінки системи.

У даному визначенні тестування виділені слова, що визначають основні питання, яким адресується дана область знань:

 Динамічність (dynamic): цей термін означає тестування завжди припускає до  виконання програми, що тестується із заданими вхідними даними. При цьому, величини, що задаються на вхід тестуються, програмного забезпечення, не завжди достатньо для визначення тесту. Складність і недетермінованість систем призводить до того, що система може по-різному реагувати на одні й ті ж вхідні параметри, в залежності від стану системи. У даній галузі знань термін "вхід" (input) буде використовуватися в рамках угоди про те, що вхід може також специфікувати стан системи, в тих випадках, коли це необхідно. Крім динамічних технік перевірки якості, тобто тестування, існують також і статичні техніки, що розглядаються в галузі знань "Software Quality".

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

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

Очікувана поведінка (expected behaviour): хоча це не завжди легко, все ж таки необхідно вирішити, яка поведінка програми буде прийнятною, а яка — ні. В іншому випадку, зусилля з тестування — марні. Спостережувана поведінка може розглядатися в контексті користувача очікувань (маючи на увазі "тестування для перевірки" — testing for validation), специфікації ( "тестування для атестації" — testing for verification) або, нарешті, в контексті передбачуваної  поведінки на основі неявних вимог або обгрунтованих очікувань. Загальний погляд на тестування програмного забезпечення останні роки активно еволюціонував, стаючи все більш конструктивним, прагматичним і наближеним до реалій сучасних проектів розробки програмних систем. Тестування більш не розглядається як діяльність, що починається тільки після завершення фази конструювання.

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

У галузі знань "Якість програмного забезпечення" (Software Quality) техніки управління якістю чітко розділені на статичні (без виконання коду) і динамічні (з виконанням коду). Обидві ці категорії важливі. Ця галузь знань — "Тестування" — стосується динамічних технік.

Основа тестування (Software Testing Fundamentals) охоплює основні поняття в галузі тестування, базові терміни, ключові проблеми і їх зв'язок з іншими областями діяльності і знань.

 

2. Поняття дефекту, збою та відмови

У літературі, присвяченій програмній інженерії, зустрічається безліч термінів, що описують порушення функціонування програмних систем — недоліки (faults), дефекти (defects), збої (failures), помилки (errors) та ін. Відповідна термінологія описана в IEEE Std. 610—90.  Важливо чітко розділяти причини порушення роботи прикладних систем, звичайно описувану термінами недолік або дефект, і як спостерігається небажаний ефект, що викликається цими причинами — збій. Термін помилка, залежно від контексту, може описувати і як причину збою, і сам збій. Тестування дозволяє виявити дефекти, що призводять до збоїв.

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

 

3. Типи дефектів, їх класифікація та статистика виникнення

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

Міжнародний стандарт ANSI/IEEE-729-83 поділяє всі помилки в розробці програм на наступні типи.

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

Дефект (fault) в програмі — наслідок помилок розробника на будь-якому з етапів розробки, яка може міститися у вихідних або проектних специфікаціях, текстах кодів програм, експлуатаційної документації тощо. У процесі виконання програми може бути виявлений дефект або збій.

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

ü   помилкова специфікація або пропущена вимога, яка означає, що специфікація точно не відображає того, що припускав користувач;

ü   специфікація містить вимогу, яку неможливо виконати на цій апаратурі та програмному забезпеченні;

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

ü  програма може бути неправильною.

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

Розглянемо процес тестування, виходячи з рекомендацій стандарту 180 / ІЕС 12207, і наведемо типи помилок, які виявляються на кожному процесі ЖЦ.

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

Характерними помилками цього процесу є:

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

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

ü   невідповідність вимог замовника до окремих і загальних властивостей ПЗ;

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

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

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

До них відносяться помилки, пов’язані:

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

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

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

ü  з некоректним завданням даних та їх структур за описом окремих компонентів і ПЗ в цілому;

ü  з некоректним описом алгоритмів модулів;

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

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

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

Причиною помилок є:

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

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

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

ü   використання одного імені для позначення різних об’єктів або різних імен одного об’єкта, погана мнемоніка імен  неузгоджене внесення змін до програми різними розробниками та ін.

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

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

Всі помилки, які виникають у програмах, прийнято поділяти на наступні класи:

Ø    логічні і функціональні помилки;

Ø    помилки обчислень і часу виконання;

Ø    помилки вводу—виводу і маніпулювання даними;

Ø    помилки інтерфейсів;

Ø    помилки обсягу даних та ін.

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

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

Помилки вводу—виводу і маніпулювання даними є наслідком неякісної підготовки даних для виконання програми, збоїв при занесення їх до бази даних або при вибірці з неї.

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

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

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

Аналіз типів помилок у програмах є необхідною умовою створення планів тестування та методів тестування для забезпечення правильності ПЗ.

На сучасному етапі розвитку засобів підтримки розробки ПЗ (об’єктно—орієнтовані методи та засоби проектування моделей і програм) проводиться таке проектування, при якому ПЗ захищається від найбільш типових помилок і тим самим запобігає появі програмних дефектів.

Зв’язок помилки з відмовою. Наявність помилки в програмі, як правило, призводить до відмови ПЗ при його функціонуванні. Для аналізу причинно—наслідкових зв’язків "помилка—відмова" виконуються наступні дії:

ü   ідентифікація недоліків у технологіях проектування та програмування;

ü   взаємозв’язок вад процесу проектування і допускаються людиною помилок;

ü   класифікація відмов, недоліків і можливих помилок, а також дефектів на кожному етапі розробки;

ü   зіставлення помилок людини, які допускаються на певному процесі розробки, і дефектів в об’єкті, як наслідків помилок специфікації проекту, моделей програм;

ü   перевірка і захист від помилок на всіх етапах ЖЦ, а також виявлення дефектів на кожному етапі розробки;

ü   зіставлення дефектів та відмов у ПЗ для розробки системи взаємозв’язків і методики локалізації, збору і аналізу інформації про відмови і дефекти;

ü   розробка підходів до процесів документування та випробування ПЗ.

Кінцева мета причинно-наслідкових зв’язків "помилка—відмова" полягає у визначенні методів і засобів тестування та виявлення помилок певних класів, а також критеріїв завершення тестування на множині наборів даних; у визначенні шляхів удосконалення організації процесу розробки, тестування та супроводження ПЗ.

Наведемо наступну класифікацію типів відмов:

v  апаратний, при якому загальносистемне ПЗ непрацездатне;

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

v  ергономічний, викликаний помилками оператора при його взаємодії з машиною;

v  програмний, за наявності помилок у компонентах та ін.

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

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

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

Команда розробників системи може також змінити синтаксис і семантику опису системи. Однак деякі помилки можуть бути не виявлені (наприклад, неправильно задані індекси або значення змінних цих операторів).

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

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

Кількісні оцінки під час тестування

Часто техніки тестування плутають з цілями тестування. Ступінь покриття тестами — не те ж саме, що висока якість тестованої системи. Однак, ці питання пов’язані. Чим вище ступінь покриття, тим більше ймовірність виявлення прихованих дефектів. Коли ми говоримо про результати тестування, ми повинні підходити до їх оцінки, як до оцінки самої тестованої системи. Саме кількісні оцінки результатів тестування (але не самих тестів, наприклад, покриття ними можливих сценаріїв роботи системи) висвітлюються нижче.

Вимірювання є інструментом аналізу якості. Вимірювання результатів тестування стосується оцінки якості одержуваного продукту — програмної системи. Історія вимірювань демонструє прогрес досягнення прийнятної якості.

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

 

 

Питання для самоконтролю:

1.       Описати область знань «тестування програмного забезпечення», виділити її основні проблеми.

2.       Надати визначення поняттю тестування.

3.       Недоліки та збої (Faults vs Failures).

4.       Пояснити, яким чином треба вимірювати та аналізувати результати тестування (Test—related measures).

5.       Навести типи дефектів, класифікувати дефекти, оцінити статистику їх виникнення.

6.       Надати визначення поняттю щільності дефектів (Fault density).