Материал: Обеспечения Базовый курс (3е издание) Версия книги 2 от 17. 04. 2023

Пример анализа и тестирования требований
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 59/301
▪
Какова реакция приложения на отсутствие лог-файла в слу-
чае, если это не первый запуск?
(Создаёт. Тут идея в том,
чтобы оно не затирало старый лог — и всё.)
Бизнес-правила
• БП-1: Источник и приёмник файлов o
БП-1.1: Каталоги, являющиеся источником исходны
м
(опечатка, ис-
ходных)
(Да.)
и приёмником конечных файлов, не должны совпадать
▪
Какова реакция приложения в случае совпадения этих катало-
гов?
(Пишет хелп и поясняет, что не так.)
o
БП-1.2: Каталог, являющийся приёмником конечных файлов, не может быть подкаталогом источника
(предлагаем заменить слово «источ-
ника» на фразу «каталога, являющегося источником исходных фай-
лов»)
.
(
Хорошо, пусть будет так.)
Атрибуты качества
• АК-1: Производительность o
АК-1.1: Приложение должно обеспечивать скорость обработки данных
5
МБ/сек
▪
При каких технических характеристиках системы?
(i7, 4GB
RAM)
• АК-2: Устойчивость к входным данным o
АК-2.1: Приложение должно обрабатывать входные файлы размером до 50 МБ включительно
▪
Какова реакция приложения на файлы, размер которых превы-
шает 50 МБ?
(Не трогает.)
o
АК-2.2: Если входной файл не является текстовым, приложение должно произвести обработку
▪
Обработку чего должно произвести приложение?
(Этого
файла. Не важно, что станет с файлом, лишь бы скрипт не
умер.)
Здесь есть несколько важных моментов, на которые стоит обратить внима- ние:
• Ответы заказчика могут быть менее структурированными и последователь- ными, чем наши вопросы. Это нормально. Он может позволить себе такое, мы — нет.
• Ответы заказчика могут содержать противоречия (в нашем примере сначала заказчик писал, что параметрами, передаваемыми из командной строки, яв- ляются только два имени каталога, а потом сказал, что там же указывается имя лог-файла). Это тоже нормально, т.к. заказчик мог что-то забыть или пе- репутать. Наша задача — свести эти противоречивые данные воедино (если это возможно) и задать уточняющие вопросы (если это необходимо).
• В случае если с нами общается технический специалист, в его ответах вполне могут проскакивать технические жаргонизмы (как «хелп» в нашем примере). Не надо переспрашивать его о том, что это такое, если жаргонизм имеет однозначное общепринятое значение, но при доработке текста наша задача — написать то же самое строгим техническим языком. Если жарго- низм всё же непонятен — тогда лучше спросить (так, «хелп» — это всего лишь краткая помощь, выводимая консольными приложениями как подсказка о том, как их использовать).

Пример анализа и тестирования требований
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 60/301
Уровень продуктных требований (см. главу «Уровни и типы требова- ний»
{39}
). Применим т.н. «самостоятельное описание» (см. главу «Источники и пути выявления требований»
{37}
) и улучшим требования. Поскольку мы уже получили много специфической технической информации, можно параллельно писать полно- ценную спецификацию требований. Во многих случаях, когда для оформления тре- бований используется простой текст, для удобства формируется единый документ, который интегрирует в себе как пользовательские требования, так и детальные спе- цификации. Теперь требования принимают следующий вид.
Системные характеристики
• СХ-1: Приложение является консольным.
• СХ-2: Приложение разрабатывается на языке программирования PHP (при- чина выбора языка PHP отражена в пункте
О-1
раздела «
Ограничения
», осо- бенности и важные настройки интерпретатора PHP отражены в пункте
ДС-1
раздела «
Детальные спецификации
»).
• СХ-3: Приложение является кроссплатформенным с учётом пункта
О-4
раз- дела «
Ограничения
».
Пользовательские требования
• Также см. диаграмму вариантов использования.
• ПТ-1: Запуск и остановка приложения. o
ПТ-1.1: Запуск приложения производится из консоли командой «php converter.php SOURCE_DIR DESTINATION_DIR [LOG_FILE_NAME]
»
(описание параметров приведено в разделе
ДС-2.1
, реакция на ошибки при указании параметров приведена в разделах
ДС-2.2
,
ДС-
2.3
,
ДС-2.4
).
o
ПТ-1.2: Остановка приложения производится выполнением команды
Ctrl+C в окне консоли, из которого было запущено приложение.
• ПТ-2: Конфигурирование приложения. o
ПТ-2.1: Конфигурирование приложения сводится к указанию парамет- ров командной строки (см.
ДС-2
).
o
ПТ-2.2: Целевой кодировкой преобразования текстов является коди- ровка UTF8 (также см.
О-5
).
• ПТ-3: Просмотр журнала работы приложения. o
ПТ-3.1: В процессе работы приложение должно выводить журнал своей работы в консоль и лог-файл (см.
ДС-4
), имя которого опреде- ляется правилами, указанными в
ДС-2.1
o
ПТ-3.2: Формат журнала работы и лог файла указан в
ДС-4.1
, а реак- ция приложения на наличие или отсутствие лог-файла указана в
ДС-
4.2
и
ДС-4.3
соответственно.
Бизнес-правила
• БП-1: Источник и приёмник файлов o
БП-1.1: Каталоги, являющиеся источником исходных и приёмником ко- нечных файлов, не должны совпадать (см. также
ДС-2.1
и
ДС-3.2
).
o
БП-1.2: Каталог, являющийся приёмником конечных файлов, не может находиться внутри каталога, являющегося источником исходных фай- лов или его подкаталогов (см. также
ДС-2.1
и
ДС-3.2
).

Пример анализа и тестирования требований
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 61/301
Атрибуты качества
• АК-1: Производительность o
АК-1.1: Приложение должно обеспечивать скорость обработки данных не менее 5 МБ/сек на аппаратном обеспечении, эквивалентном следу- ющему: процессор i7, 4 ГБ оперативной памяти, средняя скорость чте- ния/записи на диск 30 МБ/сек. Также см.
О-6
• АК-2: Устойчивость к входным данным o
АК-2.1: Требования относительно форматов обрабатываемых файлов изложены в
ДС-5.1
o
АК-2.2: Требования относительно размеров обрабатываемых файлов изложены в
ДС-5.2
o
АК-2.3: Поведение приложения в ситуации обработки файлов с нару- шениями формата определено в
ДС-5.3
Ограничения
• О-1: Приложение разрабатывается на языке программирования PHP, ис- пользование которого обусловлено возможностью заказчика осуществлять поддержку приложения силами собственного IT-отдела.
• О-2: Ограничения относительно версии и настроек интерпретатора PHP от- ражены в пункте
ДС-1
раздела «
Детальные спецификации
».
• О-3: Процедуры установки и настройки интерпретатора PHP выходят за рамки данного проекта и не описываются в документации.
• О-4: Кроссплатформенные возможности приложения сводятся к способности работать под ОС семейства Windows и Linux, поддерживающих работу ин- терпретатора PHP версии, указанной в
ДС-1.1
• О-5: Целевая кодировка UTF8 является жёстко заданной, и её изменение в процессе эксплуатации приложения не предусмотрено.
• О-6: Допускается невыполнение
АК-1.1
в случае, если невозможность обес- печить заявленную производительность обусловлена объективными внеш- ними причинами (например, техническими проблемами на сервере заказ- чика).
Созданные на основе таких пользовательских требований детальные специ- фикации имеют следующий вид.
Детальные спецификации
ДС-1: Интерпретатор PHP
ДС-1.1: Минимальная версия — 5.5.
ДС-1.2: Для работы приложения должно быть установлено и включено рас- ширение mbstring.
ДС-2: Параметры командной строки
ДС-2.1: При запуске приложения оно получает из командной строки три па- раметра:
SOURCE_DIR
— обязательный параметр, определяет путь к каталогу с файлами, которые необходимо обработать;
DESTINATION_DIR
— обязательный параметр, определяет путь к ка- талогу, в который необходимо поместить обработанные файлы (этот каталог не может находиться внутри каталога SOURCE_DIR или в его подкаталогах (см.
БП-1.1
и
БП-1.2
));
LOG_FILE_NAME
— необязательный параметр, определяет полное имя лог-файла (по умолчанию лог-файл с именем «converter.log» раз- мещается по тому же пути, по которому находится файл скрипта con- verter.php);

Пример анализа и тестирования требований
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 62/301
ДС-2.2: При указании недостаточного количества параметров командной строки приложение должно завершить работу, выдав сообщение об использовании
(
ДС-3.1
).
ДС-2.3: При указании излишнего количества параметров командной строки приложение должно игнорировать все параметры командной строки, кроме указан- ных в пункте
ДС-2.1
ДС-2.4: При указании неверного значения любого из параметров командной строки приложение должно завершить работу, выдав сообщение об использовании
(
ДС-3.1
), а также сообщив имя неверно указанного параметра, его значение и суть ошибки (см.
ДС-3.2
).
ДС-3: Сообщения
ДС-3.1: Сообщение об использовании: «USAGE converter.php SOURCE_DIR
DESTINATION_DIR LOG_FILE_NAME
».
ДС-3.2: Сообщения об ошибках:
Directory not exists or inaccessible.
Destination dir may not reside within source dir tree.
Wrong file name or inaccessible path.
ДС-4: Журнал работы
ДС-4.1: Формат журнала работы одинаков для отображения в консоли и за- писи в лог-файл: YYYY-MM-DD HH:II:SS имя_операции параметры_операции ре- зультат_операции.
ДС-4.2: В случае если лог-файл отсутствует, должен быть создан новый пу- стой лог-файл.
ДС-4.3: В случае если лог-файл уже существует, должно происходить добав- ление новых записей в его конец.
ДС-5: Форматы и размеры файлов
ДС-5.1: Приложение должно обрабатывать текстовые файлы на русском и английском языках в следующих исходных кодировках: WIN1251, CP866, KOI8R.
Обрабатываемые файлы могут быть представлены в следующих форматах, определяемых расширениями файлов:
Plain Text (TXT);
Hyper Text Markup Language Document (HTML);
Mark Down Document (MD).
ДС-5.2: Приложение должно обрабатывать файлы размером до 50 МБ (вклю- чительно), игнорируя любой файл, размер которого превышает 50 МБ.
ДС-5.3: Если файл с расширением из
ДС-5.1
содержит внутри себя данные, не соответствующие формату файла, допускается повреждение таких данных.
Задание 2.2.d: заметили ли вы, что в исправленном варианте требований
«потерялась» диаграмма вариантов использования (равно как и активная ссылка на неё)? (Просто тест на внимательность, не более.)
Итак, мы получили набор требований, с которым уже вполне можно работать.
Он не идеален (и никогда вы не встретите идеальных требований), но он вполне пригоден для того, чтобы разработчики смогли реализовать приложение, а тести- ровщики — протестировать его.

Типичные ошибки при анализе и тестировании требований
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 63/301
2.2.8.
Типичные ошибки при анализе и тестировании требований
Для лучшего понимания и запоминания материала рассмотрим типичные ошибки, совершаемые в процессе анализа и тестирования требований.
Изменение формата файла и документа. По какой-то непонятной причине очень многие начинающие тестировщики стремятся полностью уничтожить исход- ный документ, заменив текст таблицами (или наоборот), перенеся данные из Word в Excel и т.д. Это можно сделать только в одном случае: если вы предварительно договорились о подобных изменениях с автором документа. В противном случае вы полностью уничтожаете чью-то работу, делая дальнейшее развитие документа крайне затруднительным.
Самое худшее, что можно сделать с документом, — это сохранить его в итоге в некоем формате, предназначенном скорее для чтения, чем для редактирования
(PDF
, набор картинок и тому подобное).
Если требования изначально создаются в некоей системе управления требо- ваниями, этот вопрос неактуален, но высокоуровневые требования большинство заказчиков привыкли видеть в обычном DOCX-документе, а Word предоставляет такие прекрасные возможности работы с документом, как отслеживание изменений
(см. рисунок 2.2.i) и комментарии (см. рисунок 2.2.j).
Рисунок 2.2.i — Активация отслеживания изменений в Word
В итоге получается результат, представленный на рисунке 2.2.j: исходный формат сохраняется (а автор к нему уже привык), все изменения хорошо видны и могут быть приняты или отклонены в пару кликов мыши, а типичные часто повторя- ющиеся вопросы вы можете помимо указания в комментариях вынести в отдельный список и поместить его в том же документе.
Рисунок 2.2.j — Правильно выглядящий документ с правками
И ещё два маленьких, но неприятных момента относительно таблиц:
• Выравнивание ВСЕГО текста в таблице по центру. Да, выравнивание по цен- тру хорошо смотрится в заголовках и ячейках с парой-тройкой слов, но если так выровнен весь текст, читать его становится сложно.
• Отключение границ ячеек. Такая таблица намного хуже читается.
Включить!