Изменение методики при объектно-ориентированном тестировании

• тестированию модулей традиционного ПО соответствует тестирование классов объектно-ориентированного ПО;

• тестирование традиционных модулей ориентировано на поток управления внутри модуля и поток данных через интерфейс модуля;

• тестирование классов ориентировано на операции, инкапсулированные в классе, и состояния в пространстве поведения класса.

Тестирование объектно-ориентированной интеграции

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

Р. Байндер предлагает две методики интеграции объектно-ориентированных систем:

1. тестирование, основанное на потоках;

2. тестирование, основанное на использовании.

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

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

Д. МакГрегор считает, что одним из шагов объектно-ориентированного тестирования интеграции должно быть кластерное тестирование. Кластер сотрудничающих классов определяется исследованием CRC-модели или диаграммы сотрудничества объектов. Тестовые варианты для кластера ориентированы на обнаружение ошибок сотрудничества.

Объектно-ориентированное тестирование правильности

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

Для упрощения разработки тестов используются элементы Use Case, являющиеся частью модели требований. Каждый элемент Use Case задает сценарий, который позволяет обнаруживать ошибки во взаимодействии пользователя с системой.

Для подтверждения правильности может проводиться обычное тестирование «черного ящика».

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

9. Управление качеством ас

49. Процесс управления качеством. Обеспечение и планирование качества.

1. Процесс управления качеством

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

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

(Например, удобство сопровождения, повторяемость кода, переносимость, гибкость настроек, встроенный язык программирования).

2. Неизвестно, как точно определить и измерить определенные показатели качества (например, то же удобство сопровождения).

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

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

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

Теоретически управление качеством основывается на принципе опреде­ления стандартов и процедурных норм, в соответствии с которыми должно разрабатываться ПО, а также на проверке выполнения этих норм всеми разработчи­ками и менеджерами.

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

Процесс управления качеством состоит из трех основных видов деятельности:

1. Обеспечение качества. Определение множества организационных процедур и стандартов в целях создания ПО высокого качества.

2. Планирование качества. Выбор из этого множества соответствующего подмножества процедур и стандартов и адаптация их к данному проекту разработки ПО.

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

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

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

Международным стандартом, который любая компания в любых сферах производства может принять за основу развития системы управления качеством, можно назвать ISO 9000, разработанный Международной организации по стандартизации (ISO). ISO 9000 — это целый ряд всевозможных стандартов, применимых как в промышленности, так и в сфере услуг. ISO 9001 является наиболее обобщенным из этих стандартов и отно­сится к организациям, занимающимся разработкой, производством и сопровождением различных товаров. Поддерживающая документация (ISO 9000-3) адаптирует ISO 9000 к разработке программных продуктов.

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

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

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

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

Деятельность по обеспечению качества направлена на достижение определенного уровня качества при разработке программного обеспечения. Она предполагает определе­ние или выбор стандартов, применяемых либо к самому процессу разработки ПО, либо к готовому продукту. Эти стандарты могут быть частью процессов производства ПО. В ходе выполнения таких процессов могут применяться средства поддержки, учитывающие вы­бранные (или разработанные) стандарты качества.

В процессе обеспечения качества могут применяться два вида стандартов:

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

Стандарты на процесс создания ПО. Определяют ход самого процесса создания про­граммного продукта, например разработку спецификации, процессы проектирова­ния и аттестации. Кроме того, они могут описывать документацию, создаваемую в ходе выполнения этих процессов.

Коментарий по качеству ЛР

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

Стандарты в разработке программной продукции важны по ряду причин, основные из которых:

1. Стандарты аккумулируют все лучшее из практической деятельности по созданию ПО.

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

2. Стандарты предоставляют необходимую основу для реализации процесса обеспечении качества и контроля процесса создания ПО.

3. Стандарты незаменимы, когда работа переходит от одного сотрудника к другому.

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

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

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

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

1. Вовлечь самих программистов в разработку стандартов.

Они должны ясно пони­мать, с какой целью разрабатывается стандарт, и четко следовать установленным правилам и нормативам.

2. Регулярно просматривать и обновлять стандарты, чтобы идти в ногу с быстро раз­вивающимися технологиями.

3. Обеспечить поддержку стандартов программными средствами. (Например: VS, RRos)

Стандарты на процессы разработки ПО также могут вызвать ряд проблем, если ставят перед командой разработчиков практически неосуществимые задачи. Такие стандарты дают руководящие советы по выполнению работы, при этом менеджеры проектов могут интерпретировать их каждый по-своему. Нет смысла указывать определенное направле­ние работы, если оно неприменимо к данному проекту или к самой команде разработчи­ков. Поэтому менеджер нроск'га должен иметь право изменять стандарты процесса созда-нияГЮ в соответствии со специфическими условиями именно данного проекта. Здесь следует оговориться, что это утверждение не относится к стандартам на качество готовой _г продукции и на процесс сопровождения программной системы, которые могут быть из­менены только после глубокого изучения данного вопроса.

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