Тестирование программного обеспечения. Базовый курс. 3-е издание
Связанное с тест-кейсом требование
жүктеу/скачать 5,03 Mb. Pdf көрінісі
|
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 жүктеу/скачать 5,03 Mb. Достарыңызбен бөлісу:
|