Як писати тестові справи: Остаточний посібник із прикладами

how write test cases

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

Що таке тест-кейс?

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

Тестовий випадок - це набір інструкцій на тему «ЯК» для перевірки певної тестової цілі / цілі, яка при виконанні покаже нам, чи задовольняється очікувана поведінка системи чи ні.

Список навчальних посібників, висвітлених у цій серії тестових робіт:

Як писати:

Підручник No1: Що таке тестовий кейс і як писати тестові кейси (цей посібник)
Підручник No2: Зразок шаблону тестового кейсу з прикладами (Завантажити) (потрібно прочитати)
Підручник No3: Написання тестових справ із документа SRS
Підручник No4: Як написати тестові кейси для даного сценарію
Підручник No5: Як підготуватися до написання тестових кейсів
Підручник No6: Як писати негативні тестові кейси

Приклади:

Підручник No7: 180+ зразків тестових випадків для веб- та настільних додатків
Підручник No8: 100+ готових до виконання тестових сценаріїв (контрольний список)

Техніка письма:

Підручник No9: Графік причин та наслідків - Техніка написання динамічного тесту
Підручник No10: Державна перехідна методика випробувань
Підручник No11: Техніка випробування ортогональних масивів
Підручник No12: Техніка вгадування помилок
Підручник No 13: Техніка проектування випробувальної таблиці польової перевірки (FVT)

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

Підручник No14: Тестові справи проти сценаріїв тестування
Підручник No15: Різниця між планом випробувань, стратегією випробування та тестом

Автоматизація:

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

Засоби управління тестами:

Підручник No18: Найкращі інструменти управління тестами
Підручник No 19: TestLink для управління тестовими кейсами
Підручник No20: Створення та управління тестовими кейсами за допомогою Центру якості HP
Підручник No21: Виконання тестових справ за допомогою ALM / QC

Випадки для конкретного домену:

Підручник No22: Тестові випадки для застосування ERP
Підручник No23: Тестові приклади JAVA
Підручник No24: Аналіз граничних значень та розподіл еквівалентності

Продовжимо з першим підручником із цієї серії.

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

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

# 1) TestRail

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

# 2) TestMonitor

Інтернет-тест на найвищому рівні. Революційний легко.

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

=> Відвідайте веб-сайт TestMonitor

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

• Що таке тестовий кейс і як писати тестові кейси?
  • Чому ми пишемо тести?
  • Як писати тестові кейси?
  • Основний формат викладу тестового кейсу
• Поради щодо написання тестів
  • • # 1) Будьте прості, але не надто прості; зробити його складним, але не надто складним:
    • # 2) Після документування тестових випадків перегляньте один раз як тестер:
    • # 3) Зв’язок, а також полегшення роботи тестерів:
    • # 4) Будьте співавтором:
    • # 5) Ніколи не забувайте кінцевого користувача:
• Як досягти досконалості в документації до тестових кейсів
  • Корисні поради та підказки
    • # 1) Чи є ваш тестовий документ у хорошій формі?
    • # 2) Не забувайте висвітлювати негативні випадки
    • # 3) Проведіть атомні тестові етапи
    • # 4) Розставити пріоритети на тести
    • # 5) Послідовність має значення
    • # 6) Додайте мітку часу та ім’я тестувальника до коментарів
    • # 7) Включіть деталі браузера
    • # 8) Тримайте два окремих аркуші - „Помилки“ та „Підсумок“ у Документі
• Як НЕ писати тести
  • 3 Найпоширеніші проблеми в тестових випадках
    • # 1) Складені сходинки
    • # 2) Поведінка програми сприймається як очікувана поведінка
    • # 3) Кілька умов в одному випадку
• Як підвищити ефективність тестових кейсів
  • Збірник документів для тестового письма
  • Реальний приклад
  • Документ тесту
  • Тестовий збір даних
• Важливість стандартизації тестових випадків
  • Причини повторного використання тестових справ
  • Що таке стандартний тест у веб-тестуванні?
  • Висновок
  • Рекомендована література

Що таке тестовий кейс і як писати тестові кейси?

Написання ефективних кейсів - це вміння. І ви можете дізнатися про це з досвіду та знань програми, що тестується.

Основні вказівки щодо написання тестів див. У наступному відео:

Наведені вище ресурси повинні дати нам основи процесу написання тестів.

Рівні процесу написання тесту:

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

Чому ми пишемо тести?

Основною метою написання кейсів є для перевірки тестового покриття програми.

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

Як писати тестові кейси?

Поля:

• Ідентифікатор тестового кейсу
• Одиниця для тестування: Що перевірити?
• Припущення
• Дані тесту: Змінні та їх значення
• Кроки, які потрібно виконати
• Очікуваний результат
• Фактичний результат
• Передача / Помилка
• Коментарі

Основний формат викладу тестового кейсу

Перевірити
Використовуючи (назва інструменту, назва тегу, діалогове вікно тощо)
С (умови)
До (що повертається, демонструється, демонструється)

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

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

• Функціональні кейси
• Негативні випадки
• Випадки граничної вартості

Поки писав ці всі ваші TC повинні бути простими та зрозумілими .

**************************************************

Поради щодо написання тестів

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

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

Важливі фактори, що включають процес написання:

а) ТК схильні до регулярного перегляду та оновлення:

Ми живемо у світі, що постійно змінюється, і те ж стосується і програмного забезпечення. Вимоги до програмного забезпечення безпосередньо впливають на справи. Щоразу, коли вимоги змінюються, ТК необхідно оновлювати.

Однак не лише зміна вимоги може спричинити перегляд та оновлення ТЗ. Під час виконання ТК у свідомості виникає багато ідей, і може бути виявлено багато підставок одного ТК. Все це спричиняє оновлення TC, а іноді навіть призводить до додавання нових TC.

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

b) ТК схильні до розподілу серед тестувальників, які виконуватимуть такі:

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

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

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

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

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

г) ТК мають тенденцію взаємозалежності:

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

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

д) ТК схильні до розповсюдження серед розробників (особливо в середовищі розробки, керованому тестом):

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

Поради щодо написання ефективних тестів:

як виглядає ключ безпеки мережі

Маючи на увазі вищезазначені 5 факторів, ось кілька порад щодо написання ефективних ТК.

Давайте розпочнемо!!!

# 1) Будьте прості, але не надто прості; зробити його складним, але не надто складним:

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

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

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

# 2) Після документування тестових випадків перегляньте один раз як тестер:

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

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

Переконайтеся, що дані тесту зазначене в ТК є можливим не лише для реальних тестувальників, але також відповідно до середовища реального часу. Переконайтеся, що між TC не існує конфлікту залежностей, і переконайтеся, що всі посилання на інші TC / артефакти / GUI є точними. В іншому випадку тестери можуть зазнати великих проблем.

# 3) Зв’язок, а також полегшення роботи тестерів:

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

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

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

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

# 4) Будьте співавтором:

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

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

Будучи контролем якості, не просто перевіряйте, а робіть зміни!

# 5) Ніколи не забувайте кінцевого користувача:

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

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

**************************************************

Як досягти досконалості в документації до тестових кейсів

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

Ми завжди залишаємо певний простір для вдосконалення в нашому Документація до тесту . Іноді ми не можемо забезпечити 100% охоплення тестуванням через ТК, а іноді шаблон тесту не відповідає нормі, або нам бракує належної читабельності та чіткості наших тестів.

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

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

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

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

Корисні поради та підказки

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

# 1) Чи є ваш тестовий документ у хорошій формі?

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

Якщо ви використовуєте Excel, тоді зафіксуйте кожен тестовий приклад на окремому аркуші книги, де кожен тестовий приклад описує один повний тестовий процес.

# 2) Не забувайте висвітлювати негативні випадки

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

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

# 3) Проведіть атомні тестові етапи

Кожен крок тесту повинен бути атомним. Подальших підкроків не повинно бути. Чим простішим та чіткішим є крок тестування, тим легше було б продовжити тестування.

# 4) Розставити пріоритети на тести

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

Ви можете використовувати будь-яке кодування для визначення пріоритету тесту. Як правило, краще використовувати будь-який з 3 рівнів, високий, середній і низький , або 1, 50 і 100. Отже, коли у вас строгий графік, вам слід спочатку пройти всі тести з високим пріоритетом, а потім перейти до тестів із середнім та низьким пріоритетом.

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

# 5) Послідовність має значення

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

# 6) Додайте мітку часу та ім’я тестувальника до коментарів

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

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

# 7) Включіть деталі браузера

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

# 8) Тримайте два окремих аркуші - „Помилки“ та „Підсумок“ у Документі

Якщо ви документуєте в Excel, то перші два аркуші книги мають бути Summary і Bugs. Підсумковий аркуш повинен узагальнювати сценарій тестування, а в аркуші помилок - усі проблеми, що виникають під час тестування. Важливість додавання цих двох аркушів полягає в тому, що це дасть чітке розуміння тестування читачеві / користувачеві документа.

Отже, коли час обмежений, ці два аркуші можуть виявитись дуже корисними для надання огляду тестування.

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

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

**************************************************

Як НЕ писати тести

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

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

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

3 Найпоширеніші проблеми в тестових випадках

1. Складені сходинки
2. Поведінка програми сприймається як очікувана поведінка
3. Кілька умов в одному випадку

Ці три повинні бути в моєму списку 3 найпоширеніших проблем у процесі написання тестів.

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

Давайте перейдемо до цього і детально обговоримо кожен із них:

# 1) Складені сходинки

Перш за все, що таке складений крок?

Наприклад, ви даєте вказівки від пункту А до пункту Б: якщо ви скажете, що «перейдіть до місця XYZ, а потім до АВС», це не матиме великого сенсу, оскільки тут ми опиняємось у роздумах - «Як мені дістатися до XYZ в першу чергу »- натомість починаючи з« Поверніть звідси ліворуч і пройдіть 1 милю, а потім поверніть праворуч на Rd. № 11, щоб прибути до XYZ »може досягти кращих результатів.

Точно такі ж правила стосуються і тестів, і його етапів.

Наприклад Я пишу тест для Amazon.com - зробіть замовлення на будь-який товар.

Нижче наведені мої кроки тесту (Примітка: Я пишу лише кроки, а не всі інші частини тесту, як очікуваний результат тощо)

до . Запустіть Amazon.com
b . Шукайте товар, вводячи ключове слово / назву продукту в поле «Пошук» у верхній частині екрана.
c . З відображених результатів пошуку виберіть перший.
d . Натисніть Додати в кошик на сторінці деталей товару.
є . Оформити замовлення та оплатити.
f . Перевірте сторінку підтвердження замовлення.

Зараз, Ви можете визначити, що з цього є складеним кроком? Правий - Крок (e)

Пам’ятайте, тести завжди стосуються “Як” тестувати, тому важливо вписати точні кроки “Як перевірити та сплатити” у своєму тесті.

Отже, вищезазначений випадок є більш ефективним, якщо писати, як показано нижче:

до . Запустіть Amazon.com
b . Шукайте товар, вводячи ключове слово / назву продукту в поле «Пошук» у верхній частині екрана.
c . З відображених результатів пошуку виберіть перший.
d . Натисніть Додати в кошик на сторінці деталей товару.
є . Натисніть Оформити замовлення на сторінці кошика для покупок.
f . Введіть інформацію про CC, доставку та платіжну інформацію.
g . Клацніть Оформити замовлення.
h . Перевірте сторінку підтвердження замовлення.

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

# 2) Поведінка програми сприймається як очікувана поведінка

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

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

Це нешкідливо, доки ви тримаєте відкриту думку і дотримуєтесь сподівання, що - 'AUT може бути недоліком'. Лише тоді, коли ти не думаєш, що це так, все працює погано. Як завжди, ми дозволимо прикладам говорити.

Якщо нижче наведена сторінка, для якої ви пишете / розробляєте етапи тестування:

Випадок 1:

Якщо кроки мого тесту такі, як показано нижче:

1. Запустіть торговий сайт.
2. Клацніть на Доставка та повернення - Очікуваний результат: Сторінка доставки та повернення відображається з написом 'Помістіть свою інформацію сюди' та кнопкою 'Продовжити'.

Тоді це неправильно.

Випадок 2:

1. Запустіть торговий сайт.
2. Натисніть Доставка та поверніть.
3. У текстовому полі «Введіть номер замовлення» на цьому екрані введіть номер замовлення.
4. Натисніть Продовжити - Очікуваний результат: Відображаються деталі замовлення, пов'язані з доставкою та поверненням.

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

Нижня лінія: Додаток як посилання - це швидкий ярлик, але він має свої власні небезпеки. Поки ми обережні та критичні, це дає надзвичайні результати.

# 3) Кілька умов в одному випадку

Ще раз давайте вчитися у Приклад .

Погляньте на наступні кроки тесту: Нижче наведено етапи тестування в межах одного тесту для функції входу.

a. Введіть дійсну інформацію та натисніть Надіслати.
b. Залиште поле Ім'я користувача порожнім. Клацніть Надіслати.
c. Залиште поле пароля порожнім і натисніть кнопку Надіслати.
d. Виберіть вже зареєстроване ім’я користувача / пароль і натисніть кнопку Надіслати.

Те, що мали бути 4 різні випадки, об’єднується в одне. Ви можете подумати - Що в цьому поганого? Це економить багато документації, і те, що я можу зробити за 4, я роблю це за 1 - це не чудово? Ну, не зовсім. Причини?

Читати далі:

• Що робити, якщо одна з умов не виконується - ми повинні позначити весь тест як «невдалий». Якщо ми позначимо весь випадок як 'невдалий', це означає, що всі 4 умови не працюють, що насправді не відповідає дійсності.
• Тести повинні мати потік. Від передумови до кроку 1 та всіх кроків. Якщо я слідую цій справі, на кроці (а), якщо він буде успішним, я увійду на сторінку, де опція «вхід» більше недоступна. Тож коли я переходжу до кроку (b) - де тестувальник збирається ввести ім’я користувача? Розумієте, потік порушений.

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

**************************************************

Як підвищити ефективність тестових кейсів

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

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

Збірник документів для тестового письма

# 1) Документ про вимоги користувача

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

# 2) Документ справи для ділового використання

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

# 3) Документ про функціональні вимоги

Цей документ детально описує функціональні вимоги кожної функції до системи відповідно до вимог.

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

# 4) План проекту програмного забезпечення (Необов’язково)

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

# 5) ПЗ / План випробувань

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

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

Реальний приклад

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

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

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

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

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

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

• Тести інтерфейсу користувача :Елементи керування / поля, які видимі користувачеві. Для функції, що підлягає тестуванню, доступні статичне керування та динамічне управління. Наприклад, на екрані входу вище тексти «Ім'я користувача та пароль» - це статичні поля, які не потребують взаємодії з користувачем, лише для відображення тексту.

• Функціональні випадки :З іншого боку, кнопка «Вхід» та гіперпосилання (Забули пароль? & Реєстрація) - це динамічні поля, що вимагають взаємодії користувача, натискаючи на елементи керування, які згодом виконуватимуть певні дії.

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

• Тести процесу :Це пов’язано з процесом (а не діями, пов’язаними з видимими елементами керування, доступними на екрані), пов’язаними з функцією та функціональністю. Наприклад, натискання посилання «Забули пароль» на наведеному вище зразку екрана може надіслати електронне повідомлення користувачеві. Тож, можливо, електронну пошту потрібно протестувати для належного процесу та підтвердження.

4) Нарешті, дотримуйтесь Мантра BAOE ', засоби i) Основний потік ii) Альтернативний потік iii) Варіанти та iv) Винятки для повного охоплення функціонального потоку та особливості, що перевіряються. Кожна концепція повинна застосовуватися до позитивних та негативних тестів.

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

• Основний потік: Введіть URL-адресу Логіну в будь-якому браузері та введіть необхідну інформацію та увійдіть до програми.
• Альтернативний потік: Встановіть програму на мобільний пристрій, введіть необхідну інформацію та увійдіть до програми.
• Варіанти: Які варіанти доступні для того самого екрана входу? Наприклад, після входу в програму натисканням кнопки «Вийти» може з’явитися той самий екран, або якщо час очікування або сеансу закінчився, користувач може перейти на екран входу.
• Винятки: Які винятки, якщо мої тести негативні? Наприклад, якщо на екрані входу введені неправильні облікові дані, чи отримає користувач повідомлення про помилку, чи не буде пов’язано жодної дії.

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

Також читайте=> 180+ зразків готових до використання тестів для веб- і настільних додатків.

Документ тесту

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

Також читайте=> Зразок шаблону тестового кейсу з прикладами.

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

Примітка : Додайте стовпець 'Фактична поведінка' в кінці цього шаблону.

Тестовий збір даних

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

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

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

**************************************************

Важливість стандартизації тестових випадків

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

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

Питання, яке мене завжди бентежить, полягає в наступному: «Якщо більшість програм схожі, наприклад: наприклад, сайти роздрібної торгівлі, які вже тисячу разів тестувались,« Чому нам потрібно писати тестові кейси для ще одного роздрібного сайту з нуля? ' Чи не заощадить це купу часу, витягнувши існуючі тестові сценарії, які використовувались для тестування попереднього роздрібного сайту?

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

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

Причини повторного використання тестових справ

# 1) Більшість функціональних областей веб-сайту - це майже вхід, реєстрація, додавання в кошик, список бажань, оплата, варіанти доставки, варіанти оплати, вміст сторінки товару, нещодавно переглянуті, відповідні товари, засоби промокоду тощо.

# два) Більшість проектів - це лише вдосконалення або зміни існуючих функціональних можливостей.

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

# 4) Роздрібні веб-сайти мають КСВ Система (обслуговування клієнтів) теж.

# 5) Беккенд-система та складська програма, що використовує JDA, також використовуються усіма веб-сайтами.

# 6) Поняття файлів cookie, часу очікування та безпеки теж є загальним.

# 7) Веб-проекти часто схильні до змін вимог.

# 8) види тестування потрібні є загальними, як браузер тестування сумісності , тестування продуктивності , тестування безпеки

Розумієте, є багато загального та подібного.

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

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

Що таке стандартний тест у веб-тестуванні?

• Створіть повні тестові кейси - кроки, дані, змінна тощо. Це забезпечить можливість просто замінити не схожі дані / змінні, коли потрібен подібний тестовий кейс.
• Критерії входу та виїзду повинні бути правильно визначені.
• Для швидкого пошуку та заміни кроки, що модифікуються, або висловлювання на них слід виділити іншим кольором.
• Мова, яка використовується для створення стандартного тестового випадку, повинна бути загальною.
• Усі особливості кожного веб-сайту повинні бути розглянуті в тестових випадках.
• Назва тестових кейсів має бути назвою функціональності або функції, яку охоплює тестовий кейс. Це значно полегшить пошук тесту з набору.
• Якщо є якийсь базовий або стандартний зразок або файл графічного інтерфейсу користувача чи знімок екрана функції, тоді його слід вкласти з відповідними кроками.

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

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

випадкове число від 0 до 1 c ++

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

Висновок

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

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

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

Наступний підручник

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

• Функціональне тестування проти нефункціонального тестування
• Посібник із тестування на портативність із практичними прикладами
• Типи тестування програмного забезпечення: різні типи тестування з деталями
• Найкращі засоби тестування програмного забезпечення 2021 р. (Інструменти автоматизації тестування якості)
• Альфа-тестування та бета-тестування (повний посібник)
• Що таке системне тестування - Посібник для початківців
• ISTQB Тестування Сертифікація Зразок запитальних робіт з відповідями
• Як писати щотижневий звіт про тестування програмного забезпечення