Метрики підрахунку дефектів.

 

- Плотность дефектов (500 = Число дефектов / Размер юода)

- Плотность дефектов после поставки (РООО = Число дефектов

после поставки / Размер кода)

- Доля отклоненных дефектов (ВПК = Число отклоиеииых

дефектов / Число дефектов)

- «Убойность» тестов (ОР = Число дефектов / Число тестов)

- Эффективность тестирования (ТЕ = Число дефектов / Трудозатраты тестирования)

- Доля покрытия требований (КСК = Число требований,

покрытых тестами / Число требований)

- Плотность покрытия требований (КСО = Число тестов / Число

требований)

- доля повторно открытых дефектов (КОК = Число повторно

открытых дефектов / Число дефектов)

- И много-много других

 

° Lifetime - распределение дефектов по их продолжительности жизни в проекте

° Detection time - распределение дефектов по времени их обнаружения

в жизненном цикле проекта, релиза или программного продукта.

° Submitted vs Resolved - временное распределение количества

дефектов со статусом Submitted и со статусом Resolved

° Resolved vs Validated - временное распределение количества

дефектов со статусом Resolved и со статусом Validated

° Reopened - временное распределение количества дефектов со

статусом Reopened

° Zero-defects data - прогноз даты, к которой идентифицированные при системном тестировании дефекты будут закрыты.

Проблеми оракула.

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

Обмеження при проведенні тестування.

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

Ø Найвідоміші цитати в цьому відношенні є афоризми Дейкстри що “тестування програм може використовуватися для демонстрації наявності помилок, але не для демонстрації їх відсутності.”

Ø Очевидна причина в тому, що повне тестування не є можливим в справжньому ПЗ. Через це, тестування повинно визначатися в залежності від ризику, і може розглядатися як стратегія управління ризиками.

 

Тести, що базуються на блок-схемі.

Тесты, базирующиеся на блок-схеме (Control-flow-based criteria)

Набор тестов строится исходя из покрытия всех условий и решений блок-схемы. В какой-то степени напоминает тесты на основе конечного автомата. Отличие – в источнике набора тестов.

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

Тестування інсталяцій.

¨ З назви випливає, що дані тести проводяться з метою перевірки процедури інсталяції системи в цільовому оточенні.

(інфа з лекції)

Зв’язок тестування з іншими видами діяльності по розробці.

Ø Тестування ПЗ пов’язане, але відрізняється від, технік керування якістю ПЗ, доведень коректності, відладки та програмування.

Ø Тим не менше, воно є інформаційним з точки зору аналітиків якості ПЗ та центрів сертифікації

Ø Тестування vs. Статистика технік керування якістю ПЗ

Ø Тестування vs. Доведення коректності та Формальна верифікація

Ø Тестування vs. Відладка.

Ø Тестування vs. Програмування.

Ø Тестування та Сертифікація.

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

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

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

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

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

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

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

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

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

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

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

 

Рівні тестування (послідовність).

Уровни тестирования (Test Levels)

2.1 Над чем производятся тесты (The target of the test)

Тестирование обычно производится на протяжении всей разработки и сопровождения на разных уровнях. Уровень тестирования определяет “над чем” производятся тесты: над отдельным модулем,

группой модулей или системой, в целом. При этом ни один из уровней тестирования не может считаться приоритетным. Важны все уровни тестирования, вне зависимости от используемых моделей и методологий.

Модульное тестирование (Unit testing)

Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента системы. Что считать элементом – модулем системы определяется контекстом. Наиболее полно

данный вид тестов описан в стандарте IEEE 1008-87 “Standard for Software Unit Testing”, задаю щем интегрированную концепцию систематического и документированного подхода к модульному

тестированию.

Интеграционное тестирование (Integration testing)

Данный уровень тестирования является процессом проверки взаимодействия между программнымикомпонентами/модулями. Классические стратегии интеграционного тестирования – “сверху-вниз” и “снизу-вверх” –используются для традиционных, иерархически структурированных систем и их сложно применять, например, к тестированию слабосвязанных систем, построенных в сервисно-ориентированныхархитектурах (SOA).

Современные стратегии в большей степени зависят от архитектуры тестируемой системы и строяться на основе идентификации функциональных “потоков” (например, потоков операций и данных).

Интеграционное тестирование – постоянно проводимая деятельность, предполагающая работу на достаточно высоком уровне абстракции. Наиболее успешная практика интеграционного тестирования базируется на инкрементальном подходе, позволяющем избежать проблем проведения разовых тестов, связанных с тестированием результатов очередного длительного этапа работ, когда количество выявленных дефектов приводит к серьезной переработке кода (традиционно, негативный опыт выпуска и тестирования только крупных релизов называют “big bang”).

Системное тестирование (System testing)

Системное тестирование охватывает целиком всю систему. Большинство функциональных сбоев должно бать идентифицировано еще на уровне модульных и интеграционных тестов. В свою очередь, системное тестирование, обычно фокусируется на нефункциональных требованиях – безопасности, производительности, точности, надежности т.п. На этом уровне также тестируются интерфейсы к внешним приложениям, аппаратному обеспечению, операционной среде и т.д.

 

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

 

Оценка функционального размера ИС производится на основании модели информационной системы и функциональных требований пользователей. Функциональный размер ИС задается набором из пяти элементов, каждый элемент которого представляет собой соответствующую функциональную единицу измерения. Функциональные единицы измерения:

Количество вариантов использования - C

Количество типов объектов - E

Количество свойств типов объектов - Т

Количество взаимодействий между типами объектов - I

Количество типов узлов - N

Функциональный размер обозначается - SIZE={C, E, T, I,N}

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

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

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

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

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

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

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

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

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

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

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

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

 

Цілі тестування.

 

Цілі (види) тестування

 

Тестування проводиться для того, щоб

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

Перевірити створений продукт на відповідність вимогам і специфікаціям

Виявити можливі приховані дефекти ПО

· Приймальне тестування (Прийом / кваліфікаційних випробувань). Перевіряє поведінку системи на предмет задоволення вимог замовника.

· Установочное тестування (установка тестування). З назви випливає, що дані тести проводяться з метою перевірки процедури інсталяції системи в цільовому оточенні.

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

· Функціональні тести / тести відповідності (тестування відповідності / Функціональне тестування / Коректність тестування). Ці тести можуть називатися по-різному, проте, їх суть проста - перевірка відповідності системи, що пред'являються до неї вимогам, описаним на рівні специфікації поведінкових характеристик.

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

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

· Навантажувальне тестування

 

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

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

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

 

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

1. "зверху-вниз" - Відбувається поступова інтеграція модулів

2. "знизу-вгору“

3. “монолітне”.

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

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

Основна задача – виявити проблеми взаємодії модулів системи

Проблеми:

o Важко виявити джерело помилок

o Важко організувати виправлення помилок

o Процес тестування погано автоматизується

Часова класифікація

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

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

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