zinet home
home home
home ИНТЕЛЛЕКТ-ПОРТАЛ
home Стартовал прием материалов в сборник XХХIX-й научной конференции. Требования к публикациям - в разделе "Объявления".

На главную | Объявления | Отчеты предыдущих конференций | История Украины | Контакты

РЕСУРСЫ ПОРТАЛА:

Тридцать восьмая научно-практическая конференция
(23 - 28 мая 2016 г.)


Тридцать седьмая научно-практическая конференция
(19 - 22 апреля 2016 г.)


Тридцать шестая научно-практическая конференция
(29 декабря 2015 - 5 января 2016 г.)


Тридцать пятая научно-практическая конференция
(24-27 ноября 2015 г.)


Тридцать четвертая научно-практическая конференция
(13-17 октября 2015 г.)


Тридцать третья научно-практическая конференция
(20-27 мая 2015 г.)


Тридцать вторая научно-практическая конференция
(2-7 апреля 2015 г.)


Тридцать первая научно-практическая конференция
(25 февраля - 1 марта 2015 г.)


Тридцатая научно-практическая конференция
(19-25 января 2015 г.)


Двадцать девятая международная научно-практическая конференция
(19-25 ноября 2014 г.)


Двадцать восьмая международная научно-практическая конференция
(08-13 октября 2014 г.)


Двадцать седьмая научно-практическая конференция
(20-25 мая 2014 г.)


Двадцать шестая научно-практическая конференция
(7-11 апреля 2014 г.)


Двадцать пятая юбилейная научно-практическая конференция
(3-7 марта 2014 г.)


Двадцать четвертая научно-практическая конференция
(20-25 января 2014 г.)


Двадцать третья научно-практическая конференция
(10-15 декабя 2013 г.)


Двадцать вторая научно-практическая конференция
(4-9 ноябя 2013 г.)


Первая международная научно-практическая конференция
(14-18 мая 2013 г.)


Двадцать первая научно-практическая конференция
(14-18 мая 2013 г.)


Двадцатая научно-практическая конференция
(20-28 апреля 2013 г.)


Девятнадцатая научно-практическая конференция
(26 февряля - 3 марта 2013 г.)


Восемнадцатая научно-практическая конференция
(22-26 декабря 2012 г.)


Семнадцатая научно-практическая конференция
(22-26 октября 2012 г.)


Шестнадцатая научно-практическая конференция
(09-14 апреля 2012 г.)


Пятнадцатая научно-практическая конференция
(01 - 07 марта 2012 г.)


Четырнадцатая научно-практическая конференция
(12-20 декабря 2011 г.)


Тринадцатая научно-практическая конференция
(28 октября - 09 ноября 2011 г.)


Двенадцатая научно-практическая конференция
(28 мая - 06 июня 2011 г.)


Одинадцатая научно-практическая конференция
(26 апреля - 04 мая 2011 г.)


Десятая научно-практическая конференция
(15-23 марта 2011 г.)


Девятая научно-практическая конференция
(27-31 декабря 2010 г.)


Восьмая научно-практическая конференция
(05-12 декабря 2010 г.)


Седьмая научно-практическая конференция
(28 мая - 7 июня 2010 г.)


Шестая научно-практическая конференция
(1-15 апреля 2010 г.)


Пятая научно-практическая конференция
(20-27 мая 2009 г.)


Четвертая научно-практическая конференция
(10-17 апреля 2009 г.)


Третья научно-практическая конференция
(20-27 декабря 2008 г.)


Вторая научно-практическая конференция
(1-7 ноября 2008 г.)


Первая научно-практическая конференция
(10-15 мая 2008 г.)



НАШИ ПАРТНЕРЫ:

Студия веб-дизайна www.zinet.info



Студия ландшафтного дизайна Флора-МК


Уникальное предложение!



Сайт-визитка - теперь
всего за 200 грн!

подробнее>>>



УДК 004.4

 

МЕТОД АВТОМАТИЧНОЇ ГЕНЕРАЦІЇ ТЕСТІВ НА ОСНОВІ ГРАМАТИК

 

Станкевич О.А.

Україна, м. Київ, Національний технічний університет України

«Київський політехнічний інститут»

 

Статья посвящена актуальной на сегодняшний день проблеме разработки тестового множества для автоматизированного тестирования приложений. Проведен анализ существующих подходов к формированию тестовых множеств: классы эквивалентности, граничное тестирование, выбор лучших представителей и анализ причинно-следственных связей. Перечисленным подходам противопоставляется еще один вид тестирования, называемый фазз-тестированием. Автором предложен метод автоматической генерации тестовых множеств, базирующийся на построении контекстно-свободных грамматик.

 

1.      Вступ

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

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

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

Існує багато інструментів для проектування автоматизованих тестів програмного забезпечення. Вибір інструменту залежить від середи розробки продукту, який підлягатиме тестуванню, а також від виду тестування, яке необхідно виконати. Найпоширенішими інструментами є HP LoadRunner, HP QuickTest Professional, HP Quality Center, Segue SilkPerformer, IBM Rational FunctionalTester, IBM Rational PerformanceTester, IBM Rational TestStudio, SmartBear Software TestComplete [2, 3, 4, 5].

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

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

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

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

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

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

 

2.      Постановка задачі

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

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

1)      дані успішно закодовані та штих-код відображається на ярлику;

2)      введено недопустимі дані, відображається інформація про відповідну помилку;

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

 

3.      Класичні підходи до формування тестової множини: класи еквівалентності, граничне тестування

Розглянемо, як формується тестова множина при тестуванні чорного ящика.

Тестування чорного ящика (black-box testing) – це тестування, при якому тестувальник має доступ до ПЗ тільки через ті самі інтерфейси, що і замовник або користувач, або через зовнішні інтерфейси, що дозволяють іншому комп’ютеру або іншому процесу підключитися до системи для тестування [6].

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

Тестування за класами еквівалентності (Equivalence class testing). Клас еквівалентності – це множина значень змінної, що, за припущенням, є еквівалентними. Контрольні приклади є еквівалентними, якщо виконується наступна сукупність вимог:

1)      Всі вони перевіряють один об’єкт;

2)      Якщо один із них «спіймає» дефект, то інший також;

3)      Якщо один із них не виявляє дефект, то інший, скоріше за все, також цього не зробить [6].

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

Хоч тестування за класами еквівалентності значно краще за вибір випадкових тестів, цей метод має свої недоліки, а саме:

1.      Знаходження класів еквівалентності є задачею евристичного характеру. Тестувальник визначає їх самостійно і завжди ризикує не визначити всі класи еквівалентності.

2.      Є ризик пропустити деякі високоефективні тести.

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

Граничне тестування (Boundary testing). Граничні значення – це найбільші та найменші значення класів еквівалентності. При тестуванні граничних значень тестуються також значення менше за мале, та більше за велике [6]. Граничне тестування, якщо воно було застосовано правильно, дозволяє виявити велику кількість помилок, але виявлення границь для кожної задачі може виявитись окремою складною задачею. Крім того, цей метод не перевіряє комбінації вхідних значень.

Тестування кращих представників (Best representative testing). Тестування значень, що найбільш вірогідно призведуть до виявлення дефекту. Значення завжди можна змінити різними шляхами. Треба покрити всі можливі варіанти [6]. Такий підхід може бути використаний лише тестувальником з великим досвідом. У значній мірі вибір кращих представників засновується на інтуїції.

Аналіз причинно-наслідкових зв’язків - ще один вид тестування, що може бути застосовний до чорного ящика. Під причиною розуміється окрема вхідна умова або клас еквівалентності. Наслідок являє собою вихідну умову або перетворення системи. Кожним причині та наслідку привласнюється номер. На основі аналізу семантичного змісту специфікації будується таблиця істинності, у якій послідовно перебираються всі можливі комбінації причин та визначаються наслідки для кожної комбінації причин. Недоліком такого підходу є погане дослідження граничних умов [7].

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

Існує ще одна техніка тестування чорного ящика, яка дозволяє вирішити описані проблеми – це фаз-тестування.

 

4.      Фаз-тестування (fuzz-testing)

Фаз-тестування (fuzz-testing, fizzing) – це техніка тестування чорного ящика, у якій до системи, що тестується, подаються стресові, неочікувані вхідні дані та структури даних через зовнішні інтерфейси.

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

Програми і платформи, які використовуються для створення фаз-тестів або проводять фаз-тестування, називаються фазерами. За останні 10-15 років фаззінг поступово перетворився з техніки тестування у повноцінну дисципліну тестування з підтримкою як з боку досліджень в області безпеки, так і традиційного забезпечення якості (Quality Assurance (QA)) [8].

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

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

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

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

 

5.      Граматики

Детальну інформацію про теорію формальних мов а також породжуючі граматики можна знайти в [9].

Множина всіх непорожніх слів в алфавіті Σ позначається Σ+.

Множина всіх слів в алфавіті Σ позначається Σ*.

Слово, що не містить жодного символу (тобто послідовність довжини 0), називається порожнім словом і позначається ε.

Породжуючою граматикою (граматикою типу 0) (generative grammar, rewrite grammar) називається четвірка G Û ˂ N, Σ, P, S ˃, де N і Σ - кінцеві алфавіти, N ∩ Σ = , P (N Σ)+ Ч (N Σ) *, P звичайно і S N.

Тут Σ - основний алфавіт (термінальний алфавіт), його елементи називаються термінальними символами або терміналами (terminal), N - допоміжний алфавіт (нетермінальний алфавіт), його елементи називаються нетермінальними символами, нетерміналами або змінними (nonterminal, variable), S - початковий символ (аксіома) (start symbol). Пари (α, β) P називаються правилами підстановки, просто правилами або продукціями (rewriting rule, production) і записуються у вигляді α → β.

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

Контекстно-вільною граматикою (КВ-граматикою, бесконтекстною граматикою, граматикою типу 2) (context-free grammar) називається породжуюча граматика, кожне правило якої має вигляд A → α, де A N, α (N Σ) *.

Граматика в нормальній формі Хомського (граматика в бінарній нормальній формі, квадратична граматика) (grammar in Chomsky normal form) - контекстно-вільна граматика ˂ N, Σ, P, S ˃, в якій кожне правило має один з наступних трьох видів: S → ε, A → a, A → BC, де A N, B N - {S}, C N - {S}, a Σ [9].

 

6.      Приклад граматики

Розглянемо запропоновану концепцію на прикладі лінійного штрих-коду Code-128C. Стандарт штрих-коду Code-128 істотно відрізняється від таких широко поширених стандартів штрихового коду, як наприклад, EAN. Відмінності полягають, насамперед, у можливості кодування не тільки цифр, але і букв латинського алфавіту, а також спеціальних символів. Крім того, цифровий код у форматі Code 128 стає дуже компактним, що досягається за рахунок «подвійний пакування» даних, коли два числа записуються в один модуль штрих-коду. Літерні символи кодуються звичайним - «одиночним» способом, що робить буквений код у форматі Code 128 удвічі довший цифрового.

Для кодування всіх 128-ми символів ASCII передбачено три комплекти символів штрихового коду Code 128 - A, B і C, які можуть використовуватися всередині одного штрих-коду.

·         128A - символи у форматі ASCII від 00 до 95 (цифри від "0" до "9" і букви від «A» до «Z») та спеціальні символи;

·         128B - символи у форматі ASCII від 32 до 127 (цифри від "0" до "9", літери від «A» до «Z» і від «a» до «z») та спеціальні символи;

·         128C - символи у форматі ASCII від 00 до 99 (тільки для числових кодів) [10].

Для коду 128С основний алфавіт Σ матиме вигляд:

Σ = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}.

Допоміжний алфавіт буде таким:

N = {s, A1, A2, …, A38, A39},

де A1, …, A39 – відповідають позиціям символів у вхідній послідовності, що підлягатиме кодуванню. У випадку, що розглядається, закодувати можна максимум 40 символів. Таке обмеження було накладено програмним продуктом, що підлягає тестуванню.

Ще одне обмеження накладається на кількість символів, що підлягають кодуванню. У коді 128С можна закодувати тільки парну кількість символів.

За допомогою ξ позначатимемо будь-який символ з алфавіту Σ.

Побудована граматика має наступний вигляд:

s → ξ A1

A1ξ A2 | ξ

A2ξ A3

A3ξ A4 | ξ                                                         (1)

     …

A37ξ A38 | ξ

A38ξ A39

A39 ξ

Граматика (1) дозволяє згенерувати коректі дані для кодування символів у форматі Code-128C. Наступним етапом буде генерування некоректних послідовностей символів. В даному випадку, за допомогою аналогічних граматик будемо генерувати послідовності символів що матимуть:

a)      недопустимі символи;

b)      непарну кількість символів;

c)      більшу за допустиму кіль кількість символів.

 

7.        Висновки

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

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

 

Список використаних джерел

1.      І. Винниченко. Автоматизація процесів тестування.

2.      http://www8.hp.com/us/en/software-solutions/software.html?compURI=1172957#.UT9RXaIjY7w

3.      http://www.borland.com/products/silkperformer/

4.      ftp://ftp.software.ibm.com/software/rational/web/whitepapers/btia-probundle.pdf

5.      http://support.smartbear.com/viewarticle/32760/?st=%220%22

6.      Дідковська М.В., Тимошенко Ю.О. Тестування: Основні визначення, аксіоми та принципи.

7.      Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем. — Питер, 2004. — 320 с. —ISBN 5-94723-698-2

8.      A. Takanen, J.D. Demott, C. Miller. Fuzzing for Software Security and Quality Assurance.

9.      Пентус А. Е., Пентус М. Р. Теория формальных языков: Учебное пособие. — М.: Изд-во ЦПИ при механико-математическом ф-те МГУ, 2004. — 80 с.

10.  http://ru.wikipedia.org/wiki/Code_128



Первая научно-практическая конференция
"Инновационный потенциал украинской науки - ХХI век"
(10-15 мая 2008 г.)


(отчет)
Вторая научно-практическая конференция
"Инновационный потенциал украинской науки - ХХI век"
(1-7 ноября 2008 г.)
(отчет)
Третья научно-практическая конференция
"Инновационный потенциал украинской науки - ХХI век"
(20-27 декабря 2008 г.)
(отчет)
Четвертая научно-практическая конференция
(10-17 апреля 2009 г.)
(отчет)
Пятая научно-практическая конференция
(20-27 мая 2009 г.)
(отчет)
Шестая научно-практическая конференция
(1-15 апреля 2010 г.)
(отчет)
Седьмая научно-практическая конференция
(28 мая - 7 июня 2010 г.)
(отчет)
Восьмая научно-практическая конференция
(05-12 декабря 2010 г.)
(отчет)
Девятая научно-практическая конференция
(27-31 декабря 2010 г.)
(отчет)
Десятая научно-практическая конференция
(15-23 марта 2011 г.)
(отчет)
Одинадцатая научно-практическая конференция
(26 апреля 04 мая 2011 г.)
(отчет)
Двенадцатая научно-практическая конференция
(28 мая - 06 июня 2011 г.)
(отчет)
Тринадцатая научно-практическая конференция
(28 октября - 09 ноября 2011 г.)
(отчет)
Четырнадцатая научно-практическая конференция
(12-20 декабря 2011 г.)
(отчет)
Пятнадцатая научно-практическая конференция
(01-07 марта 2012 г.)
(отчет)
Шестнадцатая научно-практическая конференция
(09-14 апреля 2012 г.)
(отчет)
Семнадцатая научно-практическая конференция
(22-26 октября 2012 г.)
(отчет)
Восемнадцатая научно-практическая конференция
(22-26 декабря 2012 г.)
(отчет)
Девятнадцатая научно-практическая конференция
(26 февраля - 3 марта 2013 г.)
(отчет)
Двадцатая научно-практическая конференция
(20-28 апреля 2013 г.)
(отчет)
Двадцать первая научно-практическая конференция
(13-18 мая 2013 г.)
(отчет)
Первая международная научно-практическая конференция
"Перспективные направления отечественной науки - ХХI век"
(13-18 мая 2013 г.)
(отчет)
Двадцать вторая научно-практическая конференция
(4-9 ноября 2013 г.)
(отчет)
Двадцать третья научно-практическая конференция
(10-15 декабря 2013 г.)
(отчет)
Двадцать четвертая научно-практическая конференция
(20-25 января 2014 г.)
(отчет)
Двадцать пятая юбилейная научно-практическая конференция
(3-7 марта 2014 г.)
(отчет)
Двадцать шестая научно-практическая конференция
(7-11 апреля 2014 г.)
(отчет)
Двадцать седьмая научно-практическая конференция
(20-25 мая 2014 г.)
(отчет)
Двадцать восьмая научно-практическая конференция
(08-13 октября 2014 г.)
(отчет)
Двадцать девятая научно-практическая конференция"
(19-25 ноября 2014 г.)
(отчет)
Тридцатая научно-практическая конференция
(19-25 января 2015 г.)
(отчет)
Тридцать первая научно-практическая конференция
(25 февраля - 1 марта 2015 г.)
(отчет)
Тридцать вторая научно-практическая конференция
(2 - 7 апреля 2015 г.)
(отчет)
Тридцать третья научно-практическая конференция
(20 - 27 мая 2015 г.)
(отчет)
Тридцать четвертая научно-практическая конференция
(13 - 17 октября 2015 г.)
(отчет)
Тридцать пятая научно-практическая конференция
(24 - 27 ноября 2015 г.)
(отчет)
Тридцать шестая научно-практическая конференция
(29 декабря 2015 - 5 января 2016 г.)
(отчет)
Тридцать седьмая научно-практическая конференция
(19 - 22 апреля 2016 г.)
(отчет)
Тридцать восьмая научно-практическая конференция
(23 - 25 мая 2016 г.)
(отчет)

На главную | Объявления | Отчеты предыдущих конференций | История Украины | Контакты

Copyright © Zinet.info. Разработка и поддержка сайта - Студия веб-дизайна Zinet.info