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

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

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

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

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

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

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

изучить литературу в данной области;
раскрытие понятия «качество»;
изучить понятие «верификация»;
изучить виды тестирования;
провести анализ методов отладки программ.

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

1. Исследование предметной области

1.1 Анализ понятия «качество»

Качество программного обеспечения (Software quality) — это то насколько программное обеспечение удовлетворяет предъявляемым к нему требованиям. Выдвигаемые требования могут зависеть от многих критериев, определяемых исходя из сферы применения программного продукта.

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

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

«Приемлемое качество» можно сравнивать с уровнем обслуживания в рамках заданного SLA – Service Level Agreement. То есть, приемлемое качество может рассматриваться как <количественно выраженный> компромисс между заказчиком и исполнителем в отношении характеристик продукта, создаваемого исполнителем в интересах <решения задач> заказчика с учетом других ограничений проекта (в частности, стоимостью, что часто именуется как «cost of quality» – «стоимость качества»).

Согласие, достигнутое по требованиям к качеству (в оригинале — quality requirements), наравне с четким доведением до инженеров того, что составляет качество получаемого продукта, требуют обсуждения и формального определения многих аспектов качества. [7, 8, 16]

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

Важной идеей является то, что программные требования определяют требуемые характеристики качества программного обеспечения, а также влияют на методы количественной оценки и сформулированные для оценки этих характеристик <соответствующие> критерии приемки.

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

Можно выделить несколько основных критериев оценки качества программного обеспечения:

1. Качество исходного кода.

соответствие кода стандартам;
легкость поддержки;
малое число предупреждений при компиляции.

2. Качество программного продукта.

функциональность;
надежность;
удобство использования;
эффективность;
безопасность.

Становится понятно, что предъявляемые требования должны удовлетворять потребностям, как разработчиков программного обеспечения, так и его пользователей. [7, 8, 16]

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

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

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

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

Ожидается, что инженеры по программному обеспечению воспринимают вопросы качества программного обеспечения как часть своей профессиональной культуры. [7, 8, 16]

Этические аспекты могут играть значительную роль в обеспечении качества программного обеспечения, культуре и отношении инженеров <к своей работе>. IEEE Computer Society и ACM разработали кодекс этики (“моральный кодекс” – code of ethics) и профессиональной практики, основанный на восьми принципах, помогающих инженерам укрепить их отношение к качеству и независимость в решении вопросов обеспечения достойного качества создаваемых программных продуктов в их повседневной работе.

Понятие “качество”, на самом деле, не столь очевидно и просто, как это может показаться на первый взгляд. Для любого инженерного продукта существует множество интерпретаций качества, в зависимости от конкретной “системы координат”. Характеристики качества могут требоваться в той или иной степени, могут отсутствовать или могут задавать определенные требования, все это может быть результатом определенного компромисса. [16]

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

1.2 Верификация

Проверка и аттестация программного обеспечения – упорядоченный подход в оценке программных продуктов, применяемый на протяжении всего жизненного цикла. Усилия, прилагаемые в рамках работ по проверке и аттестации, направлены на обеспечение качества как неотъемлемой характеристики программного обеспечения и удовлетворение пользовательских требований. [16]

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

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

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

Аттестация – попытка обеспечить создание правильного продукта (построен правильный продукт; обычно, в контексте конечного продукта), с точки зрения достижения поставленной цели.

Оба процесса – верификация и аттестация – начинаются на ранних стадиях разработки и сопровождения. Они обеспечивают исследованию (экспертизу) ключевых возможностей продукта как в контексте непосредственно предшествующих результатов (промежуточных продуктов), так и с точки зрения удовлетворения соответствующих спецификаций. Целью планирования V&V является обеспечение процессов верификации и аттестации необходимыми ресурсами, четкое назначение ролей и обязанностей. Получаемый план V&V документирует и <детально> описывает различные ресурсы, роли и действия, а также используемые техники и инструменты.

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

1.3 Тестирование программных продуктов

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

Процесс должен начинаться, как только началась разработка ПО, чтоб уже к первой сборке проекта был некоторый план тестирования. В первую очередь проводится дымовое тестирование — это совокупность общих, критических сценариев, которые проверяют основную функциональность. На основе этого делается вывод о возможности и целесообразности дальнейшего тестирования. Далее основная работа централизованное тестирование по тест-кейсам и/или исследовательское тестирование. Процесс завершается написанием отчета и предоставлением баг-репортов. С процессом тестирования связано еще одно интересное понятие – это тест дизайн. Тест дизайн — это процесс проектирования определенных тестовых случаев в соответствии с определенными критериями. [7, 8, 14]

При тестировании ПО должен быть отдельный сервер, виртуальный или реальный, на котором для тестировщика есть некоторая сборка с которой работает только он.

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

В данной главе были раскрыты теоретические основы понятия тестирования программ, рассмотрено понятие «качество» ПО.