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

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

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

Разделы:

• Сценарии тестирования вручную
• Тестовые сценарии, созданные программным методом
• Записанные или фиксированные тестовые сценарии
• Сгенерированные тестовые сценарии

Сценарии тестирования вручную

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

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

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

Тестовые сценарии, созданные программным методом

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

В стандартной среде разработки программного обеспечения (например, Microsoft Visual Studio или IBM Visual Age) или специализированной среде разработки автоматизированного тестирования (например, IDE с Rational Robot) испытатель может использовать функции и преимущества среды для достижения наилучшего эффекта.

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

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

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

Записанные или зафиксированные тестовые сценарии

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

• Взаимодействие с клиентским пользовательским интерфейсом приложения путем перехвата входных данных, отправленных с периферийных устройств ввода клиента (например, мышь, клавиатура) в операционную систему клиента. В некоторых случаях перехватываются высокоуровневые сообщения между операционной системой и драйвером устройства, содержащие ясное описание взаимодействия. В других случаях перехватываются низкоуровневые сообщения, часто основанные на движениях мыши или нажатии клавиш.
• Перехват сообщений между приложением-клиентом и одним или несколькими приложениями-серверами. Интерпретация этих сообщений обычно основана на стандартных протоколах сообщений, например, HTTP, SQL и т.п. Некоторые инструменты позволяют использовать "базовые" протоколы сообщений, например, TCP/IP, однако в этих случаях работа с тестовыми сценариями усложняется.

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

Многие авторы посвятили свои работы этой и другим проблемам, связанным с использованием записи или фиксации в качестве метода автоматизации тестирования. За дополнительной информацией по этой теме рекомендуется обратиться в Internet к работам следующих авторов: Джейсмса Баха (James Bach), Сема Кейнера (Cem Kaner), Брайана Мэрика (Brian Marick) и Брета Петтикорда (Bret Pettichord), а также к книге Lessons Learned in Software Testing [KAN01]

Сгенерированные тесты

Более сложные программы для автоматизации тестирования позволяют на основе алгоритмов генерировать процедурные аспекты тестирования или аспекты, связанные с данными тестового сценария. Этот подход можно использовать как полезное дополнение к процессу тестирования, но он не достаточен сам по себе. Инструмент Rational TestFactory и функция создания пула данных Rational TestManager могут служить примерами реализации такого подхода.

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

Разделы:

• (Необязательно) Просмотрите тест вручную
• Установите подходящие инструменты прогнозирования
• Восстановите среду и инструменты тестирования

(Необязательно) Просмотрите тест вручную

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

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

Установите подходящие инструменты прогнозирования

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

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

Восстановите среду и инструменты тестирования

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

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

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

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

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

Разделы:

• Реализуйте действия навигации
• Реализуйте точки наблюдения
• Реализуйте точки контроля
• Устраните ошибки реализации

Реализуйте действия навигации

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

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

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

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

Реализуйте точки наблюдения

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

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

Реализуйте точки контроля

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

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

Исправьте ошибки в реализации теста

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

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

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

Во многих случаях данные тестирования удобнее хранить отдельно от тестового сценария. Это позволяет проще и эффективнее управлять тестовым сценарием и данными тестирования. Хранение наборов данных отдельно от теста дает следующие преимущества:

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

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

Восстановите среду тестирования в сохраненное состояние

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

Настройте инструменты и начните выполнение теста

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

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

Устраните ошибки выполнения

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

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

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

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

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

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

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

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

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