Розробка пакету автоматизованого тестування програмних застосувань на платформі 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 Висновки до розділу
  • Висновки
  • Перелік посилань
  • Додаток

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

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

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

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

МБ — мегабайт

ГБ — гігабайт

ГГц — гігагерц

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

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

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

ТОВ — товариство з обмеженою відповідальністю

GUI (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 необхідно підключення до мережі Інтернет.

1.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. Продукт являє собою додаток, що симулює роботу користувача з головоломкою — пазлом. Додаток має наступний функціонал:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процес гри

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

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

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

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

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

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

7. Перемога

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Меню Паузи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10) Старт гри

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

12) Гра

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

14) Кінець гри

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. 1, 1. 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПоказатьСвернуть
Заполнить форму текущей работой