Системное тестирование (System testing)
Системное тестирование охватывает целиком всю систему. Большинство функциональных сбоев должно бать идентифицировано еще на уровне модульных и интеграционных тестов. В свою очередь, системное тестирование, обычно фокусируется на нефункциональных требованиях – безопасности, производительности, точности, надежности т.п. На этом уровне также тестируются интерфейсы к внешним приложениям, аппаратному обеспечению, операционной среде и т.д.
59. Вимірювання, що базуються на концепції функціонального розміру.
Оценка функционального размера ИС производится на основании модели информационной системы и функциональных требований пользователей. Функциональный размер ИС задается набором из пяти элементов, каждый элемент которого представляет собой соответствующую функциональную единицу измерения. Функциональные единицы измерения:
Количество вариантов использования - C
Количество типов объектов - E
Количество свойств типов объектов - Т
Количество взаимодействий между типами объектов - I
Количество типов узлов - N
Функциональный размер обозначается - SIZE={C, E, T, I ,N}
60. Метод чорної скриньки.
¨ Поведінка на вході/виході
Ø Контрольний список із специфікації
Ø Тестування очікуваної поведінки
Ø Кінцеві автомати
¨ Застосування
Ø Застосовують на пізніх стадіях розробки
Ø Підходить як для верифікації так і валідації
Ø Сумісна з ОО програмуванням та повторним використанням
¨ Критерій зупинки
Ø Традиційний – на основі покриття
Ø На основі використання
61. Цілі тестування.
Цілі (види) тестування
Тестування проводиться для того, щоб
Проконтролювати і забезпечити заплановане якість програмного продукту
Перевірити створений продукт на відповідність вимогам і специфікаціям
Виявити можливі приховані дефекти ПО
· Приймальне тестування (Прийом / кваліфікаційних випробувань). Перевіряє поведінку системи на предмет задоволення вимог замовника.
· Установочное тестування (установка тестування). З назви випливає, що дані тести проводяться з метою перевірки процедури інсталяції системи в цільовому оточенні.
· Альфа-і бета-тестування (Альфа-і бета-тестування). Перед тим, як виробляється, програмне забезпечення, як мінімум, воно має проходити стадії альфа (внутрішнє пробне використання) і бета (пробне використання з залученням відібраних зовнішніх користувачів) версій.
· Функціональні тести / тести відповідності (тестування відповідності / Функціональне тестування / Коректність тестування). Ці тести можуть називатися по-різному, проте, їх суть проста - перевірка відповідності системи, що пред'являються до неї вимогам, описаним на рівні специфікації поведінкових характеристик.
· регресійне тестування
· тестування продуктивності
· Навантажувальне тестування
62. Метод сірої скриньки.
При тестуванні сірого ящика розробник тесту має доступ до вихідного коду, але при безпосередньому виконанні тестів доступ до коду, як правило, не потрібно.
Воно знаходиться в прикордонному стані між білим і чорним ящиком, тому його і називають сірим. Поєднання відбувається таким чином: зовні на продукт дивимося як на чорний ящик, але вибір тестів засновуємо на знанні внутрішнього устрою програми, знанні її коду. Цей метод часто використовується для тестування на веб-додатків.
Сіра скринька (змішане тестування)
Ø Більшість тестів середнього рівня.
Ø Приклад: процедури у модулях.
Ø Індивідуальні процедури як чорні скриньки
Ø Зв'язки між процедурами – біла скринька на рівні модуля
63. Регресійне тестування.
Якщо система успішно проходила тести до внесення модифікацій, вона повинна їх проходить і після внесення таких.
Основна проблема регресійного тестування
полягає в пошуку компромісу між наявними ресурсами та необхідністю проведення таких тестів у міру внесення кожної зміни.
Завдання полягає в тому, щоб визначити критерії "масштабів" змін, з досягненням яких необхідно проводити регресійні тести.
64. Інтеграційне тестування.
Інтеграційне тестування – тестування архітектури
Даний рівень тестування є процесом перевірки взаємодії між програмними компонентами / модулями.
Класичні стратегії інтеграційного тестування - "зверху-вниз" та "знизу-вгору“ , “монолітне”.
Сучасні стратегії залежать від архітектури тестованої системи і будуються на основі ідентифікації функціональних "потоків". Високий рівень абстракції
1. "зверху-вниз" - Відбувається поступова інтеграція модулів
2. "знизу-вгору“
3. “монолітне”.
Тестування окремих елементів не проводиться
Після розробки компонентів система збирається, і проводиться тестування системи в цілому
Основна задача – виявити проблеми взаємодії модулів системи
Проблеми:
o Важко виявити джерело помилок
o Важко організувати виправлення помилок
o Процес тестування погано автоматизується
Часова класифікація
1. Тестування з пізньою інтеграцією – аналог монолітного тестування (“тестування в кінці”)
2. Тестування з постійною інтеграцією – після розробки нового модуля системи, він відразу інтегрується з системою. Суміщення модульного та інтеграційного тестування.
3. Тестування з регулярною інтеграцією (ієрархічне тестування) – подібне до тестування “згори-вниз” та “знизу-вгору”, але не визначається напрямок проходу.
65. Тестування, що базується на досвіді та інтуїції.
Специализированное тестирование – этот термин используется для обозначения тестирования программного обеспечения, при котором само тестирование производится без планирования и документации. Специализированное тестирование является неформальным методом тестирования. Как таковой, этот метод был подвергнут критике, поскольку он не структурирован и, следовательно, дефекты, обнаруженные с помощью этого метода может быть труднее воспроизвести (поскольку не существует никаких баг-репортов). Тем не менее, сильной стороной специального тестирования является то, что критические дефекты могут быть обнаружены очень быстро. Фактически, такое тестирование осуществляется с долью импровизации: тестер пытается найти ошибки с помощью любых средств, которые, кажется ему уместными.
66.Порівняння методів чорної та білої скриньки.
Тестирование чёрного ящика (black box)-состоит в том, что тесты проектируются на основе внешних спецификаций программ и модулей либо спецификаций сопряжения модуля с другими модулями, программа при этом рассматривается как «черный ящик». Смысл теста заключается в том, чтобы проверить, соответствует ли программа внешним спецификациям. При этом содержание модуля не имеет значения. Такой подход получил название —- стратегия «черного ящика».
Тестирование белого ящика (white box)-стратегия «белого ящика», основан на анализе логики программы. При таком подходе тестирование заключается в проверке каждого пути, каждой ветви алгоритма. При этом внешняя спецификация во внимание не принимается.
В чому полягає тестування «чорної скриньки»?
1. Поведінка на вході/виході
a. Контрольний список із специфікації
b. Тестування очікуваної поведінки
c. Кінцеві автомати
2. Застосування
a. Застосовують на пізніх стадіях розробки
b. Підходить як для верифікації так і валідації
c. Сумісна з ОО програмуванням та повторним використанням
3. Критерій зупинки
a. Традиційний – на основі покриття
b. На основі використання
В чому полягає тестування «білої скриньки»?
1. Знання про програмний компонент/структуру
a. Контрольний список виразів чи компонентів
b. Тестування шляхів у коді (потік управління)
c. Тестування залежності по даним (потоки даних)
2. Застосування
a. Тестування на ранніх стадіях
b. Подвійна роль програміста – тестувальника
3. Критерій зупинки
a. В основному задачі покриття
b. Інколи інші задачі по якості та надійності
67.Аналіз граничних значень.
Під граничними умовами розуміють ситуації, що виникають безпосередньо на границі певної вхідної або вихідної умови, вище або нижче її. Метод аналізу граничних умов відрізняється від методу класів еквівалентності наступним:
- вибір будь-якого представника класу еквівалентності здійснюється таким чином, щоб перевірити тестом кожну границю цього класу;
- при побудові тестів розглядаються не тільки вхідні умови, але й вихідні (тобто певні специфіковані обмеження на значення вхідних даних).
Загальні правила методу аналізу граничних умов:
побудувати тести для границь множини допустимих значень вхідних даних і тести з недопустимими значеннями, що відповідають незначному виходу за межі цієї множини.
Якщо множина допустимих значень вхідних даних дискретна, то будуються тести для мінімального й максимального значення вхідних умов і тести для значень, більших або менших цих величин.
1) використовувати перше правило для кожної вихідної умови;
2) якщо вхідні й вихідні дані програми являють собою впорядковану множину (послідовний файл, лінійний список та ін.), то при тестуванні зосередити увагу на першому й останньому елементі множини;
3) повторити процедуру для всіх знайдених граничних умов.
Аналіз граничних умов - один з найбільш корисних методів проектування тестів. Але він часто виявляється неефективним через те, що граничні умови іноді ледь вловимі, а їхнє виявлення досить важко.
Основи тестування.
¨ Тестування - діяльність, що здійснюється для оцінки якості продукції, так і для його покращення, шляхом виявлення дефектів і проблем.
¨ Тестування складається з динамічної верифікації поведінки програм за обмеженим набором тест-кейсів, відповідним чином вибраних із нескінченної предметної області (галузі) для очікуваної поведінки.
¨ Динамічний: Цей термін означає, що тестування завжди передбачає виконання програми на вході. Щоб бути точним, самого вхідного значення не завжди достатньо, щоб визначити тестування, в той час як комплекс не детермінованих систем може відреагувати на ті ж вхідні дані з різною поведінкою, залежно від стану системи. Термін "вхідні дані" буде підтримуватися за звичаями, мається на увазі що його значення також включає в себе певний стан входу, в тих випадках, коли це необхідно.
¨ Кінцевий: Навіть в простих програм, так багато тест-кейсів теоретично можливих, що виснажливе тестування може займати декілька місяців або років для виконання. Ось чому на практиці цілий набір тестів в цілому можна вважати нескінченним. Тестування завжди передбачає компроміс між обмеженими ресурсами та розкладом, і по суті необмеженими вимогами до тестування.
¨ Вибір: багато запропоновані методи тестування істотно відрізняються в тому, як вони обирають набір тестів, а також програмні інженери повинні знати, що різні критерії відбору можуть дати зовсім різні ступені ефективності. Як визначити найбільш відповідний критерій відбору. За даних умов це дуже складна проблема; але на практиці застосовуються методи аналізу ризиків і досвід інженерного тестування.
¨ Очікування: Це повинно бути можливим, хоча і не завжди легко, щоб вирішити, чи є спостережені результати виконання програми бажаними чи ні, в іншому випадку зусилля витрачені на тестування будуть марними. Спостережена поведінка може бути перевірена на очікування користувачів (часто називають тестування для перевірки (валідації)), на специфікацію (тестування для перевірки), або, нарешті, на очікувану поведінки при внесенні неявних вимог або розумних очікувань.
¨ Ключові моменти:
¨ Вид тестування програмного забезпечення розвивається в більш конструктивному напрямку.
¨ Тестування більше не розглядається як діяльність, яка починається тільки після завершення фази кодування для виявлення збоїв.
¨ Тестування програмного забезпечення в даний час розглядається як діяльність, яка повинна охоплювати весь розвиток і підтримку процесу, і сама по собі є важливою частиною фактичного конструювання продукту.
69.Техніки, що базуються на аналізі коду.
Техники, ориентированные на код (Code-based techniques)
3.3.1 Тесты, базирующиеся на блок-схеме (Control-flow-based criteria)
Набор тестов строится исходя из покрытия всех условий и решений блок-схемы. В какой-то степени напоминает тесты на основе конечного автомата. Отличие – в источнике набора тестов.
Максимальная отдача от тестов на основе блок-схемы получается когда тесты покрывают различные пути блок-схемы – по-сути, сценарии потоков работ (поведения) тестируемой системы. Адекватность таких тестов оценивается как процент покрытия всех возможных путей блок-схемы.
3.3.2 Тесты на основе потоков данных (Data-flow-based criteria)
В данных тестах отслеживается полный жизненный цикл величин (переменных) – с момента рождения (определения), на всем протяжении использования, вплоть до уничтожения (неопределенности). В реальной практике используются нестрогое тестирование такого вида, ориентированное, например, только на проверку задания начальных значений всех переменных или всех вхождений переменных в код, с точки зрения их использования.
3.3.3 Ссылочные модели для тестирования, ориентированного на код (Reference models for code-based testing – flowgraph, call graph)
Является не столько техникой тестирования, сколько контролем структуры программы, представленной в виде дерева вызовов (например, sequence-диаграммы, определенной в нотации UML и построенной на основе анализа кода).
70.Порівняння збоїв та відмов.
Помилки та відмови
Стандарти:
¨ IEEE Standard 610.12-1990
¨ Standard Glossary of Software Engineering Terminology (IEEE610-90)
¨ Ключові моменти:
¨ Дуже важливо чітко розрізняти причину несправності, для яких термін несправності або дефекту буде використовуватися і небажаний ефект буде спостерігатися в наданих системних послугах, що буде названо відмовою.
¨ Тестування дозволяє виявити відмови, але це дефекти, які можуть і повинні бути видалені.
¨ Слід визнати, що причина відмови не завжди може бути ідентифікована.
¨ Не теоретині критерії існують, щоб остаточно визначити, які несправності заподіяно відмовою.
¨ Можна сказати, що це був дефект, який повинен бути змінений, щоб усунути проблему, але інші модифікації могли б працювати так само добре.