[Курьёзный тест] - смешные и глупые проблемы с тестами


(Romanchuk Katerina) #1

Доброй ночи!

Коллеги, а расскажите какие у вас были самые курьёзные фейлы тестов?

Например, тест не фейлился, хотя фича совсем не работает.
Либо тест фейлится, хотя руками все проходится без проблем. Что-то что больше всего запомнилось)
Самый-самый epic fail, на расследование которого потратили много времени)


Дайджест полезных ссылок для тестировщиков-автоматизаторов #020
(Дмитрий Жарий) #2

Мы тестировали очень крупное «коробочное» десктопное приложение, с необъятным количеством строк кода на C++ под Windows.

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

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

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

В итоге, все дружно заявили: «Это все ваша автоматизация виновата», но баг решили держать открытым.

Заставили ещё гонять тесты на специальной, Debug версии... но как мы не старались, в Debug-билде ошибки не было.

Так продлилось ещё некоторое время, пока на стадии бета-тестирования, один из пользователей не сообщил о такой же проблеме при сохранении пользователя.

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

Собрали Debug версию того же билда. Прогнали тот-же тест... и...
не воспроизвели.

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

Хорошо, что ошибку удалось исправить в момент беты.
Отозвать диски с релизом и простой полок в магазине обошёлся бы дорого.

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


(apetrovskiy) #3

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

Мне припоминаются случаи проблем, когда их быть не должно.
К примеру, приложение: визард на .NET, в собственной остнастке в MMC 3.0. На некоторых шагах визарда есть поля ввода с автодополнением. Поля ввода самые обычные, но там навёрнуто много кода между UI и API. Когда помещаешь текст при помощи UI Automation, приложение крэшится. UI Automation активирует другое событие, но это не проблема. Автодополнение - не проблема. В итоге, программеры не смогли разобраться (если скопировать форму в новый проект - всё работает), решили через вывод окна в фокус и сендкейс в эти два текстбокса.

Подобный же случай - часто падает визард одного сетапа (только одного) на шаге Installing. Тест просто нежно проверяет наличие контрола на форме и спит дальше - это медленный шаг. Скорее всего, форма периодически уходит в бэкграунд и тест попадает в неурочный час. Руками никто визард не трогает в момент установки, посему это и не баг.
Но времени занимает регулярно - то шаг становится медленнее, когда продукт меняют, то настоящие баги мешают. Время от времени приходится этот тест трогать - должна же быть и user-side проверка сетапа.

А вот припоминается успех, много лет назад. Дльлька C++ в приложении, которое копирует большие объёмы файлов с сохраниением иерархий, пермиссиями, между разнообразными серверами (эта история была на Windows-Windows копировании), с кастомизациями пермиссий, файловых иерархий и т.д. Сотрудник жаловался, что копирует медленно - интуитивно казалось, что медленно. Решили проверить на объёмах. Я накорябал утилитку для генерации файлов на Win32 (самый обычный цикл на C++ с созданием иерархий) и нагенерили что-то за сорок миллионов фалов. И нашли! ТАКИЕ объёмы копировались медленнее, чем через Windows Explorer (а должно быть побыстрее). Оказалось, что про программер написал цикл обхода (не помню, что там делалось, пермиссии, атрибуты или логгинг), прикол был в том, что точно такой же цикл обхода УЖЕ был написан год назад. Цикл в цикле работал помедленнее и на сорока миллионах файлов разница с Проводником уже была заметна. smile Вот так через акцептанс тест, наполовину ручной, сделали код ревью :):)


(Romanchuk Katerina) #4

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

Steps:
1. Дала денег на одну "коробочку удачи"- купила.
*- > Если попался не ломающийся предмет - даю денег на новую 1 коробочку и снова покупаю...
- > Если попался подходящего типа предмет - прекращаю покупку.*
2. Изнашивала предмет (чтоб он грубо говоря сломался)
3. Чинила предмет
4. Проверяла целостность предмета после починки.

Тест успешно написала, засабмитила и забыла про него.
Прошло больше месяца и тест начал периодически падать на ремонте.
Я начала подозревать что-то неладное, но причину понять не могла. Тест падал примерно 1 раз из 15-20 прогонов.

Каково было моё удивление, когда я увидела, что забыла дать себе денег на сам ремонт.
То есть предмет не чинился, потому что на это не хватало денег. А тесты так редко падали и стабильно работали поскольку с коробки удачи часто подарком было бабло)). Этих "подарочных" денег мне и хватало на ремонт так долго.
blush


(Максим Таран) #5

Это да. Защита часто приводит к таким ситуациям.


(Mykhailo Poliarush) #6

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

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

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

  1. английские слова в названиях переменных и методах написаны с ошибками
  2. неправильное использование регистров в названиях переменных и методов
  3. не отформатированный код
  4. неверно реализованные циклы
  5. и т.д.

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


(Максим Таран) #7

А на чём тесты были? smile


(Mykhailo Poliarush) #8

Если ты за немецкий проект говоришь, то на webdriver + grails + groovy


(Максим Таран) #9

Ага, за него smile


(YobiByte) #10

Не знаю, почему такие фейлы можно назвать смешными, но, когда у тебя всё работало, а потом, вдруг, перестало, да так, что сыпятся ошибки, решения которых в интернете тебе не помогают ничем, в сам момент этих фейлов я бы их не назвал курьёзными. Хотя, по прошествии времени, мнение меняется в лучшую сторону smile .

Мой пример:
Есть web-приложение для банковских расчётов, всё - на Java (back-end) и на JavaScript (front-end). Автоматизация - часть проекта, на WebDriver. Никакие библиотеки руками устанавливать нельзя (Американский БАНК!), есть собственное, многократно проверенное на безопасность, хранилище, куда "смотрит" Maven. Так вот, работала автоматизация UI, работала, а потом "хоп!" и перестала. Я по ошибкам бегаю, гуглю решения, не подходят варианты решения, никакого улучшения.

Я проверил код, стал проверять компоненты и заметил, что у одной из либ вэбдрайвера версия немного отличается "вниз". Я лезу в pom.xml , смотрю - всё норм, версия указана верно, думаю - глюк проекта, сидел, искал решения. Не нашёл. Девелоперы вокруг прикалывались, что "уличная магия". Я одного из них привлёк, когда надоело впустую ковыряться самому, и вот что обнаружилось: какая-то нехорошая(ие) голова(ы) американского(их) админа(ов) додумалась(ись) изменить кое-что в хранилище...

Итого, у меня была ссылка на "нормальную" версию, а в самом хранилище товарищ (читай - "редиска") взял и применил... релокацию. А я тогда вообще не знал, что он есть, этот механизм релокации в Maven. Я, значится, обращался в одно место, а мой запрос перенаправлялся в другое, на более "старую" версию, которая и начинала в проект "подсасываться", из-за чего проблемы и были.

Вот он, "корень зла":
http://maven.apache.org/guides/mini/guide-relocation.html


(rpwheeler) #11

История скорее банальная, но отголосок её в презентацию попал wink

Сборки промежуточных релизов iOS приложения проходили обязательную проверку скриптом по методу "обезьяньего тестирования", т.е. случайного тыка. После очередной большой переделки и коммитов, приложение стало на "обезьяньем тесте" валиться. По stacktrace разработчики ничего не могли сказать, а ошибка повторялась раз за разом, но далеко не сразу. Чтобы показать им наглядно, что собственно произошло, на дисплей Макинтоша на котором в iOS Simulator гонялся тест, была аккуратно наведена веб-камера, подключена к соседнему ПК, на который поставлена программа для видеозаписи, и всё это оставлено на ночь.

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

Вот тогда я и увидел вытаращенные глаза разработчика, и услышал "знаменитую фразу" "Да ни один живой пользователь никогда в жизни...!!!11111", которую вспоминал потом в выступлении на ATDays.

Некоторые, слыша о видеозаписи "обезьяньего теста", смеются, но это работает.


(rpwheeler) #12

Вторая история про "слава роботам".

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

Ура, починили!
Попробовал залогиниться вручную, — логин не работает, зависает.
Запустил еще раз автотест, — логинится.
Попробовал еще раз вручную, — зависает.
Блин, да в чём же дело, почему Webdriver заходит, а я нет?

Проверки на настройки прокси и пр. результата не дали. Загадка оставалась. Тогда я начал смотреть проблему в Network monitor Chrome Developer tools. Оказалось, что при попытке входа вручную не проходит запрос к серверному сервису авторизации, так как браузер не доверяет его SSL сертификату. Но для Webdriver такая проблема почему-то вообще не стояла, — он не обращал внимание на то, что у сервиса самоподписанный сертификат, и спокойно им пользовался. После ручного импорта сертификата в Trusted root проблема была снята, и ручной вход заработал, но поиски причины проблемы всё же заняли довольно много времени.


(YobiByte) #13

Почти всё понятно, но, простите, мой мозг не в силах составить картинку при чтении текста

Поясните, плиз. Уж больно разгадка интересна
blush


(Dmitriy Zverev) #14

Примерно 6 лет назад я тестировал антивирусный link-cheker (проверка сайта на вирусы перед его загрузкой в браузер). Для этого я написал вспомогательного робота, который рандомно ходил по сайтам и оставил его на ночь. Каково же было мое удивление, когда утром я обнаружил в логе - больше половины сайтов, по которым ходил робот, была порно-ресурсами. Пришлось объяснять коллегам и админам, что я совсем не собирался составлять базу порно-контента. Зато это была отличная проверка на вирусы.


(Максим Таран) #15

А ссылки робот откуда взял? smile


(Mykhailo Poliarush) #16

Так тестировали наверное какой-то порно-сайт smile а там ссылок обычно много smile


(Максим Таран) #17

Гы, если только в качестве отправной точки. smile


(Dmitriy Zverev) #18

Так и есть, но в качестве отправной точки я взял вполне приличный сайт smile (то ли udaff, то ли fishki). В общем, энтропия интернета на тот момент вполне ясно показывала преобладание порносайтов. Сейчас, наверное, робот упёрся бы в социальные сети.


(Александр Шиповалов) #19

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


(OlgaV) #20

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