Вступ до матриці відстеження вимог
Завершення проекту є викликом для кожної фірми, і кожен проект має різні вимоги та підходи, кожен може завершити проект вчасно, коли кожна вимога буде проаналізована належним чином. Таким чином, щоб зробити проект легким і виконати всі вимоги, ми використовуємо RTM (матрицю простеження вимог). RTM - це документ або таблиця, що посилаються на вимоги протягом процесу перевірки. Мета Матриці простежуваності вимог - забезпечити тестування всіх вимог, визначених для системи, у життєвому циклі.
Визначення матриці відстеження вимог
Матриця відстеження вимог, яку зазвичай називають RTM, - це документ або таблиця, яка занесена до вимог клієнтів для проекту в роботі. Це простий тип матриці зі структурою рядків та стовпців, яка чітко визначає, яка вимога виконується та яка змінюється між процесом. Таким чином, у цілому RTM ми простежуємо тестові випадки щодо вимог клієнта та переглядаємо недоліки в вимозі під час процесу.
Чому потрібна матриця відстеження вимог?
Існує ряд переваг RTM, перш за все, як ми обговорювали вище, що це використовується для відстеження вимог клієнтів, а також ми можемо знайти недоліки в вимозі, якщо такі є. Крім того, RTM надає якість проекту, оскільки цим усуваються різні дефекти, а також, якщо між тестом є якісь зміни в вимозі, ми можемо легко змінити це і заощадити час та енергію. Ці речі дуже допомагають завершити проект вчасно та швидше.
Види матриці відстеження вимог
Давайте розглянемо різні матриці простежуваності.
Вперед простежуваність
Простежуваність вперед - це тип матриці відстеження, він допоможе менеджеру проаналізувати та впевнитись, що проект проходить безперебійно у правильному напрямку та перевіряються всі вимоги, які надає клієнт.
Відстава простежуваність
Це ще один тип матриць, який запевняє менеджера в тому, що сфера проекту не розширена або вимога, яка існує, суворо дотримується без додавання зайвих випадків або функцій, які можуть не входити в проект.
Секційна простежуваність Bidi
Цей тип простежуваності допомагає менеджеру відобразити вимоги до тестування випадків як для прямої, так і назад простежуваності в одному документі. Таким чином, цей тип забезпечує правильність перевірки всіх вимог.
Приклади матриці простеження вимог
|
Вимога бізнесу ні . |
Опис |
|
BR1 | Деякі вимоги бізнесу отримані від клієнта щодо доступності моніторингу в режимі реального часу. |
|
BR2 | Вимога власника бізнесу щодо детальної інформації про працівників на екрані. |
|
BR3 | Вимога користувача від зміни теми екрана. |
|
BR4 | Деякі інші вимоги бізнесу. |
Скажімо, TS1 (BR1) - надається можливість моніторингу в режимі реального часу.
Тестові справи
Тестовий випадок 1: Параметр TS1.TC1 (BR1) успішно виконаний.
Тестовий випадок 2: Параметр TS1.TC2 (BR1) вимкнено.
Дефекти
Тож при виконанні виявленого дефекту, як-от моніторинг у режимі реального часу, не працює належним чином і дані не оновлюються після кожної секунди, таким чином генерується ідентифікатор дефекту для вирішення цієї конкретної проблеми.
Скажімо, X01, тому цей ідентифікатор відображається в матриці, щоб показати дефект.
Матриця простеження покриття та вимог
Покриття тесту визначається як процес, під час якого ми перевіряємо, які вимоги є клієнтом та які вимоги слід перевірити, коли процес тестування починається. Зазвичай це робиться, щоб виключити ймовірність дефекту в проекті.
Щоб досягти повного покриття тесту, потрібно встановити "простежуваність вимог". У якому відображені всі дефекти.
Види технічних характеристик
1. Документ щодо специфікації програмного забезпечення
2. Бізнес-вимога
3. Використовуйте документ справи
4. Документ про вимоги проекту
5. Документи перевірки дефектів
Переваги
- Щоб перевірити, чи досягнуто 100% тестового покриття.
- Визначити вплив тестових випадків на регресію легко.
- Це допомагає нам видалити сферу відсутньої функціональної вимоги.
- Це робить оцінку проекту легкою та простою.
Як створити матрицю відстеження вимог?
RTM, як обговорювалося вище, - це документ із рядками та стовпцями, який містить тестове покриття про різні вимоги та дефекти, виявлені в цьому. В основному для створення RTM слід мати доступ до Microsoft Excel, оскільки він містить усі необхідні інструменти, необхідні для виготовлення матриці.
Крім того, знання Excel є дуже корисним, оскільки для створення матриці використовуються різні інструменти, а також існують різні формули, тож якщо хтось має знання про це, він легко робить матрицю та виконує ту саму. Ось приклад RTM:
Важливі пункти, які слід пам’ятати
- Переконайтесь, що кожна вимога повністю занесена до матриці під час виготовлення матриці.
- Представлення матриці повинно бути таким, воно повинно бути легко зрозумілим, можна використовувати інше поєднання кольорів для позначення різних сегментів у матриці.
- Дефекти повинні бути належним чином вказані в матриці, з належним ідентифікатором.
Висновок
RTM (матриця простежуваності вимог) - це найкращий спосіб виконати всі вимоги клієнта в проекті, при цьому, якщо в процесі тестування буде виявлений дефект, він буде видалений з процесу, щоб він не завдав шкоди проекту. До цього часу це ефективний інструмент для оцінки проекту. Мислення, необхідне під час виготовлення матриці, полягає в тому, щоб матриця показувала всю специфікацію або вимогу проекту, і все тестове покриття повинно бути зазначено належним чином у матриці, окрім того, що ідентифікатор дефекту повинен бути належним і повинен відповідати вимозі в що це знайдено. Дані слід правильно проаналізувати та скласти окремий звіт про те, чому виникають ці дефекти та як слід усунути сферу застосування цих дефектів. Ці речі роблять оцінку проекту сильною, а виконання проекту також буде простим. Отже, нарешті, можна сказати, що хороший RTM - це трейлер хорошого проекту.
Рекомендовані статті
Це було керівництвом щодо матриці простеження вимог на прикладі. Тут ми обговорили поняття, типи, покриття тесту та як створити матрицю простеження вимог із прикладами. Ви також можете ознайомитися з іншими запропонованими нами статтями, щоб дізнатися більше -
- Що таке плагін Maven?
- Переваги використання селену
- Що таке КПП?