Сканер ошибок на страницах

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

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

Я уже писал в блоге про скрипт для поиска 404 ошибок на сайтах, но еще одной из распространенных проблем являются JS ошибки. Иногда они появляются сразу при открытии страницы, иногда при взаимодействии (нажимаем на кнопку/баннер/скидку - и видим ошибку в консоли браузера). Почему-то даже в 2020 не все тестировщики проверяют страницы на JS ошибки, а они иногда блокируют пользователя, и найти их можно быстро.

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

Так что вот, держите инструмент Pages Checker.

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

Отчет для страницы ozon.ru

Отчет для страницы mail.ru

И мой любимый пример с https://software-testing.ru (парадокс багов: они повсюду)

Хотя, конечно, по-прежнему, большая часть проблем с контентом может быть обнаружена только человеком при "ручном" тестировании.

Учимся находить уязвимости XSS

Довольно много людей мечтают быть хакерами и взламывать банки.

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

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

Одним из таких видов уязвимостей можно назвать XSS. Если у вас есть браузер и доступ в интернет - вы можете попробовать поискать уязвимости на разных сайтах и обязательно их найдете (и это классно, ведь это наша мечта здорово когда есть на чем практиковаться).

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

https://excess-xss.com/

А еще одни ребята сделали игру для поиска XSS инъекций, советую вам в нее поиграть и попробовать пройти все шаги:

https://xss-game.appspot.com/

Наименование аттрибутов в Python: не все очевидно

Недавно я начал работать над собственной библиотечкой Smart PageObject для Python тестов, и заметил, что наследование аттрибутов в Python зависит от имени аттрибута, что было неожиданно для меня, хотя я пишу на этом языке уже давно (и периодически продолжаю удивляться, да).

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


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

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

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


Теперь, если мы не хотим переопределять метод input, внутри класса b мы обызаны работать с аттрибутом _a__numbers вместо __numbers, и постоянно помнить об этом.

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

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

Простые советы по поиску багов - или напоминалка мне самому

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

Простые способы найти баги:
1) Фантазировать что вы реальный пользователь и выполнять реальные действия в системе (а не просто проверять функционал отдельных элементов)
2) Проверять JS консоль на ошибки (тут можно найти очень много "скрытых" проблем)
3) Постоянно тестировать с разными аккаунтами (разные роли / права доступа)
4) Обновлять страницу и проверять что она выглядит так же (иногда при обновлении страница загружается уже другая)
5) Пытаться взаимодействовать даже с неактивными элементами (нажатие на неактивные кнопки и ссылки)
6) Проверять обработку введенных значений во всех полях (текст, числа, календари, чек-боксы, выпадающие списки и прочее)
7) Проверять все как минимум в двух разных браузерах (и желательно в таких, которые используют пользователи, конечно)
8) Менять тестовые сценарии и вводимые значения (пестицид, ну вы знаете)
9) Менять размер экрана / устройства (ширина экрана браузера, соотношение сторон экрана и прочее)
10) Уделять время исследовательскому тестированию, когда вы не пишете автотесты и не делаете какие-то срочные / регулярные проверки и задачи, а просто тыкаете свое приложение и изучаете как оно себя ведет в разных условиях

Потестим: баги повсюду

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

1) Баги есть даже на серьезных и крупных проектах с миллионной аудиторией
2) За пять минут показать процесс тестирования не получается, и вместо 5ти минут видео получилось на 30ть минут 😊
3) Чтобы найти баги не нужно вообще знать ничего о тестировании (к сожалению)
4) Мне еще предстоит научиться записывать интересные ролики и нормально их монтировать, а пока делаю так как умею (извините 😂 )

В процессе загрузки моего первого видео на новом канале обнаружился довольно неприятный баг на youtube! (youtube, Карл! - это же Google! - и я уже не говорю про юзабилити проблемы при загрузке видео - это печалька)

Вот и скриншотик с JS ошибками на Youtube:

Печаль, баги повсюду.

Подписывайтесь на канал, ставьте лайки и пишите в комментарии что еще можно потестировать :)

Следующий объект для тестирования - портал http://software-testing.ru 😎(спойлер: посмотреть будет на что 😂😂😂)

Еще раз про pairwise

Всем привет,

эта статья будет интересна тем, кто либо совсем не знает что такое pairwise, либо тем, кто что-то слышал, но все еще не понял что это за черная магия :)

Как многие уже знают, "протестировать все невозможно" - и это утверждение в частности, базируется на том, что полный перебор всех параметров некоторой системы и проверка ее работы при таких параметрах займет миллиарды лет, даже при условии что каждый тест занимает 1 миллисекунду и даже если их запускать параллельно (просто ОЧЕНЬ много возможных комбинаций).

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

Есть исследования (http://www.pairwise.org/papers.asp), которые доказывают, что подавляющее число ошибок в программном обеспечении так или иначе связано с комбинацией оригинальных значений любых двух параметров сложной системы. Конечно, есть ошибки, для воспроизведения которых может потребоваться определенная комбинация определенных значений сразу трех параметров, но вероятность воспроизведения такой ошибки значительно меньше, чем вероятность воспроизведения ошибки, которая воспроизводится при комбинации значений двух параметров.

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

Разберем на простом примере. Есть три параметра:
- Возраст (разбиваем на категории - до 18ти, от 18ти до 24, от 24х до 35ти и от 35 до бесконечности)
- Пол (М/Ж)
- Цвет глаз (карие, голубые, серые, зеленые, черные)

Теперь нам нужно составить комбинации из этих параметров так, чтобы в этих комбинациях для каждого значения параметра "Возраст" присутствовали все значения полей "Пол" и "Цвет глаз". И то же самое для всех остальных параметров. При этом обратите внимание, что это отличается от полного Декартового произведения (где мы бы просто написали все возможные комбинации всех значений), потому что перед нами стоит задача максимально сократить число комбинаций.

Для составления набора комбинаций воспользуемся инструментом PICT (кросс платформенный, с открытым исходным кодом)

Создадим файл data.txt:


И сгенерируем уникальные комбинации, используя метод pairwise:


Эти комбинации мы теперь можем использовать в наших тестах и можно быть уверенными, что эти комбинации отловят 80+% всех багов (эмпирически научно доказано, так что пользуйтесь).

В рассмотренном примере PICT сгенерировал 20 комбинаций, а полное декартово произведение бы дало 40 комбинаций.

Обратите внимание, что метод особенно хорошо работает там, где декартово произведение дало бы нам больше 1000 уникальных комбинаций, при этом pairwise техника может помочь значительно сократить количество таких комбинаций, что сделает задачу "протестировать все уникальные комбинации" - вполне выполнимой (но конечно же всегда есть вероятность супер редких багов, для воспроизведения которых потребуется определенная комбинация 3-4 параметров - помним об этом).

Полезные статьи:
http://qcthoughtsaloud.blogspot.com/2010/06/pairwise-testing.html
http://software-testing.ru/library/testing/test-analysis/1304-pairing

PyTest + TeamCity - автоматический репортинг

Оказывается для тестов на Python есть отличная библиотечка для интеграции с TeamCity - https://github.com/JetBrains/teamcity-messages

Причем она на столько классная, что если вы используете PyTest и TeamCity - то все, что понадобится для интеграции - установить библиотечку. И все :) - все тесты подхватятся автоматически и начнут отображаться в месте с детальной информацией о падающих тестах в TeamCity.