Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Плохое требование Плохие вопросы Хорошие вопросы «Приложение должно быстро запускаться». «Насколько быстро?» (На это вы рискуете получить ответы в стиле «очень быстро», «макси- мально быстро», «нууу… просто быстро»). «А если не получится быстро?» (Этим вы рискуете просто уди- вить или даже разозлить заказ- чика.) «Всегда?» («Да, всегда». Хм, а вы ожидали другого ответа?) «Каково максимально допусти- мое время запуска приложения, на каком оборудовании и при ка- кой загруженности этого обору- дования операционной системой и другими приложениями? На до- стижение каких целей влияет скорость запуска приложения? Допускается ли фоновая за- грузка отдельных компонентов приложения? Что является кри- терием того, что приложение за- кончило запуск?» «Опционально должен поддерживаться экспорт документов в формат ». «Любых документов?» (Ответы «да, любых» или «нет, только от- крытых» вам всё равно не помо- гут.) «В PDF какой версии должен производиться экспорт?» (Сам по себе вопрос хорош, но он не даёт понять, что имелось в виду под «опционально».) «Зачем?» («Нужно!» Именно так хочется ответить, если вопрос не раскрыт полностью.) «Насколько возможность экс- порта в PDF важна? Как часто, кем и с какой целью она будет ис- пользоваться? Является ли PDF единственным допустимым фор- матом для этих целей или есть альтернативы? Допускается ли использование внешних утилит (например, виртуальных PDF- принтеров) для экспорта доку- ментов в PDF?» «Если дата события не указана, она выбирается автоматически». «А если указана?» (То она ука- зана. Логично, не так ли?) «А если дату невозможно вы- брать автоматически?» (Сам во- прос интересен, но без поясне- ния причин невозможности зву- чит как издёвка.) «А если у события нет даты?» (Тут автор вопроса, скорее всего, хотел уточнить, обязательно ли это поле для заполнения. Но из самого требования видно, что обязательно: если оно не запол- нено человеком, его должен за- полнить компьютер.) «Возможно, имелось в виду, что дата генерируется автоматиче- ски, а не выбирается? Если да, то по какому алгоритму она гене- рируется? Если нет, то из какого набора выбирается дата и как ге- нерируется этот набор? P.S. Воз- можно, стоит использовать теку- щую дату?» Тест-кейсы и чек-листы. Мы помним, что хорошее требование является проверяемым, а значит, должны существовать объективные способы определения того, верно ли реализовано требование. Продумывание чек-листов или даже пол- ноценных тест-кейсов в процессе анализа требований позволяет нам определить, насколько требование проверяемо. Если вы можете быстро придумать несколько пунктов чек-листа, это ещё не признак того, что с требованием всё хорошо (напри- мер, оно может противоречить каким-то другим требованиям). Но если никаких идей по тестированию требования в голову не приходит — это тревожный знак. Техники тестирования требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 50/298 Рекомендуется для начала убедиться, что вы понимаете требование (в том числе прочесть соседние требования, задать вопросы коллегам и т.д.). Также можно пока отложить работу с данным конкретным требованием и вернуться к нему позднее — возможно, анализ других требований позволит вам лучше понять и это конкретное. Но если ничто не помогает — скорее всего, с требованием что-то не так. Справедливости ради надо отметить, что на начальном этапе проработки требований такие случаи встречаются очень часто — требования сформированы очень поверхностно, расплывчато и явно нуждаются в доработке, т.е. здесь нет необходимости проводить сложный анализ, чтобы констатировать непроверяе- мость требования. На стадии же, когда требования уже хорошо сформулированы и протестиро- ваны, вы можете продолжать использовать эту технику, совмещая разработку тест- кейсов и дополнительное тестирование требований. Исследование поведения системы. Эта техника логически вытекает из предыдущей (продумывания тест-кейсов и чек-листов), но отличается тем, что здесь тестированию подвергается, как правило, не одно требование, а целый набор. Тестировщик мысленно моделирует процесс работы пользователя с систе- мой, созданной по тестируемым требованиям, и ищет неоднозначные или вовсе неописанные варианты поведения системы. Этот подход сложен, требует доста- точной квалификации тестировщика, но способен выявить нетривиальные недора- ботки, которые почти невозможно заметить, тестируя требования по отдельности. Рисунки (графическое представление). Чтобы увидеть общую картину тре- бований целиком, очень удобно использовать рисунки, схемы, диаграммы, интел- лект-карты 108 и т.д. Графическое представление удобно одновременно своей наглядностью и краткостью (например, UML-схема базы данных, занимающая один экран, может быть описана несколькими десятками страниц текста). На рисунке очень легко заметить, что какие-то элементы «не стыкуются», что где-то чего-то не хватает и т.д. Если вы для графического представления требований будете исполь- зовать общепринятую нотацию (например, уже упомянутый UML), вы получите до- полнительные преимущества: вашу схему смогут без труда понимать и дорабаты- вать коллеги, а в итоге может получиться хорошее дополнение к текстовой форме представления требований. Прототипирование. Можно сказать, что прототипирование часто является следствием создания графического представления и анализа поведения системы. С использованием специальных инструментов можно очень быстро сделать наброски пользовательских интерфейсов, оценить применимость тех или иных ре- шений и даже создать не просто «прототип ради прототипа», а заготовку для даль- нейшей разработки, если окажется, что реализованное в прототипе (возможно, с небольшими доработками) устраивает заказчика. 108 «Mind map» [ http://en.wikipedia.org/wiki/Mind_map ] Пример анализа и тестирования требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 51/298 2.2.7. Пример анализа и тестирования требований Поскольку наша задача состоит в том, чтобы сформировать понимание ло- гики анализа и тестирования требований, мы будем рассматривать предельно крат- кий и простой их набор. Отличный подробный пример требований можно найти в приложениях к книге Карла Вигерса «Разработка требований к программному обеспече- нию» («Software Requirements (3rd Edition) (Developer Best Practices)», Karl Wiegers, Joy Beatty). Допустим, что у некоего клиента есть проблема: поступающие в огромном количестве его сотрудникам текстовые файлы приходят в разных кодировках, и со- трудники тратят много времени на перекодирование («ручной подбор кодировки»). Соответственно, он хотел бы иметь инструмент, позволяющий автоматически при- водить кодировки всех текстовых файлов к некоей одной. Итак, на свет появляется проект с кодовым названием «Конвертер файлов». Уровень бизнес-требований. Бизнес-требования (см. главу «Уровни и типы требований» {36} ) изначально могут выглядеть так: «Необходим инструмент для ав- томатического приведения кодировок текстовых документов к одной». Здесь мы можем задать множество вопросов. Для удобства приведём как сами вопросы, так и предполагаемые ответы клиента Задание 2.2.b: прежде чем читать приведённый ниже список вопросов, сформулируйте собственный. • В каких форматах представлены текстовые документы (обычный текст, HTML, MD , что-то иное)? ( Понятия не имею, я в этом не разбираюсь.) • В каких кодировках приходят исходные документы? ( В разных.) • В какую кодировку нужно преобразовать документы? ( В самую удобную и универсальную.) • На каких языках написан текст в документах? ( Русский и английский.) • Откуда и как поступают текстовые документы (по почте, с сайтов, по сети, как-то иначе)? ( Это неважно. Поступают отовсюду, но мы их складываем в одну папку на диске, нам так удобно.) • Каков максимальный объём документа? ( Пара десятков страниц.) • Как часто появляются новые документы (например, сколько максимум доку- ментов может поступить за час)? (200 –300 в час.) • С помощью чего сотрудники просматривают документы? (Notepad++.) Даже таких вопросов и ответов достаточно, чтобы переформулировать биз- нес-требования следующим образом (обратите внимание, что многие вопросы были заданы на будущее и не привели к появлению в бизнес-требованиях лишней технической детализации). Суть проекта: разработка инструмента, устраняющего проблему множе- ственности кодировок в текстовых документах, расположенных в локальном диско- вом хранилище. Цели проекта: • Исключение необходимости ручного подбора кодировок текстовых докумен- тов. • Сокращение времени работы с текстовым документом на величину, необхо- димую для ручного подбора кодировки. Пример анализа и тестирования требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 52/298 Метрики достижения целей: • Полная автоматизация определения и преобразования кодировки текстового документа к заданной. • Сокращение времени обработки текстового документа в среднем на 1–2 ми- нуты на документ за счёт устранения необходимости ручного подбора коди- ровки. Риски: • Высокая техническая сложность безошибочного определения исходной ко- дировки текстового документа. Почему мы решили, что среднее время на подбор кодировки составляет 1–2 минуты? Мы провели наблюдение. Также мы помним ответы заказчика на вопросы об исходных форматах документов, исходных и конечной кодировках (заказчик честно сказал, что не знает ответа), а потому мы попросили его предоставить нам доступ к хранилищу документов и выяснили: • Исходные форматы: plain text, HTML, MD. • Исходные кодировки: CP1251, UTF8, CP866, KOI8R. • Целевая кодировка: UTF8. На данном этапе мы вполне можем решить, что стоит заняться детализацией требований на более низких уровнях, т.к. появившиеся там вопросы позволят нам вернуться к бизнес-требованиям и улучшить их, если в этом возникнет необходи- мость. Уровень пользовательских требований. Пришло время заняться уровнем пользовательских требований (см. главу «Уровни и типы требований» {36} ) . Проект у нас несколько специфичный — результатами работы программного средства будет пользоваться большое количество людей, но само программное средство при этом они использовать не будут (оно будет просто выполнять свою работу «само по себе» — запущенное на сервере с хранилищем документов). Потому под пользова- телем здесь мы будем понимать человека, настраивающего работу приложения на сервере. Для начала мы создадим небольшую диаграмму вариантов использования, представленную на рисунке 2.2.g (да, иногда её создают после текстового описа- ния требований, но иногда и до — нам сейчас удобнее сделать это сначала). В реальных проектах подобные схемы могут быть на несколько порядков более слож- ными и требующими подробной детализации каждого варианта использования. У нас же проект миниатюрный, потому схема получилась элементарной, и мы сразу переходим к описанию требований. Внимание! Это — ПЛОХИЕ требования. И мы далее будем их улучшать. Системные характеристики • СХ-1: Приложение является консольным. • СХ-2: Для работы приложение использует интерпретатор PHP. • СХ-3: Приложение является кроссплатформенным. Пользовательские требования • Также см. диаграмму вариантов использования. • ПТ-1: Запуск и остановка приложения. o ПТ-1.1: Запуск приложения производится из консоли командой «PHP converter.php параметры». Пример анализа и тестирования требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 53/298 o ПТ-1.2: Остановка приложения производится выполнением команды Ctrl+C. • ПТ-2: Конфигурирование приложения. o ПТ-2.1: Конфигурирование приложения сводится к указанию путей в файловой системе. o ПТ-2.2: Целевой кодировкой является UTF8. • ПТ-3: Просмотр журнала работы приложения. o ПТ-3.1: В процессе работы приложение должно выводить журнал своей работы в консоль и лог-файл. o ПТ-3.2: При первом запуске приложения лог-файл создаётся, а при по- следующих — дописывается. Рисунок 2.2.g — Диаграмма вариантов использования Бизнес-правила • БП-1: Источник и приёмник файлов o БП-1.1: Каталоги, являющиеся источником исходных и приёмником ко- нечных файлов не должны совпадать. o БП-1.2: Каталог, являющийся приёмником конечных файлов, не может быть подкаталогом источника. uc Primary Use Cases Приложение Конфигурирование приложения Администратор Остальные функции реализуются иными средствами и не предоставляются разрабатываемым приложением Запуск приложения Остановка приложения Просмотр журнала работы приложения Пример анализа и тестирования требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 54/298 Атрибуты качества • АК-1: Производительность o АК-1.1: Приложение должно обеспечивать скорость обработки данных 5 МБ/сек. • АК-2: Устойчивость к входным данным o АК-2.1: Приложение должно обрабатывать входные файлы размером до 50 МБ включительно. o АК-2.2: Если входной файл не является текстовым, приложение должно произвести обработку. Как будет сказано в главе «Типичные ошибки при анализе и тестировании требований» {60} , не стоит изменять исходный формат файла и форматирование до- кумента, потому мы используем встроенные средства Word для отслеживания из- менений и добавления комментариев. Примерный вид результата показан на ри- сунке 2.2.h. Рисунок 2.2.h — Использование средств Word для работы с требованиями К сожалению, мы не можем в данном тексте применить эти средства (резуль- тат будет отображаться некорректно, т.к. вы сейчас, скорее всего, читаете этот текст не в виде DOCX-документа), а потому применим второй классический способ — будем вписывать свои вопросы и комментарии прямо внутрь текста требований. Проблемные места требований отмечены подчёркиванием , наши вопросы отмечены курсивом , предполагаемые ответы заказчика (даже, если точнее, техни- ческого специалиста заказчика) — жирным . В процессе анализа текст требований примет вот такой вид. Задание 2.2.c: проанализируйте предложенный набор требований с точки зрения свойств качественных требований {41} , сформулируйте свои во- просы заказчику, которые позволят улучшить этот набор требований. Системные характеристики • СХ-1: Приложение является консольным. • СХ-2: Для работы приложение использует интерпретатор PHP o Какая минимальная версия интерпретатора PHP поддерживается приложением? (5.5.x) o Существует ли некая специфика настройки интерпретатора PHP для корректной работы приложения? (Наверное, должен работать mbstring.) Пример анализа и тестирования требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 55/298 o Настаиваете ли вы на реализации приложения именно на PHP? Если да, то почему. (Да, только PHP. У нас есть сотрудник, который его знает.) o Должна ли в руководстве пользователя быть описана процедура установки и настройки интерпретатора PHP? (Нет.) • СХ-3: Приложение является кроссплатформенным o Какие ОС должны поддерживаться? (Любая, где работает PHP.) o В чём вообще цель кроссплатформенности? (Мы ещё не знаем, на чём будет работать сервер.) Пользовательские требования • Также см. диаграмму вариантов использования. • ПТ-1: Запуск и остановка приложения. o ПТ-1.1: Запуск приложения производится из консоли командой « PHP (возможно, здесь опечатка: должно быть php (в нижнем регистре)) (Да, OK.) converter.php параметры ». ▪ Какие параметры передаются скрипту при запуске? (Каталог с исходными файлами, каталог с конечными файлами.) ▪ Какова реакция скрипта на: • отсутствие параметров; (Пишет хелп.) • неверное количество параметров; (Пишет хелп и пояс- няет, что не так.) • неверные значения каждого из параметров. (Пишет хелп и поясняет, что не так.) o ПТ-1.2: Остановка приложения производится выполнением команды Ctrl+C (предлагаем дополнить это выражение фразой «в окне кон- соли, из которого было запущено приложение») (Да, OK.) . • ПТ-2: Конфигурирование приложения. o ПТ-2.1: Конфигурирование приложения сводится к указанию путей в файловой системе ▪ Путей к чему? (Каталог с исходными файлами, каталог с ко- нечными файлами.) o ПТ-2.2: Целевой кодировкой является UTF8 ▪ Предполагается ли указание иной целевой кодировки, или UTF8 используется в качестве целевой всегда? (Только UTF8, других не надо.) • ПТ-3: Просмотр журнала работы приложения. o ПТ-3.1: В процессе работы приложение должно выводить журнал своей работы в консоль и лог-файл ▪ Каков формат журнала? (Дата-время, что и с чем делали, что получилось. Гляньте в логе апача, там нормально напи- сано.) ▪ Различаются ли форматы журнала для консоли и лог-файла? (Нет.) ▪ Как определяется имя лог-файла? (Третий параметр при за- пуске. Если не указан — пусть будет converter.log рядом с php- скриптом.) o ПТ-3.2: При первом запуске приложения лог-файл создаётся, а при по- следующих — дописывается ▪ Как приложение различает свой первый и последующие за- пуски? |