Реферат
кваліфікаційної роботи магістра
«Складання тестових послідовностей на основі об'єктно-орієнтованих моделей»

      Вступ

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

      Актуальність теми

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

      Цілі та завдання розробки

      Метою магістерської роботи є створення автоматизованої системи складання тестових послідовностей на основі об'єктно-орієнтованої моделі.

      Основними цілями системи є:

1) оптимізація набору тестів;

2) сскорочення терміну тестування;

3) підвищення покриття системи.

      Загальна постановка задачі

      Процесс разработки программного обеспечения состоит из 5 этапов: выдвижение требований, анализ, проектирование, разработка, тестирование [1].

      Процес розробки програмного забезпечення складається з 5 етапів: висування вимог, аналіз, проектування, розробка, тестування [1]. Виробництво якісного програмного забезпечення є основним завданням розробників. Але крім самої розробки, багато часу і коштів витрачається на перевірку продукту, що випускається. Процес тестування програмного забезпечення дозволяє дати оцінку якості програмного продукту, оцінити готовність його до впровадження. На сьогоднішній день методи тестування не дозволяють виявити всі можливі «несправності» при розгляді великих інформаційних систем і дати однозначну відповідь про коректність роботи програмного забезпечення [1]. Але в основному від якості перевірки буде, залежить, наскільки хорошим і популярним буде даний продукт.

      Тестуючи досить не велику модель, можна перевірити практично всі варіанти виконання системи. Але якщо система велика, то кількість тестів і час їх виконання може стати серйозною проблемою для розробників і тестувальників. У зв'язку з цим з'являється задача оптимізації тестових наборів. Для цієї мети використовуються критерії тестового покриття. Критерії тестового покриття це певний набір умов, виконавши який можно сказати, що система успішно пройшла тестування. На даний момент вважається, що хороший відсоток покриття 60 – 70% [2].

      Перелічимо найпоширеніші критерії тестового покриття:

• Statement coverage – в тестовому наборі Т, кожне стан буде виконано хоча б раз;
• Branch coverage – в тестовому наборі Т, кожен оператор розгалуження повинен бути виконаний як для значення true так і для значення false;
• Conditional coverage – кожне умова в графі повинно бути виконано як для true так і для false;
• Path coverage – в тестовому наборі Т, кожен перехід повинен бути пройдений хоча б раз.[2]

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

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

2) використання коду для перевірки системи є складною і трудомісткою завданням;

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

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

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

      Розрізняють 3 види тестування:

1) тестування чорного ящика;

2) тестування білого ящика;

3) тестування сірого ящика.

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

      При розгляді питань тестування на підставі об'єктно-орієнтованих моделей Test Case являє собою набір констант, значень змінних, які призводять систему в одне із станів. Для того що б зрозуміти чи працює система правильно, порівнюється test oracle – очікуваний результат системи після тестування і actual result – результат який тестувальник отримує після тестування. На підставі аналізу отриманих результатів роблять висновки, чи був тест пройдено.

      В основе тестирования объектно-ориентированных моделей лежит так называемые серый ящик, это вид тестирования, когда разработчику тестов доступен не весь код, но алгоритм процесса и все возможные условия которые могут повлиять на конечный результат выполнения программы.

      При рассмотрении вопросов тестирования на основании объектно-ориентированных моделей Test Case представляет собой набор констант, значений переменных, которые приводят систему в одно из состояний. Для того что бы понять работает ли система правильно, сравнивается test oracle – ожидаемый результат системы после тестирования и actual result – результат который тестировщик получает после тестирования. На основании анализа полученных результатов делают выводы, был ли тест пройден.

      Представлення моделей

      Будь-яку модель системи або програми можна розглядати як функцію , де S це набір можливих вхідних значень і R це набір можливих результатів. Більш формально S це набір векторів , так щоб де Dxi є областю вхідних змінних xi.

      Потік управління графа (Control Flowgraph) моделі P це спрямований граф G = (N, E, s, e) який складається з набору вузлів N і набору ребер ) з'єднаних з вузлами. У кожному графі є два спеціальних вузла вхідний вузол s і вихідний вузол e [3].

      Кожен вузол можна вважати базовим блоком, який інтерпретується як послідовність інструкцій. Виконання блоку можна розуміти як виконання послідовності інструкцій в цьому блоці. Ребро між двома вузлами n і m, відповідає можливого переходу з n в m. Кожне ребро є предикат з умовою. Предикат може бути й без умови - порожній предикат, значення якого завжди true.

      Шлях – це послідовність вузлів, де pqp це останній вузол шляху. Виконання моделі P c вхідними параметрами xi означає, що сценарій з вхідними параметрами xi призводить до проходження по шляху p. Шлях називають здійсненним, якщо існує xi S перетинає шлях, інакше його називають не здійсненним.

      На рисунку 1 представлена схема генерації тестових даних запропонована Бейзером.

Рисунок 1 – Схема генерації тестових даних
(Анимация:обсяг – 23,7 КБ; розмір – 462х446; кількість кадрів – 4; затримка між кадрами 500 мс;
ккількість циклів повторення – нескінченна)

      Виходячи з тверджень Бейзера, були створені описи для діаграм послідовності, представлені нижче [2].

      Кожна діаграма являє собою запис наступного виду D = (A, T, F, C, a1, af), де:

• A = (a1, a2 ... am) це набір стан діаграми діяльності;
• T = (t1, t2 ... tn) це набір переходів діаграми діяльності ;
• С={с1,с2…cn} це набір граничних умов, сi відповідає ti. Сon це відображення значення ti, тобто Сon(ti)= сi.
• це потік зв'язків між діями та переходами
• a1 початковий вузол, af кінцевий вузол

      Для генерації Test Cases нам необхідно порівняти виконання програми з динамічним виконанням діаграми діяльності [2].

      Методика формування Test Case

      СІснує безліч різних алгоритмів для побудови тестів по моделі системи. І найчастіше дана процедура містить три основні кроки:

1) формування системи і введення обмежень і умов;

2) інтерпретація моделі у вигляді графа;

3) 3) складання тестових послідовностей (test case).

      Розглянемо ці кроки докладніше

       Формування системи і введення обмежень та умов.

      Для того що б почати процес складання Test Cases необхідно спершу скласти модель проекту. Для розробки проекту будемо використовувати UML. Поява OCL (Object Constraint Language) дало можливість накладати додаткові умови в UML-моделі. Умови, що задаються за допомогою OCL, дозволяють розглянути діаграми послідовності та діяльності, як розширені сценарії поведінки системи.

      Интерпретация модели в виде графа

      Інтерпретація моделі у вигляді графа. Часто для формування тестових послідовностей використовують Структурований складовою граф (Structured Composite Graph). Це робиться для того що б систематично досліджувати потоки управління моделі. Інформація, яка зберігатиметься в діаграмі перетворюється, і зберігатися в структурованому складеному графі. По черзі всі стани діаграми досліджуються і розташовуються на графі. Для автоматизації процесу формування тестових послідовностей подання діаграми у вигляді графа є дуже зручним. Розглянута модель повинна містити інформацію та вимоги до можливих значень змінних і до вхідних даних, які призводять до зміни стану системи.

      Складання тестових послідовностей (Test Case)

      Завдання полягає в тому, щоб згенерувати такий набір вхідних даних xi для моделі P та шляхи u, що б набір xi привів до руху за сценарієм u. Виділяють три класи методів генерації тестових послідовностей: генерація випадкових тестових даних (random), цілеспрямована генерація даних (goal-oriented), генерація даних з використанням шляху (path-oriented).

      Генерація випадкових тестових даних (random)

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

      Цілеспрямована генерація даних (goal-oriented)

      Этот метод намного эффективнее случайной генерации. В место того чтобы сгенерировать данные которые позволяют рассмотреть модель от начала до конца, метод генерирует такой набор данных который позволит пересечь заданный неспецифический (unspecific) путь.

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

      Генерація даних з використанням шляху (path-oriented)

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

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

       На данний момент система не реалізована.

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

      1. Journal of Object Technology 2008// A Novel Approach to Generate Test Cases from UML Activity Diagrams.

      2. Journal of Object Technology 2008// Automatic Test Data Synthesis using UML Sequence Diagrams [Електронный ресурс] доступ до статті: http://www.jot.fm/issues/issue_2010_03/article2.pdf

      3. A survey on automatic test data generation. In Proceedings of the Second Conference on Computer Science and Engineering in Linkoping, pages 21-28.ECSEL, October 1999.

      4. B. Beizer. Software Testing Techniques. Van Nostrand Reinhold, 2nd edition, 1990.

      5. K. Chang, W. Carlisle, J. Cross II, and D. Brown. A heuristic approach for test case generation. In Proceedings of the 1991 ACM Computer Science Conference, pages 174{180. ACM, 1991.

      6. W. H. Deason, D. Brown, K. Chang, and J. H. Cross II. A rule-based software test data generator. IEEE Transactions on Knowledge and Data Engineering, 3(1):108{117, March 1991.

      7. R. A. DeMillo and A. J. Outt. Constraint-based automatic test data generation. IEEE Transactions on Software Engineering, 17(9):900{910, September 1991.

      8. R. Ferguson and B. Korel. The chaining approach for software test data generation. IEEE Transactions on Software Engineering, 5(1):63{86, January 1996.

      9. R. Ferguson and B. Korel. Generating test data for distributed software using the chaining approach. Information and Software Technology, 38(1):343{353, January 1996.

      10. N. Gupta, A. P. Mathur, and M. L. Soa. Automated test data generation using an iterative relaxation method. In Proceedings of the ACM SIGSOFT sixth international symposium on Foundations of software engineering, pages 231{244, November 1998.

      11. B. Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870{879, August 1990.

ДонНТУ
Портал магістрів

Біографія