Похожие презентации:
Основи тестування програмного забезпечення
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