Тестирование программного обеспечения. Базовый курс. 3-е издание


Связанное с тест-кейсом требование



Pdf көрінісі
бет154/307
Дата03.07.2023
өлшемі5,03 Mb.
#179304
1   ...   150   151   152   153   154   155   156   157   ...   307
Байланысты:
Software Testing - Base Course (Svyatoslav Kulikov) - 3rd edition - RU

Связанное с тест-кейсом требование
(requirement) 
показывает то основное 
требование, проверке выполнения которого посвящён тест-кейс (основное — по-
тому, что один тест-кейс может затрагивать несколько требований). Наличие этого 
поля улучшает такое свойство тест-кейса, как прослеживаемость
{143}

Частые вопросы, связанные с заполнением этого поля, таковы: 

Можно ли его оставить пустым? Да. Тест-кейс вполне мог разрабатываться 
вне прямой привязки к требованиям, и (пока?) значение этого поля опреде-
лить сложно. Хоть такой вариант и не считается хорошим, он достаточно рас-
пространён. 

Можно ли в этом поле указывать несколько требований? Да, но чаще всего 
стараются выбрать одно самое главное или «более высокоуровневое» 
(например, вместо того, чтобы перечислять R56.1, R56.2, R56.3 и т.д., можно 
просто написать R56). Чаще всего в инструментах управления тестами это 
поле представляет собой выпадающий список, где можно выбрать только 
одно значение, и этот вопрос становится неактуальным. К тому же многие 
тест-кейсы всё же направлены на проверку строго одного требования, и для 
них этот вопрос также неактуален. 
Модуль и подмодуль приложения
(module and submodule) 
указывают на 
части приложения, к которым относится тест-кейс, и позволяют лучше понять его 
цель. 
Идея деления приложения на модули и подмодули проистекает из того, что 
в сложных системах практически невозможно охватить взглядом весь проект цели-
ком, и вопрос «как протестировать это приложение» становится недопустимо слож-
ным. Тогда приложение логически разделяется на компоненты (модули), а те, в 
свою очередь, на более мелкие компоненты (подмодули). И вот уже для таких не-
больших частей приложения придумать чек-листы и создать хорошие тест-кейсы 
становится намного проще. 
Как правило, иерархия модулей и подмодулей создаётся как единый набор 
для всей проектной команды, чтобы исключить путаницу из-за того, что разные 
люди будут использовать разные подходы к такому разделению или даже просто 
разные названия одних и тех же частей приложения. 
Теперь — самое сложное: как выбираются модули и подмодули. В реально-
сти проще всего отталкиваться от архитектуры и дизайна приложения. Например, 
в уже знакомом нам приложении
{60}
 
можно выделить такую иерархию модулей и под-
модулей: 

Механизм запуска: 
o
механизм анализа параметров; 
o
механизм сборки приложения; 
o
механизм обработки ошибочных ситуаций. 

Механизм взаимодействия с файловой системой: 
o
механизм обхода дерева SOURCE_DIR; 
o
механизм обработки ошибочных ситуаций. 


Атрибуты (поля) тест-кейса
Тестирование программного обеспечения. Базовый курс. 
© EPAM Systems, 2015–2023
 
Стр: 126/301 

Механизм преобразования файлов: 
o
механизм определения кодировок; 
o
механизм преобразования кодировок; 
o
механизм обработки ошибочных ситуаций. 

Механизм ведения журнала: 
o
механизм записи журнала; 
o
механизм отображения журнала в консоли
o
механизм обработки ошибочных ситуаций. 
Согласитесь, что такие длинные названия с постоянно повторяющимся сло-
вом «механизм» читать и запоминать сложно. Перепишем: 

Стартер: 
o
анализатор параметров; 
o
сборщик приложения; 
o
обработчик ошибок. 

Сканер: 
o
обходчик; 
o
обработчик ошибок. 

Преобразователь: 
o
детектор; 
o
конвертер; 
o
обработчик ошибок. 

Регистратор: 
o
дисковый регистратор; 
o
консольный регистратор; 
o
обработчик ошибок. 
Но что делать, если мы не знаем «внутренностей» приложения (или не очень 
разбираемся в программировании)? Модули и подмодули можно выделять на ос-
нове графического интерфейса пользователя (крупные области и элементы внутри 
них), на основе решаемых приложением задач и подзадач и т.д. Главное, чтобы эта 
логика была одинаковым образом применена ко всему приложению. 
Внимание! Частая ошибка! Модуль и подмодуль приложения — это НЕ 
действия, это именно структурные части, «куски» приложения. В заблуж-
дение вас могут ввести такие названия, как, например, «печать, настройка 
принтера» (но здесь имеются в виду именно части приложения, отвечаю-
щие за печать и за настройку принтера (и названы они отглагольными су-
ществительными), а не процесс печати или настройки принтера). 
Сравните (на примере человека): «дыхательная система, лёгкие» — это 
модуль и подмодуль, а «дыхание», «сопение», «чихание» — нет; «голова, 
мозг» — это модуль и подмодуль, а «кивание», «думание» — нет. 
Наличие полей «Модуль» и «Подмодуль» улучшает такое свойство тест-
кейса, как прослеживаемость
{143}



Атрибуты (поля) тест-кейса
Тестирование программного обеспечения. Базовый курс. 
© EPAM Systems, 2015–2023


Достарыңызбен бөлісу:
1   ...   150   151   152   153   154   155   156   157   ...   307




©engime.org 2024
әкімшілігінің қараңыз

    Басты бет