7. 7
Quick Attacks
Сильні сторони:
• Дозволяє виконувати швидкий аналіз у
стиснуті терміни.
• Дієвий спосіб познайомитися з системою,
навіть при відсутності специфікації
• Підхід для отримання розвитку і досвіду
• Швидка оцінка системи чи її компонентів.
• Спосіб виявити слабкі місця продукту.
Слабкі сторони або обмеження:
• Пошук помилок, які можуть мати низкий
рівень важливості.
• Спрощений підхід (Примітивний).
8. 8
Equivalence and Boundary Conditions
Сильні сторони:
• Зменшення нескінченного тестового набору
(керованність тестовими наборами)
• Механізм для охоплення вимог
(Забезпечення покриття).
Слабкі сторони або обмеження:
• Недоцільно використовувати з логічними
типами данних.
• Зі збільшенням діапазону значень може
падати ефективність тестів
9. 9
Common Failure Modes
Сильні сторони:
• Допомагає виявити загальні проблеми для
платформи, проекту або команди.
• Дозволяє швидко реагувати на повторювані
дефекти.
Слабкі сторони або обмеження:
• З плином часу втрачає свою ефективність.
• Підхід тісно переплітається з наявним
досвідом команди.
10. 10
State-Transition Diagrams
Сильні сторони:
• Наочне або табличне представлення
поведінки системи, що дозволяє перевірити
рівень охоплення проілюстрованих умов.
• Експертиза на снові командної оцінки
діаграм допомагає знайти прогалини вимог,
дефекти і різні очікування серед членів
команди.
Слабкі сторони або обмеження:
• Наочне або табличне представлення може
не відображати, як працює програмне
забезпечення насправді.
• Ілюзію достовірності
• Для великих систем складно зобразити усі
стани системи.
11. 11
Soap Opera Tests
Сильні сторони:
• Підхід “Soap Opera “ дозволяє уникати
покрокових інструкцій з очікуванним
результатом.
• “Історії” дозволяють збільшити свободу і
зменьшити обсяг тестів.
• Підхід для виялення непередбачених
проблем на основі гіперболізованих
(перебільшенних, драматичних) сценаріїв
• Підхід дозволяє у стиснуті терміни
випробувати велику кількість
функціональних аспектів системи
Слабкі сторони або обмеження:
• Залежить тільки від навичок творця.
• Часто потребує взаємодії з досвідченими
користувачами.
12. 12
Use Cases
Сильні сторони:
• Візуалізація взаємодії між актором і
системою від початку і до кінця, для
досягнення конкретної задачі.
• Дієвий спосіб виявити дефекти інтеграції.
• Опис набільшімовірного використання
системи, включаючи основний і додаткові
(альтернативні) сценарії.
• Включає передумови, післяумови та опис
кінцевого стану системи.
Слабкі сторони або обмеження:
• Погано підходять для документування
вимог не заснованих на взаємодії з
системою (таких як алгоритм або
математичні вимоги) або нефункціональних
вимог (такі як платформа, продуктивність,
синхронізація, безпека).
• Залежить тільки від навичок творця.
• Формальний тип документів
13. 13
Code-Based Coverage Models
Сильні сторони:
• Перевірка коду що дозволяє оцінити
відсоток покриття операторів (тверджень) а
також покриття умов.
Слабкі сторони або обмеження:
• Потребує спеціальних навичок або знань
• Не гарантує що вся логіка буде перевірена.
• Забезспечує не повне покриття.
14. 14
Regression and High-Volume Test Techniques
Сильні сторони:
• Сбір і аналіз повторюваних результатів
• Ефективний підхід оцінки ризиків
пов'язаних зі змінами.
• Підхід що дозволяє порівнювати поведінку
програмного забезпечення для різних
версій.
Слабкі сторони або обмеження:
Ресурсномісткі техніки.
Потребують автоматизації і роботизації.
Необхідне покритя тестами навіть при
незначних змінах у коді.