О тестировании тестов

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

Итак, на что же можно обратить внимание при тестировании автотестов:

1. Тест должен делать то, что от него ожидается.

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

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

2. Если что-то идёт не так, тест должен адекватно реагировать.

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

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

3. Тест должен корректно отрабатывать как сам по себе, так и будучи запущенным в пачке с другими тестами.

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

Пример 3 (примитивный). Автотест-1 проверяет корректность создания какого-то объекта. Следующий за ним Автотест-2, проверяющий другой способ создания объекта, завершается ошибкой, поскольку объект уже существует, т.к. был создан и не удалён в рамках предыдущего Автотеста-1.

4. (Развитие п.3) Тест должен корректно отрабатывать как в случае успешного выполнения, так и в случае обнаружения ошибки.

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

Пример 4. Автотест-1 отключает некий сервис и проверяет при этом корректность обработки ошибок. После завершения проверок сервис снова включается. Однако когда Автотест-1 обнаруживал ошибку и аварийно завершался, при этом аварийном завершении включение сервиса не было предусмотрено. Следующие за Автотестом-1 тесты дружно завершались ошибками.

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

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

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

6. Если тест обнаруживает ошибку, он должен правильно о ней сообщать.

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

Пример 6. При выполнении автотеста переходим со страницы-1 на страницу-2, оттуда - на страницу-3, где в конце концов жмём на кнопку. По результатам выполнения теста мы получили информацию, что тест завершился с ошибкой, потому что кнопка недоступна. А на самом деле - мы так и остались на странице-1 и даже на страницу-2 по каким-то причинам перебраться не смогли.

Пожалуй, список получился простым. И при грамотном проектировании автотестов все эти моменты должны быть учтены. Однако если команда только начинает работать над автоматизацией и не имеет в этом особого опыта - этот список может быть весьма актуальным. Лично у меня по нему при текущем состоянии автотестов ещё масса работы, и это не считая специфических для проекта вещей, которые я не смогла или не посчитала целесообразным обобщить и описать в этой заметке. Успехов всем идущим по пути автоматизации ;)