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

180 web application testing example test cases

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

Це дуже повний перелік Прикладів тестування / сценаріїв тестування веб-додатків. Наша мета - поділитися одним із найповніших контрольних списків тестування, коли-небудь написаних, і це ще не зроблено.

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

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

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

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

Рекомендований інструмент:

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

=> Завантажте інструмент управління тестовими кейсами TestRail

Важливість використання контрольного списку для тестування

# 1) Ведення стандартного сховища тестів багаторазового використання для вашої програми забезпечить швидше виявлення більшості поширених помилок.
# два) Контрольний список допомагає швидко заповнити написання тестових кейсів для нових версій програми.
# 3) Повторне використання тестових кейсів допомагає заощадити гроші на ресурсах для написання повторюваних тестів.
# 4) Важливі тестові випадки будуть висвітлюватися завжди, тим самим майже неможливо забути.
# 5) Контрольний список тестування може бути направлений розробниками, щоб переконатися, що найпоширеніші проблеми усунені на самому етапі розробки.

Примітки:

• Виконуйте ці сценарії з різними ролями користувачів, наприклад адміністратор, гість і т.д.
• Для веб-додатків ці сценарії слід протестувати на декількох браузерах як IE, FF, Chrome та Safari з версіями, затвердженими клієнтом.
• Тестуйте з різною роздільною здатністю екрану, наприклад 1024 x 768, 1280 x 1024 тощо.
• Програму слід протестувати на різних дисплеях, таких як РК-дисплей, ЕЛТ, ноутбуки, планшети та мобільні телефони.
• Тестуйте додаток на різних платформах, таких як операційні системи Windows, Mac, Linux тощо.

Що ви дізнаєтесь:

• 180+ Приклади тестування веб-додатків
  • Загальні сценарії випробувань
  • Сценарії тестування графічного інтерфейсу та зручності використання
    • Тестові сценарії для критеріїв фільтру
    • Тестові сценарії для сітки результатів
    • Тестові сценарії для вікна
  • Сценарії тестування бази даних для тестування
    • Тестові сценарії функціональності завантаження зображень
    • Тестові сценарії надсилання електронних листів
    • Тестові сценарії функціональності експорту Excel
  • Сценарії тестування продуктивності
  • Сценарії тестування на тестування безпеки
• 100+ готових до виконання тестових випадків (контрольні списки)
  • Повний контрольний список (тестові випадки) для найбільш поширених компонентів AUT
    • Контрольний список №1: Контрольний список для мобільного тестування
    • Контрольний список №2: Контрольний список для тестування форм / екранів
    • Контрольний список №3: Контрольний список польового тестування текстового поля
    • Контрольний список №4: Контрольний список для тестування списку або випадаючого списку
    • Контрольний список №5: Контрольний список польових випробувань
    • Контрольний список №6: Контрольний список тестування радіокнопки
    • Контрольний список №7: Сценарії тестування полів дати
    • Контрольний список №8: Сценарії тестування кнопки збереження
    • Контрольний список №9: Сценарії тестування кнопок скасування
    • Контрольний список №10: Видалити точки тестування кнопок
    • Контрольний список №11: Щоб перевірити зони, що зазнали впливу, після збереження або оновлення
    • Контрольний список №12: Список тестування сітки даних
  • Рекомендована література

180+ Приклади тестування веб-додатків

Припущення: Припустимо, що ваша програма підтримує такі функціональні можливості

• Форми з різними полями
• Дитячі вікна
• Додаток взаємодіє з базою даних
• Різні критерії фільтра пошуку та результати відображення
• Завантаження зображень
• Надіслати функціональність електронної пошти
• Функціонал експорту даних

Загальні сценарії випробувань

1. Усі обов’язкові поля повинні бути перевірені та позначені зірочкою (*).
2. Повідомлення про помилки перевірки повинні відображатися належним чином у правильному положенні.
3. Усі повідомлення про помилки повинні відображатися в одному стилі CSS ( Наприклад, з використанням червоного кольору)
4. Повідомлення загального підтвердження повинні відображатися із використанням стилю CSS, відмінного від стилю повідомлень про помилки ( Наприклад, з використанням зеленого кольору)
5. Текст підказок повинен бути змістовним.
6. У випадаючих полях перший запис повинен бути порожнім або текстом, наприклад, «Вибрати».
7. «Видалити функціональність» для будь-якого запису на сторінці має вимагати підтвердження.
8. Виберіть / скасувати вибір усіх записів, якщо сторінка підтримує функцію додавання / видалення / оновлення записів
9. Значення суми повинні відображатися з правильними символами валют.
10. Слід забезпечити сортування сторінок за замовчуванням.
11. Функціональність кнопки скидання має встановлювати значення за замовчуванням для всіх полів.
12. Усі числові значення слід форматувати належним чином.
13. Поля введення слід перевірити на максимальне значення поля. Вхідні значення, що перевищують вказане максимальне обмеження, не слід приймати або зберігати в базі даних.
14. Перевірте всі поля введення на наявність спеціальних символів.
15. Польові мітки повинні бути стандартними, наприклад поле, що приймає ім’я користувача, має бути належним чином позначене як „Ім'я”.
16. Перевірте функціональність сортування сторінок після операцій додавання / редагування / видалення будь-якого запису.
17. Перевірте функціональність тайм-ауту. Значення часу очікування повинні бути настроюваними. Перевірте поведінку програми після закінчення часу очікування.
18. Перевірте файли cookie, що використовуються в додатку.
19. Перевірте, чи завантажувані файли вказують на правильний шлях до файлів.
20. Усі ключі ресурсів слід конфігурувати у файлах конфігурації або базі даних замість жорсткого кодування.
21. Всюди слід дотримуватися стандартних домовленостей щодо іменування ключів ресурсів.
22. Перевірити розмітку для всіх веб-сторінок (перевірити HTML та CSS на наявність синтаксичних помилок), щоб переконатися, що вона відповідає стандартам.
23. Збій програми або недоступні сторінки слід перенаправити на сторінку помилки.
24. Перевірте текст на всіх сторінках на наявність орфографічних та граматичних помилок.
25. Перевірте числові поля введення зі значеннями введення символів. Повинна з’явитися відповідне повідомлення про перевірку.
26. Перевірте наявність від’ємних чисел, якщо це дозволено для числових полів.
27. Перевірте кількість полів із десятковими числами.
28. Перевірте функціональність кнопок, доступних на всіх сторінках.
29. Користувач не повинен мати можливість двічі подати сторінку, швидко натискаючи кнопку подати.
30. Для будь-яких обчислень слід обробляти помилки ділення на нуль.
31. Вхідні дані з першим та останнім пробілами повинні оброблятися правильно.

формат тестування при тестуванні програмного забезпечення

Сценарії тестування графічного інтерфейсу та зручності використання

1. Усі поля на сторінці ( Наприклад, текстове поле, параметри радіо, випадаючі списки) повинні бути правильно вирівняні.
2. Числові значення повинні бути обґрунтовані правильно, якщо не вказано інше.
3. Потрібно передбачити достатньо місця між мітками полів, стовпцями, рядками, повідомленнями про помилки тощо.
4. Смужку прокрутки слід увімкнути лише тоді, коли це необхідно.
5. Розмір, стиль та колір шрифту для заголовка, тексту опису, міток, даних поля та інформації сітки повинні бути стандартними, як зазначено в SRS.
6. Текстове поле опису має бути багаторядковим.
7. Відключені поля повинні бути сірими, а користувачі не повинні мати змоги зосередитись на цих полях.
8. Після натискання текстового поля введення курсор миші повинен змінитись на курсор.
9. Користувач не повинен мати можливості вводити розкривні списки вибору.
10. Інформація, заповнена користувачами, повинна залишатися незмінною, коли на сторінці надсилання з’являється повідомлення про помилку. Користувач повинен мати можливість подати форму ще раз, виправивши помилки.
11. Перевірте, чи в повідомленнях про помилки використовуються правильні мітки полів.
12. Випадаючі значення полів повинні відображатися у визначеному порядку сортування.
13. Tab і Shift + Tab порядок повинен працювати належним чином.
14. Параметри радіо за замовчуванням повинні бути попередньо вибрані під час завантаження сторінки.
15. Повинні бути доступні довідкові повідомлення на рівні поля та на рівні сторінки.
16. Перевірте, чи правильні поля виділено на випадок помилок.
17. Перевірте, чи є параметри випадаючого списку доступними для читання та чи не усічені через обмеження розміру поля.
18. Усі кнопки на сторінці повинні бути доступні за допомогою комбінацій клавіш, а користувач повинен мати можливість виконувати всі операції за допомогою клавіатури.
19. Перевірте всі сторінки на наявність пошкоджених зображень.
20. Перевірте всі сторінки на відсутність посилань.
21. Усі сторінки повинні мати заголовок.
22. Повідомлення-підтвердження повинні відображатися перед виконанням будь-якої операції оновлення або видалення.
23. Пісочний годинник повинен відображатися, коли програма зайнята.
24. Текст сторінки слід вирівнювати зліва.
25. Користувач повинен мати можливість вибрати лише одну опцію радіо та будь-яку комбінацію для прапорців.

Тестові сценарії для критеріїв фільтру

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

Тестові сценарії для сітки результатів

1. Символ завантаження сторінки повинен відображатися, коли завантаження сторінки результатів займає більше часу за замовчуванням.
2. Перевірте, чи всі параметри пошуку використовуються для отримання даних, показаних у сітці результатів.
3. Загальна кількість результатів повинна відображатися в сітці результатів.
4. Критерії пошуку, що використовуються для пошуку, повинні відображатися в сітці результатів.
5. Значення сітки результатів слід сортувати за стовпцем за замовчуванням.
6. Відсортовані стовпці повинні відображатися з піктограмою сортування.
7. Сітки результатів повинні включати всі зазначені стовпці з правильними значеннями.
8. Функція сортування за зростанням і спаданням повинна працювати для стовпців, що підтримуються сортуванням даних.
9. Сітки результатів повинні відображатися з належним інтервалом між стовпцями та рядками.
10. Розбиття сторінок на сторінки повинно бути ввімкненим, коли результатів є більше, ніж кількість результатів за замовчуванням на сторінку.
11. Перевірте функціональність сторінки з наступною, попередньою, першою та останньою сторінками.
12. Повторювані записи не повинні відображатися в сітці результатів.
13. Перевірте, чи всі стовпці видно, і горизонтальну смугу прокрутки увімкнено, якщо це необхідно.
14. Перевірте дані для динамічних стовпців (стовпців, значення яких обчислюються динамічно на основі інших значень стовпців).
15. Для сіток результатів, що відображають звіти, поставте прапорець біля рядка «Підсумки» та перевірте загальну суму для кожного стовпця.
16. Для сіток результатів, що відображають звіти, перевірте дані рядка „Суми”, коли включена пагінація, і користувач переходить до наступної сторінки.
17. Перевірте, чи використовуються правильні символи для відображення значень стовпців, наприклад Символ% повинен відображатися для розрахунку відсотків.
18. Перевірте дані сітки результатів, щоб знати, чи ввімкнено діапазон дат.

Тестові сценарії для вікна

1. Перевірте, чи правильний розмір вікна за замовчуванням.
2. Перевірте, чи правильний розмір дочірнього вікна.
3. Перевірте, чи є на сторінці поле з фокусом за замовчуванням (загалом фокус слід встановлювати на першому полі введення на екрані).
4. Перевірте, чи закриваються дочірні вікна при закритті батьківського / відкривального вікна.
5. Якщо дочірнє вікно відкрито, користувач не повинен мати змоги використовувати або оновлювати будь-яке поле у ​​фоновому або батьківському вікні
6. Перевірте вікно згорнути, розгорнути та закрити функціональність.
7. Перевірте, чи не може вікно змінюватися.
8. Перевірте функціональність смуги прокрутки для батьківського та дочірнього вікон.
9. Перевірте функціональність кнопки скасування для дочірнього вікна.

Сценарії тестування бази даних для тестування

1. Перевірте, чи правильні дані зберігаються в базі даних після успішного надсилання сторінки.
2. Перевірте значення для стовпців, які не приймають нульових значень.
3. Перевірити цілісність даних. Дані повинні зберігатися в одній або декількох таблицях залежно від конструкції.
4. Назви індексів слід наводити відповідно до стандартів, наприклад IND__
5. Таблиці повинні мати стовпець первинного ключа.
6. Стовпці таблиці повинні мати доступну інформацію з описом (крім стовпців аудиту, таких як дата створення, створення тощо)
7. Для кожної бази даних слід додавати журнал операцій додавання / оновлення бази даних.
8. Слід створити необхідні індекси таблиць.
9. Перевірте, чи дані зафіксовані в базі даних, лише коли операція успішно завершена.
10. Дані слід відкочувати у разі невдалих транзакцій.
11. Назва бази даних повинна вказуватися відповідно до типу програми, тобто test, UAT, пісочниця, live (хоча це не стандарт, це корисно для обслуговування бази даних)
12. Логічні імена бази даних слід давати відповідно до імені бази даних (знову ж це не є стандартним, але корисним для обслуговування БД).
13. Зберігаються процедури не слід називати префіксом “sp_”
14. Перевірте, чи правильно заповнюються значення для стовпців аудиту таблиці (наприклад, дата створення, створена, оновлена, оновлена, видаляється, видаляється, видаляється тощо).
15. Перевірте, чи не усічені вхідні дані під час збереження. Довжина поля, що відображається користувачеві на сторінці та в схемі бази даних, повинна бути однаковою.
16. Перевірте числові поля з мінімальними, максимальними та плаваючими значеннями.
17. Перевірте числові поля з від’ємними значеннями (як на прийняття, так і на неприйняття).
18. Перевірте, чи правильно збережені в базі даних перемикач та параметри випадаючого списку.
19. Перевірте, чи поля бази даних розроблені з правильним типом даних та довжиною даних.
20. Перевірте, чи всі обмеження таблиці, такі як первинний ключ, зовнішній ключ тощо, реалізовані правильно.
21. Перевірте збережені процедури та тригери на вибірці вхідних даних.
22. Проміжні поля поля введення та кінцеві кінці повинні бути усічені перед передачею даних у базу даних.
23. Для стовпця Первинний ключ не можна допускати нульових значень.

Тестові сценарії функціональності завантаження зображень

(Також застосовується для інших функцій завантаження файлів)
1. Перевірте шлях завантаженого зображення.
2. Перевірте завантаження зображення та змініть функціональність.
3. Перевірте функціональність завантаження зображень за допомогою файлів зображень різних розширень ( Наприклад, JPEG, PNG, BMP тощо)
4. Перевірте функціональність завантаження зображень із зображеннями, які мають пробіл або будь-який інший дозволений спеціальний символ в назві файлу.
5. Перевірте завантаження зображення дублікатів імен.
6. Перевірте завантаження зображення із розміром зображення, що перевищує максимально дозволений розмір. Повинно відображатись повідомлення про належну помилку.
7. Перевірте функціональність завантаження зображень з іншими типами файлів, крім зображень ( Наприклад, txt, doc, pdf, exe тощо). Повинно відображатися належне повідомлення про помилку.
8. Перевірте, чи приймаються зображення із зазначеною висотою та шириною (якщо вони визначені) в іншому випадку.
9. Для зображень великого розміру повинна з’являтися панель перебігу завантаження зображень.
10. Перевірте, чи працює функція кнопки скасування між процесом завантаження.
11. Перевірте, чи у діалоговому вікні вибору файлів відображаються лише перелічені підтримувані файли.
12. Перевірте функціональність завантаження декількох зображень.
13. Перевірте якість зображення після завантаження. Якість зображення не слід змінювати після завантаження.
14. Перевірте, чи може користувач використовувати / переглядати завантажені зображення.

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

(Тестові приклади для складання або перевірки електронних листів сюди не включені)
(Перед виконанням тестів, пов’язаних з електронною поштою, обов’язково використовуйте фіктивні адреси електронної пошти)
1. Шаблон електронної пошти повинен використовувати стандартний CSS для всіх електронних листів.
2. Адреси електронної пошти слід перевірити перед надсиланням електронних листів.
3. Спеціальні символи у шаблоні основного повідомлення електронної пошти повинні оброблятися належним чином.
4. Мовні символи ( Наприклад, У шаблоні основного повідомлення електронної пошти слід правильно обробляти символи російської, китайської чи німецької мов).
5. Тема електронного листа не повинна бути порожньою.
6. Поля заповнювача, що використовуються у шаблоні електронної пошти, слід замінити фактичними значеннями, наприклад {Ім'я} {Прізвище} слід замінити на ім’я та прізвище особи належним чином для всіх одержувачів.
7. Якщо звіти з динамічними значеннями включені до основного повідомлення електронної пошти, і дані звіту повинні бути правильно розраховані.
8. Ім'я відправника електронної пошти не повинно бути порожнім.
9. Електронні листи слід перевіряти в різних поштових клієнтах, таких як Outlook, Gmail, Hotmail, Yahoo! пошта та ін.
10. Поставте прапорець, щоб надіслати функціональність електронної пошти за допомогою полів TO, CC та BCC.
11. Перевірте електронний лист із простим текстом.
12. Перевірте електронні листи у форматі HTML.
13. Перевірте верхній і нижній колонтитули електронної пошти на наявність логотипу компанії, політики конфіденційності та інших посилань.
14. Перевірте електронні листи з вкладеннями.
15. Поставте прапорець, щоб надіслати функціональність електронної пошти одиночним, кільком одержувачам або списку розсилки.
16. Перевірте, чи правильна відповідь на електронну адресу.
17. Поставте галочку, щоб надіслати велику кількість електронних листів.

Тестові сценарії функціональності експорту Excel

1. Файл повинен бути експортований у відповідному розширенні.
2. Ім'я файлу експортованого файлу Excel має відповідати стандартам, Наприклад, якщо ім'я файлу використовує позначку часу, вона повинна бути належним чином замінена фактичною позначкою часу під час експорту файлу.
3. Перевірте формат дати, якщо експортований файл Excel містить стовпці дати.
4. Перевірте форматування чисел на наявність числових чи валютних значень. Форматування має бути таким, як показано на сторінці.
5. Експортований файл повинен мати стовпці з власними іменами стовпців.
6. Сортування сторінок за замовчуванням також має бути здійснено в експортованому файлі.
7. Дані файлу Excel повинні бути правильно відформатовані із значеннями тексту верхнього та нижнього колонтитула, дати, номерів сторінок тощо для всіх сторінок.
8. Перевірте, чи дані, що відображаються на сторінці та експортованому файлі Excel, однакові.
9. Перевірте функціональність експорту, коли включена пагінація.
10. Перевірте, чи кнопка експорту відображає відповідну піктограму відповідно до експортованого типу файлу, Наприклад, Значок файлу Excel для файлів XLS
11. Перевірте функціональність експорту для файлів із дуже великим розміром.
12. Перевірте функціональність експорту сторінок, що містять спеціальні символи. Перевірте, чи правильно експортовано ці спеціальні символи у файлі Excel.

Сценарії тестування продуктивності

1. Перевірте, чи час завантаження сторінки знаходиться в межах допустимого діапазону.
2. Перевірте завантаження сторінки на повільних з'єднаннях.
3. Перевірте час відгуку на будь-які дії в умовах легкого, нормального, помірного та великого навантаження.
4. Перевірте ефективність збережених процедур та тригерів бази даних.
5. Перевірте час виконання запиту до бази даних.
6. Перевірте наявність навантажувального тестування програми.
7. Перевірте наявність стрес-тестування програми.
8. Перевірте використання процесора та пам'яті в умовах пікового навантаження.

Сценарії тестування на тестування безпеки

1. Перевірте наявність атак введення SQL.
2. Безпечні сторінки повинні використовувати протокол HTTPS.
3. Збій сторінки не повинен розкривати інформацію про програму чи сервер. Для цього повинна відображатися сторінка помилки.
4. Уникайте введення спеціальних символів.
5. Повідомлення про помилки не повинні розкривати конфіденційну інформацію.
6. Усі облікові дані слід передавати за зашифрованим каналом.
7. Перевірте захист пароля та дотримання політики щодо паролів.
8. Перевірте функціональність виходу із програми.
9. Перевірте наявність атак грубої сили.
10. Інформація про файли cookie повинна зберігатися лише у зашифрованому форматі.
11. Перевірте тривалість файлу cookie сеансу та завершення сеансу після таймауту або виходу з системи.
11. Маркери сеансу повинні передаватися через захищений канал.
13. Пароль не повинен зберігатися в файлах cookie.
14. Тест на атаки відмови в обслуговуванні.
15. Тест на витік пам’яті.
16. Перевірте несанкціонований доступ до програми, маніпулюючи значеннями змінних в адресному рядку браузера.
17. Перевірте передачу розширення файлу, щоб exe-файли не завантажувались і не виконувались на сервері.
18. Для конфіденційних полів, таких як паролі та дані кредитної картки, не повинно бути ввімкнено автозаповнення.
19. Функціонал для завантаження файлів повинен використовувати обмеження типу файлів, а також антивірус для сканування завантажених файлів.
20. Перевірте, чи заборонено перелік каталогів.
21. Паролі та інші чутливі поля слід маскувати під час набору тексту.
22. Переконайтеся, що функціональність забутого пароля захищена такими функціями, як тимчасовий термін дії пароля через зазначені години, та запитання безпеки перед тим, як змінювати або запитувати новий пароль.
23. Перевірте функціональність CAPTCHA.
24. Перевірте, чи не реєструються важливі події у файлах журналів.
25. Перевірте, чи правильно застосовано привілеї доступу.

Тестові кейси на тестування на проникнення - Я перерахував близько 41 тесту для тестування на проникнення цій сторінці .

Я б дуже хотів подякувати Лаваня Деваншу (Старший інженер з контролю якості, який працює в I-link Infosoft) за допомогу мені у підготовці цього всебічного контрольного списку тестування.

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

Оновлено:

100+ готових до виконання тестових випадків (контрольні списки)

Ви можете використовувати цей список для перевірки найпоширеніших компонентів AUT

Як щодня перевіряти найпоширеніші компоненти вашого AUT?

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

Кожен AUT (додаток, що перевіряється) унікальний і має цілком конкретну бізнес-мету. Окремі аспекти (модулі) AUT відповідають різним операціям / діям, які мають вирішальне значення для успіху бізнесу, який підтримує AUT.

Хоча кожен AUT розроблений по-різному, окремі компоненти / поля, які ми зустрічаємо на більшості сторінок / екранів / програм, однакові з більш-менш подібною поведінкою.

Деякі загальні компоненти AUT:

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

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

Продовжимо зі списком найпоширеніших перевірок для Веб або настільний додаток сторінки / форми.

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

де знаходяться apk, що зберігаються на android

Мета цього вичерпного контрольного списку:

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

Врешті-решт, впевненості у продукті можна досягти, лише протестувавши кожен окремий елемент якнайкраще.

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

Примітка:Ви можете використовувати ці контрольні списки у форматі Microsoft Excel (завантаження надається в кінці статті). Ви навіть можете відстежувати виконання тесту в одному файлі з результатами проходження / відмови та статусом.

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

Контрольний список №1: Контрольний список для мобільного тестування

Контрольний список №2: Контрольний список для тестування форм / екранів

Контрольний список №3: Контрольний список польового тестування текстового поля

Текстове вікно:

BVA (розмір) для текстового поля:

Хв -> -> Пропуск
Хв-1 -> -> Помилка
Мінімум + 1 -> -> Передача
Макс-1 -> -> Пропуск
Макс. + 1 -> -> Помилка
Макс -> -> Передача

ECP для текстового поля:

Контрольний список №4: Контрольний список для тестування списку або випадаючого списку

Вікно списку / випадаюче меню:

Контрольний список №5: Контрольний список польових випробувань

CheckBox:

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

Радіо-кнопка:

Контрольний список №7: Сценарії тестування полів дати

Поле дати:

Контрольний список №8: Сценарії тестування кнопки збереження

Зберегти / оновити:

Контрольний список №9: Сценарії тестування кнопок скасування

Скасувати:

Контрольний список №10: Видалити точки тестування кнопок

Видалити:

Контрольний список №11: Щоб перевірити зони, що зазнали впливу, після збереження або оновлення

Після збереження / оновлення:

Контрольний список №12: Список тестування сітки даних

Сітка даних:

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

Хоча цей список може бути не вичерпним, він справді великий.

ЗАВАНТАЖИТИ==> Ви можете завантажити всі ці контрольні списки у форматі MS Excel: Завантажте у форматі Excel

Примітки:

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

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

Крім того, я був би вдячний, якщо б ви поділились цим зі своїми друзями!

НАЗАД Підручник | НАСТУПНИЙ підручник

Рекомендована література

• Як писати тестові справи: Остаточний посібник із прикладами
• Тестування файлів cookie веб-сайту та тестові кейси для тестування файлів cookie веб-додатків
• Зразок шаблону тестового кейсу з прикладами тестового кейсу (Завантажити)
• Найкращі засоби тестування програмного забезпечення 2021 р. (Інструменти автоматизації тестування якості)
• Посібник із тестування безпеки веб-додатків
• Тестування додатків - до основ тестування програмного забезпечення!
• Встановіть свою програму на пристрій і починайте тестування з Eclipse
• TDD проти BDD - проаналізуйте відмінності на прикладах