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

1. Лекція 9: основи Тестування програмного забезпечення

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

2.

2
Тестування: поняття та процес
Тестування: споріднені питання
Дефекти при тестуванні
Види тестування
Software Architecture and Design
Thursday, June 29, 2017

3. Визначення тестування і пов'язаної з ним термінології

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

4. Визначення тестування і пов'язаної з ним термінології

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

5. Визначення тестування і пов'язаної з ним термінології

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

6. Визначення тестування і пов'язаної з ним термінології

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

7. Визначення тестування і пов'язаної з ним термінології

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

8. Визначення тестування і пов'язаної з ним термінології

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

9. Визначення тестування і пов'язаної з ним термінології

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

10. Визначення тестування і пов'язаної з ним термінології

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

11. Визначення тестування і пов'язаної з ним термінології

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

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

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

13. Помилки та відмови

13
Стандарти:
IEEE Standard 610.12-1990
Standard
Glossary
of
Software
Engineering Terminology (IEEE610-90)

14. Дефекти та відмови

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

15. Дефекти та відмови

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

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

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

17. Тестування ефективності / цілі для тестування

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

18. Тестування для визначення дефекту

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

19. Проблема Оракула

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

20. Теоретичні та практичні обмеження тестування

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

21. Проблема неможливих гілки

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

22. Тестоспроможність

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

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

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

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

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

25. Тестування та альтернатива забезпеченню якості

25
Дефекти та забезпечення якості:
Запобігання дефектів:
Блокування помилок та видалення джерела помилки
Усунення дефектів:
Дефекти: помилка\ несправність\ відмова
Дефекти: запобігання\ усунення\ стримування
План до основної діяльності по забезпеченню якості
Тестування
Інспекція
Стримування дефектів: відмовостійкість та стримування
відмов
Software Architecture and Design
Thursday, June 29, 2017

26. Забезпечення Якості та Тестування

26
Тестування як частина Забезпечення якості:
Діяльність спрямована на стадії тестування
Забезпечення якості/тестування у каскаді та V-моделі
Одна с найважливіших частин Забезпечення якості –
усунення недоліків
Software Architecture and Design
Thursday, June 29, 2017

27.

27
Тестування: Ключові питання:
Чому: Демонстрація якості проти виявлення дефектів
та їх усунення
Як: Методи/ Діяльність/ Процес
Огляд: Функціональне/ Зовнішнє / «Чорний ящик»
проти Структурного/ Внутрішнього / «Білого ящика»
Вихід: Покриття проти основаного на використанні
Software Architecture and Design
Thursday, June 29, 2017

28. Тестування: Чому?

28
Початкова мета: демонстрація належної
поведінки чи демонстрація якості
~ «Тестування» у традиційних галузях
Доказ якості чи належної поведінки
Software Architecture and Design
Thursday, June 29, 2017

29. Нові цілі: виявлення дефектів та їх усунення:

29
Нові цілі: виявлення дефектів та їх
усунення:
Майже бездефектне виробництво програмного
забезпечення проти традиційного виробництва
Гнучкість програмного забезпечення (легкість
зміни)
Спостереження за відмовою => Усунення
несправності (виявлення дефектів => виправлення
виправлення дефектів)
Затемнення початкової мети
Software Architecture and Design
Thursday, June 29, 2017

30. Тестування: Як

30
Як? Запускаєм-спостерігаєм-подальша
діяльність
(Особливо у випадку відмови спостережень)
Software Architecture and Design
Thursday, June 29, 2017

31. Тестування: Діяльність та загальні процеси

31
Основна діяльність тестування:
планування та підготовка тестів
Виконання тестів (Тестування)
Аналіз та наступна діяльність
Загальний процес:
Планування-виконання-аналіз-зворотній зв`язок
Вступні критерії: Зазвичай зовнішні
Вихідні критерії: Внутрішні та зовнішні
Деякі (малі) процеси зміни – але ми
зосереджуємось на стратегіях та техніках
Software Architecture and Design
Thursday, June 29, 2017

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

32
Планування тестування:
Цільове налаштування на основі
перспектив та очікувань клієнтів по якості
Загальна стратегія на онові характеристик
продукту/оточення
Підготовка тестування:
Підготовка тестових випадків та наборів–
зазвичай на основі формальних моделей
Підготовка процедури випробувань
Software Architecture and Design
Thursday, June 29, 2017

33. Виконання Тестування

33
Головні кроки виконання тесту:
Виділення часу на тест (та ресурси)
Застосування тесту
Виявлення відмов систем (та збір
інфомаціі для подальших дій)
Ключ до виконання: Обробка обох
нормальних та ненормальних випадків
Oracle Проблема тестування
Software Architecture and Design
Thursday, June 29, 2017

34. Тестування: Аналіз та подальша діяльність

34
Тестування: Аналіз та подальша
діяльність
Аналіз результатів тестування:
Перевірка результату (як частина
виконання)
Подальший аналіз результатів –
аналіз на дефекти/надійність і т.д.
Інші аналізи: кількість дефектів та
інші метрики
Software Architecture and Design
Thursday, June 29, 2017

35. Подальша діяльність

35
Зворотній
зв`язок на основі результатів
аналізу
Негайне: усунення дефекту (чи ретестування)
Інша подальша діяльність (Довший
термін):
Вибір рішення (Вихід з тестування і т.д.)
Вдосконалення процесів тестування, і
т.д.
Software Architecture and Design
Thursday, June 29, 2017

36. Тестування: як?

10
Як тестувати?
- Розподілимо на 3 набори запитань
Основні питання
Питання по техніці тестування
Питання організації
Основні питання сьогодні
Які
робочі проекти тестуються?
Що тестувати?
Коли припинити тестування?
Software Architecture and Design
Thursday, June 29, 2017

37. Питання по техніці тестування

11
Питання по техніці тестування
Яка специфічна техніка використана?
Які систематичні моделі використовуються?
Адаптація технік з інших галузей
Інтеграція заради підвищення ефективності.
Питання по моделі тестування:
Структурі моделі
Списки та кінцеві автомати
Як ці моделі використовуються?
Розширення моделей?
Software Architecture and Design
Thursday, June 29, 2017

38. Питання організації тестування

12
Інші питання керування:
Хто і які виконує задачі?
Коли специфічні задачі виконуються?
Автоматизація тестів? засоби
Спецтехніка, використовувана в
управлінні тестуванням.
Тип продукту/сегменту
Software Architecture and Design
Thursday, June 29, 2017

39.

39
Дефекти в контексті забезпечення
якості (ЗЯ)
Для більшості організацій забезпечення якості
означає боротьбу з дефектами:
Запобігання
дефектам
Виявлення
та усунення дефектів
Стримування
дефектів
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

40. Вступ

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

41. Ідеї від інших високо надійних систем

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

42. Ідеї від інших високо надійних систем

Якщо неможливо запобігти відмові
упереджують катастрофу

43. Ідеї від інших високо надійних систем

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

44. Два основні припущення про надійність систем

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

45. Класифікація методів

Методи забезпечення відмовостійкості
та стримування дефектів
Методи відмовостійкості
Дублювання
Резервне копіювання
Методи стримування дефектів
Упередження аварії
Зменшення шкоди аварії

46. Відмовостійкість за допомогою блоків відновлення

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

47. Основна діяльність

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

48. Якщо відмови виявлені

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

49. Проблеми блоків відновлення

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

50. Балансування частоти контрольних точок

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

51. Відмовостійкість за допомогою програмування N-версій

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

52. Основний метод програмування N-версій

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

53. Алгоритми прийняття рішень

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

54. Основне припущення

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

55. Забезпечення незалежності версій

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

56. Шляхи забезпечення незалежності проектних рішень

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

57. Забезпечення незалежності команд

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

58. Використання команди комунікації

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

59. Аналіз небезпек

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

60. Приклад аналізу небезпек автомобільної аварії

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

61.

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