OpenQuality.ru

А и Б сидели на трубе, или тестируем автотесты

Добрый день.

В статье “Автоматизация тестирования: зачем это нужно?” мы говорили о той пользе, которую могут принести автотесты. Но насколько мы можем им доверять? Вот на что стоит обратить внимание при внедрении и эксплуатации систем автоматизированного тестирования приложений:

Нет ли ошибок в логике автотеста?

Автотесты - это такой же программный код, как и приложение, которое они проверяют. Ошибки, приводящие к багам в продукте, в автотестах приводят к искажению результатов. Вот пример: “A” и “Б” сидели на трубе. “A” упало. Кто остался на трубе?

if ($pFallen == "A") {
     print "On the tube: Б\n";
} else {
     print "On the tube: A\n";
}

Даже если отбросить случай, при котором помимо “A” и “Б” на трубе сидело “И”, такой код будет очень ненадежным. Если переменная $pFallen будет содержать неопределенное значение (не “A” и не “Б”), то на выходе мы получим “А”. Нужно проверять все допустимые варианты, а при появлении недопустимого сообщать об ошибке.

Действительно ли отчеты о выполнении автотестов выдают достоверные результаты?

Рассмотрим простой пример:

if ($vResult = $vExpected) {
      print "Success\n";
} else {
      print "Failed\n";
}

Такой куcок кода всегда выдаст Success вне зависимости от значений $vResult и $vExpected. Вместо проверки условия (==) происходит присваивание значения (=). Выполнение тестового сценария прошло успешно, баги обнаружены, а в отчете не отобразятся.

Надежность процедуры запуска автотестов

Запускаются ли они тогда, когда это нужно? Не прерывается ли их выполнение в силу внешних причин? Какую версию продукта мы проверяем?

Если продолжительность выполнения автотеста составляет пять часов, а на четвертом часу его работы потребуется доступ к SQL-серверу, то доступность последнего стоит проверить в самом начале работы автотеста. Если автотест сочтет SQL-сервер недоступным, то лучше узнать об этом сразу и не терять драгоценные 4-5 часов. Безусловно, SQL-сервер может стать недоступным и за 5 минут до того, как он станет нужным, но ранняя проверка позволит избежать простых неувязок: опечаток в конфигурационном файле, переименования машины, блокировки аккаунта и т.п.

На машине в разных каталогах лежат три версии программы. Какая из них будет проверена автотестом? Из непосредственно указанного каталога или же из каталога, который первым прописан в PATH?

Какую функциональность покрывают автотесты?

Если автотест тестирует функциональность архиватора tar, то при интерпретации результатов нужно понимать, а что же именно автотест проверяет? Факт создания архива *.tar? Его содержимое? Идентичность структуры файлов и каталогов при разархивации этого файла? Ключи запуска? Что делает автотест в его текущей реализации? Что планируется в него добавить? Что нужно проверять вручную - сейчас и в будущем? У семи нянек дитя без глазу. Важно этого не допустить.

Как проверять автотесты?

Вот что можно предложить:

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

- автотесты тестируют автотесты. В статье “Автоматизированное тестирование автотестов” представлены подходы к организации такой системы.

- доверить проверку автотестов ручным тестировщикам. Найдут они немало. И, кроме того, будут понимать, на что следует обратить внимание при тестировании: до чего не дотянулись щупальца автотеста, что прикрутить, усилить, ослабить, изменить.

Автотесты - отличное оружие тестировщика, но оно должно быть ухоженным и отточенным. Оставайтесь с нами.

Отправить в Twitter, Facebook, ВКонтакте | Опубликовано 31.10.2008 в рубрике "Автоматизация"

Комментарии (2)

1. Автор комментария : Artour Bakiev | December 8, 2008

   Согласен, полезный список check-pont’ов. Его хорошо иметь перед глазами при написании тестов. Я бы взял на себя смелость и переиначил порядок:
   - На первое место поставил бы надёжность запуска;
   - Далее - достоверность результатов;
   - И затем - набор покрываемой функциональности

   Разделы “Нет ли ошибок в логике автотеста?” и “Действительно ли отчеты о выполнении автотестов выдают достоверные результаты?” разделённые в статье, на первый взгляд, пересекаются. Или я ошибаюсь?

   [Ответить]

   
   

2. Автор комментария : Капитан Аляска | December 8, 2008

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

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

   По поводу пересечения “Нет ли ошибок в логике автотеста?” и “Действительно ли отчеты о выполнении автотестов выдают достоверные результаты?”:
   - данные пункты пересекаются в том, что в обоих случаях речь идет об ошибках в коде, что приводит к неверному результату;
   - но ошибка ошибке рознь: ошибки в логике не стоит приравнивать к ошибкам в кодировании, и вот почему:

   – ошибка в логике - это неверный алгоритм. В нашем случае, если с крыши упала А, то будет неверным сказать, что на трубе осталась Б (как известно, кроме Б, там еще осталась И :). То есть, вместо “если упала А, то осталась Б”, надо написать “если упала А, то если осталось Б - наши действия, иначе - выдать исключение (сообщить об ошибке)”.

   – ошибка в кодировании: алгоритм правильный, но спутали = и ==.

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

   [Ответить]

   
   

Добавить комментарий