Автотесты: критерии завершенности


(Mykhailo Poliarush) #1

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

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

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

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

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

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

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

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

  • Hard-coding сведен к минимуму. Настоящий джедай избегает использования магических чисел и магических слов, так как их смысл может со временем быть утерян. То есть, использование числовых, строковых и прочих константных значений в явном виде должен быть сведен к минимуму. Явное указание значений уместно в случаях:
    • Задается формат ввода/вывода
    • Задается указание к некоторому зафиксированному внешнему ресурсу, являющемуся частью системы
    • Ограничителя заданы явно
  • Область видимости компонентов ограничена областью использования - подразумевается, что объявления переменных/функций/классов/объектов и т.п. должны быть доступны только там, где они реально используются, но не более того. Также, нужно свести использование глобальных объектов/переменных к минимуму.
  • Именование, форматирование компонентов осуществляется в соответствии с принятыми стандартами
  • Все действия и проверки, предусмотренные тестами (и реализуемые автоматически), реализованы - так или иначе, есть некоторые предписания, которые являются основой для автоматического теста. Это либо спецификации, либо тестовые сценарии. Если мы делегируем часть тестирования машине, то мы должны гарантировать, что возложенные задачи будут выполняться. Таким образом, все действия и проверки должны быть либо реализованы, либо должно быть указание, почему они так или иначе пропущены
  • Вывод, осуществляемый тестом, должен быть информативным - хорошо написанный тест после выполнения позволит указать, были ли ошибки, если были, то выдаст сообщение, четко объясняющее проблему, а также место возникновения ошибки
  • Тест реализует предусмотренные действия наиболее оптимальным путем - те или иные алгоритмы реализуют некоторые задачи лучше, другие - хуже. Нужно обеспечить, чтобы используемые средства наиболее эффективно реализовывали поставленную задачу и были минимально чувствительны к корректировкам системы
  • Тест должен минимально зависеть от настроек конкретной машины - нужно минимизировать привязку к системе. Как правило, это предпочтение использования относительных путей вместо абсолютных, либо вынесение некоторых ключевых частей в конфигурационный файл или другой внешний ресурс.

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