Лекції

1.

Тестування. Вступ
Лекція 1

2.

План лекції
Термінологія тестування.
Дефект.
Звіт про дефект.
Життєвий цикл дефекту.

3.

Поняття тестування
Відповідно до стандарту ISO/ IEC 1227 тестування може розглядатися як
окремий етап життєвого циклу, що підкреслює важливість процедур
тестування в процесі розробки.
Тестування – це процес аналізу ПЗ, спрямований на виявлення відмінностей
між його реально існуючими й необхідними властивостями (дефект) і на
оцінку властивостей програмного забезпечення (стандарт IEEE Std 8291983).
Тестування – перевірка відповідності між реальною й очікуваною
поведінкою програми, що здійснюється на кінцевому наборі тестів, обраному
певним чином (IEEE Guide to Software Engineering Body of Knowledge,
SWEBOK, 2004).

4.

Поняття тестування
Тестування використовується для того, щоб показати наявність
помилок, але не їхню відсутність (визначення Дейкстри).
Результати тестування: гарантувати, що результати тестування коректні й
що розбіжності між фактичним й очікуваним результатами можна пояснити».
У більш широкому розумінні, тестування – це одна з технік контролю
якості, що включає в себе активності по плануванню робіт (Test
Management), проектуванню тестів (Test Design), виконанню тестування
(Test Execution) і аналізу отриманих результатів (Test Analysis).

5.

Поняття тестування
Процес тестування складається з наступних стадій:
Джерела очікуваного результату:
Специфікація.
Загальновизнані стандарти.
Здоровий глузд.
Код програми.
Авторитетна думка.

6.

Термінологія тестування
Верифікація (Verification) – це процес оцінки системи або її компонентів
з метою визначення, чи задовольняють результати поточного етапу
розробки умовам, сформованим на початку цього етапу [IEEE], тобто чи
виконуються мета, строки, завдання по розробці проекту, визначені на
початку поточної фази.
Валідація (Validation) – це визначення відповідності програмного
забезпечення, що розробляється, очікуванням і потребам користувача,
вимогам до системи [BS7925-1].
Забезпечення якості (QA, Quality Assurance) – це сукупність заходів, що
охоплює всі технологічні етапи розробки, випуску й експлуатації ПЗ для
забезпечення якості продукту, що випускається.

7.

Баг
Bug (баг) – це дефект/помилка в програмі або системі, яка видає
несподіваний або неправильний результат.
Існує кілька визначень терміна “баг”:
дефект, помилка в програмі або в системі, яка видає несподіваний або
неправильний результат;
жаргонне слово, яке зазвичай означає помилку в програмі або системі, яка
видає несподіваний або неправильний результат;
відхилення фактичного результату (actual result) від очікуваного результату
(expected result).
Термін “баг” використаний в обліковому записі піонером комп’ютерів Грейс
Хоппер, яка описала причину збою в ранньому електромеханічному
комп’ютері.

8.

Звіт про дефект
Баг / Дефект Репорт (Bug Report) – документ, що описує знайдений
дефект, а також дії, необхідні для його відтворення.
У баг репорті описується ситуація або послідовність дій, яка призвела до
некоректної роботи об'єкта тестування, із зазначенням причин і очікуваного
результату.
Після прочитання короткого опису помилки (Bug Summary) програміст
повинен зрозуміти, в чому проблема, після прочитання детального опису
помилки (Bug Description) він повинен знати рядок коду для редагування.
Хороший опис помилки має відповідати на питання:
Які кроки призвели до помилки?
Що ви очікували побачити?
Що ви насправді побачили?

9.

Атрибути баг-репорта
Поля
Унікальний ідентифікатор
Короткий опис (Summary)
Детальний опис
(Description)
Проект (Project)
Компонент додатку
(Component)
Номер версії (Version)
Серйозність (Severity)
Пріоритет (Priority)
Детальний опис
Короткий опис проблеми, що явно вказує на причину й тип
помилкової ситуації.
Детальний опис проблеми, що явно вказує на причину й тип
помилкової ситуації.
Проект / продукт, що тестується
Назва частини або функції продукту ,що тестується
Версія, у якій була знайдена помилка
Найпоширеніша система градації серйозності дефекту:
S1 Блокуючий (Blocker)
S2 Критичний (Critical)
S3 Значний (Major)
S4 Незначний (Minor)
S5 Тривіальний (Trivial)
Пріоритет дефекту:
P1 Високий (High)
P2 Середній (Medium)
P3 Низький (Low)

10.

Атрибути баг-репорта
Поля
Статус (Status)
Детальний опис
Статус бага. Залежить від використовуваної процедури й життєвого
циклу бага (bug workflow and life cycle)
Автор (Author)
Автор баг репорту
Призначений (Assigned To) Ім’я співробітника, призначеного для вирішення проблеми
Оточення
ОС / Сервіс Пак і т.д. /
Інформація про оточення, на якому був знайдений баг: операційна
Браузера + версія / ...
система, сервіс пак, для WEB тестування – ім’я і версія браузера.
Опис
Кроки відтворення (Steps to Кроки, по яких можна легко відтворити ситуацію, яка призвела до
Reproduce)
помилки.
Фактичний Результат
Результат, отриманий після проходження кроків до відтворення
(Result)
Очікуваний результат
Очікуваний правильний результат
(Expected Result)
Доповнення
Прикріплений файл
Файл із логами, скриншот або будь-який інший документ, що може
(Attachment)
допомогти прояснити причину помилки або вказати на спосіб
вирішення проблеми

11.

Вимоги до баг репорта
Обов'язкові поля звіту про помилку:
Короткий опис;
Серйозність;
Кроки для відтворення;
Фактичний результат;
Очікуваний результат.
Примітки:
один звіт створюється для однієї помилки;
один звіт створюється для однієї помилки, яка відтворюється в різних
браузерах/ОС;
браузери/ОС перераховуються в полі Платформа/ОС.

12.

Серйозність
Серйозність (severity) – це технічна категорія, яка визначає критичність багу
з точки зору тестувальника: особливість, помилка в тексті, дрібна
проблема, значна проблема, падіння продукту, проблема блокуючого
характеру:

13.

Серйозність
Blocker
(блокуючий) – помилка, яка блокує тестування або
використання більшості функціональних можливостей проекту.
Critical (критичний):
критичний системний збій (crash) – помилка, яка призводить до
збою програми;
втрата даних (data loss);
проблема з безпекою (security issue);
Major (значний):
помилка в основному функціоналі;
сайт "зависає" (site hangs);
Minor (помірний):
помилка в додатковій функціональності (functional bugs);
Cosmetic (косметичний) – косметична проблема
trivial (тривіальна/банальна) – це дрібні та малопомітні помилки;
text (текст) – невелика текстова/друкарська помилка
Tweak
(незручність) – помилка, яка створює незручності у
використанні

14.

Пріоритет
Пріоритет
дефекту
вказує
на
важливість
або
терміновість
виправлення дефекту. Чим вище пріоритет, тим швидше потрібно усунути
дефект.
Класифікація пріоритетів:
P1 High / Високий – дефект необхідно виправити якомога швидше,
оскільки його наявність є критичною для проекту.
P2 Medium / Середній – наявність дефекту не є критичною, але вимагає
вирішення.
P3 Low / Низький – наявність дефекту не є критичною і не вимагає
термінового вирішення. Інші, більш серйозні дефекти мають більший
пріоритет.
Порядок усунення дефектів відповідно до їх пріоритетів:
Високий -> Середній -> Низький.

15.

Summary

16.

Summary
Summary :
Вам потрібно скласти речення, в якому факти дефекту
описані в такій послідовності:
Що?:
Де?:
Коли? Які умови?
Приклад:
Що: поле «Підтвердити пароль» не обов’язкове;
Де: реєстраційна форма;
Які умови: при реєстрації нового користувача.
Summary: Поле «Підтвердити пароль» не є обов’язковим у
формі реєстрації

17.

Summary. Приклади
1. Програма аварійно завершує роботу під час збереження
текстового файлу розміром більше 50 МБ.
2. Дані у формі «Профіль» не зберігаються після натискання
кнопки «Зберегти».
3. Поле «Підтвердити пароль» є необов'язковим у формі
реєстрації.
4. Текст спливаючого списку головного меню (вкладка
«Courses») відображається за межами виділеної області.

18.

Правила створення баг-репортів
Один баг = один баг-репорт.
Вказати URL або розділ сайту.
Описати послідовність дій.
Описати фактичний та очікуваний
результат.
Які кроки призвели до
помилки?
Зробити
скріншот,
додати
прямокутник (виділяючи проблемне
місце) і червону стрілку, показуючи
повну сторінку з адресним рядком
браузера. Якщо баг функціональний –
додається складний скріншот або
відео.
Що ви насправді
побачили?
Гарний звіт про помилку
відповідає на питання:
Що ви очікували
побачити?

19.

Зняття скриншотів

20.

Приклади

21.

Приклади

22.

Термінологія
Життєвий цикл бага – послідовність етапів, які проходить баг на своєму
шляху з моменту його створення до остаточного закриття.
Баг-трекер – це система обліку та відстеження помилок, яка дозволяє:
Створювати
Зберігати
Переглядати
Редагувати

23.

Життєвий цикл дефекта
Головна точка входу.
ініціалізація нового звіту про дефект
New (новий)
Rejected
(відхилений)
Open
(відкритий)
Deferred
(відтермінований)
Verified
(виправлений)
Reopen
(відкритий
повторно)
Closed
(закритий)
Останній статус звіту про дефект
Зміна статусів звіту про дефект

24.

Статуси багів

25.

Аксіоми тестування
Лекція 2

26.

План лекції
Мета тестування.
Аксіоми тестування.
Питання.

27.

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

28.

Мета тестування
Мета тестування може включати:
Оцінку елементів продукту, таких як вимоги, історії користувачів,
дизайн і код
Перевірку, чи виконано всі зазначені вимоги
Перевірку, чи тестовий об’єкт завершений і працює так, як очікують
користувачі та інші зацікавлені сторони
Формування впевненості у рівні якості об'єкта тестування
Запобігання дефектам
Знаходження несправностей та недоліків
Надання достатньої інформації зацікавленим сторонам
Зниження рівня ризику неналежної якості програмного забезпечення
Дотримання договірних, правових або нормативних вимог або
стандартів та/або для перевірки відповідності об’єкта випробувань
таким вимогам або стандартам

29.

Причини виникнення дефектів
Рисунок 1 – Розподіл причин виникнення дефектів

30.

Принцип 1
Тестування показує наявність дефектів, а не їх відсутність
(Дейкстра, 1972 р.).

31.

Принцип 2
Вичерпне тестування неможливо.
Вичерпне тестування неможливо, навіть для найпростіших програм, тому
що:
Кількість можливих вхідних даних дуже велика.
Кількість можливих результатів дуже велика.
Кількість проходів по ПЗ дуже велика.
Специфікація ПЗ суб'єктивна. Можна сказати, що помилка – це зовсім
не помилка, так і було задумано

32.

Принцип 3
Раннє тестування рятує час і гроші.
Рисунок 2 – Вартість пошуку та усунення дефектів

33.

Принцип 4
Тестування – це процес, що містить ризики.
Рисунок 3 – Залежність між обсягом тестування та якістю проекту

34.

Принцип 5
Дефекти групуються разом.
Чим більше помилок знаходить тестер, тим більше їх існує.
Причини:
У програмістів бувають невдалі дні. Код, написаний в один день,
може бути ідеальним; в іншій – неякісним. Одна помилка може бути
маячком, що показує – тут поруч є ще.
Програмісти часто роблять одні й ті самі помилки.
Деякі помилки – лише вершина айсбергу. Дуже часто проект або
архітектура ПЗ мають фундаментальні проблеми. Помилки, які на
перший погляд здаються не зв'язаними, можуть вказувати на одну
серйозну первинну причину.

35.

Принцип 6
Парадокс пестицидів.
Б. Бейзер “Техніки тестування програмного забезпечення” (1990 р.)
запропонував термін парадокс пестицидів – чим більше тестер тестує
ПЗ, тим більше воно стає невразливим до тестувань.

36.

Принцип 7
Тестування – контекстнозалежне .
Чим вище ймовірність втрат, тим більше нам потрібно інвестувати в
тестування

37.

Принцип 8
Іноді складно сказати, чи є помилка помилкою

38.

Принцип 9
Не всі знайдені помилки обов’язково будуть виправлені
Наведемо деякі причини, з яких помилка може бути не виправленою:
Недостатньо часу. У кожному проекті завжди є багато специфікацій та
нюансів і не досить можливостей, що б закінчити їх усі.
Це насправді не помилка. Часто від розробників можна почути: не
помилка, це – властивість!”.
Занадто ризиковано виправляти. Виправлення однієї помилки може
спричинити виникнення нових.
Це просто не варто виправляти. Помилки, які виникають нерегулярно
або в мало використовуваних функціях можуть бути опущені.
Причина цього – бізнес рішення, що базуються на ризику.

39.

Принцип 9
Не всі знайдені помилки обов’язково будуть виправлені
Наведемо деякі причини, з яких помилка може бути не виправленою:
Недостатньо часу. У кожному проекті завжди є багато специфікацій та
нюансів і не досить можливостей, що б закінчити їх усі.
Це насправді не помилка. Часто від розробників можна почути: не
помилка, це – властивість!”.
Занадто ризиковано виправляти. Виправлення однієї помилки може
спричинити виникнення нових.
Це просто не варто виправляти. Помилки, які виникають нерегулярно
або в мало використовуваних функціях можуть бути опущені.
Причина цього – бізнес рішення, що базуються на ризику.

40.

Сформулюйте суть бага

41.

Сформулюйте суть бага
Відсутнє випадаюче меню в пункті Actions при невибраному документі

42.

Сформулюйте суть бага

43.

Сформулюйте суть бага
Значення полів Display width, Min Length не зберігаються при додаванні
Node Index

44.

Сформулюйте суть бага

45.

Сформулюйте суть бага
Відсутній параметр Size в Document Summary при експорті даних документа

46.

Питання
Який баг необхідно виправляти швидше: з серйозністю Critical чи з
пріоритом Urgent?
Що є статусом бага: Новий, Виправлений, Дублікат, Закритий?
Як визначаються обов’язкові поля на формі?
Хто визначає пріоритет?

47.

Тестування веб-проектів.
Тестування верстки
Лекція 3

48.

План лекції
Етапи тестування веб-проектів.
Тестування верстки.

49.

Етапи тестування веб-проектів
Тестування веб-додатків складається з таких етапів:
Тестування верстки.
Функціональне тестування, тестування бізнесу-логіки.
Usability-тестування.
Тестування безпеки.
Тестування продуктивності.
Навантажувальне тестування.
Регресійне тестування.
Тестування займає до 50 % від загального часу проекту. 90% від
загального обсягу тестування займає функціональне тестування.

50.

Анатомія веб-сторінки

51.

Тестування веб-проектів
Вхідні дані:
Тест-план
Чек-аркуш
Набір тестів
Сайт
Джерела очікуваних результатів:
Технічне завдання.
Специфікація.
Досвід.
Прийняті норми.

52.

Тестування веб-проектів. Візуальна
частина
Відсутність помітних оку невідповідностей: поламані блоки, не стикування
кольорів, некоректне відображення тексту навколо зображень, перекриття
одних елементів верстки іншими й т.д.
Точність відповідності макету:
1. Перевіряється за допомогою накладки шарів в Photoshop так:
Робиться знімок екрана в браузері.
Додається до макета як окремий шар.
На доданий шар ставиться прозорість.
Зображення порівнюються між собою.
2. З використанням Pixel Perfect для Firefox або PerfectPixel для Chrome.
Розташування блоків повинне бути 1:1 у порівнянні з макетом.
Допускається розбіжність до 5px для тексту.

53.

Тестування веб-проектів. Візуальна
частина
Перевірка сітки (вертикальні/горизонтальні вирівнювання), особливо у
формах.
Перевірка в різних розширеннях:
не повинне нічого ламатися;
не повинне з'являтися горизонтальне прокручування
обумовлених технічним завданням дозволів;
не повинні різко обриватися фони при великих дозволах.
Інструменти тестування для переводу екрана в різні розширення:
1. Firefox Меню / Інструменти / Веб-разработка / Адаптивный дизайн.
2. Resolution Test plugin в Chrome.
для

54.

Тестування веб-проектів. Візуальна
частина
Зменшення розміру вікна менше мінімального за ТЗ – не повинне нічого
ламатися, фони не повинні "плисти".
Перевірка масштабування сторінки: у діапазоні 75-150% сторінка повинна
виглядати без візуальних недоліків.
Зміна розмірів текстового поля (textarea) не повинна ламати верстку.
Підсвічування полів у фокусі; підсвічування полів з помилками.

55.

Тестування веб-проектів.
Доступність
Підсвічування полів у фокусі; підсвічування полів з помилками.
Титульна сторінка повинна бути валідна в будь-якому разі.
Перевірка, чи виділяється текст у текстових блоках.
Перевірка, чи натискаються “кликабильні” елементи (посилання/ кнопки).
Перевірка, чи встановлюється фокус у поля форм;
Кликабильні елементи повинні мати покажчик "курсор", елементи, що
перетаскуються - «move" або “crosshair", неактивні/недоступні - курсор
default;
В ідеалі всі активні елементи повинні реагувати на наведення, не
доступні/неактивні – не повинні.
Клик по мітці (label) повинен переводити фокус у зв'язане поле.
Клікабельні елементи, призначення яких не очевидно, повинні бути
забезпечені підказками (title);
перевірка друку сторінки ( якщо було в технічному завданні);

56.

Тестування веб-проектів.
Доступність
Логотип на головній сторінці посиланням бути не повинен, на внутрішніх –
повинен.
Наявність favicon.ico.
Favicon (сокр. від англ. FAVorite ICON – «значок для вибраного») – значок
веб-сайта або веб-сторінки. Відображається браузером у вкладці перед
назвою сторінки, а також як картинка поруч із закладкою, у вкладках й в
інших елементах інтерфейсу.
Традиційно використалися зображення розміру 16×16 пікселів формату
ICO, поміщені в кореневий каталог сайту під ім'ям favicon.ico.
Підтримувані формати іконки сайту представлені в таблиці:
Браузер
ICO
Google Chrome
Так
Internet Explorer
5.0
PNG
GIF
4.0
4.0
Анімований GIF JPEG APNG
Немає
4.0
SVG
Немає Немає
Немає Немає
Немає
Немає Немає Немає
Firefox
1.0
1.0
1.0
Так
Так
3.0
Немає
Opera
7.0
7.0
7.0
7.0
7.0
9.5
9.6
Safari
Так
4.0
4.0
Немає
4.0
Немає

57.

Тестування веб-проектів.
Доступність
При відключених зображеннях написи (особливо логотип і головне меню
сайту) повинні залишатися читабельними, у всіх інформаційних картинок
повинні бути підписи акуратним невеликим сірим шрифтом (так, для img
можна задавати font – це зовнішній вигляд alt-тексту, що відображається
замість картинки). Картинки іноді відключають при використанні Інтернету,
що тарифікуються по трафіку (GPRS, роумінг).
Перевіряється в FF через плагін Web Developer -> Images -> Replace Images
With Alt Attributes.

58.

Тестування веб-проектів. Javascript
Перевірка, чи працює Javascript функціонал відповідно до технічного
завдання.
Перевіряється в FF через плагін:
WebDeveloper>Disable>DisableJavaScript>AllJavaScript;
Перевірка на Javascript помилки (firebug). Виконується в IE: при наявності
Javascript помилок у лівому нижньому куті екрана виводиться напис
«Виконано, але з помилками».
Перевірка працездатності при виключеному JavaScript. Критично важливий
функціонал повинен бути доступний без JS. JS може бути виключений
згідно корпоративних вимог безпеки. А в Opera Mini він працює тільки
перезавантаженням сторінки.
Сайт повинен зберігати нормальний вид, поки він вантажиться js-скрипти
ще не виконалися.
Якщо немає можливості реалізовувати функціонал без JS, потрібно виводити
повідомлення про необхідність його включити (реалізується через
<noscript>).

59.

Тестування веб-проектів.
Коректна робота при уведенні реального тексту:
Перевірка необхідна для того, щоб на сайті потім не виникли проблеми при
заповненні реальними даними.
Перевірка уведення й видалення даних. Уводиться багато й мало тексту.
Блоки з контентом міняються місцями.
Перевірка коректності роботи стилів. Уводиться текст із абзацами й без
абзаців, зі списками й картинками, таблицями й заголовками різних рівнів.
Виправлення вмісту сторінки робляться в FF через плагін Firebug:
HTML>Edit - міняємо/додаємо/видаляємо текст.
404-і запити
Перевірка на відсутність у верстці 404-х запитів (firebug).
Помилка 404 або Not Found («не знайдена») – стандартний код відповіді http
про те, що сервер був знайдений, але сервер не може знайти запитувану
сторінку або дані відповідно до запиту.

60.

Тестування веб-проектів.
Кросбраузерність
Перевіряється переглядом сайту в наступних браузерах:
Windows / Linux:
Microsoft Edge, Internet Explorer (8 і вище);
Mozilla Firefox (останній).
Google Chrome (останній);
Opera (останній).
MAC OS
iOS:
Safari.
Safari.
Android:
Browser;
Mozilla Firefox;
Google Chrome;
Opera mini.

61.

Тестування веб-проектів.
Кросбраузерність
На iPhone додатково необхідно перевірити відображення в
горизонтальному (landscape) і вертикальному (portrait) режимах.
Оскільки
перелік браузерів може бути досить великим,
достатньо обмежиться такими перевірками:
візуальна частина;
доступність;
Функціональність.
Для лінійки IE додатково перевіряються:
масштаб сторінки;
розширюваність;
рамки в елементів у фокусі;
не повинне бути Javascript помилок (лівий нижній кут).

62.

Тестування веб-проектів.
Інструментарій
JUnit – тестування додатків для Java
NUnit – порт JUnit під .NET
xUnit – тестування додатків для .NET
TestNG – тестування додатків для Java
Selenium
–
тестування
додатків
HTML;
підтримує
браузери Internet Explorer, Mozilla Firefox, Opera, Google
Chrome, очікується підтримка Safari.
WatiN – тестування веб-додатків; підтримує браузери Internet
Explorer, Mozilla Firefox
TOSCA Testsuite – тестування додатків HTML, .NET, Java, SAP
UniTESK – тестування додатків на Java, Сі.

63.

Функціональне тестування
Лекція 4
На функціональне
тестування може
виділятися до 90%
загального бюджету
тестування.

64.

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

65.

Функціональне тестування
складається з таких компонентів:
90% часу тестування;
перевірка функціональних вимог: логіки і бізнес-правил додатків
або системи;
повноцінне системне / функціональне тестування є найбільш
трудомістким процесом і може займати (Ф.Брукс) до 80% всього
бюджету проекту з тестування.

66.

Функціональне тестування:
Функціональне тестування (functional testing) – вид
тестування, при якому виявляється некоректна / неправильна
робота функціоналу програми.
Функціональне тестування (functional testing) – процес
перевірки відповідності поведінки системи спочатку
заявленим функціональним вимогам.
Функціональне тестування (functional testing) –
тестування ПЗ з метою перевірки реалізованості
функціональних вимог, тобто здатності ПЗ в певних умовах
вирішувати завдання, потрібні користувачам. Функціональні
вимоги визначають, що саме робить ПЗ та які завдання
вирішує.

67.

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

68.

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

69.

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

70.

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

71.

Тестування за ознакою
позитивності сценаріїв:
позитивний тестовий сценарій (positive testing scenarios)
використовує тільки коректні дані і перевіряє, що додаток
правильно виконав функцію, тобто покликаний показати, що
програма працює так, як і годиться, за умови, що користувач
вносить коректні дані і не виходить за рамки передбаченого
сценарію поведінки.
Основна мета – перевірка здатності системи працювати з
виконанням тих функцій, для яких розроблялася. Як правило,
перед початком тестування створюються тестові сценарії, які
передбачають коректне функціонування системи.

72.

Тестування за ознакою
позитивності сценаріїв:
негативний тестовий сценарій (negative testing scenarios)
призначений для перевірки сценаріїв, відмінних від коректного,
вхідних даних з одним або більше неправильних параметрів і т.д.
Основна мета – перевірка стійкості системи до впливів різного
роду, валідації невірного набору даних, перевірка обробки
виняткових ситуацій (як в реалізації програмних алгоритмів, так і
логікою бізнес-правил).
Негативне тестування додатків передбачає обробку сценаріїв, які
можуть статися з системою, наприклад: помилка користувача при
введенні даних. У даному випадку система повинна видати
повідомлення про помилку.

73.

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

74.

Типовий план тестування:
Вивчення документації.
Димове тестування (smoke testing) – перший прогін програми,
щоб зрозуміти чи працює вона взагалі.
Позитивне тестування – перевірка роботи програми при
отриманні "правильних" вхідних даних.
Негативне тестування включає наступні найбільш поширені
негативні тест кейси (negative test case):
• обов'язкове введення (Required Data Entry);
• типи даних полів (Field Type Test);
• розмір поля (Field Size Test);
• числові граничні значення (Numeric Bounds Test);
• граничні значення дати (Date Bounds Test);
• валідність дати (Date Validity);
• правила заповнення полів (Rules for filling fields);
• внутрішні одинарні лапки (Embedded Single Quote).

75.

Категорії функціональних тестів
Тести ініціалізації, реєстрації й авторизації (init / login /
logout).
для основного тесту ініціалізації в тестовому наборі додати
глобальні змінні, що використовуються у всіх тестах;
для основного тесту в наборі додати перевірку того, що
обов'язкові елементи форми в додатку присутні й доступні;
додати перевірку форми реєстрації / авторизації;
тести (шаблони) для всіх інших тестів, що розробляються
перед реалізацією основних перевірок, повинні містити
блок команд для коректного входу й виходу з додатка;
при
перевірці функціонала необхідно перевіряти
доступність кожного пункту для неавторизованого/
авторизованого користувача.

76.

Реєстрація

77.

Авторизація

78.

Категорії функціональних тестів
Функціональні CRUD-тести (Create, Read, Update, Delete)
для тестування інтерфейсу стандартних операцій зі
створення, читання, зміни, видалення елементів форми.
перевірка можливості додавання декількох різнотипних
елементів, з різних класів тестових даних;
перевірка можливості редагування доданих даних;
перевірка можливості видалення даних;
перевірка успішного оновлення даних.
Функціональні регресійні тести для перевірки коректності
виправлених дефектів і відсутності раніше наявних помилок.
перевірка всіх дефектів, зареєстрованих у системі bugтрекінга;
перевірки основних функцій системи, які мають критичний функціонал або впливають на логіку роботи додатка.

79.

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

80.

Категорії функціональних тестів
Функціональні негативні тести для перевірки коректної
обробки неправильно уведених даних (наприклад,
перевірка того, що при спробі уведення в текстове поле
занадто довгого рядка виводиться повідомлення про
помилку).
перевірка коректності обробки неприпустимих або
некоректних даних для операцій CRUD: при таких даних
програма не повинна допускати їхнього збереження,
редагування або оновлення в БД, а також не допускати
видалення даних, з якими є зв'язки, без попередньої
обробки цих зв'язків і т.п.;
перевірка повідомлень про некоректні дії користувача або
невірних вихідних даних.

81.

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

82.

Передбачуваний набір перевірок:
CRUD-тести:
додавання. Додаємо 3-4 елемента.
редагування. Редагуємо один зі створених елементів.
оновлення. Обновляємо дані.
видалення. Видаляємо всі створені елементи.
перевірка на відсутність помилок.
Після кожної з перерахованих дій, а також при відкритті
нових форм і діалогів перевіряємо на відсутність
помилок.

83.

Передбачуваний набір перевірок:
Позитивні тести:
довжина
полів. Перевіряємо, що в поля уведення
вводиться рядок максимально допустимої довжини.
ОДЗ полів. Актуально, наприклад, для математичних
функцій (cos x і т.д.) або конкретних обмежень (кількість
варіантів не більше 50 і т.д.)
відкриття списків, що випадають. Перевіряємо, що
списки, що випадають, при натисканні відкриваються.
вибор прапорців, перемикачів. Перевіряємо, що прапорці
й перемикачі вибираються.
сортування. Якщо немає можливості перевірити коректність сортування, то перевіряємо, що після сортування по
всіх наявних стовпцях не з’являється помилка.

84.

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

85.

Передбачуваний набір перевірок:
Негативні тести:
неактивність кнопок. Перевіряємо, що при невиконанні
обов'язкових умов, кнопки неактивні.
довжина полів. Перевіряємо, що в поля уведення не
вводяться рядки менше й більше мінімальної й
максимальної допустимої довжини.
ОДЗ полів. Перевіряємо, що в поля не вводяться
значення, що не входять до області допустимих (див.
аналогічний пункт у позитивних тестах).
помилки. Після уведення некоректних даних перевіряємо,
чи не з’явилася помилка. Це може бути виділення поля
червоним кольором, підказка, що вспливає, повідомлення
або об'єднання декількох повідомлень про помилку.

86.

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

87.

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

88.

Перевірка типових помилок
коректність відображення даних після відходу із вкладки й
повернення на неї (у т.ч. після оновлення даних).
нумерація рядків і полів записів.
область допустимих значень для математичних змінних
(наприклад, значення для cos від -1 до 1).
допустимі значення податкових/ фінансових/ банків-ських
номерів і скорочень (наприклад, інн – не більше 12 символів).
перевірка на те, що всі рядки відповідно обробляються (після
збереження повинні видалятися пробіли до пер-шого
значущого символу й після останнього значущого символу:
" Татарстан " => "Татарстан").
модальність діалогових вікон.
блокування
кнопок редагування/видалення в процесі
відкриття діалогів редагування або видалення відповідних
елементів (з метою запобігання повторного відкриття діалогів
або видалення).

89.

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

90.

Популярні негативні тест кейси
для веб-форм
обов'язкове уведення (Required Data Entry);
типи даних полів (Field Type Test);
розмір поля (Field Size Test);
числові граничні значення (Numeric Bounds Test);
граничні значення дати (Date Bounds Test);
валідність дати (Date Validity);
правила заповнення полів (Rules for filling fields);
внутрішні одинарні лапки (Embedded Single Quote).

91.

Процес розробки тестів перевірки
логіки роботи додатка в цілому
Скласти функціональну схему логіки роботи додатка: виділити основні типові форми й згрупувати їх за реалізованим
функціоналом (довідники, панель адміністратора, форми
уведення даних, форми для вивантаження даних тощо).
2. Створити комплекти шаблонів для тестів необхідних
категорій (файли "пустушки", що містять заголовки й
основну структуру тесту).
3. Розробник тесту вибирає для форми, що тестується,
відповідний їй шаблон і заповнює його перевірками,
необхідними для конкретної категорії тесту.
4. Окремі тест-кейси можна об'єднати в тестові набори,
виходячи з функціонала, що перевіряється.
1.

92.

Новинний модуль

93.

Пошук по сайту

94.

Зворотній зв’язок

95.

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

96.

Фотоальбом

97.

Форум

98.

Інтернет-магазин

99.

Валідні та невалідні дані:
При роботі з даними важливу роль відіграє валідація даних (data
validation). Перш ніж використовувати отримані від користувача
дані, необхідно переконатися, що дані введені правильно і
являють коректні значення.
Валідація (validation) – це процес перевірки даних на
відповідність певним, заздалегідь відомим правилам (форматам,
вимогам).

100.

Проблеми, що виникають при
відсутності валідації:
Неможливість відновитися після збою.
Додаткове навантаження на систему.
Ін'єкції не викликають збоїв.
Складність ідентифікації причини проблеми.

101.

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

102.

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

103.

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

104.

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

105.

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

106.

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

107.

Приклади тестування поля
логін/пароль
1. Реєстрація нового користувача:
з логіном new_user:
очікуваний результат: можна;
з логіном new_user_test:
очікуваний результат: можна;
з логіном new-user:
очікуваний результат: можна;
з логіном new1234user:
очікуваний результат: можна;

108.

з логіном new @ user:
очікуваний результат: негативна відповідь;
з логіном newuser і паролем newuser (повний збіг):
очікуваний результат: негативна відповідь;
використання тільки ASCII символів у логіні:
очікуваний результат: негативна відповідь;
з логіном new1234user:
очікуваний результат: можна;
з логіном, що містить пробіли або складається лише з
пробілів:
очікуваний результат: негативна відповідь;

109.

з паролем, що містить пробіли або складається лише з
пробілів:
очікуваний результат: негативна відповідь;
з логіном, що містить XSS або SQL injections:
очікуваний результат: негативна відповідь;
з логінами "admin" і "аdmin" (де а – з російської
розкладки)?
в деяких випадках перевіряють користувача в базі за
допомогою LIKE, і не обробляють user input. Тому
потрібно перевірити комбінацію %%% / %%% (знак %
повторюється 3 рази, щоб обійти валідацію на мінімальну
довжину).
логін під існуючим користувачем – зміна пароля:

110.

створити акаунт з максимально можливим числом символів
у логіні:
спробувати зайти в систему;
спробувати змінити пароль;
Причина: можлива розбіжність максимумів між рядками
введення нового пароля, введення пароля, зміни пароля, і в БД.
Додатково: виконати ті ж кроки, але з максимальною кількістю
символів + 1.
Додатково: виконати ті ж кроки, але з максимальною кількістю
дозволених символів + пробіл (та інші нешкідливі);

111.

З максимальною кількістю дозволених символів + 1
заборонений.
створити акаунт з максимально можливим числом
символом в паролі:
спробувати зайти в систему;
спробувати змінити пароль (і логін);
Причина: можлива розбіжність максимумів між рядками
введення нового пароля, введення пароля, зміни пароля, і в БД.

112.

Приклади тестування поля
логін/пароль
2. Введення некоректних даних.
ввести коректний логін і коректний пароль.
очікуваний результат: успішний вхід в систему.
вийти з системи, очистити кеш і куки (відкрити/закрити
браузер?);
залишити обидва поля порожніми і натиснути на кнопку
"Login":
очікуваний результат: негативна відповідь;
залишити порожнє поле "Login" і натиснути на кнопку
"Login":
очікуваний результат: негативна відповідь;

113.

залишити порожнє поле "Password" і натиснути кнопку
"Login":
очікуваний результат: негативна відповідь;
ввести коректний логін і некоректний пароль:
очікуваний результат: негативна відповідь;
ввести некоректний логін, але коректний пароль:
очікуваний результат: негативна відповідь;
ввести некоректний логін і некоректний пароль:
очікуваний результат: негативна відповідь.
в поле логіна ввести коректний пароль, в поле пароля ввести
коректний логін:
очікуваний результат: негативна відповідь;
ввести логін <script> alert (123) </ script> і коректний пароль:
очікуваний результат: негативна відповідь;

114.

Приклади тестування поля
логін/пароль
3. Зміна / видалення логінів
в базі або настройках сайту вказати, що термін придатності
певного логіна минув, увійти в систему під цим логіном:
очікуваний результат: негативна відповідь;
увійти в систему під коректним логіном / паролем, потім
змінити пароль та увійти в систему під новим паролем:
очікуваний результат: пароль змінений, можна зайти.

115.

зміна пароля і вхід під старим:
запам'ятати пароль;
увійти в систему;
поміняти пароль;
вийти з системи;
увійти в систему назад зі старим паролем:
очікуваний результат: негативна відповідь;

116.

увійти в систему під коректним логіном/ паролем,
перейменувати аккаунт і перезавантажити браузер:
увійти в систему під старим логіном/паролем:
очікуваний результат: негативна відповідь;
увійти в систему під новим логіном/паролем:
очікуваний результат: можна;
увійти в систему під коректним логіном / паролем, потім
видалити акаунт і перезавантажити браузер:
увійти в систему під старими логіном / паролем:
очікуваний результат: негативна відповідь;

117.

Формування простого чек-листа для
функціонального тестування:
Шапка
• Іконка і назва на вкладці
• Логотип
• Live Chat
• Twitter
• Facebook
• Like
Реєстрація/Авторизація
• Реєстрація користувача
• Авторизація користувача
• Анонімний користувач
• Відновлення пароля
• Редагування облікового запису
Статті
• Шаринг статтей у запропонованих
Фотогалереї
соціальних мережах
• Перегортання фото
• Відображення фото
• Коректний масштаб (якщо є)
• Коректний поворот фотографій (якщо є) • Коректність переходу за посиланнями
• Коректність повернення на головну
• Коректне відображення списку
сторінку
фотографій і фото

118.

Формування простого чек-листа для
функціонального тестування:
Особистий кабінет
Пошук
• Редагування анкети
• Пошук за новинами,
• Можливість видалення анкети
розділами
• Відображення статусу
• Перехід по посиланням
користувача
• Відображення дат новин
• Відображення статусу підписки
• Можливість
відмінити/підтвердити
Зворотній зв’язок
підписку
• Робота при правильному
• Вихід користувача із особистого
заповненні полів
кабінету
• Робота при неправильному
заповненні полів

119.

Тест-план
Лекція 5

120.

План лекції
Поняття тест-плану.
Приклад тест-плану.

121.

Поняття тест-плану
Тест план (Test Plan) – це документ, який описує обсяг робіт з
тестування, починаючи з опису об'єкта, стратегії, розкладу,
критеріїв початку і закінчення тестування, до необхідного в
процесі роботи обладнання, спеціальних знань, а також оцінки
ризиків з варіантами їх вирішення.
Шаблони тест планів від RUP (Rational Unified Process) і стандарт
IEEE 829:
Test Plan Template RUP;
Test Plan Template IEEE 829.

122.

Поняття тест-плану
Якісний тест-план повинен як мінімум відповідати на такі
питання:
Що треба тестувати?
Що будете тестувати?
список функцій і опис системи та її компонент.
Як будете тестувати?
опис об'єкта тестування: системи, додатки, обладнання.
стратегія тестування, а саме: види тестування та їх застосування по
відношенню до об'єкту, що тестується.
Коли будете тестувати?
послідовність проведення робіт: підготовка (Test Preparation), тестування
(Testing), аналіз результатів (Test Result Analysis) у розрізі запланованих
фаз розробки.

123.

Поняття тест-плану
Якісний тест-план повинен як мінімум відповідати на такі
питання:
Критерії початку тестування:
Критерії закінчення тестування:
готовність тестової платформи (тестового стенда);
закінченість розробки необхідного функціоналу;
наявність необхідної документації.
результати тестування задовольняють критеріям якості продукту;
вимоги до кількості відкритих багів виконані;
витримка певного періоду без зміни початкового коду програми Code
Freeze (CF);
витримка певного періоду без відкриття нових багів Zero Bug Bounce
(ZBB).
Хто буде тестувати.

124.

Поняття тест-плану
Додаткові пункти:
оточення системи, що тестується;
необхідне для тестування обладнання та програмні засоби;
ризики та їх вирішення.
Види тест планів:
Майстер Тест План (Master Plan or Master Test Plan).
Тест План (Test Plan) – детальний тест план.
План приймальних випробувань (Product Acceptance Plan).
Список учасників проектної групи, які повинні затвердити
тест-план:
Ведучий тестувальник.
Тест менеджер (менеджер з якості).
Керівник розробки.
Менеджер Проекту.

125.

Чек-лист
Лекція 6

126.

План лекції
Поняття чек-листа
Приклади чек-листів

127.

Поняття чек-листа
Контрольний список (перелік, таблиця, карта; англ.
checklist) – список факторів, властивостей, параметрів,
аспектів, компонентів, критеріїв або задач, структурованих
особливим чином з метою досягнення поставлених задач.
Чек-лист – це документ, який описує, що необхідно
тестувати. Чек-лист може бути виконаний з різним рівнем
деталізації, рівень якої залежить від вимог до звітності, рівня
знання продукту співробітниками та складності продукту.
Мета створення чек-листа:
структуризація перевірок;
запам’ятовування необхідних перевірок;
поділ задач за рівнем кваліфікації;
збереження звітності та результатів тестування.

128.

Поняття чек-листа
Структура чек-листа
список перевірок (з потрібним рівнем деталізації);
статус
перевірок (Пройдено, помилка, не виконано,
заблоковано або Pass (ОК), Fail, Blocked, Not run);
платформа, на якій проводилося тестування (операційна
система, збірка, браузер тощо);
тестове середовище; тестувальник.
Інструменти ведення чек-листів:
таблиці Excel/OpenOffice для самостійної роботи;
таблиці GoogleDocs для розподіленої роботи;
Sitechco для командної роботи та версійності.

129.

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

130.

Тест-дизайн
Лекція 7

131.

План лекції
Основні поняття тест-дизайну.
Тест-кейси.

132.

Основні поняття тест-дизайну
Тест-дизайн – етап процесу тестування ПЗ, на якому проектуються й створюються тестові випадки (тест-кейси), відповідно до
визначених раніше критеріїв якості й мети тестування.
Елементи тест-дизайну:
аналіз наявних ресурсів проекту: документація (специфікації,
вимоги, плани), моделі, код, що виконується, тощо;
написання специфікації по тест-дизайну (Test Design
Specification);
проектування й створення тестових випадків (Test Cases).

133.

Основні поняття тест-дизайну
Основні поняття тест-дизайну:
Тестовий випадок (Test Case) – це сукупність кроків,
конкретних умов і параметрів, необхідних для перевірки
реалізації функції, що тестується, або її частини.
Тестовий набір (Test Suite) – набір тестів, що реалізують
бізнес-задачу, що виконується системою. Тестовий набір
включає крім тестових сценаріїв ще й тестові дані або правила
їхньої генерації.
Системи управління тест-кейсами (test case management):
TestLink (безкоштовна), TestRail, TestStuff, TestLodge,
PractiTest, Klaros-Testmanagement, TestCollab, RedCase плагиін
для Redmine (безкоштовна) тощо.

134.

Тестові випадки
Підходи до написання тестових випадків:
покриття вимог (Requirements Coverage) – покриття тестами
функціональних і нефункціональних вимог до продукту
(«чорний ящик»).
покриття коду (Code Coverage) – покриття тестами коду, що
виконується («білий ящик»).
Види тестових випадків: Тест-кейси розділяються
очікуваним результатом на позитивні й негативні.
за

135.

Структура тестових випадків
Назва (titul)
Включає унікальний номер тесту та змістовну назву, яка вказує
на мету перевірки. Може включати вказання на вид тест-кейсу
(позитивний, негативний).
Передумови
PreConditions
Список дій, які приводять систему до стану, придатного для
проведення основної перевірки. Або список умов, виконання
яких говорить про те, що система перебуває в придатному для
проведення основного тесту стані.
Опис кроків
Steps
Список дій, що переводять систему з одного стану в інший,
для одержання результату, на підставі якого можна зробити
висновок про задоволення реалізації поставленим вимогам
Результати
Results
Післяумови
PostConditions
Список очікуваних результатів
Список дій, що переводять систему в первісний стан (стан до
проведення тесту – initial state)

136.

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

137.

Приклад тестових випадків
001. Перевірка відображення сторінки (+)
Дія
Відкрити сторінку
"Вхід у систему"
Очікуваний результат
- Вікно "Вхід у систему" відкрито.
- Назва вікна – Вхід у систему.
- Логотип компанії відображається в правому верхньому
куті.
- На формі 2 поля - Ім'я й Пароль.
- Кнопка Вхід доступний.
- Посилання "забув пароль" – доступні.

138.

Приклад тестових випадків
Завдання – протестувати функціональність форми прийому
заявок, вимоги до якої надані в наступній таблиці:
Елемент
Тип елемента
Вимоги
Тип обігу
combobox
Набір даних (Консультація, Проведення тестування,
Розміщення реклами, Помилка на сайті)
Контактна
особа
Editbox
1. Обов'язкове для заповнення
2. Максимально 25 символів
3. Використання цифр і спец символів не допускається
Контактний
телефон
editbox
1. Обов'язкове для заповнення
2. Припустимі символи "+"( на початку номера) і цифри
3. Допустимі формати:
o починається із плюса - 11-15 цифр, наприклад:
+31612361264, +375291438884
o без плюса - 5-10 цифр, наприклад:
0613261264, 2925167
Повідомлення text area
1. Обов'язкове для заповнення
2. Максимальна довжина 1024 символу
Відправити
Стан:
1. За замовчуванням – не активна (Disabled).
2. Після заповнення обов'язкових полів стає активна (Enabled).
Дії після натискання:
1. Якщо уведені дані коректні – відправлення повідомлення.
2. Якщо уведені дані НЕ коректні – відповідне повідомлення.
Button

139.

Приклад тестових випадків
Приклад позитивного тест кейса для даної форми:
001. Перевірка форми відправлення повідомлення при заповненні коректними даними (+)
Дія
Очікуваний результат
1. Відкриваємо форму відправлення
повідомлення
Форма відкрита
Всі поля за замовчуванням порожні
Обов'язкові поля позначені - *
Кнопка "Відправити" не активна
2. Заповнюємо поля форми:
Тип обігу = Консультація
Контактна особа = йцукенгшщзйе
Контактний телефон =
+79161111211
Повідомлення = рлпордп
Поля заповнені
Кнопка "Відправити" – активна (Enabled)
3. Натискаємо кнопку "Відправити"
Повідомлення
"Заявка
відправлена"
виведене на екран.
Нова заявка з'явилася в списку на сторінці
"Заявки".

140.

Приклад тестових випадків
Приклад негативного тест кейса для даної форми:
Дія
Очікуваний результат
1. Відкриваємо форму відправлення
повідомлення
2. Заповнюємо поля форми:
Тип обігу = Консультація
Контактна особа
= @#$%^&;.?,>|\/№"!()_{}[<~
Контактний телефон = (916)33333-33
Повідомлення = йццуйцуйц(...)йцу
- 1024 символа
3. Натискаємо кнопку "Відправити"
Форма відкрита
Всі поля за замовчуванням порожні
Обов'язкові поля позначені - *
Кнопка "Відправити" не активна
Поля заповнені
Кнопка "Відправити" - активна (Enabled)
Повідомлення про помилки виведено на екран:
"У полі "Контактна особа" заборонене
використання цифр і спец. символів."
Заявка НЕ з'явилася в списку на сторінці
"Заявки".

141.

Приклад тестових випадків. Testlink

142.

Приклад тестових випадків. Testlink

143.

Види тестування
Лекція 9

144.

План лекції
Етапи процесу тестування.
Види тестування.

145.

Етапи процесу тестування:
Планування тестування – процес встановлення та організації
процесу тестування.
Результат: тест-план.
План тестування (Test Plan) – це документ, що описує
весь обсяг робіт з тестування, починаючи з опису об'єкта,
стратегії, розкладу, критеріїв початку й закінчення
тестування, до необхідного в процесі роботи устаткування,
спеціальних знань, а також оцінки ризиків з варіантами
їхнього вирішення.
Проектування тестів.
Результат: Набір тест-кейсів і тестових наборів.
Набір тест-кейсів і тестів (Test Case, Test suite) – це
послідовність дій, за якою можна перевірити, чи
відповідає функція, що тестується, встановленим вимогам.

146.

Етапи процесу тестування:
Реалізація тестів.
Результат: Звіти по дефектах.
Дефект / звіт з дефекту (Bug Report / Defect) – це
документи, що описують ситуацію або послідовність дій,
що призвела до некоректної роботи об'єкта тестування,
із вказанням причин й очікуваного результату.
Аналіз результатів тестування й написання звітів.
Результат: Звіт за результатами тестування.

147.

Класифікація видів тестування
За ступенем автоматизації:
ручне тестування (manual testing);
автоматизоване тестування (automated testing);
напівавтоматизоване тестування (semiautomated testing).
Ручне тестування – це процес пошуку дефектів в роботі
програми, коли виконання тестів відбувається без використання
програм, що автоматизують роботу тестувальника. Приклад
реєстрація нового користувача в програмі електронної пошти.
Автоматизоване тестування програмного забезпечення –
частина процесу тестування, яка використовує програмні засоби
для виконання тестів і перевірки результатів виконання, що
допомагає скоротити час тестування і спростити його процес.

148.

Класифікація видів тестування
Основні підходи до автоматизації тестування:
тестування на рівні коду, до якого належить, зокрема, модульне
тестування.
GUI-тестування – імітація дій користувача за допомогою
спеціальних тестових фреймворків.
Техніки GUI-автоматизації:
Утиліти запису і відтворення (capture/playback tools)
записують дії тестувальника під час ручного тестування. Вони
дозволяють виконувати тести без прямої участі людини протягом тривалого часу, збільшуючи продуктивність і усуваючи
повторення одноманітних дій під час ручного тестування.
Сценарії (Scripting) – форма програмування на мовах,
спеціально розроблених для автоматизації тестування ПЗ.

149.

Класифікація видів тестування
Техніки GUI-автоматизації (продовження):
Data-driven testing – методологія, яка використовується в
автоматизації тестування. Особливістю є те, що тестові
скрипти виконуються і верифікуються на основі даних, які
зберігаються в центральному сховищі даних або БД.
Keyword-based автоматизація передбачає поділ процесу
створення кейсів на 2 етапи: етап планування та етап
реалізації.
Напівавтоматизоване тестування – поєднання ручного
подходу з автоматизованим. Передбачається, що автоматизація
застосовується для окремих елементів (автоматизація розгортки
оточення, функціонального тестування, генерації даних тощо).

150.

Класифікація видів тестування
За ознакою позитивності сценаріїв:
позитивне тестування (positive testing);
негативне тестування (negative testing).
Позитивний тестовий сценарій використає тільки коректні
дані й перевіряє, що додаток правильно виконав викликану
функцію, тобто покликаний показати, що програма працює
так, як треба, за умови, що користувач вносить коректні дані й
не виходить за рамки передбаченого сценарію поведінки.
Негативний тестовий сценарій призначений для перевірки
сценаріїв, відмінних від коректного, вхідних даних з одним або
більше неправильних параметрів тощо. Основна мета
виконання таких тестів – переконатися, що система прийнятно
реагує на виняткові ситуації й не викликає функцію при
неправильних вхідних даних.

151.

Класифікація видів тестування
За ступенем підготовленості до тестування:
тестування за документацією (formal testing);
Ad-hoc (інтуїтивне) тестування (ad hoc testing);
Дослідницьке тестування(exploratory).
Тестування за документацією – проводиться за заздалегідь
підготовленими даними (тест-кейси, чек-листи, чит-листи,
специфікація тощо).
Ad-hoc тестування (лат. «по місцю», означає «до цього, для
даного випадку, для даної мети») – імпровізоване тестування без
попередньої підготовки. Таке тестування проводиться при
повній відсутності документації, без плану і мети.

152.

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

153.

Класифікація видів тестування
За часом проведення тестування:
Альфа-тестування (alpha testing):
тестування при прийманні (smoke test, sanity test,
confidence test);
тестування нової функціональності (new feature testing);
регресійне тестування (regression testing);
тестування при здачі (acceptance testing, certification
testing);
Бета-тестування (beta testing).
Альфа-тестування – тестування до передачі користувачу.
Бета-тестування – тестування після передачі користувачу.

154.

Класифікація видів тестування
Санітарне тестування (Sanity) – вузьконаправлене тестування, достатнє
для доказу того, що конкретна функція працює згідно заявлених у
специфікації вимог. За результатами робиться висновок про те, приймається чи ні ПЗ на тестування / експлуатацію / постачання замовнику.
Димове тестування (Smoke) – спрямоване на поверхневу перевірку всіх
модулів програми на предмет працездатності та наявність швидко
встановлюваних критичних і блокуючих дефектів. За результатами
робиться висновок про те, приймається чи ні ПЗ на тестування /
експлуатацію / постачання замовнику.
Регресійне тестування (Regression) спрямоване на перевірку змін,
зроблених у додатку або навколишньому середовищі, для підтвердження того факту, що існуюча функціональність працює як і раніше.
Приймальне тестування (Acceptance) – формальний процес тестування, який перевіряє відповідність системи вимогам і проводиться з метою
визначення, чи задовольняє система приймальним критеріям; рішення
замовником або уповноваженою особою, приймається додаток чи ні.

155.

Класифікація видів тестування
За знанням внутрішньої структури системи:
тестування чорного ящика (black box testing);
тестування білого ящика (white box або glass box testing);
тестування сірого ящика (gray box testing).
Чорний ящик. Тести конструюються без знання про
внутрішню структуру системи. Вони зазвичай базуються на
функціональних вимогах на основі зовнішніх специфікацій
програм і модулів, або специфікацій сполучення програми або
модуля. Програма при цьому розглядається як чорний ящик,
логіка програми до уваги не приймається. Сутність підходу –
перевірити, чи відповідає програма зовнішнім специфікаціям.

156.

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

157.

Класифікація видів тестування
За ступенем ізольованості компонентів:
компонентне (модульне) тестування (component / unit testing);
інтеграційне тестування (integration testing);
системне тестування (system / end-to-end testing).
Модульне тестування (юніт-тестування) відноситься до тестів,
які перевіряють функціональність певного розділу. При цьому
тестується мінімально можливий для тестування компонент,
наприклад, клас або функція. Часто модульне тестування
здійснюється розробниками під час роботи над кодом (стиль
«білої скриньки»), щоб впевнитись, що функція працює згідно
вимог. Модульне тестування може включати статичний аналіз
коду, аналіз потоку даних, аналіз метрик, експертні оцінки коду,
аналіз покриття коду та інші методи.
Юніт-тестування дає змогу усунути близько 70% помилок.

158.

Класифікація видів тестування
Інтеграційне тестування тестує інтерфейси між компонентами або підсистемами та взаємодію інтегрованих компонентів
(модулів). Компоненти можуть бути інтегровані як в рамках
ітеративного підходу, так і всі разом. За наявності резерву часу
тестування ведеться ітераційно, з поступовим підключенням
наступних підсистем. Інтеграційне тестування проводиться до
тих пір, поки групи тестованих компонентів ПЗ, які відповідають потрібній архітектурі, починають працювати як система.
Рівні інтеграційного тестування:
компонентний інтеграційний рівень (Component Integration
testing) – перевіряється взаємодія між компонентами системи
після проведення компонентного тестування;
системний інтеграційний рівень (System Integration Testing) –
перевіряється взаємодія між різними системами після проведення системного тестування.

159.

Класифікація видів тестування
Підходи до інтеграційного тестування:
знизу вгору (Bottom Up Integration). Усі низькорівневі
модулі, процедури або функції збираються воєдино і потім
тестуються. Після чого збирається наступний рівень модулів
для інтеграційного тестування. Підхід корисний, якщо всі
модулі розроблюваного рівня готові.
зверху вниз (Top Down Integration). У першу чергу тестуються компоненти верхнього рівня ієрархії з використанням
заглушок замість компонентів більш низького рівня;
великий вибух ("Big Bang" Integration). Усі або практично
усі розроблені модулі збираються разом у вигляді закінченої
системи або її основної частини, і потім проводиться
інтеграційне тестування. Такий підхід дуже хороший для
збереження часу. Проте, якщо тест-кейси та їх результати
записані не вірно, процес інтеграції дуже ускладниться.

160.

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

161.

Класифікація видів тестування
Види QoS тестів, які включаються в системне тестування
(продовження):
Безперервне навантажувальне тестування – визначає
рівень безперервного навантаження, при якій система
відмовляє.
Конфігураційне тестування – визначає максимальну й
мінімальну конфігурацію апаратного й програмного
забезпечення, при яких зберігається працездатність ПЗ.
Тестування на сумісність – виявляє ті області, де система
несумісна з аналогом або попередньою версією. Це
стосується ПЗ, програмних інтерфейсів, структур даних й
язикових аспектів, класів і системних перетворень
Тестування на безпеку – визначає слабкі місця, які
дозволяють здійснити несанкціонований доступ до
інформації або дії по руйнуванню системи.

162.

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

163.

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

164.

Класифікація видів тестування
За об’єктом тестування:
функціональне тестування (functional testing);
тестування
на основі
характеристик якості
(QoStesting).
сервісу
Функціональне тестування перевіряє коректність і повноту
реалізації набору основних функцій програмної системи.
Тестування на основі
характеристик якості сервісу
(QoStesting) включає такі перевірки:
основних показників надійності програми, у т.ч. безвідмовність, готовність, відновлюваність;
основних показників продуктивності, у т.ч. навантажувальне
тестування або на час реакції (load/stress/performance testing);
споживання обчислювальних ресурсів, у т.ч. на предмет
витрати й втрат оперативної пам'яті (memory leaks testing);

165.

Класифікація видів тестування
на сумісність (compatibility testing) з попередніми версіями,
різновидами апаратури й системне ПЗ. При тестуванні вебПЗ при перевірці на сумісність додатково виділяють кросбраузерне тестування (cross-browser testing) – з різними
браузерами, і крос-платформне тестування (cross-platform
testing) – з різними операційними системами;
тестування на практичність системи, включаючи перевірки
на легкість навчання роботі із системою, ефективність
використання, мінімізація наслідків помилок, допущених
користувачем при роботі із системою, адаптація до потреб
користувача, ступінь довіри користувача до правильності
роботи із системою (usability testing);
тестування безпеки (security testing);
тестування інтерфейсу користувача, включаючи локалізацію
(UI-testing).

166.

Блок-схема процесу тестування
Розробка та
виправлення багів
Нова версія ПЗ
Димове
тестування
Димове
тестування
успішне
ні
так
Санітарне та регресійне
тестування
Автоматизоване
тестування
Дослідницьке
тестування
Звіт з багів
ні
Продукт
готовий?
так
Підготовка
релізу

167.

Техніки тест дизайну
Лекція 8

168.

Основні техніки
Еквівалентний розподіл (Equivalence Partitioning). Як
приклад, у вас є діапазон припустимих значень від 1 до 10,
ви повинні вибрати одне вірне значення усередині
інтервалу, наприклад, 5, і одне невірне значення поза
інтервалом – 0.
Аналіз граничних значень (Boundary Value Analysis).
Якщо взяти приклад вище, як значення для позитивного
тестування виберемо мінімальну й максимальну границі (1 й
10), і значення більше й менше границь (0 й 11). Аналіз
граничних значень може бути застосований до полів,
записів, файлів, або до будь-якого роду сутностей, що
мають обмеження.

169.

Основні техніки
(Cause/Effect Analysis): уведення комбінацій умов (причин),
для одержання відповіді від системи (Наслідок). Наприклад, ви
перевіряєте можливість додавати клієнта, використовуючи певну
екранну форму. Для цього вам необхідно буде ввести кілька
полів, таких як "Ім'я", "Адреса", "Номер Телефону" а потім,
нажати кнопку "Додати", – це "Причина". Система додає клієнта
в базу даних і показує його номер на екрані – це "Наслідок".
Передбачення помилки (Error Guessing). Тестувальник з
досвідом шукає помилки без методів, але при цьому він підсвідомо використовує метод припущення про помилку. Тестаналітик використовує свої знання системи й здатність до
інтерпретації специфікації, щоб "угадати", при яких вхідних
умовах система видасть помилку. Наприклад, специфікація говорить: "користувач повинен увести код". Тест-аналітик думає:
"Що, якщо я не введу код або введу неправильний код?".

170.

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

171.

Еквівалентний розподіл
Виділення класів еквівалентності є евристичним, однак
існує ряд правил:
Якщо вхідна умова описує область значень, наприклад «Ціле
число приймає значення від 0 до 999», то існує один
правильний клас еквівалентності й два неправильних.
Якщо вхідна умова описує число значень, наприклад «Число
рядків у вхідному файлі лежить в інтервалі (1..6)», то також існує
один правильний клас і два неправильних.
Якщо вхідна умова описує множину вхідних значень, то визначається кількість правильних класів, рівна кількості елементів у
множині вхідних значень. Якщо вхідна умова описує ситуацію
«повинне бути», наприклад «Перший символ повинен бути
заголовним», тоді один клас правильний й один неправильний.
Якщо є підстава вважати, що елементи усередині одного класу
еквівалентності можуть програмою трактуватися по-різному,
необхідно розбити даний клас на підкласи..

172.

Еквівалентний розподіл. Приклади
Перевірка поля, в яке можна ввести ціле число в діапазоні 1 ...
1000. Які класи еквівалентності можна виділити?
Клас
Значення
Вид тесту
1
0
Негативний
2
1, 500, 1000
Позитивний
3
1001, 2000
Негативний
Розмір оплати за електроенергію залежить від витраченого
обсягу:
Категорії споживачів
1. Електроенергія, що відпускається:
1.1. Населенню (у тому числі, яке проживає в житлових
будинках, обладнаних кухонними електроплитами):
за обсяг, спожитий до 100 кВт·год електроенергії на місяць
(включно)
за обсяг, спожитий понад 100 кВт·год до 600 кВт·год
електроенергії на місяць (включно)
за обсяг, спожитий понад 600 кВт·год електроенергії на місяць
Тарифи на електроенергію за 1 кВт·год, коп.
36,6
63
140,7

173.

Еквівалентний розподіл. Приклади
Виділяємо такі класи еквівалентності:
Категорії споживачів
Тарифи на електроенергію за 1 кВт·год, коп.
1. Електроенергія, що відпускається:
1.1. Населенню (у тому числі, яке проживає в житлових
будинках, обладнаних кухонними електроплитами):
за обсяг, спожитий до 100 кВт·год електроенергії на місяць
(включно)
за обсяг, спожитий понад 100 кВт·год до 600 кВт·год
електроенергії на місяць (включно)
за обсяг, спожитий понад 600 кВт·год електроенергії на місяць
Клас
Значення
36,6
63
140,7
Тариф
1
0 сума 100
36,6
2
100<сума 00
63
3
600<сума
140,7
4
-5, 5.5, букви, спецсимволи
-

174.

Аналіз граничних значень
Граничні умови – це ситуації, що виникають на вищих і
нижніх границях вхідних класів еквівалентності.
Аналіз граничних значень відрізняється від еквівалентної
розбивки наступним:
Вибір будь-якого елемента в класі еквівалентності в якості
представницького здійснюється таким чином, щоб перевірити
тестом кожну границю цього класу.
При розробці тестів розглядаються не тільки вхідні значення
(простір входів), але й вихідні (простір виходів).
Аналіз граничних значень, якщо він застосований правильно,
дозволяє виявити велику кількість помилок. Однак визначення
цих границь для кожного завдання може бути окремим важким
завданням. Також цей метод не перевіряє комбінації вхідних
значень.

175.

Аналіз граничних значень
Існує декілька правил:
Побудувати тести з неправильними вхідними даними для
ситуації незначного виходу за межі області значень. Якщо
вхідні значення повинні бути в інтервалі [-1.0.. +1.0],
перевіряємо -1.0, 1.0, -1.000001, 1.000001.
Обов'язково писати тести для мінімальної й максимальної
границі діапазону.
Використати перші два правила для кожного із вхідних значень
(використати пункт 2 для всіх вихідних значень).
Якщо вхід і вихід програми представляє впорядковану
множину, зосередити увагу на першому й останньому
елементах списку.

176.

Аналіз граничних значень.
Приклади
Таблиця класів еквівалентності з урахуванням граничних
значень до прикладу 2:
Клас
Значення
Тариф
1
0
0.1
50
99.9
100
36,6
2
100.1
300
599.9
600
63
3
1000
140,7
4
-5, 5.5, букви,
спецсимволи
Негативний тест

177.

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

178.

179.

180.

Інструменти тестування
Для автоматизації тестування рекомендується використовувати:
Selenium, RobotFramework – інструменти для створення
наборів функціональних тестових скриптів для перевірки webдодатків.
Apache JMeter – інструмент для проведення навантажувального тестування й зняття кількісних показників навантаження
на сервер.
ZeNmap, XSpider, Metasploit – сканери безпеки для
дослідження топології мережі, пошуку вразливостей у мережній
інфраструктурі додатка і їхньої експлуатації.
Acunetics WVS, інструментарій OWASP LiveCD – сканер й
аналізатор логіки роботи web-додатків, пошуку вразливостей у
додатку, і інструменти для тестування web-додатків.

181.

Тестування мобільних додатків
Лекція 10

182.

План лекції
Основні поняття
Етапи розробки мобільних додатків
Поняття прототипу та мокапу
Види тестування мобільних додатків
Що тестується
Установка мобільних додатків
Зняття креш-логів та скриншотів/відео на мобільних
пристроях
Емулятори мобільних пристроїв
Автоматизація тестування для Android

183.

Основні поняття
Мобільний додаток – це спеціально розроблений додаток
під конкретну мобільну платформу (Android, iOS тощо).
Мобільний веб-сайт – сайт, адаптований для перегляду й
функціонування на мобільному пристрої.

184.

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

185.

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

186.

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

187.

Статистика мобільних платформ
Android поширена в європейських країнах, країнах Африки,
Азії, Південної Америки. Таке поширення обумовлено тим, що
під Android щодня пишуть тисячі зручних додатків.
iOS, розроблена Apple, широко поширена в англомовних
країнах: Канаді, Австралії, США, Великій Британії, Ірландії.
Також iOS випереджає Android у Японії та Південній Кореї.

188.

Статистика використання мобільних
пристроїв

189.

Етапи розробки мобільних
додатків
Розробка технічної
документації
Розробка інтерфейсу
користувача
Створення концепції
дизайну
Малювання екранів
Розробка
Тестування
Налагодження
Регресійне тестування
Створення іконки додатка
Запуск в магазині мобільних
додатків. Публікація додатка в
магазині включає:
завантаження файлу
додатка;
розміщення
інформаційних матеріалів;
розгляд додатка
адміністрацією й
прийняття його в магазин
Тестування нових версій +
регресійне тестування

190.

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

191.

Поняття прототипу

192.

Поняття мокапу
Mockup або mock-up (макет) –
непрацююча модель, яка виконана в
натуральну величину й виглядає так,
так, як буде виглядати працюючий
екземпляр.
Приклад:
Зроблена у Photoshop веб-сторінка,
віддана на верстку, – це мокап.
Мокапи
можуть
бути
відносно
динамічними й інтерактивними.

193.

Види тестування мобільних
додатків
Тестування оновлень – часті оновлення системи призводять до
необхідності оновлювати додаток. Слід виконувати тестування
оновлень програми і на стороні сервера, перевіряти шляху
установки програми (WiFi, шнур, Bluetooth, SD).
Тестування інтернаціоналізації дозволяє на ранньому етапі
процесу розробки мобільного ПЗ переконатися в підтримці
інтернаціоналізації – головним чином, у мовній підтримці.
Можуть виникнути проблеми, пов'язані з нестачею вільного
простору на екрані або, наприклад, форматуванням дат.
Тестування зручності користування (usability) виявляє частини
програми, які недостатньо привабливі або викликають труднощі
в навігації / використанні, переконатися, що споживання ресурсів
додатком відповідає цільовій аудиторії. Наприклад, офісні
додатки не повинні викликати надмірне споживання енергії.

194.

Види тестування мобільних
додатків
Тестування мобільності зазвичай включає перевірку функцій
геолокації, даних, профілів і API. Приміром, мобільний додаток
для мандрівників повинен відображатися з урахуванням місця
розташування користувачів. Тестування мобільності направлено
на перевірку якості функціонування системи визначення місця
розташування, оцінку даних і поведінки системи.
Тестування навантаження – спостереження за використанням
пам'яті і системних ресурсів; крім того, тестування навантаження
дозволяє виявити "вузькі" місця в додатку, пов'язані з
продуктивністю, а також витоки пам'яті.
Випадкове тестування (monkey testing, стрес-тест) – додаток
повинен коректно реагувати на виникнення випадкових і непередбачуваних подій, наприклад, незаблокований комунікатор в
кишені.

195.

Види тестування мобільних
додатків
Мультиплатформене і мультідевайсне тестування – додаток
повинен правильно працювати на всіх конфігураціях пристроїв
на всіх пристроях, для яких розроблялося.
Лабораторне тестування – імітація реальних умов якості
зв'язку.
Атестаційне тестування використовується для підтвердження
відповідності додатку стандартам, ліцензійними угодами та
умовами використання:

196.

Що тестується
Розмір екрану і touch-інтерфейс:
Підтримка горизонтального (landscape) та вертикального
(portrait) режимів

197.

Що тестується
Розмір екрану і touch-інтерфейс:
Всі елементи повинні бути такого розміру, щоб користувач
міг однозначно потрапити по ним.
–
+
+

198.

Що тестується
Розмір екрану і touch-інтерфейс:
Відсутність порожніх екранів в додатку (або опускаємо такі
екрани, або пишемо на них пояснювальний текст для
першого відкриття).
Швидкість відгуку елементів повинна бути досить високою
(використовувати старі пристрої, якщо підтримуються
додатком).
У всіх елементів, що натиснуті, має бути натиснутий стан
(відгук на дію).

199.

Що тестується
Ресурси телефону:
Витікання пам'яті. Особливо може проявлятися на вікнах, з
великою кількістю інформації (довгі списки як приклад), під
час завдань з тривалим workflow (коли користувач довго не
виходить з програми), при некоректно працюючому
кешуванні зображень.
Збереження даних у кеш (сесії або синхронізація даних).
У мобільних браузерах принцип роботи кеша аналогічнийі
десктопной версії і її чищення можливе в: Настройки>Приложения->приложение->кнопка Clear cache.
Невистачання місця для установки або роботи програми.
Установка на карту SD.
Перевірка роботи батареї (акумулятора)

200.

Що тестується
Різні розширення екрану і версії ОС:
Ретинові і неретинові екрани. На ретинових екранах
елементи інтерфейсу / текст будуть дрібніше. Картинки для
ретина-екрану можуть потрапити в Неретина версію і тоді
будуть дуже великими.
Версії
ОС. Додаток не має встановлюватися на
непідтримувані пристрої, обов'язкова перевірка на всіх
можливих з підтримуваних девайсів (повні тести на
ретинової і неретінових версіях з останніми прошивками,
додаткові перевірки на девайсах з іншими прошивками).
Різні функції на девайсах: відсутність / наявність камери
(автофокусу), відсутність / наявність GPS.
Підтримка необхідних медіа-файлів даною моделлю і ОС,
тому що окремі розробники можуть урізати підтримку
роботи з деякими форматами.

201.

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

202.

Що тестується
Інтернаціоналізація:
Перевірка коректності перекладу.
Перевірка того, що всі написи входять у відповідні форми,
кнопки і т.п.
Перевірка форматів дат.
Перевірка роздільників в числах (між розрядами і між цілою і
дробовою частиною).
Постійний зворотний зв'язок з користувачем:
Реакція кнопок на натискання.
Повідомлення при завантаженні контенту / прогрес-бар.
Повідомлення при помилку доступу до мережі.
Повідомлення при спробі видалити важливу інформацію.
Наявність екрану / повідомлення при закінченні процесу /
гри.
Наявність і синхронність звукових і вібраційних повідомлень
з повідомленнями на екрані.

203.

Що тестується
Оновлення:
Переконатися, що підтримуються ті ж версії ОС, що і
попередня версія (якщо нова версія додатка використовує
нові можливості ОС, то для старих підтримуваних версій
ОС необхідно створення урізаною версією додатки).
Перевірка адекватного відновлення (зберігаються всі дані
користувача тощо).
Мультиплеєрні ігри:
Коректність підключення гравців (напр., списування балансу
лише після підключення).
Часові лаги.
Підключення через різні мережі.
Коректна поведінка при відключенні гравців.
Атестаційне тестування.

204.

Установка мобільних додатків
Додатки до запуску в магазині можуть бути встановлені
через:
Wi-Fi
кабель (шнур),
-Bluetooth
використовуючи PC
-SD-карти пам'яті

205.

Мобільні додатки. Креш-логи
Креш-лог (crash log) – файл, у якому зберігається вся
технічна інформація з помилки непрацездатності/екстреного
завершення роботи програми.
У термінології програмування критична помилка, що
приводить до аварійного завершення програми («падіння»),
також називається крешем або «крашем» (від англ. crash).
Опис бага:
Серйозність: Critical
Актуальний
результат: Програма
роботу після натискання на ...
завершила
свою

206.

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