У цій частині нашої Super-Puper шпаргалки для QA, ми узагальнено повторимо питання:

  • Що таке розробка тестів? Як їх групувати? Кінці-кінців, Що таке тест дизайн?
  • Які техніки тест дизайну існують?
  • І як ці техніки тест дизайну можна класифікувати?

Розпочинаймо, до роботи!

Питання #33 Що таке тест-дизайн?

Тут все просто тест дизайн — це один з етапів процесу розробки програмного забезпечення, етап придумування, розробки, та упорядкування тестів в набори на основі аналізу вимог та функціональності продукту (складання тест планів, тест сценаріїв, CheckLists,  Test Сases, Use Cases, побудова таблиці прийняття рішень тощо).

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

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

Для різних припущень існують тести різної ступіні ефективності.

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

Отже, процес тестування програмного забезпечення повинен бути грамотним без «зайвих рухів», тобто з мінімальною кількістю тестів. Але яких тестів? Вірно! — Ефективних тестів, які будуть в змозі виявити найбільш серйозні помилки продукту. І тому без знання технік тестдизайну ніяк не обійтися!

Питання #34 Що таке техніки тест дизайну?

Техніка тест дизайну — (коротко) це спосіб, іншими словами це метод створення тестів.

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

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

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

Найпоширеніші класифікації технік тест дизайну:

Питання #35 Cтатична та динамічна методика тестування:

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

Static Test Design Techniques  — техніки тестування, які включають тестування ПЗ без виконання коду. Різні методи розробки таких статичних тестових випробувань у свою чергу можна розділити ще на дві частини: ручні методи та з використанням спеціалізованого інструменту:

Manual static design techniques:

  • Walk through
  • Informal reviews
  • Technical reviews
  • Audit
  • Inspection
  • Management review

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

Static design techniques using tool:

  • Static analysis of code — полягає в аналізі різних шляхів і потоків у додатку (анг. flow) та отриманих різних даних тестів. Приклади інструментів для Java: Checkstyle, FindBugs, PMD, для Javascript: JSLint.
  • Compliance to coding standard — визначають відповідність коду різним стандартам кодування.
  • Analysis of code metrics — інструмент, який використовується для статичного аналізу, необхідний для оцінки різних показників, таких як рядки коду, складності, покриття коду тощо.

Dynamic Test Design Techniques це техніки дизайну, які передбачають тестування в процесі безпосереднього виконання програми.

  • Specification based — також називається тестуванням Blackbox Testing (Тестування Чорної Скриньки). Це техніки тестування, які включають тестування на основі володіння інформацією по специфікації існуючої системи, але без знання її внутрішньої архітектури.
  • Structure based — методика проектування тестів відома ще під назвою White Box Testing (Тестування Білої Скриньки). У цій техніці дизайну, на відміну від попередньої, необхідне знання коду або внутрішньої архітектури системи для проведення тестування.
  • Experienced based — це техніки дизайну тестів, які повністю базуються на досвіді або інтуїції тестера. Дві найбільш поширені форми тестування з досвіду — види Ad-hoc тестування та Exploratory testing. ДЕТАЛЬНІШЕ про ці види тестування ми згадуємо у Частині 3: Шпаркалки для QA — види тестування.

Питання #36 Перелічіть дизайн техніки Blackbox Testing?

Ли Копланд (Lee CopeLand)  виділяє наступні дизайн техніки, котрі використовуються в тест дизайні:

  • Equivalence partitioning (Еквівалентний поділ) — полягає у групуванні тестових даних у логічні групи або класи еквівалентності з поступовим зменшенням кількості тестів і урахуванням того, що будь-які елементи даних, що лежать у класах, матимуть однаковий вплив на додаток.
  • Boundary value analysis (Аналіз граничного значення) — тестування з використанням крайніх граничних значень класів еквівалентності, прийнятих як тестовий вхід. Наприклад, мінусові значення, використання спеціальних символів, значення більші за максимально допустимий діапазон тощо.
  • Domain Analysis Testing (Доменний Аналіз) — це дизайн техніка, яка теж грунтується на розбитті діапазону можливих значень змінних (або самих змінних) на піддіапазони (або домени), з подальшим вибором одного або кількох значень з кожної домену для тестування. На відміну від попередньо описаного методу, доменне тестування не обмежується тільки граничними значеннями. Доменний аналіз включає в себе аналіз залежностей між змінними, пошук значень змінних, які несуть у собі великий ризик (не тільки на крайніх точках).
  • Decision tables (Таблиці рішень) — тестування з використанням таблиці рішень. Таблиця рішень відображає поведінку програми на основі різного поєднання вхідних значень. У таблицях рішень представлений набір умов, одночасне виконання яких повинно привести до певної дії. Цей метод хороший для упорядкування складних бізнес вимог. Або якщо узагалі не має адекватної документації — таблиці дозволяють тест-інженеру самостійно більш-менш структурувати розрізнену інформацію.
  • Cause-effect graph (Графік причинно-наслідкового впливу) — техніка тестування, яка відображає вхідні дані (причину) і відповіді системи (наслідок) у комбінації. Цей метод використовує різні оператори, котрі відображають взаємозв’язки: AND, OR, NOT etc. А умови приводять до виводу. Наприклад, Ви перевіряєте можливість додати клієнта на сайт клієнтської бази інтернет магазину. Для цього Вам необхідно ввести кілька полів, таких як «Ім’я», «Адреса», «Номер Телефону», а потім натиснути кнопку «Додати» — це «Причина». Після натискання кнопки «Додати», система додає клієнта в Базу Даних і показує його ID номер у відповідь — це й є наслідок.
  • State transition testing (Перевірка станів і переходів) — система переходить у той чи ін. стан, залежності, які операції над нею виконуються. Функціонал системи найчастіше описують діаграмами переходів, і опираючись на цю схему вже прописуються тест-кейси.
  • Use case testing (Сценарії тестування) — тестування проводиться з використанням Use cases (сценарій взаємодії користувача і системи). Цей вид тестування ми теж розглядаємо ДЕТАЛЬНІШЕ  у Частині 1: Шпаркалки для QA — 100+ найпоширеніших запитань на інтерв’ю — і..і…і РЕКОМЕНДУЄМО ознайомитися з правилами складання Use Case Diagrams (діаграми прецендентів) за поданим посиланням.
  • Pairwise Testing (Метод парного тестування) — це тести які перевіряють один або кілька параметрів у комбінації. Оскільки уся комбінаторика, як і статистика — то ВЕЛИКІ цифри від яких тільки так «розболиться голова». Наприклад, 10 параметрів із комбінацією Включити/Виключити буде 1024 (2 в 10 -му степені). ➡ прямуйте краще по активному посиланні до Вікіпедії Про Pairwise Testing там гарно і стисло описано. Цей метод дозволяє нам зменшити кількість тестів відсіявши пусті тести, де параметр з комбінацією не зустрічаються в парі. Робиться це за допомогою математики ортогональних таблиць, і автоматизованих інструментів, які використовують алгоритм AllPairs. Зокрема, цикл цього алгоритму можна запустити різними мовами програмування….ага продовжуйте вчитися, вчитися, вчитися…

Питання #35 Поясніть розподіл по класам еквівалентності на прикладі?

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

Наприклад, для тестування програми піднесення до квадрата, яка друкує квадрат числа — класи еквівалентності можуть бути:

  • набір від’ємних чисел;
  • набір додатніх чисел;
  • цілих чисел;
  • десяткових чисел;
  • набір простих чисел.

Питання #36 Наведіть приклад аналізу граничних значень?

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

Наприклад: у інтернет-магазині на складі є  в наявності 1000 олівців. При покупці до 100 олівців діє роздрібна ціна 10 гривень, від 100 олівців до 500 дрібно-гуртова ціна 8 гривень, від 500 олівців гуртова ціна 5 гривень.

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

  • 1-99 олівців — 10 гривень
  • 100-499 — 8гривень
  • 500-1000 — 5 гривень

Аналіз граничних значень буде включати такі вхідні дані: {-1, 0, 1} {99, 100, 101} { 499, 500, 501} {999, 1000, 1001}

Питання #37  Приклад Тестування таблиці рішень?

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

Умова:Тест 1Тест 2Тест 3 Тест 4
Знижка по дисконтній картці 5%такнітакні
Додаткова знижка 10% (по смс)тактакніні
Дія:    
Разом знижка?15%10%5%0

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

Питання #38 Накресліть графік effect graph testing?

Effect graph testing (Тестування причинного наслідкового ефекту) — повтормимо, це техніка дизайну тесту Чорної скриньки, в якій для проектування тесту використовується графічне подання вхідних даних, причини та виведення, тобто ефект. Між умовами введення, що приводять до виводу (ефекту). Цей метод використовує різні позначення, що представляють відносини AND, OR, NOT.  Effect graph testing ми можемо відображати у матриці (табличці, як у попередньому питанні), а можемо зображати діаграмами:

Ось для прикладу картиночки ілюстрації з інтернету:

Operators Effect Graph Symbols

Effect graph testing

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

Питання #39 Приклад тестування станів та переходів State transition testing?

State transition testing — грунтується на концепції, що систему можна визначити як сукупність  станів, а перехід від одного стану до іншого відбувається через певну подію, як на зображенні:

State transition testing

  • Стан (state, представлене у вигляді квадратика на діаграмі) — це стан додатку, в якому воно очікує одне або більше подій. Стан пам’ятає вхідні дані, отримані до цього, і показує, як додаток буде реагувати на отримані події. Події можуть викликати зміну стану і / або ініціювати дії.
  • Перехід (transition, представлено у вигляді стрілки на діаграмі) — це перетворення одного стану в інший, що відбувається за подією.
  • Подія (event, може бути представлена ярликом над стрілкою) — це щось, що змушує додаток поміняти свій стан. Події можуть надходити ззовні додатку, через інтерфейс самого додатку. Сам додаток також може генерувати події (наприклад, подія «закінчився таймер»). У нашому Випадку правильне/неправильне значення Pin. Коли відбувається подія, додаток може поміняти (або не міняти) стан і виконати (або не виконати) дію. Події можуть додатково мати параметри (наприклад, подія «Оплата» може мати параметри «Готівка», «Чек», «Дебетова карта» або «Кредитна картка»).
  • Дія (action, представлено після «/» в ярлику над переходом) ініціюється зміною стану ( «1 спроба», «2 спроба» і ін.). Зазвичай дії створюють щось, що є вихідними / повертаються даними системи. Дії виникають при переходах, сам по собі стан пасивний.
  • Точка входу позначається чорним кружечком.
  • Точка виходу показується на діаграмі у вигляді мішені. Більше про такі схеми, які звуться UML діаграмами пропонуємо вивчати за посиланням у розділі ТЕОРІЯ ТЕСТУВАННЯ

Питання #41 Що таке структурні техніки тестування?

Тест дизайн техніки, які грунтуються на знанні коду і внутрішньої архітектури (тобто структури) програми — також називаються тестуванням Білої скриньки (White box testing). Або ще як говорять скляного, прозорого ящика, оскільки тестувальнику усе є відомо про систему. І ці знання є необхідною умовою для проведення тестування.

Структурне тестування доповнює функціональне тестування і сценарні техніки тестування. Логічно, цей вид тестування можливий для рівня не вище рівня програмного модуля. Чимось схожий на Юніт тестування (англ. unit testing), яким зазвичай займаються розробники, при якому тестуються тільки окремі частини системи.

Звідси мета структурних технік тестування — максимально покрити тестами код (code coverage), точніше код сценаріїв і їх розгалужень (statement & decision coverage).

Виконання функціонального і структурного тестування системи може бути здійснене незалежно одне від одного.  

Розрізняють наступні види White box testing (Тестування Білої скриньки):

  • Statement testing — це коли тестові скрипти розробляються для виконання виразів коду, а покриття — це міра підрахунку рядків коду пройдених тестовим скриптом. Сто відсоткове покриття має місце коли покриті всі рядки та всі твердження коду. В іншому випадку береться до уваги покриття у процентному відношенні. Хорошим показником statement coverage вважається 60-75%.
  • Decision testing/branch testing (Тестування рішень / гілок) — це вже більш високий рівень, котрий охоплює усі типи ієрархій (if-else, switch операторів, виклики методів). Вимірює відсоток точок рішень, що виконуються у розрахунку із загальної кількості умов в аплікації. Показник повинен варіюватися в межах 40-60%.
  • Condition testing (Тестування умов) — коли при тестуванні виконуються умови (ІСТИНА або ХИБА || TRUE or FALSE). Таким чином, отримання 100% умовного покриття вимагає виконання кожної умови для отримання таких результатів як TRUE або FALSE. Використовуючи тестові скрипти (за умови n — ми отримаємо 2n тестових сценаріїв). Головні логічні оператори тут (AND, OR, NOT).
  • Multiple condition testing (Тестування кількох умов) — це коли ми тестуємо різні комбінації вхідних умов. Таким чином, для 100% покриття ми будемо мати 2^n тестових сценаріїв. Досягти 100% покриття нереально.
  • Condition determination testing (Тестування визначених умов) — це більш математично оптимізований тип Multiple condition testing, у якому комбінації, які не впливають на результати, відкидаються.
  • Path testing (Тестування маршрутів) — тестування набору незалежних шляхів у системі (під-шляхів) по яких принципі може пройти програма по усіх розгалуженнях. Теоретично таких шляхів нескінченна кількість, враховуючи цикли.
  • Loop coverage (Тестування циклів) — наявність циклів у програмних модулях здатне різко збільшувати складність їхнього тестування. На складність тестування циклу впливає його структура та два параметри: число маршрутів у тілі циклу та число ітерацій циклу. Одним словом, то є складна математика і алгоритми: зростання на квадратичну, експоненціальну та логарифмічні множити.

Кому таке ДІЙСНО цікаво, повторюємо ще раз ЧИТАЙТЕ: Лі Копланда у нашій бібліотеці IT Книг все завантажувати можна БЕЗКОШТОВНО 😛 

Питання #42 Яка різниця між White box & Black box Testing?

Black box

White box

1. Тестувальник не володіє інформацією про внутрішню будову системи або її компонентів. Дизайн, внутрішня структура компонентів тестувальнику є відомі. Наприклад, з аналізу коду можна визначити, скільки контрольних тестів потрібно виконати для того, щоб у процесі тестування всі оператори виконалися принаймні один раз.
2.BlackBox Testing відповідає на питання: WHAT? Що програма робить виконуючи тести.WhiteBox Testing відповідає на питання: HOW? Як програма робить певну дію? Тобто тестувальник за такого виду тестування виступає більше в ролі механіка, який намагається всередині машини розібратися чому програма не працює?
3.Тестувальники більше зосереджені на функціональному тестуванні — дослідженні. Хоча Тестування Безпеки, Перфоманс, Конфігураційне, Інсталяції тестування відносяться до тестування Чорної скриньки.Більше зосереджені на структурі програми, її коді, гілок, циклів тощо.
4.Здебільного Тестування Чорної скриньки — це тестування цілісної системи. System Testing, Acceptance Testing.Тестування Білого ящика — це модульне тестування, таке як Unit Testing, Integration Testing.
 Виконують тестувальники. Може виконуватися користувачами методом проб та помилок. Може виконуватися як фаховими тестувальниками, так і розробниками.
5.Може проводитися незалежними зовнішніми тестувальниками. Зазвичай таке тестування проводять внутрішні тестувальники.
6. Тестування Чорної Скриньки може бути проведене без знання жодної з мов програмування.Необхідні знання якоїсь із мов програмування, Автоматизованого Тестування, спеціалізованих інструментів.
7.Не підходить для тестування алгоритмами. Потрібне хоча б базове знання поширених алгоритмів.
 8.Дешевше і легше налагодити.Отже, більш трудомістке та дороге.
9. Більша залежність від людського фактору. Можна провести більш якісне тестування, з покриттям великої кількості шляхів та гілок, які виконує програма.
10. Поведінка системи може бути не очікувана.Оскільки ми знаємо внутрішню будову, поведінка для нас завжди буде очікуваною. Тестери навіть можуть впливати на дизайн програми.
11.Для початку тестування необхідно чекати створення користувацького інтерфейсу. Тестування може розпочинатися на більш ранніх етапах Циклу Розробки Програмного Забезпечення.
12. Основа для тест-кейсів специфікація, вимоги. Потрібна більш детальніша інформація, де описується архітектура. Напр. проектна документація

Підсумок:

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

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

      Дійсно: який сенс, припустимо, від повного тестового покриття клієнтської форми авторизації, якщо при цьому не буде коректно працювати механізм оплати за товар в інтернетмагазині? Адже за той час, поки тестувальник 100 тестами перевірить 100 значень, тестдизайнер придумає, як за 10 тестів перевірити 1000 значень в 10 разів швидше! Оцініть раціональність застосування автоматизованого тестування!

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

     Якщо на співбесідах на тестувальника, технічних інтерв’ю задавали інакші, не менш підступні запитання пишіть їх у коментарях — учасники нашої спільноти будуть  вдячні Вам за це 🙂

Related posts

Leave a Comment

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.