Система функціонального випробування. Функціональні види тестування

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

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

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

І цей засіб називається ТЕСТУВАННЯ програмного продукту .

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

p align="justify"> Якість програмного продукту характеризується набором властивостей, що визначають, наскільки продукт "хороший" з точки зору зацікавлених сторін, таких як замовник продукту, спонсор, кінцевий користувач, розробники та тестувальники продукту, інженери підтримки, співробітники відділів маркетингу, навчання та продажів. Кожен із учасників може мати різне уявлення про продукт і про те, наскільки він хороший чи поганий, тобто про те, наскільки високою є якість продукту. Таким чином, постановка задачі забезпечення якості продукту виливається в завдання визначення зацікавлених осіб, їх критеріїв якості та знаходження оптимального рішення, що відповідає цим критеріям.

Коли та хто?

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

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

• Функціональне тестування
• Нефункціональне тестування

Функціональне тестування

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

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

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

Зазвичай функціональне тестування проводиться на двох рівнях:

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

Нефункціональне тестування

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

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

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

Тестування вбудованого ПЗ та дотримання стандартів в еру Agile

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

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

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

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

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

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

Документація для тестування

Як уже було зазначено вище, тестування проводиться відповідно до програми та методики випробувань, яка розробляється відповідно до ГОСТ 34.603-92.

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

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

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

Якщо результат тестування негативний, проводиться усунення недоліків та повторне тестування.

Дослідницьке тестування

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

Тестування навантаження

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

1. Генерація тестових сценаріїв

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

2. Розробка тестової конфігурації

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

3. Проведення тестового випробування

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

Автоматизація тестування

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

Тестування юзабіліті

Будь-яка програма створюється для того, щоб ним скористалися. Зручність використання – важливий якісний показник програми. IT-індустрія знає безліч прикладів, коли проекти злітали після вдалого виправлення зручності використання. Чим ширша аудиторія, тим важливіший факторюзабіліті. Тестування юзабіліті включає детальний аналіз поведінки користувачів. Для оцінки ергономіки важливо мати дані не тільки про швидкість виконання бізнес-завдання, а й про емоції користувача, міміку обличчя, тембру голосу.

Конфігураційне тестування

Конфігураційне тестування дає впевненість, що програма запрацює на різних платформах, а значить у максимальної кількості користувачів. Для веб-додатків зазвичай вибирають тестування на крос-браузерність. Для Windows додатків – тестування на різних операційних системах та бітностях (x86, x64). p align="justify"> Важливою складовою конфігураційного тестування є тестова інфраструктура: для проведення випробувань потрібно постійно підтримувати парк тестових машин. Їх кількість варіюється від 5 до кількох десятків.

Інтеграційне тестування

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

Стрес тестування

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

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

Функціональне тестування: куди спрямувати основні зусилля?

на модульне та системне тестування;

На перевірку «білої» або «чорної» скриньки;

На ручне тестування та автоматизацію;

на перевірку нового функціоналу або;

На "негативні" чи "позитивні" тести.

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

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

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

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

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

Аналіз граничних значень;

Еквівалентне розбиття;

Припущення про помилки;

Аналіз зв'язків між причинами та наслідком.

Можна розглянути кожен із них окремо.

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

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

Аналіз зв'язків причини та наслідки. Система може вибирати тести із високою результативністю завдяки проведенню таких перевірок. В даному випадку як причина приймається окрема вхідна умова, а як слідство бачиться вихідна умова. Метод базується на ідеї віднесення всіх видів причин до певних наслідків, тобто на уточненні тих причинно-наслідкових зв'язків. Тестування програмного продукту здійснюється в кілька етапів, в результаті чого виходить список з причин і наслідків, що випливають.

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

• тестування black box(чорна скринька) – проведення функціонального тестування без доступу до коду системи,
• тестування white box (біла скринька) – функціональне тестування з доступом до коду системи.

Тестування black box проводиться без знання внутрішніх механізмів роботи системи та спирається на зовнішні прояви її роботи. При цьому тестуванні перевіряється поведінка при різних вхідних даних і внутрішньому стані систем. У разі тестування white box створюються тест-кейси, що базуються переважно на коді системи ПЗ. Також існує розширений тип black-box тестування, що включає вивчення коду, - так званий grey box (сірий ящик).

Ключові переваги

1. Функціональне тестування ПЗ повністю імітує фактичне використання системи.
2. Дозволяє своєчасно виявити системні помилки ПЗ і тим самим уникнути безлічі проблем при роботі з ним надалі.
3. Економія з допомогою виправлення помилок більш ранньому етапі життєвого циклу ПЗ.

Основні етапи функціонального тестування

Підготовка

Проведення

Підготовка

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

Проведення

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

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

Інструменти

Управління тестуванням ведеться у спеціалізованих системах.

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

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

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

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

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

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

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

Отже, розглянемо основні етапи, які ви повинні пройти, щоб протестувати свій сайт. Вони представлені на малюнку внизу.

Тестування документації

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

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

• Вимоги
• План тестування
• Тест кейси
• Матриця відповідностей

Функціональне тестування сайту

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

Спробуймо створити чек-лист для тестування функціональності веб-сайту.

Тестування посилань

Ви повинні перевірити:

• Вихідні посилання
• Коректність внутрішніх посилань
• Відсутність посилань, що ведуть до однієї сторінки
• Посилання, які використовуються для надсилання електронної поштиадмінам сайту
• Чи є сторінки, на які не вказано посилання
• Відсутність непрацюючих посилань

Тестування форм для всіх сторінок

Ви використовуєте форми для інтерактивного спілкування з клієнтами. Отже, необхідно перевірити такі моменти:

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

Тестування cookies

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

• Перевірте сайт із вимкненими cookies
• Перевірте сайт із включеними cookies
• Переконайтеся, що файли cookie зашифровані перед записом на комп'ютер користувача
• Перевірте аспекти безпеки під час видалення файлів cookies.
• Якщо cookies мають тривалість дії, слід перевірити, чи активні вони у зазначений період часу.

HTML/CSS валідація

• Синтаксичні помилки HTML
• Переконайтеся, що веб-сайт доступний для пошукових машин.
• Переконайтеся, що ваша веб-сторінка має точну карту сайту у форматі XML та HTML

Корисні інструменти для проведення функціонального тестування: Selenium , Linux Test Project , JUnit, Sprinter by Hewlett Packard Entreprise(ручне тестування), Browserstack(ручне та автоматизоване тестування), Usersnap(Ручне тестування).

Usability тестування сайту (тестування зручності використання)

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

Навігаційне тестування сайтумістить такі перевірки:

• Усі сторінки сайту зрозумілі та прості у використанні.
• Кнопки, форми та поля зручні для використання.
• Доступ до головного меню здійснюється з усіх сторінок.

Чек лист тестування контенту:

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

Зрештою, щоб оцінити зручність використаннявашого веб-порталу, просто дайте відповідь на ці питання:

• Чи є ваш сайт зрозумілим та зручним?
• Чи зручна навігація?
• Яке враження він справляє на користувача?
• Чи є зайві чи непотрібні речі?

Корисні інструменти для використання тестування: User Zoom , Reflector, Loop 11 .

Тестування UI (інтерфейсу користувача)

Тестування інтерфейсу користувача (UI) виконується для перевірки відповідності графічного інтерфейсу користувача вашого сайту специфікаціям.

Ось деякі перевірки для тестування інтерфейсу веб-сайту:

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

Корисні інструменти для UI тестування: FitNesse , iMacros, Coded UI, Jubula, LoadUI .

Тестування сумісності (конфігураційне тестування)

Тестування сумісності виконується для перевірки роботи сайту при різних програмних та апаратних конфігураціях:

• Конфігурація операційної системи
• Конфігурація браузера
• Конфігурація бази даних

Крос-платформне тестування сайтудозволяє оцінювати роботу вашого сайту за різних ОС (як десктопних, і мобільних): Windows, iOS / Mac OS, Linux, Android, BlackBerry тощо.

Крос-браузерне тестування сайтудопомагає перевірити правильність роботи сайту у різних конфігураціях браузера: Mozilla Firefox, Google Chrome, Internet Explorer, Opera тощо.

Тестування баз данихвиконується для забезпечення правильної роботи вашого сайту за різних конфігурацій бази даних: Oracle, DB2, MySql, MSSQL Server, Sybase і т.д.

Сумісність опцій друкутакож слід згадати у плані тестування вашого веб-сайту:

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

Ви можете використовувати такі інструменти як BrowserStack, CrossBrowserTesting by Smart Bear , Litmus , Browsera , Rational Clearcase by IBM , Ghostlabдля тестування сумісності сайту

За цією адресою Ви знайдете більше інформації про тестування конфігурації –

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

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

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

Корисні інструменти для тестування продуктивності: Apache JMeter , HP LoadRunner , Silk Performer from Micro Focus , WebLOAD , Gatling.

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

Тестування безпеки

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

Ви можете імітувати атаку шкідливого джерела, щоб оцінити рівень безпеки вашого сайту ( тестування проникнення).

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

Деякі перевірки для тестування безпеки:

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

Корисні інструменти для тестування безпеки сайту: Retina CS Community , OWASP Zed Attack Proxy , Veracode, Google Nogotofail, SQL Map.

Тестування, пов'язане із змінами

Тестування, пов'язане із змінами, має дві основні цілі:

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

Тестування мобільної версії сайту

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

Ось кілька порад для того, щоб зробити ефективним тестування сайту на мобільних пристроях:

• Перевірте сумісність зі смартфонами та планшетами
• Переконайтеся, що навігація сайтом максимально проста
• Оптимізуйте час завантаження вашого сайту
• Переконайтеся, що кнопки мають достатній розмір для людей із великим пальцем
• Оптимізуйте розмір усіх зображень
• Не використовуйте Flash та спливаючі вікна
• Використовуйте маркери та короткі пропозиції
• Переконайтеся, що номер телефону може бути набраний за допомогою одного кліка
• Переконайтеся, що веб-сайт може отримати доступ до вашого розташування через GPS

Корисні інструменти для тестування мобільної версіїсайту – BrowserStack , Perfecto Mobile Continuous Quality Lab ,Windows Phone Emulator , Android Studio emulator , Google's Mobile-Friendly Test,Google's Page Speed ​​Online.

Дізнайтеся більше про мобільне тестування та його інструменти-

Бета-тестування

Бета-тестування – остання попередня стадія тестування. Як правило, це роблять кінцеві користувачі, які не є співробітниками компанії.

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

Такі інструменти, як HockeyApp , Ubertesters ,і TestFlight, є всесвітньо використовується платформами для бета-тестування.

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

Як проводити тестування сайту за допомогою EasyQA Chrome Extension

EasyQA Chrome Extension дозволяє створити баг репорт з вашого веб-сайту або веб-програми, не витрачаючи час на відправку інформації, допомагає в найкоротший термін розпочати роботу з виправлення бага.

Використовувати EasyQA Chrome Extension для роботи з багами дуже просто. Все, що вам потрібно зробити, це:

• Створіть токен для Вашого Проекту
• Встановіть EasyQA Chrome Extension у свій браузер
• Залягайте (за бажанням).

Основні можливості EasyQA Chrome Extension:

• Можливість репортувати баг безпосередньо з вашого веб-сайту або веб-програми
• Можливість створення баг репорту як для зареєстрованих, так і для незареєстрованих користувачів
• Створення скріншотів
• Відеозапис виявлених багів
• Підготовка та відправка баг репорту в ілюстрованій формі

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

Розглянемо процес тестування, виходячи з рекомендацій стандарту ISO/IEC 12207, і наведемо типи помилок, які виявляються кожному процесі ЖЦ.

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

Характерними помилками цього процесу є:

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

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

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

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

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

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

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

Усі помилки, що виникають у програмах, прийнято поділяти на такі класи [7.12]:

• логічні та функціональні помилки;
• помилки обчислень та часу виконання;
• помилки введення виводу та маніпулювання даними;
• помилки інтерфейсів;
• помилки обсягу даних та ін.

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

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

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

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

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

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

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

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

Зв'язок помилки з відмовою.Наявність помилки в програмі, як правило, призводить до відмови ПЗ при його функціонуванні. Для аналізу причинно-наслідкових зв'язків "помилка відмова" виконуються такі дії:

• ідентифікація вад у технологіях проектування та програмування;
• взаємозв'язок вад процесу проектування та помилок, що допускаються людиною;
• класифікація відмов, вад та можливих помилок, а також дефектів на кожному етапі розробки; - зіставлення помилок людини, що допускаються на певному процесі розробки, та дефектів в об'єкті, як наслідків помилок специфікації проекту, моделей програм;
• перевірка та захист від помилок на всіх етапах ЖЦ, а також виявлення дефектів на кожному етапі розробки;
• зіставлення дефектів та відмов у ПЗ для розробки системи взаємозв'язків та методики локалізації, збору та аналізу інформації про відмови та дефекти;
• розробка підходів до процесів документування та випробування ПЗ.

Кінцева мета причинно-наслідкових зв'язків "помилка відмова" полягає у визначенні методів та засобів тестування та виявлення помилок певних класів, а також критеріїв завершення тестування на безлічі наборів даних; у визначенні шляхів удосконалення організації процесу розробки, тестування та супроводу ПЗ.

Наведемо таку класифікацію типів відмов:

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

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

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

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

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

Команда розробників системи може також змінити синтаксис та семантику опису системи. Однак деякі помилки можуть бути не виявлені (наприклад, неправильно задані індекси або значення цих змінних операторів).