White-box testing techiniques

Привіт друзі! Пам’ятаєте, ми писали низку статей про техніки тест дизайну? Тепер їх всі можна знайти за тегом #testdesign. І знаєте, що об’єднувало всі згадані нами техніки? Всі вони – black-box. Тобто тестер може не знати, як влаштоване ПЗ, що тестується і опиратись виключно на вимоги та здоровий глузд.
Думаю, зараз гарний момент, щоб освітити кілька технік white-box тестування для відновлення балансу в силі (не вірю, але в телеграмі немає жодного смайлу про зоряні війни 🤷‍♂️)

Statement Testing and Coverage
Задача техніки – розробити тести таким чином, що покрити якомога більше дій (statements) в коді програми. Покриття вираховується як відношення кількості дій, покритих тестами до загальної кількості дій в коді програми.

Decision Testing and Coverage
Задача техніки – розробити тести таким чином, що покрити якомога більше переходів/рішень між діями. Переходом вважається будь який умовний перехід чи цикл (IF – THEN – ELSE, WHILE-DO, FOR). Покриття вираховується як відношення кількості переходів, покритих тестами до загальної кількості переходів в коді програми.
І, до речі, 100% Decision покриття гарантує 100% Statement покриття, але не навпаки.

Для більш зручного процесу тест дизайну, код програми можна зобразити у вигляді графу чи блок схеми, щоб наглядно прорахувати всі варіанти.

Коли тестеру варто це робити? Коли є час та натхнення 😃 А якщо серйозно – тоді, коли цього вимагає ваш тест план (наприклад, для тестування safety critical систем), чи система дуже складна, чи нестабільна.

Як це робити? Гарне питання. Ми з коллегами вважаємо, що в 2020 навички програмування (чи як мінімум читання коду) переходять з категорії “буде плюсом” в категорію must have навіть для мануального тестера (давайте подискутуємо, якщо ви іншої думки!). А ще, як варіант, ви можете дизайнити тести разом з розробником, що писав код – щоб вам наглядно показали всі дії та переходи.

Хочете більше white-box технік?

13 July 2020
Автор: 
Oleksii Ostapov

Leave a comment

Leave a Reply