🧩Тестування за метою

Типи тестування за метою

• Функціональне (Functional testing)

• Нефункціональне (Non-functional testing)

• Тестування структури та архітектури (Structural testing)

• Тестування пов'язане зі змінами (Confirmation and Regression testing)

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

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

Елементи функціонального тестування:

• підготовка тестових даних виходячи з описаної документації;

• бізнес-вимоги, як частина функціонального тестування;

• отримання результатів на основі специфікації;

• проходження тест-кейсів;

• аналіз фактичних та очікуваних результатів.

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

Переваги функціонального тестування:

• в рамках тестування ми «копіюємо» безпосереднє використання системи;

• тестування, як правило, проводиться в умовах близьких до реальних.

Недоліки:

• існує ймовірність пропустити кілька помилок логіки гри під час перевірки функціоналу програми.

Типи функціонального тестування:

• Функціональне тестування (Functional testing);

• Тестування безпеки (Security and Access Control Testing);

• Тестування взаємодії (Interoperability Testing);

• Тестування інтерфейсу користувача (GUI Testing).

Приклади:

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

• Взаємодія користувачів.

• Інтерфейси користувача.

• Тестування транзакцій.

• Калібрування та перевірка точності камер мобільного телефону.

• Роздільна здатність екрану.

• Тестування адаптивного дизайну мобільних пристроїв.

• Тестування якості звуку.

Нефункціональне (Non-functional testing)

Якщо в рамках функціонального тестування ми відповідаємо на питання «Чи працює система?», то нефункціональне відповідає на питання: «Як добре працює система?». Нефункціональне тестування направлено на перевірку тих аспектів гри, які можуть бути описані в документації, але не відносяться до функцій програмних продуктів.

Нефункціональне тестування складається з підвидів. Розглянемо деякі з них:

Тестування сумісності - Перевірка, чи гра сумісна на різних пристроях та в різних конфігураціях апаратного та програмного забезпечення.

Приклад: Встановити та видалити гру на всіх підтримуваних мобільних телефонах.

Тестування продуктивності - Перевіряється загальна ефективність гри. Налаштування продуктивності виконується для оптимізації швидкості гри.

Параметри важливості перевірені під час тестування продуктивності:

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

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

• Обмеження процесора та пам'яті: лічильники продуктивності використовуються для вимірювання центрального процесора та споживання пам'яті додатком.

• Мережеве підключення: вимірює час відгуку мобільних ігор на різні типи мереж (Wi-Fi, 2G, 3G, 4G). Це дає загальне уявлення про те, наскільки добре гра буде працювати в ненадійних мережах. Він також перевіряє зв'язок між мобільними пристроями, центрами обробки даних або хмарою. Весь час піків, нестабільні зв’язки, копіювання даних, втрата пакетів, фрагментація даних контролюються.

• Тестування продуктивності мобільних ігор, особливо MMO

Тестування на відповідність - відповідність правилам Marketplace (наприклад, політиці Apple App Store), корпоративній політиці (наприклад, заборонений вміст. Гра націлена на певний рейтинг вмісту. Якщо є неприйнятний вміст, який є невідповідні бажаному рейтингу, тоді вони виявляються та повідомляються. Навіть за одне порушення, подане на затвердження ліцензії, гра може бути відхилена, що спричинить додаткові витрати на подальше тестування та повторне подання.

Приклад: Якщо гра планується опублікувати в європейських країнах, протестуйте на конвертацію PAL, якщо гра створена для Північної Америки, протестуйте на конвертацію NTSC.

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

Приклад: Локалізація потреб, характерних для регіону MENA (Близький Схід/ Північна Африка), арабська локалізація (підтримка тексту справа наліво, двонаправлені дисплеї), тестування псевдо-локалізації, двобайтові символи (для східно азіатських мов), місцеві час/дата, валюта, формати адрес та інші місцеві вимоги.

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

Приклад: Гра розпочалась, і персонаж змушений стояти без діла протягом 24 годин. Ця техніка використовується для виявлення збоїв, спричинених витоками пам'яті та іншими несправностями в ігровій системі.

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

Приклад: Поки запущена ігрова програма, раптово перезапустіть ігрову консоль і перевірте перевірку цілісності даних

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

Приклад: Зміна URL-адреси з / login на / play на ігровому сайті не повинна дозволити прямий доступ до ігор.

Тестування структури та архітектури (Structural testing)

Структурне тестування направлено на тестування структури системи або компонента. Цей вид тестування, як правило, відносять до тестування «білого» та «сірого» ящиків, оскільки ми перевіряємо, що відбувається всередині системи або гри.

Методи структурного тестування:

1. Строкове покриття (Statement Coverage) – перевірка застосування усіх операторів в грі на використання (хоча б один раз).

2. Покриття шляху (Path Coverage) – метод тестування, призначений для задоволення критеріїв охоплення кожного логічного шляху через програму.

3. Покриття рішення (Branch Coverage) – перевіряє, чи має кожна умова розгалуження для програми дійсні чи хибні значення;

4. Покриття умови (Condition Coverage) – метод, схожий на Branch Coverage, основна відмінність полягає в перевірці стану покриття для умовних і неумовних гілок.

Переваги:

• можливість виявити та видалити «зайвий» код;

• можливість виявлення потенційних помилок на ранній стадії;

• забезпечує більш ретельне тестування гри;

• не потребує високих витрат людино-годин.

Недоліки:

• вимагає знання коду та інструментів тестування.

Тестування пов'язане зі змінами. Confirmation and regression tests.

При тестуванні змін в системі дуже важливо зрозуміти різницю та межу між поняттями регресійне тестування (Regression testing) та повторне тестування (Retesting).

Регресійне тестування (Regression testing) проводиться з метою перевірки працездатності функціоналу, що існує, та перевірки на відсутність сторонніх помилок після оновлення білда (внесення правок або доповнень в систему). Наприклад, в гру було добавлено новий функціонал, який взаємодіє напряму з раніше створеним та розробленим функціоналом, який вже був протестований. Новий функціонал має безпосередній вплив на всю гру. В такому разі варто зробити регресивне тестування, адже в функціях де не було багів можуть виникнути нові, або відтворитись старі дефекти.

Повторне тестування (Retesting) – проводиться для підтвердження виправлення помилки та роботи даного функціоналу. Наприклад, тестувальником був знайдений баг та заведений баг-репорт. Далі розробник виправив баг, та викотив новий білд. Тестувальник має перевірити фікс баги та, або закрити його (якщо баг починений), або з відкрити повторно (якщо баг відтворився знову).

Regression testing	Retesting
Регресійне тестування виконується тільки при додаванні нової фічі (додаткова функціональність гри) або істотній зміні функціоналу системи.	Ретест виконується в тому ж оточенні й з тими ж даними, але на новому білді.
Регрес можна проводити паралельно з повторним тестуванням.	Повторне тестування має вищий пріоритет та має бути виконано до регресійного.
Тест-кейси можуть бути автоматизовані.	Тест-кейси не можуть бути автоматизовані.
В рамках регресійного тестування тест-кейси, які були відмічені раніше як «Passed», повинні бути перевірені повторно.	В рамках повторного тестування (ретест) перевіряються тест-кейси тільки зі статусом «Failed».

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

Переваги:

• підтверджує відсутність багів після додавання фічі або правки коду;

• може бути виконано з використанням інструментів автоматизації;

• допомагає поліпшити якість продукту.

Недоліки:

• даний вид тестування може бути дуже трудомістким.

Повторне тестування (Retesting)

Переваги:

• підтверджує виправлення помилки й коректну роботу функціонала;

• підвищує загальну якість продукту;

• вимагає менше часу на верифікацію;

• не вимагає яких-небудь нових налаштувань середовища тестування.

Недоліки:

• тест-кейси для повторного тестування можуть бути виявлені тільки після першого раунду тестування;

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

• вимагає додаткового часу для проходження вже пройдених раніше тест-кейсів.

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

SMOKE TEST

Димове тестування — це процес тестування гри, який визначає, чи є розгорнута збірка гри стабільною чи ні. Димове тестування є підтвердженням для команди QA продовжити подальше тестування гри. Він складається з мінімального набору тестів, які виконуються на кожній збірці для перевірки функцій гри. Димове тестування також відоме як «Тестування верифікації збірки» або «Тестування достовірності».

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

What is Smoke Testing?Guru99

Санітарне тестування

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