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

Форма представления, степень детализации и перечень полезных свойств требований зависят от уровней и типов требований, которые схематично представлены.

Бизнес-требования выражают цель, ради которой разрабатывается продукт (зачем вообще он нужен, какая от него ожидается польза, как заказчик с его помощью будет получать прибыль). Результатом выявления требований на этом уровне является общее видение — документ, который, как правило, представлен простым текстом и таблицами. Здесь нет детализации поведения системы и иных технических характеристик, но вполне могут быть определены приоритеты решаемых бизнес-задач, риски и т.п.

Несколько простых, изолированных от контекста и друг от друга примеров бизнес-требований:

· Нужен инструмент, в реальном времени отображающий наиболее выгодный курс покупки и продажи валюты.

· Необходимо в два-три раза повысить количество заявок, обрабатываемых одним оператором за смену.

· Нужно автоматизировать процесс выписки товарно-транспортных накладных на основе договоров.

Рисунок 1 Уровни и типы требований.

Пользовательские требования описывают задачи, которые пользователь может выполнять с помощью разрабатываемой системы (реакцию системы на действия пользователя, сценарии работы пользователя). Поскольку здесь уже появляется описание поведения системы, требования этого уровня могут быть использованы для оценки объёма работ, стоимости проекта, времени разработки и т.д. Пользовательские требования оформляются в виде вариантов использования, пользовательских историй, пользовательских сценариев. (Также см. создание пользовательских сценариев в процессе выполнения тестирования.)

Несколько простых, изолированных от контекста и друг от друга примеров пользовательских требований:

· При первом входе пользователя в систему должно отображаться лицензионное соглашение.

· Администратор должен иметь возможность просматривать список всех пользователей, работающих в данный момент в системе.

· При первом сохранении новой статьи система должна выдавать запрос на сохранение в виде черновика или публикацию.

Бизнес-правила описывают особенности принятых в предметной области (и/или непосредственно у заказчика) процессов, ограничений и иных правил. Эти правила могут относиться к бизнес-процессам, правилам работы сотрудников, нюансам работы ПО и т.д.

Несколько простых, изолированных от контекста и друг от друга примеров бизнес-правил:

· Никакой документ, просмотренный посетителями сайта хотя бы один раз, не может быть отредактирован или удалён.

· Публикация статьи возможна только после утверждения главным редак-тором.

· Подключение к системе извне офиса запрещено в нерабочее время.

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

Несколько простых, изолированных от контекста и друг от друга примеров атрибутов качества:

· Максимальное время готовности системы к выполнению новой команды после отмены предыдущей не может превышать одну секунду.

· Внесённые в текст статьи изменения не должны быть утеряны при нарушении соединения между клиентом и сервером.

·  Приложение должно поддерживать добавление произвольного количества неиероглифических языков интерфейса.

Функциональные требования описывают поведение системы, т.е. её действия (вычисления, преобразования, проверки, обработку и т.д.) В контексте проектирования функциональные требования в основном влияют на дизайн системы.

Стоит помнить, что к поведению системы относится не только то, что система должна делать, но и то, что она не должна делать (например: «приложение не должно выгружать из оперативной памяти фоновые документы в течение 30 минут с момента выполнения с ними последней операции»).

Несколько простых, изолированных от контекста и друг от друга примеров функциональных требований:

· В процессе инсталляции приложение должно проверять остаток свободного места на целевом носителе.

· Система должна автоматически выполнять резервное копирование данных ежедневно в указанный момент времени.

· Электронный адрес пользователя, вводимый при регистрации, должен быть проверен на соответствие требованиям RFC822.

Нефункциональные требования описывают свойства системы (удобство использования, безопасность, надёжность, расширяемость и т.д.), которыми она должна обладать при реализации своего поведения. Здесь приводится более техническое и детальное описание атрибутов качества. В контексте проектирования нефункциональные требования в основном влияют на архитектуру системы.

Несколько простых, изолированных от контекста и друг от друга примеров нефункциональных требований:

· При одновременной непрерывной работе с системой 1000 пользователей, минимальное время между возникновением сбоев должно быть более или равно 100 часов.

· Ни при каких условиях общий объём используемой приложением памяти не может превышать 2 ГБ.

· Размер шрифта для любой надписи на экране должен поддерживать настройку в диапазоне от 5 до 15 пунктов.

Следующие требования в общем случае могут быть отнесены к нефункциональным, однако их часто выделяют в отдельные подгруппы (здесь для простоты рассмотрены лишь три таких подгруппы, но их может быть и гораздо больше; как правило, они проистекают из атрибутов качества, но высокая степень детализации позволяет отнести их к уровню требований к продукту).

Ограничения представляют собой факторы, ограничивающие выбор способов и средств (в том числе инструментов) реализации продукта.

Несколько простых, изолированных от контекста и друг от друга примеров ограничений:

· Все элементы интерфейса должны отображаться без прокрутки при разрешениях экрана от 800x600 до 1920x1080.

· Не допускается использование Flash при реализации клиентской части приложения.

· Приложение должно сохранять способность реализовывать функции с уровнем важности «критический» при отсутствии у клиента поддержки JavaScript.

Требования к интерфейсам описывают особенности взаимодействия разрабатываемой системы с другими системами и операционной средой.

· Несколько простых, изолированных от контекста и друг от друга примеров требований к интерфейсам:

· Обмен данными между клиентской и серверной частями приложения при осуществлении фоновых AJAX-запросов должен быть реализован в формате JSON.

· Протоколирование событий должно вестись в журнале событий операционной системы.

· Соединение с почтовым сервером должно выполняться согласно RFC3207 («SMTP over TLS»).

Требования к данным описывают структуры данных (и сами данные), являющиеся неотъемлемой частью разрабатываемой системы. Часто сюда относят описание базы данных и особенностей её использования.

Несколько простых, изолированных от контекста и друг от друга примеров требований к данным:

· Все данные системы, за исключением пользовательских документов, должны храниться в БД под управлением СУБД MySQL, пользовательские документы должны храниться в БД под управлением СУБД MongoDB.

· Информация о кассовых транзакциях за текущий месяц должна храниться в операционной таблице, а по завершении месяца переноситься в архивную.

· Для ускорения операций поиска по тексту статей и обзоров должны быть предусмотрены полнотекстовые индексы на соответствующих полях таблиц.

Спецификация требований (software requirements specification, SRS83) объединяет в себе описание всех требований уровня продукта и может представлять собой весьма объёмный документ (сотни и тысячи страниц).

Поскольку требований может быть очень много, а их приходится не только единожды написать и согласовать между собой, но и постоянно обновлять, работу проектной команды по управлению требованиями значительно облегчают соответствующие инструментальные средства (requirements management tools84, 85).