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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Функціональну пригодність (англ. 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 - Результати дослідження методом чорної скриньки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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