четвер, 8 червня 2017 р.

Техніки Тестування "З Досвіду"

Анлійську версію цієї статті опубліковано на EUROSTAR's Huddle as Experience-based Testing Strategies

 
На різних ресурсах з тестування програмного забезпечення часто згадують деякі загадкові “Experience-Based Test Techniques” (Засновані на досвіді техніки тестування). Для мене це завжди звучало як "от доростеш до наших літ, тоді й узнаєш". Але коли я сам став вчити тестуванню, то не міг нормально пояснити, що воно таке. Бо "досвіду" трохи важко навчити :-). Можна вигадати деякі практичні завдання, зроблені так, що студенти щось вивчають, але неможливо зробити так, щоб вони вивчили точно мій досвід.






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

Хлопці (чи скоріше вже "Шановні Пани") з контекстно-керованої школи тестування ПЗ (http://context-driven-testing.com/?page_id=9) вирішили зібрати усі ці невизначені категорії  під відкритим терміном «контекст».

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

Але навчаючи, я не можу навчити мистецтву.

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

Але, як учитель, я маю представити дисципліну тестування ПЗ, як ряд вправ, які можна повторити, щоб навчитись і стати кращим тестером.

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


Користувацький інтерфейс

  •     Перевіряйте всі назви / текст повідомлень
  •     Взаємне розташування елементів
  •     Перекриття динамічних елементів

UX

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

Розрахунки у Таблицях з Даними

  •     Щоб перевірити швидко, спробуйте провести багато обчислень, а потім порівняти підсумки (можливе накопичення помилки)
  •     Зважайте на кількість знаків - для подібних розрахунків результат матиме таку ж кількістю цифр
  •     Готуйте дані для тестування обсягом(volume testing), зважаючи на реалістичну варіативність: подивіться в реальні дані та виберіть найцікавіше - те що вибивається з середнього, але все ще вважається нормальним
  •     Перевірте прийнятні/ неприйнятні типи чисел: як ваша система реагує на пробіл чи підкреслення всередині чисел? Чи є кома чи крапка роздільником дробів? Арифметика всередині полів?
  •     Будуйте послідовності розрахунків (накопичення помилки)

Вхідні дані

  •     Різні типи вхідних даних (нехай плагін для браузера BugMagnet вас надихає)
  •     Валідація значень відбувається: в самому полі, на фокусуванні на полі, на зміні фокуса, на відправці даних, фронтенд / бекенд.
  •     Стежте за всіма місцями, де введені дані згодом будуть показані або використані. Складіть повний список таких місць.

Ін'єкції
  •     Це можна було б віднести до тестування безпеки, але часто такі баги навіть заважають користувачам ввести їхні правдиві дані.
  •     JS (XSS):
    •  I go plz<script>alert('JS is executed well!11')</script>
  •     SQL:
    •  Robert'); DROP TABLE Students;--
    •  Щоб отримати помилку з SQL часто достатньо просто вставити ; або спробувати різні типи лапок ’'`   
  •     Формат даних (HTML, XML, JSON):
    •       <b><i><u>Hi there, </u></i></b><blink>Dear!</blink>
    •       <i><b>Wrong tag order</i></b>
    •       ><
    •       '},

Витік пам'яті

  •     Тестування обсягом даних(Data volume testing)
  •     Випробування на виснаження (Soak testing)
  •     Повторюйте деякі ресурсовитратні дії знову і знову, спостерігайте в системний монітор за збільшенням споживання ресурсів

Збереження/читання файлів

  •     Перезапис існуючих файлів
  •     Дуже часте збереження в файл
  •     Спостерігайте за змінами змісту файлу під час його зміни програмою
  •     Вручну міняйте зґенеровані файли (їх зазвичай називають "Не чіпай, там нічого не змінюють руками")

Інтеграції та API

  •     Вимагайте незалежне тестове середовище
  •     Заповнюйте всі поля (от всі-всі! Знайдіть можливі, необов’язкові поля, в тому числі в XML та JSON, та заповніть їх повністю)
  •     Пронумеруйте значення у тестових полях або змініть їх по-своєму, щоб їх легко було впізнати у подальшій обробці
  •     Використовуйте п́арне(pair-wise) заповнення полів(для початку)
  •     Перевірте, як проходить кожна частина вихідних даних  через весь робочий процес, від одного кінця до іншого
  •     Змініть формат, порядок, довжину і інші параметри у дозволених (незаборонених) межах

Взаємний вплив одночасних користувачів

  •     Вводіть схожі/такі самі дані
  •     Змінюйте ті ж записи
  •     Відкривайте/ змінюйте ті ж файли
  •     Переривайте/ Вмикайте ті ж потоки
  •     Використовуйте ті ж ролі/ дозволи користувачів
  •     Використовуйте різні клієнти одночасно (з-під одного облікового запису, або з декількох): настільний, мобільний, веб, API (різні рівні, якщо вони є), мобільний веб

Права доступу

  •     Всі наявні в UI дії дозволені для ролі
  •     Всі дії, які повинні бути дозволені, доступні в інтерфейсі для ролі
  •     Недозволені дії не доступні для цієї ролі навіть за прямими посиланнями (або іншими непрямими способами, як API)
  •     Набір «допустимих дій» може змінюватися під час робочого процесу. Перевірте на кожному кроці
  •     Додайте/ видаліть дозвіл для активного користувача / ролі
  •     Нещодавно додана функція узгоджена з політикою дозволів системи

Контроль процесу

  •     Використовуйте «живі» або «схожі на живі» дані
  •     Ще один крок. Ще трошечки (Просто ще один маленький клік...)
  •     Закінчіть процес як би це зробив «реальний користувач»
  •     Стежте за одиницями виміру по всій системі (не додавайте милі до кілометрів чи долари до відсотків)
  •     Виконайте випадкову дію, яка не має вплинути на основний сценарій, у випадковий момент часу: до/під час/після «основних» кроків.

Немає коментарів: