what is stlc v model
Що таке VLC-модель STLC?
Один з головних недоліків модель водоспаду STLC полягало в тому, що дефекти були виявлені на дуже пізній стадії процесу розробки, оскільки тестування проводилося в кінці циклу розробки. Виправити дефекти стало дуже складно і дорого, оскільки виявлено було на дуже пізній стадії. Щоб подолати цю проблему, була введена нова модель розвитку під назвою «V-модель»
V-модель зараз є одним із найбільш широко використовуваних процесів розробки програмного забезпечення. Впровадження V-моделі фактично довело здійснення тестування вже з фази вимог. V-модель також називається моделлю перевірки та перевірки.
Що ви дізнаєтесь:
Перевірка та перевірка
Щоб зрозуміти модель V, давайте спочатку зрозуміємо, що таке перевірка та перевірка в програмному забезпеченні.
Перевірка : Верифікація - це метод статичного аналізу. У цій техніці тестування проводиться без виконання коду. Серед прикладів - Огляди, перевірка та покрокове керівництво.
Перевірка : Перевірка - це метод динамічного аналізу, коли тестування проводиться шляхом виконання коду. Прикладами є функціональні та нефункціональні методи тестування.
V-модель
У моделі V розробка та перевірка якості здійснюються одночасно. Не існує дискретної фази, яка називається тестуванням, швидше тестування починається безпосередньо з фази вимог. Діяльність з перевірки та валідації йде паралельно.
Щоб зрозуміти модель V, давайте подивимось на малюнок нижче:
вставка та видалення двійкового дерева в Java
У типовому процесі розробки ліва сторона показує розробки, а права - тестування. Я не повинен помилятися, якщо кажу, що на етапі розробки виконуються як перевірка, так і перевірка разом із реальними заходами з розробки.
Тепер давайте розберемося з цифрою:
Ліва сторона
Як було сказано раніше, лівосторонні заходи - це діяльність з розвитку. Зазвичай ми відчуваємо, яке тестування ми можемо зробити на етапі розробки, але в цьому полягає краса цієї моделі, яка демонструє, що тестування також можна проводити на всіх етапах розробки.
Аналіз вимог : На цьому етапі вимоги збираються, аналізуються та вивчаються. Тут не важливо, як впроваджується система, але важливо те, що система повинна робити. Сеанси штурму мозку / проходження, інтерв’ю проводяться, щоб цілі були чіткими.
- Діяльність з перевірки : Огляди вимог.
- Діяльність з перевірки : Створення UAT ( Тест прийнятності користувача ) тестові кейси
- Вироблені артефакти : Документ, що розуміє вимоги, тести UAT.
Системні вимоги / Дизайн високого рівня : На цьому етапі створено високорівневий дизайн програмного забезпечення. Команда вивчає та досліджує, як ці вимоги можуть бути реалізовані. Також вивчається технічна доцільність вимог. Команда також пропонує модулі, які створюються / залежності, обладнання / програмне забезпечення
- Діяльність з перевірки : Огляди дизайну
- Діяльність з перевірки : Створення План тестування системи та кейси, Створення метрик простежуваності
- Вироблені артефакти : Тестові приклади системи, звіти щодо техніко-економічного обґрунтування, план тестування системи, вимоги до програмно-апаратного забезпечення, модулі, що створюються тощо.
Архітектурне проектування: На цьому етапі заснований на високому рівні дизайн , створюється архітектура програмного забезпечення. Модулі, їх взаємозв'язки та залежності, архітектурні схеми, таблиці баз даних, технологічні деталі завершуються на цьому етапі.
- Діяльність з перевірки : Огляди дизайну
- Діяльність з перевірки : План інтеграційного тестування та тестові кейси.
- Вироблені артефакти : Проектна документація, План інтеграційного тестування та тести, Дизайн таблиць баз даних тощо.
Дизайн модуля / Дизайн низького рівня: На цьому етапі кожен модуль програмних компонентів розробляється індивідуально. Методи, класи, інтерфейси, типи даних тощо завершуються на цьому етапі.
- Діяльність з перевірки : Огляди дизайну
- Діяльність з перевірки : Створення та огляд модульних тестових кейсів.
- Вироблені артефакти : Одиничні тестові кейси,
Впровадження / Кодекс : На цьому етапі виконується власне кодування.
- Діяльність з перевірки : Перегляд коду, огляд тестових кейсів
- Діяльність з перевірки : Створення функціональних кейсів.
- Вироблені артефакти : тестові кейси, огляд контрольного списку.
Правосторонній
Права сторона демонструє тестування або фазу перевірки. Почнемо знизу.
Одиничне тестування: На цьому етапі виконуються всі модульні тестові кейси, створені на етапі проектування низького рівня.
* Модульне тестування - це техніка білого вікна тестування, де пишеться фрагмент коду, який викликає метод (або будь-який інший фрагмент коду), щоб перевірити, дає фрагмент коду очікуваний результат чи ні. Це тестування в основному проводиться командою розробників. У разі будь-якої аномалії дефекти реєструються та відстежуються.
Вироблені артефакти : Результати виконання модульного тесту
Інтеграційне тестування : На цьому етапі виконуються тестові випадки інтеграції, які були створені на етапі архітектурного проектування. У разі будь-яких аномалій дефекти реєструються та відстежуються.
* Інтеграційне тестування: Інтеграційне тестування - це техніка, коли модульні тестовані модулі інтегруються та перевіряються, чи забезпечують інтегровані модулі очікувані результати. Простішими словами, він перевіряє, чи працюють компоненти програми разом, як очікувалося.
Вироблені артефакти : Результати інтеграційного тесту.
Тестування систем : На цьому етапі виконуються всі системні тести, функціональні тести та нефункціональні тести. Іншими словами, тут відбувається фактичне та повне тестування заявки. Дефекти реєструються та відстежуються для його закриття. Звітність про прогрес також є основною частиною цього етапу. Показники простежуваності оновлюються для перевірки охоплення та зменшення ризику.
Вироблені артефакти : Результати випробувань, журнали випробувань, звіт про дефекти, звіт про випробування та оновлені матриці простежуваності.
Тестування прийняття користувача : Прийомне тестування в основному пов'язане з тестуванням бізнес-вимог. Тут проводиться тестування, щоб перевірити, чи відповідають бізнес-вимоги в середовищі користувача. Тестування на сумісність, а іноді і нефункціональне тестування ( Навантаження, стрес і обсяг ) тестування також проводиться на цьому етапі.
Вироблені артефакти : Результати UAT, оновлені матриці охоплення бізнесу.
Коли використовувати V-модель?
V-модель застосовується, коли:
- Вимога чітко визначена і не є двозначною
- Критерії прийнятності чітко визначені.
- Проект короткий до середнього розміру.
- Використовувані технології та інструменти не є динамічними.
Плюси та мінуси використання моделі V
| Плюси | ПРОТИВ |
|---|---|
| - Розвиток і прогрес дуже організований і систематичний | -Не підходить для великих та складних проектів |
| - Добре працює для малих та середніх проектів. | - Не підходить, якщо вимоги не узгоджуються. |
| - Тестування починається з самого початку, тому неоднозначності виявляються з самого початку. | - На проміжному етапі не виробляється робоче програмне забезпечення. |
| - Легке управління, оскільки кожна фаза має чітко визначені цілі та цілі. | - Не передбачено проведення аналізу ризиків, тому існує невизначеність та ризики. |
Рекомендована література
- Підручник з тестування SOA: Методологія тестування для архітектурної моделі SOA
- Найкращі засоби тестування програмного забезпечення 2021 р. (Інструменти автоматизації тестування якості)
- Статичне тестування та динамічне тестування - різниця між цими двома важливими методами тестування
- Спіральна модель - що таке спіральна модель SDLC?
- Практичне тестування програмного забезпечення - Нова БЕЗКОШТОВНА електронна книга (Завантажити)
- Альфа-тестування та бета-тестування (повний посібник)
- Завантажити тестувальник електронних книг
- На місці - офшорна модель проектів тестування програмного забезпечення (і як змусити це працювати для вас)