Экстремальное программирование

Размещено на http://www.allbest.ru/

Экстремамльное программимрование (англ. Extreme Programming, XP) -- одна из гибких методологий разработки программного обеспечения. Авторы методологии -- Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.

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

Основные приёмы XP

Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:

Короткий цикл обратной связи (Fine-scale feedback)

Разработка через тестирование (Test-driven development)

Игра в планирование (Planning game)

Заказчик всегда рядом (Whole team, Onsite customer)

Парное программирование (Pair programming)

Непрерывный, а не пакетный процесс

Непрерывная интеграция (Continuous integration)

Рефакторинг (Design improvement, Refactoring)

Частые небольшие релизы (Small releases)

Понимание, разделяемое всеми

Простота (Simple design)

Метафора системы (System metaphor)

Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)

Стандарт кодирования (Coding standard or Coding conventions)

Социальная защищенность программиста (Programmer welfare):

40-часовая рабочая неделя (Sustainable pace, Forty-hour week)

Тестирование

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

юнит-тестирование модулей;

функциональное тестирование.

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

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

Для XP более приоритетным является подход, называемый TDD (от англ. test-driven development -- разработка через тестирование). В соответствии с этим подходом сначала пишется тест, который изначально не проходит (так как логики, которую он должен проверять, ещё просто не существует), затем реализуется логика, необходимая для того, чтобы тест прошел. TDD, в некотором смысле, позволяет писать код, более удобный в использовании -- потому что при написании теста, когда логики ещё нет, проще всего позаботиться об удобстве будущей системы.

Игра в планирование

Основная цель игры в планирование -- быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими. Артефактами игры в планирование является набор бумажных карточек, на которых записаны пожелания заказчика (customer stories), и приблизительный план работы по выпуску следующих одной или нескольких небольших версий продукта. Критическим фактором, благодаря которому такой стиль планирования оказывается эффективным, является то, что в данном случае заказчик отвечает за принятие бизнес-решений, а команда разработчиков отвечает за принятие технических решений. Если не выполняется это правило, весь процесс распадается на части.

Заказчик всегда рядом

«Заказчик» в XP -- это не тот, кто оплачивает счета, а конечный пользователь программного продукта. XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов.

Парное программирование

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

Непрерывная интеграция

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

Рефакторинг

Рефакторинг (refactoring) -- это методика улучшения кода без изменения его функциональности. XP подразумевает, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан. Разработчики XP безжалостно переделывают написанный ранее код для того, чтобы улучшить его. Этот процесс называется рефакторингом. Отсутствие тестового покрытия провоцирует отказ от рефакторинга в связи с боязнью поломать систему, что приводит к постепенной деградации кода.

Частые небольшие релизы

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

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

Простота проектирования

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

Метафора системы

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

Метафора системы (system metaphor) -- это аналог того, что в большинстве методик называется архитектурой. Метафора системы даёт команде представление о том, каким образом система работает в настоящее время, в каких местах добавляются новые компоненты, и какую форму они должны принять.

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

Стандарты кодирования

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

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

обеспечивается эффективное выполнение остальных практик.

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

Коллективное владение

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

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

Тест План (План тестирования)

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

Рекомендации по написанию Тест Плана

экстремальный программирование кодирование тест

Каждая методология или процесс пытаются навязать нам свои форматы оформления планов тестирования. Предлагаю вам, как пример, шаблоны тест планов от RUP (Rational Unified Process) и стандарт IEEE 829:

Test Plan Template RUP

Test Plan Template IEEE 829

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

Что надо тестировать?

описание объекта тестирования: системы, приложения, оборудования

Что будете тестировать?

список функций и описание тестируемой системы и её компонент в отдельности

Как будете тестировать?

стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования

Когда будете тестировать?

последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки

Критерии начала тестирования:

готовность тестовой платформы (тестового стенда)

законченность разработки требуемого функционала

наличие всей необходимой документации

Критерии окончания тестирования:

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

требования к количеству открытых багов выполнены

выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF)

выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB)

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

Окружение тестируемой системы (описание программно-аппаратных средств)

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

Риски и пути их разрешения.

Виды тест планов

Чаще всего на практике приходится сталкиваться со следующими видами тест планов:

Мастер Тест План (Master Plan or Master Test Plan)

Тест План (Test Plan), назовем его детальный тест план)

План Приемочных Испытаний (Product Acceptance Plan) - документ, описывающий набор действий, связанных с приемочным тестированием(стратегия, дата проведения, ответственные работники и т.д.) (Шаблон плана приемо-сдаточных испытаний от RUP)

Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую (High Level) информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является "живым" документом, который постоянно претерпевает изменения, отражающие реальное положение дел на проекте.

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

Рецензия и Утверждение

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

Ведущий тестировщик

Тест менеджер (менеджер по качеству)

Руководитель разработки

Менеджер Проекта

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

Тест-планы

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

На основании тест-требований составляются тест-планы - программы испытаний (проверки, тестирования) программной реализации системы. В отличие от тест-требований в тест-плане описываются конкретные способы проверки функциональности системы, т.е. то, как должна проверяться функциональность. Как правило, тест-план состоит из отдельных тестовых примеров, каждый из которых проверяет некоторую функцию или набор функций системы. Для каждого тестового примера однозначно определяется критерий успешного прохождения ( pass/fail criteria ), при помощи которого можно судить - соответствует ли поведение системы заданному в требованиях или нет (Рис 11.1).

Рис. 11.1 Место тест-планов среди проектной документации

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

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

ссылку на требование(я), которое проверяется этим пунктом;

конкретное входное воздействие на программу (значения входных данных);

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

описание последовательности действий, необходимых для выполнения пунктов тест-плана.

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

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

Возможные формы подготовки тест-планов

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

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

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

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

Сценарии

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

идентификатор;

описание теста и его цель;

ссылки на тестируемую часть системы;

ссылки на используемую проектную документацию, в частности тест-требования;

перечисление действий сценария;

ожидаемая реакция системы на каждый пункт сценария.

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

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

Сообщение "Загрузка" пропадает через приемлемое время

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

Сообщение "Загрузка" исчезает с экрана не более, чем через 10 секунд после появления.

Ниже приведен пример описания тестового примера в виде сценария, предназначенного для ручного тестирования:

Группа тестов: Работа с учетными записями

Тестовый пример: 1289-15

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

Тест-требования: 8.5.8.1, 8.5.8.2

Предусловия для теста: Система должна быть приведена в состояние "Максимальная защита" и сброшена в настройки по умолчанию.

Критерий прохождения теста: Все ожидаемые значения совпадают с реальными

Сценарий тестирования:
№	Шаг сценария	Ожидаемый результат
1	Запустить терминальный клиент и соединиться с системой по адресу 127.0.0.1	Должно появиться приглашение терминала TRANSFER>
2	Запустить процесс передачи данных при помощи ввода команды SEND DATA	Должно появиться приглашение DATA TRANSFER INITIATED и следующими двумя строками Enter your credentials… Login:
3	Ввести имя учетной записи default	Должна появиться строка Password:
4	Ввести пароль default	Должно появиться сообщение Default user blocked - system set to High security и соединение с терминалом должно быть прервано

Как можно видеть, такая форма представления действительно неудобна для автоматизации тестирования и предназначена исключительно для ручного тестирования. Иногда такие тест-планы совмещают с отчетами о проведении тестирования, добавляя в таблицу описания сценария третью и четвертые колонки - "Реальный результат" и "Соответствует", в который заносятся реальная реакция системы и указание на совпадение/несовпадение результатов соответственно. В конце описания каждого тестового примера добавляется графа "Пройден/не пройден", в которую заносится информация о том, пройден ли тестовый пример в целом. В конце всего тест-плана, совмещенного с отчетом, помещается графа "Тестовых примеров пройдено/всего", в которую заносится число пройденных тестовых примеров и общее их число.

Сценарии тестирования для автоматического тестирования часто описывают на том или ином языке программирования. Например, методы в тестирующих классах Microsoft Visual Studio Team Edition представляют собой именно пошаговые описания действий, которые необходимо выполнить тестовому окружению для проведения тестирования. Возможна и более близкая к естественному языку форма подготовки тестовых примеров. Например, при тестировании логической функции с уровнем покрытия MC/DC и описании тестовых примеров на одном из диалектов Visual Basic Script возможно записать сценарий тест-плана в такой форме:

'----------------------------------------------------------------

' TEST CASES

'----------------------------------------------------------------

' 8 testcases

' 1 2 3 4 5 6 7 8

' -----------------------------------------------

' computed - - 0 0 0 - - -

' good1 0 1 0 0 0 0 0 0

' computed2 - - - - 0 - - -

' good2 1 1 1 0 0 1 1 1

' delay - - - - - 0 - -

' pack1 1 1 1 1 1 1 0 0

' pack2 0 0 0 0 0 0 0 1

' -----------------------------------------------

' output_message 1 0 0 1 0 0 0 1

'-------------------------------------------------------------------

' Testcase #1:

Call Test_Message_Call (-, 0, -, 1, -, 1, 0, 1)

'-------------------------------------------------------------------

' Testcase #2:

Call Test_Message_Call (-, 1, -, 1, -, 1, 0, 0)

'-------------------------------------------------------------------

' Testcase #2:

Call Test_Message_Call (0, 0, -, 1, -, 1, 0, 0)

'-------------------------------------------------------------------' Testcase #4:

Call Test_Message_Call (0, 0, -, 0, -, 1, 0, 1)

'-------------------------------------------------------------------' Testcase #5:

Call Test_Message_Call (0, 0, 0, 0, -, 1, 0, 0)

'-------------------------------------------------------------------' Testcase #6:

Call Test_Message_Call (-, 0, -, 1, 0, 1, 0, 0)

'-------------------------------------------------------------------' Testcase #7:

Call Test_Message_Call (-, 0, -, 1, -, 0, 0, 0)

'-------------------------------------------------------------------' Testcase #8:

Call Test_Message_Call (-, 0, -, 1, -, 0, 1, 1)

Листинг 11.1.

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

Оценка качества тестируемого кода - статистика выполнения тестов

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

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

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

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

Например,

180 test cases passed

20 test cases failed

200 test cases total

1 + вывод идентификаторов не прошедших тестовых примеров. Позволяет локализовать тестовые примеры, потенциально выявившие дефект.

Например,

Invoking test case 1 … Passed

Invoking test case 2 … Failed

Invoking test case 3 … Failed

<…>

Invoking test case 200 … Passed

Final stats:

180 test cases passed

20 test cases failed

200 test cases total

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

Например,

Invoking test case 1 … Passed

---

Invoking test case 2 … Failed

Expected values: Actual values:

A = 200 A = 0

B = 450 B = 0

Message = "Submenu 1" Message = ""

---

Invoking test case 3 … Failed

Expected values: Actual values:

A = 0 A = 200

B = 0 B = 300

Message = "" Message = "Main Menu"

---

<…>

Invoking test case 200 … Passed

---

Final Stats

180 test cases passed

20 test cases failed

200 test cases total

2 + вывод всех ожидаемых и реальных выходных данных. Вариант предыдущего пункта.

Например,

Invoking test case 1 … Passed

---

Invoking test case 2 … Failed

Expected values: Actual values:

A = 200 A = 0 FAIL

B = 450 B = 0 FAIL

C = 500 C = 500 P

D = 600 D = 600 P

Message = "Submenu 1" Message = "" FAIL

---

Invoking test case 3 … Failed

Expected values: Actual values:

A = 0 A = 200 FAIL

B = 0 B = 300 FAIL

C = 500 C = 500 P

D = 600 D = 600 P

Message = "" Message = "Main Menu" FAIL

---

<…>

Invoking test case 200 … Passed

---

Final Stats

180 test cases passed

20 test cases failed

200 test cases total

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

Например,

Invoking test case 1 … Passed

A = 0 A = 0 P

B = 0 B = 0 P

C = 500 C = 500 P

D = 600 D = 600 P

Message = "" Message = "" P

---

Invoking test case 2 … Failed

Expected values: Actual values:

A = 200 A = 0 FAIL

B = 450 B = 0 FAIL

C = 500 C = 500 P

D = 600 D = 600 P

Message = "Submenu 1" Message = "" FAIL

---

Invoking test case 3 … Failed

Expected values: Actual values:

A = 0 A = 200 FAIL

B = 0 B = 300 FAIL

C = 500 C = 500 P

D = 600 D = 600 P

Message = "" Message = "Main Menu" FAIL

---

<…>

Invoking test case 200 … Passed

Message = "Submenu 1" Message = "Submenu 1 P

Prompt = ">" Prompt = ">" P

---

Final Stats

180 test cases passed

20 test cases failed

200 test cases total

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

Понятие покрытия

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

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

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

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

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

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

Анализ покрытия

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

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

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

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

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

Литература

1. Кент Бек: Экстремальное программирование Питер, 2002, ISBN 5-94723-032-1.

2. Кент Бек, Мартин Фаулер: Экстремальное программирование: планирование Питер, 2003, ISBN 5-318-00111-4.

3. Кент Бек: Экстремальное программирование: разработка через тестирование Питер, 2003, ISBN 5-8046-0051-6.

4. Кен Ауэр, Рой Миллер: «Экстремальное программирование: постановка процесса с первых шагов и до победного конца» Питер, 2003, ISBN 5-318-00132-7.

Размещено на Allbest.ru