Що таке тестування додатків?

⚡ Розумний підсумок

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

  • 🎯 Визначення: Тестування застосунку перевіряє весь застосунок на наявність помилок перед випуском.
  • 🪜 Чотири етапи: Плануйте на основі вимог, створюйте кейси та скрипти, запускайте функціональні тести, а потім запускайте навантажувальні тести.
  • 🧩 Три сегменти: Веб-, настільні та мобільні додатки вимагають різного поєднання типів тестів.
  • Методології: Тестування цільової поведінки, коду та структури методами чорної, білої та сірої скриньок відповідно.
  • 🚪 Критерії входу та виходу: Узгоджені умови визначають, коли може розпочатися тестування та коли воно буде завершено.
  • 📈 Метрики: Щільність дефектів, покриття тестом та витік дефектів показують, чи працює тестування.
  • 📱 Мобільний фокус: Фрагментація, шляхи встановлення та обмежена кількість фізичних пристроїв домінують у мобільному тестуванні.

Що таке тестування додатків

Що таке тестування додатків?

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

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

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

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

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

Як протестувати програму?

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

Перевірте додаток

Життєвий цикл тестування програми включає чотири етапи.

  • Етап 1) Розробляйте плани тестування на основі вимог програми
  • Етап 2) Розробляйте ручні тестові сценарії та автоматизовані тестові сценарії
  • Етап 3) Виконайте функціональні тести для перевірки вимог програми
  • Етап 4) Виконайте навантажувальні тести та налаштуйте продуктивність програми

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

  • Тестування веб-додатків
  • Тестування настільних програм
  • Тестування мобільних додатків
Тестування додатків Види проведених тестувань
  • Тестування веб-додатків
  • Тестування настільних програм
  • Тестування інтерфейсу користувача
  • Тестування на зручність
  • Тестування продуктивності
  • Тестування на сумісність (програмне/апаратне забезпечення)
  • Функціональне тестування
  • Тестування безпеки
  • Тестування мобільних додатків
  • Тестування інтерфейсу користувача
  • Тестування на основі правил
  • Регресійне тестування
  • Функціональне тестування
  • Тестування безпеки

Порівняння тестування веб-, десктопних та мобільних додатків

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

Точка різниці Сайт робочий стіл Mobile
Біжить далі Браузер через мережу Одна встановлена ​​машина Мобільний телефон або планшет
Основна змінна Браузер та версія Operaсистема та апаратне забезпечення ting Пристрій, версія ОС та розмір екрана
Залежність від мережі Завжди на зв'язку Часто офлайн Періодичний, і має пережити втрату
Найбільший ризик Кросбраузерний рендеринг та завантаження Встановлення та сумісність Фрагментація на різних пристроях
Обробка переривань Рідко актуально Рідко актуально Дзвінки, сповіщення та низький заряд батареї
Шлях оновлення На стороні сервера, миттєво для всіх Користувач встановлює патч Огляд магазину додатків, поетапне розгортання

Мобільний технологія містить найбільше неконтрольованих змінних, тому вона розглядається окремо далі на цій сторінці.

Методології тестування додатків

Методологія тестування — це структурований спосіб забезпечення повного тестування програмного застосунку. Неорганізована та погана методологія тестування може призвести до нестабільності продукту.

Існує три способи проведення тестування.

  • Black Box Тестування
  • білий Box Тестування
  • сірий Box Тестування

Black Box Тестування

Black Box Тестування Техніка зазвичай використовується для тестування Функціональне тестування, Нефункціональне тестування, та регресійне тестування. У тестуванні чорної скриньки використовуються такі стратегії:

  • Тестування класу еквівалентності
  • Перевірка граничних значень
  • Тестування таблиці рішень
  • Таблиці переходів станів

білий Box Тестування

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

  • Code Аналіз покриття
  • Покриття шляху

сірий Box Тестування

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

План тестування для тестування програми

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

Стандартний план тестування для тестування додатків має визначати наступні функції;

  • Визначте обсяг тестування
  • Визначте мету тестування
  • Підхід до тестової діяльності
  • Графік проведення тестування
  • Помилка tracкороль і звітність

Критерії входу та виходу для тестування додатків

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

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

  • Вимоги та SRS переглядаються та узгоджуються з базовими показниками.
  • План тестування та тестові випадки написані та затверджені.
  • Збірка розгортається у стабільному тестовому середовищі та проходить тестування на наявність диму.
  • Тестові дані та необхідні облікові записи або пристрої доступні.
  • Дефект tracІнструмент king налаштовано, і команда має доступ.

Критерії виходу показати, що етап виконав своє призначення.

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

Інструменти тестування програми

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

Ось декілька з них.

💡 Примітка: IBM Rational Robot, який довго був у списку поряд з RFT, був знятий з продажу. Rational Functional Tester є поточним... IBM пропозиція, тому нові проекти не повинні плануватися навколо Robot.

Ключові показники для тестування додатків

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

  • Тестове покриття: Частка вимог з принаймні одним відображеним тестовим випадком. Низьке покриття означає непротестовану поведінку, що б не говорив показник успішності.
  • Щільність дефектів: Дефекти, поділені за розміром, зазвичай на тисячу рядків коду або на модуль. Це вказує на компоненти, які потребують переробки, а не додаткового тестування.
  • Витік дефекту: Кількість виявлених дефектів у виробництві, поділена на загальну кількість виявлених дефектів. Зростання витоків – найчіткіший сигнал того, що в передрелізному тестуванні чогось бракує.
  • Ефективність усунення дефектів: Дефекти, виявлені до випуску, як частка всіх дефектів. Загальною метою є показник вище дев'яноста відсотків.
  • Швидкість виконання тестів: Справи, що розглядаються проти запланованих справ, tracкерується за цикл, тому прослизання видно на ранній стадії, а не на вихідних затворах.

Tracскоріше аналіз тенденції, ніж окремий показник. Один цикл окремо говорить дуже мало.

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

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

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

  • Визначте функціональні характеристики
  • Revоглядів та інспекцій
  • Формальні критерії входу та виходу
  • Варіації функціонального тесту
  • Багатоплатформне тестування
  • Автоматизоване виконання тесту

Проблеми тестування програми

Під час тестування програми тестер може зіткнутися з багатьма труднощами

  • Проблеми виявляються лише під час виклику користувача
  • Нездатність передбачити вплив змін
  • Відсутність видимості програмних і операційних помилок
  • Багато часу

Тестування мобільних додатків

Як тестування веб-додатків, Mobile Тестування додатків також базується на тій самій стратегії та методології тестування. Різниця може полягати в інструментах, що використовуються для тестування, деякі поширені інструменти, що використовуються для тестування мобільних додатків: Appium, TestComplete, Robotium та Espresso.

Типи мобільних додатків поділяються на три категорії

  • Веб-додаток – доступ до нього здійснюється користувачами через мережу, наприклад Інтернет або інтранет
  • Власна програма – розроблена для конкретної платформи та встановлена ​​на комп’ютері
  • Гібридний додаток – він поєднує елементи як веб-сайту, так і нативного додатку, наприклад, Facebook.

Для більшості мобільних платформ ви можете використовувати прості CSS, HTML, JS тощо.

Приклади тестів для тестування мобільних додатків

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

Що стосується мобільних додатків, те, що потрібно перевірити

  • Встановлення
  • OTA
  • Wi-Fi Internet,
  • Кабель для передачі даних
  • Bluetooth
  • Видалення
  • Логотип програми
  • Сплеск
  • Низька пам’ять
  • Візуальні відгуки
  • Вийти з програми
  • Запуск/перезапуск програми

Проблеми мобільного тестування

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

  • Комплексне покриття тестів
  • Управління фрагментацією (різна версія ОС, процесор, пам'ять)
  • Відсутність плану тестування
  • Тиск часу
  • Відсутність фізичних пристроїв
  • Різноманітність платформи та ОС

Поширені запитання

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

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

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

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

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

Підсумуйте цей пост за допомогою: