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

Автор: Томас Гамільтон Томас Гамільтон
Hours оновлений

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

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

  • ️ Функціонально спочатку: Перевірте обов'язкові поля, довжину меж, високосні роки, ділення на нуль та поведінку тайм-ауту перед початком будь-якого косметичного перегляду.
  • 🧭 Сигнали зручності використання: Перевіряйте вирівнювання, підказки, доступ з клавіатури, смуги прокручування та відновлення повідомлень про помилки, щоб користувач-початківець ніколи не стикався з труднощами.
  • 🌐 Матриця сумісності: Повторіть критичні процеси в Chrome, Firefox, Edge, Safari та мобільні браузери, щоб виявити відмінності в макеті та скриптах.
  • 🗄️ Цілісність бази даних: Зіставляти значення інтерфейсу зі збереженими записами, перевіряти ключі, тригери, збережені процедури та довжини полів на обох рівнях.
  • 🔌 Рівень API: Заявляйте коди стану, схеми, автентифікацію, обмеження швидкості та обробку збоїв нижче за течією окремо від браузера.
  • 🔐 Базовий рівень безпеки: Примусово використовувати HTTPS, шифрувати збережені секретні дані, блокувати облікові записи після багаторазових збоїв та перевіряти на SQL-ін'єкції та метод повного перебору.
  • ???? Продуктивність та доступ: Завантажуйте профілі скриптами з автоматизацією замість ручного виконання, а потім перевіряйте контрастність WCAG, мітки та операції з клавіатури.
Детальніше

Під час тестування веб-додатків слід враховувати наведений нижче шаблон. Наведений нижче контрольний список майже застосовний для всіх типів веб-додатків залежно від бізнес-вимог.

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

Тепер розглянемо кожен контрольний список детально:

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

Що таке функціональне тестування?

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

Яка мета або мета функціонального тестування?

  • Мета Функціональне тестування перевірити, чи відповідає ваш продукт запланованим функціональним специфікаціям, зазначеним у вашій документації щодо розробки.

Приклади сценаріїв функціональних тестів:

  • Перевірте, щоб усі обов’язкові поля були перевірені.
  • Перевірте, щоб знак зірочки відображався для всіх обов’язкових полів.
  • Перевірте, чи система не повинна відображати повідомлення про помилку для необов’язкових полів.
  • Перевірте, чи високосні роки правильно підтверджені та не викликають помилок/прорахунків.
  • Перевірте, чи числові поля не повинні приймати алфавіти, і має відображатися відповідне повідомлення про помилку.
  • Перевірте наявність від’ємних чисел, якщо це дозволено для числових полів.
  • Тестове ділення на нуль слід правильно обробляти для обчислень.
  • Перевірте максимальну довжину кожного поля, щоб переконатися, що дані не скорочуються.
  • Перевірте спливаюче повідомлення («Це поле обмежено 500 символами»), яке має з’явитися, якщо дані досягають максимального розміру поля.
  • Перевірте, чи має відображатися повідомлення про підтвердження операцій оновлення та видалення.
  • Перевірте значення суми, які мають відображатися у валютному форматі.
  • Перевірте всі поля введення на наявність спеціальних символів.
  • Перевірте функцію тайм-ауту.
  • Перевірте функцію сортування.
  • Перевірте працездатність наявних кнопок
  • Тест Політика конфіденційності та поширені запитання чітко визначені та мають бути доступними для користувачів.
  • Перевірте, якщо будь-яка функція виходить з ладу, користувач перенаправляється на спеціальну сторінку помилки.
  • Перевірте, чи всі завантажені документи відкрито належним чином.
  • Перевірте, чи користувач повинен мати можливість завантажити завантажені файли.
  • Перевірте функціональність електронної пошти системи.
  • Перевірте Java скрипт правильно працює в різних браузерах (IE, Firefox, Chrome, safari та Opera).
  • Перевірте, що станеться, якщо користувач видалить файли cookie під час перебування на сайті.
  • Перевірте, що станеться, якщо користувач видалить файли cookie після відвідування сайту.
  • Перевірте всі дані в полі зі списком/списком розташовано в хронологічному порядку.

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

Тестування на зручність

Що таке юзабіліті тестування?

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

Яка мета або мета тестування зручності використання?

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

Приклади тестів зручності використання

  • Вміст веб-сторінки має бути правильним без будь-яких орфографічних чи граматичних помилок
  • Усі шрифти мають бути однаковими відповідно до вимог.
  • Весь текст має бути правильно вирівняний.
  • Усі повідомлення про помилки мають бути правильними без будь-яких орфографічних чи граматичних помилок, а повідомлення про помилки має збігатися з міткою поля.
  • Текст підказки має бути для кожного поля.
  • Всі поля повинні бути правильно вирівняні.
  • Між мітками полів, стовпцями, рядками та повідомленнями про помилки має бути достатньо місця.
  • Усі гудзики мають бути стандартного формату та розміру.
  • Посилання на домашню сторінку має бути на кожній сторінці.
  • Неактивні поля мають бути виділені сірим кольором.
  • Перевірте наявність пошкоджених посилань і зображень.
  • Повідомлення про підтвердження має відображатися для будь-якої операції оновлення та видалення.
  • Перевірте сайт на різних роздільних здатностях (640 x 480, 600 × 800 тощо?)
  • Переконайтеся, що кінцевий користувач може запустити систему без розчарування.
  • Перевірте, чи вкладка працює належним чином.
  • Смуга прокрутки має з’являтися лише за потреби.
  • Якщо під час надсилання з’являється повідомлення про помилку, там має бути інформація, яку заповнив користувач.
  • Заголовок має відображатися на кожній веб-сторінці
  • Усі поля (текстове поле, спадне меню, перемикач тощо) і кнопки мають бути доступні за допомогою комбінацій клавіш, і користувач повинен мати змогу виконувати всі операції за допомогою клавіатури.
  • Перевірте, чи дані спадного меню не скорочуються через розмір поля. Також перевірте, чи дані жорстко закодовані чи керуються через адміністратора.

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

СТАТТІ ПО ТЕМІ

Тестування сумісності

Що таке перевірка сумісності?

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

Яка мета або мета тестування на сумісність?

  • Метою тестування на сумісність є оцінка того, наскільки добре програмне забезпечення працює в певному браузері, Operaсистеми, обладнання або програмне забезпечення.

Приклади сценаріїв перевірки сумісності:

  • Перевірте сайт у різних браузерах (тобто Firefox, Chrome, Safari та Opera) і переконайтеся, що веб-сайт відображається належним чином.
  • Перевірте, чи версія HTML, що використовується, сумісна з відповідними версіями браузера.
  • Перевірте, чи правильно відображаються зображення в різних браузерах.
  • Перевірте, чи можна використовувати шрифти в різних браузерах.
  • Перевірте, чи код java script можна використовувати в різних браузерах.
  • Перевірте анімовані GIF-файли в різних браузерах.

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

Тестування бази даних

Що таке тестування бази даних?

  • In Тестування бази даних перевіряються внутрішні записи, які були вставлені через веб-програми або програми для настільних ПК. Дані, які відображаються у веб-додатку, мають збігатися з даними, що зберігаються в базі даних.

Щоб виконати тестування бази даних, тестувальник повинен знати про наведені нижче моменти:

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

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

Приклади тестів для тестування бази даних:

  • Перевірте ім'я бази даних: ім'я бази даних має відповідати специфікаціям.
  • Перевірте таблиці, стовпці, типи стовпців і значення за замовчуванням: усе має відповідати специфікаціям.
  • Перевірте, чи допускає стовпець значення null чи ні.
  • Перевірте первинний і зовнішній ключ кожної таблиці.
  • Перевірте збережену процедуру:
  • Перевірте, чи інстальовано збережену процедуру.
  • Перевірте назву збереженої процедури
  • Перевірте назви параметрів, типи та кількість параметрів.
  • Перевірте параметри, якщо вони потрібні чи ні.
  • Перевірте збережену процедуру, видаливши деякі параметри
  • Перевірте, коли результат дорівнює нулю, це має вплинути на нульові записи.
  • Перевірте збережену процедуру, написавши простий SQL запити.
  • Перевірте, чи повертає збережена процедура значення
  • Перевірте збережену процедуру за зразком вхідних даних.
  • Перевірте поведінку кожного прапора в таблиці.
  • Переконайтеся, що дані правильно збережені в базі даних після кожного надсилання сторінки.
  • Перевірте дані, якщо виконуються операції DML (оновлення, видалення та вставлення).
  • Перевірте довжину кожного поля: довжина поля на задньому та передньому кінцях має бути однаковою.
  • Перевірте назви бази даних QA, UAT і production. Імена повинні бути унікальними.
  • Перевірте зашифровані дані в базі даних.
  • Перевірте розмір бази даних. Також перевірте час відповіді на кожен виконаний запит.
  • Перевірте дані, які відображаються на передній частині, і переконайтеся, що вони однакові на задній частині.
  • Перевірте дійсність даних, вставивши недійсні дані в базу даних.
  • Перевірте тригери.

Контрольний список тестування API

Більшість бізнес-правил зараз знаходяться за кінцевими точками REST або GraphQL, тому самі лише перевірки браузера не можуть довести працездатність системи. Тестування кінцевих точок безпосередньо виявляє конфіденційність.tracдефекти t та авторизації набагато раніше, ніж це може зробити користувацький інтерфейс.

Розгляньте такі сценарії, перш ніж кінцеву точку буде підписано:

Зразки сценаріїв тестування для API:

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

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

Деякі з цих перевірок перетинаються з роботою безпеки.

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

Тестування безпеки передбачає перевірку на виявлення будь-яких недоліків і прогалин з точки зору безпеки.

Приклади тестових сценаріїв для перевірки безпеки:

  • Переконайтеся, що веб-сторінка, яка містить важливі дані, як-от пароль, номери кредитних карток, секретні відповіді на таємне запитання тощо, має бути надіслана через HTTPS (SSL).
  • Перевірте, щоб важлива інформація, як-от пароль, номери кредитних карток тощо, відображалася в зашифрованому форматі.
  • Перевірте, що правила пароля реалізовано на всіх сторінках автентифікації, таких як Реєстрація, Забули пароль, Зміна пароля.
  • Переконайтеся, що якщо пароль змінено, користувач не зможе увійти зі старим паролем.
  • Переконайтеся, що повідомлення про помилки не повинні відображати жодної важливої ​​інформації.
  • Переконайтеся, що користувач вийшов із системи або закінчився сеанс користувача, користувач не повинен мати можливість переходити по сайту.
  • Підтвердьте доступ до захищених і незахищених веб-сторінок безпосередньо без входу.
  • Переконайтеся, що параметр «Переглянути вихідний код» вимкнено та не має бути видимим для користувача.
  • Переконайтеся, що обліковий запис користувача блокується, якщо користувач кілька разів вводить неправильний пароль.
  • Переконайтеся, що файли cookie не повинні зберігати паролі.
  • Переконайтеся, що будь-яка функція не працює, система не повинна відображати жодну інформацію про програму, сервер або базу даних. Натомість має відображатися спеціальна сторінка помилки.
  • Перевірте атаки SQL-ін’єкції.
  • Перевірте ролі користувачів і їхні права. Наприклад, автор запиту не повинен мати доступ до сторінки адміністратора.
  • Перевірте, чи важливі операції записані у файли журналів, і чи слід цю інформацію tracможливо.
  • Переконайтеся, що значення сеансу в адресному рядку знаходяться в зашифрованому форматі.
  • Переконайтеся, що інформація cookie зберігається в зашифрованому форматі.
  • Перевірте додаток на наявність атак грубою силою

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

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

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

Загальні тестові сценарії:

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

Як провести тестування продуктивності? Тестування вручну або автоматизовано

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

  • Буде потрібно більше ресурсів.
  • Одночасні дії неможливі.
  • Належний моніторинг системи недоступний.
  • Нелегко виконати повторюване завдання.

Отже, щоб подолати вищевказані проблеми, ми повинні використовувати інструмент тестування продуктивності. Нижче наведено список деяких популярних інструментів тестування.

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

Контрольний список тестування доступності

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

Зразки тестових сценаріїв для тестування доступності:

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

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

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

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

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

Більшість команд прив'язують охоплення безпеки до Посібник з тестування веб-безпеки OWASP, доступність WCAG 2.2 та загальну термінологію процесу відповідно до ISTQB. Ці посилання дозволяють контролювати контрольний список, а не базуватися виключно на командних звичках.

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

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

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