Генератор тестів InputSpace TestGenerator. Частина 1., Різне, Програмування, статті

Про систематичному тестуванні

Підхід


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


Коли ми говоримо про повне або вичерпному тестуванні, то маємо на увазі, що перевірені всі можливі варіанти використання програмного засобу. Розуміючи нездійсненність в загальному випадку вирішення такої завдання, необхідно розглядати її як ідеал, до якого потрібно прагнути, проводячи систематичне тестування програмного об’єкта. В якості наближення до нього природно ввести визначення систематичного тестування як тестування, що охоплює всі «гілки» додатка або всю його інфраструктуру на рівні, по-крайней мере, класів еквівалентності. Іншими словами, тут систематичність розглядається в першу чергу як «рівномірність», а не «щільність» охоплення в якості вихідного пріоритету.


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


Вхідна простір програми


Використання програмного засобу для вирішення задач кінцевого користувача передбачає певні фізичні маніпуляції користувача з конкретним екземпляром запущеного програмного продукту (які абстрактно можна назвати командами і вводами). При цьому інфраструктура (всі її зовнішні інтерфейси, зовнішня будова) програмного засобу визначає той горизонт, в рамках може діяти користувач. Для оцінки «повноти тестування» необхідно ввести поняття потенційно повного вхідного простору додатки як формального подання всіх можливих маніпуляцій (вводів і команд) кінцевого користувача (Актора), що допускаються конструктивно відповідним цьому додатком програмним засобом. «Структура» цього простору буде визначатися будовою інфраструктури конкретного програмного засобу. Якщо ми виділяємо, маючи на увазі інструмент InputSpace TestGenerator, систематичне тестування вхід / вихід в окрему підзадачі, то в загальному випадку, необхідно сформулювати умови коректності такого виділення (виділення без втрати хоча б потенційної повноти повного вхідного простору).


Методична частина. Операції вхід / вихід в моделі програми


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


Пропонується типова модель системного тестування програмного засобу з графічним призначеним для користувача інтерфейсом (ДПІ). Ця модель будується на основі декомпозиції інфраструктури програмного засобу і на цій основі розбиття загальної задачі систематичного тестування на окремі види.


Про інфраструктуру прикладного програмного забезпечення


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


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



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


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


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


Відділення графічного інтерфейсу користувача


Обмежимося розглядом додатків, орієнтованих на графічний користувальницький інтерфейс (ДПІ).


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


Рисунок 1: інфраструктура додатки з ДПІ.


Інфраструктуру додатки з ДПІ можна розглядати в двох розрізах: «вертикальному» (команди, обмін даними) і «горизонтальному» (навігація по додатком).


У першому випадку (рисунок 1) можна абстрагуватися від маніпуляційного аспекту і розглядати його як засіб обміну даними між користувачем та програмою. Це в основному статичний аспект розгляду. З цієї точки зору правильність ДПІ можна розглядати як відповідність між зовнішніми входами і виходами в додаток і, зворотного, між «внутрішніми» входами і засобами відображення. У другому випадку розглядається динамічний аспект програми – забезпечення навігації для реалізації сценаріїв вирішення користувальницьких задач.


Програмне гніздо


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


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


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


Таблиця 1. Організація гнізда і вводів.














































№ № п. / п.


Шар компонентів ДПІ


 


Функція програми


 


Підвид тестування


Входить до компетенції InputSpaceTestGenerator

1


Спрацювання командного контрола


Передача команди додатком


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


Немає

2


Порядок обходу входів гнізда при введенні значень


Можлива зміна стану гнізда від послідовності вводів


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


Та

3


Посимвольної введення значень


Контроль формату і синтаксичної правильності вводів


Синтаксичне тестування


Немає

4


Конкретне вводиться значення


Контроль приналежності вводяться значень граничним інтервалам входу


Тестування граничних інтервалів


Та

5


Сукупність значень, що вводяться гнізда


Контроль приналежності вводяться значень доменам взаємозалежних входів


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


Немає

6


Завершення введення


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


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


Немає


Другий рівень – це транзакції вхід / вихід. Тестування вхід / вихід охоплює основну прикладну функціональність програмного засобу. Основне призначення програмного засобу InputSpace TestGenerator – Контрольована розробником тест-проекту генерація тест-наборів для тестування вхід / вихід на рівні програмних гнізд. Центральне значення при цьому має гіпотетичне структурування вхідного простору програмного гнізда для виділення пріоритетних підмножин тестових прикладів.


Сценарії використання


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



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


Транзакції кроків завдання можна класифікувати по відсутності / наявності і особливостей перерахованих складових.


Тестування вхід / вихід і тестування управління програмним об’єктом (горизонтальний розріз) в загальному випадку не є незалежними. За характером управління прикладних програм можна виділити два крайніх випадку.


1. Потік управління не пов’язаний з потоком даних. Управління зводиться до простого включенню необхідних функцій. Приклад – управління типу меню. В цьому випадку тестування вхід / вихід не залежить від потоку даних.


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


Одне і те ж гніздо входів в дизайні ДПІ може, взагалі кажучи, знаходитися в більш, ніж одному стані (зміна числа активних входів, зміна параметрів доменів). Це пов’язано з тим, що таке гніздо може використовуватися в різних користувальницьких сценаріях. Крім того, стан гнізда може залежати від зовнішніх глобальних параметрів (наприклад, налаштувань).


Підсумки


1. Тестування для користувача інтерфейсу виділяється в окремо проведену автономну задачу. Тестування вхід / вихід доцільно проводити після завершення тестування користувальницького інтерфейсу.


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


3. Тестування потоку зовнішнього управління виділяється в окрему підзадачі. В рамках неї проводиться сценарний аналіз операцій вхід / вихід. Він включає:



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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*