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

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

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

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

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

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

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

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

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

Необходимо отметить, что тест на отказ и восстановление является довольно специфическим тестированием. При разработке сценариев тестирования следует учитывать все особенности тестируемого программного обеспечения. Методы воздействия при этом применяются достаточно жесткие, поэтому следует сразу решить: необходимо и целесообразно вообще проводить подобные испытания для конкретной программы?

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

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

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

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

Связанные с изменениями виды тестирования реализуются после внесения необходимых изменений и корректировки. Программа должна быть заново протестирована, чтобы подтвердить, что ошибка была устранена. [^[5]]

1.3 Сущность и методика отладки программ. Виды ошибок

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

Нелогичный пользовательский интерфейс;

Неудовлетворенные ожидания;

Низкая производительность;

Аварийные завершения или разрушение данных.

Нелогичный пользовательский интерфейс это разновидность не очень серьезных ошибок, однако может привести к потере потенциальных клиентов и снижению рейтинга вашего продукта. Почему, например, операционная система Windows от Microsoft пользуется такой популярностью? Одной из причин является как раз – удобный и понятный пользовательский интерфейс во всех ее приложениях. Если отклониться от ее стандартов, программа становится трудной для использования пользователем. В качестве примера такого трудного приложения можно привести Microsoft Outlook. В нем различные сочетания клавиш для быстрой работы не соответствуют вызовам привычных функций и действий пользователя; например поиск и др.

Если говорить о клиентских приложениях, то в них проблема нелогичности решается довольно просто. При разработке лишь необходимо придерживаться специальных рекомендаций и стандартов для Windows-приложений.

В случае проектирования интерфейса Web-приложения, эта задача существенно усложняется. Здесь уже нет конкретных стандартов на пользовательский интерфейс. Самое главное, что надо учитывать при разработке интерфейса для Web-клиента, это возможную низкую скорость трафика, поэтому следует создавать пользовательский интерфейс максимально простым и избегать загрузки с сервера всяких ненужных мелочей, тяжелых графических элементов и прочего. К примеру, простые решения, подобные CNN.com, нравятся практически всем пользователям. Использование простого набора ссылок выглядит куда лучше и работает быстрее, чем нагромождение всякого ненужного функционального хлама, вызывающее неудобства и отпугивающего клиентов.[^[6]]

Одной из наиболее трудноразрешимых ошибок являются неудовлетворенные ожидания пользователей. Причиной этого обычно является недостаточность исследования реальных потребностей потребителя, т.е. возникает проблема взаимодействия. Подобные ошибки обычно возникают на самых ранних этапах проектирования программы.[^[7]]

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

Наибольшее разочарование приносят ошибки, приводящие к снижению производительности при некорректной обработке данных приложением. Зачастую именно эти ошибки вызваны недостаточным тестированием программного обеспечения. Они могут быть выявлены с запозданием при обработке большого массива данных. Очень часто бывает так, что выпуская первую версию недостаточно протестированной программы на рынок, производитель обрекает себя на полный провал. Причем последующие исправленные версии уже не хочет использовать большая часть пользователей, которые обожглись на первой версии приложения.

Существует два основных метода борьбы с подобными ошибками. С одной стороны необходимо сразу же установить конкретные требования к производительности программного продукта. Для выявления проблем с производительностью нужно сравнить основные показатели работы приложения под разными нагрузками. Если вдруг происходит потеря производительности на 10%, то необходимо принять меры и выяснить – по какой причине это произошло и внести нужные изменения в код.

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

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

Если же уделять достаточно внимания всякого рода деталям, то ошибок можно если не избежать, то минимизировать. Причин появления всех этих ошибок достаточно много, но из них можно выделить основные. Это, во-первых, непонимание разработчиками требований предъявляемых к программному продукту. Так происходит, когда приложение наполняется ненужными функциями и другими мелочами без необходимости. Во-вторых, причиной могут быть невежественные и мало обученные разработчики, которые недостаточно разбираются в операционных системах, технологиях и языках программирования. В-третьих, какие либо административные причины – слишком сжатые и невозможные для разработки поставленные сроки. Вопрос о приемлемости поставленных сроков должен обсуждаться всеми разработчиками на основании набора реализуемых функций. В случае недостаточности времени на качественную работу целесообразней даже просто отказаться от выполнения заказа. Одной из частых причин ошибок в программах является недостаточная ориентация на выпуск качественной продукции. Разработчики должны гордиться своим творением и корпят над всеми элементами продукта, а не только над теми, что им интересны. Например, вместо того чтобы копаться в деталях алгоритма, они выбирают более простой алгоритм и думают, как лучше его протестировать. В конце концов, заказчика интересуют не алгоритмы, а качественный продукт. Производители программного обеспечения, по настоящему приверженные качеству, должны опираться на тщательное планирование, персональную ответственность, надлежащий контроль качества и хорошие способности к общению с клиентами и между собой. Многие программисты на разных этапах разработки больших систем, но только тот, кто уделяет значительное внимание деталям, будет выпускать продукцию в нужные сроки и отличного качества.[^[8]]