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

Эволюция

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

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

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

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

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

Теперь рассмотрим, что и как мы можем автоматически протестировать:

• Непосредственно автотесты - динамически такие компоненты проверяются непосредственно во время тестовых запусков, что не выделяет тестирование автоматизированных решений из контекста автоматизированного тестирования, для которого это тесты предназначены. Проще говоря, наиболее эффективный способ проверить работоспособность автотестов - это выполнить эти автотесты.
• Вспомогательные классы/функции/методы - поскольку подобные компоненты представляют собой некоторый программный код, то ничто не мешает применить для них традиционные практики white-box тестирования.
• Оконные объекты - этот тип компонентов специфичен для автоматизированного тестирования, в частности GUI-level тестирования и один из наиболее критичных к изменениям тестируемого приложения. Поэтому, для тестирования подобных компонент следует выработать некоторый workflow-сценарий, который затронет все ( или хотя бы просто большинство ) оконных объектов

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

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

• Читаемость
• Расширяемость
• Переносимость
• Оптимальность
• Соответствие требованиям
• Удобство модификации
• Прочее (добавить по вкусу) 

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

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

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

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

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