Розробка пакету автоматизованого тестування програмних застосувань на платформі IOS

Зміст

 

Вступ

1. Аналіз технічного завдання

1.1 Обґрунтування доцільності розробки пакету автоматизованого тестування програми

1.2 Призначення пакету

1.3 Характеристика пакету

1.4 Основні вимоги до пакету

1.5 Вимоги до програмного забезпечення

2. Вибір та обґрунтування методики тестування та засобів для реалізації пакету

2.1 Опис функціональних можливостей додатка, що тестується

2.2 Аналіз можливості автоматизації тестування додатку

2.3 Вибір і обґрунтування функціонала для автоматизації

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

2.5 Вибір апаратної платформи

2.6 Обґрунтування вибору програмних методик та засобу тестування програмних застосувань для мобільних пристроїв

3. Розробка пакету автоматизованого тестування

3.1 Розробка методики тестування додатку

3.2 Розробка структури пакету автоматизованого тестування програмних застосувань для мобільних пристроїв на платформі iOS

3.3 Розробка модулів пакету автоматизованого тестування програмних застосувань для мобільних пристроїв на платформі iOS

4. Тестування пакету та рекомендації щодо використання пакету

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

4.2 Рекомендації, щодо використання пакету

5. Організаційно-економічний розділ

5.1 Функціонально-вартісний аналіз (ФВА)

5.2 Обґрунтування функцій програмного продукту

5.2.1 Виділення основних функцій

5.2.2 Опис основних функцій ПП

5.3 Обґрунтування системи параметрів

5.4 Аналіз варіантів реалізації функцій

5.5 Економічний аналіз варіантів ПП

5.5.1 Визначення витрат на розробку ПП

5.5.2 Оцінка техніко-економічного рівня варіантів ПП

5.6 Висновки до розділу

6. Охорона праці та безпека в надзвичайних ситуаціях

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

6.1.1 Аналіз приміщення

6.1.2 Повітря робочої зони

6.1.3 Виробниче освітлення

6.1.4 Захист від виробничого шуму і вібрації

6.1.6 Електробезпека

6.1.7 Безпека технологічних процесів та обслуговування обладнання

6.2 Пожежна безпека

6.3 Висновки до розділу

Висновки

Перелік посилань

Додаток

Перелік умовних позначень

ПЗ - програмне забезпечення

ПЗП - постійний запам’ятовуючий пристрій

ОЗП - оперативний запам’ятовуючий пристрій

МБ - мегабайт

ГБ - гігабайт

ГГц - гігагерц

ПП - програмний продукт

ОС - операційна система

ПК - персональний комп’ютер

ТОВ - товариство з обмеженою відповідальністю(Graphical User Interface) - графічний інтерфейс користувача

Вступ

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

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

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

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

Надійність

Супроводжуваність

Практичність

Ефективність

Мобільність

Функціональність

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

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

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

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

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

В даній роботі було представлено приклад автоматизації тестування програми Join It - Jigsaw Puzzle, розробленої ТОВ D-Studio.

програмний платформа тестування забезпечення

1. Аналіз технічного завдання

1.1 Обґрунтування доцільності розробки пакету автоматизованого тестування програми

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

Переваги автоматизації тестування:

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

·        Швидке виконання - автоматизованому скрипту не потрібно звірятися з інструкціями та документаціями, що сильно скорочує час виконання.

·        Менші витрати на підтримку - коли автоматичні скрипти вже написані, на їх підтримку та аналіз результатів витрачається, як правило, менша кількість часу ніж на проведення тієї ж кількості тестування вручну.

·        Звіти - звіти про результати тестування, що автоматично розсилаються та зберігаються.

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

Недоліки автоматизації тестування:

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

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

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

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

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

В досліджуваній програмі в зв’язку з комерційним використанням продукту дуже важливі:

·        Швидкість тестування

·        Маленькі витрати на розробку та підтримку

·        Безкоштовність платформи розробки пакету автоматизованого тестування

·        Ефективність тестування практично не змінного функціоналу

В зв’язку з вище зазначеними виробничими завданнями було прийнято рішення про автоматизацію тестування.

1.2 Призначення пакету

Даний пакет автоматизованого тестування призначений для тестування комерційного продукту Join It - Jigsaw Puzzle та, при невеликому доопрацюванні, для його похідних - Join It - Join The Hearts, Join It - uJigsawArt.

1.3 Характеристика пакету

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

Пакет розробляється спеціально для тестування програми Join It - Jigsaw Puzzle та його похідних спеціально для ООО D-Studio.

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

Пакет, що розробляється, може бути використаний тільки на персональних комп’ютерах Mac с ОЗП не менше 1 ГБ, процесором 1.7 ГГц Intel Core 2 Duo, ОС не менше Mac OS X 10.6 Snow Leopard.

Пакет використовується в програмі Instruments, яке являється частиною сфери розробки XCode версії не менше 4.0.

Пакет повністю підтримує мобільні прилади iPad, iPad 2, The New iPad, iPad 4, iPad Mini, iPhone 3GS, iPhone 4, iPhone 4s, iPhone 5, iPod Touch 3G, iPod Touch 4G.

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

Загальний розмір пакету - 50 МБ.

1.4 Основні вимоги до пакету

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

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

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

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

1.5 Вимоги до програмного забезпечення

Пакет має працювати на операційній системі Apple Mac OS X версії не менше 10.6 Snow Leopard.

Для використання пакету необхідна сфера розробки Apple XCode версії не менше 4.0 з встановленою утилітою Instruments від компанії Apple.

Для використання бібліотеки iOS Development Guide необхідно підключення до мережі Інтернет.

.6 Вимоги до технічного забезпечення

Пакет автоматизованого тестування що розробляється, повинен працювати на персональних комп’ютерах серії iMac (з 2006 року випуску) та Mac Mini (з 2006 року випуску).

Мінімальні системні вимоги:

·        Процесор - Intel Core 2 Duo 1.7 ГГц

·        ОЗП - 1 ГБ

Також, необхідно мобільний прилад сімейства iPad.

Характеристики iPad 2:

·        Процесор - 1 ГГц двояхдерний Apple A5

·        ОЗП - 512 МБ LPDDR2

·        Постійна пам'ять - 16 ГБ

Також в якості ПЗП можуть використовувався зовнішні накопичувачі та ресурси мережі.

2. Вибір та обґрунтування методики тестування та засобів для реалізації пакету

2.1 Опис функціональних можливостей додатка, що тестується

Join It - Jigsaw Puzzle - комерційний продукт компанії ТОВ D-Studio. Продукт в даний момент доступний на Apple App Store. Продукт являє собою додаток, що симулює роботу користувача з головоломкою - пазлом. Додаток має наступний функціонал:

Первинний функціонал:

.        Запуск додатку

2.      Демонстрація вступного ролика

Головний екран додатку зображено на рис.2.1.

Рисунок 2.1 - Головний екран додатку Join It - Jigsaw Puzzle

1.      Кнопка Допомога Натискання на кнопку Допомога призводить до демонстрації Екрану Допомоги

2.      Демонстрація Зображення На Головному Екрані відображується останнє вибране користувачем Зображення

.        Демонстрація Назви Зображення, вибраної Важкості На Головному Екрані демонструється поточна важкість Зображення і його назва

.        Кнопки Легко, Середнє, Важко, Нереально Данні кнопки встановлюють важкість Зображення, що збирається в залежності від її формату

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

6.      Кнопка Рекорди Натискання на кнопку Рекорди призводить до демонстрації меню Рекорди

7.      Кнопка Опції Натискання на кнопку Опції призводить до демонстрації меню з налаштуваннями гри

8.      Кнопка Про Фотографію Натискання на кнопку Про Фотографію призводить до демонстрації спливаючого вікна з інформацією о Зображенні: ім’я фотографа, посилання на зображення, інформацію о авторських правах. Вікно зникає через 3 секунди

9.      Кнопка Зберегти Натискання на кнопку Зберегти призводить до збереження Зображення на пристрій. У разі, якщо Зображення не було зібрано демонструється сповіщення "Водяний Знак. Незібране Зображення буде збережене х водяним знаком" з Кнопками Зберегти і Відміна. У разі, якщо Зображення було збережене раніше, демонструється сповіщення "Зберегти Зображення. Це Зображення уже раніше зберігалося в Бібліотеку. Хочете Зберегти його ще раз?" з Кнопками Зберегти и Відміна

10.    Кнопка Збільшити Натискання на кнопку Збільшити призводить до демонстрації Зображення на весь екран. У разі, якщо Зображення не було зібрано, по діагоналі Зображення відображується напис " Це Зображення ще не було зібрано. Зберіть пазл, щоб прибрати цей текст. "

.        Кнопки Наступна/Попередня Натискання на кнопку Наступна/Попередня призводить до переходу на наступне/попереднє Зображення колекції

.        Жест Flick Використання жесту Flick призводить до переходу на наступне/попереднє Зображення колекції

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

14.    Кнопка Старт Натискання на кнопку Старт починає Гру

Меню Колекції

1.      Кнопка Назад Натискання на кнопку Назад призводить до повернення на Головний Екран

2.      Кнопка Додати Зображення Натискання на кнопку Додати Зображення призводить до появлення спливаючого меню вибору джерела зображення

2.1.   Пункт Мої Фотографії Вибір пункту Меню Мої Фотографії призводить до вибору Зображення, яке знаходиться на пристрої

2.2.   Групи Flickr Користувач має можливість вибрати зображення з груп Інтернет ресурсу Flickr

3.      Вибір Колекції Користувач має можливість вибору Колекції зображень:

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

.        Зображення з позначкою "скачати" Натискання на Зображення с позначкою "скачати" призводить до завантаження Зображення з сервера компанії. Під час завантаження на Зображенні з’являється лічильник прогресу. Після завантаження позначка "скачати" зникає.

6.      Кнопка Правка Натискання на кнопку Правка переводить користувача в режим редагування

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

6.2.   Виставлення рейтингу Жест Flick під Зображенням (в районі трьох крапок) призводить до виставлення рейтингу Зображенню. Система рейтингу - Одна Зірка, Дві Зірки, Три Зірки відображують Один, Два и Три Бали відповідно. Помічені таким чином Зображення потрапляють в Колекцію Улюблені Зображення

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

6.4.   Кнопка Правка Повторне Натискання на кнопку Правка призводить до виходу з режиму редагування

7.      Жест Flick Жест Flick в області відображення зображень у групі призводить до "прокручування" колекції и демонстрації Зображень, що не вміщуються на екран

8.      Вибір Зображення для гри Натискання на будь яке із закачаних зображень призводить до переходу на Головний Екран і зміненню попереднього Зображення для Гри на вибране

Функціонал Екрану Допомоги

1.      Кнопка Назад Натискання на кнопку Назад призводить до переходу на Головний Екран

2.      Кнопки iPad Керування/ iPhone Керування Натискання на кнопки iPad Керування/ iPhone Керування призводить до змінення відображуваної інформації про керування

.        Демонстрація інструкцій по керуванню у грі, звернення від розробників, перечня розробників

.        Посилання support@joinitpuzzle.com Натискання на посилання призводить до відкриття додатку Пошта для відправки листа техпідтримці.

.        Посилання Веб-сайт гри Join It Натискання на посилання відкриває браузер для переходу на сайт додатку Join It - Jigsaw Puzzle.

Опції головного екрану

.        Перемикач Sticking Включення режиму Sticking включає відповідний Функціонал у грі. Дана функція дозволяє закріпити частини пазла на відповідаючому їм місці на Основному Зображенні.

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

.        Перемикач Таймер Включення перемикача Таймер призводить до появлення лічильника часу (таймера) у грі

.        Перемикач Звуки Вимикання перемикача Звуки призводить до відключення звука у Додатку

.        Перемикач Ділитися Результатами Включення перемикача Ділитися результатами призводить до автоматичної передачі результатів у Facebook і Twitter по закінченню Гри

.        Перемикач Керування Перемикач Керування призначений для переключення схеми керування iPad/iPhone

.        Перемикач Стиль Шматочків Перемикач Стиль Шматочків призначений для вибору стиля шматочків на які буде розбите Зображення перед початком Гри

.        Вибір Фона Ігрового Столу Користувачеві на Вибір надається 8 видів фона робочого столу, які будуть використані у грі.

Процес гри

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

2.      Повідомлення "Торкніться, щоб почати Гру" Перед початком Гри демонструється Повідомлення "Торкніться, щоб почати Гру"

3.      Кнопка Пауза Натискання на кнопку Пауза призводить до появлення Меню Паузи

.        Зборка Зображення Основний ігровий процес. Зборка вибраного Зображення з вибраної кількості шматочків певного типу

5.      Кнопка Опції Натискання на кнопку Опції призводить до демонстрації спливаючого Меню Опцій

.        Таймер Натискання на таймер призводить до його підсвічування

.        Перемога

a.      Кнопка Facebook Натискання на кнопку Facebook призводить до екрану "Опублікувати на Facebook"

b.      Кнопка Twitter Натискання на кнопку Twitter призводить до екрану "Опублікувати в Twitter"

c.       Кнопка Скріншот Натискання на кнопку Скріншот призводить до збереження зображення Ігрового Столу з зібраним Зображенням в пам’ять пристрою

d.      Кнопка Прибрати Шви

Натискання на кнопку Прибрати Шви призводить до прибирання швів (стиків) між шматочками Зображення

e.       Кнопка Кінець

Натискання на кнопку Кінець повертає користувача на Головний Екран

Внутрішньоігрові Опції

.        Бігунок Прозорість Зразка Зображення Пересування бігунка Прозорість Зразка Зображення призводить до змінення прозорості Зображення-Зразка.

2.      Перемикач Sticking Включення режиму Sticking включає відповідний Функціонал у грі. Дана функція дозволяє закріпити частини пазла на відповідаючому їм місці на Основному Зображенні.

.        Перемикач Рамка для Пазла для включення відповідного Функціонала у грі

.        Бігунок Масштаб Ігрового Столу Пересування бігунка Масштаб Ігрового Столу призводить до збільшення або зменшення масштабу Ігрового Стола

.        Перемикач Масштабування Включення перемикача Масштабування вимикає Використання жесту Pinch-to-Zoom на Ігровому Столі

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

.        Перемикач Таймер Включення перемикача Таймер призводить до появлення лічильника часу (таймера) у грі

.        Перемикач Звуки Вимикання перемикача Звуки призводить до відключення звука в Додатку

.        Перемикач Ділитися Результатами Включення перемикача Ділитися результатами призводить до автоматичної передачі результатів в Facebook и Twitter по закінченню Гри

.        Вибір Фона Ігрового Столу Користувачеві на Вибір надається 8 видів фона робочого столу, які будуть використані у грі.

Меню Паузи

1.      Кнопка Продовжити Натискання на кнопку Продовжити повертає користувача до Гри

2.      Кнопка Меню Натискання на кнопку Меню повертає користувача до Головного Екрану

3.      Кнопка Рестарт Натискання на кнопку Рестарт призводить до початку гри заново

4.      Кнопка Інформація Натискання на кнопку Інформація переводить користувача до Екрану Допомоги

Меню Рекордів

.        Кнопки Легко, Середнє, Важко, Нереально Натискання на кнопки Легко, Середнє, Важко, Нереально призводить до відображення Рекордів по Важкості

2.      Зображення Натискання на Зображення призводить до відображення Рекордів, які відносяться до вибраного Зображення

3.      Кнопка Меню Натискання на кнопку Меню повертає користувача на Головний Екран

На рис.2.10 зображено діаграму взаємодії користувача з додатком Join It - Jigsaw Puzzle.

Рисунок 2.10 - Діаграма взаємодії користувача з додатком Join It - Jigsaw Puzzle

Опишемо середній процес роботи користувача с додатком.

)        Запуск додатку

2)      Перегляд вступного відео

)        Якщо додаток запускається в перший раз - Перегляд інформації What’s New

)        Попадання на Головний Екран додатку

)        Перегляд вікна Допомога

)        Перехід в меню колекції

)        Вибір зображення (з готової колекції чи додавання свого зображення)

)        Вибір бажаних Опцій гри

)        Вибір Важкості гри

)        Старт гри

)        Вибір додаткових Опцій гри

)        Гра

)        Поділитися результатами гри в Facebook/Twitter

)        Кінець гри

2.2 Аналіз можливості автоматизації тестування додатку

Інструмент Instruments від компанії Apple, що входить у середу розробки XCode дозволяє автоматизувати тестування додатку через Користувацький інтерфейс.

Будь який функціонал, зв’язаний з користувацьким інтерфейсом може бути автоматизовано, якщо інше не обумовлено специфікою додатку.

Для того, щоб елемент Користувацького інтерфейсу був доступний з Instruments, відповідальний за розробку додатку має забезпечити доступ до елементу користувацького інтерфейсу шляхом встановлення галочки Is Accessible в параметрах елемента в проекті у середі розробки XCode.

Перерахуємо Функціонал додатку Join It - Jigsaw Puzzle, тестування якого можна автоматизувати.

·        Запуск додатку

·        Пропуск вступного відео

·        Реакція на екран What’s New

·        Перегляд вікна Допомога

·        Збереження зображення

·        Збільшення зображення

·        Перегляд Рекордів (по зображенням и по Важкості)

·        Перегляд Опцій

·        Змінення Опцій (включення або вимикання прилипання, обертання, таймера, звука, функції поділитися результатами, Вибір схеми керування, фона, типу пазла)

·        Вибір зображення (Натискання кнопок Наступна і Попередня)

·        Робота в меню Колекції (додавання зображень, Видалення зображень)

·        Продовження або початок гри з початку

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

·        Робота с меню Паузи (почати с початку, продовжити, подивитися екран допомоги, вийти у меню)

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

2.3 Вибір і обґрунтування функціонала для автоматизації

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

·        Запуск додатку

·        Пропуск вступного відео

·        Вибір Важкості

·        Перегляд Опцій

·        Змінення Опцій (Включення або Вимикання прилипання, обертання, таймера, звука, функції поділитися результатами, вибір схеми керування, фона, типу пазла)

·        Вибір зображення (Натискання кнопок Наступна и Попередня)

·        Робота в меню Колекції (додавання зображень, Видалення зображень, Збільшення и зменшення рейтингу зображень)

·        Продовження або початок гри с початку

·        Робота з меню Паузи (почати с початку, продовжити, подивитися екран допомоги, вийти в меню)

·        Перегляд Рекордів

Згідно з вибраним функціоналом розробимо структуру пакета автоматизованого тестування додатків.

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

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

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

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

З точки зору ISO 9126, якість програмного забезпечення можна визначити як сукупну характеристику досліджуваного ПЗ з урахуванням наступних складових:

·        Надійність

·        Супроводжуваність

·        Практичність

·        Ефективність

·        Мобільність

·        Функціональність

Існує кілька ознак, за якими прийнято проводити класифікацію видів тестування. Зазвичай виділяють наступні:

По об'єкту тестування::

·        Функціональне тестування (functional testing)

·        Тестування продуктивності (performance testing)

o   Навантажувальне тестування (load testing)

o   Стрес-тестування (stress testing)

o   Тестування стабільності (stability / endurance / soak testing)

·        Юзабиліті-тестування (usability testing)

·        Тестування інтерфейсу користувача (UI testing)

·        Тестування безпеки (security testing)

·        Тестування локалізації (localization testing)

·        Тестування сумісності (compatibility testing)

По знанню системи:

·        Тестування Чорної Скриньки (black box)

·        Тестування білого ящика (white box)

·        Тестування сірого ящика (grey box)

По степені автоматизації:

·        Ручне тестування (manual testing)

·        Автоматизоване тестування (automated testing)

·        Напівавтоматизоване тестування (semiautomated testing)

По степені ізольованості компонентів:

·        Компонентне (модульне) тестування (component/unit testing)

·        Інтеграціонне тестування (integration testing)

·        Системне тестування (system/end-to-end testing)

По часу проведення тестування:

·        Альфа-тестування (alpha testing)

·        Тестування при прийомі (smoke testing)

·        Тестування нової функціональності (new feature testing)

·        Регресійне тестування (regression testing)

·        Тестування при здачі (acceptance testing)

·        Бета-тестування (beta testing)

По признаку позитивності сценаріїв:

·        Позитивне тестування (positive testing)

·        Негативне тестування (negative testing)

По степені підготовленості до тестування:

·        Тестування по документації (formal testing)

·        Тестування ad hoc або інтуїтивне тестування (ad hoc testing)

Автоматизація тестування використовується при:

По об’єкту тестування:

·        Функціональному тестуванні (functional testing)

·        Тестуванні продуктивності (performance testing)

·        Навантажувальному тестуванні (load testing)

·        Стрес-тестуванні (stress testing)

·        Тестуванні стабільності (stability / endurance / soak testing)

По знанню системи:

·        Тестування Чорної Скриньки (black box)

По степені ізольованості компонентів:

·        Системне тестування (system/end-to-end testing)

По часу проведення тестування:

·        Альфа-тестування (alpha testing)

·        Тестування при прийомі (smoke testing)

·        Регресіонне тестування (regression testing)

·        Тестування при здачі (acceptance testing)

·        Бета-тестування (beta testing)

Розглянемо види тестування в яких може застосовуватись автоматизація.

Функціональне тестування

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

Функціональні вимоги включають в себе:

·        Функціональну пригодність (англ. suitability).

·        Точність (англ. accuracy).

·        Здатність до взаємодії (англ. interoperability).

·        Відповідність стандартам і правилам (англ.compliance).

·        Захищеність (англ. security).

Тестування продуктивності

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

Тестування продуктивності - це одна зі сфер діяльності розвивається в галузі інформатики інженерії продуктивності, яка прагне враховувати продуктивність на стадії моделювання та проектування системи, перед качаном Основному стадії кодування. У тестуванні продуктивності розрізняють наступні напрямки:

·        стрес (stress)

·        навантажувальне (load)

·        тестування стабільності (endurance or soak or stability)

·        конфігураційне (configuration)

Навантажувальне тестування (англ. Load Testing) - визначення або збір показників продуктивності і годині відгуку програмно-технічної системи або пристрою у відповідь на зовнішній запит з метою встановлення відповідності вимогам, що пред'являються до даної системи (пристрою). Для дослідження годині відгуку системи на високих або пікових навантаженнях проводиться стрес-тестування, при якому створювана на систему навантаження перевищує нормальні сценарії його використання. Не існує чіткої межі між навантажувальним та стрес-тестуванням, однак ці поняття не варто змішувати, так як ці види тестування відповідають на різні бізнес-питання і використовують різну методологію [10].

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

Основна мета навантажувального тестування полягає в тому, щоб, створивши певну очікувану в системі навантаження (наприклад, за допомогою віртуальних користувачів) і, звичайно, використавши ідентичне програмне і апаратне забезпечення, спостерігати за показниками продуктивності системи. В ідеальному випадку в якості критеріїв успішності навантажувального тестування виступають вимоги до продуктивності системи, які формулюються і документуються на стадії розробки функціональних вимог до системи до початку програмування основних архітектурних рішень. Однак часто буває так, що такі вимоги не були чітко сформульовані або не були сформульовані зовсім. У цьому випадку перше навантажувальний тестування буде являтися пробним (exploratory load testing) і ґрунтуватися на розумних припущеннях про очікувану навантаженні і споживанні апаратної частини ресурсів [10].

Одним з оптимальних підходів у використанні навантажувального тестування для вимірювань продуктивності системи є тестування на стадії ранньої розробки. Навантажувальне тестування на перших стадіях готовності архітектурного рішення з метою визначити його спроможність називається 'Proof-of-Concept' тестуванням.

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

Термін "стрес-тестування" часто використовується як синонім "навантажувального тестування", а також "тестування продуктивності", що помилково, так як ці види тестування відповідають на різні бізнес-питання і використовують різну методологію [11].

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

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

·        У випадку SLA-контракту (угоди про рівень послуг) вартість відмови системи в екстремальних умовах може бути дуже високою.

·        Виявлення деяких помилок або дефектів у функціонуванні системи не завжди можлива з використанням інших типів тестування.

·        Тестування, проведеного розробником, Може буті недостатньо для емуляції умов при яких відбувається відмова системи.

·        Переважно бути готовим до обробки екстремальних умов системи, ніж чекати їх відмови.

Основні напрямки застосування стрес-тестування:

·        Загальне дослідження поведінки системи при пікових навантаженнях.

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

·        Тестування ємності системи.

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

Пропорційне навантаження

Стрес-тестування може застосовуватися як для відокремлених додатків, так і для розподілених систем з клієнт-серверною архітектурою. Найпростішим прикладом стрес-тестування відокремленого програми може бути відкриття файлу розміром в 50 Мб програмою Notepad, яка входить в комплект ОС Windows. Умови стрес-тестування програми зазвичай формуються виходячи з критичних бізнес-процесів його функціональності, визначеними на стадії розробки вимог і аналізу ризиків групою, відповідальною за продуктивність.

У загальному випадку в якості умов для стрес-тестування може використовуватися лінійно збільшена очікувана навантаження [10].

Диспропорційне навантаження

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

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

Тестування стабільності

Тестування стабільності або надійності (Stability / Reliability Testing) - один з видів тестування ПЗ, метою якого є перевірка працездатності додатка при тривалому тестуванні з середнім (очікуваним) рівнем навантаження.

Перед тим як піддавати ПО екстремальним навантаженням варто провести перевірку стабільності в передбачуваних умовах роботи, тобто занурити продукт в повну робочу атмосферу. При тестуванні, тривалість його проведення не має першорядного значення, основне завдання - спостерігаючи за споживанням ресурсів, виявити витоки пам'яті і простежити щоб швидкість обробки даних і / або час відгуку програми на початку тесту і з плином часу не зменшувалася. В іншому випадку можливі збої в роботі продукту і перезавантаження системи [12].

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

Тестування Чорної Скриньки

Тестування чорної скриньки або поведінкове тестування - стратегія (метод) тестування функціонального поведінки об'єкта (програми, системи) з точки зору зовнішнього світу, при якому не використовується знання про внутрішній устрій тестованого об'єкта. Під стратегією розуміються систематичні методи відбору і створення тестів для тестового набору. Стратегія поведінкового тесту виходить з технічних вимог і їх специфікацій [9].

Поняття "чорної" скриньки

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

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

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

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

В даний час відомі два види "чорних" скриньок. До першого виду відносять будь який "чорний" ящик, який може розглядатися як автомат, званий кінцевим або нескінченним. Поведінка таких "чорних" скриньок відома. До другого виду відносяться такі "чорні" ящики, поведінка яких Може буті споглядана тільки в експерименті. У такому випадку в явній чи неявній формі висловлюється гіпотеза про передбачуваність поведінки "чорної" скриньки в імовірнісному сенсі. Без попередньої гіпотези неможливе будь-яке узагальнення, або, як кажуть, неможливо зробити індуктивний висновок на основі експериментів з "чорним" ящиком. Для позначення моделі "чорної" скриньки Н. Вінером запропоновано поняття "білої" скриньки. "Білий" ящик складається з відомих компонентів, тобто відомих X, Y, δ, λ. Його вміст спеціально підбирається для реалізації тієї ж залежності виходу від входу, Що й у відповідного "чорного" скриньки. В процесі проведених досліджень і при узагальненнях, висуванні гіпотез і встановлення закономірностей виникає необхідність коректування організації "білого" скриньки і зміни моделей. У зв'язку з цим, при моделюванні дослідник має обов'язково багаторазово звертатися до схеми відносин "чорний" - "білий" ящик.

Дослідження поведінки "чорної" скриньки

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

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

Таблиця 2.1 - Результати дослідження методом чорної скриньки

Стан входів	Стан виходів	Час
X1 (T1),X2 (T1),…Xn (T1)	Y1 (T1),Y2 (T1),…Yn (T1)	T1
X1 (T2),X2 (T2),…Xn (T2)	Y1 (T2),Y2 (T2),…Yn (T2)	T2
…	…	.
X1 (Tk),X2 (Tk),…Xn (Tk)	Y1 (Tk),Y2 (Tk),…Yn (Tk)	Tk

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

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

Розробка методів побудови математичних моделей "чорної" скриньки є однією з важливих кібернетичних проблем. За умови наявності математичної моделі "чорної" скриньки з'являється можливість віднести його до якогось одного класу, всі системи якого ізоморфні по поведінці [13].

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

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

Принципи тестування чорного ящика

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

Властивості правильно обраного теста

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

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

Прийоми тестування чорного ящика

·        Еквівалентне розбиття.

·        Аналіз граничних значень.

·        Аналіз причинно-наслідкових зв’язків.

·        Допущення про помилку.

Розглянемо детальніше кожен з цих методів:

Еквівалентне розбиття

Основу методу складають два положення:

Вихідні данні необхідно розбити на кінцеве число класів еквівалентності.

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

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

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

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

Виділення класів еквівалентності є евристичним способом, однак існує ряд правил:

·        Якщо вхідна умова описує область значень, наприклад "Ціле число приймає значення від 0 до 999", то існує один правильний клас еквівалентності і два неправильних.

·        Якщо вхідна умова описує число значень, наприклад "Число рядків у вхідному файлі лежить в інтервалі (1.6)", то також існує один правильний клас і два неправильних.

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

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

Визначення тестів:

·        Кожному класу еквівалентності присвоюється унікальний номер.

·        Якщо ще залишилися не включені в тести правильні класи, то пишуться тести, які покривають максимально можливу кількість класів.

·        Якщо залишилися не включені в тести неправильні класи, то пишуть тести, які покривають тільки один клас [13].

Аналіз граничних значень

Граничні умови - це ситуації, що виникають на вищих і нижніх межах вхідних класів еквівалентності.

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

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

·        При розробці тестів розглядаються не тільки вхідні значення (простір входів), але і вихідні (простір виходів).

Метод вимагає певної міри творчості та спеціалізації в розглянутій задачі.

Існує декілька правил:

Побудувати тести з неправильними вхідними даними для ситуації незначного виходу за межі області значень. Якщо вхідні значення повинні буті в інтервалі [-1.0. +1.0], Перевіряємо - 1.0, 1.0, - 1.000001, 1.000001.

Обов'язково писати тести для мінімальної і максимальної межі діапазону.

Використовувати перші два правила для кожного з вхідних значень (використовувати пункт 2 для Всіх вихідних значень).

Якщо вхід і вихід програми представляє впорядкована множина, зосередити увагу на першому і останньому елементі списку.

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

Аналіз причинно-наслідкових зв'язків

Етапи побудови тесту:

·        Специфікація розбивається на робочі ділянки.

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

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

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

Припущення про помилку

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

Системне тестування

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

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

Можна виділити два підходу до системного тестування:

·        на базі вимог (requirements based)

Для кожної вимоги пишуться тестові випадки (test cases), перевіряючі виконання даної вимоги.

·        на базі випадків використання (use case based)

Альфа-тестування і бета-тестування є підкатегоріями системного тестування.

Альфа-тестування

Альфа-тестування - імітація реальної роботи з системою штатними розробниками, або реальна Робота з системою потенційними користувачами / замовником. Частіше всього альфа-тестування проводиться на ранній стадії розробки продукту, але в деяких випадках Може застосовуватися для закінченого продукту в якості внутрішнього приймального тестування. Іноді альфа-тестування виконується під відладчиком або з використаних оточення, яке допомагає швидко виявляти знайдені помилки. Виявлені помилки можуть буті передані тестувальникам для додаткового дослідження в оточенні, подобному до того, в якому буде використовуватися програма.

Тестування при прийомі

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

Приклади

·        Помилки інсталяції: Якщо програмний продукт не встановлюється, його тестування, швидше всього, виявиться неможливим.

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

Smoke Tests легше автоматизувати, ніж більш глибоке і інтелектуальне тестування. Автоматизація знижує кількість ручної праці і тому дозволяє проводити ці тести частіше. Чим частіше виконуються тести, тим раніше стає відомо про проблеми, що виявляються цими тестами. Чим раніше стає відомо про проблему, тим легше її усунути. Автоматизація тестування часто виконується з допомогою засобів безперервної інтеграції [12].

Регресійне тестування

Регресійне тестування (англ. regression testing, від лат. Regressio - рух назад) - збірна назва для всіх видив тестування програмного забезпечення, спрямованих на виявлення помилок у вже протестованих ділянках вихідного коду. Такі помилки - коли після внесення змін в програму перестає працювати те, що повинно було продовжувати працювати, - називають регресійними помилками (англ. regression bugs).

Регресійне тестування (за деякими джерелами) включає new bug-fix - перевірка виправлення знову знайденого дефекту, old bug-fix - перевірка, що виправлений раніше і верифікований дефект не відтворюється в системі знову, а також side-effect - перевірка того, що не порушилася працездатність функціональності що раніше працювала, якщо її код міг буті змінений при виправленні деяких дефектів в інший функціональності. Звичайно використовувані методи регресійного тестування включають повторні прогони попередніх тестів, а також перевірки, чи не потрапили регресійні помилки в чергову версію в результаті злиття коду.

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

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

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

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

Бета-тестування

Бета-тестування (англ. beta testing) - інтенсивне використання майже готової версії продукту (як правило, програмного або апаратного забезпечення) з метою виявлення максимального числа помилок в його роботі для їх наступного усунення перед остаточним виходом (релізом) продукту на ринок, до масового споживача.

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

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

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

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

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

2.5 Вибір апаратної платформи

Для розробки пакета автоматизованого тестування додатку Join It - Jigsaw Puzzle ТОВ D-Studio надала персональний комп’ютер iMac 2009 з наступними параметрами:

·        Процесор - Intel Core 2 Duo 2.7 ГГц

·        ОЗУ - 4 ГБ

·        ПЗУ - 250 ГБ

Також для тестування були надані пристрої iPad, iPad 2, The New iPad, iPhone 4, iPhone 4S, iPod Touch 4G, iPod Touch 5G

.5 Вибір програмної платформи

Для всіх поширених мобільних ОС пропонуються безкоштовні (для розробників) і досить функціональні емулятори. Для платформи iOS є офіційний iOS Instruments, який включає в себе емулятор мобільного пристрою, який реалізує всі апаратні і програмні особливості типового пристрою. Він запускається виключно, на MacOS X, як частина середовища розробки XCode.

Також, існують інші рішення:- заснований на веб-браузері симулятор для швидкого тестування веб-додатків для iPhone. Працює з використаних Internet Explorer 7, Firefox 2 і Safari 3. Безкоштовно, але симуляція дуже обмежена.

Хмарні платформи пристроїв дозволяють віддалено протестувати свій продукт на безлічі різних пристроїв, передаючи данні про тестування розробнику. Найзнаменитіші - Perfecto Mobile і Device Everywhere. Ці дві контори використовують стенди з реальними мобільними пристроями на iOS і Android. Всередину фотографії телефону вставлено зображення з веб-камери. Управляється повністю мишкою. Також Perfecto Mobile і Device Anywhere віддалено надають пристрої "напрокат". У них стоїть безліч різних телефонів, і годину роботи з одним телефоном коштує близько $ 15.

Переваги:

·        чорний ящик - майже немає втручання в тестований додаток;

·        один інструмент і тестовий скрипт використовується для тестування на всіх мобільних платформах;

·        різноманіття пристроїв.

Недоліки:

·        Затримки при взаємодії з телефоном в Україні.

·        Автоматизоване відтворення скрипкових тестів

JamoSolution - одна з самих багатообіцяючих платформ, на якій зараз розробляється кілька інструментів (наприклад, Meux test і SeeTest). Вона дозволяє тестувати iPhone, Android, Windows Phone та інші платформи. Підтримується запис тестів (record & play) і можна тестувати iPhone додатки на Windows. Працює через установку на пристрої додатка-агента, що звільняє розробника від модифікування свого додатка.від студії TestPlant дозволяє запускати свій тестовий скрипт на безлічі пристроїв одночасно, визначаючи вихідні данні методом розпізнавання зображення на екрані. Підтримує тестування на пристроях Android і iOS, емуляторах Android, iOS і Windows Phone.

В результаті аналізу ринку надаваних додатків Туво прийнято рішення зупинитися на офіційному пакеті iOS Instruments - безкоштовної частини середовища розробки XCode.

2.6 Обґрунтування вибору програмних методик та засобу тестування програмних застосувань для мобільних пристроїв

Пакет автоматизованого тестування додатку повністю розроблений в утиліті iOS Instruments, частині середи розробки XCode.

Утиліта Instruments використовується для автоматизації тестування користувацького інтерфейсу з допомогою написаних тестувальником скриптів. Ці скрипти симулюють дії користувача використовуючи UI Automation, що використовує програмний інтерфейс JavaScript, який і вказує дії, які будуть виконуватися в процесі роботи додатка. В процесі роботи система повертає звіт про дії та їх результати.

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

Інструмент Automation дозволяється використовувати тільки для додатків, підписаних відповідними сертифікатами Apple. Також можливе використання для додатків, які були завантажені з iTunes Store.

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

Рисунок 2.11 - Початковий екран утиліти Instruments

Створення або імпорт скрипта.

Для створення нового скрипта необхідно натиснути Create - > New і ввести ім'я нового скрипта. Для імпорту вже готового скрипта необхідно натиснути Create - > Import і вказати шлях до файлу зі скриптом. Вікно вибору готового скрипта зображено на рис 2.12.

Прив'язка скрипта до додатка.

У випадаючому меню Choose Target. необхідно вибрати додаток, що цікавить. Необхідно переконатися, що в цей момент пристрій підключено, додаток на нього встановлено і підписано відповідним сертифікатом розробника Apple.

Тестувальник має можливість написати необмежену кількість тестів.передбачає повторне Використання функцій. Для цього передбачена директива # import. Наприклад, якщо часто використовувані функції знаходяться в файлі Join_It_Functions. js необхідно включити в скрипт рядок

# include "<шлях-до-файлу> / Join_It_Functions. js"

для імпорту файлу з функціями.

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

Рисунок 2.12 - Вікно вибору готового скрипта утиліти Instruments

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

Accessibility-based mechanism, що використовується у UI Automation представляє Кожній елемент Керування як унікальний визначуваний елемент. Для здійснення дій над елементом його необхідно визначити як елемент ієрархії додатка.

Нагорі ієрархії знаходиться клас UIATarget, який представляє елементи користувацького інтерфейсу високого рівня на пристрої або симуляторі. Для зручності, тестований додаток позначається як target app і визначений як

UIATarget. localTarget (). FrontMostApp ();

Щоб звернутися до головного вікна додатка необхідно вказати

UIATarget. localTarget (). FrontMostApp (). MainWindow ();

Для доступу до елемента таблиці необхідно вказати

UIATarget. localTarget (). FrontMostApp (). MainWindow (). TableViews () [N];

, де N - номер таблиці в головному вікні додатка.

Усередині таблиці кожен елемент представлений як осередок (cell). До кожної таблиці можна звернутися відповідним чином.

UIATarget. localTarget (). FrontMostApp (). MainWindow (). TableViews () [N]. Cells () [K];

, де N - номер таблиці в головному вікні додатка, K - номер комірки у таблиці.

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

UIATarget. localTarget (). frontMostApp (). mainWindow (). tableViews () [N]. cells () [K]. elements () ["Info_Name"];

, де N - номер таблиці в Головному вікні додатка, K - номер комірки у таблиці, Info_Name - Ім'я елемента в комірці.

Відображення елементів ієрархії.

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

Методи навігації в додатку.

Метод tap () використовується для симуляції натискання на елемент керування додатка. Також можливе використання для натискання по координатах. Фактично - натискання користувача на кнопку.

Використання:

UIATarget. localTarget (). frontMostApp (). navigationBar (). buttons () ["Add"]. tap ();

Метод doubleTap () використовується для симуляції подвійного натискання на елемент Керування додатка. Також можливе використання для натискання по координатах. Фактично - подвійне натискання користувача на кнопку.

Використання:

UIATarget. localTarget (). frontMostApp (). navigationBar (). buttons () ["Add"]. doubleTap ();

Метод twoFingerTap () використовується для симуляції натискання на елемент керування додатка двома пальцями. Також можливе використання для натискання по координатах. Фактично, натискання користувача на кнопку двома пальцями.

Метод pinchOpenFromToForDuration () використовується для симуляції жесту Pinch-to-Zoom, що використовується для масштабування (збільшення) об'єктів. Використовується тільки з зазначенням координат і часу дії.

Використання:

UIATarget. localTarget () pinchOpenFromToForDuration ({х: 20, Y: 200}, {х: 300, Y: 200},

);

Метод pinchCloseFromToForDuration () використовується для симуляції жесту Pinch-to-Zoom, що використовується для масштабування (зменшення) об'єктів. Використовується тільки з зазначенням координат і часу дії.

Використання:

UIATarget. localTarget () pinchCloseFromToForDuration ({х: 20, Y: 200}, {х: 300, Y: 200},

);

Метод dragFromToForDuration () використовується для перетягування об'єктів. Використовується тільки з координатами і зазначенням часу дії.

Використання:

UIATarget. localTarget () dragFromToForDuration ({х: 160, Y: 200}, {х: 160, Y: 400}, 1);

Метод flickFromTo () - аналог методу dragFromToForDuration (). Використовується без вказівки часу дії так як передбачається що це швидкий жест.

Метод scrollDown () використовується для прокручування інформації вниз.

Використання:

UIATarget. localTarget (). frontMostApp (). MainWindow (). tableViews () [N]. scrollDown ();

Метод scrollUp () використовується для прокручування інформації вгору.

Використання:

UIATarget. localTarget (). frontMostApp (). MainWindow (). TableViews () [N] scrollUp ();

Запис результатів тесту

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

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

Використання:

UIALogger. logStart (Ім'я_Теста);

/ / Код тесту

UIALogger. logPass (Ім'я_Теста);

Також існує метод UIALogger. logMessage () для виводу повідомлень в процесі виконання тесту.

Використання:

UIALogger. logStart (Ім'я_Теста);

/ / Код тесту

UIALogger. logMessage ("Повідомлення")

/ / Код тесту

UIALogger. logPass (Ім'я_Теста);

Для зняття зображення екрані додатка існує метод captureScreenWithName (), який зберігає зображення з поточним станом додатка в форматі JPEG. Не підтримується в симуляторі. Приклад логування результатів зображено на рис 2.13.

Рисунок 2.13 - Вікно відображення логу утиліти Instruments

Визначення і змінення положення пристрою

При запуску додатка автоматично перевіряється стан, в якому знаходиться пристрій. Варіанти визначення:_DEVICE_ORIENTATION_UNKNOWN

Неможливо визначити положення.

UIA_DEVICE_ORIENTATION_PORTRAIT

Пристрій в портретному режимі з кнопкою Home внизу.

UIA_DEVICE_ORIENTATION_PORTRAIT_UPSIDEDOWN

Пристрій в портретному режимі з кнопкою Home вверху.

UIA_DEVICE_ORIENTATION_LANDSCAPELEFT

Пристрій в горизонтальному положенні, Кнопка Home справа.

UIA_DEVICE_ORIENTATION_LANDSCAPERIGHT

Пристрій в горизонтальному положенні, Кнопка Home зліва.

UIA_DEVICE_ORIENTATION_FACEUP

Пристрій паралельно землі, екраном догори.

UIA_DEVICE_ORIENTATION_FACEDOWN

Пристрій паралельно земле, екраном вниз.

Для змінення положення пристрою існує метод setDeviceOrientation () для надання пристрою бажаного положення.

Тестування мультизадачності

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

Використання:

UIATarget. localTarget (). deactivateAppForDuration (10);

Дана команда зверне додаток на 10 секунд, а потім викличе його знову. Процес створення скрипта в утиліті Instruments зображено на рис 2.14.

Рисунок 2.14 - Вікно написання скрипта в утиліті Instruments

3. Розробка пакету автоматизованого тестування

3.1 Розробка методики тестування додатку

Функціонал, обраний для автоматизації, представлено у розділі 2.2.

Опишемо процес тестування обраного функціонала.

Таблиця 3.1 - Тестування функціоналу додатку Join It - Jigsaw Puzzle

Функціонал	Очікуємий результат
Запуск додатку	Додаток запускається Демонструється вступний ролик Вступний ролик можна пропустить При першому запуску додатку демонструється екран What’s New При наступних запусках користувач потрапляє на Головний Екран
Перегляд вікна Допомога	При натисненні кнопки Допомога користувач переходить до екрану Допомоги Користувачеві надається інформація про керування в додатку, інформація про команду розробників При натисненні на кнопку iPad Керування користувачеві надається інформація про схему керування "iPad" При натисненні на кнопку iPhone Керування Користувачеві надається інформація о схему керування "iPhone"
	При натисненні на посилання support@joinitpuzzle.com відкривається додаток для роботи с поштою, в якому відкрито новий лист з адресатом support@joinitpuzzle.com При натисненні на посилання Веб-сайт гри Join It відкривається браузер с адресом joinitpuzzle.com При натисненні кнопки Назад, користувач повертається на Головний Екран
Збереження зображень	Натискання на кнопку Зберегти призводить до збереження Зображення на пристрій. У разі, якщо Зображення не було зібрано демонструється сповіщення "Водяний Знак. Незібране Зображення буде збережене с водяним знаком" с Кнопками Зберегти и Відміна. У разі, якщо Зображення було збережене раніше, демонструється сповіщення "Зберегти Зображення. Це Зображення уже раніше зберігалося в Бібліотеку. Хочете Зберегти його ще раз?" с Кнопками Зберегти и Відміна
Збільшення зображень	Натискання на кнопку Збільшити призводить до демонстрації Зображення на весь екран. У разі, якщо Зображення не було зібрано, по діагоналі Зображення відображується напис " Це Зображення ще не було зібрано. Зберіть пазл, щоб прибрати цей текст. "
	Повторне Натискання на зображення повертає користувача на Головний Екран
Екран Рекордів	Натискання на кнопку Рекорди переводить користувача к Екрану Рекордів Натискання на кнопки Легко, Середнє, Важко, Нереально призводить до відображення Рекордів по Важкості Натискання на Зображення призводить до відображення Рекордів, які відносяться к вибраної Зображенні Натискання на кнопку Меню повертає користувача на Головний Екран Натискання кнопки Допомога переводить користувача к Екрану Допомоги
Меню Опцій	Натискання на кнопку Меню призводить до відображення спливаючого меню налаштувань додатку Включення режиму Sticking включає відповідний функціонал у грі. Дана функція дозволяє закріпити частини пазла на відповідаючому їм місці на Основному Зображенні. Не має видимого результату на Головному Екрані
	Включення режиму Обертання Пазлів включає відповідний функціонал у грі. При виключені цієї функції шматочки пазла не можуть обертатися навколо своєї оси. Включення цієї функції призведе к можливості обертання шматочків пазла и, відповідно к збільшення Важкості гри. Не має видимого результату на Головному Екрані Включення перемикача Таймер призводить до появлення лічильника часу (таймера) у грі. Не має видимого результату на Головному Екрані Вимикання перемикача Звуки призводить до відключення звука в Додатку. Не має видимого результату на Головному Екрані Включення перемикача Ділитися результатуми призводить до автоматичної передачі результатів в Facebook и Twitter по закінченню Гри. Не має видимого результату на Головному Екрані Перемикач Керування призначений для переключення схеми керування iPad/iPhone. Натискання на кнопку iPad перемикає схему керування в режим iPad. Натискання на кнопку iPhone перемикає схему керування в режим iPhone. Не має видимого результату на Головному Екрані
	Перемикач Стиль Шматочків призначений для вибору стиля шматочків на які буде розбите Зображення перед початком Гри. Натискання на відповідний вид кусочка викличе відповідні зміни. Не має видимого результату на Головному Екрані Користувачеві на Вибір надається 8 видів фона робочого столу, які будуть використані у грі. Натискання на Фон Ігрового Столу викличе підменю вибору Фона Ігрового столу. Натискання на відповідний фон, змінить фон Ігрового столу. Не має видимого результату на Головному Екрані
Вибір зображення (Натискання кнопок Наступна и Попередня)	Натискання на кнопку Наступна/Попередня призводить до переходу на наступне/попереднє Зображення колекції Використання жесту Flick призводить до переходу на наступне/попереднє Зображення колекції
Меню Колекції	Натискання на кнопку Колекції переводить користувача к Екрану Колекцій Натискання на кнопку Назад призводить до повернення на Головний Екран
	Натискання на кнопку Додати Зображення призводить до появлення спливаючого меню вибору джерела зображення Вибір пункту Меню Мої Фотографії призводить до Вибору Зображення, котре знаходиться на пристрої Користувач має можливість вибрати зображення з Групи Інтернет ресурсу Flickr, що його цікавить Натискання на зображення з Групи Інтернет ресурсу Flickr призводить до її завантаження в додаток Натискання на групу призводить до демонстрації її вмісту Натискання на Зображення с позначкою "скачати" призводить до завантаження Зображення с сервера компанії. Під час завантаження Зображення на ній з’являється лічильник прогресу. Після завантаження позначка "скачати" зникає. При відсутності з’єднання з мережею Інтернет демонструється сповіщення "Загрузка Неможлива. Мабуть, з’єднання з Інтернетом відсутнє"
	Натискання на кнопку Правка переводить користувача в режим редагування Користувач може вибрати будь яке завантажене Зображення. Вибрана Зображення відмічається спеціальним символом в правому верхньому кутку Жест Flick під Зображенням (в районі трьох крапок) призводить до виставлення рейтингу Зображенні. Система рейтингу - Одна Зірка, Дві Зірки, Три Зірки відображують Один, Два и Три Бали відповідно. Помічені таким чином Зображення потрапляють в Колекцію Улюблені Зображення По натиску на кнопку Видалити з’являється спливаюче Вікно с попередженням "При видаленні зображень, інформація о Рекордах для цих зображень також видаляється" і Кнопка Видалити Зображення. Натискання на кнопку Видалити Зображення призводить до видалення Зображень з колекції. Видалення Зображень призводит до виходу з режиму редагування
	Повторне Натискання на кнопку Правка призводить до виходу з режиму редагування Жест Flick в області відображення зображень в групі призводить до "прокручування" колекції и демонстрації Зображень, що не вміщаються на екран Натискання на будь яке з закачаних зображень призводить до переходу на Головний Екран и зміненню попереднього Зображення для Гри на вибране
Продовження або початок гри з початку	При натисненні кнопки Старт починається загрузка Гри Якщо Зборка Зображення було раніше перервана користувачем, Зборка Зображення починається зі збереженої позиції Якщо Зображення збирається на Важкості, що відрізняється від останньої збереженої Важкості, з’являється сповіщення "Нова Гра. Незакінчена Гра на N частин буде втрачена" з Кнопками Почати и Відміна, де N - остання збережена важкість збираного Зображення
Внутрішньоігрові Опції	Натискання на кнопку Меню призводить до відображення спливаючого меню налаштувань додатку
	Пересування бігунка Прозорість Зразка Зображення призводить до зміненню прозорості Зображення-Зразка. Пересування бігунка Масштаб Ігрового Столу призводить до збільшення або зменшення масштабу Ігрового Столу Перемикач Рамка для Пазла включає і вимикає рамку навколо Зразка збираного Зображення Включення режиму Sticking включає відповідний функціонал у грі. Дана функція дозволяє закріпити частини пазла на відповідаючому їм місці на Основному Зображенні Включення режиму Обертання Пазлів включає відповідний функціонал у грі. При виключені цієї функції шматочки пазла не можуть обертатися навколо своєї оси. Включення цієї функції призведе к можливості обертання шматочків пазла и, відповідно к збільшення Важкості гри Включення перемикача Таймер призводить до появлення лічильника часу (таймера) у грі. Вимикання перемикача Звуки призводить до відключення звука в Додатку Включення перемикача Ділитися Результатами призводить до автоматичної передачі результатів в Facebook и Twitter по закінченню Гри
	Користувачеві на Вибір надається 8 видів фона робочого столу, які будуть використані у грі. Натискання на Фон Ігрового Столу викличе підменю вибору Фона Ігрового столу. Натискання на відповідний фон, змінить фон Ігрового столу
Меню Паузи	Натискання на кнопку Продовжити повертає користувача до Гри Натискання на кнопку Меню повертає користувача до Головному Екрану Натискання на кнопку Рестарт призводить до початку гри заново Натискання на кнопку Інформація переводить користувача до Екрану Допомоги

В якості методики тестування було визначено тестувати додаток методом чорного ящика на стадії Альфа і Бета тестування. Також буде розроблений окремий модуль для тестування при прийманні.

3.2 Розробка структури пакету автоматизованого тестування програмних застосувань для мобільних пристроїв на платформі iOS

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

Структура пакета автоматизованого тестування додатка зображена на рис 3.1

Рисунок 3.1 - Структура пакета автоматизованого тестування

Як видно з рисунку, пакет автоматизованого тестування має просту структуру. Усі модулі пакета є незалежними. Результат тестування, як і самі модулі знаходяться в єдиному файлі з розширенням Trace.

Тести, що відповідають модулям пакета представлені у таблиці 3.2.

Таблиця 3.2 - Відповідність тестів модулям пакета

Join_It_Functions	Набор функцій, що використовуються в модулях пакета
Smoke_Test	Запуск додатку, Меню Опцій, Меню Колекції, Головний Екран
Collections_Test	Повний тест функціоналу меню Колекції
Difficulty_Test	Тест розбиття зображення по Важкості (Використання кнопок)
Help_Test	Повний тест функціоналу Екрану Допомоги
Main_Screen_Test	Повний тест функціоналу Головного Екрану
Picture_Change_Test	Тестування переключення зображень по Кнопкам Наступна, Попередня, по жесту Flick
Piece_Style_Test	Тест переключення типів Пазлів
High_Score_Test	Повний тест Функціонала Екрану Рекордів
Suspend_Test	Додатковий тест для визначення поведінки додатку в момент згортання
Orientation_Test	Додатковий тест для визначення поведінки додатку в момент зміни положення пристрою

3.3 Розробка модулів пакету автоматизованого тестування програмних застосувань для мобільних пристроїв на платформі iOS

За допомогою утиліти Instruments були розроблені наступні модулі пакета: Smoke_Test, Collections_Test, Difficulty_Test, Help_Test, Main_Screen_Test, Picture_Change_Test, Piece_Style_Test, High_Score_Test, Suspend_Test, Orientation_Test. Модуль Join_It_Functions був розроблений для зберігання найбільш часто використовуваних функцій.

Розглянемо дії що виконуються кожним модулем пакету:_Test:

.        Запуск додатку

2.      Пропуск відео ролика

.        Вхід в меню Колекції

.        Вибір випадкового зображення

.        Натискання на важкість Легко

.        Натискання на важкість Середнє

.        Натискання на важкість Важко

.        Натискання на важкість Нереально

.        Перетаскування бігунка на випадкову позицію

.        Натискання на важкість Легко

.        Натискання на кнопку Опції

.        Натискання на елемент керування Sticking

.        Натискання на елемент керування Обертання

.        Натискання на елемент керування Таймер

.        Натискання на елемент керування Звук

.        Натискання на елемент керування Схема Керування iPhone

.        Натискання на елемент керування Схема Керування iPad

.        Вибір першого типу Пазлів

.        Вибір другого типу Пазлів

.        Вибір третього типу Пазлів

.        Вибір четвертого типу Пазлів

.        Вибір випадкового Фона Ігрового Столу

.        Зачинення Опцій

.        Натискання на кнопку Старт

.        Натискання на випадкову точку Екрану для початку гри

.        Натискання на паузу

.        Натискання кнопки Назад

Даний модуль діє по найбільш розповсюдженій схемі роботи користувача з додатком._Test:

.        Запуск додатку

2.      Пропуск відео ролика

.        Вхід в меню Колекції

.        Натискання на кнопку Додати зображення

.        Вибір випадкової Групи

.        Закачка чотирьох перших зображень

.        Натискання кнопки Назад

.        Вибір Групи Мої Фотографії

.        Вибір Фото с Камери

.        Вибір випадкової Фотографії

.        Натискання на кожну з Колекцій

.        Натискання на Колекцію Join It - Original Collection

.        Закачка випадкового зображення

.        Натискання на Колекцію Всі Зображення

.        Натискання на кнопку Правка

.        Натискання на кнопку Видалити

.        Натискання на кнопку Видалити Обрані Зображення

.        Натискання на кнопку Назад

Даний модуль тестує меню Колекції._Test:

.        Запуск додатку

2.      Пропуск відео ролика

.        Натискання на кнопку Легко

.        Натискання на кнопку Старт

.        Натискання на випадкову точку Екрану для початку гри

.        Збереження знімку Екрану

.        Натискання на кнопку Пауза

.        Натискання на кнопку Меню

.        Натискання на кнопку Середнє

.        Натискання на кнопку Старт

.        Натискання на випадкову точку Екрану для початку гри

.        Збереження знімку Екрану

.        Натискання на кнопку Пауза

.        Натискання на кнопку Меню

.        Натискання на кнопку Важко

.        Натискання на кнопку Старт

.        Натискання на випадкову точку Екрану для початку гри

.        Збереження знімку Екрану

.        Натискання на кнопку Пауза

.        Натискання на кнопку Меню

.        Натискання на кнопку Нереально

.        Натискання на кнопку Старт

.        Натискання на випадкову точку Екрану для початку гри

.        Збереження знімку Екрану

.        Натискання на кнопку Пауза

.        Натискання на кнопку Меню

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

.        Запуск додатку

2.      Пропуск відео ролика

.        Натискання на кнопку Допомога

.        Збереження зображення Екрану

.        Прокручування вниз

.        Збереження зображення Екрану

.        Пункти 5 и 6 послідовно повторюються по 3 рази

.        Натискання на кнопку Схема Керування iPhone

.        Збереження зображення Екрану

.        Прокручування вниз

.        Збереження зображення Екрану

.        Пункти 10 и 11 послідовно повторюються 3 рази

.        Натискання на посилання на сайт Join It - Jigsaw Puzzle

.        Відмова від переходу у браузер

.        Натискання на кнопку Назад

Даний модуль тестує функціонал Екрану Допомоги_Screen_Test:

.        Запуск додатку

2.      Пропуск відео ролика

.        Натискання на кнопку Допомога

.        Натискання на кнопку Назад

.        Натискання на важкість Легко

.        Натискання на важкість Середнє

.        Натискання на важкість Важко

.        Натискання на важкість Нереально

.        Натискання на кнопку Рекорди

.        Натискання на кнопку Головне Меню

.        Перетаскування бігунка на випадкову позицію

.        Натискання на кнопку Опції

.        Зачинення Опцій

.        Натискання на кнопку Про Фотографію

.        Натискання на кнопку Зберегти

.        Натискання на кнопку Збільшити

.        Натискання на зображення для виходу з режиму збільшення

.        Натискання на кнопку Наступна

.        Натискання на кнопку Попередня

.        Жест Flick для переходу до наступного зображення

.        Жест Flick для переходу до попереднього зображення

.        Натискання на кнопку Колекції

.        Натискання на кнопку Назад

Даний модуль тестує Функціонал Головного Екрану_Change_Test:

.        Запуск додатку

2.      Пропуск відео ролика

.        Натискання на кнопку Колекції

.        Натискання на первое зображення колекції Всі Зображення

.        15 нажатий на кнопку Наступна

.        15 нажатий на кнопку Попередня

.        15 жестів Flick для переходу до наступного зображення

.        15 жестів Flick для переходу до попереднього зображення

Даний модуль призначений для перевірки переходу між зображеннями_Style_Test:

.        Запуск додатку

2.      Пропуск відео ролика

.        Натискання на кнопку Опції

.        Вибір першого типу пазла

.        Зачинення Опцій

.        Натискання на кнопку Старт

.        Натискання на випадкову точку Екрану для початку гри

.        Збереження зображення Екрану

.        Натискання на паузу

.        Натискання на кнопку Меню

.        Натискання на кнопку Опції

.        Вибір другого типу пазла

.        Зачинення Опцій

.        Натискання на кнопку Старт

.        Натискання на випадкову точку Екрану для початку гри

.        Збереження зображення Екрану

.        Натискання на паузу

.        Натискання на кнопку Меню

.        Натискання на кнопку Опції

.        Вибір третього типу пазла

.        Зачинення Опцій

.        Натискання на кнопку Старт

.        Натискання на випадкову точку Екрану для початку гри

.        Збереження зображення Екрану

.        Натискання на паузу

.        Натискання на кнопку Меню

.        Натискання на кнопку Опції

.        Вибір четвертого типу пазла

.        Зачинення Опцій

.        Натискання на кнопку Старт

.        Натискання на випадкову точку Екрану для початку гри

.        Збереження зображення Екрану

.        Натискання на паузу

.        Натискання на кнопку Меню

Даний модуль призначений для тестування розбиття зображення на відповідні типу шматочки._Score_Test:

.        Запуск додатку

2.      Пропуск відео ролика

.        Натискання на кнопку Рекорди

.        Натискання на кнопку Легко

.        Збереження зображення Екрану

.        Натискання на кнопку Середнє

.        Збереження зображення Екрану

.        Натискання на кнопку Важко

.        Збереження зображення Екрану

.        Натискання на кнопку Нереально

.        Збереження зображення Екрану

.        Натискання на кнопку Меню

Даний модуль призначений для перевірки функціонала меню Рекордів._Test:

.        Запуск додатку

2.      Пропуск відео ролика

.        Згортання на 3 секунди

.        Натискання на кнопку Колекції

.        Згортання на 3 секунди

.        Натискання на первую зображення в групі Всі Зображення

.        Згортання на 3 секунди

.        Натискання на кнопку Опції

.        Згортання на 3 секунди

.        Зачинення Опцій

.        Згортання на 3 секунди

.        Натискання на кнопку Старт

.        Згортання на 3 секунди

.        Натискання на кнопку Продовжити

.        Натискання на кнопку Пауза

.        Натискання на кнопку Головне Меню

.        Згортання на 3 секунди

Даний модуль призначений для дослідження поведінки пристрою при згортанні._Test:

.        Запуск додатку

2.      Пропуск відео ролика

.        Установка положення LANDSCAPE_RIGHT

.        Установка положення LANDSCAPE_LEFT

.        Натискання на кнопку Опції

.        Установка положення LANDSCAPE_RIGHT

.        Установка положення LANDSCAPE_LEFT

.        Зачинення Опцій

.        Установка положення LANDSCAPE_RIGHT

.        Установка положення LANDSCAPE_LEFT

.        Натискання на кнопку Колекції

.        Установка положення LANDSCAPE_RIGHT

.        Установка положення LANDSCAPE_LEFT

.        Натискання на кнопку Старт

.        Натискання на випадкову точку Екрану для початку гри

.        Установка положення LANDSCAPE_RIGHT

.        Установка положення LANDSCAPE_LEFT

.        Натискання на кнопку Пауза

.        Натискання на кнопку Меню

.        Установка положення LANDSCAPE_RIGHT

.        Установка положення LANDSCAPE_LEFT

.        Натискання на кнопку Рекорди

.        Установка положення LANDSCAPE_RIGHT

.        Установка положення LANDSCAPE_LEFT

.        Натискання на кнопку Меню

Даний модуль призначений для дослідження поведінки додатку в умовах зміни положення пристрою

Модуль Join_It_Functions зберігає в собі наступні функції:

Deactivate (t) - згортає додаток на час t, сек.

Start_Game (t) - Натискання на кнопку Старт, очікування завантаження зображення t, сек.

Exit_Game () - Натискання на кнопку Пауза, натискання на кнопку Меню.

First_Launch_Check () - перевірка першого запуску. Якщо видно заголовок "Що Нового" - задержка на загрузку, Натискання на кнопку Продовжити, Натискання на кнопку Схема Керування iPad, Натискання на кнопку ОК.

Open_Options () - відкриває Опції гри в залежності от положення користувача в Додатку.

Tap_Piece_Style (Piece_Num) - в залежності от цифри, що передається (от 1 до 4) обирає відповідний тип шматочків пазла.

Choose_Background (r) - обирає випадковий фон робочого столу.

Change_Difficulty (Difficulty) - в залежності від значення, що передається у функцію, встановлює важкість. По замовчанню встановлює важкість Середнє.

4. Тестування пакету та рекомендації щодо використання пакету

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

Пакет автоматизованого тестування був використаний у розробці додатку Join It - Jigsaw Puzzle.

Для тестування пакета було виділено пристрій iPad 2. Тестувалася версія додатку 2.0.4b1. Був проведений тест ефективності відносно ручного тестування. Для тестування було представлено спеціальну версію додатку с вже відомою кількістю критичних, важливих, середніх та незначних дефектів. Час, відведений на тестування версії - 2 години. Приведемо результати ручного и автоматизованого тестування в табл.4.1.

Таблиця 4.1 - Результати тестування пакета

Тип дефектів	Кількість дефектів, знайдених при ручному тестуванні	Кількість дефектів, знайдених при автоматизованому тестуванні
Критичні	2	3
Важливі	7	10
Середні	3	3
Незначні	10	6

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

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

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

В процесі тестування у пакет були внесені модифікації, що дозволили використовувати пакет автоматизованого тестування додатку для тестування модифікацій додатку Join It - Jigsaw Puzzle - uJigsawArt и Join The Hearts. Планується подальша розробка пакетів автоматизованого тестування для більшості проектів ТОВ D-Studio.

В даний момент пакет автоматизованого тестування активно використовується для пошуку дефектів у додатках ТОВ D-Studio, про що свідчить акт впровадження.

4.2 Рекомендації, щодо використання пакету

Пакет слід використовувати для тестування програмного застосування Join It - Jigsaw Puzzle та його похідних - Join The Hearts та uJigsawArt.

Пакет може використовуватися інженером - тестувальником компанії D-Studio для тестування вище зазначених додатків.

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

5. Організаційно-економічний розділ

5.1 Функціонально-вартісний аналіз (ФВА)

На створення програмного продукту (ПП) витрачаються значні трудові та фінансові ресурси, отже необхідний ретельний аналіз усіх можливих варіантів створення ПП, який дозволить вибрати найбільш раціональний варіант. Одним із сучасних методів економічного аналізу ПП є функціонально-вартісний аналіз (ФВА) [21].

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

Темою організаційно-економічної частини дипломного проекту є техніко-економічне обґрунтування (ТЕО) етапів розробки програмного продукту "пакет автоматизованого тестування застосування на платформі iOS". Даний розділ містить економічне обґрунтування вибору оптимального плану розробки програмної функціональності.

5.2 Обґрунтування функцій програмного продукту

5.2.1 Виділення основних функцій

Виділимо основні функції, які повинна виконувати дана програма:- встановлення параметрів тестування;- тестування;- виведення одержаних результатів;- аналіз результатів і їх повторне використання.

 

5.2.2 Опис основних функцій ПП

Розглянемо варіанти реалізації цих функцій::) введення параметрів з клавіатури;:) проведення повністю автоматизованого тестування;

б) проведення автоматизованого тестування з наглядом оператора;

в) збереження результатів тестування для повторного використання.:

а) виведення результатів на екран;

б) збереження результатів у файл.

По розглянутим варіантам будуємо морфологічну карту (рис.5.1).

 

Рисунок 5.1 - Морфологічна карта

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

Таблиця 5.1 - Позитивно-негативна матриця

Основні функції	Варіанти реалізації	Переваги	Недоліки
F1	а)	Можливість моделювання процесу без прив’язки до файлу	Низька продуктивність роботи мережі
F2	а)	Немає необхідності в роботі оператора	Можливі псування результатів через неправильний підбір параметрів тестування
	б)	Мала доля помилки, миттєве реагування на неправильний результат роботи тесту та його модифікація	Витрачається час оператора
	в)	Можливість збереження найкращих параметрів	Збереження невдалої конфігурації у файл вдалої
F3	а)	Велика наочність отриманої інформації	Повторення процесу моделювання кожен раз при необхідності
	б)	Мінімальний час отримання вхідних даних	Необхідність додаткових ресурсів для зв’язку програми з файлом
F4	а)	Можливість автоматичного сповіщення про дефект	Можуть бути пропущені важливі деталі

 

5.3 Обґрунтування системи параметрів

Для характеристики розроблюваного ПП можна використати наступне систему параметрів:

·        X1 - розмір вихідного файлу, Мб;

·        X2 - час для завантаження даних з файлу, сек;

·        X3 - наочність інформації, що відображається, %;

·        X4 - коефіцієнт використання ПП, %.

По даним технічної літератури і досвіду попередніх розробок визначаємо гірші, середні та кращі значення параметрів (таблиця 5.2) [21]:

Таблиця 5.2 - Основні параметри ПП

Назва параметра	Позначення параметра	Одиниця виміру	Значення
			гірше	середнє	Краще
Розмір модуля, що загружається	X1	Мб	500	100	20
Час для завантаження даних із файлу	X2	Сек	0.1	0.01	0.001
Наочність інформації, що відображається	X3	Доля одиниці	1	80	100
Коефіцієнт використання ПП	X4	Доля одиниці	10	40	100

По даним цієї таблиці будуємо бальні оцінки основних параметрів програмного продукту. Гіршому значенню відповідає бальна оцінка 1, середньому - 5, кращому - 10 (рис.5.2 - 5.6).

Рисунок 5.2 - Бальна оцінка розміру модуля, що загружається

Рисунок 5.3 - Бальна оцінка час для завантаження даних із файлу

Рисунок 5.4 - Бальна оцінка коефіцієнту наочність інформації, що відображається

Рисунок 5.5 - Бальна оцінка коефіцієнт використання ПП

На основі рішення експертної комісії, в склад якої входять 4 спеціалістів, кожному одиничному показнику якості продукту ставиться у відповідність ранг. Найбільш важливому (на думку експерта) ставиться ранг 1, менш важливому 2 - і т.д.

Розрахуємо коефіцієнт конкордації (узгодженості) експертних оцінок (таблиця 5.3).

Таблиця 5.3 - Результати ранжування параметрів

Позначення параметра    Назва параметра              Одиниця виміру Ранг параметра по оцінкам експертів        Сума рангів Ri Відхилення DDi

DD2i

			1	2	3	4
X1	Розмір модуля, що загружається	КБ	1	2	1	1	5	-5	25
X2	Час для завантаження даних із БД	Сек	4	3	3	4	14	4	16
X3	Наочність інформації, що відображається	Доля одиниці	3	4	4	3	14	4	16
X4	Коефіцієнт використання ПП	Доля одиниці	2	1	2	2	7	-3	9
			10	10	10	40	0	66

Обчислюємо суму рангів кожного параметра:

, для  (5.1)

де r_ij - ранг і-го параметра, визначений j-м експертом, N - кількість експертів, n - кількість параметрів.

Перевіримо значення суми рангів, яке повинно дорівнювати

 (5.2)

Дійсно:

Середня сума рангів:

  (5.3)

Відхилення суми рангів кожного параметра  від середньої суми рангів:

 (5.4)

Сума відхилень по всім параметрам має дорівнювати 0, що виконується:

Знаходимо квадрат відхилень по кожному з параметрів  та суму квадратів відхилень всіх параметрів.

Тепер знайдемо коефіцієнт узгодженості (конкордації):

 (5.5)

 (5.6)

 (5.7)

Порівнюючи отриманий коефіцієнт W=0,825 з нормативною величиною Wн (яка для засобів обчислювальної техніки та ПП дорівнює 0.67) отримаємо, що  (0,825>0,67), тобто дані заслуговують на довіру. Можемо користуватися результатами експертного опитування для подальших розрахунків.

Вагу параметрів будемо визначати методом розстановки пріоритетів на основі рішення експертної комісії (таблиця 5.4).

Значення коефіцієнтів:

 (5.8)

де  параметри, що порівнюються

Використовуючи значення  (див. табл.4) будуємо квадратну матрицю А= ||.

Таблиця 5.4 - Експертне порівняння параметрів

Параметри	Підсумкова				Чисельне
	1	2	3	4	оцінка	Значення
X1, X2	>	>	>	>	>	1.5
X1, X3	>	>	>	>	>	1.5
X1, X4	>	>	<	>	<	0.5
X2, X3	<	<	<	<	<	0.5
X2, X4	<	<	<	<	<	0.5
X3, X4	>	<	<	>	<	0.5

Вагомість кожного параметра будемо обчислювати за формулами:

 (5.9)

 (5.10)

 (5.11)

 (5.12)

де  - відносна оцінка i-го параметра;

 - вагомість i-го параметра за результатами оцінок всіх експертів,  - числове значення оцінки;

 - відносна оцінка і-го параметра на другому кроці;

 - вагомість i-го параметра за результатами оцінок всіх експертів на другому кроці.

,

,

,

,

,

Результати розрахунків (таблиця 5.5):

Таблиця 5.5 - Розрахунок пріоритету параметрів

Параметри	Параметри Xj				2-й крок
Xi	X1	X2	X3	X4	Bi	jjiBi|jji |
X1	1.0	1.5	1.5	0.5	5.5	0.343	21.25	0.3512
X2	0.5	1.0	0.5	0.5	2.5	0.153	9.25	0.1528
X3	0.5	1.5	1.0	0.5	3.5	0.212	12.25	0.2024
X4	1.5	1.5	1.5	1.0	4.5	0.282	17.75	0.2933
Сума					16	1	60.5	1

Перевіримо, чи варто нам виконувати подальші ітерації:

 (5.13)

, що складає 5% відхилення  від попереднього .

Відносна оцінка , отримана на останній ітерації розрахунків, вважається коефіцієнтом вагомості () i-того параметра. Згідно з нею судять про пріоритетність параметра.

5.4 Аналіз варіантів реалізації функцій

На основі порівняльного аналізу реалізації функцій, їх переваг та недоліків, коефіцієнтів вагомості параметрів, залишимо наступні 3 варіанти реалізації функцій:

) F1a + F2a + F3б + F4а;

) F1a + F2б + F3б + F4а;

) F1а + F2в + F3б + F4а;

Визначимо рівень якості обраних розв’язків за формулою:

 (5.14)

Та варіантів виконання за формулою:

 (5.15)

де  - коефіцієнт важливості (табл.4);

 - бальна оцінка якості, знаходиться з графіків (рис.5.1-5.4);

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

Розрахуємо показники рівня якості для кожного варіанта реалізації функцій (таблиця 5.6):

, (5.16)

де  - показник технічного рівня першої функції k-го варіанту реалізації основних функцій виробу.

Таблиця 5.6 - Розрахунок рівня якості

Основна Функція	Варіант реалізації ПП	Параметр реалізації функції	Абсолютне значення параметра	Оцінка параметра в балах	Коефіцієнт важливості параметра	Коефіцієнт рівня якості
F1	а	X3	0.090	0.5	0.212	0.422
F2	a	X2	2700	5.8	0.153	0.242
	б	X2	2900	5.2	0.153	0.294
	в	X1	0.07	4	0.343	1.183
F3	a	X4	70	4.4	0.282	1.052
	б	X4	90	7.6	0.282	1.817
F4	а	X4	80	0.8	0.198	0.722

= F1a + F2a + F3б + F4а= 3.203;

= F1a + F2б + F3б + F4а= 3.255;

= F1а + F2в + F3б + F4а= 4.144;

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

5.5 Економічний аналіз варіантів ПП

5.5.1 Визначення витрат на розробку ПП

Витрати на розробку кожного варіанту ПП знайдемо за допомогою наступної формули:

 (5.17)

де  - зарплата разом з відрахуваннями;

 - витрати на оплату машинного часу;

 - накладні витрати.

Витрати на оплату праці розробників ПП:

, (5.18)

де  - денна зарплата програміста,  - трудомісткість розробки ПП.

Визначимо вихідні дані для розрахунку трудомісткості ПП:

·        кількість наборів даних вхідної інформації - 1;

·        кількість різновидів форм вихідної інформації - 3;

·        за ступенем новизни що розробляється завдання відноситься до групи А;

·        за складністю алгоритм відноситься до першої групи;

·        складність організації контролю вхідної і вихідної інформації:

а) вхідний контроль - група 12;

б) вихідний контроль - група 22;

·        - трудомісткість виконання робіт; для завдань групи А та першої групи складності алгоритму складає 90 людино-днів (норма часу розрахована на восьми годинний робочий день при п'ятиденному робочому тижні).

Тепер знайдемо загальну трудомісткість розробки:

, (5.19)

де  - поправковий коефіцієнт, який враховує групу складності, ступінь новизни і вид інформації, що використовується:

Кп = (К₁ ∙ m+ К₂ ∙ n+ К₃ ∙ р) / (m + n + р), (5.20)

де K1, K2, К3 - поправкові коефіцієнти, що визначаються за таблицею "Поправкові коефіцієнти для розрахунку трудомісткості робіт";, n, р - відповідно ПІ, ПДІ, БД кількість наборів даних.

,

 - поправковий коефіцієнт, що враховує складність контролю вхідної та вихідної інформації, .

 - поправковий коефіцієнт, який враховує рівень мови програмування, .

 - поправковий коефіцієнт, який враховує використання стандартних модулів, .

Отже, знаходимо загальну трудомісткість розробки ПП:

 людино-днів

Визначимо потрібну кількість працівників, що будуть виконувати розробку програмного продукту. Оскільки запланований строк розробки 1 рік, то:

, (5.21)

де  - річний фонд робочого часу, =253 дні.

Отже

 людина.

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

 грн. (5.22)

Основна заробітна плата:

 грн. (5.23)

Додаткова зарплата:

 грн. (5.24)

Згідно з чинним законодавством єдиний соціальний внесок для програміста з класом професійного ризику 2 становить 36.77% від заробітної плати.

Таким чином, фонд заробітної плати програміста дорівнює:

 (5.25)

Вартість машинного часу, витраченого на налагодження ПП, визначається за формулою:

, (5.26)

де  - собівартість однієї машинної години роботи ЕОМ, грн.;

 - машинний час, необхідний для налагодження ПП, год.

Собівартість однієї машинної години визначається за формулою:

 (5.27)

де  - річні експлуатаційні витрати, грн;

 - річний фонд корисної роботи ЕОМ, год (визначається виходячи з календарного річного фонду часу за винятком вихідних, свят і добового режиму роботи).

Річний фонд часу корисної роботи ЕОМ складає:

 (5.28)

де  - кількість робочих днів у році ( = 253 днів);

 - номінальна кількість годин щодоби роботи пристрою (8год);

 - кількість годин у році на поточний ремонт та обслуговування (15% від ).

Тоді  год.

Річні експлуатаційні витрати визначаються за наступною формулою:

 (5.29)

де  - основна і додаткова заробітна плата персоналу, який обслуговує техніку;

 - відрахування на соціальні заходи (37.5% від фонду оплати праці персоналу, що обслуговує техніку);

 - амортизаційні відрахування (25% від , де  - вартість машини);

 - витрати на електроенергію;

 - витрати на ремонт ЕОМ (0.04, де  - вартість машини);

 - інші витрати.

Так як вартість машини дорівнює  = 7000 грн.,

то =0.25∙ 7000 =1750 грн.,

=0.04∙7000 =280 грн.

Так як потужність ЕОМ становить -  = 400 Вт, вартість1 кВт/г -

= 0.243 грн.,

а річний фонд корисного часу роботи ЕОМ -  = 1720 год, то витрати на електроенергію за рік складають:

 грн. (5.30)

Один інженер з окладом 2000 грн. обслуговує 4 ЕОМ, а середня кількість робочих днів у місяці складає 21.1, то денна заробітна плата інженера становить:

грн;

 людино-дні - трудомісткість інженера;

Таким чином, фонд заробітної плати інженера дорівнює:

 грн. (5.31)

Отже, внесок в єдиний соціальний фонд становить 36.77% для інженера другої категорії з класом професійного ризику 2:

= 0.3677 ∙  = 0.3677 ∙ 5056.5 = 1862.95 грн.

Інші витрати приймаються в розмірі 7% від суми всіх попередніх статей витрат:

=0.07 ∙ (1862.95+5056.5 +167.18+1750+280) =640.5 грн.

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

=1862.95+5056.5 +167.184+1750+280+640.5 = 9790.4 грн.

Отже, вартість однієї машинної години складає:

грн. =1200год.

Таким чином, вартість машинного часу становить:

 грн.

=5.69∙1200 =6828 грн.;

 грн.

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

 грн. (5.32)

5.5.2 Оцінка техніко-економічного рівня варіантів ПП

Визначимо показник техніко-економічного рівня за формулою:

 (5.33)

де  - коефіцієнт рівня якості і-го варіанту;

 - вартість розробки ПП і-го варіанту.

Проведемо оцінку варіантів рішення, порівнюючи показники техніко-економічного рівня:

;

;

.

Самим раціональним варіантом буде третій, оскільки він має максимальне значення

5.6 Висновки до розділу

В результаті виконання економічного розділу були систематизовані і закріплені теоретичні знання в області економіки та організації виробництва використанням їх для техніко-економічного обґрунтування розробки методом ФВА. У даному дипломному проекті виконаний ФВА програмного продукту. Запропоновано чотири різних варіанти реалізації даного програмного продукту. Найбільш ефективним є останній варіант, показаний в таблиці 5.7.

Таблиця 5.7 - Результати аналізу

Назва показника	Позначення	Одиниця виміру	Числове значення
Узагальнений показник рівня якості	Кт. р		5,01
Показник техніко-економічного рівня якості ПП	Кт.е. р
Загальні витрати на розробку ПП	Спп

6. Охорона праці та безпека в надзвичайних ситуаціях

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

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

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

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

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

Згідно [7], робота з розробленим програмним продуктом відноситься до 2 класу (таблиця "Класи умов праці за показниками напруженості трудового процесу").

 

.1.1 Аналіз приміщення

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

Кількість працюючих у приміщенні 2. У приміщенні знаходиться 3 столи, 4 стільці, 2 комп'ютери, 1 принтер, 1 телефон, 1 шафа, 1 тумбочка.

Рисунок 6.1 - План робочого приміщення

Таблиця 6.1 - Розміри приміщення

Найменування	Значення
Довжина, м	6.0
Ширина, м	4.0
Висота, м	3.0
Площа, м2	24.0
Об’єм, м3	72

6.1.2 Повітря робочої зони

Відповідно до ДСН 3.3.6.042-99 [2] роботу, що виконується в лабораторії, можна віднести до категорії легка Ia, оскільки вона виконується сидячи і не вимагає фізичної напруги. Оптимальні значення параметрів мікроклімату, прийняті проектом, наведені у таблиці 6.2.

Таблиця 6.2 - Норми мікроклімату робочої зони об’єкту

Період року	Категорія робіт	Температура С0	Відносна вогкість %	Швидкість руху. повітря, м/с
Холодна	легка-1 а	22 - 24	40 - 60	0,1
Тепла	легка-1 а	23 - 25	40 - 60	0,1

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

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

Прилади контролю - термометр, психрометр, анемометр.

6.1.3 Виробниче освітлення

Відповідно до ДБН В.2.5-28-2006 [1] роботи, що виконуються в приміщенні відносяться до V розряду зорових робіт. Передбачається використання комбінованого природного (верхнє освітлення поєднується з бічним), і комбінованого штучного (загальне і місцеве освітлення робочих місць світильниками) і суміщеного освітлення. У світильниках місцевого освітлення використовуються люмінесцентні лампи, нормального виконання.

У виробничих приміщеннях прийнята система загального рівномірного освітлення. Норми параметрів освітлення приведено в таблиці 6.3.

Таблиця 6.3 - Санітарні норми параметрів освітлення приміщення

Характеристика зорової роботи	Розряд зорової роботи	Штучне освітлення		Природне освітлення		Суміщене освітлення
		Освітленість, лк		КЕО%
		При комбінованому освітленні	При загальному освітленні	При верхньому або комбінованому освітленні	При бічному освітленні	При верхньому або комбінованому освітленні	При бічному освітленні
Малої точності	V6	300-200	200-100	3	1	1,8	0,6

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

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

На даному підприємстві згідно СН 181-70 передбачається пофарбування стін і стелі в світлі тони з відносно невеликою насиченістю і високим коефіцієнтом віддзеркалення; застосовувати теплі тони, необхідно дотримувати контрасти між теплими і холодними тонами (оскільки стіни забарвлені в теплі тони, то устаткування забарвлено в холодні).

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

6.1.4 Захист від виробничого шуму і вібрації

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

Допустимий рівень вібрації на робочому місці:

·        для 1 ступеня шкідливості до 3 дБ;

·        для 2-3 - 1-6 дБ;

·        для 3 - більше 6 дБ.

Параметрами постійного шуму, що підлягають нормуванню, є рівні звукового тиску 8 дБ в октавних смугах частот з середньогеометричними частотами 16, 31.5, 63, 125, 250, 500, 1000, 2000, 4000, 8000 Гц, рівні звуку 80 дБА згідно ДСН 3.36.037-99 [2].

Допустимі значення октавних рівнів звукового тиску, рівнів звуку на робочих місцях в приміщеннях з комп'ютерною технікою слід приймати згідно таблиці 6.4. В приміщеннях із ЕОМ корегований рівень звукової потужності не перевищує 45 дБА.

Вібрація на робочих місцях, що створюється ЕОМ, не вище значень, які представлені в таблиці 6.5.

Таблиця 6.4 - Норми параметрів значення октавних рівнів

Призначення приміщення та умови	Рівні звукового тиску, дБ, в октанових смугах частот з середньогеометричними частотами, Гц										Рівні звуку, дБА
	16	31,5	63	125	250	500	1000	2000	4000	8000
Приміщення без роботи ЕОМ	-	-	63	52	45	39	35	32	30	28	40
Приміщення при роботі ЕОМ	85	75	67	57	49	44	40	37	35	33	45

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

Таблиця 6.5 - Гранично допустимі рівні вібрації на робочому місці, дБ

Нормований параметр	Середньогеометричні частоти октанових смуг, Гц						Коректовані та еквівалентні рівні, дБ
	2	4	8	16	31,5	63
Віброшвидкість	79	73	67	67	67	67	72
Віброприскорення	25	25	25	31	37	43	30

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

6.1.5 Випромінювання

Одним із шкідливих апаратних забезпечень ЕОМ для людського організму є дисплеї, побудовані на основі електронно-променевої трубки, які являються джерелами електростатичного поля, м'якого рентгенівського, ультрафіолетового, інфрачервоного, видимого, низькочастотного, наднизькочастотного та високочастотного електромагнітного випромінювання (ЕМВ).

Енергія рентгенівського та частини інших випромінювань повністю поглинається склом екрана. Навколо працюючого монітору виникають електромагнітні поля низької частоти (від 5 Гц до 400 кГц).

Граничнодопустима напруженість електростатичного поля на робочих місцях не перевищує рівнів, наведених в ТСО’99, ДСанПіН 3.3.2-007-98 [3], ДНАОП 000.131-99 [2].

Таблиця 6.6 - Параметри електромагнітних неіонізуючих випромінювань і електростатичного поля

Смуга частот, кГц	Електричне поле, В/м	Магнітне поле, нТл
0,005-2	10	200
2-400	1,0	25

Поверхневий електростатичний потенціал не перевищує 500 В.

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

·        встановлені заземлені захисні фільтри для екранів моніторів (СР-фільтри фірми Polaroid CP Universal Gold), які зменшують випромінювання видимого діапазону на 60 %, випромінювання ELF+VLF на 99,6 %, збільшують контрастність в 50 разів.

·        віддаль від екрана монітору до користувача становить 600-700 мм;

6.1.6 Електробезпека

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

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

Відповідно ГОСТ 12.1.038-82 допустимі рівні напруги дотику (U_д) і струму, що проходить через тіло людини (I_д) дорівнює: при нормальному режимі роботи електроустаткування U_д = 2В, а I_д = 0,3мА при τ ≤ 10хв; при аварійному - відповідно 36В і 6мА, при τ > 1c.

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

де U_ф = 220 - фазна напруга, В;_л = 4000 - опір тіла людини, Ом;_o - опір нейтралі заземлення, Ом.

Напруга дотику розраховується по формулі:

_пр = I_л* R_л = 55*4 = 220В.

Як видно з порівняння при порушені ПБЕ (правил безпечної експлуатації електроустановок споживача) можливі електротравми з тяжкими наслідками.

На робочому місці виконуються наступні вимоги електробезпеки:

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

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

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

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

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

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

6.1.7 Безпека технологічних процесів та обслуговування обладнання

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

Для підтримки оптимальних умов в холодний період передбачена центральна система водяного опалення, згідно СНиП 2.04.05-91 [3] однотрубна з нижнім підведенням і передбачається природна і механічна вентиляція. Механічна вентиляція здійснюється за допомогою вентиляторів. Припливні отвори розташовані в нижній частині приміщення на висоті 1,2м, щоб зовнішнє повітря в теплу пору року надходило безпосередньо на робоче місце. У холодний час припливні отвори відкривають на висоті 4м від підлоги, аби зовнішнє повітря, доходячи на робоче місце, встигало змішуватись з теплим внутрішнім повітрям. Отвори для витоку повітря розташовуються вище за пристрої для приймання повітря.

6.2 Пожежна безпека

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

Електростатичний розряд виникає під час тертя двох ізольованих матеріалів. Розряд статичної електрики може виникнути під час роботи вентилятора чи комп’ютера.

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

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

·        навкруги виробничих корпусів - проїзди;

·        через кожні 5,0-7,5 м по ланцюгу зовнішнього водопроводу встановлені гідранти;

·        передбачений внутрішній протипожежний водопровід з витратами води 2,5 л\с;

·        із зовнішньої ст9орони будівлі передбачено встановлення пожежних сходів.

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

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

Будівля захищена від прямого удару блискавки (відповідно до СН 305 - 77) за допомогою вертикально-стрижньового блискавковідводу, що складається з блискавкоприймача, заземлювача і струмопровідника антенного типу. У приміщенні, окрім стаціонарної системи пожежогасіння згідно з [7] відповідно до типу приміщення і його площі були обрані 2 вогнегасника порошкових, закачних ВП-5 (з). Зазначені вогнегасники відповідають ДСТУ 3675-98.

У даному розділі проекту була проведена оцінка пожежо - і вибухонебезпечності проектованого приміщення.

6.3 Висновки до розділу

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

Висновки

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

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

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

Перелік посилань

1.      ДБНВ.1.1-7 - 2002, Пожарная безопасность объектов строительства Госстрой Украины, Киев, 2003 - 42с.

2.      ДСанПіН 3.3.2.007 - Державні санітарні правила і норми роботи з візуальними дисплейними терміналами електронно-обчислювальних машин. - Київ 1998р.

.        ДСН 3.3.6.037-99 - Санітарні норми виробничого шуму, ультразвуку і інфразвуку, 1999

.        ДНАОП 0.00-1.32-01 - Затверджено наказом Міністерства праці та соціальної політики України від 21 червня 2001 р. N 272

.        ОНТП 24-86. - Определение категорий помщений и зданий по взрывопожарной и пожарной опасности. ВНИИ ПО МВД СССР, 1987.30с.

.        Гігієнічна класифікація праці - Наказ МОЗ України № 528 від 27.12.2001 року

.        Типові норми належності вогнегасників - Наказ Міністерства України з питань надзвичайних ситуацій та у справах захисту населення від наслідків Чорнобильської катастрофи від 2 квітня 2004 р. N 151

.        Гленфорд Майерс, Том Баджетт, Кори Сандлер Искусство тестирования программ, 3-е издание = The Art of Software Testing, 3rd Edition. - М.: "Диалектика", 2012. - 272 с. - ISBN 978-5-8459-1796-6

.        Лайза Криспин, Джанет Грегори Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд = Agile Testing: A Practical Guide for Testers and Agile Teams. - М.: "Вильямс", 2010. - 464 с. - (Addison-Wesley Signature Series). - 1000 экз. - ISBN 978-5-8459-1625-9

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

.        Калбертсон Роберт, Браун Крис, Кобб Гэри Быстрое тестирование. - М.: "Вильямс", 2002. - 374 с. - ISBN 5-8459-0336-X

.        Синицын С.В., Налютин Н.Ю. Верификация программного обеспечения. - М.: БИНОМ, 2008. - 368 с. - ISBN 978-5-94774-825-3

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

Додаток

Додаток А

 

Програмний код розробленого пакета:

Collections_Test. js

#import "Join_It_Functions. js"target = UIATarget. localTarget ();. logStart ("Join It Temp Script");. delay (1);. frontMostApp (). mainWindow (). elements () [0]. tap (); // Cancel video. delay (2);. frontMostApp (). mainWindow (). buttons () ["Collections"]. tap ();. delay (1);. frontMostApp (). mainWindow (). buttons () ["Add Pictures"]. tap ();. delay (1);. frontMostApp (). mainWindow (). popover (). tableViews () [0]. cells () [Random (8)]. tap ();. delay (5);(i=0; i<3; i++)

{. frontMostApp (). mainWindow (). popover (). scrollViews () [0]. elements () [i]. tap ();. delay (2);

}. delay (5);. frontMostApp (). mainWindow (). popover (). navigationBar (). buttons () ["Back"]. tap ();. delay (1);. frontMostApp (). mainWindow (). popover (). tableViews () [0]. cells () ["My Photos"]. tap ();. delay (1);. frontMostApp (). mainWindow (). popover (). tableViews () ["Empty list"]. cells () [0]. tap ();. delay (1);. frontMostApp (). mainWindow (). popover (). tableViews () ["Empty list"]. cells () [20]. images () [0]. tap ();(j=0; j<10; j++)

{. frontMostApp (). mainWindow (). tableViews () ["Empty list"]. cells () [j]. tap ();. delay (1);

}. frontMostApp (). mainWindow (). tableViews () ["Empty list"]. cells () ["Join It - Original Collection"]. tap ();. delay (1);. frontMostApp (). mainWindow (). scrollViews () [0]. elements () [0]. tap ();. delay (1);. frontMostApp (). mainWindow (). tableViews () ["Empty list"]. cells () ["All Pictures"]. tap ();. delay (1);. frontMostApp (). mainWindow (). buttons () ["Edit"]. tap ();. delay (1);(k=0; k<4; k++)

{. frontMostApp (). mainWindow (). scrollViews () [0]. elements () [Random (16)]. tap ();. delay (1);

}. frontMostApp (). mainWindow (). buttons () ["Delete"]. tap ();. delay (1);. frontMostApp (). mainWindow (). popover (). buttons () ["Delete Selected Pictures"]. tap ();. delay (1);. frontMostApp (). mainWindow (). buttons () ["Back"]. tap ();. delay (1);. logPass ("Done");

Smoke_Test. js

#import "Join_It_Functions. js"target = UIATarget. localTarget ();. logStart ("Join It Temp Script");. delay (1);. frontMostApp (). mainWindow (). elements () [0]. tap (); // Cancel video. delay (1);_Launch_Check ();_Random_Picture ();_Difficulty ("Easy");. delay (1);_Difficulty ("Medium");. delay (1);_Difficulty ("Hard");. delay (1);_Difficulty ("Insane");. delay (1);_Difficulty_Drag (Random (1));. delay (1);_Difficulty ("Easy");. delay (1);_Options ();_Sticking ();_Rotation ();_Timer ();_Sound ();_Iphone ();_Ipad ();_Piece_Style (1);_Piece_Style (2);_Piece_Style (3);_Piece_Style (4);_Piece_Style ();_Background (Random (8));_Options ();_Game (5);();. logPass ("Done");. frontMostApp (). mainWindow (). images () [3]. doubleTap ();

Suspend_Test. js

#import "Join_It_Functions. js"target = UIATarget. localTarget ();. logStart ("Join It Temp Script");. delay (1);. frontMostApp (). mainWindow (). elements () [0]. tap (); // Cancel video. delay (2);

// First_Launch_Check ();(3);. delay (1);. frontMostApp (). mainWindow (). buttons () ["Collections"]. tap ();. delay (1);(3);. delay (1);. frontMostApp (). mainWindow (). scrollViews () [0]. elements () [0]. tap ();. delay (1);(3);. delay (1);_Options ();. delay (1);(3);. delay (1);_Options ();. delay (1);(3);. delay (1);_Game (5);. delay (1);(3);. delay (1);. frontMostApp (). mainWindow (). staticTexts () ["Resume"]. tap ();. delay (1);_Game ();. delay (1);(3);. delay (1);. logPass ("Done");

Main_Screen_Test. js

#import "Join_It_Functions. js"target = UIATarget. localTarget ();. logStart ("Join It Temp Script");. delay (1);. frontMostApp (). mainWindow (). elements () [0]. tap (); // Cancel video. delay (2);. frontMostApp (). mainWindow (). buttons () ["HelpToolbar"]. tap ();. delay (1);. frontMostApp (). mainWindow (). buttons () ["BackToolbar"]. tap ();. delay (1);_Difficulty ("Easy");. delay (2);_Difficulty ("Medium");. delay (2);_Difficulty ("Hard");. delay (2);_Difficulty ("Insane");. delay (2);. frontMostApp (). mainWindow (). elements () [7]. tap (); // Enter Hi Score. delay (1);. frontMostApp (). mainWindow (). elements () [8]. tap (); // Exit Hi Score. delay (1);_Difficulty_Drag (0);. delay (1);_Difficulty_Drag (0.5);. delay (1);(target. frontMostApp (). mainWindow (). buttons () [2]. isVisible () ==true)

{. frontMostApp (). mainWindow (). buttons () [2]. tap ();. delay (1);

}_Options ();_Options ();. frontMostApp (). mainWindow (). images () [2]. buttons () ["Info"]. tap ();. delay (4);. frontMostApp (). mainWindow (). images () [2]. buttons () ["saveButton"]. tap ();. frontMostApp (). mainWindow (). images () [2]. buttons () ["zoomButton"]. tap ();. delay (1);. frontMostApp (). mainWindow (). images () [2]. tap ();. delay (1);. frontMostApp (). mainWindow (). buttons () ["Next"]. tap ();. delay (2);. frontMostApp (). mainWindow (). buttons () ["Previous"]. tap ();. delay (2);. flickFromTo ({x: 360, y: 200}, {x: 160, y: 200}); // Flick Picture Change (NEXT). delay (2);. flickFromTo ({x: 160, y: 200}, {x: 260, y: 200}); // Flick Picture Change (PREVIOUS). delay (2);. frontMostApp (). mainWindow (). buttons () ["Collections"]. tap ();. delay (1);. frontMostApp (). mainWindow (). buttons () ["Back"]. tap ();. delay (1);. frontMostApp (). mainWindow (). images () [2]. buttons () ["Go"]. tap ();. logPass ("Done");

Difficulty_Test. js

#import "Join_It_Functions. js"target = UIATarget. localTarget ();. logStart ("Join It Temp Script");. delay (1);. frontMostApp (). mainWindow (). elements () [0]. tap (); // Cancel video. delay (1);_Difficulty ("Easy");_Game (5);. captureScreenWithName ("Easy Game");_Game ();_Difficulty ("Medium");_Game (10);. captureScreenWithName ("Medium Game");_Game ();_Difficulty ("Hard");_Game (15);. captureScreenWithName ("Hard Game");_Game ();_Difficulty ("Insane");_Game (20);. captureScreenWithName ("Insane Game");_Game ();. logPass ("Done");

Help_Test. js

#import "Join_It_Functions. js"target = UIATarget. localTarget ();. logStart ("Join It Temp Script");. delay (1);. frontMostApp (). mainWindow (). elements () [0]. tap (); // Cancel video. delay (2);. frontMostApp (). mainWindow (). buttons () ["HelpToolbar"]. tap ();. delay (1);. captureScreenWithName ("Help_Screenshot_iPad 1");. delay (1);(i=2; i<5; i++)

{. frontMostApp (). mainWindow (). scrollViews () [0]. scrollViews () [0]. webViews () [0]. scrollDown ();. delay (1);. captureScreenWithName ("Help_Screenshot_iPad " +i);. delay (1);

}. delay (2);. frontMostApp (). mainWindow (). scrollViews () [0]. scrollViews () [0]. webViews () [0]. staticTexts () ["iPhone Controls"]. tap ();. delay (1);. captureScreenWithName ("Help_Screenshot_iPhone 1");. delay (1);(i=2; i<5; i++)

{. frontMostApp (). mainWindow (). scrollViews () [0]. scrollViews () [0]. webViews () [0]. scrollDown ();. delay (1);. captureScreenWithName ("Help_Screenshot_iPhone " +i);. delay (1);

}. delay (2);. frontMostApp (). mainWindow (). scrollViews () [0]. scrollViews () [0]. webViews () [0]. links () ["\nJoin It website"]. staticTexts () ["Join It website"]. tap ();. delay (1);. frontMostApp (). mainWindow (). buttons () ["BackToolbar"]. tap ();. logPass ("Done");

Picture_Change_Test. js

#import "Join_It_Functions. js"target = UIATarget. localTarget ();. logStart ("Join It Temp Script");. delay (1);. frontMostApp (). mainWindow (). elements () [0]. tap (); // Cancel video. delay (1);. frontMostApp (). mainWindow (). buttons () ["Collections"]. tap ();. delay (1);. frontMostApp (). mainWindow (). scrollViews () [0]. elements () [0]. tap ();. delay (2);(i=1; i<16; i++)

{. flickFromTo ({x: 360, y: 200}, {x: 160, y: 200}); // Flick Picture Change (NEXT). delay (2);

}(i=1; i<16; i++)

{. flickFromTo ({x: 160, y: 200}, {x: 260, y: 200}); // Flick Picture Change (PREVIOUS). delay (2);

}(j=1; j<16; j++)

{. frontMostApp (). mainWindow (). buttons () ["Next"]. tap (); // Button Picture Change (NEXT). delay (2);

}(j=1; j<16; j++)

{. frontMostApp (). mainWindow (). buttons () ["Previous"]. tap (); // Button Picture Change (PREVIOUS). delay (2);

}. logPass ("Done");

Piece_Style_Test. js

#import "Join_It_Functions. js"target = UIATarget. localTarget ();. logStart ("Join It Temp Script");. delay (1);. frontMostApp (). mainWindow (). elements () [0]. tap (); // Cancel video. delay (1);

// First_Launch_Check ();(j=1; j<5; j++)

{_Options ();_Piece_Style (j);. delay (1);_Options ();_Game (5);. captureScreenWithName ("Piece_Syle " + j);_Game ();

}. logPass ("Done");

High_Score_Test. js

#import "Join_It_Functions. js"target = UIATarget. localTarget ();. logStart ("Join It Temp Script");. delay (1);. frontMostApp (). mainWindow (). elements () [0]. tap (); // Cancel video. delay (2);. frontMostApp (). mainWindow (). elements () [7]. tap (); // High SCore_Difficulty ("Easy");. delay (2);. captureScreenWithName ("High Score for Easy");_Difficulty ("Medium");. delay (2);. captureScreenWithName ("High Score for Medium");_Difficulty ("Hard");. delay (2);. captureScreenWithName ("High Score for Hard");_Difficulty ("Insane");. delay (2);. captureScreenWithName ("High Score for Insane");. frontMostApp (). mainWindow (). buttons () ["HelpToolbar"]. tap ();. frontMostApp (). mainWindow (). buttons () ["BackToolbar"]. tap ();_Options ();_Options ();. frontMostApp (). mainWindow (). elements () [8]. tap (); // Main Menu. logPass ("Done");

Join_It_Functions. js

var target = UIATarget. localTarget ();Deactivate (t)

{. localTarget (). deactivateAppForDuration (t);

}Start_Game (t)

{. frontMostApp (). mainWindow (). images () [3]. buttons () ["Go"]. tap ();. delay (t);. tap ({x: 350.00, y: 350.00});

}Game ()

{_Options ();_Reference_Picture_Visibility (Random (1));_Sticking ();_Picture_Frame ();_Table_Scale (Random (1));_Zoom_Lock ();_Rotation ();_Timer ();_Sound ();_Sharing ();_Background (Random (8));_Options ();_Game ();

}Exit_Game ()

{. frontMostApp (). mainWindow (). buttons () ["Pause"]. tap ();. delay (1);. frontMostApp (). mainWindow (). staticTexts () ["Main Menu"]. tap ();

}First_Launch_Check ()

{(target. frontMostApp (). mainWindow (). staticTexts () ["What's New"]. isVisible () ==true)

{. delay (20);. frontMostApp (). mainWindow (). buttons () ["Continue"]. tap ();. delay (1);. frontMostApp (). mainWindow (). buttons () ["iPadButtonSwitchPressed"]. tap ();. delay (1);. frontMostApp (). mainWindow (). buttons () ["OK"]. tap ();. delay (1);

}

}Open_Options ()

{(target. frontMostApp (). mainWindow (). buttons () ["HelpToolbar"]. isVisible () ==true)

{. frontMostApp (). mainWindow (). buttons () ["SettingsSmall"]. tap (); // The Options

}

{. frontMostApp (). mainWindow (). buttons () ["SettingsControl"]. tap (); // The InGame Options

}. delay (1);

}Close_Options ()

{. tap ({x: 651.00, y: 63.00});

}Random (p)

{(p<=1)

{= Math. random ();

}

{= parseInt (Math. random () * p) +1;

}. logMessage ("Random Number is " +r)r;

}Set_Reference_Picture_Visibility (r)

{. frontMostApp (). mainWindow (). scrollViews () [0]. sliders () [0]. dragToValue (r);

}Tap_Sticking ()

{. frontMostApp (). mainWindow (). scrollViews () [0]. elements () [6]. tap (); // STICKING y={95: 123}. delay (1);

}Tap_Picture_Frame ()

{. frontMostApp (). mainWindow (). scrollViews () [0]. elements () [10]. tap ();

}Set_Table_Scale (r)

{. frontMostApp (). mainWindow (). scrollViews () [0]. sliders () [1]. dragToValue (r);

}Tap_Zoom_Lock ()

{. frontMostApp (). mainWindow (). scrollViews () [0]. elements () [10]. tap ();

}Tap_Rotation ()

{. frontMostApp (). mainWindow (). scrollViews () [0]. elements () [22]. tap (); // ROTATION y={430: 460}. delay (1);

}Tap_Timer ()

{. frontMostApp (). mainWindow (). scrollViews () [0]. elements () [25]. tap (); // TIMER y={479: 509}. delay (1);

}Tap_Sound ()

{. frontMostApp (). mainWindow (). scrollViews () [0]. elements () [28]. tap (); // SOUND y={526: 556}. delay (1);

}Tap_Sharing ()

{. frontMostApp (). mainWindow (). scrollViews () [0]. elements () [30]. tap (); // SHARING y={573: 603}. delay (1);

}Tap_Iphone ()

{. frontMostApp (). mainWindow (). scrollViews () [0]. elements () [34]. tap (); // IPHONE. delay (1);

}Tap_Ipad ()

{. frontMostApp (). mainWindow (). scrollViews () [0]. elements () [35]. tap (); // IPAD. delay (1);

}Tap_Piece_Style (Piece_Num)

{(Piece_Num)

{1:. frontMostApp (). mainWindow (). scrollViews () [0]. scrollViews () [0]. elements () [0]. tap (); // PIECE STYLE 1. delay (1);;2:. frontMostApp (). mainWindow (). scrollViews () [0]. scrollViews () [0]. elements () [1]. tap (); // PIECE STYLE 2. delay (1);;3:. frontMostApp (). mainWindow (). scrollViews () [0]. scrollViews () [0]. elements () [2]. tap (); // PIECE STYLE 3. delay (1);;4: target. frontMostApp (). mainWindow (). scrollViews () [0]. scrollViews () [0]. elements () [3]. tap (); // PIECE STYLE 4. delay (1);;:. frontMostApp (). mainWindow (). scrollViews () [0]. scrollViews () [0]. elements () [2]. tap (); // PIECE STYLE 3. delay (1);

}

}Choose_Background (r)

{. frontMostApp (). mainWindow (). scrollViews () [0]. scrollViews () [0]. elements () [3]. scrollToVisible ();. delay (1);. frontMostApp (). mainWindow (). scrollViews () [0]. buttons () [8]. tap ();. delay (1);(r)

{1:. frontMostApp (). mainWindow (). scrollViews () [0]. buttons () [1]. tap (); // PIECE STYLE 1. delay (1);;2:. frontMostApp (). mainWindow (). scrollViews () [0]. buttons () [2]. tap (); // PIECE STYLE 2. delay (1);;3:. frontMostApp (). mainWindow (). scrollViews () [0]. buttons () [3]. tap (); // PIECE STYLE 3. delay (1);;4:. frontMostApp (). mainWindow (). scrollViews () [0]. buttons () [4]. tap (); // PIECE STYLE 4. delay (1);;5:. frontMostApp (). mainWindow (). scrollViews () [0]. buttons () [5]. tap (); // PIECE STYLE 1. delay (1);;6:. frontMostApp (). mainWindow (). scrollViews () [0]. buttons () [6]. tap (); // PIECE STYLE 2. delay (1);;7:. frontMostApp (). mainWindow (). scrollViews () [0]. buttons () [7]. tap (); // PIECE STYLE 3. delay (1);;8:. frontMostApp (). mainWindow (). scrollViews () [0]. buttons () [8]. tap (); // PIECE STYLE 4. delay (1);;:. frontMostApp (). mainWindow (). scrollViews () [0]. buttons () [1]. tap (); // PIECE STYLE 3. delay (1);

}. delay (1);

}Change_Difficulty (Difficulty)

{(Difficulty)

{"Easy":. frontMostApp (). mainWindow (). elements () [3]. tap (); // EASY. delay (1);;"Medium":. frontMostApp (). mainWindow (). elements () [4]. tap (); // MEDIUM. delay (1);;"Hard":. frontMostApp (). mainWindow (). elements () [5]. tap (); // HARD. delay (1);;"Insane":. frontMostApp (). mainWindow (). elements () [6]. tap (); // INSANE. delay (1);;:. frontMostApp (). mainWindow (). elements () [4]. tap (); // MEDIUM. delay (1);

}

}Change_Difficulty_Drag (Difficulty_Drag)

{. frontMostApp (). mainWindow (). sliders () [0]. dragToValue (Difficulty_Drag);. delay (2);

}Choose_Random_Picture (Random_Image)

{. frontMostApp (). mainWindow (). buttons () ["Collections"]. tap ();=Random (6);(r==1)

{++;

}. frontMostApp (). mainWindow (). tableViews () ["Empty list"]. cells () [r]. tap ();. delay (2);=Random (15);. frontMostApp (). mainWindow (). scrollViews () [0]. elements () [r]. tap ();. delay (1);++;(target. frontMostApp (). mainWindow (). buttons () ["Edit"]. isVisible () ==true)

{. delay (30);. frontMostApp (). mainWindow (). scrollViews () [0]. elements () [r]. tap ();. delay (1);

}

}