5 важливих схем, які тестери повинні навчитися використовувати

5 important diagrams that testers need learn how use

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

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

У технологічній галузі наші схеми нам дорогі.

Ось деякі найвидатніші, з якими ми, тестувальники, часто контактуємо і як ми їх використовуємо.

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

• 5 діаграм, які тестери повинні навчитися використовувати
• # 1) Блок-схеми:
• # 2) Діаграми переходів стану:
• # 3) Контекстні діаграми:
• # 4) Карти розуму:
• # 5) Діаграми ER:
• # 6) Бонус: Макет екранів / каркаси:
• Щоб завершити - Як ви можете створити ці схеми, якщо вам потрібно?
• Рекомендована література

5 діаграм, які тестери повинні навчитися використовувати

Ось і ми.

# 1) Блок-схеми:

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

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

Найпоширенішими символами та їх значеннями на блок-схемі є:

• Овали - Для запуску і зупинки
• Прямокутники- Для обробки / або завдання
• Алмазний Для прийняття рішень

Повну інформацію про форми блок-схеми див Блок-схема символів .

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

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

Ось два способи використання тестерів діаграмами:

а) Блок-схеми для контрольного потоку та статистичного аналізу:

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

Блок-схема - це метод переходу до цього показника.

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

Просто створіть блок-схему управління, як показано нижче, і використовуйте цю формулу:

Цикломатична складність: = Кількість з'єднань або рядків - Кількість вузлів + 2

З діаграми кількість вузлів дорівнює 7, а з'єднань - 7.

Отже, цикломатична складність цього фрагмента коду становить 7-7 + 2 = 2.

Потрібна додаткова інформація про те, як використовувати діаграму управління та цикломатичну складність?

Заціни:

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

б) Блок-схеми для ілюстрації процесу:

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

(Примітка:Клацніть на зображення для збільшення

# 2) Діаграми переходів стану:

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

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

Це може бути показано у вигляді схеми або таблиці. Як нижче:

Просто, правда? Візьмемо щось дещо складніше. Подивіться на схему переходу стану для системи квитків. Це досить просто і легко зрозуміти.

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

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

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

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

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

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

Для набагато більш повного пояснення та використання в реальному світі перегляньте => Державна перехідна методика випробувань для випробування складних додатків

# 3) Контекстні діаграми:

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

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

Далі наводиться контекстна схема для щойно описаної системи оплати праці:

Контекстна діаграма дуже чітко показує контекст певної системи з усіма іншими сутностями, які до неї відносяться. Для простого пояснення перевірте тут =>

Для простого пояснення перевірте тут => Контекстна діаграма системи

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

# 4) Карти розуму:

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

компанії, що займаються Інтернетом речей

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

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

Наприклад: Далі наведена схема для програми електронної комерції, де ви просто відстежуєте тестування за допомогою розумової карти, як показано нижче:

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

Для отримання додаткової інформації та інструментів перевірте => Складання розуму при тестуванні програмного забезпечення - способи зробити тестування цікавішим!

# 5) Діаграми ER:

Діаграми сутності-взаємозв'язку (ER-Entity-Relationship) використовуються для моделювання баз даних. Вони допомагають нам зрозуміти таблиці, їх поля та те, як поля в одній таблиці співвідносяться з полями в інших таблицях системи БД. Він наочно показує компоненти вашої системи БД та взаємозв'язки між ними.

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

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

Є багато варіантів діаграм ER, але найпростіша версія може виглядати нижче:

Зображення Джерело

Для швидкого вступу та пояснення перевірте:

• Діаграма взаємовідносин суб’єктів (ERD) Навчальне відео
• Підручник з діаграми взаємовідносин суб’єктів (ERD)

# 6) Бонус: Макет екранів / каркаси:

Каркаси - це або HTML, або прості зображення (скріншоти), які схематично показують нам майбутню сторінку / компонент інтерфейсу.

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

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

Простий каркас для екрана входу може бути таким:

Ось коротке посилання, щоб зрозуміти, як команди з контролю якості використовують каркаси для раннього тестування та деякі інструменти для їх створення => Каркаси - чи справді їх слід тестувати? І якщо так, то як?

Щоб завершити - Як ви можете створити ці схеми, якщо вам потрібно?

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

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

Про автора: Ця стаття написана членом нашої команди Swati.

Отже, якими схемами ви користуєтесь і які улюблені?

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

• Поради щодо тестування програмного забезпечення для початківців тестувальників
• Найкращі засоби тестування програмного забезпечення 2021 р. (Засоби автоматизації тестування якості)
• Що таке тестування компонентів або модульне тестування (Дізнайтеся на прикладах)
• Що таке порівняльне тестування (Дізнайтеся на прикладах)
• Чи втрачають тестери контроль над тестуванням через автоматизацію?
• Незабаром глобальний бізнес з тестування програмного забезпечення досягне $ 28,8 млрд
• Як зберегти мотивацію живою в тестерах програмного забезпечення?
• Тестування Праймера Завантажити електронну книгу