Управление Закодированными Тестами ИП в процессе ЖЦРПО

ЖЦРПО или жизненный цикл разработки программного обеспечения охватывает огромное множество различных процессов таких как: «Водопад», «Agile», «Scrum», «XP»; это некоторые из них.

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

Увеличить

Рисунок 1 – Пример фаз ЖЦРПО Водопад

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

Инициирование поставки

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

Требования

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

Проектирование

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

Построение

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

Стабилизация

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

Развертывание

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

Закрытие

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

Влияние на автоматизацию

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

Один из способов это сделать – использовать ваши записанные действия в Закодированных Тестах ИП и сохранить их для использования в тестовый случай. Возьмем пример, вы собираетесь быстро запустить сценарий автоматизации, который открывает веб-сайт, что-то делает, а затем проверяет ожидаемое:

Увеличить

Рисунок 2 – Пример общего тестового случая

В Visual Studio это будет выглядеть примерно так:

Увеличить

Рисунок 3 – Общий Сценарий Тестирования Закодированных Тестов ИП

Увеличить

Рисунок 4 – Пример UIMap.uitest

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

Итоги

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

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