Файл: Отладка и тестирование программ: основные подходы и ограничения (Модульное тестирование).pdf

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

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

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

1.2. Организация процесса тестирования

При тестировании программного продукта одновременно проводится в трех направлениях:

Проверка кода.

Тестирование высокого уровня.

Тестирование низкого уровня.

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

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

Тестирование высокого уровня ставит перед собой цель выявить насколько удовлетворяет разработка требованиям заказчика. Для программы пишутся специальные эмуляторы, с помощью которых тестировщик наблюдает за работой системы в качестве оператора. Он оценивает, как система производит диалог с пользователем и какие сообщения она выдает на различные события. Тестирование низкого уровня: Тестер проверяет, на сколько логически полно исходный код покрывает всё возможные варианты работы системы, для которой он разрабатывается [8].

1.3. Качество программного обеспечения

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

Тестирование требований выполняется на предмет их соответствия критериям качества требований, перечисленным далее. Завершённость (completeness). Требование является полным и законченным с точки зрения представления в нём всей необходимой информации, ничто не пропущено по соображениям «это и так всем понятно».

Типичные проблемы с завершённостью: - Отсутствуют нефункциональные составляющие требования или ссылки на соответствующие нефункциональные требования (например: «пароли должны храниться в зашифрованном виде», а каков алгоритм шифрования?). - Указана лишь часть некоторого перечисления (например: «экспорт осуществляется в форматы PDF, PNG и т.д.», а что следует понимать под «и т.д.»?). - Приведённые ссылки неоднозначны (например: «см. выше» вместо «см. раздел 123.45.b»).

Атомарность, единичность (atomicity). Требование является атомарным, если его нельзя разбить на отдельные требования без потери завершённости и оно описывает одну и только одну ситуацию. Типичные проблемы с атомарностью: - В одном требовании, фактически, содержится несколько независимых (например: «кнопка “Restart” не должна отображаться при остановленном сервисе, окно “Log” должно вмещать не менее 20-ти записей о последних действиях пользователя»: здесь в одном предложении описаны совершенно разные элементы интерфейса в совершенно разных контекстах). - Требование допускает разночтение в силу грамматических особенностей языка (например: «если пользователь подтверждает заказ и редактирует заказ или откладывает заказ, должен выдаваться запрос на оплату»: здесь описаны три разных случая, и это требование стоит разбить на три отдельных требования во избежание путаницы).

Такое нарушение атомарности часто влечёт за собой возникновение противоречивости. - В одном требовании объединено описание нескольких независимых ситуаций (например: «когда пользователь входит в систему, должно отображаться приветствие; когда пользователь вошёл в систему, должно отображаться имя пользователя; когда пользователь выходит из системы, должно отображаться прощание»: все эти три ситуации заслуживают того, чтобы быть описанными отдельными и более детальными требованиями). Непротиворечивость, последовательность (consistency). Требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.

Типичные проблемы с непротиворечивостью: - Противоречия внутри одного требования (например: «после успешного входа в систему пользователя, не имеющего права входить в систему…»: а как пользователь вошёл в систему, если не имел такого права?). - Противоречия между двумя и более требованиями, между таблицей и текстом, рисунком и текстом, требованием и прототипом и т.д. (например: «712.a Кнопка “Close” всегда должна быть красной» и «36452.x Кнопка “Close” всегда должна быть синей»: так всё же красной или синей?). - Использование неверной терминологии или использование разных терминов для обозначения одного и того же объекта или явления (например: «в случае, если разрешение окна составляет менее 800x600…»: разрешение есть у экрана, у окна есть размер). Недвусмысленность (unambiguousness, clearness).

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

Требование атомарно в плане невозможности различной трактовки сочетания отдельных фраз. Типичные проблемы с недвусмысленностью: - Использование терминов или фраз, допускающих субъективное толкование (например: «приложение должно поддерживать передачу больших объёмов данных»: насколько «больших»?)

Вот лишь небольшой перечень слов и выражений, которые можно считать верными признаками двусмысленности: адекватно, быть способным, легко, обеспечивать, как 8 минимум, быть способным, эффективно, своевременно, применимо, если возможно, будет определено позже, по мере необходимости, если это целесообразно, но не ограничиваясь, быть способно, иметь возможность, нормально, минимизировать, максимизировать, оптимизировать, быстро, удобно, просто, часто, обычно, большой, гибкий, устойчивый, по последнему слову техники, улучшенный, результативно. - Использование неочевидных или двусмысленных аббревиатур без расшифровки (например: «доступ к ФС осуществляется посредством системы прозрачного шифрования» и «ФС предоставляет возможность фиксировать сообщения в их текущем состоянии с хранением истории всех изменений»: ФС здесь обозначает файловую систему или какой-нибудь «Фиксатор Сообщений»?)

- Формулировка требований из соображений, что нечто должно быть всем очевидно (например: «Система конвертирует входной файл из формата PDF в выходной файл формата PNG» и при этом автор считает совершенно очевидным, что имена файлов система получает из командной строки, а многостраничный PDF конвертируется в несколько PNG-файлов, к именам которых добавляется «page-1», «page-2» и т.д.). Эта проблема перекликается с нарушением корректности. Выполнимость (feasibility). Требование технологически выполнимо и может быть реализовано в рамках бюджета и сроков разработки проекта.

Типичные проблемы с выполнимостью: - «Озолочение» (gold plating) — требования, которые крайне долго и/или дорого реализуются и при этом практически бесполезны для конечных пользователей (например: «настройка параметров для подключения к базе данных должна поддерживать распознавание символов из жестов, полученных с устройств трёхмерного ввода»).

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

Обязательность, нужность (obligation) и актуальность (up-todate). Если требование не является обязательным к реализации, оно должно быть просто исключено из набора требований. Если требование нужное, но «не очень важное», для указания этого факта используется указание приоритета. Также исключены (или переработаны) должны быть требования, утратившие актуальность. Типичные проблемы с обязательностью и актуальностью:

- Требование было добавлено «на всякий случай», хотя реальной потребности в нём не было и нет. - Требованию выставлены неверные значения приоритета по критериям важности и/или срочности. - Требование устарело, но не было переработано или удалено. Прослеживаемость (traceability). Прослеживаемость бывает вертикальной и горизонтальной. Вертикальная позволяет соотносить между собой требования на различных уровнях требований, горизонтальная позволяет соотносить требование с тест-планом, тест-кейсами, архитектурными решениями и т.д. Для обеспечения прослеживаемости часто используются специальные инструменты по управлению требованиями и/или матрицы прослеживаемости. 1

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

. Модифицируемость (modifiability). Это свойство характеризует простоту внесения изменений в отдельные требования и в набор требований. Можно говорить о наличии модифицируемости в том случае, если при доработке требований искомую информацию легко найти, а её изменение не приводит к нарушению иных описанных в этом перечне свойств. Типичные проблемы с модифицируемостью: - Требования неатомарны (см. «атомарность») и непрослеживаемы, а потому их изменение с высокой вероятностью порождает противоречивость. - Требования изначально противоречивы. В такой ситуации внесение изменений (не связанных с устранением противоречивости) только усугубляет ситуацию, увеличивая противоречивость и снижая прослеживаемость.

Требования представлены в неудобной для обработки форме (например, не использованы инструменты управления требованиями, и в итоге команде приходится работать с десятками огромных текстовых документов). Проранжированность по важности, стабильности, срочности (ranked for importance, stability, priority). Важность характеризует зависимость успеха проекта от успеха реализации требования. Стабильность характеризует вероятность того, что в обозримом будущем в требование не будет внесено никаких изменений.

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

Проблемы с проранжированностью по стабильности повышают риск выполнения бессмысленной работы по совершенствованию, реализации и тестированию требований, которые в самое ближайшее время могут претерпеть кардинальные изменения (вплоть до полной утраты актуальности). Проблемы с проранжированностью по срочности повышают риск нарушения желаемой заказчиком последовательности реализации функциональности и ввода этой функциональности в эксплуатацию. Корректность (correctness) и проверяемость (verifiability).

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