Файл: Отладка и тестирование программ: основные подходы и ограничения.pdf
Добавлен: 30.06.2023
Просмотров: 68
Скачиваний: 3
Нефункциональная проверка берет свою основу на тестах, которые нужны для определения разных характеристик продукта, измеряющихся всеразличными величинами, т.е. указывает, каким образом программа ведет себя в работе. Нефункциональные тесты включают в себя ряд подвидов. Это тестирование производительности, установка, удобство, тест отказа и конфигурация.
Тест производительности или нагрузочный тест имитирует работу системы несколькими пользователями в распределенных ресурсах программы. Выявляются возможности и недостатки приложения при работе под нагрузкой и в стрессовых условиях – стабильная работа программ.
Тестирование является одной из важнейших задач обеспечения качества программного обеспечения и служит для нормальной установки приложения, его конфигурации и обновления. В настоящее время наиболее распространенной является установка программ с помощью специальных программных модулей - инсталляторов, которые сами нуждаются в соответствующих тестах.
Если установщик не установлен, установка выполняется независимо в соответствии с инструкциями и спецификациями или специальным планом установки; например, в распределенных системах.
Тест юзабилити не имеет никакого отношения к тестированию функциональности пользовательского интерфейса, он выполняется только на пользовательском интерфейсе, а также на многих других возможных компонентах продукта. Это всего лишь метод тестирования, который определяет простоту использования программы, обучение, понятность для пользователей программного обеспечения в определенных условиях. В то же время удобство использования программы в соответствии с критериями эффективности, эффективностью, точностью действий пользователя, запоминанием, а также необходимой эмоциональной реакцией человека после работы с продукт оценивается.
Функциональность самой программы проверяется тестом черного ящика, а также ее интерфейсом, проверяя белый ящик, где проверяется удобство использования модулей, классов, методов и переменных и возможность изменения , модификации системы и простоты интеграции. Все это вещи нужны для повышения качества, скорости написания кода, а также его поддержки. Тестирование комфорта можно проводить на разных этапах разработки продукта. Чтобы создать практическую концепцию программ, полезно следовать принципу «защита от дурака». Таким образом, если вам нужно ввести целочисленное значение в поле формы, вы должны ограничить пользователя диапазоном ввода только числами и исключить другие символы, чтобы избежать исключений из кода.
Тесты отказов и восстановления анализируют стрессоустойчивость программы, когда оборудование ломается, сеть ломается и другие. Проверяются системы отката и восстановления для обеспечения целостности и безопасности этих программ в случае сбоя в нормальной работе программы или окружающей среды. Этот тест просто необходим при разработке веб-приложений, поскольку потеря данных может привести к потере многих клиентов, денег и, что самое важное, репутации вашего продукта.
Технически это достигается путем моделирования сбоя питания, сбоя связи, отключения носителя или специального тестового набора для ситуации с наличием в системе неверных данных.
Следует отметить, что тест на отказ и восстановление - это довольно специфическое тестирование. При разработке тестовых примеров вы должны учитывать все функции тестируемого программного обеспечения. В этом случае методы воздействия довольно жесткие, поэтому вы должны решить немедленно: необходимо ли и необходимо выполнить такие тесты для конкретной программы?
Тестирование конфигурации предназначено для тестирования производительности программы в различных конфигурациях системы, платформах, средах, оборудовании и т.Д. Целями этого тестирования могут быть: определение оптимальной конфигурации оборудования или возможность миграции и совместимости системы с различными платформами и конфигурациями компьютеров.
В случае клиент-серверных приложений тестирование выполняется на уровне сервера и клиента. На уровне сервера продукт тестируется на аппаратном и программном обеспечении. Здесь особое внимание уделяется определению оптимальной конфигурации оборудования, обеспечивающего хорошее качество, производительность и надежность.
На клиентском уровне анализируется состояние конечных пользователей программы с различными конфигурациями клиентских машин и операционных систем. Особое внимание уделено функциональности и удобству использования программного обеспечения. Тесты выполняются с учетом всех возможных параметров: типа операционной системы, размера бит, типа браузера, характеристик видеоадаптера, драйверов, библиотек, разрешения экрана и т. Д.
И чем больше требований предъявляется к работе программы при различных конфигурациях компьютеров, тем больше различных тестов потребуется провести. Например в данных случае будет очень эффективным автоматизация процесса тестирования, которая позволит сэкономить огромное количество времени и средств разработчиков.
Связанные с изменением типы тестирования реализуются после внесения необходимых изменений и корректировок. Программа должна быть заново протестирована, чтобы подтвердить, что ошибка была устранена.
1.3 Сущность и методика отладки программ. Виды ошибок
Весь спектр возможных ошибок в программных продуктах можно условно разделить на четыре категории:
Нелогичный пользовательский интерфейс;
Неудовлетворенные ожидания;
Низкая производительность;
Аварийные завершения или разрушение данных.
Нелогичный пользовательский интерфейс представляет собой версию не очень серьезных ошибок, но это может привести к потере потенциальных клиентов и снижению оценки вашего продукта. Почему, например, так популярна операционная система Microsoft Windows? Одной из причин является как раз – удобный и понятный пользовательский интерфейс во всех ее приложениях. Если отклониться от ее стандартов, программа становится трудной для использования пользователем. Примером такого сложного приложения является Microsoft Outlook. В этом случае различные сочетания клавиш для быстрой работы не соответствуют вызовам обычных функций и действий пользователя; как исследования и т. д.
Если мы говорим о клиентских приложениях, то проблема нелогичности просто решена. При разработке лишь необходимо придерживаться специальных рекомендаций и стандартов для Windows-приложений.
В случае проектирования интерфейса веб-приложения эта задача намного сложнее. Для пользовательского интерфейса нет конкретных стандартов. Самое важное, что следует учитывать при разработке интерфейса для веб-клиента, - это низкая возможная скорость трафика, поэтому вам нужно как можно более просто создать пользовательский интерфейс и не скачивать ненужные мелочи, тяжелую графику и другие вещи сервера. Например, простые решения, такие как CNN.com, как и почти все пользователи. Использование простого набора ссылок кажется намного лучше и работает быстрее, чем куча ненужных функциональных отходов, вызывая неудобства и напуганные клиенты.
Одной из главных сложно разрешимых ошибок являются завышенные и вседствие неудовлетваренные ожидания пользователей. Причиной обычно является отсутствие исследований реальных потребностей потребителя, то есть проблема взаимодействия. Такие ошибки обычно возникают на самых ранних этапах разработки программы.
Сами разработчики напрямую не взаимодействуют с клиентами своих программ, поэтому они не изучают, какие пользователи нуждаются в себе. Поэтому нужно взаимодействовать с клиентами, для того чтобы узнать, что они делают с их программами. Многие будут проясняться, если вы будете наблюдать за действиями обычного пользователя или клиента, как используется ваше программное обеспечение. Кроме того, этот опыт позволит разработчику понять, что, по мнению клиента, требуется от разрабатываемого приложения.
Наибольшее разочарование вызвано ошибками, которые приводят к снижению производительности, когда приложение обрабатывает неверные данные. Довольно часто подобного рода ошибки могут быть вызваны недостаточно полной проверкой программного обеспечения. Их можно идентифицировать с задержкой при обработке большого набора данных. Часто бывает, что публикация первой версии программы, не прошедшей проверку на рынке, производитель обречен на полный сбой. И следующие исправленные версии больше не используются большинством пользователей, которые ошибались в первой версии приложения.
Существует два основных метода решения таких ошибок. С одной стороны, вы должны немедленно установить конкретные требования к производительности программного продукта. Чтобы определить проблемы с производительностью, вы должны сравнить базовую производительность приложения в разных рабочих нагрузках. Если есть потеря производительности 10%, вы должны действовать и обнаруживать - по какой-либо причине и вносить необходимые изменения в код.
Затем вам нужно убедиться, что загрузка действительно соответствует наиболее близкому к реальному сценарию, и вам нужно сделать это на самых ранних этапах проектирования.
В случае аварийного завершения и потери данных, а также утечки памяти также очень болезненны для пользователей. Это наиболее распространенный вид ошибок. Среди этих дефектов есть и простые в разрешении, и практически неразрешимые ошибки. Недопустимо размещать такой продукт на рынке, заранее зная такие дефекты, даже самые незначительные.
Если вы уделяете достаточное внимание всем видам деталей, ошибки могут, если не избегать, сводить к минимуму. Причин появления всех этих ошибок довольно много, но можно выделить основные. Это, во-первых, непонимание разработчиками требований предъявляемых к программному продукту. Это происходит, когда приложение заполняется бесполезными функциями и различными мелочами без необходимости в них. Во-вторых, причиной могут быть невежественные и мало обученные разработчики, которые недостаточно разбираются в операционных системах, технологиях и языках программирования. В-третьих, все административные причины - слишком короткие и невозможные для разработки сроков. Вопрос о приемлемости крайних сроков должен обсуждаться всеми разработчиками на основе набора реализованных функций. В случае отсутствия времени для качественной работы, даже лучше просто отказаться от выполнения заказа. Наиболее частая причина ошибок и недочетов в программах является недостаточный расчет на производство качественной продукции. Разработчики должны гордиться своим созданием и складывать все элементы продукта, а не только те, которые их интересуют. Например, вместо того, чтобы копать детали алгоритма, они выбирают более простой алгоритм и думают о лучшем способе его протестировать. В конце концов, клиент не заинтересован в алгоритмах, а в качественных продуктах. Поставщики программного обеспечения, которые действительно привержены качеству, должны полагаться на тщательное планирование, личную ответственность, надлежащий контроль качества и хорошие коммуникативные навыки с клиентами и друг с другом. Большинство программистов находятся на разных этапах разработки больших систем, но выпускать качественную продукцию будет тот, кто будет уделять большое количество времени важным деталям.
Планирование тестирования должно проводиться в сочетании с планированием отладки. В то же время во время планирования задача состоит в том, чтобы найти разные способы ускорения и оптимизации обоих процессов. Чтобы сохранить меры предосторожности, вы должны писать и использовать всевозможные утилиты для анализа дампа файла и проверки внутренних структур и двоичных файлов параллельно. Если приложение работает с данными и двоичными файлами, тогда необходимо предоставить специальную тестовую утилиту, которая преобразует и представляет данные в удобном формате. Приложение дампа также должно проверять данные и их зависимости в двоичных файлах. Данные меры сильно упрощают процесс проверки и отладки.
При планировании и проектировании вам необходимо создать достаточный объем кода для отладки в ваших программах, поэтому этот код подскажет программисту обнаружить ошибки. Именно код, а не отладчик.
2. Практика отладки приложений в среде Delphi
2.1 Два важных инструмента
тестирование отладка программный delphi
Двумя важнейшими структурными элементами являются специальные системы управления версиями приложения и отслеживания ошибок. Эти инструменты записывают полную историю проекта. Многие программисты пытаются хранить необходимую информацию в уме. Однако, если они работают в компании, желательно, чтобы у нее была вся информация. Во многих случаях документация по требованиям к продукту и проектной документации плохо поддерживается в дизайне приложения. В результате единственными полезными документами являются контрольные журналы управления проектами и системы отслеживания ошибок.
Слежение за частотой обнаружения и разрешение проблем, использование системы треккинга ошибок дает возможность точно планировать дату и время о работы над программой. Кроме того, система управления версиями дает представление о степени изменения кода, поэтому вы можете определить, сколько потребуется дополнительное тестирование. Этот инструментарий предоставляет нам один из лучших способов оценки того, как эффективны изменения, которые вносятся по ходу производства программного обеспечения.