Software Testing
0063502:The dropdown menu in the «About us» headline is superimposed on the dropdown menu in the «Contact us» headline.
0063502:Выпадающее меню в заголовке «О нас» накладывается на выпадающее меню меню в заголовке «Контакты».
До основних елементів анатомії веб-сторінки (web-page) відносять
1,Заголовок (header) - використовується у верхній частині сторінки, де міститься логотип (logo),навігацію (navigation), рекламний слоган (tagline), назву сайту та сервісні форми, такі як пошук (search), зв'язок або авторизація (authorization). Бічна панель (sidebar) Основний контент (main content) - текстове наповнення веб-сайту, яке за правилами практичності використання (usability) має займати не менше 70% сторінки, а також включати в себе заголовки, текстовий і графічний контент/ = Підвал сайту (footer)
Розрізняють наступні етапи тестування веб-проєктів (web-project stages of testing):
1. Вивчення документації (documentation analysis). 2. Тестування верстки (layout testing). 3. Функціональне тестування (functional testing). 4. Тестування практичності/перевірка на простоту використання 5. (usability testing). 6. Тестування безпеки (security testing). 7. Тестування продуктивності сайту (performance testing).
Рівні тестування програмного забезпечення
1. Компонентне (модульне) тестування (Unit Testing or Component Testing)перевіряє функціональність та шукає дефекти у частинах додатку, які доступні й можуть бути протестовані окремо (модулі програм, об'єкти, класи, функції та ін.). Один з найбільш ефективних підходів до компонентного (модульного) тестування - це підготовка автоматизованих тестів до початку основного кодування (розробки) програмного забезпечення. Це називається «розробка від тестування» (test- driven development) або «підхід тестування на початку» (test first approach).
Основные отрибуты бага
1. Номер бага - Bug Number 2. Severity - серйозность (trivial, major, critical) 3. Priority - приоритет дефекта (low, high, urgent) 4.Summary- краткое описание 5. Description - подробное описание 6. Stept to Reproduce - шаги для воспроизведения 7.Actual Result- фактический результат 8. Expected Result- ожидаемый результат 9, Attachment - вложение (screenschot)
Розрізняють такі етапи тестування (Stages of testing):
1.Вивчення документації (Documentation) 2.Тестування верстки (Layout testing) 3.Функціональне тестування (Functional testing) Тестування практичності / перевірки на простоту використання (Usability testing) - проводиться для оцінки зручності продукту у використанні: • тестування навігації (Test for navigation) - веб-сайт повинен бути простим у використанні, інструкції повинні бути зрозумілими і головне меню повинно бути передбаченим на кожній сторінці і бути послідовним; • перевірка вмісту (Content checking) - зміст має бути логічним і простим для розуміння без орфографічних помилок, без використання кольорової гами, яка дратує користувачів. 5. Тестування безпеки (Security testing)
Розрізняють такі етапи тестування (Stages of testing):
1Вивчення документації (Documentation) 2Тестування верстки (Layout testing) 3Функціональне тестування (Functional testing) 4. Тестування практичності / перевірки на простоту використання (Usability testing)тестування навігації (Test for navigation) - веб-сайт повинен бути простим у використанні, інструкції повинні бути зрозумілими і головне меню повинно бути передбаченим на кожній сторінці і бути послідовним; • перевірка вмісту (Content checking) - зміст має бути логічним і простим для розуміння без орфографічних помилок, без використання кольорової гами, яка дратує користувачів. 5 Тестування безпеки (Security testing)перевіряється доступ користувача до службових/закритих сторінок, а також проводиться перевірка захисту всіх критично важливих сторінок (наприклад,розділу адміністрування сайту) від зовнішнього впливу і включає наступні дії: • виявлення помилок в коді сайту та програмному забезпеченні сервера; • виявлення наявності таких вразливостей, як SQL Injection або ін'єкція SQL, XSS (Cross SiteScripting), PHP includes, биті посилання (broken links) [14]; • тестування на стійкість до комбінованих методів атак і нестандартних технік зламування. 6. Тестування продуктивності сайту (Performance testing)
Рівні тестування програмного забезпечення
2. Інтеграційне тестування (Integration Testing) Рівні інтеграційного тестування: ✔ компонентний інтеграційний рівень (Component Integration Testing) - перевіряється взаємодія між компонентами системи післяпроведення компонентного тестування; ✔ системний інтеграційний рівень (System Integration Testing) - перевіряється взаємодія між різними системами після проведення системного тестування. Підходи до інтеграційного тестування: • знизу вгору (Bottom Up Integration):великий вибух («Big Bang» Integration): всі або практично всі розроблені модулі збираються разом у вигляді закінченої системи або їїосновної частини, а потім проводиться інтеграційне тестування.
secerity
minor, trivial, text, tweak, major, crash, block
priority
none, low, normal, hight, urgent, immediate
використовувати в пасивному стані, їх краще замінити на «show» або «display».
snow, display
Можливі такі варіанти статусів
«Passed» - перевірка пройдена успішно, багів не знайдено; ▪ «Failed» - знайдений один або більше багів;▪ «Blocked» - неможливо перевірити, тому що один з багів блокує поточну перевірку; ▪ «In Progress» - поточний пункт, над яким працює тестувальник; ▪ «Not run» - ще не перевірено; ▪ «Skipped» - не буде перевірятися з будь-якої причини.
5. Регресійне тестування.
Вид тестування, спрямований на перевірку змін, зроблених у додатку або в оточуючому середовищі (лагодження дефекту, злиття коду, міграція на іншу операційну систему, базу даних, веб- сервер або сервер додатку), для підтвердження того факту, що існуюча функціональність працює як і раніше. Регресійними можуть бути тести як функціональні, так і нефункціональні. Зазвичай для регресійного тестування використовуються тест-кейси, написані на ранніх стадіях розробки та тестування. Це дає гарантію того, що зміни у новій версії додатку не пошкодили вже існуючу функціональність.регресія багів (bug regression) - спроба довести, що виправлена помилка насправді не виправлена; • регресія старих багів (old bugs regression) - спроба довести, що нещодавня зміна коду або даних зламала виправлення старих помилок, тобто старі баги знову стали відтворюватися; • регресія побічного ефекту (side effect regression) - спроба довести, що нещодавня зміна коду або даних зламала інші частини додатку.
Attachments (Вкладення)
До баг-репортів потрібно прикріплювати файли, наприклад, скріншот, відео або лог-файл. Це робиться тому, що інформація краще засвоюється візуально, ніж текстово. Якщо додавати скріншот, де візуально показати стрілкою, що «ось тут баг», то, відкривши цей скріншот іноді можна і не читати кроки і description. Бувають такі баги, коли скріншот не підтверджує наявність дефекту. В такому випадку, необхідно обов'язково прикріпити і скріншот, і відео з помилкою. Це потрібно для того, щоб візуально зорієнтувати в якому місці шукати баг і не переглядати відео кілька разів.
Actual result: The Patient's card is not saved in the patient database after clicking the «Save» button Expected result: The Patient's card is saved in the patient database after clicking the «Save» button.
Картка пацієнта зберігається в базі даних пацієнтів після натискання кнопки «Зберегти»)
The patient's card is not saved in the patient database after clicking the «Save» button.
Картка пацієнта не зберігається в базі пацієнтів після натискання кнопки «Save».
The layout crashes on the «Register» form after changing the «Address» field.
Макет вылетает на форме «Регистрация» после изменения поля «Адрес».
Етап 2. Доступність
На цьому етапі необхідно перевірити: наявність необхідних елементів; розмір елементів та їх колір; чи виділяється текст в текстових блоках; чи натискається іконка логотипу; чи натискаються клікабельні елементи (посилання/кнопки); розташування елементів відносно один одного; чи набуває курсор різну форму при наведенні на клікабельні елементи. З типами курсора можна ознайомитися на наступному зображенні.
Верстка Етап 1. Візуальна частина
На цьому етапі необхідно перевірити: точність відповідності макету (зазвичай, використовується інструмент Pixel Perfect); сітку (вирівнювання по горизонталі/вертикалі); масштаб (від 75% до 150%); зміну розміру текстового поля; виділення полів у фокусі; верстку у різних роздільних здатностях (розширеннях), а саме:
Hover the mouse over the «Contact us» headline.
Наведите указатель мыши на заголовок «Свяжитесь с нами».
Click (on) the «Save» button
Натиснути кнопку «Enter»
Steps To Reproduce (Кроки для відтворення)
Необхідно точно описати всі кроки, щоб можна було без проблем відтворити помилку. Приклад: Перейти на сайт (посилання на сайт) Натиснути на кнопку «Реєстрація» Натиснути на кнопку «Надіслати» Звернути увагу на форму реєстрації. На випадок, якщо кроків для відтворення буде дуже багато (більше 8) , можна вказати передумови (Preconditions), наприклад: Користувач авторизований у системі. Товар був доданий до кошика.
Severity (Серйозність дефекта)
Один з варіантів градації Серйозності дефекту: S1 Блокер (Blocker) Блокуюча помилка, що призводить додаток в неробочий стан, в результаті якого подальша робота з тестованою системою або її ключовими функціями стає неможливою. Рішення проблеми необхідне для подальшого функціонування системи. S2 Критична (Critical) Критична помилка, неправильно працює ключова бізнес-логіка, діра в системі безпеки, проблема, яка призвела до тимчасового падіння сервера або приводить в неробочий стан деяку частину системи, без можливості вирішення проблеми, використовуючи інші вхідні точки. Рішення проблеми необхідно для подальшої роботи з ключовими функціями тестованою системою. S3 Значна (Major) Значна помилка, яка означає, що частина основної бізнес-логіки не працює правильно. Помилка не є критичною, або є можливість роботи з функцією що тестується, використовуючи інші вхідні точки. S4 Незначна (Minor) Незначна помилка, що не порушує бізнес логіку частини додатку, що тестується, очевидна помилка користувацького інтерфейсу. S5 Незручність (Tweak) Незручність, очевидна проблема користувацького інтерфейсу. Означає, що необхідний «підгін», підвищення ступеню приязності інтерфейсу. S6 Текст/одрук (Text) Невелика текстова помилка/друкарська помилка. Пунктуаційна або орфографічна помилка. S7 Тривіальна (Trivial)
Expected result: The «Address» field has the fixed scale on the «Register» form.
Ожидаемый результат: Поле «Адрес» имеет фиксированный масштаб на форме «Регистрация».
Status (Статус)
Основний атрибут, що визначає поточний стан бага. Відображає життєвий цикл бага від початкового стану до завершення. Назви статусів дефектів можуть бути
Оточення дефекту
Оточення дефекта Component (Компонент) або Environment (Оточення) - це атрибут дефекту, який вказує на якій платформі цей дефект відтворюється (iOS, Android, Windows, Mac і їх версії, назви і версії браузерів, в яких відтворюється дефект). У Mantis оточення вказується в полях «Platform» (назва і версія браузера, PC або Mobile), «OS» (назва операційної системи) і «OS Version» (версія операційної системи). Також варто вказати другорядні атрибути баг-репорта : Fix Version (Версія) - цей атрибут вказує, на якому етапі розробки програмного продукту був знайдений дефект. Assignee (Призначення) - це атрибут, у якому вказується кому присвоюється баг-репорт для подальшої перевірки. Build (Номер збірки) - це атрибут, у якому вказаний номер білда, у якому був знайдений дефект. Lable (Лейбл) - це атрибут, що вказує на належність дефекту до того або іншого типу дефектів (графічний дефект, дефект локалізації і т.д.).
Go to the footer of the web-page.
Перейдите в нижний колонтитул веб-страницы.
Pull at the right bottom corner «Address» field at the «Register» form.
Потяните в правом нижнем углу поле «Адрес» на форме «Регистрация».
Стандартний набір статусів (для баг-трекера Mantis):
Стандартний набір статусів (для баг-трекера Mantis): Новий (New) - новий баг-репорт; Зворотний зв'язок (Feedback) - необхідна додаткова інформація; Розглянутий (Acknowledged) - з питанням було ознайомлено, але підтвердження ще не було, відповідального не призначено; Підтверджено (Accepted) - дефект було відтворено та підтверджено; Призначено (Assigned) - баг-репорт призначений на розробника; Відпрацьовано (Resolved) - питання вирішене, очікується підтвердження, що баг усунутий; Зачинено (Closed) - дефект виправлений, підтверджений та не потребує ніяких подальших дій.
6. Тестування продуктивності сайту (Performance testing)
Тестування продуктивності включає в себе такі види тестування: • Навантажувальне тестування (Load-testing) - найпростіша форма тестування продуктивності. Тестування навантаження зазвичай проводиться для того, щоб оцінити поведінку сайту (або програми) під заданим очікуваним навантаженням. Цим навантаженням може бути, наприклад, очікувана кількість одночасно працюючих користувачів на сайті, що виконують задане число транзакцій за інтервал часу. Такий тип тестування зазвичай дозволяє отримати час відгуку всіх найважливіших бізнес-функцій. Тестування швидкодії - перевірка швидкості завантаження сайту для визначення швидкості відпрацювання скриптів, завантаження зображень і контенту. Цей тест проводиться з метою оптимізації процесу завантаження сайту, а також визначення оптимальності налаштувань сервера
Summary (Тема)
У цьому полі необхідно коротко викласти суть бага. Для того, щоб в повній мірі описати баг, необхідно послідовно відповісти на три питання: ЩО не так працює? в якому місці продукту, тобто ДЕ? і КОЛИ дана проблема з'являється?
за часом проведення тестування:
альфа-тестування: o димове тестування (smoke testing); o тестування нової функції (new feature testing); o підтверджуюче тестування; o регресійне тестування; o приймальне тестування; • бета-тестування;
Баг
в ходе тестирования выясняется, что фактический результат не равен ожидаемому результату
Етап 3. Коректна робота
величину елемента - необхідно виміряти його і порівняти зі специфікацією. Можна це зробити за допомогою Page Ruler; коректність шрифтів (колір, розмір, назва) - розширення для ідентифікації шрифтів Fontface Ninja для Safari і Chrome цілком ефективно для перевірки; кольори інтерфейсу - для даної перевірки добре підійде ColorZilla; контент - для перевірки на наявність орфографічних або граматичних помилок буде корисною програма SpellChecker; фавікон - це обов'язкова частина, відсутність якої може зіпсувати надалі думку користувача; стандарти HTML/CSS - для даної перевірки можна використовувати W3C; стандарт заголовків у всьому додатку:
Reproducibility
воспроизводимость always, sometimes, random,
execution
выполнение
Веб-дизайн (Web-design)
галузь веб-розробки, а також різновид дизайну, до завдань якої входить проектування веб-інтерфейсів (Web UI) для сайтів або веб-додатків.
Верстка (Layout)
етап дизайну сторінки сайту, що представляє собою просторове розміщення на ній текстових елементів і графічних зображень відповідно до концепції оформлення ресурсу.
Веб-додатки (Web-applications)
клієнт серверний додаток, в якому клієнтом виступає браузер, а сервером - веб-сервер.
за ступенем ізольованості компонентів:
модульне тестування; • інтеграційне тестування; • системне тестування;
Priority (Пріоритет дефекта)
один з варіантів градації Пріоритета дефекту: P1 Високий (High) Помилка повинна бути виправлена якомога швидше, адже, її наявність є критичною для проєкту. P2 Середній (Medium) Помилка повинна бути виправлена, її наявність не є критичною, але потребує обов'язкового вирішення. P3 Низький (Low) Помилка має бути виправлена, її наявність не є критичною, і не потребує термінового усунення. Порядок усунення помилок по їх пріоритетам:: High -> Medium -> Low
Перевірка однотипності/симетричності в інтерфейсі:
однотипність/симетричність використання відступів; • ширина колонок та контентного поля; • позиціонування елементів верхнього та нижнього колонтитулів на всіх сторінках; • позиціонування банерів, правого та лівого блоку; • розмір текстів; • відступи між абзацами; • відстані між рядками; • елементи управління (кнопки, чекбокси, випадаючі списки); • розмір/колір/тип шрифта;наявність стилів оформлення заголовків першого, другого та більше рівнів; • коректне відображення тексту навколо зображень; • напрямки тіней у всіх елементів управління; • назви однакових елементів у різних місцях; • чи мають елементи, що призначені для натискання, вказівник «pointer»; елементи, які можна перетягувати - вказівник «move» або «crosshair»; неактивні/недоступні елементи - вказівник «default»
Валідація -
перевірка того, що продукт відповідає очікуванням і потребам користувачів.
3. Системне тестування (System Testing) -
перевірка як функціональних, так і не функціональних вимог Можна виділити два підходи до системного тестування: • на базі вимог (requirements based): для кожної вимоги пишуться тестові випадки (test cases), що перевіряють виконання даної вимоги;на базі випадків використання (use case based): на основі уявлення про способи використання продукту створюються випадки використання системи (Use Cases). За конкретним випадком використання можна визначити один або більше сценаріїв. Для перевірки кожного сценарію пишуться тест-кейси (Test Cases), які повинні бути протестовані.
overflowed
переполнен
overrun
переходить пределы, границы (чего-л.)
за ознакою позитивності сценаріїв:
позитивне тестування; • негативне тестування;
Функціональне тестування (Functional testing)
посилання (працездатність, відкриття в тому ж або новому вікні); • форми (введення тексту, чисел, використання маски, робота з незаповненими полями, довжина символів, що вводяться, коректна робота чек боксів, комбо-боксів, radio кнопок, логічність установок «за замовчуванням» і т.д.); • бази даних (пошук, додавання інформації, редагування, видалення, перевірка на дублювання інформації). • секретність (робота з паролями, передача даних, захист і т.д.); • кешування (перевірка на установку кешування та оновлення файлів); • перевірка роботи з браузером (оновлення сторінки, посилання/кнопка «Назад», зміна розмірів вікна, вибір кодування, скролінг); • фрейми (завантаження сторінок, скролінг і т.п.); • анімація (наявність, зміна розмірів, завантаження і т.д.); • аудіо і відео (наявність, розміщення, якість та ін.); друк (чи коректно друкуються сторінки); • тестування додатка шляхом включення або відключення куків (cookie) в настройках браузера
Жизненный цикл бага
последовательность этапов которые проходит баг на своем пути, начиная с того момента, как он был обнаружен и до его окончательного исправления и закрытия
спецификация
пошаговая инструкция
Верифікація -
підтвердження того, що певні вимоги були виконані.
за ступенем автоматизації:
ручне тестування; • автоматизоване тестування; • напівавтоматизоване тестування;
Атрибути бага
свойство отличительный признак, определенные характерные черты чего либо
Веб-сайт (Website)
система з декількох сторінок, що мають одну адресу в мережі Інтернет.
за ступенем підготовленості до тестування:
тестування за документацією (формальне тестування); • інтуїтивне тестування (ad hoc testing).
Веб-тестування (Web-testing)
тестування програмного забезпечення, сфокусоване на веб-додатках (web-applications), яке здійснюється з застосуванням систем, що використовують веб-технології (web-basedsystem), та вирішують такі питання як: безпека веб-додатків, базова функціональність сайту, доступність користувачам і т.д.
за знанням системи:
тестування чорного ящика; • тестування білого ящика; • тестування сірого ящика;
Верстка
це розміщення елементів веб-додатку відповідно до макету та вимог. Варто звернути увагу на те, що тільки мануальний тестувальник виконує перевірку HTML і CSS. Для фахівця важливо, щоб всі елементи веб-додатку відображалися коректно.
Приймальне тестування (Acceptance Testing)
це формальний процес тестування, який перевіряє відповідність системи вимогам та проводиться з метою: • визначення чи задовольняє система приймальні критерії; • винесення рішення замовником або іншою уповноваженою особою чи приймається додаток. Приймальне тестування виконується на підставі набору типових тестових випадків та сценаріїв, розроблених на підставі вимог до даного додатку.
верстка
— это описание визуальной части сайта с помощью гипертекстового документа на основе HTML-разметкичи немає помітних оку невідповідностей: поламані блоки, не стикування кольору, некоректне відображення тексту навколо зображень; • якщо дизайн згідно ТЗ розрахований на певну ширину, то, незалежно від браузера, не повинна з'являтися горизонтальна прокрутка; • під час зменшення розміру вікна менше мінімального згідно ТЗ не повинно нічого ламатися, фони не повинні «розпливатися»; • сайт повинен виглядати однаково у всіх стандартних розширеннях екрану (1024x600, 1024x768, 1152x864, 1280x800, 1280x1024, 1440x900, 1680x1050, 1920x1080): не повинно нічого ламатися, не повинні різко обриватися фони при великих розширеннях; • при відключених зображеннях, написи (особливо логотип та головне меню сайту) повинні залишатися читабельними, на всіх інформаційних картинках повинні бути підписані акуратним, невеликим, сірим шрифтом (відключення картинок: Chrome → Settings → Search settings → JavaScript → Site settings→ Images → вибрати опцію «Don`t allow sites to show images»; Firefox→ about:config → permissions.default.image → 2); • працездатність при вимкненому JavaScript. Увесь критично важливий функціонал сайту повинен бути доступний без JS (відключення JavaScript: Chrome → Settings → Search settings → JavaScript → JavaScript (Content) → Don`t allow sites to use JavaScript; Firefox→ about:config → Accept the Risk and Continue → javascript.enabled → Toggle the «javascript.enabled» preference).
за об'єктом тестування:
• функціональне тестування; • тестування продуктивності: o навантажувальне тестування; o стрес-тестування; o тестування стабільності; • конфігураційне тестування; • юзабіліті-тестування; • тестування інтерфейсу користувача; тестування безпеки; • тестування локалізації; • тестування сумісності;
