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

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

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

Скиба О.В., Камак Д.О., Руденко О.В., Кравченко В.С.

Державний науково-дослідний інститут випробувань і сертифікації озброєння та військової техніки

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

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

Ключові слова: програмне забезпечення, тестування програмного забезпечення, техніка тестування програмного забезпечення, класи еквівалентності, еквівалентне розбиття, граничні значення.

APPLICATION OF TECHNIQUE OF INPUT DATA SEPARATING INTO EQUIVALENCE CLASSES FOR OPTIMIZATION OF SPECIAL SOFTWARE CHECKING O Skyba, D Kamak, O Rudenko and V Kravchenko

Usually, planning a software testing requires solving the basic dilemma: how to provide quality of testing and spend optimal amount of resources. Typically, resources include components such as personnel, software, technical equipment, time, consumables and others.

The Armed Forces of Ukraine have the same problems in planning and testing of programs that are expected to be used in the interests of troops and arms command and control.

Testing can be performed by manual method and computer-aided method. The computer-aided method is faster but has its drawbacks. In particular, this method requires the development and then verification of a special program that will be involved in testing. In addition, this program may not detect certain problems that a person can notice.

Therefore, the authors of the article propose to use the method of manual testing. It is proposed to apply a rational approach for reducing the time for planning and testing using this method.

It refers to a significant reduction in the range of input values which will be checked. This approach provides a high quality testing program at the same time.

The approach is based on the fact that the range (or list) of all possible values of each input variable is divided into several groups (equivalence classes). The separation is carried out by the principle that each equivalence class includes such input values, which will give the similar results after processing them by program.

This approach is widely used by experts in the field of testing. It also meets the standards requirements applicable in Ukraine.

There are two general classes of equivalence: accepted values and nonaccepted values. Each of them is divided into more specific ones. The separation is done leaning upon knowledge, skills and predictions of a specialist who is planning the testing.

This article provides an example of dividing the input values offour variables into equivalence classes.

The approach proposed by the authors of the publication allows to perform software testing faster and more rationally.

It is assumed that such a method should be used during testing software that is intended to be used in the interests of the Armed Forces of Ukraine.

Keywords: software, software testing, software testing techniques, equivalence classes, equivalence partition, threshold values.

Постановка проблеми

еквівалентність програмний інформаційний

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

З одного боку, якщо перевірити усі можливі варіанти вхідних даних та режимів роботи ПЗ, то якість тестування вважатиметься достатньо високою (хоча, як зазначено у [1, С. 135], "...все ошибки найти невозможно”). З іншого, якщо програма має велику кількість вхідних значень, які у свою чергу мають широкий діапазон допустимих величин, перевірка може затягнутися на місяці.

У такому випадку необхідно вміти знаходити раціональний компроміс між якістю та витратами.

Актуальність дослідження

Це питання є актуальним у сфері перевірки окремих ПП, які передбачається застосовувати у стаціонарних умовах на об'єктах Збройних Сил України (ЗС України) і на озброєнні та військовій техніці (ОВТ), що функціонує під керівництвом спеціального ПЗ (СПЗ).

Як засвідчує досвід постачання ПП до ЗС України, програмні засоби передаються готовим продуктом з інсталяційним пакетом та експлуатаційною документацією. Програмний код розробниками не надається, що, в принципі, не суперечить загальноприйнятим правилам, оскільки є інтелектуальною власністю.

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

Аналіз інших джерел

Автори більшості опрацьованих навчальних посібників та тематичної літератури, що розкривають підходи та техніки тестування ПЗ, переконують у тому, що перебір всіх можливих варіантів комбінацій вхідних даних є ірраціональним та не виправданим [1, 2, 3]. Для того, щоб організувати й провести оптимальну перевірку ПЗ, авторами статті пропонується всі вхідні дані розділити на класи еквівалентності, що є достатньо розповсюдженим підходом:

"Избегайте избыточных, дублирующих друг друга тест-кейсов. Минимизировать их количество вам помогут техники классов эквивалентности, граничных условий” [1, С. 137];

"Используйте разбиение на эквивалентные классы и анализ граничных значений для снижения трудозатрат на тестирование” [2, С. 61];

"В тестировании ... применяются различные стратегии тестирования: зависящие от выполняемых действий, от данных (включая анализ значений границ и разбиения на эквивалентные классы)” [3, С. 338].

Застосування класів еквівалентності також передбачають і державні стандарти України, які стосуються тестування ПЗ [4].

Зв'язок авторського доробку з практичними завданнями

Практика випробувальної діяльності Державного науково-дослідного інституту випробувань і сертифікації озброєння та військової техніки переконує, що СПЗ, яке планується використовувати в інтересах ЗС України, обов'язково повинно бути протестовано та оцінено.

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

Виклад основного матеріалу

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

Такий підхід відповідає [4, п. 4.11], у якому зазначено, що еквівалентне розбиття - це "підмножина діапазону значень змінної або множини змінних усередині об'єкта тестування чи на його інтерфейсах, щодо якої можна обґрунтовано очікувати, що всі значення в ній будуть сприйматися об'єктом тестування аналогічно (тобто їх можна вважати еквівалентними)”.

У чому полягає суть такого підходу?

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

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

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

Яким чином це застосувати для перевірки не одного, а кількох вхідних значень? У цьому випадку складають комбінації допустимих ("правильних”) та недопустимих ("неправильних”) значень.

Для кращого розуміння та засвоєння цього підходу пропонується розглянути це на прикладі розрахункової задачі (як елемент СПЗ, що може використовуватися в інтересах протиповітряної оборони) - рисунок 1 (при цьому прийнято, що для градусної міри курсу число 360 не використовується і є недопустимим вхідним значенням).

Рис. 1. Вигляд діалогового вікна навчальної інформаційно-розрахункової задачі

Як видно з рисунку 1, для проведення розрахунку використовуються 4 вхідні значення. Кожне з них має свій діапазон допустимих цілих значень. Якщо перевірити правильність проведення розрахунку для всіх можливих комбінацій допустимих вхідних даних, їх кількість становитиме 2,9711Е+13 :

де N- кількість усіх можливих комбінацій допустимих вхідних даних;

Ndzi- кількість усіх можливих допустимих значень i-ї вхідної змінної.

Якщо припустити, що на введення вручну кожної комбінації даних та перевірку отриманих значень відвести 1 хвилину, це займе 20 633 187 750 діб або 56 529 282 роки. І це тільки для перевірки даних, які відповідають допустимому діапазону.

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

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

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

Такий підхід пропонується застосовувати багатьма фахівцями, зокрема і автором [5]: "... розрізняють два типи класів еквівалентності: правильні, що задають вхідні дані для програми, і неправильні, засновані на завданні помилкових вхідних значень” [5, С. 167].

Розглянемо це на прикладі вхідних даних швидкості польоту, для якого існує 2 751 можливе допустиме вхідне значення (від 250 до 3 000 км/год).

У загальному вигляді розбиття на класи еквівалентності наведено в таблиці 1.

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

Слід звернути увагу, що класи еквівалентності 2, 3, 4, 5 та 6 хоча й охоплюють множини недопустимих значень, вони не можуть бути об'єднані. Причиною цього є те, що очікувано ПЗ буде по-різному їх опрацьовувати та може видати відмінні результати.

Але класифікація на класи еквівалентності, надана у таблиці 1, не є кінцевою. Кожна множина розбивається на інші класи. І для цього фахівці пропонують такі підходи:

- обов'язковій перевірці підлягають граничні значення, які перебувають на межі допустимих і недопустимих діапазонів ("Обеспечьте тестирование граничных условий” [6, С. 380], "Необходимо протестировать каждую границу класса эквивалентности, причем с обеих сторон” [7, С. 192].Багато фахівців техніку перевірки граничних значень розцінюють як складову методики перевірки за класами еквівалентності [1, С. 81], [2, С. 109]. У вищенаведеному прикладі для швидкості польоту це такі значення: 250 (мінімально допустиме); 249 (недопустиме ціле число, яке межує з мінімально допустимим); 3000 (максимально допустиме); 3001 (недопустиме ціле число, яке межує з максимально допустимим);

- якщо допустимими значеннями є цілі числа, потрібно перевірити реагування програми на дробові числа, які лежать у межах між мінімальним та максимальним допустимими значеннями (у наведеному прикладі - між 250 та 3000). При цьому доцільно перевірити розділення цілої та дробової частини як комою, так і крапкою. Також рекомендується перевірити реагування ПЗ на введення дробової частини числа, представленої нулем (з крапкою та комою), наприклад, 423.0 та 423,0;

- число "0” перевіряється завжди, незалежно від того, до якого класу еквівалентності (допустимих чи недопустимих значень) відноситься;

- доцільно перевіряти допустимі дані з усіх можливих груп розрядності (одно-, дво-, трицифрові і т.д.) У нашому прикладі щодо швидкості - числа з трьох та чотирьох цифр, оскільки нижня межа допустимого діапазону є 250 (трицифрове), верхнє 3000 (чотирицифрове);

- перевірити, як вестиме себе ПЗ, якщо ввести число зі знаком "+”. У нашому прикладі плюсове число від 250 до 3000 є допустимим, тому знак "+” по суті нічого не міняє з точки зору обчислення. Але не відомо, яким чином програма зреагує на нього, оскільки цей символ не є числом;

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

При перевірці інших недопустимих значень для прикладу зі швидкістю польоту рекомендовано перевірити:

- додатні цілі числа від 1 до граничного числа (у нашому прикладі - до 248), при цьому можливо окремо перевірити одно-, дво- та трицифрові числа, які менші граничного числа та числа, більші максимально допустимого (у прикладі - більше 3000);

- додатні дробові значення з недопустимого діапазону, які наближені до мінімального та максимального допустимих значень (для наведеного прикладу можуть бути 249,999 та 3000,0001);

- від'ємні цілі значення;

- від'ємні дробові значення;

- літерні символи;

- літерно-цифрові символи;

- цифри з пробілом;

- пробіл;

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

Обов'язково перевірити поведінку ПП, якщо поле вводу залишити пустим.

Формування класів еквівалентності може додатково здійснюватися, виходячи і з інших поглядів, наприклад, виділити в окремий клас такі варіанти вхідних значень, коли замість числа в поле вводу вводитиметься вираз (типу 600:2) або додаватися перевірки граничних чисел для кожної розрядності (999 - для трицифрових, 1000 - для чотирицифрових) тощо.

Відповідно до [8, С. 83] "Определение классов эквивалентности осуществляется эвристическим способом”. Кожен фахівець виходить з власного досвіду та передбачень того, за яких значень вхідних даних ПЗ може працювати помилково.

Як зазначено у [1, С. 37], “Тестировщик мысленно моделирует процесс работы пользователя с системой... и ищет неоднозначные или вовсе неописанные варианты поведения системы”.

Отже, після проведеної класифікації класи еквівалентності виглядають дещо інакше (Таб. 2).

Табл. 2. Класи еквівалентності для швидкості польоту в деталізованому вигляді

Як видно, завдяки такій оптимізації кількість допустимих вхідних значень для швидкості польоту зменшилася до 4 (замість 2 751), тобто у 688 разів. Кількість всіх класів еквівалентності (з допустимих та недопустимих значень) становить 29, що у 95 разів менша від 2 751.

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

Для прикладу в таблиці 3 наводиться результат розбиття на класи еквівалентності значень курсу (від 0 до 359).

Табл. 3. Класи еквівалентності для курсу в деталізованому вигляді

Отримали 30 варіантів (у т. ч. 5 з допустимого діапазону) вхідних значень - замість 360.

Для інших двох параметрів (висоти та дальності) кількість класів еквівалентності також буде коливатися в районі 30.

Отже, орієнтовна кількість всіх комбінацій вхідних (швидкість, курс, висота, дальність) з визначених класів еквівалентності становитиме близько 783 тис. Але навіть не усі вони будуть застосовані, що описано далі у статті.

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

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

Існують також й інші судження. Так, у [2, С. 109] зазначено: "Нужно спроектировать такие тесты, которые выполняют проверку, по меньшей мере, одного представителя каждого допустимого класса ввода и, по меньшей мере, одного представителя недопустимого класса ввода”.

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

Відтак, пропонується обрати набір тестових даних, де лише один параметр буде з числа недопустимих значень.

У нашому прикладі класів еквівалентності недопустимих значень більша, ніж допустимих. Це означає, що кількість комбінацій дорівнюватиме сумі класів еквівалентності для недопустимих даних: близько 100 тест-кейсів (замість розрахованого по формулі (1) значення 2,9711Е+13). Відтак, тестування може зайняти лише біля півтора - двох годин.

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

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

Табл. 4. Приклад формування комбінацій (набору) вхідних тестових з урахуванням отриманих класів еквівалентності

Головні висновки та перспективи використання результатів дослідження

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

Він повинен відповідати існуючій нормативно-правовій базі та включати перспективні й найбільш оптимальні існуючі методи, які б і забезпечували належну якість перевірки, та не були не виправданно затратними.

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

Запропонований підхід пропонується до використання при плануванні і проведенні тестування СПЗ, що планується до використання в інтересах ЗС України.

Список літератури

1. Куликов С.С. Тестирование программного обеспечения: учебное пособие / С.С. Куликов. - Минск: БГУИР, 2019. - 276 с.

2. Калбертсон. Быстрое тестирование / Браун, Кобб. - М.: Издательский дом “Вильямс”, 2002. - 374 с.

3. Вигерс Карл. Разработка требований к программному обеспечению. Практические приемы сбора требований.и управления ими при разработке. программного продукта; перевод с англ. - М.: Издательско-торговый дом "Русская Редакция”, 2004. - 576 с.

4. Інженерія систем і програмних засобів. Тестування програмних засобів. Частина 1. Поняття та визначення (ISO/IEC/IEEE29119-1/2013, IDT): ДСТУ ISO/IEC/IEEE 291191:2017. - [Чинний від 2019-01-01]. - Київ: Держспоживстандарт України, 2018. - 53 с. (Державний стандарт України).

5. Лавріщева К.М. Програмна інженерія: підручник - К: Друкарня "Видавничого дому "Академперіодика” НАН України, 2008. - 319 с.

6. Криспин. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд.; пер. с англ. / Криспин, Лайза, Грегори, Джанет. - М.: ООО “Издательский дом. Вильямс”, 2010. - 464 с.

7. Канер Сэм. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений; пер. с англ. / Сэм Канер, Джек Фолк, Енг Кек Нгуен. К.: Издательство “ДиаСофт”, 2001. - 544 с.

8. Семахин А. М. Методы верификации и оценки качества программного обеспечения: учеб.пособие. - Курган : Издательство КГУ, 2018. - 150 с.

Размещено на Allbest.ru