Тестирование удобства и простоты использования (Usability testing)

Цель – проверить, насколько легко конечный пользователь системы может ее освоить, включая не только функциональную составляющую – саму систему, но и ее документацию; нас колько эффективно пользователь может выполнять задачи, автоматизация которых осуществляется с использованием данной системы; наконец, насколько хорошо система застрахована (с точки зрения

потенциальных сбоев) от ошибок пользователя.

 

1. Метод сірої скриньки.

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

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

Сіра скринька (змішане тестування)

 Більшість тестів середнього рівня.

 Приклад: процедури у модулях.

 Індивідуальні процедури як чорні скриньки

 Зв'язки між процедурами – біла скринька на рівні модуля

 

1. Регресійне тестування.

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

¨ Основна проблема регресійного тестування
полягає в пошуку компромісу між наявними ресурсами та необхідністю проведення таких тестів у міру внесення кожної зміни.

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

 

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

¨ Інтеграційне тестування – тестування архітектури

¨ Даний рівень тестування є процесом перевірки взаємодії між програмними компонентами / модулями.

¨ Класичні стратегії інтеграційного тестування - "зверху-вниз" та "знизу-вгору“, “монолітне”.

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

¨ Високий рівень абстракції

Види:

¨ Тестування з пізньою інтеграцією – аналог монолітного тестування (“тестування в кінці”)

¨ Тестування з постійною інтеграцією – після розробки нового модуля системи, він відразу інтегрується з системою. Суміщення модульного та інтеграційного тестування.

¨ Тестування з регулярною інтеграцією (ієрархічне тестування) – подібне до тестування “згори-вниз” та “знизу-вгору”, але не визначається напрямок проходу.

 

 

1. Тестування, що базується на досвіді та інтуїції.

Техники, базирующиеся на интуиции и опыте инженера (Based on the software engineer’s intuition and experience)

Специализированное тестирование (Ad hoc testing) Возможно, наиболее широко практикуемая техника. Тесты основываются на опыте, интуиции и знаниях инженера, рассматривающего проблему с точки зрения имевшихся ранее аналогий. Данный вид тестирования может быть полезен для идентификации тех тестов, которые не охватываются рассматривавшимеся выше более формализованными техниками.

Исследовательское тестирование (Exploratory testing)Такое тестирование определяется как одновременное обучение, проектирование теста и его исполнение. Данный вид тестирования заранее не определяется в плане тестирования и такие тесты создаются, выполняются и модифицируются динамически, по мере необходимости. Эффективность исследовательских тестов напрямую зависит от знаний инженера, формируемых на основе поведения тестируемого продукта в процессе проведения тестирования, степени знакомства с приложением, платформой, типами возможных сбоев и дефектов, рисками, ассоциированными с конкретным продуктом и т.п.

1. Порівняння методів чорної та білої скриньки.

Тестирование чёрного ящика (black box)-состоит в том, что тесты проектируются на основе внешних спецификаций программ и модулей либо спецификаций сопряжения модуля с другими модулями, программа при этом рассматривается как «черный ящик». Смысл теста заключается в том, чтобы проверить, соответствует ли программа внешним спецификациям. При этом содержание модуля не имеет значения. Такой подход получил название —- стратегия «черного ящика».

Тестирование белого ящика (white box)-стратегия «белого ящика», основан на анализе логики программы. При таком подходе тестирование заключается в проверке каждого пути, каждой ветви алгоритма. При этом внешняя спецификация во внимание не принимается.

Метод чорної скриньки.

¨ Поведінка на вході/виході

-Контрольний список із специфікації

-Тестування очікуваної поведінки

-Кінцеві автомати

¨ Застосування

-Застосовують на пізніх стадіях розробки

-Підходить як для верифікації так і валідації

-Сумісна з ОО програмуванням та повторним використанням

¨ Критерій зупинки

-Традиційний – на основі покриття

-На основі використання

Метод білої скриньки.

¨ Знання про програмний компонент/структуру

-Контрольний список виразів чи компонентів

-Тестування шляхів у коді (потік управління)

-Тестування залежності по даним (потоки даних)

¨ Застосування

-Тестування на ранніх стадіях

-Подвійна роль програміста – тестувальника

¨ Критерій зупинки

-В основному задачі покриття

-Інколи інші задачі по якості та надійності

 

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

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

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

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

Загальні правила методу аналізу граничних умов:

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

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

1) використовувати перше правило для кожної вихідної умови;

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

3) повторити процедуру для всіх знайдених граничних умов.

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

 

1. Основи тестування.

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

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

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

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

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

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

• Ключові моменти:

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

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

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