СиППО (46-53) (987682), страница 4

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

Текст из файла (страница 4)

В реализации участвуют архитектор, инженер по компонентам и системный интегратор.

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

Инженер по компонентам отвечает за исходные тексты компонентов, за реализацию классов и подсистем. Что точно понимается под компонентом, зависит от среды реализации. Компонент – это физический контейнер для элементов модели (подсистем и классов). Наиболее распространенные виды компонентов: исполняемый модуль - программа, готовая к запуску; файл с исходным текстом программы (или вспомогательный файл); таблица реляционной базы данных. Компоненты предоставляют те же интерфейсы, что и элементы моделей, реализацией которых они являются. Между компонентами может существовать зависимость компиляции, показывающая, в какой очередности компоненты следует скомпилировать для получений работоспособной программы.

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

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

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

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

50. Особенности тестирования программных средств, построенных по объектно-ориентированной методике. Тестирование классов.

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

· Проверять как можно раньше.

· Проверять часто.

· Проверять в полном объеме.

Из сказанного вытекают следующие виды проверок:

· Проверка моделей.

· Тестирование классов.

· Тестирование взаимодействия и иерархии классов.

· Системное тестирование.

Основной недостаток стандартных проверок заключается в том, что проверяется то, что уже имеется (модели, программы), а не то, что там должно быть. При целенаправленной проверке все модели проверяют по мере их создания на предмет соответствия требованиям проекта. Модель целенаправленной проверки [7] представлена на рис. 7.1.

Рис. 7.1.

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

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

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

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

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

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

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

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

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

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

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

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

Класс должен быть протестирован по всем перечисленным случаям.

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

1. Покрытие, основанное на ограничениях: сколько пар предусловие – постусловие покрываются тестами.

2. Покрытие, ориентированное на состояния: основано на том, сколько переходов между состояниями покрываются тестами.

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

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

51. Тестирование взаимодействия классов. Тестирование иерархии классов.

1) Тестирование взаимодействия классов.

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

· Один класс может быть типом формального параметра метода другого класса.

Характеристики

Список файлов ответов (шпаргалок)