Качество программного изделия

Качество программного обеспечения — характеристика программного обеспечения (ПО) как степени его соответствия требованиям.

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

§ Читаемость кода.

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

§ Низкая сложность кода.

§ Низкое использование ресурсов: памяти и процессорного времени.

§ Корректная обработка исключительных ситуаций.

§ Малое число предупреждений при компиляции.

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

Некоторые из факторов качества:

§ Понятность – назначение ПО должно быть понятным, из самой программы и документации.

§ Полнота – все необходимые части программы должны быть представлены и полностью реализованы.

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

§ Портируемость – лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии.

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

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

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

§ Удобство использования – простота и удобство использования программы. Это требование относится прежде всего к интерфейсу пользователя.

§ Надёжность – отсутствие отказов и сбоев в работе программ, а также простота исправления дефектов и ошибок;

§ Структурированность;

§ Эффективность – насколько рационально программа относится к ресурсам (память, процессор) при выполнении своих задач.

§ Безопасность;

Стиль программирования

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

Три фактора хорошего стиля программирования:

1. требования простоты, лёгкости и удобочитаемости программы;

2. использование программистом особенностей языка программирования;

3. стремление программиста повысить эффективность программы в результате тщательного анализа структуры данных и ресурсов.

43. Тестирование программного обеспечения. Основные принципы разработки тестов для программных продуктов. Особенности тестирования объектно - ориентированных программ.

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

Отладка – выявление места, где происходит ошибка, и внесение исправлений в программу.

Цель тестирования – обнаружение ошибок в программе.

Этапы тестирования:

1. Проверка нормальных условий. Тестирование на основе данных, характерных для реальных условий функционирования программы.

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

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

Принципы:

1. Ошибки в программе есть всегда.

2. Тестовые данные должны быть достаточно просты для проверки.

3. Готовятся тесты заранее до выхода на машину.

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

5. Результаты тестирования должны быть зафиксированы.

6. Тесты должны быть одинаково как для правильных исходных данных, так и для неправильных.

7. Необходимо проверить два момента:

· программа делает то, что должна делать;

· программа не делает то, чего она делать не должна.

8. Результаты тестов необходимо тщательно анализировать.

9. Ради упрощения тестирования недопустимо изменять саму программу.

10. После исправления ошибки необходимо заново проводить тестирование.

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

12. Тестирование лучше проводить не автору, а другому человеку.

Объектно-ориентированная технология привносит свои особенности в процесс тестирования систем. Формулируется несколько вопросов, которые необходимо разрешить для успешного проведения тестирования:

§ Какая часть унаследованных свойств должна заново тестироваться.

§ Когда и как можно проверять информацию о состоянии класса.

§ Как можно проверить поведение системы, зависящее от состояния, когда отсутствует единый механизм управление состояниями в программе.

§ Как следует тестировать интеграцию классов и какие стратегии тестирования применять.

Решение подобных вопросов выполняется путем разработки новых подходов и модернизации старых, специально для тестирования объектно-ориентированных систем.

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

Основные свойства объектов добавляют новые аспекты тестирования:

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

Наследование ставит вопросы о повторении тестирования наследуемых операций. Допустим операция А принадлежит базовому классу, и она протестирована. Операция В принадлежит производному классу и вызывает операцию А. Должна ли операция А тестироваться повторно?

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

44. Основные понятия и определения теории тестирования. Подходы к тестированию. Стратегии тестирования. Критерии тестирования.

Тестирование программного обеспечения — процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта.

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

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

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

Критерии «чёрного ящика»:

1. Критерий тестирования функций.

2. Критерий тестирования входных данных.

3. Критерий тестирования выходных данных.

4. Тестирование области допустимых значений.

5. Тестирование длины набора данных (пустой, единичный, минимально возможной длины, выход за пределы длины).

6. Тестирование упорядоченности входных данных.

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

Критерии «белого ящика»:

1. Критерий покрытия операторов.

2. Критерий покрытия решений (ветвей).

3. Критерий покрытия путей.

4. Критерий комбинаторного покрытия условий.

5. Критерий минимально грубого тестирования.

45. Способы тестирования программ, состоящих из модулей (блоков).

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

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

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