Тестирование компьютерных приложений

К сожалению, мы не можем в данном тексте применить эти средства (результат будет отображаться некорректно, т.к. вы сейчас, скорее всего, читаете этот текст не в виде DOCX-документа), а потому применим второй классический способ — будем вписывать свои вопросы и комментарии прямо внутрь текста требований.

Проблемные места требований отмечены подчёркиванием, наши вопросы отмечены курсивом, предполагаемые ответы заказчика (даже, если точнее, технического специалиста заказчика) — жирным. В процессе анализа текст требований примет вот такой вид.

Задание 2.: проанализируйте предложенный набор требований с точки зрения свойств качественных требований, сформулируйте свои вопросы заказчику, которые позволят улучшить этот набор требований.

Системные характеристики

· СХ-1: Приложение является консольным.

· СХ-2: Для работы приложение использует интерпретатор PHP.

ü Какая минимальная версия интерпретатора PHP поддерживается приложением? (5.5.x)

ü Существует ли некая специфика настройки интерпретатора PHP для корректной работы приложения? (Наверное, должен работать mbstring.)

ü Настаиваете ли вы на реализации приложения именно на PHP? Если да, то почему. (Да, только PHP. У нас есть сотрудник, который его знает.)

ü Должна ли в руководстве пользователя быть описана процедура установки и настройки интерпретатора PHP? (Нет.)

· СХ-3: Приложение является кроссплатформенным.

ü  Какие ОС должны поддерживаться? (Любая, где работает PHP.)

ü В чём вообще цель кроссплатформенности? (Мы ещё не знаем, на чём будет работать сервер.)

Пользовательские требования

· Также см. диаграмму вариантов использования.

· ПТ-1: Запуск и остановка приложения.

Пользовательские требования

ü Также см. диаграмму вариантов использования.

ü  ПТ-1: Запуск и остановка приложения.

o ПТ-1.1: Запуск приложения производится из консоли командой «PHP (возможно, здесь опечатка: должно быть php (в нижнем регистре)) (Да, OK.) converter.php параметры».

ü Какие параметры передаются скрипту при запуске? (Каталог с исходными файлами, каталог с конечными файлами.)

Какова реакция скрипта на:

ü отсутствие параметров; (Пишет help)

ü  неверное количество параметров; (Пишет help и поясняет, что не так.)

ü неверные значения каждого из параметров. (Пишет help и поясняет, что не так.).

o ПТ-1.2: Остановка приложения производится выполнением команды Ctrl+C (предлагаем дополнить это выражение фразой «в окне консоли, из которого было запущено приложение») (Да, OK.).

ПТ-2: Конфигурирование приложения.

· ПТ-2.1: Конфигурирование приложения сводится к указанию путей в файловой системе.

Путей к чему? (Каталог с исходными файлами, каталог с конечными файлами.)

o ПТ-2.2: Целевой кодировкой является UTF8.

Предполагается ли указание иной целевой кодировки, или UTF8 используется в качестве целевой всегда? (Только UTF8, других не надо.)

 ПТ-3: Просмотр журнала работы приложения.

o ПТ-3.1: В процессе работы приложение должно выводить журнал своей работы в консоль и лог-файл.

 Каков формат журнала? (Дата-время, что и с чем делали, что получилось. Гляньте в логе апача, там нормально написано.)

 Различаются ли форматы журнала для консоли и логфайла? (Нет.)

Как определяется имя лог-файла? (Третий параметр при запуске. Если не указан— пусть будет converter.log рядом с php-скриптом.)

o ПТ-3.2: При первом запуске приложения лог-файл создаётся, а при последующих — дописывается.

Как приложение различает свой первый и последующие запуски? (Никак.)

Какова реакция приложения на отсутствие логфайла в случае, если это не первый запуск? (Создаёт. Тут идея в том, чтобы оно не затирало старый лог — и всё.)

Бизнес-правила

· БП-1: Источник и приёмник файлов

БП-1.1: Каталоги, являющиеся источником исходным (опечатка, исходных) (Да.) и приёмником конечных файлов, не должны совпадать.

Какова реакция приложения в случае совпадения этих каталогов? (Пишет хелп и поясняет, что не так.)

БП-1.2: Каталог, являющийся приёмником конечных файлов, не может быть подкаталогом источника (предлагаем заменить слово «источника» на фразу «каталога, являющегося источником исходных файлов»). (Не надо, непонятно становится.)

Атрибуты качества

· АК-1: Производительность

АК-1.1: Приложение должно обеспечивать скорость обработки данных 5 МБ/сек.

При каких технических характеристиках системы? (i7, 4GB RAM)

· АК-2: Устойчивость к входным данным

АК-2.1: Приложение должно обрабатывать входные файлы размером до 50 МБ включительно.

Какова реакция приложения на файлы, размер которых превышает 50 МБ? (Не трогает.)

АК-2.2: Если входной файл не является текстовым, приложение должно произвести обработку.

Обработку чего должно произвести приложение? (Этого файла. Не важно, что станет с файлом, лишь бы скрипт не умер.)

Здесь есть несколько важных моментов, на которые стоит обратить внимание:

· Ответы заказчика могут быть менее структурированными и последовательными, чем наши вопросы. Это нормально. Он может позволить себе такое, мы — нет.

· Ответы заказчика могут содержать противоречия (в нашем примере сначала заказчик писал, что параметрами, передаваемыми из командной строки, являются только два имени каталога, а потом сказал, что там же указывается имя логфайла). Это тоже нормально, т.к. заказчик мог что-то забыть или перепутать. Наша задача — свести эти противоречивые данные воедино (если это возможно) и задать уточняющие вопросы (если это необходимо).

·В случае если с нами общается технический специалист, в его ответах вполне могут проскакивать технические жаргонизмы (как «хелп» в нашем примере). Не надо переспрашивать его о том, что это такое, если жаргонизм имеет однозначное общепринятое значение, но при доработке текста наша задача — написать то же самое строгим техническим языком. Если жаргонизм всё же непонятен — тогда лучше спросить (так, «хелп» — это всего лишь краткая помощь, выводимая консольными приложениями как подсказка о том, как их использовать).

Уровень продуктных требований (см. главу «Уровни и типы требований»). Применим т.н. «самостоятельное описание» (см. главу «Источники и пути выявления требований») и улучшим требования. Поскольку мы уже получили много специфической технической информации, можно параллельно писать полноценную спецификацию требований. Во многих случаях, когда для оформления требований используется простой текст, для удобства формируется единый документ, который интегрирует в себе как пользовательские требования, так и детальные спецификации. Теперь требования принимают следующий вид.

Системные характеристики

· СХ-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).

Атрибуты качества

· АК-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» размещается по тому же пути, по которому находится файл скрипта converter.php);

ДС-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 содержит внутри себя данные, не соответствующие формату файла, допускается повреждение таких данных.

      Итак, мы получили набор требований, с которым уже вполне можно работать. Он не идеален (и никогда вы не встретите идеальных требований), но он вполне пригоден для того, чтобы разработчики смогли реализовать приложение, а тестировщики — протестировать его.

Задание 4: протестируйте этот набор требований и найдите в нём хотя бы 3–5 ошибок и неточностей, задайте соответствующие вопросы заказчику.