Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
(Никак.) Пример анализа и тестирования требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 56/298 ▪ Какова реакция приложения на отсутствие лог-файла в слу- чае, если это не первый запуск? (Создаёт. Тут идея в том, чтобы оно не затирало старый лог — и всё.) Бизнес-правила • БП-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–2022 Стр: 57/298 Уровень продуктных требований (см. главу «Уровни и типы требова- ний» {36} ). Применим т.н. «самостоятельное описание» (см. главу «Источники и пути выявления требований» {34} ) и улучшим требования. Поскольку мы уже получили много специфической технической информации, можно параллельно писать полно- ценную спецификацию требований. Во многих случаях, когда для оформления тре- бований используется простой текст, для удобства формируется единый документ, который интегрирует в себе как пользовательские требования, так и детальные спе- цификации. Теперь требования принимают следующий вид. Системные характеристики • СХ-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–2022 Стр: 58/298 Атрибуты качества • АК-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–2022 Стр: 59/298 ДС-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: заметили ли вы, что в исправленном варианте требований «потерялась» диаграмма вариантов использования (равно как и активная ссылка на неё)? (Просто тест на внимательность, не более.) Итак, мы получили набор требований, с которым уже вполне можно работать. Он не идеален (и никогда вы не встретите идеальных требований), но он вполне пригоден для того, чтобы разработчики смогли реализовать приложение, а тести- ровщики — протестировать его. Задание 2.2.e: протестируйте этот набор требований и найдите в нём хотя бы 3–5 ошибок и неточностей, задайте соответствующие вопросы заказ- чику. Типичные ошибки при анализе и тестировании требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 60/298 2.2.8. Типичные ошибки при анализе и тестировании требований Для лучшего понимания и запоминания материала рассмотрим типичные ошибки, совершаемые в процессе анализа и тестирования требований. Изменение формата файла и документа. По какой-то непонятной причине очень многие начинающие тестировщики стремятся полностью уничтожить исход- ный документ, заменив текст таблицами (или наоборот), перенеся данные из Word в Excel и т.д. Это можно сделать только в одном случае: если вы предварительно договорились о подобных изменениях с автором документа. В противном случае вы полностью уничтожаете чью-то работу, делая дальнейшее развитие документа крайне затруднительным. Самое худшее, что можно сделать с документом, — это сохранить его в итоге в некоем формате, предназначенном скорее для чтения, чем для редактирования , набор картинок и тому подобное). Если требования изначально создаются в некоей системе управления требо- ваниями, этот вопрос неактуален, но высокоуровневые требования большинство заказчиков привыкли видеть в обычном DOCX-документе, а Word предоставляет такие прекрасные возможности работы с документом, как отслеживание изменений (см. рисунок 2.2.i) и комментарии (см. рисунок 2.2.j). Рисунок 2.2.i — Активация отслеживания изменений в Word В итоге получается результат, представленный на рисунке 2.2.j: исходный формат сохраняется (а автор к нему уже привык), все изменения хорошо видны и могут быть приняты или отклонены в пару кликов мыши, а типичные часто повторя- ющиеся вопросы вы можете помимо указания в комментариях вынести в отдельный список и поместить его в том же документе. Рисунок 2.2.j — Правильно выглядящий документ с правками И ещё два маленьких, но неприятных момента относительно таблиц: • Выравнивание ВСЕГО текста в таблице по центру. Да, выравнивание по цен- тру хорошо смотрится в заголовках и ячейках с парой-тройкой слов, но если так выровнен весь текст, читать его становится сложно. • Отключение границ ячеек. Такая таблица намного хуже читается. Включить! Типичные ошибки при анализе и тестировании требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 61/298 Отметка того факта, что с требованием всё в порядке. Если у вас не воз- никло вопросов и/или замечаний к требованию — не надо об этом писать. Любые пометки в документе подсознательно воспринимаются как признак проблемы, и та- кое «одобрение требований» только раздражает и затрудняет работу с документом — сложнее становится заметить пометки, относящиеся к проблемам. Описание одной и той же проблемы в нескольких местах. Помните, что ваши пометки, комментарии, замечания и вопросы тоже должны обладать свой- ствами хороших требований (настолько, насколько эти свойства к ним применимы). Если вы много раз в разных местах пишете одно и то же об одном и том же, вы нарушаете как минимум свойство модифицируемости. Постарайтесь в таком слу- чае вынести ваш текст в конец документа, укажите в нём же (в начале) перечень пунктов требований, к которым он относится, а в самих требованиях в коммента- риях просто ссылайтесь на этот текст. Написание вопросов и комментариев без указания места требования, к которым они относятся. Если ваше инструментальное средство позволяет ука- зать часть требования, к которому вы пишете вопрос или комментарий, сделайте это (например, Word позволяет выделить для комментирования любую часть тек- ста — хоть один символ). Если это невозможно, цитируйте соответствующую часть текста. В противном случае вы порождаете неоднозначность или вовсе делаете вашу пометку бессмысленной, т.к. становится невозможно понять, о чём вообще идёт речь. Задавание плохо сформулированных вопросов. Эта ошибка была по- дробно рассмотрена выше (см. раздел «Техники тестирования требований» {48} и таблицу 2.2.a {49} ). Однако добавим, что есть ещё три вида плохих вопросов: • Первый вид возникает из-за того, что автор вопроса не знает общепринятой терминологии или типичного поведения стандартных элементов интерфейса (например, «что такое чек-бокс?», «как в списке можно выбрать несколько пунктов?», «как подсказка может всплывать?»). • Второй вид плохих вопросов похож на первый из-за формулировок: вместо того, чтобы написать «что вы имеете в виду под {чем-то}?», автор вопроса пишет «что такое {что-то}?» То есть вместо вполне логичного уточнения по- лучается ситуация, очень похожая на рассмотренную в предыдущем пункте. • Третий вид сложно привязать к причине возникновения, но его суть в том, что к некорректному и/или невыполнимому требованию задаётся вопрос наподо- бие «что будет, если мы это сделаем?». Ничего не будет, т.к. мы это точно не сделаем. И вопрос должен быть совершенно иным (каким именно — зави- сит от конкретной ситуации, но точно не таким). И ещё раз напомним о точности формулировок: иногда одно-два слова могут на корню уничтожить отличную идею, превратив хороший вопрос в плохой. Срав- ните: «Что такое формат даты по умолчанию?» и «Каков формат даты по умолча- нию?». Первый вариант просто показывает некомпетентность автора вопроса, то- гда как второй — позволяет получить полезную информацию. К этой же проблеме относится непонимание контекста. Часто можно увидеть вопросы в стиле «о каком приложении идёт речь?», «что такое система?» и им по- добные. Чаще всего автор таких вопросов просто вырвал требование из контекста, по которому было совершенно ясно, о чём идёт речь. Типичные ошибки при анализе и тестировании требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 62/298 Написание очень длинных комментариев и/или вопросов. История знает случаи, когда одна страница исходных требований превращалась в 20–30 страниц текста анализа и вопросов. Это плохой подход. Все те же мысли можно выразить значительно более кратко, чем сэкономить как своё время, так и время автора ис- ходного документа. Тем более стоит учитывать, что на начальных стадиях работы с требованиями они весьма нестабильны, и может получиться так, что ваши 5–10 страниц комментариев относятся к требованию, которое просто удалят или изменят до неузнаваемости. Критика текста или даже его автора. Помните, что ваша задача — сделать требования лучше, а не показать их недостатки (или недостатки автора). Потому комментарии вида «плохое требование», «неужели вы не понимаете, как глупо это звучит», «надо переформулировать» неуместны и недопустимы. |