Функциональное тестирование. 
Тестирование программного обеспечения

Рис 3. Элементы функционального тестирования

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

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

Системные требования к разрабатываемому программному обеспечению — это строительные блоки, из которых разработчик воздвигает свою систему. Системные требования делятся на функциональные и дополнительные. Функциональные системные требования определяют то, как пользователь выполняет свои функции. Например, в систему необходимо ввести систему поиска устройства по данным gps — это требование будет является функциональным. Нефункциональными требования, как правило называют требования к качеству продукции.

Системные требования можно классифицировать по различным параметрам, таким как требования по уровням:

Рис 4. Классификация системных требований

Бизнес-требования — описывают то, как разрабатываемую систему видит компания-разработчик или заказчик. Эти требования так же содержат тот предполагаемый источник прибыли или выгоды, которые рассчитывают получить заинтересованные стороны. Они могут быть описаны в виде документов, кейсов либо в виденье проекта или в перечне функционала. Бизнес требования описывают виденья главы проекта или заинтересованных лиц на одном комплекте документации. Программное обеспечение не может быть написано исходя лишь из этой высокоуровневой информации. Бизнес-требования в первую очередь содержат информацию о:

• 1. Целях разрабатываемого проекта
• 2. Задачах разрабатываемого проекта
• 3. Области покрытия проекта
• 4. Ожидаемом результате разработки проекта
• 5. Приоритете и ожидаемых сроках завершения проекта
• 6. Целесообразности проекта, зачем нужно разрабатывать этот проект, как он будет приносить прибыл
• 7. Подразделениях и отделах компании, участвующие в разработке проекта.

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

В разработке и дизайне программного обеспечения очень важно понимать, что хочет пользователь от взаимодействия с данной системой. Это вызвано тем, что пользователь часто бывает не в состоянии полностью взаимодействовать с системой из-за непродуманного интерфейса, который не обеспечивает должной функциональности или выдает пользователю неполную или неточную информацию о процессах и состоянии системы.

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

User case: Включить компьютер.

Актеры: Пользователь Частота: Каждый день Приоритет: 1 (высший) Описание: пользователь включает выключенный ранее компьютер.

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

Поток нормальный.

• 1. Пользователь нажимает кнопку POWER на системном блоке
• 2. Загружается BIOS
• 3. BIOS инициализирует компоненты системы
• 4. Загружается OS
• 5. Система предлагает ввести пользователю пароль для доступа к его учетной записи
• 6. Пользователь вводит пароль
• 7. Пользователь попадает на рабочий столь

Сценарий завершен Сценарий 1а.

• 1. А) Пользователь нажимает кнопку POWER на системном блоке
• 2. А) BIOS не загружается.

Конец сценария Сценарий 1а 2.

• 3. Б) Компьютер не включен в сеть
• 4. Б) Пользователь включает компьютер
• 5. Б) Назад к шагу 1

Сценарий 1а 3.

• 2. В) Компьютер включен в сеть
• 3. В) Нужно проверить исправности материнской платы

Вторая группа требований — нефункциональные требования. Эти требования содержат требования к качеству работы системы, такие как работоспособность, масштабируемость, ремонтопригодность и удобство. Они так же важны, как и функциональные, так как они определяют, будет ли комфортно пользователю взаимодействовать с конечной системой. Невыполнение любого из этих пунктов может повлечь несоответствие системы с заявленными параметрами в плане использования и функционирования. Нефункциональные требования определяют качество и стабильность к системе и обычно не меняются от релиза к релизу и остаются постоянными на весь период разработки. Нефункциональные требования встречаются на всех трех уровнях разработки. Основное «место обитания» — программный уровень. Это такой уровень, на котором определяется качество программного обеспечения — уровень работы программы. Так же нефункциональные требования существуют на уровне команд разработок — важный для реализации таких требований уровень, на котором определяются то, как будут функционировать между собой команды разработчиков. Эти связи способствуют более гладкому и гибкому процессу разработки, который позволит избежать множества ошибок и тем самым повысить качество системы. Уровень документации так же может содержать в себе нефункциональные требования. Выделяют следующие виды нефункциональных требований:

Бизнес правила. Включают в себя какие-либо правила, по которым система должна быть описана так и никак иначе. Может содержать какие-либо правила и пожелания заказчика, отсылки на законодательство.

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

Атрибуты качества. К атрибутам качества обычно относят такие характеристики как:

• 1. легкость и простота использования
• 2. производительность
• 3. удобство эксплуатации
• 4. удобство технического обслуживания
• 5. надежность и устойчивость к сбоям
• 6. взаимодействие системы с пользователем
• 7. расширяемость и гибкость.

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

Функциональная декомпозиция.

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

Анализ требований

Это процесс систематизации, анализа и выявления противоречий в написанных для разрабатываемого программного обеспечения требований. К таковому процессу тестирования он отношения не имеет и применяется аналитиками на стадии разработки и дизайна концепции приложения.