- •Щотакетестування?
- •Техніки, що базуються на специфікаціях.
- •Альфа та бета тестуваня.
- •5. Тесты на основе конечного автомата (Finite-state machine-based)
- •7. Дефект - неправильний крок, процес чи визначення даних в комп'ютерній програмі
- •8. Тестування на основі формальних специфікацій.
- •9. Случайное тестирование (Random testing)
- •Тестування, орієнтоване на дефекти.
- •11.Тестування мутацій.
- •Збої та відмови.
- •14.Тестування продуктивності.
- •15.Стрес тестування.
- •16.Системне тестування.
- •17.Методологія покращення якості.
- •Вимірювання, пов’язані з тестуванням.
- •19.Випадкове тестування.
- •20.Техніки орієнтовані на код.
- •3.3 Техники, ориентированные на код (Code-based techniques)
- •21. Система відслідковування проблем
- •22. Класифікація дефектів за серйозністю:
- •24. Тестуванняконфігурації.
- •25. Модульнетестування.
- •26. Тестуваннязручностівикористання (usability).
- •27. Звіти по помилках.
- •28. Метрики дефектів.
- •29. Тестуванняграфічногоінтерфейсукористувача.
- •30. Метрики динамікизнаходження дефектів.
- •Виконання тестів.
- •Модель процесу тестування.
- •Управління тестуванням.
- •Інструменти тестування.
- •Метрики покриття.
- •Статистичне тестування.
- •Класифікація інструментів тестування.
- •Спеціалізоване тестування.
- •41. Планування тестування.
- •42. Створення тестів (test-cаse).
- •43. Засоби (середовища) тестування.
- •44. Критерії вибору тестів.
- •45. Проведення тестування.
- •Порівняльне тестування.
- •47. Ефективність проведення тестування.
- •48. Функціональне тестування.
- •49.Тестування Web-застосувань.
- •50.Тестування та визначення дефектів.
- •Метрики підрахунку дефектів.
- •Проблеми оракула.
- •Обмеження при проведенні тестування.
- •Тести, що базуються на блок-схемі.
- •Тестування інсталяцій.
- •Зв’язок тестування з іншими видами діяльності по розробці.
- •Метод білої скриньки.
- •Рівні тестування (послідовність).
- •2. Уровни тестирования (Test Levels)
- •2.1.1 Модульное тестирование (Unit testing)
- •2.1.2 Интеграционное тестирование (Integration testing)
- •2.1.3 Системное тестирование (System testing)
- •Вимірювання, що базуються на концепції функціонального розміру.
- •Метод чорної скриньки.
- •Цілі тестування.
- •Метод сірої скриньки.
- •Регресійне тестування.
- •Інтеграційне тестування.
- •Тестування, що базується на досвіді та інтуїції.?
- •66.Порівняння методів чорної та білої скриньки.
- •67.Аналіз граничних значень.
- •68.Основи тестування.
- •69.Техніки, що базуються на аналізі коду.
- •70.Порівняння збоїв та відмов.
28. Метрики дефектів.
-
Open/Closed Bugs
Метрика показывает отношение количества открытых багов к закрытым (исправленным и перепроверенным)
-
Reopened/ClosedBugs
Метрика показывает отношение количества переоткрытых багов к закрытым (исправленным и перепроверенным)
-
Rejected/OpenedBugs
Метрика показывает отношение количества отклоненных багов к открытым
-
BugsbySeverity
Количество багов по серьезности
-
BugsbyPriority
Количество багов по приоритету
29. Тестуванняграфічногоінтерфейсукористувача.
Тестирование графического интерфейса пользователя предполагает проверку соответствия приложения требованиям к графическому интерфейсу, профессионально ли оно выглядит, выполнено ли оно в едином стиле.
В большинстве случаев, функциональное тестирование приложения осуществляется вместе со следующими видами тестирования графического интерфейса пользователя:
-
Тестирование на соответствие стандартам графических интерфейсов;
-
Тестирование с различными разрешениями экрана;
-
Тестирование в ограниченных условиях, например, в условиях нехватки памяти;
-
Совместимость с различными Интернет-браузерами;
-
Тестирование локализованных версий: точность перевода, проверка длины названий элементов интерфейса и т.д.;
-
Тестирование графического интерфейса пользователя на целевых устройствах (для КПК-совместимых приложений).
30. Метрики динамікизнаходження дефектів.
Метрики якості процесів
• Вимірювання частоти дефектів під час тестування – чим більше дефектів виявлено під час тестування, тим більше їх буде при використанні
• Вимірювання динаміки виявлення дефектів на протязі часу
• Вимірювання дефектів по фазах життєвого циклу
Ефективність видалення дефектів (DRE)
31. Розробка, керована тестуванням (Test-driven development).
-
Можна не писати код продукції, якщо написано перший невдалий модульний тест
-
Можна більше не писати модульних тестів, ніж достатньо для провалу
-
Можна більше не писати коду ніж потрібно для того щоб невдалий модульний тест було пройдено
-
Виконання тестів.
1. Начинать выполнение тестов с самых важных
a. Проверка правильности работы основных сценариев
b. Выполнение регрессионного тестирования (закрытие исправленных дефектов)
c. Прогон эффективных тестов (например, тестов частей программы, изменявшихся в последней сборке)
2. Лабораторные испытания
a. Подготовить тестовые данные и стенды
3. Помнить что до 80% ошибок будут переоткрыты после исправления
4. Не забывать обновлять сценарии тестирования. Добавлять тесты для новой функциональности, оптимизировать старые тесты.
5. Если остается время после выполнения формального тестирования, заняться исследовательским (неформальным/интуитивным) тестированием.
-
Модель процесу тестування.
Причини для модульного тестування в автономній манері:
-
Знайдена помилка асоціюється з визначеного модулю і так її легше виправити
-
Під час тестування бажано перевіряти чи приносить виконання певного модуля бажані результати. В ідеалі виконання всіх можливих (або максимально можлива кількість) випадків повинне бути розглянуто підчас тестування. Це вимагає обережно обирати вхідні дані для кожного виконання.
-
Виконати кожну стрічку коду. За відсутності такого спостереження, сюрпризи можуть дуже дорого коштувати.
-
Виконати кожен предикат
в модулі, для того щоб
оцінити його істинність чи хибність.
-
Важливим є виконання модулем своїх функцій та забезпечення відсутності в них відомих помилок.
Попередньо проведене модульне тестування не дає гарантій що програма буде працювати вірно в цілому. Але це не означає що його не потрібно проводити. Немає сенсу інтегрувати помилкові модулі через такі причини:
-
Багато з наступних тестів будуть марною тратою ресурсів
Пошук корінних причин невдач у інтегрованої системи є більш ресурсномістким