Офіс в Україні: +38 (063) 50 74 707

Офіс у США: +1 (212) 203-8264

Ручне тестування

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

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

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

Автоматизоване тестування

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

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

Вдосконалюйте основний функціонал вашого додатку за допомогою наших послуг з функціонального тестування

ПЕРЕГЛЯНУТИ ВСІ ПОСЛУГИ

Обговорення -

0

Обговорення -

0

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

  • функціональне тестування;
  • тестування продуктивності;
  • тестування безпеки;
  • юзабіліті-тестування;
  • тестування на сумісність;
  • тестування на відновлення.

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

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

  1. Тип програми визначається її бізнес-функціональністю (банківська справа, ігрова індустрія, соціальні мережі, освіта).
  2. Цільова аудиторія (користувач, компанія, освітнє середовище).
  3. Канал розповсюдження додатку (наприклад, App Store, Google Play або пряме розповсюдження).

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

  1. Перевірте правильність заповнення обов’язкових полів.
  2. Переконайтеся, що обов’язкові поля не відображаються на екрані як необов’язкові.
  3. Переконайтеся, що робота програми під час запуску/виходу відповідає основним вимогам.
  4. Переконайтеся, що додаток переходить у фоновий режим у разі вхідного дзвінка. Для цього вам знадобиться ще один телефон.
  5. Перевірте, чи може телефон зберігати, отримувати та надсилати повідомлення під час роботи програми. Для цього вам знадобиться інший телефон, з якого ви зможете надіслати повідомлення на тестований пристрій з уже запущеним додатком.
  6. Переконайтеся, що пристрій працює в багатозадачному режимі, коли це необхідно.
  7. Перевірте, як працюють необхідні опції з соціальними мережами - “Поділитися”, “Публікація”, “Навігація”.
  8. Переконайтеся, що додаток підтримує платіжні операції через платіжні системи Visa, Mastercard, Paypal тощо.
  9. Перевірте адекватність сценаріїв прокрутки сторінок.
  10. Перевірте наявність належної навігації між важливими модулями програми.
  11. Переконайтеся, що кількість помилок округлення мінімальна.
  12. Перевірте наявність повідомлень про помилки, наприклад, “Помилка мережі. Будь ласка, спробуйте пізніше” у разі некоректної роботи мережі.
  13. Переконайтеся, що встановлена програма не перешкоджає нормальній роботі інших програм і не споживає їхню пам’ять.
  14. Перевірте, чи може програма повернутися до стану, в якому вона перебувала до призупинення (наприклад, після жорсткого скидання або збою системи).
  15. Встановлення програми має відбутися без суттєвих помилок, за умови, що пристрій відповідає системним вимогам.
  16. Переконайтеся, що автоматичний запуск програми відбувається коректно.
  17. Перевірте, як працює додаток на всіх пристроях поколінь 2G, 3G і 4G.
  18. Проведення регресійного тестування для виявлення нових програмних помилок в існуючих і вже змінених ділянках системи. Додаткове проведення всіх попередніх тестів для перевірки поведінки програми після внесених змін.
  19. Забезпечте наявність посібника користувача.

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


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

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

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

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

Негативні сценарії (найбільш очевидні):

  • Повторна реєстрація на той самий e-mail з тим самим логіном неможлива.
  • Реєстрація без заповнення обов’язкових полів неможлива.
  • Реєстрація, якщо всі поля не заповнені, буде недоступна.
  • Реєстрація, якщо формат введених даних не відповідає вимогам, недоступна.
  • Авторизація з порожніми полями недоступна.
  • Авторизація з неправильним / видаленим / заблокованим логіном недоступна.
  • Авторизація з неправильним паролем недоступна.

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

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

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

Негативні сценарії:

  • Створення двох однакових контактів недоступне (це може бути позитивним сценарієм).
  • Створення контакту з відсутніми необхідними елементами/даними недоступне.

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

  1. Перевірка екрану на відповідність макетів.
  2. Перевірка роботи нативних жестів: свайп, мультитач тощо. - додаток повинен реагувати на них певним чином.
  3. Перевірка станів елементів: кнопки змінюють колір при натисканні, списки згортаються і розгортаються тощо.
  4. Перевірка локалізації, якщо вона заявлена в заявці. Важливо звернути увагу на верстку. Багато назв іншими мовами набагато довші, ніж англійською або російською.

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

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

  1. Визначте кількість користувачів, які можуть одночасно працювати з додатком.
  2. Перевірте, як поводиться додаток при збільшенні інтенсивності будь-яких операцій.
  3. Перевірте продуктивність програми при середньому навантаженні протягом декількох годин використання.
  4. Перевірте поведінку програми в стресових умовах.
  5. Перевірте роботу в “розрослійся” базі даних - як швидко виконуються запити.

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

  1. Визначте, чи однаково працює програма в різних умовах мережі.
  2. З’ясуйте, чи здатне поточне покриття мережі забезпечити роботу програми при різних рівнях навантаження користувачів.
  3. Визначити, чи забезпечує існуюча конфігурація клієнт-сервер оптимальну продуктивність.
  4. Знаходьте різні вузькі місця в додатках та інфраструктурі, які знижують продуктивність додатків.
  5. Перевірте, чи відповідає час відгуку заявки вимогам.
  6. Оцініть здатність продукту та/або обладнання впоратися із запланованими обсягами навантаження.
  7. Оцініть час, протягом якого батарея може підтримувати роботу програми в умовах запланованих обсягів навантаження.
  8. Перевірте роботу програми у випадках переходу з мережі Wi-Fi на мобільну мережу 2G / 3G і навпаки.
  9. Переконайтеся, що кожен з рівнів пам’яті процесора працює оптимально.
  10. Переконайтеся, що витрата заряду акумулятора і витік пам’яті не виходять за межі норми, а робота різних ресурсів і сервісів, таких як GPS-навігація або камера, відповідає вимогам.
  11. Перевірте стабільність роботи програми в умовах високого користувацького навантаження.
  12. Перевірте ефективність роботи мережі в умовах, коли пристрій знаходиться в русі.
  13. Перевірте працездатність програми, якщо вона працює в умовах непостійного підключення до Інтернету.

Тестування безпеки

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

  1. Переконайтеся, що дані користувачів додатку, логіни, паролі, номери банківських карт, захищені від мережевих атак автоматизованих систем і не можуть бути знайдені шляхом підбору.
  2. Переконайтеся, що додаток не надає доступ до конфіденційного контенту або функціоналу без належної автентифікації.
  3. Переконайтеся, що система безпеки програми вимагає надійного пароля і не дозволяє зловмиснику заволодіти паролями інших користувачів.
  4. Переконайтеся, що період тайм-ауту сеансу є достатнім для програми.
  5. Знайдіть динамічні залежності та вживіть заходів для захисту цих вразливих сайтів від зловмисників.
  6. Захистіть додаток від атак SQL-ін’єкцій.
  7. Знаходити помилки нативного коду та усувати їх наслідки.
  8. Переконайтеся, що термін дії сертифікатів не закінчився, незалежно від того, чи використовує додаток Certificate Pinnig чи ні.
  9. Захистіть програму та мережу від DoS-атак.
  10. Проаналізуйте вимоги до зберігання даних та їх верифікації.
  11. Забезпечте управління сеансами, щоб захистити інформацію від несанкціонованих користувачів.
  12. Перевірте всі криптографічні коди і, за необхідності, виправте помилки.
  13. Переконайтеся, що бізнес-логіка додатку захищена і не піддається зовнішнім атакам.
  14. Аналізувати взаємодію системних файлів, виявляти та виправляти вразливості.
  15. Перевірте обробники протоколів (наприклад, чи не намагаються вони переналаштувати цільову сторінку, використовуючи шкідливі плаваючі фрейми за замовчуванням).
  16. Захистіть додаток від зловмисних атак на клієнтів.
  17. Захистіть систему від шкідливих реалізацій під час роботи програми.
  18. Запобігайте можливим шкідливим наслідкам кешування файлів.
  19. Запобігання ненадійному зберіганню даних у кеші клавіатури пристрою.
  20. Запобігайте можливим шкідливим діям файлів cookie.
  21. Забезпечити регулярний моніторинг безпеки даних.
  22. Вивчайте файли користувача та запобігайте їхньому можливому зловмисному впливу.
  23. Захистіть систему від випадків переповнення буфера або пошкодження пам’яті.
  24. Проводьте аналіз різних потоків даних і захищайте систему від їх можливого зловмисного впливу.

Юзабіліті-тестування

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

  1. Переконайтеся, що кнопки мають нормальний розмір і підходять для великих пальців.
  2. Розташовуйте кнопки в одній області екрану, щоб не плутати користувачів.
  3. Переконайтеся, що іконки та зображення виглядають природно в середовищі програми.
  4. Переконайтеся, що колір кнопок, які виконують однакову функцію, однаковий.
  5. Переконайтеся, що система збільшення та зменшення масштабу працює коректно.
  6. Забезпечити мінімальне введення з клавіатури.
  7. Переконайтеся, що ви можете повернути або скасувати дію, якщо натиснули не ту кнопку.
  8. Переконайтеся, що контекстні меню не перевантажені, оскільки вони передбачають швидке використання.
  9. Переконайтеся, що текст простий, зрозумілий і видимий для користувача.
  10. Переконайтеся, що короткі речення та абзаци можна читати.
  11. Знайдіть оптимальний розмір шрифту.
  12. Переконайтеся, що додаток попереджає про можливі збої в його роботі, коли користувач завантажує великі обсяги інформації.
  13. Переконайтеся, що додаток можна завершити з будь-якого стану і що він відновлює свою роботу в тому ж стані.
  14. Переконайтеся, що всі рядки відображаються потрібною мовою, якщо програма має опцію перекладу.
  15. Переконайтеся, що компоненти програми синхронізовані з діями користувача.
  16. Надайте користувачеві посібник, який допоможе зрозуміти програму та ефективно її використовувати.

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

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

Щоб покращити юзабіліті, корисно дотримуватися цих двох принципів:

  1. “Захист від дурня”. Якщо поле передбачає введення номера телефону, необхідно обмежити діапазон введення тільки цифрами і сформувати клавіатуру. Те ж саме стосується електронної пошти та інших елементів, які передбачають введення даних користувачем.
  2. Використовуйте цикл Демінга (планування-дія-перевірка-коригування). Тобто збирати інформацію про дизайн та юзабіліті від існуючих користувачів і планувати зміни в додатку на основі їхніх думок.

Тестування конфігурації

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

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

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

  • Тип пристрою: смартфон, планшет тощо.
  • Конфігурація пристрою: обсяг оперативної пам’яті, тип процесора, роздільна здатність екрану, ємність акумулятора тощо.
  • Тип і версія операційної системи. iOS 6, 7; Android 4.2.2 тощо.
  • Тип мережі: Wi-Fi, GSM.

Рекомендується перед тестуванням конфігурації

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

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

  1. Перевірка відновлення після збою системи та збою транзакції.
  2. Перевірка ефективного відновлення програми після непередбачених сценаріїв збоїв.
  3. Перевірка здатності додатку обробляти транзакції в умовах збою живлення (розряджений акумулятор / некоректне завершення роботи додатку).
  4. Перевірка процесу відновлення даних після розриву з’єднання.

Інші важливі сфери верифікації:

  1. Тестування інсталяції (швидка, адекватна інсталяція програми).
  2. Тестування видалення (швидке, адекватне видалення додатку).
  3. Тестові кейси мережі (перевірка адекватної роботи мережі за різних умов навантаження, а також здатність мережі забезпечувати функціонування всіх додатків, що використовуються під час тестування).
  4. Перевірка наявності непрацюючих ключів.
  5. Перевірка екрану завантаження програми.
  6. Перевірте можливість введення з клавіатури під час збоїв у мережі.
  7. Перевірка методів запуску програми.
  8. Перевірка наявності ефекту зарядки, якщо додаток знаходиться у фоновому режимі.
  9. Перевірте роботу економного та високопродуктивного режимів.
  10. Визначення наслідків виймання батареї під час роботи програми.
  11. Перевірка рівня енергоспоживання програми.
  12. Перевірка побічних ефектів програми.

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

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

Ці випадки повинні бути передбачені при розробці та тестуванні програми.

 

0 коментарів

Вам також може сподобатися

Тестування програмного забезпечення в США у 2026 році - 10 речей, які дійсно мають значення

Тестування програмного забезпечення в США у 2026 році - 10 речей, які дійсно мають значення

Чому місцезнаходження все ще має значення - і що насправді дає розподілена команда QA Давайте будемо відвертими....

Гід по ціноутворенню на тестування програмного забезпечення: Скільки платитимуть американські компанії у 2026 році

Гід по ціноутворенню на тестування програмного забезпечення: Скільки платитимуть американські компанії у 2026 році

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