Основи тестування програмного забезпечення презентация

Содержание

Тестування: поняття та процес Тестування: споріднені питання Дефекти при тестуванні Види тестування * Software Architecture and Design

Слайд 1ЛЕКЦІЯ 9: ОСНОВИ ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Дишлевий О.П.
NAU

Слайд 2
Тестування: поняття та процес
Тестування: споріднені питання
Дефекти при тестуванні
Види тестування

*
Software Architecture

and Design

Слайд 3Визначення тестування і пов'язаної з ним термінології
Тестування - діяльність, що здійснюється

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

Слайд 4Визначення тестування і пов'язаної з ним термінології
Тестування складається з динамічної верифікації

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

Слайд 5Визначення тестування і пов'язаної з ним термінології
Динамічний: Цей термін означає, що

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

Слайд 6Визначення тестування і пов'язаної з ним термінології
Кінцевий: Навіть в простих програм,

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

Слайд 7Визначення тестування і пов'язаної з ним термінології
Вибір: багато запропоновані методи тестування

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

Слайд 8Визначення тестування і пов'язаної з ним термінології
Очікування: Це повинно бути можливим,

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

Слайд 9Визначення тестування і пов'язаної з ним термінології
Ключові моменти:
Вид тестування програмного забезпечення

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

Слайд 10Визначення тестування і пов'язаної з ним термінології
Справді, планування тестування має починатися

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

Слайд 11Визначення тестування і пов'язаної з ним термінології
Можливо, це очевидно, але слід

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

Слайд 12Розподіл тестування програмного забезпечення

Слайд 13Помилки та відмови
Стандарти:
IEEE Standard 610.12-1990
Standard Glossary of Software Engineering Terminology (IEEE610-90)

Слайд 14Дефекти та відмови
Дуже важливо чітко розрізняти причину несправності, для яких термін

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

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

Слайд 15Дефекти та відмови
Слід визнати, що причина відмови не завжди може бути

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

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

Слайд 16Випробування критерії відбору / Перевірка адекватності критеріїв (або правил зупинки)
Критерієм вибору

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

Слайд 17Тестування ефективності / цілі для тестування
Тестування це спостереження за виконанням зразка

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

Слайд 18Тестування для визначення дефекту
В тестуванні для визначення дефекту вдалий тест той,

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

Слайд 19Проблема Оракула
Оракул будь-який (людини або механізм) агент, який вирішує, чи програма

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

Слайд 20Теоретичні та практичні обмеження тестування
Теорія тестування застерігає від приписування невиправданого рівня

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

Слайд 21Проблема неможливих гілки
Неможливі гілки – гілки потоків управління, які не проходяться

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

Слайд 22Тестоспроможність
З одного боку, вона відноситься до міри в якій легко для

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

Термін “тестоспроможності ПЗ” має два взаємопов'язаних але різних значення:

Слайд 23Зв’язки тестування з іншими видами діяльності
Тестування ПЗ пов’язане, але відрізняється від,

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

Слайд 24Зв’язки тестування з іншими видами діяльності
Тестування vs. Статистика технік керування якістю

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

Слайд 25Тестування та альтернатива забезпеченню якості
Дефекти та забезпечення якості:
Дефекти: помилка\ несправність\ відмова
Дефекти:

запобігання\ усунення\ стримування
План до основної діяльності по забезпеченню якості
Запобігання дефектів:
Блокування помилок та видалення джерела помилки
Усунення дефектів:
Тестування
Інспекція
Стримування дефектів: відмовостійкість та стримування відмов

*

Software Architecture and Design

Слайд 26 Забезпечення Якості та Тестування
Тестування як частина Забезпечення якості:
Діяльність спрямована на стадії

тестування
Забезпечення якості/тестування у каскаді та V-моделі
Одна с найважливіших частин Забезпечення якості – усунення недоліків

*

Software Architecture and Design

Слайд 27
Тестування: Ключові питання:
Чому: Демонстрація якості проти виявлення дефектів та їх

усунення
Як: Методи/ Діяльність/ Процес
Огляд: Функціональне/ Зовнішнє / «Чорний ящик» проти Структурного/ Внутрішнього / «Білого ящика»
Вихід: Покриття проти основаного на використанні

*

Software Architecture and Design

Слайд 28Тестування: Чому?
Початкова мета: демонстрація належної поведінки чи демонстрація якості
~

«Тестування» у традиційних галузях
Доказ якості чи належної поведінки

*

Software Architecture and Design

Слайд 29 Нові цілі: виявлення дефектів та їх усунення:
*
Software Architecture and Design
Майже

бездефектне виробництво програмного забезпечення проти традиційного виробництва
Гнучкість програмного забезпечення (легкість зміни)
Спостереження за відмовою => Усунення несправності (виявлення дефектів => виправлення виправлення дефектів)
Затемнення початкової мети

Слайд 30Тестування: Як
Як? Запускаєм-спостерігаєм-подальша діяльність
(Особливо у випадку відмови спостережень)




*
Software Architecture and Design

Слайд 31Тестування: Діяльність та загальні процеси
Основна діяльність тестування:
планування та підготовка тестів
Виконання тестів

(Тестування)
Аналіз та наступна діяльність
Загальний процес:
Планування-виконання-аналіз-зворотній зв`язок
Вступні критерії: Зазвичай зовнішні
Вихідні критерії: Внутрішні та зовнішні
Деякі (малі) процеси зміни – але ми зосереджуємось на стратегіях та техніках

*

Software Architecture and Design

Слайд 32Планування тестування:
Цільове налаштування на основі перспектив та очікувань клієнтів по якості


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

*

Software Architecture and Design

Тестування: Планування та Підготовка

Слайд 33Виконання Тестування
Головні кроки виконання тесту:
Виділення часу на тест (та ресурси)
Застосування тесту
Виявлення

відмов систем (та збір інфомаціі для подальших дій)
Ключ до виконання: Обробка обох нормальних та ненормальних випадків
Oracle Проблема тестування

*

Software Architecture and Design

Слайд 34Тестування: Аналіз та подальша діяльність
Аналіз результатів тестування:
Перевірка результату (як частина виконання)
Подальший

аналіз результатів – аналіз на дефекти/надійність і т.д.
Інші аналізи: кількість дефектів та інші метрики

*

Software Architecture and Design

Слайд 35 Подальша діяльність
Зворотній зв`язок на основі результатів аналізу
Негайне: усунення дефекту (чи

ре-тестування)
Інша подальша діяльність (Довший термін):
Вибір рішення (Вихід з тестування і т.д.)
Вдосконалення процесів тестування, і т.д.

*

Software Architecture and Design

Слайд 36Тестування: як?
Як тестувати?
- Розподілимо на 3 набори запитань
Основні питання
Питання по техніці

тестування
Питання організації
Основні питання сьогодні
Які робочі проекти тестуються?
Що тестувати?
Коли припинити тестування?

*

Software Architecture and Design

10

Слайд 37Питання по техніці тестування
Питання по техніці тестування
Яка специфічна техніка використана?
Які систематичні

моделі використовуються?
Адаптація технік з інших галузей
Інтеграція заради підвищення ефективності.
Питання по моделі тестування:
Структурі моделі
Списки та кінцеві автомати
Як ці моделі використовуються?
Розширення моделей?

*

Software Architecture and Design

11

Слайд 38Питання організації тестування
Інші питання керування:
Хто і які виконує задачі?
Коли специфічні задачі

виконуються?
Автоматизація тестів? засоби
Спецтехніка, використовувана в управлінні тестуванням.
Тип продукту/сегменту

*

Software Architecture and Design

12

Слайд 39Дефекти в контексті забезпечення якості (ЗЯ)
Для більшості організацій забезпечення якості

означає боротьбу з дефектами:
Запобігання дефектам
Виявлення та усунення дефектів
Стримування дефектів

Вівторок, вересень 21, 2010

Якість та тестування програмного забезпечення

Слайд 40Вступ
Використовуючи методи QA ми здатні лише знизити кількість дефектів але не

повністю їх усунути

Слайд 41Ідеї від інших високо надійних систем
Для уникнення відмови зазвичай використовують запасні

частини та резервування даних

Слайд 42Ідеї від інших високо надійних систем
Якщо неможливо запобігти відмові упереджують катастрофу

Слайд 43Ідеї від інших високо надійних систем
Якщо неможливо запобігти катастрофі забезпечують полегшення

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

Слайд 44Два основні припущення про надійність систем
Припущення про рідкість події — відмови

та аварії мають надзвичайно малу ймовірність
Припущення про незалежність відмов — різні компоненти та підсистеми відмовляють незалежно одна від одної

Слайд 45Класифікація методів
Методи забезпечення відмовостійкості
та стримування дефектів
Методи відмовостійкості
Методи стримування дефектів


Дублювання
Резервне копіювання
Упередження

аварії

Зменшення шкоди аварії





Слайд 46Відмовостійкість за допомогою блоків відновлення
Блоки відновлення дублюють виконання програм так,

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

Слайд 47Основна діяльність
Створення контрольних точок – періодичне збереження динамічного вмісту виконання програми


Виявлення відмов – перед створенням контрольної точки виконується перевірка цілісності даних для перевірки чи не було відмов при виконанні програми

Слайд 48Якщо відмови виявлені
Вівторок, вересень 21, 2010
Якість та тестування програмного забезпечення
Виконується відкат

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

Слайд 49Проблеми блоків відновлення
Виявляють відмови та не усувають дефекти, що лежать

у основі
Необхідно змінити конфігурацію для повторного виконання
У випадку повторюваних відмов систему необхідно зупиняти та виправляти дефекти
Часті відмови сильно знижують продуктивність
При аналізі повторних виконань складно визначити чи воно викликане зовнішніми факторами чи дефектами в ПЗ

Слайд 50Балансування частоти контрольних точок
Висока частота призводить до високих витрат на оновлення

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

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

паралельно. Застосовується в системах, де час виконання є критичним

Слайд 52Основний метод програмування N-версій
Вівторок, вересень 21, 2010
Якість та тестування програмного забезпечення

Слайд 53Алгоритми прийняття рішень
Вівторок, вересень 21, 2010
Якість та тестування програмного забезпечення
Принцип більшості

– вихід системи є правильним якщо щонайменше полови на версій правильні і продукують правильний результат. Система відмовостійка до
N/2-1
Одна версія основна, а інші резервні – інші версії розглядаються якщо результат основної неправильний
Версії розділяються на групи і формують ієрархічну реалізацію

Слайд 54Основне припущення
Вівторок, вересень 21, 2010
Якість та тестування програмного забезпечення
Відмови у різних

версіях компонентів програмного забезпечення незалежні

Слайд 55Забезпечення незалежності версій
Вівторок, вересень 21, 2010
Якість та тестування програмного забезпечення
Різноманітність людей
Тип,

освіта, тренінги, участь у командах
Різноманітність процесів розробки
Різноманітність технології: методи, засоби
Різноманітність результату:
Проект – високий потенціал
Реалізація – низький потенціал

Слайд 56Шляхи забезпечення незалежності проектних рішень
Вівторок, вересень 21, 2010
Якість та тестування

програмного забезпечення

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

Слайд 57Забезпечення незалежності команд
Вівторок, вересень 21, 2010
Якість та тестування програмного забезпечення
Незалежність проектних

команд – незалежність версій
Забезпечення ізоляції проектних команд
Обов'язкові правила (що робити або не роботи)
Контроль над комунікаціями

Слайд 58Використання команди комунікації
Вівторок, вересень 21, 2010
Якість та тестування програмного забезпечення
Одна команда

комунікації на N проектных команд
Комунікації через команди комунікації:
Немає комунікації між двома проектними командами
Для команд комунікації необхідне спеціальне нвчання

Слайд 59Аналіз небезпек
Вівторок, вересень 21, 2010
Якість та тестування програмного забезпечення
Ідея дерева відмов
Найвища

подія (аварія)
Проміжні події/умови
Базові події/умови
Логічні зв'язки
Формування деревовидної структури
Елементи дерева відмов
Вузли: умови та підумови (термінальні та нетермінальні)
Логічні зв'язки між підумовами (or, and, not)




Слайд 60Приклад аналізу небезпек автомобільної аварії
Вівторок, вересень 21, 2010
Якість та тестування програмного

забезпечення

Слайд 61Запитання?
Вівторок, вересень 21, 2010
Якість та тестування програмного забезпечення

Похожие презентации

Вещественный тип данных, указатели, функции 357
Компьютерная графика 309
Расстояния между строками и меры близости 283
Основы технологии CUDA 398
Express.js 466
Автоматизированное рабочее место коменданта общежития БГПК 329

Обратная связь

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

Email: Нажмите что бы посмотреть 

Что такое ThePresentation.ru?

Это сайт презентаций, докладов, проектов, шаблонов в формате PowerPoint. Мы помогаем школьникам, студентам, учителям, преподавателям хранить и обмениваться учебными материалами с другими пользователями.

Для правообладателей

Яндекс.Метрика