Организация тестирования в объектно-ориентированных системах

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

Традиционно тестирование делится на тестирование элементов, интеграционное тестирование и системное тестирование.

На уровне элементов тестирование объектно-ориентированных программ отличается по следующим показателям:

· определение единиц тестирования;

· тестирование наследования;

· тестирование полиморфизма.

Естественной единицей тестирования является класс. Разбиение его на более мелкие элементы (методы) нецелесообразно, поскольку они не существуют отдельно от классов. Иногда за единицу тестирования принимается тесно связанная группа классов.

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

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

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

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

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

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

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

Построение требований к системе в форме вариантов использования обеспечивает естественный и простой способ планирования системного тестирования. Фактически система вариантов использования становится основой плана тестов на этапе системного тестирования.

Программная документация

 

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

Во-первых, умение создавать программную документацию определяет профессиональный уровень программиста. Заказчик не будет вникать в тонкости и особенности даже самой замечательной программы. Заказчик будет сначала читать документацию. Большую роль играет в этом и психологический фактор. В частности, во всем мире ценилась (и ценится сейчас) былая советская школа программирования. Современные же отечественные программисты котироваться перестали. Класс не тот. Нынче программы уже не пишутся, а составляются (а это - «две большие разницы»). Так вот, созданный в «классическом» стиле пакет программной документации (далее - ПД) создаст у вашего заказчика или работодателя самое что ни на есть благоприятное впечатление. Тем более, если автор ПД будет избегать фраз вида «кликните на скроллбар…», «винт» и т.п. К сожалению, за подобной жаргонной трескотней обычно скрывается либо скудость мыслей, либо полная пустота (неизгладимое впечатление произвел на автора рассказ одного его знакомого о неком «геймере», который с кем-то там то ли «чатился», то ли «модераторством» занимался или что-то в этом роде.). Язык ПД - это своего рода бюрократический, весьма консервативный язык. Есть в нем своя особая прелесть. Согласитесь, что термины НЖМД, НГМД, ручной манипулятор типа «мышь» (или «колобок», как значилось в одном из старинных пакетов ПД) звучат совсем иначе, нежели соответствующие «винт», «флоп» и просто «мышь». Между прочим, дело уже дошло до того, что, говорят, появилась даже особая специальность - технический писатель, т.е. человек, умеющий создавать программную документацию.

Во-вторых, грамотно составленный (точнее, созданный) пакет ПД избавит вас от многих неприятностей. В частности, избавиться от назойливых вопросов и необоснованных претензий можно просто отослав пользователя к документации. Это касается прежде всего важнейшего документа - Технического задания. Об этом мы будем говорить ниже, а сейчас можно напомнить о многомиллионном иске к компании IBM. Этот иск предъявило одно крупное издательство, неудовлетворенное качеством ВТ и программного обеспечения. IBM суд выиграла. И выиграла только благодаря тому, что предъявила подписанное обеими сторонами Техническое задание. Было это давно, еще в 70-х гг., однако сути дела это не меняет.

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

Для начала необходимо вооружиться ГОСТами. ГОСТ определяет все. В частности, в него входит и интересующая нас Единая система программной документации (ЕСПД).

Техническое задание оформляют на листах формата А4 и / или А3, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.

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

Техническое задание должно содержать следующие разделы:

. Наименование и область применения;

. Основание для разработки;

. Назначение разработки;

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

. Технико-экономические показатели;

. Стадии и этапы разработки;

. Порядок контроля и приемки;

. Приложения.

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

Список литературы

1. Информатика базовый курс. 2-е издание / Под ред. С.В. Симоновича. - Спб.: Питер, 2008. - 640 с.: ил

2. Гейн А.Г., Сенокосов А.И. справочник по информатике для школьников. - Екатеринбург: «У-Фактория», 2003. - 346 с.